Latest working kernel version: Never known to work. Earliest failing kernel version: 2.6.25.x Distribution: Fedora 9 Hardware Environment: Thinkpad T60p, advanced docking station with SATA drive. Software Environment: Problem Description: Thinkpad does not resume from "Suspend to RAM" when docked to a docking station that contains a SATA drive. Steps to reproduce: Put SATA drive in the docking station's drive bay, and dock T60p. Suspend to RAM, and close lid. The "crescent moon" light comes on and the T60p beeps, to indicate that it has suspended successfully. Reopen lid - the "crescent moon" light stays on and the T60p does not resume. Removing the SATA drive allows the docked T60p to suspend and resume normally. This bug can be reproduced without the fglrx module loaded, and using the radeonhd DDX Xorg driver.
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.