On Fri, Mar 15, Greg KH wrote:
> On Thu, Mar 14, 2002 at 02:21:47PM +0100, Olaf Hering wrote:
> > > The problem looks like the usbdevfs calls are happening at the same time
> > > the hid driver is also talking to the device.
> > >
> > > Olaf, is this what your log messages show?
> >
> > It seems so. I think a more correct fix would be a lock in the usbcore
> > code to hold usbdevfs requests when "some bus action" is going on, like
> > this renumbering. You said there is no lock right now for this case?
>
> This is correct and has been on the list of things to fix in the usb
> code for a while.
What is the status of this bug in the hotplug related functions? We
added a "sleep 3" in the add routing in usb.rc, but that can only be a
workaround.
My idea was that we queue the hotplug events somehow and wait for all
"bus traffic" to complete, the stuff that occours when the usb-uhci
driver is loaded. Something like
insmod usbcore;insmod usb-uhci;modprobe hid;insmod keybdev;insmod mousedev
should work. And it did not with 2.4.19pre2/3, I got timeouts. However,
typing the commands manually to get some delay, and it worked. So I
think that it is not strictly related to usbdevfs, that might be another
bug.
However, after reading the whole thread again, it seems that queuing the
events is maybe not the best solution. What should be done to get this
fixed? (The delay and locking should be in the kernel and not in the
hotplug package).
Gruss Olaf
--
$ man clone
BUGS
Main feature not yet implemented...
_______________________________________________________________
Have big pipes? SourceForge.net is looking for download mirrors. We supply
the hardware. You get the recognition. Email Us: [EMAIL PROTECTED]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
