Hi Olav, thanks for your response. (my personal email account with NTL (*spits*), which is where I am subscribed to linux-usb-devel, seems to be down today, so I'm only getting the responses that are CC'd to my work email... please continue to CC me, cheers!)
On Thu, 2005-02-24 at 02:04 +0200, Olav Kongas wrote:
>
> 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?
I'm not too familiar with the pegasus driver (perhaps I will have to
become familiar by the end)...
The driver queues an URB with length PEGASUS_MTU + 8. PEGASUS_MTU is
1536, I guess the extra 8 is a status header added by the dongle, this
gives an URB that is large enough to contain the largest packet that
could arrive.
72 is 64 + 8, and 64 is the minimum Ethernet packet size, so this just
seems to be a smaller than maximum size packet arriving, which is fine
and normal.
> 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;
thanks, what I had written was complete rubbish of course, which is why
i was seeing all sorts of PTDs I wasn't expecting...
> 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.
The amount of debug still seemed to be too much over a serial line, but
if I redirect it all via syslog to /var/log/debug I get the attached (I
added KERN_DEBUG to dump_ptd_*), this is with the fix for the reporting
of short_not_ok corrected.
Writing via syslog was fast enough that I didn't need to restrict the
PTDs that were printed and I could include the dump_ptd_*_data as well.
I see a lot of PTDs with CC=f (TD_NOTACCESSED). Is it normal to see so
many?
I see one CC=3 (DataToggleMismatch) and a whole load of CC=9's
(DataUnderrun).
The DataUnderrun seem to correspond to the allowed underruns we
discussed above. I see 39 CC=9's and 40 allowed data underruns (I'm
willing to believe that syslog dropped the occasional message).
I have to admit I don't have a clue what toggle is supposed to do...
Is there any further debugging I can enable that will help?
Cheers,
Ian.
--
Ian Campbell, Senior Design Engineer
Web: http://www.arcom.com
Arcom, Clifton Road, Direct: +44 (0)1223 403 465
Cambridge CB1 7EA, United Kingdom Phone: +44 (0)1223 411 200
_____________________________________________________________________
The message in this transmission is sent in confidence for the attention of the
addressee only and should not be disclosed to any other party. Unauthorised
recipients are requested to preserve this confidentiality. Please advise the
sender if the addressee is not resident at the receiving end. Email to and
from Arcom is automatically monitored for operational and lawful business
reasons.
This message has been virus scanned by MessageLabs.
isp116x-pegasus-ptds-3.log.bz2
Description: application/bzip
