Re: Kernel panic on shutdown -p -- ACPI problem?
* Stefan Unterweger on Tue, May 04, 2010 at 12:43:22AM +0200: > 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. > | syscing disks... done > | ### AML PARSE ERROR (0x455): Undefined name: IO2B > | multiply freed item 0xd1d62b00 > | panic: free: duplicated free > | Stopped at Debugger+0x4:leave I've done some additional tests (since I remembered that this particular mainboard _did_ power off correctly a few years ago, albeit it was running an ancient 2.4.something Linux at that time, and maybe not even ACPI, so this does not really count). I just installed NetBSD on the machine---I suppose it is close enough to OpenBSD to make for a meaningful comparison. Here, the poweroff works. Well, I still see some ACPI error messages from the kernel fly by, but they're gone much too fast, and then the machine powers off. I'll try if I can find the responsible piece of NetBSD that works around this mainboard quirk. Maybe there's hope that I'll get it to work in OpenBSD at last, I don't really want to run NetBSD on it. :o) Since I don't really have any experience at all with kernel hacking, especially not with black magic as ACPI, does anyone have a pointer where I should start looking? s//un
Re: Kernel panic on shutdown -p -- ACPI problem?
* Mike Larkin on Wed, May 05, 2010 at 09:04:06PM -0700:
> If you haven't sent an acpidump yet, send it over.
/*
RSD PTR: Checksum=20, OEMID=PTLTD, RsdtAddress=0x3fefcf28
*/
/*
RSDT: Length=44, Revision=1, Checksum=13,
OEMID=PTLTD, OEM Table ID= RSDT, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
*/
/*
Entries={ 0x3fefef2e, 0x3fefefa2 }
*/
/*
DSDT=0x3fefcf54
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0x802f, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x8000-0x8003
PM1a_CNT_BLK=0x8004-0x8005
PM2_TMR_BLK=0x8008-0x800b
PM2_GPE0_BLK=0x8020-0x8023
P_LVL2_LAT=101ms, P_LVL3_LAT=1001ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=0
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
Flags={WBINVD,PROC_C1}
*/
/*
DSDT: Length=8154, Revision=1, Checksum=247,
OEMID=AMD, OEM Table ID=AMDACPI, OEM Revision=0x604,
Creator ID=MSFT, Creator Revision=0x10d
*/
DefinitionBlock (
"acpi_dsdt.aml",//Output filename
"DSDT", //Signature
0x1,//DSDT Revision
"AMD", //OEMID
"AMDACPI", //TABLE ID
0x604 //OEM Revision
)
{
Scope(\_PR_) {
Processor(CPU0, 0, 0x8010, 0x6) {
}
Processor(CPU1, 1, 0x0, 0x0) {
}
}
Name(\_S0_, Package(0x4) {
0x0,
0x0,
0x0,
0x0,
})
Name(\_S1_, Package(0x4) {
0x1,
0x1,
0x1,
0x1,
})
Name(\_S4_, Package(0x4) {
0x6,
0x6,
0x6,
0x6,
})
Name(\_S5_, Package(0x4) {
0x7,
0x7,
0x7,
0x7,
})
Name(OSFL, 0x0)
Method(STRC, 2) {
If(LNot(LEqual(SizeOf(Arg0), SizeOf(Arg1 {
Return(0x0)
}
Add(SizeOf(Arg0), 0x1, Local0)
Name(BUF0, Buffer(Local0) { })
Name(BUF1, Buffer(Local0) { })
Store(Arg0, BUF0)
Store(Arg1, BUF1)
While(Local0) {
Decrement(Local0)
If(LNot(LEqual(DerefOf(Index(BUF0, Local0)), DerefOf(Index(BUF1,
Local0) {
Return(Zero)
}
}
Return(One)
}
OperationRegion(\DEBG, SystemIO, 0x80, 0x1)
Field(\DEBG, ByteAcc, NoLock, Preserve) {
DBG1, 8
}
OperationRegion(KBC_, SystemIO, 0x64, 0x1)
Field(KBC_, ByteAcc, NoLock, Preserve) {
KCMD, 8
}
OperationRegion(EXTM, SystemMemory, 0x000ff830, 0x10)
Field(EXTM, WordAcc, NoLock, Preserve) {
ROM1, 16,
RMS1, 16,
ROM2, 16,
RMS2, 16,
ROM3, 16,
RMS3, 16,
AMEM, 32
}
OperationRegion(VGAM, SystemMemory, 0x000c0002, 0x1)
Field(VGAM, ByteAcc, Lock, Preserve) {
VGA1, 8
}
OperationRegion(GRAM, SystemMemory, 0x0400, 0x0100)
Field(GRAM, ByteAcc, Lock, Preserve) {
Offset(0x10),
FLG0, 8
}
OperationRegion(ELCR, SystemIO, 0x04d0, 0x2)
Field(ELCR, ByteAcc, NoLock, Preserve) {
ELC1, 8,
ELC2, 8
}
OperationRegion(\PSC_, SystemIO, 0x8027, 0x1)
Field(\PSC_, ByteAcc, NoLock, Preserve) {
PSCC, 8
}
OperationRegion(\STUS, SystemIO, 0x8028, 0x1)
Field(\STUS, ByteAcc, NoLock, Preserve) {
G_ST, 8
}
OperationRegion(\STUB, SystemIO, 0x8029, 0x1)
Field(\STUB, ByteAcc, NoLock, Preserve) {
G_SB, 8
}
OperationRegion(\SMIC, SystemIO, 0x802f, 0x1)
Field(\SMIC, ByteAcc, NoLock, Preserve) {
SCP_, 8
}
OperationRegion(\OPS0, SystemIO, 0x21, 0x1)
Field(\OPS0, ByteAcc, NoLock, Preserve) {
IMR0, 8
}
OperationRegion(\OPS1, SystemIO, 0xa1, 0x1)
Field(\OPS1, ByteAcc, NoLock, Preserve) {
IMR1, 8
}
OperationRegion(\GSE_, SystemIO, 0x802a, 0x1)
Field(\GSE_, ByteAcc, NoLock, Preserve) {
IRQR, 8
}
OperationRegion(\FANC, SystemIO, 0x80f8, 0x2)
Field(\FANC, ByteAcc, NoLock, Preserve) {
FAN0, 8,
FAN1, 8
}
OperationRegion(\PM21, SystemIO, 0x8021, 0x1)
Field(\PM21, ByteAcc, NoLock, Preserve) {
IO21, 8
}
OperationRegion(\PM23, SystemIO, 0x8023, 0x1)
Field(\PM23, ByteAcc, NoLock, Preserve) {
IO23, 8
}
OperationRegion(\GP1_, SystemIO, 0x80c0, 0x20)
Field(\GP1_, ByteAcc, NoLock, Preserve) {
GP00, 8,
GP01, 8,
GP02, 8,
GP03, 8,
GP04, 8,
GP05, 8,
GP06, 8,
GP07, 8,
GP08, 8,
GP09, 8,
GP10, 8,
GP11, 8,
GP12, 8,
GP13, 8,
GP14, 8,
GP15, 8,
GP16, 8,
GP17, 8,
GP18, 8,
GP19, 8,
GP20, 8,
GP21, 8,
GP22, 8,
GP23, 8,
GP24, 8,
GP25, 8,
GP26, 8,
GP27, 8,
GP28, 8,
GP29, 8,
GP30, 8,
GP31, 8
}
Name(PICF, 0x0)
Method(_PIC, 1) {
Store(Arg0, PICF)
}
Scope(\) {
Method(DISD, 1) {
Store(Local0, Local0)
}
Method(CKIO, 2) {
Store(Local0, Local0)
}
Method(SLDM, 2) {
Store(Local0, Local0)
}
}
Scope(_GPE) {
Method(_L08) {
N
Re: Kernel panic on shutdown -p -- ACPI problem?
* Jan Stary on Tue, May 04, 2010 at 08:31:10AM +0200: > > 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. > Have you also tried with current? The download went surprisingly fast (and the install even moreso; big thanks at this point for the folks who did the installer, it seems rare that one can install an operating system in five minutes). Running the April 28 snapshot which I just grabbed from FTP this instant doesn't change a thing---as expected, I get the same "AML PARSE ERROR" kernel panic. Here's a pseudo-diff from the previous dmesg to the 4.7-current one, other than the vscsi stuff nothing changes: -8<-8<-8<-8<-8<-8<-8<-8<- -OpenBSD 4.6 (GENERIC.MP) #89: Thu Jul 9 21:32:39 MDT 2009 +OpenBSD 4.7-current (GENERIC.MP) #560: Wed Apr 28 11:55:01 MDT 2010 -avail mem = 1027940352 (980MB) +avail mem = 1028833280 (981MB) +vscsi0 at root +scsibus1 at vscsi0: 256 targets ->8->8->8->8->8->8->8->8- acpidump(8) gives exactly the same result (well, as expected; the ACPI tables didn't change, after all...). s//un
Re: Kernel panic on shutdown -p -- ACPI problem?
* Aaron Mason on Tue, May 04, 2010 at 08:48:05PM +1000:
> When you get it out again, we'll also need to see an acpidump output.
Here is the output of both acpidump(8) and dmesg(8).
s//un
-8<-8<-8<-8<-8<-8<-8<-8<-
/*
RSD PTR: Checksum=20, OEMID=PTLTD, RsdtAddress=0x3fefcf28
*/
/*
RSDT: Length=44, Revision=1, Checksum=13,
OEMID=PTLTD, OEM Table ID= RSDT, OEM Revision=0x604,
Creator ID= LTP, Creator Revision=0x0
*/
/*
Entries={ 0x3fefef2e, 0x3fefefa2 }
*/
/*
DSDT=0x3fefcf54
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0x802f, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x8000-0x8003
PM1a_CNT_BLK=0x8004-0x8005
PM2_TMR_BLK=0x8008-0x800b
PM2_GPE0_BLK=0x8020-0x8023
P_LVL2_LAT=101ms, P_LVL3_LAT=1001ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=0
DAY_ALRM=13, MON_ALRM=0, CENTURY=50
Flags={WBINVD,PROC_C1}
*/
/*
DSDT: Length=8154, Revision=1, Checksum=247,
OEMID=AMD, OEM Table ID=AMDACPI, OEM Revision=0x604,
Creator ID=MSFT, Creator Revision=0x10d
*/
DefinitionBlock (
"acpi_dsdt.aml",//Output filename
"DSDT", //Signature
0x1,//DSDT Revision
"AMD", //OEMID
"AMDACPI", //TABLE ID
0x604 //OEM Revision
)
{
Scope(\_PR_) {
Processor(CPU0, 0, 0x8010, 0x6) {
}
Processor(CPU1, 1, 0x0, 0x0) {
}
}
Name(\_S0_, Package(0x4) {
0x0,
0x0,
0x0,
0x0,
})
Name(\_S1_, Package(0x4) {
0x1,
0x1,
0x1,
0x1,
})
Name(\_S4_, Package(0x4) {
0x6,
0x6,
0x6,
0x6,
})
Name(\_S5_, Package(0x4) {
0x7,
0x7,
0x7,
0x7,
})
Name(OSFL, 0x0)
Method(STRC, 2) {
If(LNot(LEqual(SizeOf(Arg0), SizeOf(Arg1 {
Return(0x0)
}
Add(SizeOf(Arg0), 0x1, Local0)
Name(BUF0, Buffer(Local0) { })
Name(BUF1, Buffer(Local0) { })
Store(Arg0, BUF0)
Store(Arg1, BUF1)
While(Local0) {
Decrement(Local0)
If(LNot(LEqual(DerefOf(Index(BUF0, Local0)), DerefOf(Index(BUF1,
Local0) {
Return(Zero)
}
}
Return(One)
}
OperationRegion(\DEBG, SystemIO, 0x80, 0x1)
Field(\DEBG, ByteAcc, NoLock, Preserve) {
DBG1, 8
}
OperationRegion(KBC_, SystemIO, 0x64, 0x1)
Field(KBC_, ByteAcc, NoLock, Preserve) {
KCMD, 8
}
OperationRegion(EXTM, SystemMemory, 0x000ff830, 0x10)
Field(EXTM, WordAcc, NoLock, Preserve) {
ROM1, 16,
RMS1, 16,
ROM2, 16,
RMS2, 16,
ROM3, 16,
RMS3, 16,
AMEM, 32
}
OperationRegion(VGAM, SystemMemory, 0x000c0002, 0x1)
Field(VGAM, ByteAcc, Lock, Preserve) {
VGA1, 8
}
OperationRegion(GRAM, SystemMemory, 0x0400, 0x0100)
Field(GRAM, ByteAcc, Lock, Preserve) {
Offset(0x10),
FLG0, 8
}
OperationRegion(ELCR, SystemIO, 0x04d0, 0x2)
Field(ELCR, ByteAcc, NoLock, Preserve) {
ELC1, 8,
ELC2, 8
}
OperationRegion(\PSC_, SystemIO, 0x8027, 0x1)
Field(\PSC_, ByteAcc, NoLock, Preserve) {
PSCC, 8
}
OperationRegion(\STUS, SystemIO, 0x8028, 0x1)
Field(\STUS, ByteAcc, NoLock, Preserve) {
G_ST, 8
}
OperationRegion(\STUB, SystemIO, 0x8029, 0x1)
Field(\STUB, ByteAcc, NoLock, Preserve) {
G_SB, 8
}
OperationRegion(\SMIC, SystemIO, 0x802f, 0x1)
Field(\SMIC, ByteAcc, NoLock, Preserve) {
SCP_, 8
}
OperationRegion(\OPS0, SystemIO, 0x21, 0x1)
Field(\OPS0, ByteAcc, NoLock, Preserve) {
IMR0, 8
}
OperationRegion(\OPS1, SystemIO, 0xa1, 0x1)
Field(\OPS1, ByteAcc, NoLock, Preserve) {
IMR1, 8
}
OperationRegion(\GSE_, SystemIO, 0x802a, 0x1)
Field(\GSE_, ByteAcc, NoLock, Preserve) {
IRQR, 8
}
OperationRegion(\FANC, SystemIO, 0x80f8, 0x2)
Field(\FANC, ByteAcc, NoLock, Preserve) {
FAN0, 8,
FAN1, 8
}
OperationRegion(\PM21, SystemIO, 0x8021, 0x1)
Field(\PM21, ByteAcc, NoLock, Preserve) {
IO21, 8
}
OperationRegion(\PM23, SystemIO, 0x8023, 0x1)
Field(\PM23, ByteAcc, NoLock, Preserve) {
IO23, 8
}
OperationRegion(\GP1_, SystemIO, 0x80c0, 0x20)
Field(\GP1_, ByteAcc, NoLock, Preserve) {
GP00, 8,
GP01, 8,
GP02, 8,
GP03, 8,
GP04, 8,
GP05, 8,
GP06, 8,
GP07, 8,
GP08, 8,
GP09, 8,
GP10, 8,
GP11, 8,
GP12, 8,
GP13, 8,
GP14, 8,
GP15, 8,
GP16, 8,
GP17, 8,
GP18, 8,
GP19, 8,
GP20, 8,
GP21, 8,
GP22, 8,
GP23, 8,
GP24, 8,
GP25, 8,
GP26, 8,
GP27, 8,
GP28, 8,
GP29, 8,
GP30, 8,
GP31, 8
}
Name(PICF, 0x0)
Method(_PIC, 1) {
Store(Arg0, PICF)
}
Scope(\) {
Method(DISD, 1) {
Store(Local0, Local0)
}
Method(CKIO,
Re: Kernel panic on shutdown -p -- ACPI problem?
On Tue, May 4, 2010 at 8:43 AM, Stefan Unterweger
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
> | PIDPPID PGRP UID S FLAGS WAITCOMMAND
> | *11147 111147 0 7 0x42004000 halt
> | 15 00 0 3 0x2100200 bored crypto
> | 14 00 0 3 0x2100200 aiodonedaiodonec
> | 13 00 0 3 0x2100200 syncer update
> | 12 00 0 3 0x2100200 cleaner cleaner
> | 11 00 0 3 0x100200reaper reaper
> | 10 00 0 3 0x2100200 pgdaemonpagedaemon
> | 9 00 0 3 0x2100200 pftmpfpurge
> | 8 00 0 3 0x2100200 usbtsk usbtask
> | 7 00 0 3 0x2100200 usbevt usb0
> | 6 00 0 3 0x2100200 acpi_idle acpi0
> | 5 00 0 7 0x40100200 idle1
> | 4 00 0 3 0x2100200 bored syswq
> | 3 00 0 3 0x40100200 idle0
> | 2 00 0 3 0x2100200 kmalloc kmthread
> | 1 01 0 3 0x2004080 waitinit
> | 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
