Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
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(0xfd807eaa7220, 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,8000fffeed20) at comopen+0x710 spec_open(800042489638) at spec_open+0xd6 VOP_OPEN(fd806e86f568,5,fd807ee7af00,8000fffeed20) at VOP_OPEN+0x53 vn_open(800042489850,5,0) at vn_open+0x271 doopenat(8000fffeed20,ff9c,7f7e2bd0,4,0,800042489a20) at doopenat+0x1cd syscall(800042489a90) at syscall+0x374 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7e2bc0, count: 8 https://www.openbsd.org/dbb.html describes... ... ddb{2}> Below is a sendbug generated on the same machine on 27th September 2021 (usually try to generate one after a sysupgrade, but seems I forgot in December) SENDBUG: -*- sendbug -*- SENDBUG: Lines starting with `SENDBUG' will be removed automatically. SENDBUG: SENDBUG: Choose from the following categories: SENDBUG: SENDBUG: system user library documentation kernel alpha amd64 arm hppa i386 m88k mips64 powerpc sh sparc sparc64 vax SENDBUG: SENDBUG: To: bugs@openbsd.org Subject: From: root Cc: root Reply-To: root >Synopsis: >Category: >Environment: System : OpenBSD 7.0 Details : OpenBSD 7.0 (GENERIC.MP) #231: Mon Sep 27 17:23:17 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP Architecture: OpenBSD.amd64 Machine : amd64 >Description: >How-To-Repeat: >Fix: SENDBUG: dmesg, pcidump, acpidump and usbdevs are attached. SENDBUG: Feel free to delete or use the -D flag if they contain sensitive information. dmesg: OpenBSD 7.0 (GENERIC.MP) #231: Mon Sep 27 17:23:17 MDT 2021 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP real mem = 212082 (2022MB) avail mem = 2040614912 (1946MB) random: good seed from bootblocks mpath0 at root scsibus0 at mpath0: 256 targets mainbus0 at root bios0 at mainbus0: SMBIOS rev. 2.7 @ 0x7f69f020 (7 entries) bios0: vendor coreboot version "382892c" date 09/07/2016 bios0: Intel D945GCLF acpi0 at bios0: ACPI 4.0 acpi0: sleep states S0 S3 S4 S5 acpi0: tables DSDT FACP SSDT MCFG TCPA APIC HPET acpi0: wakeup devices HDEF(S4) USB1(S4) USB2(S4) USB3(S4) USB4(S4) EHC1(S4) SLT1(S4) SLT2(S4) SLT3(S4) SLT6(S4) LANC(S3) LANR(S3) MODM(S4) SLPB(S4) PWRB(S4) acpitimer0 at acpi0: 3579545 Hz, 24 bits acpimcfg0 at acpi0 acpimcfg0: addr 0xf000, bus 0-63 acpimadt0 at acpi0 addr 0xfee0: PC-AT compat cpu0 at mainbus0: apid 0 (boot processor) cpu0: Intel(R) Core(TM) CPU 330 @ 1.60GHz, 1600.27 MHz, 06-1c-02 cpu0: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu0: 512KB 64b/line 16-way L2 cache cpu0: smt 0, core 0, package 0 mtrr: Pentium Pro MTRR support, 8 var ranges, 88 fixed ranges cpu0: apic clock running at 133MHz cpu0: mwait min=64, max=64, C-substates=0.1, IBE cpu1 at mainbus0: apid 1 (application processor) cpu1: Intel(R) Core(TM) CPU 330 @ 1.60GHz, 1600.00 MHz, 06-1c-02 cpu1: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu1: 512KB 64b/line 16-way L2 cache cpu1: smt 1, core 0, package 0 cpu2 at mainbus0: apid 2 (application processor) cpu2: Intel(R) Core(TM) CPU 330 @ 1.60GHz, 1600.02 MHz, 06-1c-02 cpu2: FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,DTES64,MWAIT,DS-CPL,TM2,SSSE3,CX16,xTPR,PDCM,MOVBE,NXE,LONG,LAHF,PERF,SENSOR,MELTDOWN cpu2: 512KB 64b/line 16-way L2 cac
Re: Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
On Mon, Dec 20, 2021 at 01:19:54PM +, 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(0xfd807eaa7220, 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,8000fffeed20) at comopen+0x710 > spec_open(800042489638) at spec_open+0xd6 > VOP_OPEN(fd806e86f568,5,fd807ee7af00,8000fffeed20) at > VOP_OPEN+0x53 > vn_open(800042489850,5,0) at vn_open+0x271 > doopenat(8000fffeed20,ff9c,7f7e2bd0,4,0,800042489a20) at > doopenat+0x1cd > syscall(800042489a90) at syscall+0x374 > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x7f7e2bc0, 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 } It think we're better of doing the sanity check during match and not attach. This will hopefully cause com to attach over isa as seen in your old dmesg. diff --git sys/dev/acpi/com_acpi.c sys/dev/acpi/com_acpi.c index 12e61288181..eeda6a82bef 100644 --- sys/dev/acpi/com_acpi.c +++ sys/dev/acpi/com_acpi.c @@ -63,6 +63,8 @@ com_acpi_match(struct device *parent, void *match, void *aux) struct acpi_attach_args *aaa = aux; struct cfdata *cf = match; + if (aaa->aaa_naddr < 1 || aaa->aaa_nirq < 1) + return 0; return acpi_matchhids(aaa, com_hids, cf->cf_driver->cd_name); } @@ -77,16 +79,6 @@ com_acpi_attach(struct device *parent, struct device *self, void *aux) sc->sc_node = aaa->aaa_node; printf(" %s", sc->sc_node->name); - if (aaa->aaa_naddr < 1) { - printf(": no registers\n"); - return; - } - - if (aaa->aaa_nirq < 1) { - printf(": no interrupt\n"); - return; - } - printf(" addr 0x%llx/0x%llx", aaa->aaa_addr[0], aaa->aaa_size[0]); printf(" irq %d", aaa->aaa_irq[0]);
Re: Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
> Date: Mon, 20 Dec 2021 15:10:42 +0100 > From: Anton Lindqvist > > On Mon, Dec 20, 2021 at 01:19:54PM +, 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(0xfd807eaa7220, 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,8000fffeed20) at comopen+0x710 > > spec_open(800042489638) at spec_open+0xd6 > > VOP_OPEN(fd806e86f568,5,fd807ee7af00,8000fffeed20) at > > VOP_OPEN+0x53 > > vn_open(800042489850,5,0) at vn_open+0x271 > > doopenat(8000fffeed20,ff9c,7f7e2bd0,4,0,800042489a20) at > > doopenat+0x1cd > > syscall(800042489a90) at syscall+0x374 > > Xsyscall() at Xsyscall+0x128 > > end of kernel > > end trace frame: 0x7f7e2bc0, 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! > It think we're better of doing the sanity check during match and not > attach. This will hopefully cause com to attach over isa as seen in your > old dmesg. Maybe. But we should also protect the com(4) driver against "partially attached" driver instances I think. > diff --git sys/dev/acpi/com_acpi.c sys/dev/acpi/com_acpi.c > index 12e61288181..eeda6a82bef 100644 > --- sys/dev/acpi/com_acpi.c > +++ sys/dev/acpi/com_acpi.c > @@ -63,6 +63,8 @@ com_acpi_match(struct device *parent, void *match, void > *aux) > struct acpi_attach_args *aaa = aux; > struct cfdata *cf = match; > > + if (aaa->aaa_naddr < 1 || aaa->aaa_nirq < 1) > + return 0; > return acpi_matchhids(aaa, com_hids, cf->cf_driver->cd_name); > } > > @@ -77,16 +79,6 @@ com_acpi_attach(struct device *parent, struct device > *self, void *aux) > sc->sc_node = aaa->aaa_node; > printf(" %s", sc->sc_node->name); > > - if (aaa->aaa_naddr < 1) { > - printf(": no registers\n"); > - return; > - } > - > - if (aaa->aaa_nirq < 1) { > - printf(": no interrupt\n"); > - return; > - } > - > printf(" addr 0x%llx/0x%llx", aaa->aaa_addr[0], aaa->aaa_size[0]); > printf(" irq %d", aaa->aaa_irq[0]); > > >
Re: Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
Mark Kettenis wrote: > > Date: Mon, 20 Dec 2021 15:10:42 +0100 > > From: Anton Lindqvist > > > > On Mon, Dec 20, 2021 at 01:19:54PM +, 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(0xfd807eaa7220, 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,8000fffeed20) at comopen+0x710 > > > spec_open(800042489638) at spec_open+0xd6 > > > VOP_OPEN(fd806e86f568,5,fd807ee7af00,8000fffeed20) at > > > VOP_OPEN+0x53 > > > vn_open(800042489850,5,0) at vn_open+0x271 > > > doopenat(8000fffeed20,ff9c,7f7e2bd0,4,0,800042489a20) at > > > doopenat+0x1cd > > > syscall(800042489a90) at syscall+0x374 > > > Xsyscall() at Xsyscall+0x128 > > > end of kernel > > > end trace frame: 0x7f7e2bc0, 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.
Re: Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
> Date: Mon, 20 Dec 2021 15:10:42 +0100 > From: Anton Lindqvist > > On Mon, Dec 20, 2021 at 01:19:54PM +, 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(0xfd807eaa7220, 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,8000fffeed20) at comopen+0x710 > > spec_open(800042489638) at spec_open+0xd6 > > VOP_OPEN(fd806e86f568,5,fd807ee7af00,8000fffeed20) at > > VOP_OPEN+0x53 > > vn_open(800042489850,5,0) at vn_open+0x271 > > doopenat(8000fffeed20,ff9c,7f7e2bd0,4,0,800042489a20) at > > doopenat+0x1cd > > syscall(800042489a90) at syscall+0x374 > > Xsyscall() at Xsyscall+0x128 > > end of kernel > > end trace frame: 0x7f7e2bc0, 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 > } > > It think we're better of doing the sanity check during match and not > attach. This will hopefully cause com to attach over isa as seen in your > old dmesg. So ok kettenis@ on that diff > diff --git sys/dev/acpi/com_acpi.c sys/dev/acpi/com_acpi.c > index 12e61288181..eeda6a82bef 100644 > --- sys/dev/acpi/com_acpi.c > +++ sys/dev/acpi/com_acpi.c > @@ -63,6 +63,8 @@ com_acpi_match(struct device *parent, void *match, void > *aux) > struct acpi_attach_args *aaa = aux; > struct cfdata *cf = match; > > + if (aaa->aaa_naddr < 1 || aaa->aaa_nirq < 1) > + return 0; > return acpi_matchhids(aaa, com_hids, cf->cf_driver->cd_name); > } > > @@ -77,16 +79,6 @@ com_acpi_attach(struct device *parent, struct device > *self, void *aux) > sc->sc_node = aaa->aaa_node; > printf(" %s", sc->sc_node->name); > > - if (aaa->aaa_naddr < 1) { > - printf(": no registers\n"); > - return; > - } > - > - if (aaa->aaa_nirq < 1) { > - printf(": no interrupt\n"); > - return; > - } > - > printf(" addr 0x%llx/0x%llx", aaa->aaa_addr[0], aaa->aaa_size[0]); > printf(" irq %d", aaa->aaa_irq[0]); > > >
Re: Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
On Mon, Dec 20, 2021 at 11:14:49AM -0700, Theo de Raadt wrote: > Mark Kettenis wrote: > > > > Date: Mon, 20 Dec 2021 15:10:42 +0100 > > > From: Anton Lindqvist > > > > > > On Mon, Dec 20, 2021 at 01:19:54PM +, 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(0xfd807eaa7220, 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,8000fffeed20) at comopen+0x710 > > > > spec_open(800042489638) at spec_open+0xd6 > > > > VOP_OPEN(fd806e86f568,5,fd807ee7af00,8000fffeed20) at > > > > VOP_OPEN+0x53 > > > > vn_open(800042489850,5,0) at vn_open+0x271 > > > > doopenat(8000fffeed20,ff9c,7f7e2bd0,4,0,800042489a20) > > > > at doopenat+0x1cd > > > > syscall(800042489a90) at syscall+0x374 > > > > Xsyscall() at Xsyscall+0x128 > > > > end of kernel > > > > end trace frame: 0x7f7e2bc0, 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(0xfd807eaa5770, 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,8000fffeed20) at comopen+0x710 spec_open(8000424895d8) at spec_open+0xd6 VOP_OPEN(fd806e9e5e30,5,fd807ee7aea0,8000fffeed20) at VOP_OPEN+0x53 vn_open(8000424897f0,5,0) at vn_open+0x271 doopenat(8000fffeed20, ff9c,7f7c9c00,4,0,8000424899c0) at doopenat+0x1cd syscall(800042489a30) at syscall+0x374 Xsyscall() at Xsyscall+0x128 end of kernel end trace frame: 0x7f7c9bf0, count: 8 It is true, every 5 months or so a snapshot update takes it out. I posted to openbsd-bugs in the past. Thank you for the help. I know the OpenBSD approach is to cut back rather than overstretch (e.g. tmpfs), so if you want to drop support I can understand. For comparison, the board does not boot whatsoever with Linux kernel above 4.9, but has always booted with FreeBSD including 13.0
Re: Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
On Wed, Dec 22, 2021 at 02:02:43PM +, cipher-hea...@riseup.net wrote: > On Mon, Dec 20, 2021 at 11:14:49AM -0700, Theo de Raadt wrote: > > Mark Kettenis wrote: > > > > > > Date: Mon, 20 Dec 2021 15:10:42 +0100 > > > > From: Anton Lindqvist > > > > > > > > On Mon, Dec 20, 2021 at 01:19:54PM +, 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(0xfd807eaa7220, 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,8000fffeed20) at comopen+0x710 > > > > > spec_open(800042489638) at spec_open+0xd6 > > > > > VOP_OPEN(fd806e86f568,5,fd807ee7af00,8000fffeed20) at > > > > > VOP_OPEN+0x53 > > > > > vn_open(800042489850,5,0) at vn_open+0x271 > > > > > doopenat(8000fffeed20,ff9c,7f7e2bd0,4,0,800042489a20) > > > > > at doopenat+0x1cd > > > > > syscall(800042489a90) at syscall+0x374 > > > > > Xsyscall() at Xsyscall+0x128 > > > > > end of kernel > > > > > end trace frame: 0x7f7e2bc0, 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(0xfd807eaa5770, 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,8000fffeed20) at comopen+0x710 > spec_open(8000424895d8) at spec_open+0xd6 > VOP_OPEN(fd806e9e5e30,5,fd807ee7aea0,8000fffeed20) at > VOP_OPEN+0x53 > vn_open(8000424897f0,5,0) at vn_open+0x271 > doopenat(8000fffeed20, ff9c,7f7c9c00,4,0,8000424899c0) at > doopenat+0x1cd > syscall(800042489a30) at syscall+0x374 > Xsyscall() at Xsyscall+0x128 > end of kernel > end trace frame: 0x7f7c9bf0, count: 8 Can you see any '^com*' attachment lines being printed before the panic?
Re: Latest snapshot does not boot on Libreboot D945GCLF2 (only board with both open-source BIOS and no Spectre bugs)
> > OK I tried the latest snapshot, here is the new (same) error message: > > > > uvm_fault(0xfd807eaa5770, 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,8000fffeed20) at comopen+0x710 > > spec_open(8000424895d8) at spec_open+0xd6 > > VOP_OPEN(fd806e9e5e30,5,fd807ee7aea0,8000fffeed20) at > > VOP_OPEN+0x53 > > vn_open(8000424897f0,5,0) at vn_open+0x271 > > doopenat(8000fffeed20, ff9c,7f7c9c00,4,0,8000424899c0) at > > doopenat+0x1cd > > syscall(800042489a30) at syscall+0x374 > > Xsyscall() at Xsyscall+0x128 > > end of kernel > > end trace frame: 0x7f7c9bf0, count: 8 > > Can you see any '^com*' attachment lines being printed before the panic? > I did a snapshot upgrade 30th December and it booted. Before trying an update, I did have a hunt through (pretty sure all) the boot messages using photos, but there was no trace of ^com* it seemed. And it did boot into bsd.rd OK, so I was starting to doubt if it was the serial port? Like, maybe I am the only one doing uappnd /etc/firmware/intel, for example?