On Mon, Dec 20, 2021 at 11:14:49AM -0700, Theo de Raadt wrote:
> Mark Kettenis <mark.kette...@xs4all.nl> wrote:
>
> > > Date: Mon, 20 Dec 2021 15:10:42 +0100
> > > From: Anton Lindqvist <an...@basename.se>
> > >
> > > On Mon, Dec 20, 2021 at 01:19:54PM +0000, cipher-hea...@riseup.net wrote:
> > > > I booted into bsd.rd to grep in /var/log/messages when I last ran
> > > > sysupgrade:
> > > >
> > > > Dec 19 22:11:48 0 sysupgrade: installed new /bsd.upgrade. Old kernel
> > > > version: OpenBSD 7.0-current (GENERIC.MP) #135: Tue Nov 30 17:39:34 MST
> > > > 2021
> > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > > Dec 1 20:17:52 0 sysupgrade: installed new /bsd.upgrade. Old kernel
> > > > version: OpenBSD 7.0-current (GENERIC.MP) #106: Fri Nov 19 10:43:11 MST
> > > > 2021
> > > > dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
> > > >
> > > > Below is the error message at boot, typed manually, and double-checked
> > > > (omitted the file system checks before wd0e which were all clean, and
> > > > the
> > > > generic instructions after 'dbb.html describes')
> > > >
> > > > --------------------------------------------------------------------------------
> > > >
> > > > dev/wd0e (afcec7a171c4b011.e): file system is clean; not checking
> > > > uvm_fault(0xfffffd807eaa7220, 0x0, 0, 1) -> e
> > > > kernel: page fault trap, code=0
> > > > Stopped at comopen+0x710: movq 0(%rax),%r11
> > > > TID PID UID PRFLAGS PFLAGS CPU COMMAND
> > > > *189345 37957 0 0x3 0 2K ttyflags
> > > > comopen(800,5,2000,ffff8000fffeed20) at comopen+0x710
> > > > spec_open(ffff800042489638) at spec_open+0xd6
> > > > VOP_OPEN(fffffd806e86f568,5,fffffd807ee7af00,ffff8000fffeed20) at
> > > > VOP_OPEN+0x53
> > > > vn_open(ffff800042489850,5,0) at vn_open+0x271
> > > > doopenat(ffff8000fffeed20,ffffff9c,7f7ffffe2bd0,4,0,ffff800042489a20)
> > > > at doopenat+0x1cd
> > > > syscall(ffff800042489a90) at syscall+0x374
> > > > Xsyscall() at Xsyscall+0x128
> > > > end of kernel
> > > > end trace frame: 0x7f7ffffe2bc0, count: 8
> > > > https://www.openbsd.org/dbb.html describes...
> > > > ...
> > > > ddb{2}>
> > >
> > > Probably caused by the recent change to attach com over acpi. Looking at
> > > your disassembled acpi tables, I see two com devices which lacks a
> > > corresponding _PRS node:
> > >
> > >
> > > Device (UAR1)
> > > {
> > > Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM Serial
> > > Port */) // _HID: Hardware ID
> > > Name (_UID, One) // _UID: Unique ID
> > > }
> > > Device (UAR2)
> > > {
> > > Name (_HID, EisaId ("PNP0501") /* 16550A-compatible COM Serial
> > > Port */) // _HID: Hardware ID
> > > Name (_UID, 0x02) // _UID: Unique ID
> > > }
> >
> > Look at the comments in:
> >
> > https://github.com/coreboot/coreboot/blob/master/src/mainboard/intel/d945gclf/acpi/superio.asl
> >
> > What a joke!
>
> Sadly I have to agree:
>
> coreboot is a joke.
>
> This is not the first time coreboot didn't get around to doing something
> correctly, which is a defect. This results in coreboot-users demanding
> that operating systems work around the defect. Thus operating systems
> have to carry more and more workarounds for defects. Forever, right?
>
> > Maybe. But we should also protect the com(4) driver against
> > "partially attached" driver instances I think.
>
> For around half the life of OpenBSD, I have argued Chris Torek made a
> design mistake --- *attach() functions should have returned "int" not
> "void", so that subr_autoconf.c can avoid establishing some callpaths to
> the driver.
--------------------------------------------------------------------------------
OK I tried the latest snapshot, here is the new (same) error message:
uvm_fault(0xfffffd807eaa5770, 0x0, 0, 1) -> e
kernel: page fault trap, code=0
Stopped at
TID PID UID PRFLAGS PFLAGS CPU COMMAND
*400263 16138 0 0x3 0 2K ttyflags
comopen(800,5,2000,ffff8000fffeed20) at comopen+0x710
spec_open(ffff8000424895d8) at spec_open+0xd6
VOP_OPEN(fffffd806e9e5e30,5,fffffd807ee7aea0,ffff8000fffeed20) at VOP_OPEN+0x53
vn_open(ffff8000424897f0,5,0) at vn_open+0x271
doopenat(ffff8000fffeed20, ffffff9c,7f7ffffc9c00,4,0,ffff8000424899c0) at
doopenat+0x1cd
syscall(ffff800042489a30) at syscall+0x374
Xsyscall() at Xsyscall+0x128
end of kernel
end trace frame: 0x7f7ffffc9bf0, count: 8
--------------------------------------------------------------------------------
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 (text only).
Though OpenBSD X11 on this board has improved since I started using it, as it
stopped crashing when switching from console to graphics, and hotplug USB now
works.
Have tried to compile newer versions of Coreboot for it a few times, but they
never boot, whereas other boards have booted on first config/compile.
Ironically I haven't ever managed to get serial port to work on this board
(tried when Coreboot compilations were not booting)!
In case it makes a difference: I blocked Intel firmware updates via uchg. Pretty
sure I tested RAM with memtest before installing (over a year ago).
No Spectre bugs as the processor does no speculative execution. Performance is
on par with Raspberry Pi 3 but with OpenBSD graphics support (and x86-grade
energy inefficiency), and must have different microcode bugs. Can compile a
minimalist kernel in half an hour. Makes you realise how overrated
speculative execution is, until you try graphical consumer software, which has
become very dependent on it.
Just wonder, since the insight about serial ports is new to me, if there a
config file I can edit, to just ignore initialising all ports at boot, except
USB? Even power buttons can go.
I'm kind of holding out on old x86 until architectures shift some more
(worldwide). Then there is the option to go back to Intel BIOS, though having
flashed BIOS a few times, it is difficult to ever trust it with a disk
encryption password anymore! There is really alot of space on a BIOS chip, easy
to see how the newest BIOS chips contain a full filesystem, OS. Maybe time to
rethink of a different approach.
