On Tue, May 4, 2010 at 8:43 AM, Stefan Unterweger
<stefan+openbsd@aleturo.com> wrote:
quoted text > 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
>
>
Hi,
When you get it out again, we'll also need to see an acpidump output.
Thanks
--
Aaron Mason - Programmer, open source addict
I've taken my software vows - for beta or for worse
