Suspend wakes right back up

[ill]

in xubuntu 12.10, attempting to suspend causes the machine to attempt to suspend, but the fans never go off and after about 30 seconds, the screen comes back on:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1065840/+attachment/3760398/+files/log

[Ubuntu Foundations Team Bug Bot (crichton)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. It seems that your bug report is not filed about a specific source package though, rather it is just filed against Ubuntu in general. It is important that bug reports be filed about source packages so that people interested in the package can find the bugs about it. You can find some hints about determining what package your bug might be about at https://wiki.ubuntu.com/Bugs/FindRightPackage. You might also ask for help in the #ubuntu-bugs irc channel on Freenode.

To change the source package that this bug is filed about visit https://bugs.launchpad.net/ubuntu/+bug/1065840/+editstatus and add the package name in the text box next to the word Package.

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

[Fabio Marconi (fabiomarconi)]

Oct 12 00:42:29 htpc kernel: [ 53.856263] ata8.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Oct 12 00:42:29 htpc kernel: [ 53.856265] ata8.00: failed command: STANDBY IMMEDIATE
Oct 12 00:42:29 htpc kernel: [ 53.856270] ata8.00: cmd e0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
Oct 12 00:42:29 htpc kernel: [ 53.856270] res 40/00:00:00:00:00/00:00:00:00:00/40 Emask 0x4 (timeout)
Oct 12 00:42:29 htpc kernel: [ 53.856271] ata8.00: status: { DRDY }
Oct 12 00:42:29 htpc kernel: [ 53.856276] ata8: hard resetting link
Oct 12 00:42:29 htpc kernel: [ 53.856277] ata8: nv: skipping hardreset on occupied port
Oct 12 00:42:29 htpc kernel: [ 54.324031] ata8: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
Oct 12 00:42:29 htpc kernel: [ 54.340196] ata8.00: configured for UDMA/100
Oct 12 00:42:29 htpc kernel: [ 54.340199] ata8.00: device reported invalid CHS sector 0
Oct 12 00:42:29 htpc kernel: [ 54.340210] ata8: EH complete
Oct 12 00:42:29 htpc kernel: [ 54.340223] sd 7:0:0:0: >[sda] START_STOP FAILED
Oct 12 00:42:29 htpc kernel: [ 54.340225] sd 7:0:0:0: >[sda]
Oct 12 00:42:29 htpc kernel: [ 54.340226] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Oct 12 00:42:29 htpc kernel: [ 54.340227] sd 7:0:0:0: >[sda]
Oct 12 00:42:29 htpc kernel: [ 54.340228] Sense Key : Aborted Command [current] [descriptor]
Oct 12 00:42:29 htpc kernel: [ 54.340231] sd 7:0:0:0: >[sda]
Oct 12 00:42:29 htpc kernel: [ 54.340232] Add. Sense: No additional sense information
Oct 12 00:42:29 htpc kernel: [ 54.340246] dpm_run_callback(): scsi_bus_suspend+0x0/0x20 returns 134217730
Oct 12 00:42:29 htpc kernel: [ 54.340249] PM: suspend of drv:sd dev:7:0:0:0 complete after 30555.449 msecs
Oct 12 00:42:29 htpc kernel: [ 54.340254] PM: Device 7:0:0:0 failed to suspend async: error 134217730
Oct 12 00:42:29 htpc kernel: [ 54.340290] PM: Some devices failed to suspend

Seems that the hard disk is in a bad state, can you analize it with a diagnostic tool ?
Thanks
Fabio
---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[ill (illumilore)]

What tool should I use? Palimpsest gives no smart errors when I check with that .

[Eric_DL (edelare)]

Exact same problem here with freshly installed Ubuntu Studio 12.10.
Installed all 169 updates + new kernel right after install from dvd => version is now :

Linux version 3.5.0-21-lowlatency (buildd@allspice) (gcc version 4.7.2 (Ubuntu/Linaro 4.7.2-2ubuntu1) ) #19-Ubuntu SMP PREEMPT Tue Dec 18 18:37:29 UTC 2012 (Ubuntu 3.5.0-21.19-lowlatency 3.5.7.1)

I previously had Ubuntu Studio 10.10 installed on same hardware and it did not have problem to suspend, problems came with 12.10 : I can neither suspend (suspend process gives up and machine comes back on after 30s timeout), nor shutdown properly (have to force stop with power button).

Common hw/drivers with original syslog posted by ill :
- sata_nv and snd_hda_intel (NVidia chipset) => mine is MCP55 Pro (Tyan S2915 mobo)
- NVidia graphics card (I'm using nvidia's driver instead of nouveau) => mine is 9600GT

My machine hosts 4 hard drives among which 2 seem to stop and the other 2 refuse to stop.
My syslog (at end of post below) displays the same "invalid CHS sector 0" for 3 of the 4 drives, including the system drive.

Maybe the "FLUSH CACHE EXT" error on the system disk, preceding the "invalid CHS sector 0" error, is due to the fact that the system disk is an HP-labeled server disk and not a regular one.

But, the fact is that the 2 disks (scsi4 and scsi10) that fail to stop exhibit the same "START_STOP FAILED" error, and after a bit of searching through the logs, it appears that they are the only 2 disks that are not partitioned.
I formatted them from Ubuntu Studio 10.10 as whole ext4 volumes and they seem to hold no partition table at all, as they both cause an "unknown partition table" warning during boot.

Once boot is finished, they are nevertheless mountable and writable, as removable disks (they do not hold any system data).

One more info : before formatting under Ubuntu 10.10, both of these drives were exhaustively analyzed with "badblocks" tool in write mode (yes, I tend to be a little paranoid about bad sectors by now) and neither SMART, nor "badblocks" detected any problem.

My best guess for filing this bug would be sata_nv or pm-utils packages.

Extract from syslog :
Jan 6 20:36:08 mrblack kernel: [ 1020.308371] PM: Syncing filesystems ... done.
Jan 6 20:36:08 mrblack kernel: [ 1020.317152] PM: Preparing system for mem sleep
Jan 6 20:36:08 mrblack kernel: [ 1020.317169] Freezing user space processes ... (elapsed 0.01 seconds) done.
Jan 6 20:36:08 mrblack kernel: [ 1020.329154] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
Jan 6 20:36:08 mrblack kernel: [ 1020.340148] PM: Entering mem sleep
Jan 6 20:36:08 mrblack kernel: [ 1020.340172] Suspending console(s) (use no_console_suspend to debug)
Jan 6 20:36:08 mrblack kernel: [ 1020.340771] sd 10:0:0:0: [sdh] Synchronizing SCSI cache
Jan 6 20:36:08 mrblack kernel: [ 1020.340954] sd 10:0:0:0: [sdh] Stopping disk
Jan 6 20:36:08 mrblack kernel: [ 1020.341476] sd 5:0:0:0: [sdc] Synchronizing SCSI cache
Jan 6 20:36:08 mrblack kernel: [ 1020.341605] sd 5:0:0:0: [sdc] Stopping disk
Jan 6 20:36:08 mrblack kernel: [ 1020.341627] sd 4:0:0:0: [sdb] Synchronizing SCSI cache
Jan 6 20:36:08 mrblack kernel: [ 1020....

[Joe Sapp (sappj)]

Is this related to https://bugzilla.kernel.org/show_bug.cgi?id=48951 ? It looks like it is...you might want to give the following code a try to see if you can suspend after disabling async suspend for the scsi target:

echo disabled > /sys/devices/pci0000:00/0000:00:0e.0/ata1/host0/target0:0:0/power/async
echo mem > /sys/power/state

[ill (illumilore)]

Would the storage system being a ssd instead of hdd matter?

there doesn't seem to be a folder named "ata1" in 0000:00:0e.0.

/sys/devices/pci0000:00/0000:00:0e.0$ ls
0000:00:0e.0:pcie08 dma_mask_bits msi_bus resource
0000:02:00.0 driver msi_irqs subsystem
0000:02:00.1 enable numa_node subsystem_device
broken_parity_status firmware_node pci_bus subsystem_vendor
class irq power uevent
config local_cpulist remove vendor
consistent_dma_mask_bits local_cpus rescan
device modalias reset

[Joe Sapp (sappj)]

Maybe, I'm not sure how that directory structure works. Check other directories in /sys/devices/pci0000:00 .
This may only work with "CONFIG_PM_ADVANCED_DEBUG=y" in your kernel.

[Eric_DL (edelare)]

Hi all,

ill, if you type

ls -al /sys/block

in a terminal, you should get a list of symlinks referencing all block devices registered on your machine.
From which you find the bus addresses of your actual hard drives (for example on my machine) :

lrwxrwxrwx 1 root root 0 2013-01-19 19:43 sde -> ../devices/pci0000:00/0000:00:05.0/host4/target4:0:0/4:0:0:0/block/sde/
lrwxrwxrwx 1 root root 0 2013-01-19 19:43 sdf -> ../devices/pci0000:00/0000:00:05.1/host6/target6:0:0/6:0:0:0/block/sdf/
lrwxrwxrwx 1 root root 0 2013-01-19 19:43 sdg -> ../devices/pci0000:00/0000:00:05.1/host7/target7:0:0/7:0:0:0/block/sdg/
lrwxrwxrwx 1 root root 0 2013-01-19 19:43 sdh -> ../devices/pci0000:00/0000:00:05.2/host8/target8:0:0/8:0:0:0/block/sdh/

(Note : this list is from my Ubuntu 10.10, on 12.10, you should see an intermediate "ataX" level before "hostX").

From there you should recognize your hard disk and find the right path for the async file mentioned by Joe earlier.

Anyway, what I wanted to say here is that the hierarchy present in /sys is the result of machine hardware enumeration done by the kernel at boot, hence the pseudo-files we can see there are totally dynamic and volatile (as those in /proc for instance).
Which means forcing any value here won't survive a reboot.

Trying to force disable async suspend on some devices is a workaround, but I really think the bug doesn't come from async suspend itself, because it has been there for some time.
It's just some change in its behaviour that's causing our problems.

I'll develop that in next post for the sake of clarity.

[Eric_DL (edelare)]

Joe, I think we're clearly dealing with the same bug as yours #48951.

From what I've found on people having this same problem :

-> Joe's bug #48951 on the kernel tracker (+ the various contributors on it)
-> here : http://forums.fedoraforum.org/showthread.php?t=283005
-> here : https://bugs.archlinux.org/task/31833
-> here : http://forums.opensuse.org/english/get-technical-help-here/applications/479271-suspend-s2ram-issues-12-2-nvidia-platform.html
-> and here : http://www.linux.org.ru/forum/linux-hardware/8359386

... I've noticed that all these people had one thing in common in their hardware : an NVidia chipset => sata_nv driver.

Some other people share the "Some devices failed to suspend" error message, but on other devices. The non stopping hard drives case seems to happen, AFAIK, only on NVidia chipsets.

In my case, as I previously described in my (too long) first post, behavior is even weirder :
- one machine with 4 hdd
- Ubuntu Studio 10.10 x64 installed on one physical disk (Hitachi 160GB)
- Ubuntu Studio 12.10 x64 installed on another one (HP-labeled VB0250EAVER 250GB - origin Seagate)
- suspend works OK when booted from 10.10 (see attached log)
- only one disk enters suspend when booted from 12.10 (the one holding 10.10 install), the others fail to suspend (see second log after this post .... sorry machine renamed in 12.10 install)

Note: the "FLUSH CACHE EXT" error on the HP disk may be due to a firmware bug. I'll try to update HP firmware to at least get this bug out of the way, so don't take this error into account for now .... although I find it really hard to believe that a firmware bug could be OS-dependent !

Well, gathering all this, I'd say that the problem lies in the sata_nv driver, either the way sata_nv interprets PM requests or the way sata_nv talks to disks.

I've found no matching package name for potential affectation of the bug, is sata_nv maintained directly by NVidia ?

[ill (illumilore)]

I found the proper async file and changed it to disabled, which caused the system to stay suspended. However, it seems like my SSD doesn't want to stay in the same directory, and changes after reboots. It was in .../pci0000:00/0000:00:05.2/ata8/host7/target7:0:0/... but now has changed to .../pci0000:00/0000:00:05.2/ata10/host9/target9:0:0/...
How do I make async stay disabled if the directory changes?

What is the difference between the async in
/sys/devices/pci0000:00/0000:00:05.2/ata10/host9/target9:0:0/9:0:0:0/block/sda/power
vs the async in
/sys/devices/pci0000:00/0000:00:05.2/ata10/host9/target9:0:0/power
?

[Joe Sapp (sappj)]

It's not supposed to be a permanent fix (i.e., one that you can make on every boot), it's supposed to be a way of debugging the problem. If you take a look at the kernel bug I linked to, there's a kernel commit that you could revert that supposedly addresses this issue.

With that said, I don't know the answer to your questions. I imagine the "directory" in /sys is created as devices come online and are registered at boot, which don't always happen in the same order. And I think the difference between those two "directories" are the device buses.

[remaker (remaker)]

I have a similar immediate wakeup issue:

[ 7951.156318] PM: Syncing filesystems ... done.
[ 7951.170491] PM: Preparing system for mem sleep
[ 7951.186366] Freezing user space processes ... (elapsed 0.01 seconds) done.
[ 7951.200152] Freezing remaining freezable tasks ... (elapsed 0.01 seconds) done.
[ 7951.216109] PM: Entering mem sleep
[ 7951.216130] Suspending console(s) (use no_console_suspend to debug)
[ 7951.216677] sd 0:0:0:0: [sda] Stopping disk
[ 7951.216854] ata1.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x0
[ 7951.216857] ata1.00: failed command: STANDBY IMMEDIATE
[ 7951.216864] ata1.00: cmd e0/00:00:00:00:00/00:00:00:00:00/a0 tag 0
[ 7951.216864] res 51/04:00:00:00:00/00:00:00:00:00/a0 Emask 0x1 (device error)
[ 7951.216865] ata1.00: status: { DRDY ERR }
[ 7951.216867] ata1.00: error: { ABRT }
[ 7951.216876] ata1.00: device reported invalid CHS sector 0
[ 7951.216894] sd 0:0:0:0: [sda] START_STOP FAILED
[ 7951.216896] sd 0:0:0:0: [sda]
[ 7951.216897] Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[ 7951.216899] sd 0:0:0:0: [sda]
[ 7951.216900] Sense Key : Aborted Command [current] [descriptor]
[ 7951.216903] sd 0:0:0:0: [sda]
[ 7951.216905] Add. Sense: No additional sense information
[ 7951.216916] dpm_run_callback(): scsi_bus_suspend+0x0/0x20 returns 134217730
[ 7951.216920] PM: Device 0:0:0:0 failed to suspend: error 134217730
[ 7951.216921] PM: Some devices failed to suspend
[ 7951.476689] PM: resume of devices complete after 259.763 msecs
[ 7951.476831] PM: resume devices took 0.260 seconds
[ 7951.476884] PM: Finishing wakeup.

This is an old old Compaq V2000 with IDE. I an using an IDE to SD converter to have a "flash drive" of sorts. (slow, but stable!)

Relevant ATA startup. I am running the OS from what it thinks is a "removable" disk.

[ 2.062741] scsi0 : pata_atiixp
[ 2.066210] scsi1 : pata_atiixp
[ 2.067047] ata1: PATA max UDMA/100 cmd 0x1f0 ctl 0x3f6 bmdma 0x8410 irq 14
[ 2.067050] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x8418 irq 15
[ 2.096151] ssb: Found chip with id 0x4318, rev 0x02 and package 0x02
[ 2.096166] ssb: Core 0 found: ChipCommon (cc 0x800, rev 0x0D, vendor 0x4243)
[ 2.096176] ssb: Core 1 found: IEEE 802.11 (cc 0x812, rev 0x09, vendor 0x4243)
[ 2.096185] ssb: Core 2 found: PCI (cc 0x804, rev 0x0C, vendor 0x4243)
[ 2.096195] ssb: Core 3 found: PCMCIA (cc 0x80D, rev 0x07, vendor 0x4243)
[ 2.136166] ssb: Sonics Silicon Backplane found on PCI device 0000:05:02.0
[ 2.229220] ata2.00: ATAPI: HL-DT-STCD-RW/DVD DRIVE GCC-4244N, 1.02, max MWDMA2
[ 2.229325] ata1.00: CFA: Memory Card Adapter, 67281306, max UDMA/66
[ 2.229328] ata1.00: 63272960 sectors, multi 0: LBA
[ 2.229333] ata1.00: limited to UDMA/33 due to 40-wire cable
[ 2.236726] ata1.00: configured for UDMA/33
[ 2.236875] scsi 0:0:0:0: Direct-Access ATA Memory Card Adap 6728 PQ: 0 ANSI: 5
[ 2.237165] sd 0:0:0:0: [sda] 63272960 512-byte logical blocks: (32.3 GB/30.1 GiB)
[ 2.237216] sd 0:0:0:0: [sda] Write Protect is off
[ 2.237220] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
[ 2.237244] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn'...

[bluenova (bluenova)]

I think the bug description needs changing, this effects me on Ubuntu (Unity) it's not just an xUbuntu thing. I get the same errors in kern.log and I'm also using Nvidia drivers.

Interestingly I can suspend, sometimes. About 1 in 5 goes it will fully suspend.

[Eric_DL (edelare)]

Last security updates from Ubuntu turned kernel to version 3.5.0-23-lowlatency => no change in behavior, still can't suspend.

To add some more frustration, HP's firmware upgrade tools won't work : message is "unsupported drive" although my drive has the exact reference covered by the upgrade :-[

I feel powerless, simply posting details here and waiting for some new kernel release to magically solve the issue.
Plus this bug doesn't seem to affect many people and it's still unassigned after four months.

How can I set kernel and/or sata_nv module to debug to get some insight of what's going wrong when I suspend ?

[David Tombs (dgtombs)]

Hi all,

This is almost certainly a kernel issue and anybody experiencing it should file an _individual_ report with 'ubuntu-bug linux'.

Thanks!

---
Ubuntu Bug Squad volunteer triager
http://wiki.ubuntu.com/BugSquad

[Joe Sapp (sappj)]

There's a udev rule in one of the comments on the kernel bug. A thread has also been started on the linux-ide mailing list: http://marc.info/?l=linux-ide&m=136297331308023&w=2

[Joe Sapp (sappj)]

Seems like kernel devs can't do anything about it without help from NVIDIA, which they aren't getting. So I think we're left with using a udev rule.

[Eric_DL (edelare)]

Thanks very much Joe for keeping us posted on that bug.
I created the udev rule and it seems to work.

I say "seems to work" because I actually found I was having 2 different problems at the same time :

1- this sata_nv bug
2- a vendor tuned (and bugged) firmware on my Ubuntu 12.10 boot disk (HP VB0250EAVER 250GB hard drive), that kernel seems unable to manage as a boot disk

But wait .... it got worse ...

HP's firmware update for THAT SPECIFIC DRIVE refused to update mine, with an unbelievable "drive not supported" message.

Seeing that one of HP's changes in that new firmware was disabling write cache by default, it occured to me that maybe kernel couldn't stop that boot drive because it couldn't flush that cache ... OK, let's turn that thing off at boot time with hdparm !

BANG ... another bug (Ubuntu bug) : hdparm.conf stanza not executed when disk name mentioned is a symlink and not the explicit device file !
There we go, information search, loads of googling, forums reading, posting bug on Launchpad, etc .... to finally get an answer a few days ago : you're experiencing bug #222458, just fixed with 13.04 release.

Fix not back-ported to 12.10 => port fix myself or update to 13.04 => fix being actually a 6 lines add in a script, I fixed it manually => drive finally comes up with write cache off as expected .... but that damn thing still won't suspend or reboot !
So there I was, back to square one.

Then I observed more carefully hdparm identification report for this drive and discovered really weird messages :

    Model=VB0250EAVER, FwRev=HPG0, SerialNo=9VMTTK1M
    .......
    BuffType=unknown, BuffSize=8192kB, MaxMultSect=16, MultSect=off
    .......
    Drive conforms to: unknown: ATA/ATAPI-4,5,6,7

So I finally decided to do myself a favor and dump that crap.

I'll post here if the udev rule trick is working when I have installed a more classic hard drive as 12.10 boot disk.

BOTTOM LINE : never try to recycle vendor specific hard drives as boot disks, never again a motherboard with an nvidia chipset.

[papukaija (papukaija)]

Thank you for taking the time to report this bug and helping to make Ubuntu better. This bug did not have a package associated with it, which is important for ensuring that it gets looked at by the proper developers. You can learn more about finding the right package at https://wiki.ubuntu.com/Bugs/FindRightPackage . I have classified this bug as a bug in linux.

When reporting bugs in the future please use apport by using 'ubuntu-bug' and the name of the package affected. You can learn more about this functionality at https://help.ubuntu.com/community/ReportingBugs.

[Eric_DL (edelare)]

Just in case it might help someone else, here's a wrapup of the final status for my issues.

Intent : migrate from "Ubuntu Studio x64 10.10" to "Ubuntu Studio x64 12.10" (both installed, on distinct HDDs)

System specs : Tyan s2915 (non-E) motherboard, Tyan BIOS v3.00, MCP55 Pro chipset, dual Opteron 2212, NUMA + IOMMU + S3 S-state + C2/C3 C-states are enabled, cross-nodes RAM interleave + NVRAID are disabled, NVidia 9600GT PCIe, SiliconImage 3124 eSATA controller PCI-X, 4xSATA II Hitachi HDDs

From info I've gathered here and there while searching for a solution, there seems to be two main "families" of suspend to RAM issues on NVidia chipsets :

  1- suspend procedure hangs because some devices refuse to suspend => machine wakes back up after ~30 seconds timeout

  2- suspend procedure finishes normally but some device concurrently wakes machine up (this behavior sometimes only occurs randomly, depending upon specific hardware) => machine's back up immediately

I experienced both problems above.
Here's what I believe were their root causes, with the workarounds (numbering corresponds to that of issue above) :

  1- kernel 3.5 differs from my previous kernel 2.6 by using by default, an async device-suspend scheme, which revealed an async-suspend-request management bug in NVidia's chipset driver (sata_nv), diag'ed in kernel bug #48951 opened by Joe Sapp (poster in this thread)

    => only workaround at the moment : use udev rule given in kernel bug #48951 thread, comment #20

  2- kernel 3.5 also differs from my previous kernel 2.6 by granting by default, USB devices the right to wake machine up from suspend (/proc/acpi/wakeup)

    => most frequently described workaround : unload driver of offending device before suspending (see for example : https://wiki.archlinux.org/index.php/Pm-utils#Standby_.2F_Suspend_to_RAM)

    => a workaround that I find less "invasive" : disable wake-up "permission" for offending devices before suspending, by means of a pm-utils hook (see : http://askubuntu.com/questions/152403/how-do-i-make-changes-to-proc-acpi-wakeup-permanent)

Hope it can help.
Eric

[penalvch (penalvch)]

Cut from Bug Description.

[penalvch (penalvch)]

ill, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

Also, could you please test the latest upstream kernel available following https://wiki.ubuntu.com/KernelMainlineBuilds ? It will allow additional upstream developers to examine the issue. Please do not test the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please comment on which kernel version specifically you tested. If this bug is fixed in the mainline kernel, please add the following tags:
kernel-fixed-upstream
kernel-fixed-upstream-VERSION-NUMBER

where VERSION-NUMBER is the version number of the kernel you tested. For example:
kernel-fixed-upstream-v3.11-rc3

This can be done by clicking on the yellow circle with a black pencil icon next to the word Tags located at the bottom of the bug description. As well, please remove the tag:
needs-upstream-testing

If the mainline kernel does not fix this bug, please add the following tags:
kernel-bug-exists-upstream
kernel-bug-exists-upstream-VERSION-NUMBER

As well, please remove the tag:
needs-upstream-testing

If you are unable to test the mainline kernel, please comment as to why specifically you were unable to test it and add the following tags:
kernel-unable-to-test-upstream
kernel-unable-to-test-upstream-VERSION-NUMBER

Once testing of the upstream kernel is complete, please mark this bug's Status as Confirmed. Please let us know your results. Thank you for your understanding.

[penalvch (penalvch)]

ill, could you please confirm this issue exists with the latest development release of Ubuntu? ISO images are available from http://cdimage.ubuntu.com/daily-live/current/ . If the issue remains, could you please run the following command in the development release from a Terminal (Applications->Accessories->Terminal), as it will automatically gather and attach updated debug information to this report:

apport-collect -p linux <replace-with-bug-number>

[Bartosz Bielecki (bielecki-b)]

I can only confirm that this bug is still very present in 13.10.

[penalvch (penalvch)]

Bartosz Bielecki, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Alexander (alxkud)]

Hello dear Ubuntu users who suffer from this annoying bug.

I can't stay away from it since I use day by day my PC with Ubuntu 14 .04 LTS installed on it.
My config is based on the "Asus Striker II Extreme" MB which is concerned (Nvidia MCP).

So, the workaround is VERY SIMPLE:
http://sethdepot.org/site/DebianLinux
------------
Can be automated with the following udev rule, put to the file /etc/udev/rules.d/86-async-scsi-disable.rules
# Workaround for broken/slow suspend by disabling async ata/scsi targets
# https://sethdepot.org/site/DebianLinux
ACTION=="add", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_target", ATTR{power/async}="disabled"
------------

Thank you and good luck.

[Oliver R. (oliverr)]

For me, unfortunately, the workaround does not help on an FSC Amilo Pa 1538 running Mint 17.1 (Ubuntu 14.04).

Instead, I created a file 50_async-disable in /etc/pm/sleep.d with the following contents (cf posts #5 and #8 to find out your device specification). This helps in my case. Don't forget the right permissions: chmod 755 50_async-disable

#!/bin/sh

case "$1" in
 suspend)
  echo disabled > /sys/devices/pci0000\:00/0000\:00\:0e.0/ata3/host2/target2\:0\:0/power/async
  ;;
esac