[regression] Dock with USB devices + suspend == resume fails

[DaveAbrahams]

A summary of the discussion so far (as of 2008/08/29):

Steps to reproduce:
1) Boot up Ubuntu while the laptop is attached to the dock.
2) Connect a USB device to a port *on the dock*.
3) Suspend-to-Ram.
4) Resume.

Result:
On resume, the hardware powers up (fans, HD, etc.), but software soon locks up hard. The screen remains black, the system is unresponsive to the keyboard, ssh doesn't work, and even the magic sysrq keys do nothing.

This behavior has been observed on these systems:
 - IBM T60p (ATI FireGL v5200) with an IBM Advanced Mini-Dock, running i386 Hardy. (Reported by DaveAbrahams)
 - Lenovo R61 7733A82 (Intel graphics) with a ThinkPad Essential Port Replicator, running amd64 Hardy. (Reported by Daniel Gnoutcheff)

The problem has been observed with these kernels:
 - 2.6.24-{16,17,18,19}-generic

These kernels do *not* have the problem:
 - 2.6.22-*-generic (i.e. Gutsy's kernels)
 - Vanilla 2.6.26.3
 - Vanilla 2.6.24

David Alexis is reporting a problem that may be a variant of this bug: he has found that if he has a USB hub plugged into the system on suspend-to-RAM, USB is unusable on resume.

The original problem report follows:

uname -a => Linux mcbain 2.6.24-16-generic #1 SMP Thu Apr 10 13:23:42 UTC 2008 i686 GNU/Linux

This is Hardy as installed from the 4/16 daily build alternate CD. I have not installed any updates yet. I have not installed fglrx.

I have made only the following configuration changes, in /etc/default/acpi-support:

  POST_VIDEO=false
  SAVE_VBE_STATE=false

Hardware: IBM T60p (ATI FireGL v5200), IBM Advanced Mini-Dock

Procedure for reproducing this bug: plug any USB device into a port *on the dock*. Suspend-to-RAM. Attempt to resume. The process freezes, presumably where it is trying to resume the device plugged into the dock.

The bug does not occur when devices are plugged directly into the laptop, even when it is docked. The bug does not occur if devices have been used in the dock ports, as long as they are all unplugged by the time resume is initiated.

Standard logs attached. Please ask if you need more.

[DaveAbrahams (boostpro)]

One further note: I tested this with a USB keyboard, a HP LaserJet 1300 printer, and a Logitech camera (I forget the model). The keyboard and the printer behaved exactly the same. When the camera was plugged in it actually failed to suspend. I haven't tested the camera in the laptop's own ports yet.

[DaveAbrahams (boostpro)]

You can suppress the reported problem by adding ehci_hcd to the MODULES list in /etc/default/acpi-support, but the result is that the USB ports on the dock don't come back after resume, so you may as well have had things plugged directly into the computer's own ports

[DaveAbrahams (boostpro)]

This problem persists with all the latest Hardy updates

[DaveAbrahams (boostpro)]

Even my trick of unloading ehci_hcd upon suspend doesn't seem to suppress the problem reliably. My Dock's USB ports are totally unusable! Very frustrating.

[DaveAbrahams (boostpro)]

This is apparently worked around by setting DOUBLE_CONSOLE_SWITCH=1 in /etc/default/acpi-support.

I still consider this a bug: suspend should work out-of-the-box. That means setting DOUBLE_CONSOLE_SWITCH=1 for *at least* anyone with a dock, and for those of us using fglrx, POST_VIDEO=false and SAVE_VBE_STATE=false, not to mention switching out of compiz before suspending.

[DaveAbrahams (boostpro)]

A little more analysis, from the person who led me to try DOUBLE_CONSOLE_SWITCH:

"If you have custom
xorg.conf rules for your input devices and don't just use /dev/mice (and
the kbd equivalent), then if you unplug one of the devices, and then
re-plug it, xorg will still be trying to use the open file-pointer from
the dead device. Normally, you'd have to restart X to get it back."

"BUT, chvt 1, chvt 7 seems to make X re-initialise all its hardware. So,
if you do this, you probably can get away with "unmounting" the keyboard."

[Daniel Gnoutcheff (gnoutchd)]

I can confirm this behavior on a Thinkpad R61 7733A82 (with Intel graphics) on a ThinkPad Essential Port Replicator while running 64-bit Ubuntu with a "USB to parallel-port-printer" accessory.

This bug also appears to be a kernel *regression*. This was not an issue in Gutsy. Now, the upgrade has left Gutsy's 2.6.22 kernel sitting around, and I find I can boot Hardy with that kernel; when I do so, this bug is not present.

DaveAbrahams: am I correct to interpret your posts as saying that the DOUBLE_CONSOLE_SWITCH workaround worked for you? It does not work for me. Frankly, I'm surprised that /etc/defaults/acpi-support would do anything, since acpi-support does not handle suspend/hibernate/resume/thaw anymore (if I understand correctly).

[DaveAbrahams (boostpro)]

Daniel Gnoutcheff: yes, it does appear to work for me, and reliably too. /etc/defaults/acpi-support does still have an effect in Hardy, at least on my machine.

[DaveAbrahams (boostpro)]

Note that there are lots of other ways to make resume fail, so your problem might lie elsewhere. For example, don't run compiz during suspend/resume (https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/197209).

[DaveAbrahams (boostpro)]

Daniel Gnoutcheff: I take it back. setting DOUBLE_CONSOLE_SWITCH isn't working for me anymore. I guess something must've been invoking the old ACPI sleep machinery?

Worse yet, I have been unable to find an equivalent two-step for pm-utils. So I'm still stuck with this one.

[DaveAbrahams (boostpro)]

Correction: I wrote "The bug does not occur if devices have been used in the dock ports, as long as they are all unplugged by the time resume is initiated." Please s/resume/suspend/

It doesn't matter at all if I unplug the devices after suspend; it still hangs.

[DaveAbrahams (boostpro)]

I don't know if this is related, but it sounds similar: http://article.gmane.org/gmane.linux.kernel/675896
On the other hand, that article seems to suggest the problem only occurs in a kernel later than Hardy's

[DaveAbrahams (boostpro)]

Actually I think I found and integrated a workaround into my solution that's attached to https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/197209

[DaveAbrahams (boostpro)]

Ugh, that failed too. My current theory is that what really matters is whether the machine is docked with USB devices connected at boot. Apparently if I boot undocked, then dock, I can suspend/resume just fine, but if I boot in the dock, suspend will fail unless I disconnect my USB devices first. I haven't tried booting docked and /then/ connecting the USB devices yet.

[Scott Moser (smoser)]

I agree with DaveAbraham's assesment above. System works very well if not docked on initial boot. "Undock -> Power On / Boot -> Dock" results in suspend/resume consistently working with or without devices attached to the dock. So at this point I have to make sure I'm disconnected from the dock when I boot.

Regarding DOUBLE_CONSOLE_SWITCH, in my experience, setting it in acpi-support has no effect on this issue. Note, also, you need to set it to 'true' for it to have any effect, '1' would not do anything. You can see this at /etc/acpi/resume.d/65-console.sh line 65:
  if [ x$DOUBLE_CONSOLE_SWITCH = xtrue ]; then

[DaveAbrahams (boostpro)]

Scott Moser: DOUBLE_CONSOLE_SWITCH doesn't do anything anymore. In fact, none of the /etc/acpi/resume.d stuff does anything. It's ridiculous that it even ships in the distro. see https://bugs.launchpad.net/ubuntu/+source/gnome-power-manager/+bug/220383

[DaveAbrahams (boostpro)]

Is anyone listening? This is really a serious problem!

[Daniel Gnoutcheff (gnoutchd)]

Assigning this report to a package. Hopefully that will get us a response ;)

[Daniel Gnoutcheff (gnoutchd)]

I think I may have found a workaround.

Try adding the line:
options libata noacpi=1

to /etc/modprobe.d/options, and then run the command:
update-initramfs -u

then reboot.

That fixes the problem for me. I found this by accident while trying to get Ultrabay hotswap working.

AFAIK, the devs are planning to have an update to put this option in by default. Apparently, libata's newfound ACPI support has been a disaster.

[DaveAbrahams (boostpro)]

Daniel, the first time I tried this it didn't appear to work, but I've now suspended and resumed many times without a hitch. So far, this is great! Thanks so much.

[Daniel Gnoutcheff (gnoutchd)]

From <https://wiki.ubuntu.com/KernelTeamBugPolicies#head-af13b59be9b1642d8c1d2462c3711b597383bbbf>:
"It also should be noted that Confirmed state should only be set by a person triaging the bug report. The bug submitter or other person experiencing the bug should not arbitrarily set Confirmed state."

I think this means we should set the status back to New, and wait for a "triager" to set to to Confirmed. Feel free to change it back even if you feel otherwise even after reading the document I linked to.

[DaveAbrahams (boostpro)]

I'm sorry to report that, at least with 2.6.24-19-generic, turning off libata's acpi in /etc/modprobe.d/options doesn't seem to be enough. If I eject the laptop from the dock once before suspending, all seems to be well (so far), but if I just boot up in the dock and suspend, I get the same old blinking cursor upon resume.

The other odd effect I'm seeing is that when resume fails, I find that my bluetooth is off when I reboot and the login screen comes up on my laptop's display instead of on the two monitors connected to my dock. The only explanation I can think of for that would be that my undocking script (which, among other things, turns off bluetooth and the external monitors) is somehow running upon suspend, but I see no evidence in the logs to support that theory.

[Daniel Gnoutcheff (gnoutchd)]

The workaround was working quite nicely with 2.6.24-18-generic. But now, 2.6.24-19-generic has broken it for me too. (And I've verified via /sys/module/libata/parameters/noacpi that the "workaround" is still enabled).

It is becoming increasingly difficult to prevent myself from flaming the developers. I'm *so* tired of this kind of thing.

[DaveAbrahams (boostpro)]

Well, it's free software, so go easy on the kerosene. That said, I wish one of the developers would at least show up (with or without flameproof suit) and acknowledge that this ticket exists!

[DaveAbrahams (boostpro)]

Changing the package assignment in the hopes this will attract a glance from the devs.

[DaveAbrahams (boostpro)]

Hmm, changing the assignment to linux-source-2.6.24 didn't work; it got automatically reset to "linux". Let's see if the HAL devs have anything to say.

[DaveAbrahams (boostpro)]

The linux-usb developers think there may be a relationship to a kernel regression: http://news.gmane.org/find-root.php?message_id=%3cloom.20080514T050845%2d477%40post.gmane.org%3e

[David Alexis (dave-alexis)]

I'm using a Dell m1330 (4GB ram, nvidia graphics, Dell wireless module) and I'm seen this problem initially with 64-bit Hardy. After trying everything suggested on the net, I installed 32-bit Hardy, and I'm having the exact same symptoms. I don't have a dock, but I'm using a USB hub that I have a keyboard and mouse plugged into.

I did some testing of different scenarios - different keyboards and mice, and different USB hubs - and can reproduce the problem very reliably. If I have any devices directly plugged into any or both of the machine's USB ports, suspend/resume work nicely (as far as USB goes anyway).

However, if I have any USB hub attached, when I suspend, USB does not work on resume. A previous poster mentioned that his issue did not occur if he resumed without the dock that was attached at suspend time. This does not work for me. As long as a hub is attached at suspend time, USB is hosed on resume.

I notice that the output of dmesg shows "USB disconnect" during resume (see below). This is consistent every time USB gets hosed on resume.

[ 2.602386] ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[ 2.605252] ata1.00: configured for UDMA/133
[ 2.606852] sd 0:0:0:0: [sda] 390721968 512-byte hardware sectors (200050 MB)
[ 2.606909] sd 0:0:0:0: [sda] Write Protect is off
[ 2.606910] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 2.606982] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 2.613191] sd 0:0:0:0: [sda] Starting disk
[ 2.680851] PM: Finishing wakeup.
[ 2.680854] Restarting tasks ... <6>usb 5-1: USB disconnect, address 7
[ 2.768433] done.
[ 2.837317] usb 7-2: USB disconnect, address 18
[ 2.837322] usb 7-2.1: USB disconnect, address 19
[ 2.965299] usb 7-2.2: USB disconnect, address

And here's something interesting... after a hosed resume, issuing the lsusb command totally locks up the console!

I'm not a kernel developer so I can't pinpoint this, but something in the USB code hates USB hubs.

[harry (harry-tti-c)]

Is there any news on this?
Last week I ran some standard update in hardy on my Thinkpad T60 which among other things installed kernel 2.6.24-20. Now I have the above problem. Suspend/resume works fine if undocked. If docked and usb-devices are attached the machine hangs on resume. However,
booting with 2.6.24-19 also has this problem now...

[DaveAbrahams (boostpro)]

Changing package again; hoping somone will notice.

[DaveAbrahams (boostpro)]

I don't know if any of the other subscribers have the resources for this, but in the thread at http://thread.gmane.org/gmane.linux.usb.general/7889, the linux-usb developers are asking for console debug info from a newer kernel. I may be able to do that myself eventually, but am a bit too pressed for at /least/ the next week. If any of you can see your way to doing the experiments they've requested, it could be great for all of us...

Thanks.

[David Alexis (dave-alexis)]

I'm sorry, but this is a little ridiculous. I read that thread, and this
guy, Alan Stern, is saying that nobody else is reporting this problem?? Has
he done the slightest bit of research into the issue?

I've been a developer for 19 years and I've seen this too many times. I'm
sorry, but its laziness on the developer's part. Everyone in the known
universe using Ubuntu is having this issue. People have supplied debugging
info over and over again. All it takes just a little initiative on the
developer(s) responsible for this code to run their own test. I get the
problem with *every* USB hub I try! Reproducing this would be as hard as
shooting fish in a barrel.

On Mon, Jul 28, 2008 at 8:46 PM, DaveAbrahams <email address hidden>wrote:

> I don't know if any of the other subscribers have the resources for
> this, but in the thread at
> http://thread.gmane.org/gmane.linux.usb.general/7889, the linux-usb
> developers are asking for console debug info from a newer kernel. I may
> be able to do that myself eventually, but am a bit too pressed for at
> /least/ the next week. If any of you can see your way to doing the
> experiments they've requested, it could be great for all of us...
>
> Thanks.
>
> --
> [regression] Dock with USB devices + suspend == resume fails
> https://bugs.launchpad.net/bugs/218760
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[DaveAbrahams (boostpro)]

David, please take a chill pill. I agree the situation is a little ridiculous, but it's not Alan Stern's fault. These people (almost certainly volunteers) are responsible for what goes into the mainline linux kernel, not what ubuntu ships, and it's understandable that they don't want to debug ubuntu's particular set of kernel patches and backports any more than we do, especially since the ubuntu people are the ones who are supposed to be responsive to bug reports against their distribution. And whether or not we agree with the linux-usb people, we're not going to get more help with this problem by antagonizing them. Since we're not paying anyone for support (I'm not, anyway) we're not really in a position to demand better service.

[David Alexis (dave-alexis)]

You're right, of course. I owe my apologies to Alan Stern and the
developers. Sorry guys. Chill pill taken, Dave. :)

On Tue, Jul 29, 2008 at 7:47 AM, DaveAbrahams <email address hidden>wrote:

> David, please take a chill pill. I agree the situation is a little
> ridiculous, but it's not Alan Stern's fault. These people (almost
> certainly volunteers) are responsible for what goes into the mainline
> linux kernel, not what ubuntu ships, and it's understandable that they
> don't want to debug ubuntu's particular set of kernel patches and
> backports any more than we do, especially since the ubuntu people are
> the ones who are supposed to be responsive to bug reports against their
> distribution. And whether or not we agree with the linux-usb people,
> we're not going to get more help with this problem by antagonizing them.
> Since we're not paying anyone for support (I'm not, anyway) we're not
> really in a position to demand better service.
>
> --
> [regression] Dock with USB devices + suspend == resume fails
> https://bugs.launchpad.net/bugs/218760
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Daniel Gnoutcheff (gnoutchd)]

Another pattern I've noticed, at least with the current kernel:

If I start up my laptop disconnected from the dock, I find that even if I later connect it to the dock, I don't get the lockups. Just something that might be worth noting in terms of trying to reproduce the crash. Note that I am still using the "libata noacpi=1" thing I described in https://bugs.launchpad.net/ubuntu/+bug/218760/comments/21 - I have not tested it yet with that option disabled.

Of course, given this bug's track record, this workaround will probably be broken in a few weeks.

~~

Anyway, I'm going to make an attempt at compiling the 2.6.26.3 kernel on this system. Here's hoping that this will help ...

[David Alexis (dave-alexis)]

I got riled up about Dave Abrahams saying that the linux-usb developers
wanted console debug info and pointed to a thread where the bug triage guy
was saying that nobody is reporting this issue. I was told to take a chill
pill, and that I can't expect the kernel devs to test Ubuntu-specific
issues.

Well, I tested this with OpenSuse 11 and guess what? Same issue! I can do
the developer's work for them and test on yet another distro, but I think I
know what the outcome will be. Sorry, this does not seem to be Ubuntu
specific. The bug reporting system is broken.

But on to something more constructive. I did yet more testing and by
removing the bluetooth kernel module as well as some others like some
Acer-specific USB module that kept loading, I finally got it to the point
where suspend/resume worked with the USB hub attached with my wireless mouse
dongle plugged into it. I did a few suspend/resume cycles to make sure it
was consistent. Then I plugged my keyboard into the USB hub and suspended.
This hosed USB on resume.

[Daniel Gnoutcheff (gnoutchd)]

Well, with the help of instructions at https://help.ubuntu.com/community/forum/software/CustomKernel, I have compiled and installed a vanilla 2.6.26.3 kernel.

I have *not* been able to reproduce this behavior with this kernel. Suspend/resume always works even when using "libata noacpi=0" (i.e. when disabling the libata trick that used to be a workaround).

I suppose the next step for me is to compile a vanilla 2.6.24 kernel; if that also works, then that would throw the suspicion on the Ubuntu-specific patches.

~~

BTW: regarding the "boot when disconnected from the dock" workaround: I have now realized that you guys discovered that long before I did. Sorry about the noise.

~~

David Alexis: are you sure we are talking about the same bug? It sounds like in your case, when you have a "hosed" resume, you are still able to do some stuff on the system - dmesg, lsusb attempts, etc. On my system, when a resume is "hosed", that's the end of it - no command prompt, no ssh, no response to even the magic sysrq keys - total lockup. If I am interpreting things correctly, DaveAbrahams is reporting the same thing.

Please correct me if I am misunderstanding your descriptions.

BTW, I completely understand your frustration. If I wasn't such a free software fanatic, I would have abandoned GNU/Linux a long time ago.

[DaveAbrahams (boostpro)]

Daniel,

* you are correct that I am experiencing the same thing as you: total
  lockup.

* I'm a bit confused about your report regarding 2.6.26.3. It sounds
  like you're saying the problem is fixed, and the old workaround
  doesn't break the fix. Is that right? If so, that would indeed be
  good news.

* Unfortunately IIUC Intrepid will be based on 2.6.26.2

* I eagerly await your 2.6.24 results.

[David Alexis (dave-alexis)]

Daniel, it's possible that what I'm seeing could be a different bug, but
based on my experience I would say its the same bug but that a dock triggers
slightly different/extra symptoms. The issue I'm seeing is reported by
others in the same threads as your total lockup issue.

I did experience the total lockup recently when I was attempting to get a
Pinnacle USB TV tuner working. As soon as I plug it in I get total lockup,
with the only way out being the "alt-sysrq" trick.

In any case, again, this could not be Ubuntu specific because I reproduced
it with Suse.

[Daniel Gnoutcheff (gnoutchd)]

I have compiled and installed a vanilla 2.6.24 kernel. I have not been able to reproduce the "hard lockup" problem with this kernel either.

~~

DaveAbrahams: your interpretation of my report is correct. So far, our problem does not appear to exist in 2.6.26.3 or vanilla 2.6.24, and it does not seem to matter if the old "libata noacpi=1" workaround is enabled or disabled.

~~

I should mention that under the new kernels, I do get a new set of regressions. Under both 2.6.26.3 and 2.6.24, the system hardlocks when resuming from hibernate (via uswsusp) unless I disable usplash. Under 2.6.24, every time I resume from suspend, the system forgets to turn the backlight on - I must do a "double console switch" to turn on the backlight. Also, under both kernels, once I have suspended the system once, it responds very slowly to the brightness keys.

I'm going to forget about the "libata noacpi=1" thing; I'm starting to think that it never really mattered. I just booted into 2.6.24-18 and I found that "libata noacpi=1" failed there too. I must have been fooled by the "boot while undocked" workaround.

~~

Well, I'm going to take a break from this bug for a few days. Here's my TODO for when I get back:
- Try to find a USB hub and see if I can reproduce David's USB problem.
- Compile a version of 2.6.24-19-generic with some debugging options enabled.
- Go from there ...

[Leann Ogasawara (leannogasawara)]

The Ubuntu Kernel Team is planning to move to the 2.6.27 kernel for the upcoming Intrepid Ibex 8.10 release. As a result, the kernel team would appreciate it if you could please test this newer 2.6.27 Ubuntu kernel. There are one of two ways you should be able to test:

1) If you are comfortable installing packages on your own, the linux-image-2.6.27-* package is currently available for you to install and test.

--or--

2) The upcoming Alpha5 for Intrepid Ibex 8.10 will contain this newer 2.6.27 Ubuntu kernel. Alpha5 is set to be released Thursday Sept 4. Please watch http://www.ubuntu.com/testing for Alpha5 to be announced. You should then be able to test via a LiveCD.

Please let us know immediately if this newer 2.6.27 kernel resolves the bug reported here or if the issue remains. More importantly, please open a new bug report for each new bug/regression introduced by the 2.6.27 kernel and tag the bug report with 'linux-2.6.27'. Also, please specifically note if the issue does or does not appear in the 2.6.26 kernel. Thanks again, we really appreicate your help and feedback.

[Daniel Gnoutcheff (gnoutchd)]

Leann,

First of all, thank you so much for you attention to this issue.

Not sure if this is what you wanted, but ...
I manually downloaded and installed (via dpkg -i) the package linux-image-2.6.27-1-generic_2.6.27-1.2_amd64.deb onto my Hardy system and rebooted.

Frankly, I can't tell if this bug is present; with 2.6.27-1-generic, resume from suspend *never* works, regardless of what I do with the dock. Whenever I attempt to resume, the system powers up, the screen flickers a tiny bit, and after 4 seconds or so, it reboots.

Looks like a new bug report is in order. But I'm guessing I should install and test Intrepid first.

~~

To answer another question: this bug does *not* appear in vanilla 2.6.26.3. It also does not appear in vanilla 2.6.24.

To make things easier to people to get up to speed with this bug, I have updated the bug description.

[David Alexis (dave-alexis)]

I installed the 2.6.27.2-generic kernel on Linux Mint 5 I my results are
similar to Daniel's. This is with OR without the USB hub and devices
plugged in. On resume, the screen is blank and it looks like the machine
locked up. But in fact, the OS is active. I had to fly blind, but I did a
ctl-F2, logged in blind, then issued a "sudo shutdown -r now" command.

So, except for the blank video, its an improvement since USB isn't hosed. :)

[DaveAbrahams (boostpro)]

I'm wondering if Ubuntu is simply ignoring this bug for Hardy. Given that Hardy is an LTS release and that the bug is not present in any vanilla kernel, it seems to me somebody should be doing more than asking us whether it's broken on intrepid.

[Leann Ogasawara (leannogasawara)]

Hi Dave,

Thanks for your comment and concern. According to the Stable Release Update policy - https://wiki.ubuntu.com/StableReleaseUpdates - we need to verify this bug is first fixed in the current development release before we can consider backporting a fix to Hardy. Since you are the original bug reporter, would you be willing to at least test the latest Intrepid RC candidate? http://cdimage.ubuntu.com/daily-live/current/ . You should be able to test suspend via a LiveCD. The Intrepid kernel was most recently rebased with the upstream 2.6.27.2 upstream stable kernel so I would hope if this is resolved with the upstream kernel it would at least be resolved with the Intrepid one. Otherwise, lets try to work together to figure out where the discrepancy is between the upstream kernel and the Ubuntu one. Thanks.

[Seth Randall (sethrandall)]

I've been running the Intrepid beta for a few weeks and suspending on the dock seems to be working okay for me with my Thinkpad T61

[David Alexis (dave-alexis)]

I second that. I tested upgrading to the beta release when it first came
out, and the suspend/resume scenarios that previously failed were working
beautifully.

On Fri, Oct 24, 2008 at 8:20 PM, Seth Randall <email address hidden> wrote:

> I've been running the Intrepid beta for a few weeks and suspending on
> the dock seems to be working okay for me with my Thinkpad T61
>
> --
> [regression] Dock with USB devices + suspend == resume fails
> https://bugs.launchpad.net/bugs/218760
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[Leann Ogasawara (leannogasawara)]

Hi Guys,

Thanks for testing and the feedback. Glad to hear it's resolved for you with Intrepid.

@DaveAbrahams, care to test the final Intrepid release and verify if it is fixed for you? We can then try to narrow down which patch to backport for Hardy - although we'll need your help with that too since you have the hardware to reproduce. Thanks.

[David Alexis (dave-alexis)]

Guys, you can't believe how happy I am with Intrepid. It feels very solid
and the display looks sharper too. But best of all, I'm now able to fully
trust the suspend/resume! I've tried all the previously failing scenarios
and more, and it works every time. Battery like is much better also.

I'll be glad to do any specific testing you need. I'll test it on all the
hardware I have.

On Fri, Nov 7, 2008 at 10:49 PM, Leann Ogasawara <email address hidden> wrote:

> Hi Guys,
>
> Thanks for testing and the feedback. Glad to hear it's resolved for you
> with Intrepid.
>
> @DaveAbrahams, care to test the final Intrepid release and verify if it
> is fixed for you? We can then try to narrow down which patch to
> backport for Hardy - although we'll need your help with that too since
> you have the hardware to reproduce. Thanks.
>
> ** Changed in: linux (Ubuntu)
> Status: New => Incomplete
>
> --
> [regression] Dock with USB devices + suspend == resume fails
> https://bugs.launchpad.net/bugs/218760
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[DaveAbrahams (boostpro)]

on Fri Nov 07 2008, Leann Ogasawara <leann-AT-ubuntu.com> wrote:

> Hi Guys,
>
> Thanks for testing and the feedback. Glad to hear it's resolved for you
> with Intrepid.
>
> @DaveAbrahams, care to test the final Intrepid release and verify if it
> is fixed for you? We can then try to narrow down which patch to
> backport for Hardy - although we'll need your help with that too since
> you have the hardware to reproduce. Thanks.

@Leann,

At the moment I'm under a crazy workload, but once the current project
is done I'll try switching to intrepid.

Thanks,

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[DaveAbrahams (boostpro)]

@Leann,

I've upgraded to intrepid and am now trying to sort out all the
changes I had to make to work around suspend problems in Hardy. I'll
let you know how this goes.

Thanks

[DaveAbrahams (boostpro)]

My initial experiments with the stock intrepid configuration files (but with fglrx installed) have shown a failure to bring back the screen on resume, although ctrl-alt-del does cause a reboot thereafter.

Will try with my .conf file edits next.

[DaveAbrahams (boostpro)]

@Leann,

I can't really tell whether I'm seeing the same bug or a different one, but I cannot get my screen to come back upon resume in Intrepid. I am able to ctrl-alt-del to restart the system, but clearly the screen isn't the only thing that hasn't come back correctly, since I can't ssh in from another machine until I've rebooted.

So, what now?

[David Alexis (dave-alexis)]

Dave, have you tried disabling bluetooth? Intrepid works great for me in
terms of this issue, but with Hardy bluetooth seemed to have been a variable
with a definite effect on my suspend/resume issues.

On Mon, Dec 15, 2008 at 6:52 AM, DaveAbrahams <email address hidden> wrote:

> @Leann,
>
> I can't really tell whether I'm seeing the same bug or a different one,
> but I cannot get my screen to come back upon resume in Intrepid. I am
> able to ctrl-alt-del to restart the system, but clearly the screen isn't
> the only thing that hasn't come back correctly, since I can't ssh in
> from another machine until I've rebooted.
>
> So, what now?
>
> --
> [regression] Dock with USB devices + suspend == resume fails
> https://bugs.launchpad.net/bugs/218760
> You received this bug notification because you are a direct subscriber
> of the bug.
>

[DaveAbrahams (boostpro)]

on Mon Dec 15 2008, David Alexis <dave.alexis-AT-gmail.com> wrote:

> Dave, have you tried disabling bluetooth?

No; not really a viable option for me as I use a BT mouse when at my
desktop.

> Intrepid works great for me in terms of this issue, but with Hardy
> bluetooth seemed to have been a variable with a definite effect on my
> suspend/resume issues.

I never noticed an effect in Hardy. Anyway, the issue affecting me
seems to be a brand new one. But for the sake of debugging, I'll try
what you suggest right now and see what happens. Did you ever report
this BT/suspend interaction to Ubuntu?

Thanks,

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[DaveAbrahams (boostpro)]

on Mon Dec 15 2008, David Alexis <dave.alexis-AT-gmail.com> wrote:

> Dave, have you tried disabling bluetooth? Intrepid works great for me in
> terms of this issue, but with Hardy bluetooth seemed to have been a variable
> with a definite effect on my suspend/resume issues.

Results: first suspend/resume worked; second one hung on resume.

--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com

[DaveAbrahams (boostpro)]

@Leann

Now that I've worked around https://bugs.launchpad.net/bugs/197209 (again!) I am getting reliable suspend/resume when I'm not docked When I get back from vacation on Jan 1st I will be able to test suspend in the dock again.

[DaveAbrahams (boostpro)]

@Leann

Happy New Year!

I'm pleased to report that Intrepid, at least with 2.6.27-10-generic (which I think may be from the backports repo?) does not show any signs of dock-related suspend problems. Now I hope someone will be able to backport the fix to Hardy for those poor souls who stuck with LTS. :)

[Leann Ogasawara (leannogasawara)]

Thanks for testing and the update Dave. I'm marking this Fix Released against Intrepid.

[cement_head (andorjkiss)]

Holy COW!

  Glad I found this bug report. This has just started happening to me. Will try the workaround and let you know. Using Hardy Heron 8.04.3 and an HP6910p laptop with docking station. Will not resume from suspend when USB mouse was plugged in, but will if unplugged before waking computer.

Any progress on backporting this fix to Hardy Heron? Using Kernel "Linux 2.6.24-24.55".

Thanks
Andor

[cement_head (andorjkiss)]

Nope. The options libata noacpi=1 solution posted by Daniel Gnoutcheff doesn't work for me.

- Andor