2006/1/6, Alan Stern <[EMAIL PROTECTED]>:
> For example, on my system here's the path to the power-state file for one
> of my root hubs:
>
> /sys/devices/pci0000:00/0000:00:1d.7/usb1/power/state
>
> and here's the power-state file for the hub's interface:
>
> /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-0:1.0/power/state
>
> They are not the same. What path are you looking at?
I was suspending both paths since I can't suspend a device, if its
interfaces are not suspended.
$ echo -n 3 > /sys/bus/usb/devices/2-2\:1.0/power/state
$ cat /sys/bus/usb/devices/2-2\:1.0/power/state
3
$ echo -n 3 > /sys/bus/usb/devices/2-2/power/state
$ cat /sys/bus/usb/devices/2-2\:1.0/power/state
3
*** Remote wakeup ***
$ cat /sys/bus/usb/devices/2-2\:1.0/power/state
0 # <----- OK interface seems to be resumed
$ cat /sys/bus/usb/devices/2-2/power/state
3 # <----- KO interface seems to be resumed
could you just try to suspend your mouse ?
>
> Also, what kernel version + patchset are you using? Right now I'm on
> 2.6.15 together with gregkh-all-2.6.15.patch (which no longer exists; the
> current gregkh-all patch is for 2.6.15-git1).
2.6.15
> Anyway, if you still can't figure out what's going on, add some printk
> statements to finish_device_resume in core/hub.c. You should see where
> udev->dev.power.power_state gets set to 0, near the top of the routine.
>
Ok I'll do that.
Thanks
--
Franck
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
