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. > A related note. The first time the remote is plugged in (in the patched > kernel), I see: > > Jun 15 20:48:01 esk kernel: [ 62.532117] usb 5-1: new full speed USB > device using uhci_hcd and address 2 > Jun 15 20:48:02 esk kernel: [ 63.947538] usb 5-1: configuration #1 > chosen from 1 choice > Jun 15 20:48:03 esk kernel: [ 64.046432] usbcore: registered new > interface driver hiddev > Jun 15 20:48:03 esk kernel: [ 64.047052] usbcore: registered new > interface driver usbhid > Jun 15 20:48:03 esk kernel: [ 64.047627] usbhid: v2.6:USB HID core driver > Jun 15 20:48:04 esk kernel: [ 65.376201] usb 5-1: USB disconnect, > address 2 > > Whereas every other time I see just: > > Jun 15 20:48:09 esk kernel: [ 70.168028] usb 5-1: new full speed USB > device using uhci_hcd and address 3 > Jun 15 20:48:10 esk kernel: [ 71.360549] usb 5-1: configuration #1 > chosen from 1 choice > Jun 15 20:48:13 esk kernel: [ 74.056087] usb 5-1: USB disconnect, > address 3 > > I believe this correlates What do you mean by "this"? The "registered new interface driver" messages? > with the concordance application not being > able to detach the kernel HID driver from the device the first time it > runs, using usb_detach_kernel_driver_np(). However, the problem goes > away I think if I just run the concordance application again (I think > unplug/replug wasn't required). Any idea what's up with that? The drivers are loaded automatically by the hotplug system the first time you plug in your device. They don't need to be loaded again on later plug-ins because then they are already loaded. However, loading takes some time. If your program is started automatically, it may begin running before the drivers do -- in which case it would be unable to unbind the driver because the driver wasn't bound yet! 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