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]);
uvn_flush: obj=0xfffffd838db602e8, offset=0x0. error during pageout.
While watching a video under firefox, I experienced what appeared to be a halt of the system: the system no longer responded to keyboard/mouse (no keyboard led activity), or to the network. As I have a RPi connected to the serial port, I logged in there to find that it was logging a lot of uvn_flush output: uvn_flush: obj=0xfd838db602e8, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0x0, offset=0x0. error during pageout. uvn_flush: WARNING: changes to page may be lost! uvn_flush: obj=0xfd838db602e8, offset=0x1. error during pageout. uvn_flush: WARNING: changes to page may be lost! This then repeats for various offsets (skipping all the other output): uvn_flush: obj=0xfd838db602e8, offset=0x0. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x1. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x2. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x3. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x4. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x5. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x6. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x7. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x8. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x9. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0xa. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0xb. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0xc. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0xd. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0xe. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0xf. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x10. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x11. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x12. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x13. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x14. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x15. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x16. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x17. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x18. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x19. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x1a. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x1b. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x1c. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x1d. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x1e. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x1f. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x20. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x21. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x22. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x23. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x24. error during pageout. uvn_flush: obj=0xfd838db602e8, offset=0x25. error
Re: uvn_flush: obj=0xfffffd838db602e8, offset=0x0. error during pageout.
> Date: Mon, 20 Dec 2021 17:55:14 +0100 > From: Paul de Weerd > > While watching a video under firefox, I experienced what appeared to > be a halt of the system: the system no longer responded to > keyboard/mouse (no keyboard led activity), or to the network. As I > have a RPi connected to the serial port, I logged in there to find > that it was logging a lot of uvn_flush output: > > uvn_flush: obj=0xfd838db602e8, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0x0, offset=0x0. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > uvn_flush: obj=0xfd838db602e8, offset=0x1. error during pageout. > uvn_flush: WARNING: changes to page may be lost! > > This then repeats for various offsets (skipping all the other output): > > uvn_flush: obj=0xfd838db602e8, offset=0x0. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x1. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x2. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x3. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x4. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x5. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x6. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x7. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x8. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x9. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0xa. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0xb. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0xc. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0xd. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0xe. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0xf. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x10. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x11. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x12. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x13. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x14. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x15. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x16. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x17. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x18. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x19. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x1a. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x1b. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x1c. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x1d. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x1e. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x1f. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x20. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x21. error during pageout. > uvn_flush: obj=0xfd838db602e8, offset=0x22. error du
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: uvn_flush: obj=0xfffffd838db602e8, offset=0x0. error during pageout.
On Mon, Dec 20, 2021 at 06:05:51PM +0100, Mark Kettenis wrote: | > So the system didn't crash or panic, but it was spending all its time | > writing output to the console (at 9600 baud...). After a long pause, | > I was able to briefly interact with the system again (move mouse, | > toggle numlock, etc) and it happened again. Eventually, I managed to | > stop firefox, and the system's been stable ever since (I've started | > firefox again, but not watched more videos). | > | > I'll upgrade to a newer snap later today (and move to 115200 console | > speed), but wanted to share this now. | | Your disk is (almost) full. You're (obviously) right - it was /tmp (where firefox appears to have stored quite some data). In my case, /tmp is an MFS filesystem: mfs:66016 3.9G2.5G1.2G68%/tmp Thanks for the reply Mark, apologies for the noise. Paul -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
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]);
>
>
>
