Thinkpad X61 tablet - resume hangs after undocking and subsequent suspend to RAM

[Roland Bless]

Binary package hint: linux-image-2.6.27-7-generic

Under Intrepid Ibex release (Ubuntu 8.10):
1.) performing a suspend to RAM after undocking from Ultrabay works (which did not under hardy), but
2.) resume (undocked) from suspend to RAM does not work, i.e., machine hangs after spin up (no flashing moon as sign of wakeup process going on)

Machine will reboot if put into docking station after step 2.

Latest Thinkpad X61 BIOS 1.20 (same behavior with old BIOS 1.09).

Probably a USB related thingy..

[Roland Bless (roland-bless)]

Suspend and resume entirely in docked state works as well as suspend and resume entirely in undocked state.
Problem seems to exist only if suspend is performed after undocking from Ultrabay.

[Constantine (constantine-redhat-bugs)]

Created attachment 324839
dock/undock event script

AFAIK undock code stopped working as of kernel 2.6.24. Searching the Internet, many other laptops are affected (IBM and Dell). It seems to be a generic Linux kernel problem -- I could not see undock work on a number of distributions (Ubuntu, Fedora, Debian) that use a kernel above 2.6.23.

I have first seen this in Fedora 9 and did not use Fedora 9 because of that.

Fedora 7 (2.6.23.17-88.fc7 kernel works without a glitch). I have written a script that I hooked to udev and it is run on dock/undock events. The script (attached) disables/enables CDROM/DVD and enables/disables CRT.

I want to stress that 2.6.23.17-88.fc7 works fine in all situations and combinations with respect to power on state (it does not matter if laptop is docked or undocked when I power it up), hotswap dock/undock, and hibernation (that is I can hibernate undocked and power on docked and it still gets dock event). I have been using it for half a year without a single glitch, regularly (each day) docking/undocking and hibernating multiple times.

I have tried fedora 10 recently. What happens if that I press the undock button, in default kernel configuration, the laptop locks up immediately. If I specify the immediate_undock=N parameter to the docking driver, the undock event is handled, and the script that disables DVD/CRT works properly as before.
However, most of the times when I dock, the dock event is not generated. Even when the dock event is generated, the USB ports on the docking station (keyboard and mice) are not reconnected (CDROM/DVD and CRT though work, thanks to the docking script).

When undocking with immediate_undock=N, the flashing green led never stops to blink (even if my undock script has finished running). With 2.6.23.17-88.fc7, the led has stopped to blink shortly after pressing the undock button.

I have also tried writing to /sys/devices/platform/dock.0/undock file from the undock script before exiting. This, however, seems to generate undock event in a loop and the script is called again and again.

[Constantine (constantine-redhat-bugs)]

Created attachment 324840
UDEV rules for dock/undock

[Constantine (constantine-redhat-bugs)]

Created attachment 324841
dock/undock helper script for CRT

[Constantine (constantine-redhat-bugs)]

I was concerned about stability of laptop features in fedora 10, but I wanted the new intel driver (to support DRI and suspend/resume). Optionally, I also wanted to test the new kernel (better wireless, wireless leds, etc.) So, I selectively upgraded the pieces (to Fedora 10 versions) to try just the new kernel and X

* pciaccess, drm, mesa, Xorg and drivers
* mkinitrd, initscripts, upstart, udev, hal, util-linux-ng SysVinit-tools alsa mdadm
* some other minot dependencies

This has allowed me to stay with Fedora 7 while testing Fedora 10 kernel and X.

While this is not a complete Fedora 10 system, I do not think it matters, judging from the Internet posts.

Again, everything works fine with Fedora 10 components and Fedora 7 kernel.

[Constantine (constantine-redhat-bugs)]

After seemingly successful dock/undock operations (either just undocking, or undocking and then docking) resuming after suspend does not work (black screen with no reaction to keyboard presses).

Same works fine with Fedoara 7 kernel and the same Xorg binaries.

[Constantine (constantine-redhat-bugs)]

I was able to find a workaround. immediate_undock=N parameter must be used and undocking script must write to /sys/devices/platform/dock.0/undock file before exiting. This will generate a new undock event, and the next invocation of undocking script must take care not to do anything except returning 0 status.

Failure to write to to /sys/devices/platform/dock.0/undock file will not complete undock properly and following dockings will result in not-operational HW as was previously described.

On the other hand, failure to take care not to execute the undocking script on the following undocking events will result in a stuck system -- undock script will run again and again.

I wonder why this undocking behavior/requirement is not documented.

I also wonder what happened with Linux undock/hotplug after kernel 2.6.23 that immediate undocking has stopped working with IBM/Lenovo thinkpads?

On my Thinkpad X61, ata_generic and pata_acpi drivers are used (not ahci) because the way the BIOS is configured. Maybe the changes are due to SATA hotplug and AHCI driver would work? I will continue testing.

It is still a regression bug, since machine locks up and it used not to.

Attached new dock/undock script makes dock/undock work again. It checks whether immediate_undock=N is set and uses lock files with time stamp to decide whether it is a first run or second "spurious" run.

Tested with kernel 2.6.27.12-170.2.5.fc10.i686.

Attached is also rc.local script that sets immediate_undock=N parameter depending on the kernel version.

[Constantine (constantine-redhat-bugs)]

Created attachment 330546
a working dock/undock event script

[Constantine (constantine-redhat-bugs)]

Created attachment 330547
rc.local script that conditionally disables immediate undocking

[Constantine (constantine-redhat-bugs)]

Correction to the comment #5 -- the built-in ata_piix driver is used by the kernel when immediate_undock=Y does not work.

I have set the BIOS to ahci mode. This caused the kernel to choose a built-in ahci driver instead. With AHCI driver, both immediate_undock=Y and immediate_undock=N work.

So, the regression is probably due to "hotplug ACPI" sata thing. If ata_piix driver is used, we get a crash with immediate_undock=Y, which is a default.

[Leann Ogasawara (leannogasawara)]

Hi Roland,

Care to test and confirm if this issue remains with the most recent pre-release of Jaunty 9.04 (currently Alpha4) - http://cdimage.ubuntu.com/releases/jaunty/ . It contains a newer 2.6.28 based kernel. You should be able to test suspend via a LiveCD. Please let us know your results.

[Constantine (constantine-redhat-bugs)]

Additional regression problem with undock is that suspend and hibernate stop working after undock. Suspend locks machine after resume and hibernate locks machine while doing the hibrentate.

This happens unless a scsi host rescan is performed before hibernation on the host to which CDROM was connected before undocking. This happens both for immediate undocking (when kernel detaches cdrom before udev is called) and for non-immediate undocking, when the acpi callback powers off cdrom and detaches it (and ultrabay if necesssary) in a proper way.

Hibernation and suspend used to work without a hitch after undock at least with 2.6.23.17-88.fc7 kernel, so it is a regression.

Attached are updated scripts that solve the hibernate and suspend problems after undock.

rc.local -- we save what the CDROM host is if we boot docked. kernel version and use of ahci driver set either immediate or non-immediate undocking.

dock/undock handler -- we support both immediate and non-immediate undocking. For non-immediate undocking, we try to power off the device and we detach it. We also try to save the CDROM scsi host before undock and after dock.

suspend/hibernate/resume acpi handler (new): a sample script to suspend/hibernate/resume -- rescans the scsi host of CDROM device before suspend/hibernate.

[Constantine (constantine-redhat-bugs)]

Created attachment 332182
updated rc.local script to set undock type and save CDROM SCSI host

[Constantine (constantine-redhat-bugs)]

Created attachment 332183
updated dock/undock event handler

[Constantine (constantine-redhat-bugs)]

Created attachment 332184
suspend/hibernate/resume script -- takes care to reset SCSI host of cdrom device

[Constantine (constantine-redhat-bugs)]

Created attachment 332185
updated suspend/hibernate/resume script

[Constantine (constantine-redhat-bugs)]

in suspend/hibernate/resume script we call to reset_cdrom_device() before doing hibernate or suspend.

The script relied on an additional lock/unlock utility to serialize calls (as a workaround against buggy ACPI that generated additional events after resume).

New attached version will run even if utility is not present.

[Constantine (constantine-redhat-bugs)]

Changed name of the bug to be more descriptive.

[Constantine (constantine-redhat-bugs)]

Created attachment 332186
updated dock/undock event handler

Ooops, the previous update was the same version.

[Ka-Hing Cheung (kahing)]

X61 don't have CDroms, the dock has one but since this requires taking the laptop out of the dock we can't use that either.

Incidentally, according to the thread which starts at http://<email address hidden>/msg01488.html , the dock's cdrom is exactly what caused this problem. Someone posted a patch there but it's for 2.6.26, (8.10 uses 2.6.27) but I can't find if that patch has been accepted or not, nor anyone reporting that they've tried that patch.

Is there a LiveUSB? The 2 side usb ports are visible after docking so I can try that if a LiveUSB version exists and suspend works with it.

[Ka-Hing Cheung (kahing)]

https://bugzilla.redhat.com/show_bug.cgi?id=473219 also seems to be the same bug.

[Bob McElrath (bob+ubuntu)]

Interesting...as it turns out, my battery finally got delivered for the dock. I've been avoiding removing it from the dock since I got it and carrying the dock around. But I just tried suspend/resume both in and out of the dock, and they both work. Perhaps someone is interested in the messages on wake. These may cause some interaction with the CD-ROM when it's installed in the dock. (attached)

Does anyone have the ultrabay HDD adapter and a HDD they can put in and try suspend/resume?

[Chuck (chuck-redhat-bugs)]

The docking code has been rewritten in 2.6.29. Can you try a kernel from koji? You will have to manually download the kernel and kernel-firmware packages and install them with rpm:

http://koji.fedoraproject.org/koji/buildinfo?buildID=82744

[Constantine (constantine-redhat-bugs)]

I have already tested kernel-PAE-2.6.29-0.99.rc4.git1.fc11.i686.rpm from rawhide.

It has the same problems.

It seems the problem is not in the undock code but in the (s)ata hotplug layer.

We have two problems here:

* immediate undock locks up machine if ata_piix is used
  (bios is in non-ahci mode)
* removal of device with
  echo 1 > /sys/class/scsi_device/${DEV}/device/delete
  followed by physical device removal will cause hibernate
  to lock if scsi host was not rescanned after physical device removal

While ata_piix may be fixed by latest updates to work with immediate undocking, I believe the second problem is not related to docking. The fact that it happens with both drivers (ahci and ata_piix) and with both immediate undocking (when kernel removes the device and callbacks do not even see it) and with non-immediate undocking (when callbacks have a chance to power off the device and remove it) and the fact that hibernate locks up in "core" code (as far as I can see) indicate a generic problem with sata subsystem. It seems that something causes suspend handlers to lock up after device was removed and scsi host was not rescanned. I do believe it stopped working after hotplug sata support. It is probably easy to fix, too.

If you think I am wrong, and there is a specific 2.6.29 kernel that fixes it, I am willing to try it. I have tried multiple times koji updates in the past looking for a solution, so it should not be a problem.

[Ka-Hing Cheung (kahing)]

I haven't tried the full script in redhat's bugzilla, but manually running the equivalent of "reset_cdrom_device()" there after undocking fixes the problem for me.

[Leann Ogasawara (leannogasawara)]

Just adding a note that the patch @kahing was referencing is already in the Jaunty 2.6.28 kernel. I've pasted the git commit id below. @kahing, if you want to try a LiveUSB I recommend using usb-creator and the latest Alpha 5 image available at http://cdimage.ubuntu.com/releases/jaunty/ . Definitely let us know your results if you test. Thanks.

commit 8b59560a3baf2e7c24e0fb92ea5d09eca92805db
Author: Shaohua Li <email address hidden>
Date: Thu Aug 28 10:02:03 2008 +0800

    ACPI: dock: avoid check _STA method

    In some BIOSes, every _STA method call will send a notification again,
    this cause freeze. And in some BIOSes, it appears _STA should be called
    after _DCK. This tries to avoid calls _STA, and still keep the device
    present check.

    http://bugzilla.kernel.org/show_bug.cgi?id=10431

    Signed-off-by: Shaohua Li <email address hidden>
    Signed-off-by: Len Brown <email address hidden>

[Ka-Hing Cheung (kahing)]

Just adding a note that I was not referencing a kernel patch at all ;-)

according to https://bugzilla.redhat.com/show_bug.cgi?id=473219#c18 an updated kernel is not enough to resolve the bug, and https://bugzilla.redhat.com/attachment.cgi?id=332186 is still needed.

[Ka-Hing Cheung (kahing)]

Note that the checkin that Leann referenced was for 2.6.28, while the RH reporter tested 2.6.29

[Ka-Hing Cheung (kahing)]

well, either my X61 doesn't like booting usb drives or usb-creator fails to create one properly, but I just can't seem to boot from usb. I am leaning towards the former because in BIOS when I configure the boot order there's a minus sign in front of USB HDD.

Anyhow, I tried! But I can't test this.

[Rogan Creswick (creswick)]

I tested this with an ultrabay hdd adapter, and the problem persists if there is a drive in the bay, but when the hdd adapter is empty, the problem goes away.

I made a bootable usb key with the latest ubuntu beta, and I does boot, but I haven't had a chance to see if it fixes the problem or not.

[Ka-Hing Cheung (kahing)]

I upgraded my thinkpad to jaunty, and it's not fixed there

[Daniel (daniel-redhat-bugs)]

Constantine Gavrilov, I suspect that you are encountering this bug:
http://bugzilla.kernel.org/show_bug.cgi?id=11703

HTH!

[Bug (bug-redhat-bugs)]

This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

[Bug (bug-redhat-bugs)]

Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Triaged a while ago but has not had any updated comments for quite some time. Please let us know if this issue remains in the current Ubuntu release, http://www.ubuntu.com/getubuntu/download . If the issue remains, click on the current status under the Status column and change the status back to "New". Thanks.

[This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]

[Saint DanBert (saintdanbert)]

My Thinkpad X61-tablet (7764CTO) has various trouble with the Ultrabase(tm) and suspend:resume.
There is a mechanical button on the left of the ultrabase for end-user to Request_Undock.
Under win-dose, this causes a request for hibernation and associated power-off shutdown.
The end-user will then separate the ultrabase and restart the system.
On restart, win-dose will announce that parts are missing (due to ultrabase disconnect)
but will wake-up in a functional state.

ANALYSIS:
This Ultrabase is a port replicator that includes various network, telephony, and USB connectors
as well as connectors for the external video monitor. In addition, there is an UltraBay(tm) for connection
of a CD or DVD or HDD drive or a secondary battery pack.

I suspect that drivers for the various USB hubs and port replications or "disk drives" do not
correctly or adequately sweep the desk during suspend and are thus is a confused state on wake.
It is my experience that "confused drivers" most often lead to something not responding or kernel panic
or both.

~~~ 0;-Dan

[Saint DanBert (saintdanbert)]

While we are on the subject of the Ultrabase(tm) and UltraBay(tm) there is "something else" going on.

The UltraBay might be used to hold either a CD/DVD drive or an HDD drive. Each drive has a custom-to-lenovo
thin profile housing. Under win-dose, the following works:

** Select the tray icon and request "remove" the CD/DVD drive
** eventually win-dose displays "Safe to remove"
** mechanically separate the drive from the UltraBase dock
** insert the HDD
** win-dose see the drive and behaves as if a USB or similar external drive was connected

The end-user can read and write the HDD.
After some time, the end use repeats the above steps requesting removal of the HDD.
They can then insert the CD/DVD and resume using the optical drive.

Under Ubuntu 8.04 LTS, 8.10, 9.04 and 10.04 LTS:
Problem #1 -- There is no way to request to remove the CD/DVD.
Problem #2 -- If one boots with the HDD, one can request removal of the drive
but a panic or system not responding happens when inserting the CD/DVD drive.
Problem #3 -- If one uses suspend-to-disk to reconfigure, the installed drive
is routinely not available after system restart. A power-off restart is required to
wake whichever device is in the UltraBase supplied UltraBay.

In short, win-dose supports the UltraBay while Ubuntu does not.

~~~ 0;-D

[Brad Figg (brad-figg)]

This bug was filed against a series that is no longer supported and so is being marked as Won't Fix. If this issue still exists in a supported series, please file a new bug.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[bojo42 (bojo42)]

This bug is at least present on lucid, so reopening seams a better idea than reporting it as "new" bug. Due to not having my dockstation at hand anymore i can't test it on newer kernels and the like.