please attach the acpidump output of this laptop.

Created attachment 23900 [details]
acpidump output

As requested.

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...

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.

@#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.)

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?

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.

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.

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.

Created attachment 23907 [details]
/proc/acpi/dsdt

Probably relevant: when copying this file I got two RSDT checksum errors on the console.

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?

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.

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).

Can you post the dmesg output from such a bootup? Do you still see all those ACPI exceptions?

I do see the ACPI exceptions, those were the "errors" I referred to. dmesg output coming up.

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".

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.

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..

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...

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
   http://www.lesswatts.org/projects/acpi/overridingDSDT.php

   This custom DSDT comes from your original acpidump at comment #2.

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.

Created attachment 23935 [details]
dsdt_reported_by_kernel

Waiting for new kernel to finish building. Until then, here's the other DSDT you asked for.

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.

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?)

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)

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).

(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 
> |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?)

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
01000013)

It's same as the DSDT in comment #2.

> Did you run "acpidump --addr 0xafee6000  --length 0xB13C >
DSDT_reported_by_kernel"?
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?

I mean to dump the MSFT DSDT.

Boot kernel with acpi=off
acpidump --addr 0xafee6000  --length 0xB13C > DSDT.MSFT

Created attachment 23950 [details]
DSDT.MSFT

As requested.

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.

It works with no errors/warnings/oopses at all with DSDT.MSFT.

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

... although that seems to have been an INTL DSDT:

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

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.

Created attachment 23958 [details]
test patch to copy DSDT for safe

Mike, 

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.

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.)

$ 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.

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.

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.

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

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)

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.

Thanks.

Created attachment 24001 [details]
dmesg with debug patch

[laptop: mike in ~]> addr2line -e /usr/src/linux-2.6.31/vmlinux 0xffffffff8122efb6
/usr/src/linux-2.6.31/drivers/acpi/osl.c:517

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))
    }

<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.

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).

Ming,
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.

$ grep FLNK DSDT.MSFT.dsl | wc -l
71

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)
        }
        Else
        {
            Store (Arg1, SWB0)
        }

        Store (Arg0, LCMD)
        Store (0xFF, APMD)
        Store (0xE3, APMC)
        Return (And (SWB0, 0xFF))
    }

Note that LCMD/SWB0 is set before invoking the SMI. I think they are used as the SMI index.

Created attachment 24089 [details]
debug patch

please apply this patch, rebuild and boot with acpi_osi="*Windows 2009" and see if it helps.

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.

Would still be useful if one of you could verify if the problem still exists with 2.6.32..

I was unable to boot with either clean 2.6.32 or 2.6.31.7 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
/usr/src/linux-2.6.32/arch/x86/kernel/entry_64.S:1203

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.

Yes.  A clean 2.6.32 kernel also oops.  Applying the patch in comment #35 does allow it to boot though.

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.

Same problem after applying both patches; 2.6.31.7 appears to not like my system and refuses to find my disks. Not sure why, I noticed nothing abnormal in the boot log.

Mike,

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.

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.

does the problem still exists if you boot with acpi_osi=“!Windows 2006” AND acpi_osi="!Windows 2006 SP1"?

Created attachment 24191 [details]
dmesg with acpi_osi="!Windows 2006"

Yes it does. Attaching dmesg.

Created attachment 24192 [details]
dmesg with acpi_osi="!Windows 2006 SP1"

(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.

Hi Zhang,

It seems this boots on Mike's machine but in 2.6.32.1 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"

(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".

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.

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.

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

Hello,

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?

what if you boot with "acpi_osi=", without the patch in comment #35.
does the problem still exist?

Yes sorry.  The same stack trace occurs no matter what acpi_osi option I pass.

I tried the following:

acpi_osi=
acpi_osi="Windows 2009"
acpi_osi="Windows 2006"
acpi_osi="!Windows 2009"
acpi_osi="!Windows 2006"

Len,

I remember that you asked Toshiba why there are 2 DSDTs and swapped in the SMI.
Any response?

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.

Created attachment 25649 [details]
sudo dmidecode >dmidecode.txt

Created attachment 25660 [details]
dmidecode from A505-S6033

Here is a dmidecode from a different Toshiba suffering from a similar problem.

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.

Thanks.

I applied the patch to 2.6.33.1 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 ]---

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.

Steve,
Please open a new bug report about the hpet backtrace you see,
unless you only see it with the patch in this bug report.

Will do, Len.  Thanks.

FYI,
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.

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 #44 shows the offending method.

It's called from about 70 different places in the DSDT. I'm interested in figuring out which of them is responsible.

Matthew,

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.

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.

Created attachment 26578 [details]
dmesg for Linux 2.6.34

dmesg for 2.6.34 and Matthew's patch

Matthew,

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.

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.

I think the patch is already in upstream kernel,
Ming,
can you please make a double check?

The patch was included in 2.6.35-rc1.

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.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=14679
    
    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>

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).

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.
    
    https://bugzilla.kernel.org/show_bug.cgi?id=14679
    
    Signed-off-by: Lin Ming <ming.m.lin@intel.com>
    Signed-off-by: Len Brown <len.brown@intel.com>

Josh,
why not attach your dmidecode output here so that we can generate another DMI quirk for your laptop? :)

Created attachment 26963 [details]
dmidecode for Toshiba L505D-LS5005

Certainly.  Here's the attachment, from dmidecode --dump-bin.

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.

(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. :)

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.

Created attachment 31852 [details]
DMI patch for Toshiba Satellite C655D-S5048

Joseph, Please test this patch.

Created attachment 31922 [details]
DMI for all Toshiba Satellite

http://www.spinics.net/lists/linux-acpi/msg29761.html
and
http://www.spinics.net/lists/linux-acpi/msg30002.html
add

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.

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
closed

(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 2.6.35.4 with no command line arguments besides root= and ro

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).

Created attachment 56412 [details]
Toshiba L645-SP4130L dmesg

Otto,
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.