USB freezes/resets during suspend

[Nick B.]

Something causes the drive to basically
freeze up and become unresponsive when it tries to suspend. It looks
like it may be caused by the USB reset right before it tries to sync()
the file systems. I've tested another USB hard drive I have and there is
no USB reset messages before it syncs the file systems.

When I suspend the system, it sits for 15-30 seconds on a blank screen
before it actually starts the suspend process. That long wait only
happens when this drive is attached. And upon resuming the drive
disappears from the system and is not accessible because the drive is
basically in a frozen state.

I never had this or any other problem suspending with this drive
attached in previous Ubuntu releases. It worked perfectly in Intrepid
and Jaunty so this is a regression in Karmic.

ProblemType: Bug
Date: Sun Oct 25 00:18:20 2009
DistroRelease: Ubuntu 9.10
LiveMediaBuild: Kubuntu 9.10 "Karmic Koala" - Release Candidate amd64 (20091020.2)
Package: libatasmart4 0.16-1
ProcEnviron:
 LANGUAGE=
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-14.48-generic
SourcePackage: libatasmart
Uname: Linux 2.6.31-14-generic x86_64

[Martin Pitt (pitti)]

Does thaht also happen in non-JMicron mode, with "sudo skdump /dev/sdc"? libatasmart does not seem to use jmicron mode for your particular drive.

[Martin Pitt (pitti)]

In other words, do you get these kernel errors when you use the drive normally?

[Nick B. (futurepilot)]

Under normal use, no, there are no errors.

$ sudo skdump /dev/sdc
Device: sat12:/dev/sdc
Type: 12 Byte SCSI ATA SAT Passthru
Size: 476940 MiB
Awake: Operation not supported
ATA SMART not supported.

However, I do get a USB reset with this drive when I suspend the system. Is it possible that it may be doing SMART probing on suspend? Or would that be an unrelated issue?

[Martin Pitt (pitti)]

Nick B. [2009-10-27 17:59 -0000]:
> Under normal use, no, there are no errors.

Ah, good. Then I doubt that we will need this blacklisting.

> However, I do get a USB reset with this drive when I suspend the system.
> Is it possible that it may be doing SMART probing on suspend? Or would
> that be an unrelated issue?

Can you please attach /var/log/kern.log after a complete
suspend/resume cycle? I think that will be fairly normal, since
suspending involves powering down the USB ports, so your drives will
naturally have to do an USB reset after resuming.

Does it behave erratic in any way? (Please note that you shouldn't
keep removable drives mounted during suspend; that's a known
shortcoming of the Linux kernel. On the other hand it's been a while
since I tried it the last time).

[Nick B. (futurepilot)]

I had to take this log from a different computer, but the problem
happens on every computer I've tried.

Yes, it does behave erratic. Something causes the drive to basically
freeze up and become unresponsive when it tries to suspend. It looks
like it may be caused by the USB reset right before it tries to sync()
the file systems. I've tested another USB hard drive I have and there is
no USB reset messages before it syncs the file systems.

When I suspend the system, it sits for 15-30 seconds on a blank screen
before it actually starts the suspend process. That long wait only
happens when this drive is attached. And upon resuming the drive
disappears from the system and is not accessible because the drive is
basically in a frozen state.

I never had this or any other problem suspending with this drive
attached in previous Ubuntu releases. It worked perfectly in Intrepid
and Jaunty so this is a regression in Karmic.

[Martin Pitt (pitti)]

Nick B. [2009-10-28 0:34 -0000]:
> I had to take this log from a different computer, but the problem
> happens on every computer I've tried.
>
> Yes, it does behave erratic. Something causes the drive to basically
> freeze up and become unresponsive when it tries to suspend.

Does blacklisting the drive from smart probing really help? To find
out, please do

  echo 'ATTRS{idVendor}=="152d", ATTRS{idProduct}=="2329", ENV{ID_ATA_SMART_ACCESS}="none"' | sudo tee /etc/udev/rules.d/blacklist.rules

Then reboot and check suspend/resume.

I doubt that it will help, but let's be sure about it.

Thanks!

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Nick B. (futurepilot)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Martin Pitt wrote:
> Nick B. [2009-10-28 0:34 -0000]:
>> I had to take this log from a different computer, but the problem
>> happens on every computer I've tried.
>>
>> Yes, it does behave erratic. Something causes the drive to basically
>> freeze up and become unresponsive when it tries to suspend.
>
> Does blacklisting the drive from smart probing really help? To find
> out, please do
>
> echo 'ATTRS{idVendor}=="152d", ATTRS{idProduct}=="2329",
> ENV{ID_ATA_SMART_ACCESS}="none"' | sudo tee
> /etc/udev/rules.d/blacklist.rules
>
> Then reboot and check suspend/resume.
>
> I doubt that it will help, but let's be sure about it.
>
> Thanks!
>
You're right, that didn't change anything.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJK6JaMAAoJEIltSrFpUGtezkEIAJfKnvd9saauC43DRty+cGMR
YkkwddwbQRI7gcqCYQhJRwE459R9+CYPyk/agj6uS5Sk7A5U7N8ewfLx3lOARha6
3Nsd/l9tr4zYAuiiUFDURISkaFpYyFjic6tRfQ8RwskzAojWmwmZxRVW3aAHn/kx
JhZMmjUKp/JYIMkTvK1UBPT8wFR+CCzQJ/HzrwebpnfE/+inpVkoL4x1o2g+4IBI
+w0xX4MYsOJ6uP1OOj2fkauMbwyZqZRtKif+mYNIpMqRJEaetSz3Wv0Au2UXMGnC
m/oOsEHcH3lLv5MxJ5oz0mlhpynx69YiVO+lYQX4hAtVrY9Sopmk5dDGots9xLk=
=Wuy8
-----END PGP SIGNATURE-----

[Nick B. (futurepilot)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

I disassembled the enclosure of the drive to discover there's nothing
really special about the setup. It's a standard Seagate Barracuda SATA
hard drive hooked up to a SATA to USB adapter which also regulates the
power to the drive such as powering down the drive when it detects the
computer was shutdown/suspended/hibernated. I was able to hook this
adapter up to another SATA hard drive and reproduce the problem which
leads me to believe that it isn't the drive itself freezing up, but
the SATA to USB adapter. Unfortunately, there's not a whole lot of
information on this adapter that I could find.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJK7+uaAAoJEIltSrFpUGteqJAIAK0nArpGOHZ0fi5WlEeIe85/
RXaIOkRwzaus+THKIV+tYr88HEk3tW9+SfFJL2RxzSX1xq5lew3xwCSbQVHXnd+D
jFNJdYEeH0d4P1w/yn5u1txE/d73QTfUItnFn36HIT+rOWSRzytoAGDWO0qcy8q/
KA/tUwsap6p5EqmPfupIFwKjwssWuBb+dKLJ8N+llpf0VZGQMpLZaj5sRqnGwm3U
s6Mv6aMyk22tWarAXD5sPubkhziL5HRfFyZ7gQib1VG/7XGgnFJ6CQZccCw/w+BM
JiBXcfNIUNs7Gi81JKEqa0yM3afbsO3qHlaI6WOllTevsDyHtcKLE5+hngHkg2M=
=2+rR
-----END PGP SIGNATURE-----

[Nick B. (futurepilot)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

tag regression-release
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJK9GmdAAoJEIltSrFpUGte2EIH/3CLySQtPAnUzKLm8OFHW3fK
e6qRzJ0QwXi5ljPyguh06EByuA3xeEaabATN99f2vbD/Iu+mAeNWgHW9/tLCBgvO
PlqGydzOMhoN/5xakjQjiiGpEk5/672uyRooP5UeMtaNmuqKxCNVNnaSU6gyfxRt
u1eDnRmU2AMngGUweayvVkTL9lL/payUeg4XY/iiqBOFcosrihemXcuTthIxs9gH
4qNC+RWhh0onSBMU1fYvN7X2OiBJLSBGmW6WCWAiRDBsE3TMtXx9MW8qxaSd+kra
dJSCjJd0UU9hoJQHz6k6jcd5rEsP1Gam/zPewNDyG6tqtoahxelYr7ER8DntVQ8=
=ZkSd
-----END PGP SIGNATURE-----

[Nick B. (futurepilot)]

Still happening on Lucid.

[Jeremy Foshee (jeremyfoshee)]

Hi Nick,

If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.

Thanks in advance.

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

[Nick B. (futurepilot)]

On 04/21/2010 09:34 PM, Jeremy Foshee wrote:
> Hi Nick,
>
> If you could also please test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. Please let us know your results.
>
> Thanks in advance.
>
> [This is an automated message. Apologies if it has reached you inappropriately; please just reply to this message indicating so.]
>
>
> ** Tags added: kernel-suspend
>
> ** Tags added: needs-upstream-testing
>
> ** Tags added: kj-triage
>
> ** Changed in: linux (Ubuntu)
> Status: New => Incomplete
>
>

This problem seems to have been fixed upstream at some point. It works
fine with 2.6.34rc5.

[Jeremy Foshee (jeremyfoshee)]

This bug report was marked as Incomplete and has not had any updated comments for quite some time. As a result this bug is being closed. Please reopen if this is still an issue in the current Ubuntu release http://www.ubuntu.com/getubuntu/download . Also, please be sure to provide any requested information that may have been missing. To reopen the bug, 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.]