search

rickysarraf / laptop-mode-tools

Power Savings tool for Linux
https://www.researchut.com/tags/laptop-mode-tools/
GNU General Public License v2.0
554 stars 47 forks source link

Runtime-pm: Whitelist-Blacklist interaction #58

Closed kalmarek closed 8 years ago

kalmarek commented 8 years ago

I have the following in my runtime-pm.conf: CONTROL_RUNTIME_AUTOSUSPEND=1 AUTOSUSPEND_USE_WHITELIST=0 AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST="usb" AUTOSUSPEND_RUNTIME_DEVID_WHITELIST="long-list-of-lsusb-devices-ids"

This is to make all build-in systems autosuspend, while all usb-mouse-dongle-phone should not autosuspend. It works as intended with external usb devices, however a few of the build-in escape, namely: 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor 413c:818e Dell Computer Corp. Unknown device (This is DW5560 WWAN modem), and 8087:07da Inter Corp. Unknown device (Bluetooth device integrated into Intel Advanced-N 6235)

These ids are included in the WHITELIST, yet powertop indicates no pm on them

rickysarraf commented 8 years ago

Hello,

On Wed, 2016-03-09 at 03:11 -0800, kalmar wrote:

I have the following in my runtime-pm.conf: CONTROL_RUNTIME_AUTOSUSPEND=1 AUTOSUSPEND_USE_WHITELIST=0 AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST="usb"

This is wrong. How did you come up with this value ? To the best of my knowledge, there is no driver named "usb".

AUTOSUSPEND_RUNTIME_DEVID_WHITELIST="long-list-of-lsusb-devices-ids" This is to make all build-in systems autosuspend, while all usb- mouse-dongle-phone should not autosuspend. It works as intended with external usb devices, however a few of the build-in escape, namely: 0a5c:5801 Broadcom Corp. BCM5880 Secure Applications Processor with fingerprint swipe sensor 413c:818e Dell Computer Corp. Unknown device (This is DW5560 WWAN modem), and  8087:07da Inter Corp. Unknown device (Bluetooth device integrated into Intel Advanced-N 6235) These ids are included in the WHITELIST, yet powertop indicates no pm on them

Please fix the above first, and then if the issue persists, please provide debug logs. You can set debugging on a per module basis, or for the entire of LMT, in the configuration files.

Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."

kalmarek commented 8 years ago

and to my best knowledge there is; grab a driver of the root hub e.g.: cat /sys/bus/usb/devices/1-1/uevent | grep DRIVER DRIVER=usb

logfile: https://www.dropbox.com/s/xosb9150wgxf6br/runtime-pm-debug.log?dl=0

rickysarraf commented 8 years ago

Hello,

On Wed, 2016-03-09 at 04:20 -0800, kalmar wrote:

and to my best knowledge there is; grab a driver of the root hub e.g.: cat /sys/bus/usb/devices/1-1/uevent | grep DRIVER DRIVER=usb

Thank you for sharing this information. For some reason, I had built the impression that the driver name directly related to kernel module name. And I can't see a reason why I would have thought so.

logfile: https://www.dropbox.com/s/xosb9150wgxf6br/runtime-pm-debug.log?dl=0 — Reply to this email directly or view it on GitHub.

This log file looks good. I'll look into it some time later. I am really occupied this week. In case you find more details, please do share on this bug report.

And just to be clear, this happens on the very recently released 1.69 version too ?

Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."

kalmarek commented 8 years ago

I have 1.68.1 installed; I will report back as soon as 1.69 becomes available on my distro

rickysarraf commented 8 years ago

On Wed, 2016-03-09 at 18:32 +0530, Ritesh Raj Sarraf wrote:

Hello,

On Wed, 2016-03-09 at 04:20 -0800, kalmar wrote:

and to my best knowledge there is; grab a driver of the root hub e.g.: cat /sys/bus/usb/devices/1-1/uevent | grep DRIVER DRIVER=usb

Thank you for sharing this information. For some reason, I had built the impression that the driver name directly related to kernel module name. And I can't see a reason why I would have thought so.

I spent some time today investigating this. I also dug back the old usb-autosuspend module, the predecessor to runtime-pm.

As the history shows, this assumption that that file (uevent) contains names of usb device types was contributed by Google engineer.

Git Commit ID: 22f4aad42f283d82fd0fa275bd68d0e89325d783

This, at least, is not valid today. Almost all device types are being reported as base class, i.e. just the "usb" family.

Run the following command to determine the status on your box.

rrs@learner:/sys/bus/usb/devices$ for x in *; do grep DRIVER $x/uevent;
done
DRIVER=hub
DRIVER=usb
DRIVER=hub
DRIVER=hub
DRIVER=usb
DRIVER=usbhid
DRIVER=usb
DRIVER=uvcvideo
DRIVER=uvcvideo
DRIVER=usb
DRIVER=btusb
DRIVER=btusb
DRIVER=usb
DRIVER=usbhid
DRIVER=hub
DRIVER=usb
DRIVER=usb
DRIVER=usb
2016-03-12 / 18:36:13 ♒♒♒  ☺  

rrs@chutzpah:/sys/bus/usb/devices$ for x in *; do grep DRIVER
$x/uevent; done
DRIVER=hub
DRIVER=usb
DRIVER=btusb
DRIVER=btusb
DRIVER=btusb
DRIVER=usb
DRIVER=usb
DRIVER=uvcvideo
DRIVER=uvcvideo
DRIVER=usb
DRIVER=usbhid
DRIVER=hub
DRIVER=hub
DRIVER=usb
DRIVER=hub
DRIVER=usb
DRIVER=usb
DRIVER=usb
18:37 ♒♒♒   ☺    

:-( Not a good day. That framework (and assumption) is broken (today).

Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."

rickysarraf commented 8 years ago

My guess is something (quietly) changed in the kernel is the last 6 years. I just don't know when.

rickysarraf commented 8 years ago

Nope. It is my mistake. usb devices were always listed as the patch was submitted. For some reason, I assumed they were equivalent to kernel module names.

rrs@chutzpah:/sys/bus/usb/devices$ for x in *; do grep DRIVER $x/uevent; done
DRIVER=hub
DRIVER=usb
DRIVER=btusb
DRIVER=btusb
DRIVER=btusb
DRIVER=usb
DRIVER=usb
DRIVER=uvcvideo
DRIVER=uvcvideo
DRIVER=usb
DRIVER=usbhid
DRIVER=hub
DRIVER=usb
DRIVER=usb-storage
DRIVER=hub
DRIVER=usb
DRIVER=hub
DRIVER=usb
DRIVER=usb
DRIVER=usb
rickysarraf commented 8 years ago

@abulak When you try, you may want to try on top of commit: c0bc3911d23bab7775edc8095904cdc24ba69875

I think this commit finally fixes all autosuspend problems.

kalmarek commented 8 years ago

Thanks for fast investigation! on Tuesday I will have access to my gentoo box, I will run it from git and report back;

cheers,

kalmarek commented 8 years ago

ok, got rid of tlp on my arch; installed lmt -- there was 1 usb device refusing to suspend; compiled lmt from git; updated configuration -- this seems to work (on this laptop)

rickysarraf commented 8 years ago

On Sat, 2016-03-12 at 10:52 -0800, kalmar wrote:

ok, got rid of tlp on my arch;  installed lmt -- there was 1 usb device refusing to suspend; compiled lmt from git; updated configuration -- this seems to work (on this laptop)

Good to know. I pushed 1 more change. The list from yesterday was aggressive and we were losing some watts.

When you verify, try to rebase on the latest changes. I believe the current settings should be optimal, ensuring USB -> Storage, Mouse, Keyboard are blacklisted, while the rest have power savings applied.

Ritesh Raj Sarraf RESEARCHUT - http://www.researchut.com "Necessity is the mother of invention."

kalmarek commented 8 years ago

works as expected!