Bug 14679

Summary: Namespace lookup failure, AE_NOT_FOUND - ACPI table overridden after boot? - Toshiba Satellite L505D-S5983
Product: ACPI Reporter: Mike Smith (scgtrp)
Component: ACPICA-CoreAssignee: Lin Ming (ming.m.lin)
Severity: normal CC: achiang, acpi-bugzilla, devinsmith, hancockrwd, joe, krellan, lenb, mike.allen, ming.m.lin, mjg59-kernel, otto, riglersc, rjw, Robert.Moore, rui.zhang
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.31 Tree: Mainline
Regression: No
Attachments: dmesg >dmesg.txt, from a boot with acpi=noirq
acpidump output
dmesg from boot with acpi_osi="Windows 2006"
dmesg output with acpi=rsdt
custom dsdt
dmesg with overridden DSDT
custom dsdt of DSDT.MSFT
test patch to copy DSDT for safe
dmesg with patch applied
DSDT from iasl -g
debug patch
dmesg with debug patch
debug patch
dmesg with debug patch
debug patch
DSDT checking patch, v2
dmesg with acpi_osi="!Windows 2006"
dmesg with acpi_osi="!Windows 2006 SP1"
dmesg stack tace
sudo dmidecode >dmidecode.txt
dmidecode from A505-S6033
add kernel boot option acpi=copy_dsdt
Further debug patch
dmesg for Linux 2.6.34
dmidecode for Toshiba L505D-LS5005
Output of `dmidecode -u` on a Toshiba Satellite C655D-S5048
DMI patch for Toshiba Satellite C655D-S5048
DMI for all Toshiba Satellite
Toshiba L645-SP4130L dmesg

Description Mike Smith 2009-11-24 00:43:23 UTC
Created attachment 23899 [details]
dmesg >dmesg.txt, from a boot with acpi=noirq

I have a brand new Satellite L505D-S5983 which I'm trying to install
Linux on. Whenever I boot a Linux kernel on it with no special
parameters it enters an in(de)finite loop dumping messages like this:

ACPI Error (uteval-0313): Return object type is incorrect
[\_SB_.HSB1._STA] (Node ffff8800af8121a0), AE_TYPE
ACPI Error: Type returned from _STA was incorrect: Device, expected
Btypes: 1 20090521 uteval-319
ACPI Error (psargs-0359): [DR ] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.VALZ._STA] (Node ffff8800af812540), AE_NOT_FOUND
ACPI Error: Found unknown opcode 39 at AML address ffffc900000132cd
offset 0, ignoring 20090521 psloop-137

If I boot with acpi=noirq these messages only continue for a few
seconds, although they cause a couple of initscripts to hang later on.
With ACPI fully enabled they keep appearing forever and the system
doesn't finish booting. With acpi=off they don't appear at all (but
the fan stays at low speed and the laptop gets quite hot if run for
more than a few minutes).

I've found only one other mention of this problem on the internet
(http://ubuntuforums.org/showthread.php?p=8358864#post8358864) from
someone with the same laptop as mine, but there was no working fix
posted to that thread beyond completely disabling ACPI. More research
told me that there used to be a way of fixing up the DSDT and having
it loaded from the initrd but the new policy is to just ask the
manufacturer to fix it and the kernel developers to work around it,
so... here it is. (Angry emails to Toshiba and Best Buy pending.)

Full dmesg output is attached.
Comment 1 Zhang Rui 2009-11-24 01:28:39 UTC
please attach the acpidump output of this laptop.
Comment 2 Mike Smith 2009-11-24 01:49:55 UTC
Created attachment 23900 [details]
acpidump output

As requested.
Comment 3 Len Brown 2009-11-24 03:31:03 UTC
Is this a production level BIOS?

I'd first guess that we are loading the wrong tables or something,
but the XSDT and RSDT appear the same, so acpi=rsdt isn't going to help:-(

> ACPI: BIOS _OSI(Linux) query ignored

I am baffled by this line, for there is no invocation of _OSI(Linux)
in the DSDT, the SSDT, and there are no table Load operations....

Do does any joy follow from booting with "acpi_osi=Linux"?
If yes, I can't explain it, as the acpidump output says it
should be a no-op, yet dmesg says that AML is asking...
Comment 4 Len Brown 2009-11-24 03:35:15 UTC
BTW. "acpi=ht" may be a more useful workaround than "acpi=noirq",
as it will allow you to probe out both cores, but will otherwise disable acpi.
Comment 5 Mike Smith 2009-11-24 03:42:41 UTC
@#3: Not sure what you mean by "production level". It was in a computer I bought from a store, so it's not something I'm beta testing (at least not on purpose) for Toshiba or anything. I did disassemble my DSDT for fun and noticed some calls to _OSI but they were referencing "Windows 2001" (XP?) and "Windows 2006" (Vista?), not Linux. I'll try acpi_osi=Linux and let you know what happens.

@#4: My main concern with getting ACPI to work is that Linux seems to constantly run the fans at low speed, so it gets rather hot and I wind up shutting down after 5-10 minutes in fear of damaging the hardware or something. (Also, a battery meter would be nice.)
Comment 6 Mike Smith 2009-11-24 03:50:14 UTC
Just tried acpi_osi=Linux. It had the same effect as acpi=noirq - interesting.

Slightly more interesting is that I tried acpi_osi="Windows 2006" and made it to executing things from the initramfs (at which point the initramfs failed to parse that due to the space and caused a kernel panic). Out of curiosity what does Linux use for acpi_osi by default?
Comment 7 Robert Hancock 2009-11-24 03:53:16 UTC
I assume that dump is with the same BIOS version as the dmesg output was seen with? The dmesg output shows a DSDT length of 0B13C (45372) while the decompiled output shows a length of 0583A (22586). Also the decompiled output doesn't seem to show any of the errors the kernel is complaining about. Even the AML compiler listed is different (kernel shows MSFT and acpidump shows INTL).

Could this machine have two DSDT tables concatenated into one or something, one broken and one working? It seems really bizarre.
Comment 8 Robert Hancock 2009-11-24 03:56:46 UTC
Hmm. Mike, can you do:

cat /proc/acpi/dsdt > dsdt.bin

and attach the resulting dsdt.bin file? That will let us get a look at the kernel's view of the DSDT.
Comment 9 Mike Smith 2009-11-24 04:03:50 UTC
The dump and dmesg output are from exactly the same computer, everything was the same except they were collected on two different boots of the same kernel.
Comment 10 Mike Smith 2009-11-24 04:09:30 UTC
Created attachment 23907 [details]

Probably relevant: when copying this file I got two RSDT checksum errors on the console.
Comment 11 Robert Hancock 2009-11-24 04:29:13 UTC
What were those errors exactly?

Also, can you make sure that from the same bootup, the DSDT line in dmesg on bootup is the same as what you posted, and you get the same output from /proc/acpi/dsdt as you posted?
Comment 12 Mike Smith 2009-11-24 04:42:03 UTC
ACPI Warning: Incorrect checksum in table [DSDT] - 98, should be 3A 20090521 tbutils-246
ACPI Warning: Incorrect checksum in table [DSDT] - 98, should be 3A 20090521 tbutils-246

Checked on the same boot:
ACPI: DSDT 00000000afee6000 0B13C (v01 TOSINV TOSINV00 F0000000 MSFT 01000013)
cmp'ing /proc/acpi/dsdt with the copy I made previously returned 0 but spewed a screenful of the same checksum errors.
Comment 13 Mike Smith 2009-11-24 22:33:44 UTC
I found a workaround for the Arch /proc/cmdline parsing bug, and can confirm that passing acpi_osi="Windows 2006" gives the same result as acpi_osi=Linux or acpi=noirq (some errors and hanging initscripts, but capable of booting with some well timed ^C'ing and setting things up manually later).
Comment 14 Robert Hancock 2009-11-24 23:18:40 UTC
Can you post the dmesg output from such a bootup? Do you still see all those ACPI exceptions?
Comment 15 Mike Smith 2009-11-24 23:22:56 UTC
I do see the ACPI exceptions, those were the "errors" I referred to. dmesg output coming up.
Comment 16 Mike Smith 2009-11-24 23:37:02 UTC
Created attachment 23924 [details]
dmesg from boot with acpi_osi="Windows 2006"

Also realized this time that I could scroll in the terminal with shift+page up/page down. The hanging initscript is just "Loading standard ACPI modules" which just appears to be "for m in ac battery button fan processor thermal; do modprobe $m; done".
Comment 17 Mike Smith 2009-11-25 01:18:30 UTC
The complete hangs seem to have been an unrelated issue with the radeon module. Passing nomodeset seems to fix that.

Current status: acpi_osi=Linux, acpi_osi="Windows 2006", acpi_osi=asdfasdf, and no acpi_osi option at all have the same effect (shown in the dmesg above). acpi=noirq still makes no difference.
Comment 18 Robert Hancock 2009-11-25 01:26:05 UTC
It looks like in the dmesg output you posted, the ACPI video driver oopsed during module loading. It's presumably a bug that should be fixed but given the garbage the ACPI interpreter is getting it doesn't seem to surprising.

The differing DSDT sizes and headers are still rather mysterious. You can try booting with acpi=rsdt and see if that makes any difference, though the RSDT and XSDT do look equivalent to me.

I wonder if the BIOS could be editing or swapping out the DSDT somehow between the point where the ACPI tables are read during boot and when acpidump is later run.. that's quite bizarre, but so are the symptoms..
Comment 19 Mike Smith 2009-11-25 01:55:47 UTC
Created attachment 23925 [details]
dmesg output with acpi=rsdt

No useful changes from acpi=rsdt; dmesg attached.

Amusingly, it seems like Toshiba was involved in writing the ACPI spec. How embarassing...
Comment 20 Lin Ming 2009-11-25 05:52:26 UTC
Created attachment 23928 [details]
custom dsdt

Hi, Mike

This bug is really interesting.
Could you help to do below 2 things?

1. acpidump --addr 0xafee6000  --length 0xB13C > DSDT_reported_by_kernel
   dmesg shows,
   ACPI: DSDT 00000000afee6000 0B13C (v01 TOSINV TOSINV00 F0000000 MSFT 01000013)

   So this should dump the real DSDT that kernel reports.

2. Try the attached custom DSDT (DSDT.hex)
   See below link for how to use custom DSDT, you can just start from step 5

   This custom DSDT comes from your original acpidump at comment #2.
Comment 21 Lin Ming 2009-11-25 06:17:45 UTC
Seems there are 2 different DSDTs, not sure which one is used by kernel.

Item 2 above forces kernel to use the DSDT dumpped in comment #2,
If it does not help, please use another DSDT (DSDT_reported_by_kernel).

iasl -tc DSDT_reported_by_kernel
this will gets DSDT_reported_by_kernel.hex, rename it to DSDT.hex,
Then you can try it.
Comment 22 Mike Smith 2009-11-25 17:30:44 UTC
Created attachment 23935 [details]

Waiting for new kernel to finish building. Until then, here's the other DSDT you asked for.
Comment 23 Len Brown 2009-11-25 18:15:31 UTC
DefinitionBlock ("DSDT.aml", "DSDT", 1, "TOSINV", "TOSINV00", 0x00000001)

The DSDT in comment #22 is the same as the DSDT that came in the
acpidump output in comment #2.

Lin Ming, while the system is clearly interpreting AML that is
not reflected in the acpidump, I don't understand your reference
to "2 different DSDTs", and where the "other one" is located.
Comment 24 Mike Smith 2009-11-25 19:41:28 UTC
It seems that there are indeed two DSDTs, if I'm interpreting this output right (dsdt2.aml == dsdt_reported_by_kernel, 0xB13C was the length of the (first) DSDT reported in dmesg):

[mike@laptop ~]$ hexdump -Cv dsdt2.aml -s 0xB13C |head -2
0000b13c  44 53 44 54 3a 58 00 00  01 98 54 4f 53 49 4e 56  |DSDT:X....TOSINV|
0000b14c  54 4f 53 49 4e 56 30 30  01 00 00 00 49 4e 54 4c  |TOSINV00....INTL|

Not sure what this means though, as I haven't read enough of the ACPI spec to know whether this is even legal (is it a SSDT?)
Comment 25 Mike Smith 2009-11-25 19:51:17 UTC
Err, disregard that. I appear to have found a bug in hexdump too (passing the length of the file to -s causes it to start dumping from the start of the file)
Comment 26 Mike Smith 2009-11-25 22:57:07 UTC
Created attachment 23939 [details]
dmesg with overridden DSDT

I'm currently running with my DSDT overridden by the one provided by Lin Ming. I was able to successfully boot without hald or modprobe hanging, but there are still a few ACPI errors.

My external USB mouse isn't working now but I'm not sure whether that's related (I was playing with my X config earlier).
Comment 27 Lin Ming 2009-11-26 02:03:23 UTC
(In reply to comment #24)
> It seems that there are indeed two DSDTs, if I'm interpreting this output
> right
> (dsdt2.aml == dsdt_reported_by_kernel, 0xB13C was the length of the (first)
> DSDT reported in dmesg):
> [mike@laptop ~]$ hexdump -Cv dsdt2.aml -s 0xB13C |head -2
> 0000b13c  44 53 44 54 3a 58 00 00  01 98 54 4f 53 49 4e 56 
> 0000b14c  54 4f 53 49 4e 56 30 30  01 00 00 00 49 4e 54 4c 
> |TOSINV00....INTL|
> Not sure what this means though, as I haven't read enough of the ACPI spec to
> know whether this is even legal (is it a SSDT?)

Did you run "acpidump --addr 0xafee6000  --length 0xB13C > DSDT_reported_by_kernel"?

If yes, please boot with acpi=off, then dump again

It's not the DSDT that dmesg shows
   ACPI: DSDT 00000000afee6000 0B13C (v01 TOSINV TOSINV00 F0000000 MSFT

It's same as the DSDT in comment #2.
Comment 28 Mike Smith 2009-11-26 05:43:23 UTC
> Did you run "acpidump --addr 0xafee6000  --length 0xB13C >
Yes, see comment #22.

dsdt2.aml was exactly the same file as dsdt_reported_by_kernel (I deleted my local copy of it and re-downloaded it from here, hence the different filename). That's actually a dump of the start of the file, despite the offsets (hexdump bug, see comment #25). The dump was just to show, erroneously, that there was more than one DSDT in that file.

> It's not the DSDT that dmesg shows
The DSDT override I used was the INTL one, not the MSFT one. I'm not completely sure what you're asking me to do; do you want me to dump the table with ACPI disabled in the kernel to see if it differs?
Comment 29 Lin Ming 2009-11-26 06:00:55 UTC
I mean to dump the MSFT DSDT.

Boot kernel with acpi=off
acpidump --addr 0xafee6000  --length 0xB13C > DSDT.MSFT
Comment 30 Mike Smith 2009-11-26 06:20:20 UTC
Created attachment 23950 [details]

As requested.
Comment 31 Lin Ming 2009-11-26 07:13:06 UTC
Created attachment 23951 [details]
custom dsdt of DSDT.MSFT

Thanks, Mike.

Seems that below DSDT memory (from 0xafee6000) is modified by BIOS.
 BIOS-e820: 00000000afee2000 - 00000000afef7000 (ACPI data)

At the beginning it's DSDT.MSFT and then it's modified with DSDT.INTL.
Please help to try the attached custom DSDT generated from DSDT.MSFT.

If this also helps, then we should copy the DSDT to a safe place, stop BIOS from modifying the DSDT memory.
Comment 32 Mike Smith 2009-11-26 07:59:08 UTC
It works with no errors/warnings/oopses at all with DSDT.MSFT.

... why is my BIOS dynamically modifying the DSDT?
Comment 33 Mike Smith 2009-11-26 08:01:44 UTC
... although that seems to have been an INTL DSDT:

0x00,0x00,0x00,0xF0,0x49,0x4E,0x54,0x4C,  /* 00000018    "....INTL" */
Comment 34 Lin Ming 2009-11-26 08:08:56 UTC
Good news.

> 0x00,0x00,0x00,0xF0,0x49,0x4E,0x54,0x4C,  /* 00000018    "....INTL" */

Just re-compile DSDT.MSFT with Intel iASL compiler, so it showes "INTL".
That's OK.

> ... why is my BIOS dynamically modifying the DSDT?

I'm wondering why too....

I'll write a patch to copy the DSDT to a safe place.
Comment 35 Lin Ming 2009-11-27 04:02:24 UTC
Created attachment 23958 [details]
test patch to copy DSDT for safe


Would you help to test the attached patch?
You don't have to use any special acpi boot option or any custom DSDT.

Just apply the patch, build kernel, boot....

Please also attach the dmesg.
Comment 36 Mike Smith 2009-11-27 04:30:52 UTC
Created attachment 23959 [details]
dmesg with patch applied

Seems to be working.

(All I did was apply the patch and remove the custom DSDT in the configuration, but I feel like I'm missing something. If it works I won't complain though.)
Comment 37 Lin Ming 2009-11-27 05:17:14 UTC
$ grep DSDT dmesg_with_patch_applied 
ACPI: DSDT 00000000afee6000 0B13C (v01 TOSINV TOSINV00 F0000000 MSFT 01000013)
ACPI: DSDT (00000000afee6000 0B13C) is copied to ffff8800af840000

You didn't miss anything. That's correct.

OK, patch works.
Comment 38 Len Brown 2009-12-01 02:31:08 UTC
Is it possible to run Windows on this box?

It is important to find out which version of the DSDT Windows
is running with.  (Either they are running with the "new copy"
like the one inflicted on Linux, or it is running with the
"original", which seems to run fine with Linux).

One can extract the DSDT via windows by getting iasl
from acpica.org and running iasl -g

If Windows is running with a different DSDT than Linux,
then it becomes important to find out why Linux is provoking
the BIOS to scribble all over the DSDT.  Probably the
best way to do this is to take Lin Ming's patch and save
a copy of the original DSDT, and then from several places
compare the original and the current DSDT to see when
the BIOS clobbers the in-memory copy.

The most likely place this would occur is when we
write the SMI_CMD register to actually enter ACPI mode.

I very much do not want to copy the DSDT on all systems
because of the failure on this one system -- there must
be a better solution.
Comment 39 Mike Smith 2009-12-01 04:09:56 UTC
Created attachment 23979 [details]
DSDT from iasl -g

DSDT acquired from iasl -g on Windows 7.

It's worth noting that iasl -g reproducibly crashes for me, but it seems to happen after it's written all the files so I don't think there should be any corruption.
Comment 40 Lin Ming 2009-12-01 05:46:58 UTC
Created attachment 23980 [details]
debug patch

It's the same with DSDT.MSFT at comment #30.

Please test the attached debug patch to figure out if the DSDT memory is modified right after acpi_enable.

Attach the dmesg.
dmesg | grep acpi_enabe -A 1
Comment 41 Mike Smith 2009-12-01 19:07:03 UTC
Created attachment 23986 [details]
dmesg with debug patch

[laptop: mike in ~]> dmesg |grep acpi_enable -A1
Before acpi_enable()
ACPI: DSDT 00000000afee6000 0B13C (v01 TOSINV TOSINV00 F0000000 MSFT 01000013)
After acpi_enable()
ACPI: DSDT 00000000afee6000 0B13C (v01 TOSINV TOSINV00 F0000000 MSFT 01000013)
Comment 42 Lin Ming 2009-12-02 08:23:32 UTC
Created attachment 23995 [details]
debug patch

Mike, thanks for the quick response.

Seems that DSDT is not modified in acpi_enable.
I wrote another debug patch to check DSDT in several other places as Len suggested.
Would you help to test it? 
First, apply my "copy dsdt" patch at #35, then this patch.

Please enable CONFIG_DEBUG_INFO which locates at "Kernel hacking ---> Compile the kernel with debug info" of menuconfig.

If DSDT modification is detected, this patch will dump the call trace, like below
[  894.116690] check_dsdt: DSDT is modified, dump the call stack
[  894.116696] Pid: 3774, comm: cat Not tainted 2.6.32-rc8-copy_check_dsdt #116
[  894.116699] Call Trace:
[  894.116707]  [<c02dfb92>] check_dsdt+0x72/0x88
[  894.116711]  [<c02b3576>] acpi_os_read_port+0x4c/0x6b
[  894.116716]  [<c02d2981>] acpi_hw_read_port+0x25/0x80
[  894.116721]  [<c02d1463>] acpi_hw_read+0x48/0x91
[  894.116725]  [<c02d14cf>] acpi_hw_read_multiple+0x23/0x54
[  894.116729]  [<c02d1725>] acpi_hw_register_read+0x5a/0xf1
[  894.116733]  [<c02d2309>] acpi_read_bit_register+0x64/0xe7
[  894.116738]  [<c02c3dfb>] acpi_get_event_status+0x7f/0x10b

If kernel is build with CONFIG_DEBUG_INFO=y, then you can run addr2line to get the source line of above stack, for example,
addr2line -e vmlinux 0xc02b3576

Please attach the dmesg.
And also the results of addr2line if DSDT modification is detected.

Comment 43 Mike Smith 2009-12-03 05:36:38 UTC
Created attachment 24001 [details]
dmesg with debug patch

[laptop: mike in ~]> addr2line -e /usr/src/linux-2.6.31/vmlinux 0xffffffff8122efb6
Comment 44 Lin Ming 2009-12-03 06:03:18 UTC
check_dsdt in acpi_os_write_port: port 176, value 227, width 8
176 = 0xB0, 227 = 0xE3

    OperationRegion (PSMI, SystemIO, 0xB0, 0x02)
    Field (PSMI, ByteAcc, NoLock, Preserve)
        APMC,   8,
        APMD,   8

    Method (FLNK, 2, Serialized)

        Store (Arg0, LCMD)
        Store (0xFF, APMD)
        Store (0xE3, APMC)
        Return (And (SWB0, 0xFF))
Comment 45 Lin Ming 2009-12-03 06:08:22 UTC
<Sorry, send the message before finished in above comment.>

From FACP.dsl,
[030h 0048  4]             SMI Command Port : 000000B0

Method FLNK writes 0xE3 to APMC(port 0xB0) which is the SMI port, that causes SMI.
The DSDT memory is modified in SMI.
Comment 46 Robert Hancock 2009-12-07 01:08:20 UTC
Hmm, interesting. So apparently something is triggering the BIOS to swap out the working MSFT DSDT with the horribly wrong INTL version. And apparently this doesn't happen on Windows 7.

One thing is that if you're using 2.6.31 it appears that kernel version didn't report Windows 2009 (i.e. Windows 7) compatibility. Mike, would you be able to test 2.6.32, which does, and see if the behavior changes (without extra patches)? It's possible that if the BIOS detects Windows 7 that it doesn't swap out the DSDT.

It goes without saying that whatever BIOS engineer at Toshiba thought that swapping out the DSDT at runtime was a good idea needs some serious re-education. I can't imagine any OS reacting well to this (especially since the one it swaps in seems totally busted).
Comment 47 Zhang Rui 2009-12-07 02:19:34 UTC
we'd better catch the Arg0 in method FLNK, so we can see why Linux invokes this SMI and investigate if windows runs a different AML code path.
Comment 48 Lin Ming 2009-12-07 03:28:30 UTC
$ grep FLNK DSDT.MSFT.dsl | wc -l

There are 70 calls to FLNK, and note the line "Store (0xE3, APMC)" which causes SMI. It does not check any arg passed in.

    Method (FLNK, 2, Serialized)
        If (LEqual (IECC, Zero))
            Add (IEC2, 0x03, IEC2)
            Decrement (IEC1)
            Subtract (IEC0, 0x0B, IEC0)
            Store (One, IECC)

        If (LEqual (Arg0, 0xFF))
            Store (Arg1, SVCF)
            Store (Arg1, SWB0)

        Store (Arg0, LCMD)
        Store (0xFF, APMD)
        Store (0xE3, APMC)
        Return (And (SWB0, 0xFF))
Comment 49 Zhang Rui 2009-12-07 04:00:24 UTC
Note that LCMD/SWB0 is set before invoking the SMI. I think they are used as the SMI index.
Comment 50 Zhang Rui 2009-12-08 08:46:15 UTC
Created attachment 24089 [details]
debug patch

please apply this patch, rebuild and boot with acpi_osi="*Windows 2009" and see if it helps.
Comment 51 Devin Smith 2009-12-12 02:39:47 UTC
Hi Zhang,

I am not the original submitter of the bug but I have the exact same laptop and have been following closely.  

The patch causes the kernel to oops even when I have the acpi_osi string enabled.
Comment 52 Robert Hancock 2009-12-12 02:41:21 UTC
Would still be useful if one of you could verify if the problem still exists with 2.6.32..
Comment 53 Mike Smith 2009-12-12 03:18:05 UTC
I was unable to boot with either clean 2.6.32 or with the patch Lin Ming emailed me.

2.6.32 oops'd with a stack trace that was too long for my screen. addr2line on the last address in the stack trace (somewhere in child_rip) gives:
[laptop: mike in ~]> addr2line 0xFFFFFFFF8100D0D0 -e /usr/src/linux-2.6.32/vmlinux

2.6.31 with Lin Ming's revised patch dumped many of the same ACPI errors and dropped me to a shell complaining it couldn't find my root filesystem. I was unable to get any logs from either because the boot didn't get to the point where I could access the disk.
Comment 54 Devin Smith 2009-12-12 03:31:03 UTC
Yes.  A clean 2.6.32 kernel also oops.  Applying the patch in comment #35 does allow it to boot though.
Comment 55 Mike Smith 2009-12-12 03:44:57 UTC
Created attachment 24159 [details]
DSDT checking patch, v2

It looks like I may have misunderstood what I was supposed to do with Lin's patch. Apparently I was supposed to apply it with the DSDT copy patch rather than against a clean tree. Waiting for a recompile now; will post results afterwards.

Attaching the patch, mainly because I'll probably lose it if I don't.
Comment 56 Mike Smith 2009-12-12 03:53:24 UTC
Same problem after applying both patches; appears to not like my system and refuses to find my disks. Not sure why, I noticed nothing abnormal in the boot log.
Comment 57 Devin Smith 2009-12-12 19:40:37 UTC

If it helps, I noticed the same problem when I first tried to install Linux on this laptop.  I had to run the whole installer with acpi=off for it to recognize my disk.  You should be able to run fine with 2.6.32 and only the #35 patch installed.  This is what is currently working for me.
Comment 58 Mike Smith 2009-12-12 19:58:00 UTC
Devin: I've got no important reasons to upgrade for now, I only compiled 2.6.32 for testing purposes. I'm still running 2.6.31 (not .7) for general use. Thanks for the tip though.
Comment 59 Zhang Rui 2009-12-14 01:23:18 UTC
does the problem still exists if you boot with acpi_osi=“!Windows 2006” AND acpi_osi="!Windows 2006 SP1"?
Comment 60 Mike Smith 2009-12-15 05:20:38 UTC
Created attachment 24191 [details]
dmesg with acpi_osi="!Windows 2006"

Yes it does. Attaching dmesg.
Comment 61 Mike Smith 2009-12-15 05:21:15 UTC
Created attachment 24192 [details]
dmesg with acpi_osi="!Windows 2006 SP1"
Comment 62 Zhang Rui 2009-12-15 05:36:18 UTC
(In reply to comment #59)
> does the problem still exists if you boot with acpi_osi=“!Windows 2006” AND
> acpi_osi="!Windows 2006 SP1"?

sorry, My comment may be misleading here.
I mean add boot option acpi_osi=“!Windows 2006” together with acpi_osi="!Windows 2006 SP1" in the grub, and then boot.
Comment 63 Devin Smith 2009-12-16 04:32:58 UTC
Hi Zhang,

It seems this boots on Mike's machine but in it oops with a stack trace longer than an 80 lines and goes off the screen.  I tested a variety of acpi_osi="!" values and got the same stack trace.

I tested:

 acpi_osi="!Windows 2006"
 acpi_osi="!Windows 2006 SP1"
 acpi_osi="!Windows 2009"
 acpi_osi="!Windows 2006" acpi_osi="!Windows 2006 SP1"
Comment 64 Mike Smith 2009-12-16 19:53:23 UTC
(Devin: The screen is 25 lines tall, not 80. Also no kernels have booted for me without the DSDT copying patch)
I managed to get a dmesg of it this morning on Arch's stock 2.6.31 and it still oopses and hangs in the udev initscripts (requiring a ^C to continue booting) even when passing acpi_osi="!Windows 2006" acpi_osi="!Windows 2006 SP1".
Comment 65 Zhang Rui 2010-02-21 06:56:22 UTC
this seems to be another problem.
it would be great if you can catch the oopses log (maybe take a picture?) and attach it here.
Comment 66 Devin Smith 2010-03-08 04:36:31 UTC
Created attachment 25403 [details]
dmesg stack tace

I wasn't able to get a picture.  The only camera I have is on my phone and the quality wasn't great so I've copied it down by hand and attached the text.
Comment 67 Devin Smith 2010-03-08 04:38:13 UTC
Sorry, I wanted to add that I've since upgraded to 2.6.33 and that's a stack trace from a vanilla 2.6.33 kernel straight from kernel.org
Comment 68 Steve Rigler 2010-03-09 12:27:25 UTC

I have a Toshiba A505-S6033 with a similar issue.  I applied the patch from comment #35 to the 2.6.33 kernel and it looks like it fixes most of the problems (I haven't tested everything yet, but I can boot without any additional kernel options and things seems to be working as expected).

Would you like me to provide information to this bug or should I open a separate one?
Comment 69 Zhang Rui 2010-03-10 02:19:29 UTC
what if you boot with "acpi_osi=", without the patch in comment #35.
does the problem still exist?
Comment 70 Devin Smith 2010-03-10 06:37:53 UTC
Yes sorry.  The same stack trace occurs no matter what acpi_osi option I pass.

I tried the following:

acpi_osi="Windows 2009"
acpi_osi="Windows 2006"
acpi_osi="!Windows 2009"
acpi_osi="!Windows 2006"
Comment 71 Lin Ming 2010-03-11 04:52:13 UTC

I remember that you asked Toshiba why there are 2 DSDTs and swapped in the SMI.
Any response?
Comment 72 Len Brown 2010-03-23 02:28:17 UTC
If you have a Toshiba system that fails like this,
please attach the output from dmidecode.
It is likely that we'll need to wrap the workaround in comment #35
in a toshiba-specific trigger.
Comment 73 Mike Smith 2010-03-23 02:35:21 UTC
Created attachment 25649 [details]
sudo dmidecode >dmidecode.txt
Comment 74 Steve Rigler 2010-03-23 22:01:29 UTC
Created attachment 25660 [details]
dmidecode from A505-S6033

Here is a dmidecode from a different Toshiba suffering from a similar problem.
Comment 75 Lin Ming 2010-03-24 03:28:14 UTC
Created attachment 25669 [details]
add kernel boot option acpi=copy_dsdt

We are going to add code to detect a new DSDT before method execution.
If detected, we'll warn some message like,
"DSDT is modified on the fly, if the system does not work well please try to boot with acpi=copy_dsdt"

So please try this patch and boot with acpi=copy_dsdt.

Comment 76 Steve Rigler 2010-03-24 23:37:04 UTC
I applied the patch to and can boot cleanly with "acpi=copy_dsdt" on my A505.  FYI, I get this trace unless I boot with "nohpet" on any kernel, but maybe it's unrelated:

Call Trace:
 [<ffffffff8104cfdf>] warn_slowpath_common+0x7c/0x94
 [<ffffffff8104d04e>] warn_slowpath_fmt+0x41/0x43
 [<ffffffff8102857b>] hpet_next_event+0x64/0x86
 [<ffffffff810285c0>] hpet_legacy_next_event+0x10/0x12
 [<ffffffff81072cad>] clockevents_program_event+0x7a/0x83
 [<ffffffff81073df5>] tick_dev_program_event+0x3c/0xaa
 [<ffffffff810737f5>] tick_broadcast_oneshot_control+0xa4/0x100
 [<ffffffff8107311f>] tick_notify+0x222/0x379
 [<ffffffff8144deab>] notifier_call_chain+0x37/0x63
 [<ffffffff8106bfbc>] raw_notifier_call_chain+0x14/0x16
 [<ffffffff81072a74>] clockevents_notify+0x3d/0x100
 [<ffffffff81277931>] lapic_timer_state_broadcast+0x46/0x48
 [<ffffffff81277ea2>] acpi_idle_enter_bm+0x187/0x2b2
 [<ffffffff8144de88>] ? notifier_call_chain+0x14/0x63
 [<ffffffff8137cb9a>] cpuidle_idle_call+0x99/0xf3
 [<ffffffff81008c52>] cpu_idle+0xaa/0xe4
 [<ffffffff81442da6>] start_secondary+0x1f2/0x233
---[ end trace 9222b48c6e42461b ]---
Comment 77 Devin Smith 2010-03-26 01:10:03 UTC
I can report that the patch from comment #75 also works for me (running 2.6.33 as well now).  Thanks.  I've never seen any hpet stack trace either.
Comment 78 Len Brown 2010-03-30 01:23:30 UTC
Please open a new bug report about the hpet backtrace you see,
unless you only see it with the patch in this bug report.
Comment 79 Steve Rigler 2010-03-30 11:20:14 UTC
Will do, Len.  Thanks.
Comment 80 Len Brown 2010-04-06 01:22:44 UTC
I will apply the patch from comment #75 to linux when it comes
via next ACPICA update, which should be within the next week or so.
Comment 81 Matthew Garrett 2010-05-20 15:48:43 UTC
Created attachment 26461 [details]
Further debug patch

Could someone please try this patch with the debug patch from comment #42, and *without* the DSDT copying code? It would be good to trace down which method is triggering the SMI that modifies the DSDT.
Comment 82 Robert Moore 2010-05-20 16:08:28 UTC
Comment #44 shows the offending method.
Comment 83 Matthew Garrett 2010-05-20 16:10:06 UTC
It's called from about 70 different places in the DSDT. I'm interested in figuring out which of them is responsible.
Comment 84 Mike Smith 2010-05-22 15:54:19 UTC

I just tried applying your patch and got a stack trace during boot. The kernel was completely hung after that so I couldn't scroll up. I'll keep prodding it and see if I can get it to at least log something to disk.
Comment 85 Matthew Garrett 2010-05-22 16:25:41 UTC
Sorry about that - it looks like I've made a mistake somewhere in the patch. I'll try to get you a new one on Monday.
Comment 86 Devin Smith 2010-05-30 01:47:15 UTC
Created attachment 26578 [details]
dmesg for Linux 2.6.34

dmesg for 2.6.34 and Matthew's patch
Comment 87 Devin Smith 2010-05-30 01:51:05 UTC

I meant to mention that the dmesg in comment #86 is a vanilla 2.6.34 kernel with your patch and it worked fine but I needed to also apply the copy_dsdt patch from comment #75.  Hope this helps you.
Comment 88 Josh Lehan 2010-06-09 16:55:54 UTC
I can confirm the patch in comment #35 works great, in kernel 2.6.34, to fix the ACPI bug for my Toshiba L505D-LS5005 laptop.

With vanilla 2.6.34, the bug is the same as in earlier kernel versions: it fails to complete booting, getting stuck in an endless loop of ACPI messages that scroll up the screen.  It appears to be stuck in an infinite loop.  Booting up with "acpi=off" is a workaround that will give a successful boot, but then, all ACPI functionality is lost.

With the patch in comment #35 installed, however, kernel 2.6.34 works, and all ACPI functionality is just fine.

Any reason why that patch can't make it into the mainstream kernel?  It would solve a lot of problems for people with Toshiba laptops.
Comment 89 Zhang Rui 2010-06-10 01:10:34 UTC
I think the patch is already in upstream kernel,
can you please make a double check?
Comment 90 Lin Ming 2010-06-10 01:46:36 UTC
The patch was included in 2.6.35-rc1.
Comment 91 Lin Ming 2010-06-10 05:39:58 UTC
commit 69ec87efa815d69140423014bb5f91e034faac22
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Thu Apr 1 11:14:12 2010 +0800

    ACPICA: Add subsystem option to force copy of DSDT to local memory
    Optionally copy the entire DSDT to local memory (instead of
    simply mapping it.) There are some BIOSs that corrupt or replace
    the original DSDT, creating the need for this option. Default is
    FALSE, do not copy the DSDT.
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Bob Moore <robert.moore@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
Comment 92 Josh Lehan 2010-06-10 06:44:59 UTC
Nice!  Glad to know it's in 2.6.35.  Will look forward to that.

I wonder why it defaults to FALSE.  It will still break the "out-of-box experience" for Toshiba laptops.  Can a blacklist flag be added, so that it will default to TRUE when certain laptop models/vendors are detected?

Isn't the DSDT only around 64K in size?  What would be the harm of always keeping a local copy?  Perhaps a heuristic could be used, such as only copying the DSDT if the installed memory size is 1GB or larger (so the memory loss wouldn't really be noticed).

I don't mean to nitpick, just concerned about the ability of systems to do a clean install of Linux (i.e. put in the CD/USB and it "Just Works", with no manual intervention necessary to edit the kernel command line or anything like that).
Comment 93 Lin Ming 2010-06-10 06:50:30 UTC
We have a DMI blacklist for the broken machines.

commit aa2110cb1a7510f9b834adfb39b05d4843a35d35
Author: Lin Ming <ming.m.lin@intel.com>
Date:   Thu Apr 8 14:34:27 2010 +0800

    ACPI: add boot option acpi=copy_dsdt to fix corrupt DSDT
    Some BIOS on Toshiba machines corrupt the DSDT, so add a new
    boot option acpi=copy_dsdt to workaround it.
    Add warning message to ask users to use this option if corrupt DSDT detected.
    Also build a DMI blacklist to check it and automatically copy DSDT.
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>
Comment 94 Zhang Rui 2010-06-11 03:00:35 UTC
why not attach your dmidecode output here so that we can generate another DMI quirk for your laptop? :)
Comment 95 Josh Lehan 2010-06-28 18:42:58 UTC
Created attachment 26963 [details]
dmidecode for Toshiba L505D-LS5005

Certainly.  Here's the attachment, from dmidecode --dump-bin.
Comment 96 Joseph Booker 2010-08-27 16:57:32 UTC
Created attachment 28151 [details]
Output of `dmidecode -u` on a Toshiba Satellite C655D-S5048

Not sure if I should start a new bug, but here is the output of dmi for my laptop. It would kernel panic with an ACPI-related stack trace unless I used acpi=off (acpi=ht, acpi=oldboot, and pci=noacpi would not change this), however, it boots with working ACPI using 2.6.35-19-generic from Ubuntu and the acpi=keep_dsdt option.

Hoping this dump will allow others to have a better out-of-the-box experience.
Comment 97 Zhang Rui 2010-08-30 00:24:00 UTC
(In reply to comment #96)

> however, it boots with working ACPI using 2.6.35-19-generic from Ubuntu and
> the
> acpi=keep_dsdt option.
are you using acpi=keep_dsdt or acpi=copy_dsdt?
If keep_dsdt is used, it seems that the problem of your laptop has been fixed by the 2.6.35 kernel because we don't support this boot option at all. :)
Comment 98 Joseph Booker 2010-08-30 23:42:59 UTC
Yes, sorry, I put it in grub.cfg as keep_dsdt when it was working with copy_dsdt and was confused why the it wasn't working on the next boot. :)

I can't scroll once it performs a kernel panic and I don't know how to output to a usb serial console (nor do I think I have the cables for that), but the earliest part of the stack trace I can see has to do with acpi_bus_scan calls for 2.6.35 and 2.6.33. It's the lack of kernel panics with acpi=copy_dsdt that make me think I have this bug too.
Comment 99 Len Brown 2010-09-29 03:00:00 UTC
Created attachment 31852 [details]
DMI patch for Toshiba Satellite C655D-S5048

Joseph, Please test this patch.
Comment 100 Len Brown 2010-09-29 18:27:28 UTC
Created attachment 31922 [details]
DMI for all Toshiba Satellite


Satellite C650D
Satellite L650D-10J

So rather than adding 2 to the list, lets combine all four
into one that applies to all Toshiba Satellite.  This means
the workaround will be invoked for the entire product family.

please test.
Comment 101 Len Brown 2010-10-02 02:03:58 UTC
commit 100cf87788c0e9104f6fb1b0ff5f72f73fbbbea3
Author: Len Brown <len.brown@intel.com>
Date:   Tue Sep 28 22:57:02 2010 -0400

    ACPI: invoke DSDT corruption workaround on all Toshiba Satellite

shipped in 2.6.36-rc6-git2
Comment 102 Joseph Booker 2010-10-05 17:01:42 UTC
(In reply to comment #100)
> Created an attachment (id=31922) [details]
> DMI for all Toshiba Satellite

Sorry for the late response, this patch worked using vanilla linux with no command line arguments besides root= and ro
Comment 103 Otto Domínguez 2011-05-04 01:10:33 UTC
Experiencing this with 2.6.38-8 on Ubuntu. Battery is not detected.
Computer is Toshiba L645-SP4130L with Insyde BIOS 2.30 (latest available).
Failed also with Fedora 15 beta (2.6.38), Zenwalk 7 (2.6.37). Even Debian 6 does not detect the battery (2.6.32).
Comment 104 Otto Domínguez 2011-05-04 01:12:03 UTC
Created attachment 56412 [details]
Toshiba L645-SP4130L dmesg
Comment 105 Zhang Rui 2011-05-04 02:01:59 UTC
you have the "Battery not detected" problem on your laptop, right?
If yes, it's a different problem. please file a new bug report and attach the acpidump output of your laptop.