On Wed, Dec 22, 2021 at 02:02:43PM +0000, cipher-hea...@riseup.net wrote: > On Mon, Dec 20, 2021 at 11:14:49AM -0700, Theo de Raadt wrote: > > Mark Kettenis <mark.kette...@xs4all.nl> wrote: > > > > > > Date: Mon, 20 Dec 2021 15:10:42 +0100 > > > > From: Anton Lindqvist <an...@basename.se> > > > > > > > > On Mon, Dec 20, 2021 at 01:19:54PM +0000, cipher-hea...@riseup.net > > > > wrote: > > > > > I booted into bsd.rd to grep in /var/log/messages when I last ran > > > > > sysupgrade: > > > > > > > > > > Dec 19 22:11:48 0 sysupgrade: installed new /bsd.upgrade. Old kernel > > > > > version: OpenBSD 7.0-current (GENERIC.MP) #135: Tue Nov 30 17:39:34 > > > > > MST 2021 > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > Dec 1 20:17:52 0 sysupgrade: installed new /bsd.upgrade. Old kernel > > > > > version: OpenBSD 7.0-current (GENERIC.MP) #106: Fri Nov 19 10:43:11 > > > > > MST 2021 > > > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP > > > > > > > > > > Below is the error message at boot, typed manually, and double-checked > > > > > (omitted the file system checks before wd0e which were all clean, and > > > > > the > > > > > generic instructions after 'dbb.html describes') > > > > > > > > > > -------------------------------------------------------------------------------- > > > > > > > > > > dev/wd0e (afcec7a171c4b011.e): file system is clean; not checking > > > > > uvm_fault(0xfffffd807eaa7220, 0x0, 0, 1) -> e > > > > > kernel: page fault trap, code=0 > > > > > Stopped at comopen+0x710: movq 0(%rax),%r11 > > > > > TID PID UID PRFLAGS PFLAGS CPU COMMAND > > > > > *189345 37957 0 0x3 0 2K > > > > > ttyflags > > > > > comopen(800,5,2000,ffff8000fffeed20) at comopen+0x710 > > > > > spec_open(ffff800042489638) at spec_open+0xd6 > > > > > VOP_OPEN(fffffd806e86f568,5,fffffd807ee7af00,ffff8000fffeed20) at > > > > > VOP_OPEN+0x53 > > > > > vn_open(ffff800042489850,5,0) at vn_open+0x271 > > > > > doopenat(ffff8000fffeed20,ffffff9c,7f7ffffe2bd0,4,0,ffff800042489a20) > > > > > at doopenat+0x1cd > > > > > syscall(ffff800042489a90) at syscall+0x374 > > > > > Xsyscall() at Xsyscall+0x128 > > > > > end of kernel > > > > > end trace frame: 0x7f7ffffe2bc0, count: 8 > > > > > https://www.openbsd.org/dbb.html describes... > > > > > ... > > > > > ddb{2}> > > > > > > > > Probably caused by the recent change to attach com over acpi. Looking at > > > > your disassembled acpi tables, I see two com devices which lacks a > > > > corresponding _PRS node: > > > > > > > > > > > > Device (UAR1) > > > > { > > > > Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM > > > > Serial Port */) // _HID: Hardware ID > > > > Name (_UID, One) // _UID: Unique ID > > > > } > > > > Device (UAR2) > > > > { > > > > Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM > > > > Serial Port */) // _HID: Hardware ID > > > > Name (_UID, 0x02) // _UID: Unique ID > > > > } > > > > > > Look at the comments in: > > > > > > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/d945gclf/acpi/superio.asl > > > > > > What a joke! > > > > Sadly I have to agree: > > > > coreboot is a joke. > > > > This is not the first time coreboot didn't get around to doing something > > correctly, which is a defect. This results in coreboot-users demanding > > that operating systems work around the defect. Thus operating systems > > have to carry more and more workarounds for defects. Forever, right? > > > > > Maybe. But we should also protect the com(4) driver against > > > "partially attached" driver instances I think. > > > > For around half the life of OpenBSD, I have argued Chris Torek made a > > design mistake --- *attach() functions should have returned "int" not > > "void", so that subr_autoconf.c can avoid establishing some callpaths to > > the driver. > > > -------------------------------------------------------------------------------- > > OK I tried the latest snapshot, here is the new (same) error message: > > uvm_fault(0xfffffd807eaa5770, 0x0, 0, 1) -> e > kernel: page fault trap, code=0 > Stopped at > TID PID UID PRFLAGS PFLAGS CPU COMMAND > *400263 16138 0 0x3 0 2K ttyflags > comopen(800,5,2000,ffff8000fffeed20) at comopen+0x710 > spec_open(ffff8000424895d8) at spec_open+0xd6 > VOP_OPEN(fffffd806e9e5e30,5,fffffd807ee7aea0,ffff8000fffeed20) at > VOP_OPEN+0x53 > vn_open(ffff8000424897f0,5,0) at vn_open+0x271 > doopenat(ffff8000fffeed20, ffffff9c,7f7ffffc9c00,4,0,ffff8000424899c0) at > doopenat+0x1cd > syscall(ffff800042489a30) at syscall+0x374 > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x7f7ffffc9bf0, count: 8
Can you see any '^com*' attachment lines being printed before the panic?
