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?
