----- Original Message ----- From: "Benoit Audouard" <[EMAIL PROTECTED]> To: <[email protected]> Sent: Tuesday, May 24, 2005 5:07 PM Subject: Re: [Eagleusb-dev] does it work with a usb hub ?
> On Tue, May 24, 2005 15:43, Alexis Bunel said: > > 2005/5/24, Benoit Audouard <[EMAIL PROTECTED]>: > >> http://forum.eagle-usb.org/viewtopic.php?t=3374 > >> It often happens with laptops (which have a limited number of usb port, > >> hence the use of a hub). > >> Does it come from the driver or from the usb module ? > > I haven't used the eagle-usb driver since 2.0, but I had absolutely no > > issues regarding the use of a USB hub. I wasn't using any laptop. > > Can you provide the result of : > lspci -v # to list your hardware (usb + hub) > lsmod|grep -Ei "usb|hcd" # to list drivers that make it work > cat /proc/interrupts > cat /proc/pci > (I asked for an eaglediag -sui which provides quite the same) > > This issue may depend on hardware and could be addressed by linux-usb ML. > > In an answer, > http://forum.ubuntu-fr.org/viewtopic.php?pid=34700#p34700 > the user infers that it may come from the plugged device being managed by > - either uhci (when directly plugged to usb) > - or ehci (when plugged to hub) > (can be seen in /var/log/messages when the device is detected). > > Well, either an usb module problem or perhaps power-throughput not > suficient ? the error given by eagle-usb being [EAGLE-USB] Unable to > submit interrupt URB! > I look on both speedtouch and eciadsl Changelog. I find nothing interesting on eciadsl but find this on speedtouch * src/modem_run.c: Applied patch submitted by Duncan Sands Here is the explanation of the patch: Without (1) the system can be brought to a crawl due to continuous submission of urbs which immediately fail, are immediately resubmitted etc (I have seen this problem). This should probably be fixed in the kernel, but while we're waiting... With some hardware (eg: the usb hub that I just bought), the kernel module is unable to set alternate 1 on interface 1 if signalled immediately after the line comes up. Sleeping a little before signalling the kernel fixes this. I'm not sure why. I added a sleep for line down as well, though it shouldn't be needed. the patch is simple http://cvs.sourceforge.net/viewcvs.py/speedtouch/speedtouch/src/modem_run.c?r1=1.28&r2=1.29 Look at the error message before the first sleep "Error reading interrupts" Gilles
