On Tue, May 4, 2010 at 8:43 AM, Stefan Unterweger <[email protected]> wrote: > 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
