Launchpad has imported 107 comments from the remote bug at
https://bugzilla.kernel.org/show_bug.cgi?id=14679.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2009-11-24T00:43:23+00:00 scgtrp wrote:
Created attachment 23899
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/3
------------------------------------------------------------------------
On 2009-11-24T01:28:39+00:00 rui.zhang wrote:
please attach the acpidump output of this laptop.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/4
------------------------------------------------------------------------
On 2009-11-24T01:49:55+00:00 scgtrp wrote:
Created attachment 23900
acpidump output
As requested.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/5
------------------------------------------------------------------------
On 2009-11-24T03:31:03+00:00 lenb wrote:
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...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/6
------------------------------------------------------------------------
On 2009-11-24T03:35:15+00:00 lenb wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/7
------------------------------------------------------------------------
On 2009-11-24T03:42:41+00:00 scgtrp wrote:
@#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.)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/8
------------------------------------------------------------------------
On 2009-11-24T03:50:14+00:00 scgtrp wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/9
------------------------------------------------------------------------
On 2009-11-24T03:53:16+00:00 hancockrwd wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/10
------------------------------------------------------------------------
On 2009-11-24T03:56:46+00:00 hancockrwd wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/11
------------------------------------------------------------------------
On 2009-11-24T04:03:50+00:00 scgtrp wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/12
------------------------------------------------------------------------
On 2009-11-24T04:09:30+00:00 scgtrp wrote:
Created attachment 23907
/proc/acpi/dsdt
Probably relevant: when copying this file I got two RSDT checksum errors
on the console.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/13
------------------------------------------------------------------------
On 2009-11-24T04:29:13+00:00 hancockrwd wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/14
------------------------------------------------------------------------
On 2009-11-24T04:42:03+00:00 scgtrp wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/15
------------------------------------------------------------------------
On 2009-11-24T22:33:44+00:00 scgtrp wrote:
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).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/16
------------------------------------------------------------------------
On 2009-11-24T23:18:40+00:00 hancockrwd wrote:
Can you post the dmesg output from such a bootup? Do you still see all
those ACPI exceptions?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/17
------------------------------------------------------------------------
On 2009-11-24T23:22:56+00:00 scgtrp wrote:
I do see the ACPI exceptions, those were the "errors" I referred to.
dmesg output coming up.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/18
------------------------------------------------------------------------
On 2009-11-24T23:37:02+00:00 scgtrp wrote:
Created attachment 23924
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".
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/19
------------------------------------------------------------------------
On 2009-11-25T01:18:30+00:00 scgtrp wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/20
------------------------------------------------------------------------
On 2009-11-25T01:26:05+00:00 hancockrwd wrote:
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..
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/21
------------------------------------------------------------------------
On 2009-11-25T01:55:47+00:00 scgtrp wrote:
Created attachment 23925
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...
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/22
------------------------------------------------------------------------
On 2009-11-25T05:52:26+00:00 ming.m.lin wrote:
Created attachment 23928
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/23
------------------------------------------------------------------------
On 2009-11-25T06:17:45+00:00 ming.m.lin wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/24
------------------------------------------------------------------------
On 2009-11-25T17:30:44+00:00 scgtrp wrote:
Created attachment 23935
dsdt_reported_by_kernel
Waiting for new kernel to finish building. Until then, here's the other
DSDT you asked for.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/25
------------------------------------------------------------------------
On 2009-11-25T18:15:31+00:00 lenb wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/26
------------------------------------------------------------------------
On 2009-11-25T19:41:28+00:00 scgtrp wrote:
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?)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/27
------------------------------------------------------------------------
On 2009-11-25T19:51:17+00:00 scgtrp wrote:
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)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/28
------------------------------------------------------------------------
On 2009-11-25T22:57:07+00:00 scgtrp wrote:
Created attachment 23939
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).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/29
------------------------------------------------------------------------
On 2009-11-26T02:03:23+00:00 ming.m.lin wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/30
------------------------------------------------------------------------
On 2009-11-26T05:43:23+00:00 scgtrp wrote:
> 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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/31
------------------------------------------------------------------------
On 2009-11-26T06:00:55+00:00 ming.m.lin wrote:
I mean to dump the MSFT DSDT.
Boot kernel with acpi=off
acpidump --addr 0xafee6000 --length 0xB13C > DSDT.MSFT
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/32
------------------------------------------------------------------------
On 2009-11-26T06:20:20+00:00 scgtrp wrote:
Created attachment 23950
DSDT.MSFT
As requested.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/33
------------------------------------------------------------------------
On 2009-11-26T07:13:06+00:00 ming.m.lin wrote:
Created attachment 23951
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/34
------------------------------------------------------------------------
On 2009-11-26T07:59:08+00:00 scgtrp wrote:
It works with no errors/warnings/oopses at all with DSDT.MSFT.
... why is my BIOS dynamically modifying the DSDT?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/35
------------------------------------------------------------------------
On 2009-11-26T08:01:44+00:00 scgtrp wrote:
... although that seems to have been an INTL DSDT:
0x00,0x00,0x00,0xF0,0x49,0x4E,0x54,0x4C, /* 00000018 "....INTL" */
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/36
------------------------------------------------------------------------
On 2009-11-26T08:08:56+00:00 ming.m.lin wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/37
------------------------------------------------------------------------
On 2009-11-27T04:02:24+00:00 ming.m.lin wrote:
Created attachment 23958
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/38
------------------------------------------------------------------------
On 2009-11-27T04:30:52+00:00 scgtrp wrote:
Created attachment 23959
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.)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/39
------------------------------------------------------------------------
On 2009-11-27T05:17:14+00:00 ming.m.lin wrote:
$ 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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/40
------------------------------------------------------------------------
On 2009-12-01T02:31:08+00:00 lenb wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/42
------------------------------------------------------------------------
On 2009-12-01T04:09:56+00:00 scgtrp wrote:
Created attachment 23979
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/43
------------------------------------------------------------------------
On 2009-12-01T05:46:58+00:00 ming.m.lin wrote:
Created attachment 23980
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/44
------------------------------------------------------------------------
On 2009-12-01T19:07:03+00:00 scgtrp wrote:
Created attachment 23986
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)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/46
------------------------------------------------------------------------
On 2009-12-02T08:23:32+00:00 ming.m.lin wrote:
Created attachment 23995
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/47
------------------------------------------------------------------------
On 2009-12-03T05:36:38+00:00 scgtrp wrote:
Created attachment 24001
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/48
------------------------------------------------------------------------
On 2009-12-03T06:03:18+00:00 ming.m.lin wrote:
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))
}
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/49
------------------------------------------------------------------------
On 2009-12-03T06:08:22+00:00 ming.m.lin wrote:
<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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/50
------------------------------------------------------------------------
On 2009-12-07T01:08:20+00:00 hancockrwd wrote:
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).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/51
------------------------------------------------------------------------
On 2009-12-07T02:19:34+00:00 rui.zhang wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/52
------------------------------------------------------------------------
On 2009-12-07T03:28:30+00:00 ming.m.lin wrote:
$ 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))
}
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/53
------------------------------------------------------------------------
On 2009-12-07T04:00:24+00:00 rui.zhang wrote:
Note that LCMD/SWB0 is set before invoking the SMI. I think they are
used as the SMI index.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/54
------------------------------------------------------------------------
On 2009-12-08T08:46:15+00:00 rui.zhang wrote:
Created attachment 24089
debug patch
please apply this patch, rebuild and boot with acpi_osi="*Windows 2009"
and see if it helps.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/55
------------------------------------------------------------------------
On 2009-12-12T02:39:47+00:00 devinsmith wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/57
------------------------------------------------------------------------
On 2009-12-12T02:41:21+00:00 hancockrwd wrote:
Would still be useful if one of you could verify if the problem still
exists with 2.6.32..
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/58
------------------------------------------------------------------------
On 2009-12-12T03:18:05+00:00 scgtrp wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/59
------------------------------------------------------------------------
On 2009-12-12T03:31:03+00:00 devinsmith wrote:
Yes. A clean 2.6.32 kernel also oops. Applying the patch in comment
#35 does allow it to boot though.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/60
------------------------------------------------------------------------
On 2009-12-12T03:44:57+00:00 scgtrp wrote:
Created attachment 24159
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/61
------------------------------------------------------------------------
On 2009-12-12T03:53:24+00:00 scgtrp wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/62
------------------------------------------------------------------------
On 2009-12-12T19:40:37+00:00 devinsmith wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/63
------------------------------------------------------------------------
On 2009-12-12T19:58:00+00:00 scgtrp wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/64
------------------------------------------------------------------------
On 2009-12-14T01:23:18+00:00 rui.zhang wrote:
does the problem still exists if you boot with acpi_osi="!Windows 2006"
AND acpi_osi="!Windows 2006 SP1"?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/65
------------------------------------------------------------------------
On 2009-12-15T05:20:38+00:00 scgtrp wrote:
Created attachment 24191
dmesg with acpi_osi="!Windows 2006"
Yes it does. Attaching dmesg.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/66
------------------------------------------------------------------------
On 2009-12-15T05:21:15+00:00 scgtrp wrote:
Created attachment 24192
dmesg with acpi_osi="!Windows 2006 SP1"
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/67
------------------------------------------------------------------------
On 2009-12-15T05:36:18+00:00 rui.zhang wrote:
(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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/68
------------------------------------------------------------------------
On 2009-12-16T04:32:58+00:00 devinsmith wrote:
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"
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/69
------------------------------------------------------------------------
On 2009-12-16T19:53:23+00:00 scgtrp wrote:
(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".
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/70
------------------------------------------------------------------------
On 2010-02-21T06:56:22+00:00 rui.zhang wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/71
------------------------------------------------------------------------
On 2010-03-08T04:36:31+00:00 devinsmith wrote:
Created attachment 25403
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/73
------------------------------------------------------------------------
On 2010-03-08T04:38:13+00:00 devinsmith wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/74
------------------------------------------------------------------------
On 2010-03-09T12:27:25+00:00 riglersc wrote:
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?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/75
------------------------------------------------------------------------
On 2010-03-10T02:19:29+00:00 rui.zhang wrote:
what if you boot with "acpi_osi=", without the patch in comment #35.
does the problem still exist?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/76
------------------------------------------------------------------------
On 2010-03-10T06:37:53+00:00 devinsmith wrote:
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"
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/77
------------------------------------------------------------------------
On 2010-03-11T04:52:13+00:00 ming.m.lin wrote:
Len,
I remember that you asked Toshiba why there are 2 DSDTs and swapped in the SMI.
Any response?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/78
------------------------------------------------------------------------
On 2010-03-23T02:28:17+00:00 lenb wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/79
------------------------------------------------------------------------
On 2010-03-23T02:35:21+00:00 scgtrp wrote:
Created attachment 25649
sudo dmidecode >dmidecode.txt
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/80
------------------------------------------------------------------------
On 2010-03-23T22:01:29+00:00 riglersc wrote:
Created attachment 25660
dmidecode from A505-S6033
Here is a dmidecode from a different Toshiba suffering from a similar
problem.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/81
------------------------------------------------------------------------
On 2010-03-24T03:28:14+00:00 ming.m.lin wrote:
Created attachment 25669
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/82
------------------------------------------------------------------------
On 2010-03-24T23:37:04+00:00 riglersc wrote:
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 ]---
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/83
------------------------------------------------------------------------
On 2010-03-26T01:10:03+00:00 devinsmith wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/84
------------------------------------------------------------------------
On 2010-03-30T01:23:30+00:00 lenb wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/85
------------------------------------------------------------------------
On 2010-03-30T11:20:14+00:00 riglersc wrote:
Will do, Len. Thanks.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/86
------------------------------------------------------------------------
On 2010-04-06T01:22:44+00:00 lenb wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/87
------------------------------------------------------------------------
On 2010-05-20T15:48:43+00:00 mjg59-kernel wrote:
Created attachment 26461
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/88
------------------------------------------------------------------------
On 2010-05-20T16:08:28+00:00 Robert.Moore wrote:
Comment #44 shows the offending method.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/89
------------------------------------------------------------------------
On 2010-05-20T16:10:06+00:00 mjg59-kernel wrote:
It's called from about 70 different places in the DSDT. I'm interested
in figuring out which of them is responsible.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/90
------------------------------------------------------------------------
On 2010-05-22T15:54:19+00:00 scgtrp wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/91
------------------------------------------------------------------------
On 2010-05-22T16:25:41+00:00 mjg59-kernel wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/92
------------------------------------------------------------------------
On 2010-05-30T01:47:15+00:00 devinsmith wrote:
Created attachment 26578
dmesg for Linux 2.6.34
dmesg for 2.6.34 and Matthew's patch
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/93
------------------------------------------------------------------------
On 2010-05-30T01:51:05+00:00 devinsmith wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/94
------------------------------------------------------------------------
On 2010-06-09T16:55:54+00:00 krellan wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/95
------------------------------------------------------------------------
On 2010-06-10T01:10:34+00:00 rui.zhang wrote:
I think the patch is already in upstream kernel,
Ming,
can you please make a double check?
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/96
------------------------------------------------------------------------
On 2010-06-10T01:46:36+00:00 ming.m.lin wrote:
The patch was included in 2.6.35-rc1.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/97
------------------------------------------------------------------------
On 2010-06-10T05:39:58+00:00 ming.m.lin wrote:
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>
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/98
------------------------------------------------------------------------
On 2010-06-10T06:44:59+00:00 krellan wrote:
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).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/99
------------------------------------------------------------------------
On 2010-06-10T06:50:30+00:00 ming.m.lin wrote:
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>
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/100
------------------------------------------------------------------------
On 2010-06-11T03:00:35+00:00 rui.zhang wrote:
Josh,
why not attach your dmidecode output here so that we can generate another DMI quirk for your laptop? :)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/101
------------------------------------------------------------------------
On 2010-06-28T18:42:58+00:00 krellan wrote:
Created attachment 26963
dmidecode for Toshiba L505D-LS5005
Certainly. Here's the attachment, from dmidecode --dump-bin.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/102
------------------------------------------------------------------------
On 2010-08-27T16:57:32+00:00 joe wrote:
Created attachment 28151
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/103
------------------------------------------------------------------------
On 2010-08-30T00:24:00+00:00 rui.zhang wrote:
(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. :)
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/104
------------------------------------------------------------------------
On 2010-08-30T23:42:59+00:00 joe wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/105
------------------------------------------------------------------------
On 2010-09-29T03:00:00+00:00 lenb wrote:
Created attachment 31852
DMI patch for Toshiba Satellite C655D-S5048
Joseph, Please test this patch.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/106
------------------------------------------------------------------------
On 2010-09-29T18:27:28+00:00 lenb wrote:
Created attachment 31922
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/107
------------------------------------------------------------------------
On 2010-10-02T02:03:58+00:00 lenb wrote:
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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/108
------------------------------------------------------------------------
On 2010-10-05T17:01:42+00:00 joe wrote:
(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
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/109
------------------------------------------------------------------------
On 2011-05-04T01:10:33+00:00 otto wrote:
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).
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/110
------------------------------------------------------------------------
On 2011-05-04T01:12:03+00:00 otto wrote:
Created attachment 56412
Toshiba L645-SP4130L dmesg
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/111
------------------------------------------------------------------------
On 2011-05-04T02:01:59+00:00 rui.zhang wrote:
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.
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/112
------------------------------------------------------------------------
On 2024-10-18T11:53:06+00:00 andersonhermoine wrote:
Advance your career with UniCCM! Whether you want to lead contract
management, use your CAD expertise in design, ensure security with NPORS
and SMSTS qualifications or build resilience with the Human Firewall
program, UniCCM has the right course for you. Learn at your own pace
online from industry experts and get the qualifications you need to
excel.
https://www.uniccm.com/
Reply at:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/472183/comments/114
--
You received this bug notification because you are subscribed to linux
in Ubuntu.
Matching subscriptions: Bgg, Bmail, Nb
https://bugs.launchpad.net/bugs/472183
Title:
Boot halts on Toshiba L505
Status in Linux:
Fix Released
Status in linux package in Ubuntu:
Won't Fix
Bug description:
Booting from live CD or installed system on Toshiba L505D-S5992 will
fail with message: '/sbin/modprobe -b acpi:lnxvideo:' unexpected exit
with status 0x0009. I can only boot by choosing the "acpi=off" option
for the live cd or by adding "acip=off" to the end of the kernel line
in /boot/grub/grub.cfg. This is with both 9.04 and 9.10.
Laptop has an ATI Radeon 4100/4200 video card (have seen both model
numbers listed in different locations).
lspci reports this for the video: 01:05.0 VGA compatible controller:
ATI Technologies Inc Device 9712
lspci -nn reports: 01:05.0 VGA compatible controller [0300]: ATI
Technologies Inc Device [1002:9712]
ProblemType: Bug
Architecture: amd64
ArecordDevices:
**** List of CAPTURE Hardware Devices ****
card 0: SB [HDA ATI SB], device 0: ALC272 Analog [ALC272 Analog]
Subdevices: 1/1
Subdevice #0: subdevice #0
AudioDevicesInUse:
USER PID ACCESS COMMAND
/dev/snd/controlC0: mikep 1563 F.... knotify4
mikep 1586 F.... kmix
/dev/snd/controlC1: mikep 1586 F.... kmix
CRDA: Error: [Errno 2] No such file or directory
Card0.Amixer.info:
Card hw:0 'SB'/'HDA ATI SB at 0xd2400000 irq 5'
Mixer name : 'Realtek ALC272'
Components : 'HDA:10ec0272,1179ff12,00100001 HDA:11c11040,11790001,00100200'
Controls : 17
Simple ctrls : 11
Card1.Amixer.info:
Card hw:1 'HDMI'/'HDA ATI HDMI at 0xd2310000 irq 7'
Mixer name : 'ATI RS690/780 HDMI'
Components : 'HDA:1002791a,00791a00,00100000'
Controls : 4
Simple ctrls : 1
Card1.Amixer.values:
Simple mixer control 'IEC958',0
Capabilities: pswitch pswitch-joined
Playback channels: Mono
Mono: Playback [off]
Date: Mon Nov 2 19:48:31 2009
DistroRelease: Ubuntu 9.10
HibernationDevice: RESUME=UUID=092105e2-1654-41b1-bed8-4093e5be59da
InstallationMedia: Kubuntu 9.10 "Karmic Koala" - Release amd64 (20091027)
MachineType: TOSHIBA Satellite L505D
NonfreeKernelModules: fglrx
Package: linux-image-2.6.31-14-generic 2.6.31-14.48
ProcCmdLine: BOOT_IMAGE=/boot/vmlinuz-2.6.31-14-generic root=UUID=56762fb6-1081-4c85-9699-604ec732ffd4 ro quiet splash acpi=off
ProcEnviron:
LANGUAGE=
PATH=(custom, no user)
LANG=en_US.UTF-8
SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
RelatedPackageVersions:
linux-backports-modules-2.6.31-14-generic N/A
linux-firmware 1.24
RfKill:
SourcePackage: linux
Uname: Linux 2.6.31-14-generic x86_64
XsessionErrors:
(polkit-gnome-authentication-agent-1:1590): GLib-CRITICAL **: g_once_init_leave: assertion `initialization_value != 0' failed
(npviewer.bin:1832): Gtk-WARNING **: /usr/lib/gtk-2.0/2.10.0/engines/libqtcurve.so: wrong ELF class: ELFCLASS64
dmi.bios.date: 09/07/2009
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: 1.00
dmi.board.asset.tag: No Asset Tag
dmi.board.name: Portable PC
dmi.board.vendor: TOSHIBA
dmi.board.version: Base Board Version
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: AMD
dmi.chassis.version: None
dmi.modalias: dmi:bvnInsydeCorp.:bvr1.00:bd09/07/2009:svnTOSHIBA:pnSatelliteL505D:pvrPSLV6U-00L001:rvnTOSHIBA:rnPortablePC:rvrBaseBoardVersion:cvnAMD:ct10:cvrNone:
dmi.product.name: Satellite L505D
dmi.product.version: PSLV6U-00L001
dmi.sys.vendor: TOSHIBA
To manage notifications about this bug go to:
https://bugs.launchpad.net/linux/+bug/472183/+subscriptions
Комментариев нет:
Отправить комментарий