Hello, Alan said:
More likely is that the packet is larger than urb->iso_frame_desc[td->index].length
I had added a check in the completion callback (pwc_isoc_handler) in the beginning of loop that iterates on the urb packets: ..... for (i = 0; i < urb->number_of_packets; i++) { if ( urb->iso_frame_desc[i].actual_length > urb->iso_frame_desc[i].length) Err(KERN_ERR "actual_length>length"); else Err(KERN_ERR "actual_length<=length");
By running the app , I see the actual lenght is NEVER bigger than length.
I see that the length is 196. (It is the "expected length" as I understand). in the first iterations , actual length is 0 ; afterwards it is 196
I did also delved into the ohci layer. I looked in usb-ohci.c ;
I added some printing messages there ; and I know (see detial a little below)
where it
does change the urb->iso_frame_desc[i].status to -75 (EOVERFLOW)
The urb (with this iso_frame_desc array)
is sent to the completion handler.
But I do not know why this happens.
details : there is a method there called dl_transfer_length(). This message calculates the transfer length and updates the urb. In this message there is a calcaulation of the status field (urb->iso_frame_desc[i].status). This is done in this way : cc in an integer : it's valus is cc = (tdPSW >> 12) & 0xF; This integer is an index to an array of statuses. In the first entrances to the dl_transfer_length() it's value is 9. when it's value is 0 the urb->iso_frame_desc[].status is set to 0 in dl_transfer_length().
Then it becomes 8; and when it is 8, the urb->iso_frame_desc[].status is set to -75 in dl_transfer_length(). a further look in cc_to_error[16] in the header usb-ohci.h explains why : an index pf 8 is USB_ST_DATAOVERRUN ; and in usb.h , you will find #define USB_ST_DATAOVERRUN (-EOVERFLOW)
(BTW, you might wonder why , when status is 9 , it retruns status 0 ;
the reason is : in the dl_transfer_length() , you have , a little
afterwards:
.....
if (!(urb->transfer_flags & USB_DISABLE_SPD) && (cc == TD_DATAUNDERRUN))
cc = TD_CC_NOERROR;
and TD_DATAUNDERRUN is 9 (you have #define TD_DATAUNDERRUN 0x09 is usb-ohci.h).
This urb (with iso_frame_desc array where iso_frame_desc[i].status=-75 is sent back to the completion handler, which is pwc_isoc_hadler. It is done in sohci_return_urb, in the case PIPE_ISOCHRONOUS of the switch sentence. There is a call to urb->complete (urb) there.
so the problem seems to be related somehow to tdPSW. the psw is the packet status word ; and in fact, it value is tdPSW = le16_to_cpu (td->hwPSW[0]);
I do not know why this problem is caused.
I will be glad to add any further details if needed.
regards, John
From: Alan Stern <[EMAIL PROTECTED]>
To: John Que <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] actual_length of iso_frame_desc is 0 in handler after usb_set_interface() call
Date: Wed, 14 Jul 2004 14:17:38 -0400 (EDT)
On Wed, 14 Jul 2004, John Que wrote:
> By "After 31 interations," , I mean
> There is a loop in the pwc_isoc_handler() ; which is the completion callbak.
>
> for (i = 0; i < urb->number_of_packets; i++)
> {
> fst = urb->iso_frame_desc[i].status;
> flen = urb->iso_frame_desc[i].actual_length;
>
> We reach iterate in this loop 31 times ; (In fact , urb->number_of_packets
> is 10 as I said;
> so it happens after 3 times we enter the completion callbak.
>
> It seesm to me that the host controller is responsible for the -75 status
> (-EOVERFLOW).
> I use usb-ohci (no patches) .
> When looking at the code of usb-ohci I see:
>
> urb->iso_frame_desc [td->index].actual_length = dlen;
> urb->iso_frame_desc [td->index].status = cc_to_error [cc];
>
> And by adding printk() I saw that cc_to_error [cc] gets a value of
> EOVERFLOW.
That makes sense.
> I do not have any idea why it happens or if the host controller or the
> driver is the cause for it.
>
> According to the error_codes.txt in Linux documentation :
>
> -EOVERFLOW (*) The amount of data returned by the endpoint was
> greater than either the max packet size of the
> endpoint or the remaining buffer size. "Babble".
>
>
> Could it be that the endpoint returned a packert larger than max packet of
> that endpoint?
It's pretty unlikely but not impossible. More likely is that the packet is larger than urb->iso_frame_desc[td->index].length. That would also cause EOVERFLOW. Do you know what the value of .length was, and what the packet size was supposed to be?
Alan Stern
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=4721&alloc_id=10040&op=click _______________________________________________ [EMAIL PROTECTED] To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
