Bug 11604
Summary: | Docked Thinkpad T60p does not wake from "suspend to RAM" if docking station has a SATA drive. | ||
---|---|---|---|
Product: | ACPI | Reporter: | Chris Rankin (rankincj) |
Component: | Power-Sleep-Wake | Assignee: | Shaohua (shaohua.li) |
Status: | CLOSED PATCH_ALREADY_AVAILABLE | ||
Severity: | normal | CC: | lenb |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.25.17, 2.6.26.5 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
Output from T60p dmidecode
Output from T60p acpidump dmesg output of 2.6.26.5 without fglrx Xorg output of failed resume with radeonhd driver dmesg output of 2.6.26.5 with fglrx, resuming OK dmesg output of 2.6.26.5 + 11 ACPI dock patches dmesg output of 2.6.26.5 + 11 ACPI dock patches, resuming OK |
Description
Chris Rankin
2008-09-20 14:45:31 UTC
Oops - it's Fedora 8, not Fedora 9. Created attachment 17918 [details]
Output from T60p dmidecode
Created attachment 17919 [details]
Output from T60p acpidump
I've tried upgrading to the 2.6.26.5 kernel now that the Catalyst 8.9 driver has been released, and the problem still exists. Created attachment 17922 [details]
dmesg output of 2.6.26.5 without fglrx
I think the most interesting part of this is:
ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: found ejectable bay
ACPI: \_SB_.PCI0.IDE0.PRIM.MSTR: Adding notify handler
ACPI: Error installing bay notify handler
Created attachment 17923 [details]
Xorg output of failed resume with radeonhd driver
I don't know if this is useful in any way.
Ironically, the laptop *has* successfully resumed *once* with the SATA drive in the docking bay - using the 2.6.26.5 kernel and the fglrx driver! However, this has not proved to be repeatable. The laptop still resumes reliably if the SATA drive is unplugged from the docking bay. Created attachment 17924 [details]
dmesg output of 2.6.26.5 with fglrx, resuming OK
OK, so this is from a tainted kernel. But this tainted kernel is WORKING (without the drive in the bay, of course).
Shaohua has a patch set which fixed a lot of dock issue. please give them a try. :) http://marc.info/?l=linux-acpi&m=121988834907742&w=2 note that there are 11 patches in all. what's the result if put sata in dock at boot time (that is not doing runtime dock/undock)? (In reply to comment #10) > what's the result if put sata in dock at boot time (that is not doing runtime > dock/undock)? Actually, I have always added and removed the SATA drive from the bay "cold". I'm not sure that it's safe to unplug "hot", not least because of the need to unmount it first. To clarify, I am not docking or undocking my laptop here either. The laptop is connected (locked!) to its docking station the whole time, and the SATA drive either is or isn't in the docking station's drive bay when I turn the power on. (In reply to comment #9) > Shaohua has a patch set which fixed a lot of dock issue. > please give them a try. :) > http://marc.info/?l=linux-acpi&m=121988834907742&w=2 > > note that there are 11 patches in all. I have needed to add the following line to drivers/acpi/osl.c in order to compile: EXPORT_SYMBOL(acpi_os_hotplug_execute); Created attachment 17952 [details]
dmesg output of 2.6.26.5 + 11 ACPI dock patches
The dmesg output now shows the kernel finding 3 dock/bay devices, and there's no indication that a handler has not been installed. However, it still fails if the docking station has a SATA drive in.
Created attachment 17953 [details]
dmesg output of 2.6.26.5 + 11 ACPI dock patches, resuming OK
I powered down, removed the SATA drive from the docking bay, and then powered up again. Here is the resulting dmesg log from a successful resume with the patched kernel.
I should point out that when the laptop failed to resume, Fedora 8 wrote nothing relating to trying to resuming into the pm-suspend.log file. Nor did the laptop beep, the crescent moon LED stayed lit, and I ended up having to power-cycle the laptop.
re-assign to Shaohua. hi, Chris, does the problem still exist in 2.6.29? (In reply to comment #17) > does the problem still exist in 2.6.29? I haven't tried 2.6.29, but the bug doesn't appear to be present in 2.6.28.9, for either suspend to RAM or suspend to disk. >but the bug doesn't appear to be present in 2.6.28.9
good. close it.
|