can't resume x60s if suspend after undock from ultrabase x6

Bug #292144 reported by nexx on 2008-11-01
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Fix Released
linux (Ubuntu)

Bug Description

Can't resume from sleep state when suspend after undock from ultrabase. Black screen

Problem description:
1- dock the lenovo x60s on the ultrabase (dvd multiburner on the ultrabay slot of the ultrabase);
2- undock from the ultrabase;
3- make it sleep. It will suspends successfully;
4- when you try to resume: black screen, no caps lock, no ctrl-alt-backspace, no ctrl-alt-f1.

- I can successfully suspend/resume it, if I did not dock it to the ultrabase after a boot.
- I can successfully suspend/resume it, if I dock, suspend/resume (while still docked).
- the problem is 100% reproductible. Happens all the time.
- confirmed on hardy and intrepid (Ubuntu 8.10).
- laptop model: ibm/lenovo thinkpad x60s (2508-A69)

In short words, case tests:
a) boot -> suspend -> resume = ok
b) boot -> dock -> suspend -> resume = ok
c) boot -> dock -> UNDOCK -> suspend -> resume = RESUME FAILS
d) boot_while_docked -> suspend -> resume = ok
e) boot_while_docked -> UNDOCK -> suspend -> resume = RESUME FAILS

Any suggestions? I can make any tests you guys ask. I'm really determined to solve this.

thanks in advance
Valentino <email address hidden>

nexx (valentinojr) on 2008-11-01
description: updated
Anthony Noto (angusthefuzz) wrote :

Thank you for taking the time to report this bug and helping to make Ubuntu better. Unfortunately we can't fix it without more information.

Please include the following additional information, if you have not already done so (pay attention to lspci's additional options), as required by the Ubuntu Kernel Team:
1. Please include the output of the command "uname -a" in your next response. It should be one, long line of text which includes the exact kernel version you're running, as well as the CPU architecture.
2. Please run the command "dmesg > dmesg.log" after a fresh boot and attach the resulting file "dmesg.log" to this bug report.
3. Please run the command "sudo lspci -vvnn > lspci-vvnn.log" and attach the resulting file "lspci-vvnn.log" to this bug report.

As you are determined to solve this problem, using the following resource will help us greatly: If you need any help, let us know. Thanks in advance!

nexx (valentinojr) wrote :

"dmesg > dmesg.log" (boot x60s undocked, then get the log)

description: updated
nexx (valentinojr) wrote :

"sudo lspci -vvnn" (boot x60s undocked, then get the log)

nexx (valentinojr) wrote :

"" output (dmesg.txt file).

According to the document, seems like the culprit is the PCI bus:

[ 2.998659] Magic number: 0:953:582
[ 2.998666] hash matches /build/buildd/linux-2.6.27/drivers/base/power/main.c:390
[ 2.998708] tty ptyc0: hash matches
[ 2.998763] pci_bus 0000:03: hash matches

nexx (valentinojr) wrote :

Linux x60 2.6.27-7-generic #1 SMP Thu Oct 30 04:18:38 UTC 2008 i686 GNU/Linux

description: updated
nexx (valentinojr) wrote :

Anthony Noto, above is all the information requested.. Let me know if you need something else..

Valentino C. Jr.

nexx (valentinojr) on 2008-11-02
description: updated
nexx (valentinojr) wrote :

Hey guys, some advance! new information!

The problem happens *ONLY* when the "dvd multiburner device adaptar" is attached to the ultrabay slot of the ultrabase. So here's what we should take in consideration now:

c) boot -> dock(dvd_multi_on_ultrabay) -> UNDOCK -> suspend -> resume = RESUME FAILS
e) boot_while_docked (dvd_multi_on_ultrabay)-> UNDOCK -> suspend -> resume = RESUME FAILS

f) boot -> dock(ultrabay_empty) -> UNDOCK -> suspend -> resume = ok
e) boot_while_docked (ultrabay_empty)-> UNDOCK -> suspend -> resume = ok

So until now, we have two facts about the problem:
- it may be pci_bus related acording to debug.txt;
- it should be related to dvd, atapi or the sata bus as the bug only happens when dvd multiburner is attached to the ultrabay slot on the ultrabase).

Let me know your opinions or suggestions


Anthony Noto (angusthefuzz) wrote :

Thanks for reporting this bug and any supporting documentation. Since this bug has enough information provided for a developer to begin work, I'm going to mark it as confirmed and let them handle it from here. Thanks for taking the time to make Ubuntu better!

Changed in linux:
assignee: angusthefuzz → ubuntu-kernel-acpi
status: Incomplete → Confirmed
Tammer Ibrahim (tammeri) wrote :

I have precisely the same symptoms, except I've got a Thinkpad x31 instead. Suspend works fine, unless I've docked my laptop in the Ultrabay with the dvd drive connected. After ejecting the dock, and attempting to resume from suspend, I get a black screen and the inability to do anything about it.

Jouni Kivilahti (j.kivilahti) wrote :

I have the exactly same hardware, same ultrabay, same dvd burner - and guess what? Same problem. I have been using a workaround, I discovered: when the laptop refuses to "unsuspend", just put it back to ultrabay. This has helped me many times. I do not carry the ultrabay with me all the time, so this causes some unpleasant surprises.

When I dock the machine, I see some hardware related messages for a fraction of a second..


nexx (valentinojr) wrote :

Hey guys, any updates on this? pretty anoying...

I'm wondering, is it related just with the SATA CD/DVD ultrabay module or it happens also with a 2nd HDD SATA ultrabay module?

Can anyone with the 2nd HDD SATA ultrabay module confirm this?


Daniel Gnoutcheff (gnoutchd) wrote :

I'm seeing what looks like very similar behavior from upstream kernels. I've filed a bug for it:

Changed in linux:
status: Unknown → Confirmed
Gregory Oschwald (osch0001) wrote :

I am also experiencing this on my X60s.

nexx (valentinojr) wrote :

Just confirmed today. Bug also happens with 2nd HDD SATA ultrabay module.

garyo (garyo) wrote :

Also happening to me on an x60s; I get a kernel crash report, not sure if you'll get it with this comment or not.

nexx (valentinojr) wrote :

Can anybody check if this bug happens in the new ubuntu release ( 9.04)?

I suspected from the cd kernel module. But the problem also occurs with the 2nd HDD SATA ultrabay module, so it must be the SATA module...

This sucks cause everytime I'll backup to the 2nd HDD SATA ultrabay module, I need to reboot.

Kernel hackers please help us!

Koopee (koopee1234) wrote :

The same problem in Jaunty, with X40 & Ultrabase X4 with CD-RW / DVD Rom ultrabay module

Koopee (koopee1234) wrote :


Seems to have solved this issue with thinkpad X40 & ultrabay X4
Instructions from here:
behind Daniel Gnoucheff's previous link

Before suspending after undocking, run

echo "0 0 0" > /sys/class/scsi_host/host1/scan

After that suspend / resume after undock works fine. Except that CD-Rom drive seems not to be recognized automatically when docked again.

Koopee (koopee1234) wrote :

Still spamming...
 Got the CD-Rom drive working by issuing the same
echo "0 0 0" > /sys/class/scsi_host/host1/scan

 - command again after docking.

So, my undock procedure is as follows:

1. echo 1 > /sys/class/scsi_device/1\:0\:0\:0/device/delete
     # Remove CD-Rom ultrabay drive and prevent lockup when removing the computer from ultrabase
2. Push undock button at the dock

3. *** Undock by pulling lever

4. echo "0 0 0" > /sys/class/scsi_host/host1/scan
    # Prevents lockup at suspend / resume

Docking procedure:
1. Dock computer
2. echo "0 0 0" > /sys/class/scsi_host/host1/scan
    # Get CD-Rom drive back to alive.

Changed in linux:
status: Confirmed → Fix Released
nexx (valentinojr) wrote :

Sorry Koopee, but this bug still affects our X60s. It's been almost one year since I reported the bug. Does anybody have figured out a solution?

nexx wrote:
> Sorry Koopee, but this bug still affects our X60s. It's been almost one
> year since I reported the bug. Does anybody have figured out a solution?

I believe that this bug has been fixed upstream:;a=commit;h=0d9e6659a1bde3733cfd0072adbb3514b579e383

2.6.31-rc1 is the first upstream kernel to have this fix.

You may want to look into installing a bleeding-edge kernel to see if
this bugfix does it for you.

Maybe this could help:
(Haven't tried it myself, I compile my own kernels from upstream source.)

Raphaël HALIMI (raph) wrote :

Hi, although not exactly the same bug, this one is related to 189185, 242638 and 369131, and I made a little script as a workaround for these three bugs, but it also includes the fix for this.

Changed in linux:
importance: Unknown → High
Jeremy Foshee (jeremyfoshee) wrote :

Marking Released as this should have made it in to the kernel via rebase or stable update. If this is still an issue, I need the Original Reporter to reopen and provide logs from the current release.



Changed in linux (Ubuntu):
assignee: Ubuntu Kernel ACPI Team (ubuntu-kernel-acpi) → nobody
status: Confirmed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.