On Tue, 30 May 2000, Greg KH wrote:
> On Mon, May 29, 2000 at 09:48:11PM -0500, Peter E. Berger wrote:
> > Hi Greg:
> >
> > I've just been tracking down a problem in our Digi USB driver which
> > may shed some light on yours. In our case, on slower machines (e.g:
> > <=300Mhz) with transfers at high baud rates (e.g: 115K), large (e.g:
> > 400K byte) file transfers would sometimes hang the transfers with timeout
> > errors. We saw similar behavior with different file transfer protocols
> > (e.g. zmodem and kermit), with non-protocol large text file dumps,
> > with software and hardware flow control and when using usb or usb-uhci
> > (I don't have an ohci machine). On investigation it turned out that
> > the transfers were always hung in the application level write on the
> > main sending side (e.g: on the "sz" side in an sz -> rz transfer).
> > I tracked down the data flow and found that in the failure cases,
> > the line discipline was stuck sleeping and thus failing to send more
> > characters to our driver write routine. Even though we wake up the
> > line discipline in the write callback routine (as you do in the Visor
> > driver's generic_bulk_callback), it looks like there's a race condition
> > where the wakeup can fail to come late enough, so the line discipline
> > is left sleeping on the job (nice work if you can get it...).
> >
> > Maybe this is the same problem you're seeing?
>
> This sounds like the problem that I have been seeing (and lots of other
> people) with the Visor on OHCI seeming to just go to sleep in the middle
> of a large transfer. When I slow the OHCI driver down by turning on all
> of it's debugging, the problem goes away, which makes sense given what
> you just described.
>
> Thanks!
>
> Unfortunately I don't think this is the same problem on UHCI right now
> (or the OHCI oops problem either.)
>
> UHCI seems to have a problem with a transfer timing out (or so I'm
> guessing). I think I/we need to figure this one out before I can even test
> out what you see (or fix the oops on OHCI, then I could test it too.)
>
I'm not sure if it is related, but the original and continous problem I am
having with my Ethernet devices is Timeout's being generated on large file
transfers. This had forced an error condidition in the pegasus driver
that wasnt handled correctly and that was fixed, however, the timeout's
remain (which seems strange cause I have a seperate 100BT switch to test
on and cant image what is causing them). Interesting note that the
usb-uhci driver had less timeouts occuring than the JE uhci driver.
My test machines are IOpeners - Winchip 200Mhz(via) - uhci hc.
Thanks,
-Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
