On Wed, 10 Jan 2007, Jon Smirl wrote:
> > What happened to the HID interface before the reset?
>
> How can I check it? The controls cause events, is there some way to see them?
Well, earlier you wrote:
> This doesn't help but it is complicated because the PSC805 also
> includes a USBHID component. I can't skip binding the HID without
> losing my keyboard.
This seems to imply that the keyboard is part of the PSC805. So if the
keyboard continues to work then you know that the HID component of the
device is okay.
> > > Note that the failure only happens when the device is plugged into a
> > > root port. When plugged into a hub everything works ok.
> > >
> > > My root controller is:
> > > USB Controller: Intel Corporation 82801EB/ER (ICH5/ICH5R) USB UHCI
> > > Controller
> > >
> > > So I'd suspect the resume code in the driver for that chip.
> >
> > I don't know of any problems in the resume code. If you think there are
> > some, try attaching other devices to that port and see what happens when
> > you suspend and resume them.
>
> I just tried it in all four of my ports and got the same behavior. So
> it probably not a bad port.
That's not the point. Try using a different _device_ (not a different
_port_). For example, see what happens with one of your hubs. If you
plug in a hub with nothing attached to it, the hub will be suspended after
2 seconds. If you then plug something into the hub, the hub will be
resumed. If the hub does indeed resume then that shows the resume code
in the driver works correctly.
> Also, what looks like a power LED may be a "CPU is reset and running
> LED" I don't have schematics so I can't tell. I did plug in another
> 1.0 device which has a LED and it has power so maybe this is a "CPU is
> running LED" and it takes a reset to turn it on.
>
> Another possibility is that the device itself is not recovering from a
> suspend without a reset.
I think that's very likely. Or at least, it's not recovering from _these_
suspends.
> Is there a tool for forcing the device in
> and out of the suspend state? I tried setting power/state 0/2 and that
> didn't seem to do anything.
Doing that _will_ suspend and resume the device, provided
CONFIG_USB_SUSPEND is turned on. And so will unbinding all the drivers
bound to the device's interfaces (i.e., both snd-usb-audio and usbhid).
For that matter, all you have to do is unconfigure the device:
echo 0 >/sys/bus/usb/devices/2-1/bConfigurationValue
This will automatically unbind all the drivers. To reconfigure, echo 1
instead of 0.
> But if it is a problem in the device, why
> does it work in a hub and not on the root? Don't the hubs get
> suspended too?
Yes, they do. I don't know why it should work one way but not the other.
Perhaps it's a power issue. Does the device run on bus power? Does the
hub have an external power source? If both answers are Yes, then perhaps
the hub provides more power than the computer does.
> A third possibility, after the device resumes some kind of uevent
> isn't getting sent to the higher layers.
I doubt it. Resumes don't generate udev events.
> How do I turn on udev logging
> at boot?
As far as I know, you can't.
> Does udev work right if this happen?
> usb finds device
> 2 seconds are up
> device suspends
> drivers loads which triggers resume
Yes.
Alan Stern
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
