On 06/16/2010 08:09 AM, Alan Stern wrote:
On Tue, 15 Jun 2010, Stephen Warren wrote:
On 06/06/2010 06:10 PM, Alan Stern wrote:
On Sun, 6 Jun 2010, Phil Dibowitz wrote:
On 05/19/2010 07:56 PM, Alan Stern wrote:
I have no idea why it would do this. A firmware bug would generally
cause it to die every time, but there's no other obvious explanation.
Particularly since the alternate firmware does not die; it handles the
request correctly.
Hmmm. I guess I'll go read the PIC USB interface specification and see
how much of this is SW vs. HW controlled on this microcontroller.
It's odd that this occurs only some of the time. Maybe it depends on
some low-level timing details.
Could this be something like the GET_IDENTITY problems we used to see, where
we just need to wait a bit before sending this?
Maybe. I tend to doubt it, but it's certainly possible. And it's easy
enough to test, by adding a delay in the appropriate place. That would
mean putting something like
msleep(1000);
at the start of the check_highspeed() routine in
drivers/usb/core/hub.c.
Sorry for the slow response. Adding the msleep() works!
In Ubuntu Lucid kernel 2.6.32-21.32, I plugged in the remote 22 times,
and 2 times it was detected properly.
I rebuilt the same Ubuntu kernel package with that change, and plugged
in the remote 22 times, and all 22 times it was detected properly.
How should this fix be added to the quirk list?
You should first find out how long the delay needs to be. 1000 ms is
probably an overestimate. Try some smaller values.
It looks like 200ms is the magic value; 150ms is obviously still broken,
175ms was bad 1 in 45 times (funnily enough the very first), and 200ms
was good for 200 plug cycles across 2 different USB ports on my main laptop.
This is all judging by whether the kernel plug messages indicate 1 or 0
configurations found. I should probably test the modified kernel on a
couple other laptops, and also not just for plugins, but also
post-configuration-download reboot cycles. (Application level
configuration.)
--
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
