I have noticed that, on suspend to RAM, self powered (through the USB port) external drives keeps running. I think the USB ports should be powered off to prevent USB device tiring the laptop battery while suspended on battery. For now I have to disconnect everything before suspending if I'm not on external power. I do not remember if it worked once, so I'm not sure this is a regression or not, this problem occurs at least since 2.6.29 and maybe before. The laptop used is an Acer Aspire 1511 LMi (64 bits mode). I do not know if this problem also occurs on other hardware (don't think so, otherwise it would certainly have been reported by anyone else). Can give any information on this hardware if necessary (dsdt, lspci, lsusb, dmesg...).
Created attachment 22398 [details] dsdt file for this laptop
Created attachment 22399 [details] dmesg output after boot for 2.6.31-rc3 This is for 2.6.31-rc3, since this was the latest kernel I checked.
Will you please attach the output of acpidump, lspci -vxxx? Thanks.
Created attachment 22450 [details] lspci -vxxx output
Created attachment 22451 [details] acpidump output
(Cc Alan) Guys, could someone please have a think about whether this is an ACPI problem or a USB problem or something else so that we can get it routed appropriately? Thanks.
Most PCs don't have any way to power off their USB ports, other than turning off the entire computer. However, during system suspend the ports should be suspended (assuming you have enabled CONFIG_USB_SUSPEND). To debug this further, attach a dmesg log showing a suspend/resume cycle under a kernel with CONFIG_USB_SUSPEND and CONFIG_USB_DEBUG turned on.
close this bug as there is no response from the bug reporter. please reopen it if 1. the problem still exists in 2.6.31 2. you can provide the info requested in comment #7. :)
Sorry, I've completly forgotten this one. The problem still exists in 2.6.32-rc5, and I append the dmesg log with USB_SUSPEND (already activated) and DEBUG.
Created attachment 23434 [details] dmesg output with 2 suspend/resume
The dmesg log looks quite normal, except for all those messages regarding the -121 errors on the USB flash drive. Apart from that, I'd say nothing is wrong. (But you might want to investigate what's going on with that flash drive. You can use usbmon; see Documentation/usb/usbmon.txt.) The computer isn't supposed to power down the USB ports. If it did, the devices wouldn't be able to stay suspended -- suspended devices do need a small amount of power. Instead, it's the device's job to make sure that it stops drawing large amounts of power when a suspend occurs. Since the log shows that the suspends _did_ occur, if a bus-powered drive failed to spin down then it's the drive's own fault. However it's possible that the drive expected to receive an explicit "spin-down" command. Here's another place where usbmon can come in handy; it will show if that command got sent.
I tried to use USB mon as you say and got a nice file I hope will give some clues. I did: - start monitoring the whole bus (cat 0u); - plug the USB hard disk device; - suspended the devices: echo devices > /sys/power/pm_test echo mem > /sys/power/state This freezes all processes and suspends all devices for 5 seconds. - stop the cat process. The resulting file is appended.
Created attachment 23617 [details] usbmon log while suspending with a USB hdd auto powered connected
The usbmon log shows two things. First, the USB flash device either isn't working right or else isn't able to read its media. That's why you got all those -121 error messages in the dmesg log. Second, the system does not try to spin down the Lacie disk. This is controlled through a sysfs setting. Look under /sys/class/scsi_disks/sdb (or something like that) for a file named "manage_start_stop", and write a "1" to that file. This should cause the SCSI disk driver to spin the disk down during a suspend and spin it up during a resume. If this does what you want, you can write a udev rule that will automatically set manage_start_stop to 1 for the Lacie drive.
OK, manage_start_stop does what I effectively wants the system to do. I'm not fluent with udev rules, but now I know how to do it. I wonder why the kernel does not use this option by default for removable devices on auto powered bus. But this is borderline with a distro bug. Don't know what to do with this one therefore, if you close it I won't reopen it. Thanks
I don't know why manage_start_stop defaults to 0; you'll have to ask the SCSI developers. Maybe some devices misbehave if you try to spin them up or down. Also, this doesn't have anything to do with whether or not the device is "removable". In fact, the word "removable" refers to the media, not to the drive itself. A CDROM drive or card reader would be removable (because it's possible to eject the disc or the card) but a hard disk or flash drive is not. Perhaps you meant "hot-unpluggable". And whether the bus is auto-powered shouldn't matter. For example, your Lacie drive doesn't run off bus power, does it? If you want to pursue this matter further, go ahead and talk to the SCSI people. However we have at least determined that this isn't a USB, ACPI, or Power Management issue. Therefore it is appropriate to close the bug report. I can't close it because I'm not the owner, but you can since you are the reporter.
I'm sorry, English is not my native tongue. I don't understand what "run off power" means ;-) Anyway, the drive has no power plug, it relies on the USB bus power to run. That's why I want it to spin down when I suspend the computer, when the computer is not on AC power. Actually, I can power this device with an USB power cord and use it with firewire for data transfer, but it's quite usefull not to have power cord and AC adapter on it, because I just use it as a big USB memory stick. Of course, the drive is not removable (don't know how it's call in English), but it's hot-(un)pluggable (I plug it in when I need to save/transfer data). Just as a memory stick indeed. I'll close the bug. Still thanks a lot for all these explanations. Regards