Nemosoft Unv. wrote:
> Greetings,
>
> On Tuesday 30 October 2001 00:20, [EMAIL PROTECTED] wrote
>
>>Hi David, Nemosoft,
>>
>>First of all thanks for your answers. I hope we can get to the bottom of
>>this weirdness!
>>
>>I applied the patch to pwc-if.c and enabled CONFIG_DEBUG_SLAB. I hope the
>>resulting messages file means more to you than it does to me ;-)
>>
>
> [snip]
>
> [excerpt from log]
> Oct 29 23:53:24 wereldvreemd kernel: usb-ohci.c: USB-error/status: 8 :
> c167d180
> Oct 29 23:53:24 wereldvreemd kernel: usb-ohci.c: USB-error/status: 8 :
> c167d140
> Oct 29 23:53:24 wereldvreemd kernel: usb-ohci.c: RET URB:[9cc2] dev: 3,ep:
> 4-I,type:ISOC,flags: 2,len:6208/9600,stat:0(0)
> Oct 29 23:53:24 wereldvreemd kernel: usb-ohci.c: data(6208/9600): db 8f 21
> 2a d4 38 42 23 09 0d 24 34 92 d0 40 42... stat:0
> Oct 29 23:53:24 wereldvreemd kernel: pwc Iso frame 0 of URB has error -18
> Oct 29 23:53:24 wereldvreemd kernel: pwc Iso frame 1 of URB has error -18
>
> Hmm, this is kinda weird... When the URB is returned to the user driver
> handler, it's state is 0 (no error), yet two (and often one) TD has an
> error. -18 is -EXDEV.
There was no transmition error on the bus so none of the transmitted
packets has an error and so the URB error code is 0.
That might be weird if you look at the URB error as the
master error code and the frame error code as the sub-error code.
If you look at it as a set of error codes then something is wrong
if one of the error-codes (URB or frame) is not 0.
> This status is set in 2 places in usb-ohci.c, around
> line 500 (just before the driver callback handler is called), and line 600,
> in sohci_submit_urb():
>
> for (i = 0; i < urb->number_of_packets; i++) {
> urb->iso_frame_desc[i].actual_length = 0;
> urb->iso_frame_desc[i].status = -EXDEV;
> }
>
> I got a hunch... I'm using a circular linked list of 2 URBs, and it is my
> guess the auto-urb submission is too late, or out of sync with the TD
> pointer; in effect, the chip starts filling data before the URB is actually
> linked into the TD structure, leaving the status for the first one or two
> TDs at -EXDEV.
>
> Try changing the status value about to something weird, like -200 and see
> if that shows up in the log. If so, we have at least narrowed the problem
> down a bit.
>
> Second, in pwc.h try to change MAX_ISO_BUFS to 3, in stead of 2. Maybe 2
> URBs is simply too little for this chip, and it needs a bit more headroom.
>
I think it is not primary a problem of OHCI chips.
But as far as I can remember a 100MHz CPU is used here and this could be
a little bit slow for constantly streaming (decompressing?) of 10 Mbit/s
of data.
- Roman
> Mind you, I know next to nothing about the OHCI chip and its architecture;
> I'm just making educated guesses :)
>
> - Nemosoft
>
>
>
> _______________________________________________
> [EMAIL PROTECTED]
> To unsubscribe, use the last form field at:
> https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
>
>
>
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
