- I only found it when running Arch Linux where, for whatever reason, dmesg showed an error code (134217730) that I did not see on Ubuntu. It is possible it did not show up when I did a dmesg | grep PM .
- I do not know if this udev rule (the workaround) has any side effects beyond "making suspend work":
ACTION=="add", SUBSYSTEM=="scsi", ENV{DEVTYPE}=="scsi_target", ATTR{power/async}="disabled"
- I have only tested it on Arch, where it Works For Me.
I can test it out on Ubuntu (within a few days or so) if you'd like, but it sounds like the kernel folks are working on a solution, so maybe that will not be necessary?
Hi.
I found a kernel bug report ( https:/ /bugzilla. kernel. org/show_ bug.cgi? id=48951 ) with a possible workaround ( https:/ /bugzilla. kernel. org/show_ bug.cgi? id=48951# c20 ), but there are some relevant points to make:
- I only found it when running Arch Linux where, for whatever reason, dmesg showed an error code (134217730) that I did not see on Ubuntu. It is possible it did not show up when I did a dmesg | grep PM .
- I do not know if this udev rule (the workaround) has any side effects beyond "making suspend work": =="scsi_ target" , ATTR{power/ async}= "disabled"
ACTION=="add", SUBSYSTEM=="scsi", ENV{DEVTYPE}
- I have only tested it on Arch, where it Works For Me.
I can test it out on Ubuntu (within a few days or so) if you'd like, but it sounds like the kernel folks are working on a solution, so maybe that will not be necessary?