Comment 8 for bug 1065840

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.