On Sun, 22 Sep 2013, Marc MERLIN wrote: > On Sun, Sep 22, 2013 at 12:38:56PM -0400, Alan Stern wrote: > > > gandalfthegreat:/sys/bus/usb/devices/3-1.6/power# grep . * > > > active_duration:61227648 > > > async:enabled > > > autosuspend:2 > > > autosuspend_delay_ms:2000 > > > connected_duration:66830880 > > > control:auto > > > level:auto > > > persist:1 > > > runtime_active_kids:0 > > > runtime_active_time:18870052 > > > runtime_enabled:enabled > > > runtime_status:active > > > runtime_suspended_time:5324088 > > > runtime_usage:0 > > > > This all looks correct. > > Since then, I've confirmed that I don't have the problem some time after > reboot. It may be that the device doesn't seem to sleep well after I've used > it once. > > What's interesting, is that I see this when power is plugged in: > > Power est. Events/s Category Description > 8.18 W 100.0% Device USB device: Yubico Yubikey II (Yubico) > 8.13 W 100.0% Device USB device: Integrated Camera (Chicony Electronics Co., Ltd.) > > Somehow I know that my Yubikey isn't using 8W, so powertop numbers need to > be taken with a grain of salt. I don't know where powertop gets its numbers from. Perhaps it uses the value reported by the device (bMaxPower). That value is only a maximum; it doesn't change to reflect the actual usage. > Once I go to batteries, I see this: > Summary: 760.1 wakeups/second, 718.9 GPU ops/seconds, 0.0 VFS ops/sec and 6.9% CPU use > > Power est. Usage Events/s Category Description > 8.32 W 100.0% Device USB device: Yubico Yubikey II (Yubico) > 2.52 W 73.3% Device Display backlight > > So at least for now, the camera does sleep ok, until later when it probably won't again. > > I'm somehow thinking there is a driver or hardware problem when the device > does get stuck in a mode where it won't sleep properly again until the next > reboot (just unloading/loading the driver does not fix this). That's quite possible. But if it is a driver problem, wouldn't unloading and reloading the driver fix it? > > You might get more information from a kernel with CONFIG_USB_DEBUG > > enabled. Especially if you add > > > > #define VERBOSE_DEBUG > > > > to drivers/usb/core/driver.c before the first #include line. > > Do you think thaty would help debug the problem above, or not really? I'm There's no way to know in advance. > starting to think that the USB layer is not at fault, although I could be > wrong I suppose. You asked for advice on things to try, and I suggested something. That's the best I can do. Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
