On Wed, 23 Feb 2005, Ian Campbell wrote:
> I've attached a trace made with DEBUG and URB_TRACE, it's quite big but
> compresses really well. The interesting parts, I think, are many
> messages similar to this one:
> 116x: Enqueue: FA 2 ep1in bulk: len 1544 short_not_ok
> [SNIP several successful ip3in int transfers]
> 116x: Allowed data underrun
> 116x: Finish: FA 2 ep1in bulk: len 72/1544 short_not_ok stat 0
I went through the logs. From the urbs log it seems like the
dongle sends to the host controller indeed short data (like
72 bytes instead of requested 1544 above). The received data
was not multiple of the MaxPacketSize of the bulk ep1in,
which is 64 bytes (right?). Therefore it seems that the
isp116x driver finishes correctly the corresponding urbs. Do
you have an idea, whether the data received through bulk1in
is reasonable?
> Towards the end there is also a message
> 116x: start_atl_transfers: load 858, MAX_LOAD_LIMIT 850
This message shows that there were more urbs submitted to
isp116x than could be scheduled for a single frame. Should
be a harmless message assuming that the driver handles this
correctly.
> I tried to capture a trace with PTD_TRACE enabled, but the control
> messages never settled down enough that I could bring the interface up
> and capture the short bulk transfers. The capture is attached and
> consists of lots and lots of control transfers. Only one was short:
I understood the ptds log as follows. The configuration
procedure proceeded similar to urbs log case until the
following messages were printed:
eth1: Belkin F5D5050 USB Ethernet
usbcore: registered new driver pegasus
and one more control urb was successfully submitted and
finished. Then the first and only bulk1in urb was submitted,
but printing of that much information completely loaded the
cpu, so that the enqueuing of the first and only int3in urb
was started (Enqueue: FA 2 ep3in int message in ptds log),
but its scheduling never happened (no message like schedule
qh32/c2f2ec60 branch 0 in ptds urb).
> I wanted to change it to only print PTDs for the ep1in transfers (hoping
> to catch the bulk transfers only), but when I did that[1] I still didn't
> get far enough to bring the interface up.
I propose that you put just 'return;' to the beginning of
both dump_ptd_{in,out}_data() and put the following to the
beginning of the dump_ptd() (this test slightly differs from
what you proposed):
if(PTD_GET_EP(ptd) != 1 || PTD_GET_DIR(ptd) != PTD_DIR_IN)
return;
I hope that with these modifications it is possible to get
more informative ptds log. If even this does not help then
there are other considerable speedups possible. In any case,
let me know.
Olav
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
linux-usb-devel@lists.sourceforge.net
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
