Hello!
I've recently "rediscovered" a computer that I'd been using as a
Linux fileserver a few years ago. Since it's hardware is
considerably better than the even older machine I'm using now as
an OpenBSD fileserver, I tried if I could make it run.
In principle, everything works fine, to some extent much smoother
than on Linux (especially getting the sensors to work back then
was a true nightmare, and I eventually gave up in defeat -- on
OpenBSD, they just work).
However, if I do `shutdown -h -p` (thus power off), I get a
kernel panic; specifically, "AML PARSE ERROR" (see below). This
only happens when doing '-p' is involved somehow; rebooting
works, and just '-h' without '-p' does, too.
I've done some research, and it turns out that the motherboard
seems to a particularly buggy ACPI tables. And just as well, if I
disable ACPI, the kernel panic vanishes. However, the machine
doesn't get turned off as well, so it's not really a victory.
All this was done using 4.6 release, as this was a few months
ago.
Before I do any further research or experiments with that
machine, I just wanted to ask if I'd have any chances to work
against this problems. As far as I understood from some ancient
NetBSD mailinglist threads, in theory it should be possible
to somehow do something such that the kernel loads patched ACPI
tables which have those particular bugs corrected. So, if this
would be possible on OpenBSD, I knew that I should spend some
more time on this, without it being wasted.
The motherboard in question is a Tyan Tiger S2466 dual-Athon
multiprocessor board, with both processor sockets filled. As
already said, not the most recent of mainboard imaginable, so I
don't think that trying 4.7 would be much difference, especially
as it seems that the bug is in the BIOS, not in OpenBSD.
If anyone has a pointer---a "no, it won't work" would be more
than helpful, too---, I'd be grateful. If I could get that thing
to work again, my poor student's budget would be saved yet
another expense. ;o)
Regards,
Stefan
Here is the kernel panic that I've recorded from the machine.
Unfortunately, I've lost the dmesg that I thought I had prepared;
if there _is_ a chance to make this work, I'll post it as soon as
I again have some floor space to set it up again.
| syscing disks... done
| ### AML PARSE ERROR (0x455): Undefined name: IO2B
| multiply freed item 0xd1d62b00
| panic: free: duplicated free
| Stopped at Debugger+0x4: leave
|
| ddb{0}> trace
| Debugger(d0825e18,8,dc247d60,d1d62b00,21) at Debugger+0x4
| panic(d0717761,d1d62b00,dc247de0,d06ce12b,40) at panic+0x55
| free(d1d62b00,21,3f9,0) at free+0x40
| aml_freevalue(d1d62c44,d0817227,75d) at aml_freevalue+0xdb
| aml_xpopscope(d1d62c44,54,d0817578,d1c06504,dc247eac) at aml_xpopscope+0x81
| aml_xeval(0,d1c06504,74,1,dc247e78,dc247e72,dc247e90,d04c8555) at
aml_xeval+0x13f
| aml_evalnode(d1bfec00,d1c06544,1,dc247e78,0,1,dc247ea0,d06c90c7) at
aml_evalnode+0x57
| acpi_prepare_sleep_state(d1bfec00,5,dc247f00,d04ab607) at
acpi_prepare_sleep_state+0xfa
| acpi_powerdown(d0944b60,d6a62420,dc247f20,d035f7f8,1008) at
acpi_powerdown+0x22
| boot(1009,0,0,0,d0824a34) at boot+0x190
| __stack_smash_handler(d6a62420,dc247f68,dc247f58,d6a62420) at
__stack_smash_handler
| syscall() at syscall+0x12b
| --- syscall (number 55) ---
| 0x1c000a59:
|
| ddb{0}> ps
| PID PPID PGRP UID S FLAGS WAIT COMMAND
| *11147 1 11147 0 7 0x42004000 halt
| 15 0 0 0 3 0x2100200 bored crypto
| 14 0 0 0 3 0x2100200 aiodoned aiodonec
| 13 0 0 0 3 0x2100200 syncer update
| 12 0 0 0 3 0x2100200 cleaner cleaner
| 11 0 0 0 3 0x100200 reaper reaper
| 10 0 0 0 3 0x2100200 pgdaemon pagedaemon
| 9 0 0 0 3 0x2100200 pftm pfpurge
| 8 0 0 0 3 0x2100200 usbtsk usbtask
| 7 0 0 0 3 0x2100200 usbevt usb0
| 6 0 0 0 3 0x2100200 acpi_idle acpi0
| 5 0 0 0 7 0x40100200 idle1
| 4 0 0 0 3 0x2100200 bored syswq
| 3 0 0 0 3 0x40100200 idle0
| 2 0 0 0 3 0x2100200 kmalloc kmthread
| 1 0 1 0 3 0x2004080 wait init
| 0 -1 0 0 3 0x2080200 scheduler swapper
