Page MenuHomeFreeBSD

Remove 'struct trapframe' from mips64's 'struct syscall_args'
ClosedPublic

Authored by trasz on Sep 30 2020, 10:17 PM.

Details

Summary

Remove 'struct trapframe' from mips64's 'struct syscall_args'.
It serves no purpose. While here, use MAXARGS, like other
architectures do.

Diff Detail

Repository
rS FreeBSD src repository
Lint
Automatic diff as part of commit; lint not applicable.
Unit
Automatic diff as part of commit; unit tests not applicable.

Event Timeline

This revision is now accepted and ready to land.Sep 30 2020, 10:19 PM
trasz planned changes to this revision.Oct 3 2020, 1:51 PM

Sigh.

Starting devd.
Autoloading module: intpm.ko
pci0: driver added
found-> vendor=0x8086, dev=0x7110, revid=0x00
domain=0, bus=0, slot=10, func=0
class=06-01-00, hdrtype=0x00, mfdev=1
cmdreg=0x0000, statreg=0x0200, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
pci0:0:10:0: reprobing on driver added
found-> vendor=0x8086, dev=0x7112, revid=0x01
domain=0, bus=0, slot=10, func=2
class=0c-03-00, hdrtype=0x00, mfdev=0
cmdreg=0x0000, statreg=0x0000, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=d, irq=0
pci0:0:10:2: reprobing on driver added
found-> vendor=0x8086, dev=0x7113, revid=0x03
domain=0, bus=0, slot=10, func=3
class=06-80-00, hdrtype=0x00, mfdev=0
cmdreg=0x0000, statreg=0x0280, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=0
pci0:0:10:3: reprobing on driver added
intsmb0: <Intel PIIX4 SMBUS Interface> irq 0 at device 10.3 on pci0
intsmb0: Lazy allocation of 0x4 bytes rid 0x90 type 4 at 0x110
intsmb0: intr IRQ 9 enabled revision 0
smbus0: <System Management Bus> on intsmb0
panic: Not in critical section
time = 1601675419
KDB: enter: panic
[ thread pid 177 tid 100041 ]
Stopped at      0x4
db>

There is something very weird going on with MIPS. Using the images fetched from CI (https://artifact.ci.freebsd.org/snapshot/head/r367395/mips/mips64/disk-test.img.zst, in this case), I can boot just fine with either kernel, vanilla or patched - but only once. Subsequent reboot results in a panic:

db> bt
Tracing pid 151 tid 100041 td 0xc0000000002fd760
kdb_enter+0x94 (?,?,?,?) ra ffffffff8044c9c0 sp ffffffff808bbde0 sz 32
vpanic+0x200 (?,?,?,?) ra ffffffff8044c638 sp ffffffff808bbe00 sz 64
doadump (?,?,?,?) ra ffffffff80725eac sp ffffffff808bbe40 sz 80
MipsKStackOverflow (?,?,?,?) ra 0 sp ffffffff808bbe90 sz 0
--- exception, cause c00000001862a0f0 badvaddr c00000001862a188 ---
sysctl_handle_uma_zone_cur+0x6ae4 (?,?,?,?) ra ffffffff806bfb98 sp c000000018629fa0 sz 96
uma_zalloc_arg+0x180 (?,?,?,?) ra ffffffff806f3a20 sp c00000001862a000 sz 64
vm_page_alloc_domain_after+0x1e8 (?,?,?,?) ra ffffffff806fcac8 sp c00000001862a040 sz 176
vm_page_grab_pages+0x310 (?,?,?,?) ra ffffffff806fd338 sp c00000001862a0f0 sz 272
vm_page_grab_pages_unlocked+0x2d0 (?,?,?,?) ra ffffffff8053c678 sp c00000001862a200 sz 128
allocbuf+0x520 (?,?,?,?) ra ffffffff805397cc sp c00000001862a280 sz 112
getblkx+0xac4 (?,?,?,?) ra ffffffff80538ac0 sp c00000001862a2f0 sz 224
breadn_flags+0x80 (?,?,?,?) ra ffffffff80693cd4 sp c00000001862a3d0 sz 112
ffs_vgetf+0x45c (?,?,?,?) ra ffffffff80693860 sp c00000001862a440 sz 176
ffs_vget+0x18 (?,?,?,?) ra ffffffff806a4964 sp c00000001862a4f0 sz 16
ufs_lookup_ino+0xd74 (?,?,?,?) ra 0 sp c00000001862a500 sz 0

Overwriting the disk image with stock one (basically extracting the zst) makes it boot, but again, only once.

This revision was not accepted when it landed; it landed in state Changes Planned.Fri, Nov 6, 7:20 PM
This revision was automatically updated to reflect the committed changes.