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]); > > >