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? A quick way to test this
would be to grab a copy of the wakeup code from the bottom of your
generic_bulk_callback() and paste it temporarily into a suitabl place
in your open or ioctl code. Then when you see a stuck transfer, see
if the condition clears when you exercise the temporary wakeup code
by, say, running stty on that port (e.g: stty -a -F /dev/ttyUSB0).
That test worked for me. Another test that worked here involved setting
the wakeup code to run whenever a modem event occurs, though the wakeups
generated by normal hardware handshaking were not sufficient -- I had
to supplement them with extra manual modem events at a breakout box (not
a solution of course, but it gave me confidence in my problem assessment).
If either of these tests work for you, I'd say we've probably found the
same problem.
I tried adding code to invoke the wakeup code whenever our device transmit
buffer empties, but given the small size of the USB transfer packets and
the low priority of the wakeup messages, I think this is a bad approach.
I think a better approach will be to setup a task queue where we can
schedule the line discipline wakeups when the buffers empty, but do
the wakeups later. Unless anyone has a better suggestion, I'll try
that tomorrow.
I'll be very curious to hear if our problems turn out to be related.
Good luck.
--Peter
--
Peter E. Berger Tel: (218) 848-2885
Brimson Laboratories Fax: (218) 848-2433
1549 Hiironen Rd. Email: [EMAIL PROTECTED]
Brimson, MN 55602
> Hi all,
>
> I just got done testing the Visor driver on UHCI after a few people
> emailed me that they were having some problems. I duplicated these
> problems:
>
> Running 2.4.0-test1-ac4 trying to do a complete backup of my Visor.
> These errors happened only after a few files were transfered, and are
> repeatable.
>
> uhci.o:
> I get the following error after what seems to be a long timeout:
>
> uhci.c: uhci_result_interrupt/bulk() failed with status 440000
> URB [cf71b4a0] urbp [cee75020]
> QH [cee0a060]
> td 0: [cedff120]
> 00000001 e0 SPD Stalled CRC/Timeo Length=7ff MaxLen=3f DT1 EndPt=2 Dev=2,
>PID=69(IN) (buf=0f757920)
>
> The visor doesn't like this, and right after this error it disconnects.
>
>
> usb-uhci.o:
> I get the same kind of error after the same long timeout:
>
> usb-uhci.c: interrupt, status 3, frame# 249
> usb-uhci-debug.h: TD @ ced3dfa0/0ED3DFA0, MaxLen=3f DT0 EP=2 Dev=2 PID=( IN )
>buf=0f757b60
> usb-uhci-debug.h: Len=7ff e0 SPD IOC Stalled CRC/Timeo
> usb-uhci-debug.h: TD Link Terminate
>
>
> Anyone have any ideas of what is going on here?
>
> UHCI never caused any problems for me in the past (although it has been
> a number of kernel versions since I last tested the Visor.)
>
> thanks,
>
> greg k-h
> greg@(kroah|wirex).com
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
