Hi,
Short description of the problem: Norbert can�t use the webcam driver
because the driver always receives image frames that are too short; it looks
like a lot of URBs got dumped. Interestingly, the iamge frame length is
usally constant. We narrowed the problem down to the isoc-handler, which
collects the transfered ISO packets into a single, contiguous buffer.
On 25-May-01 Norbert Preining wrote:
> On Fre, 25 Mai 2001, Nemosoft Unv. wrote:
>> something like ?detect short packet? enabled, or disabled (not sure if it
>> affects ISOC transfers)?
>
> Not that I know form. I found USB_DISABLE_SPD and checked if it is set,
> but it is not.
>
>> There is something else you can do: in pwc_isoc_handler, there is a large
>> piece of code inside ?if (fst == 0) { ... }?, but there is no ?else?
>> branch.
>> Try and print this fst-status if its != 0, there maybe some corrupted
>> packets on the line.
>
> Here what I did:
> for (i = 0; i < urb->number_of_packets; i++) {
> fst = urb->iso_frame_desc[i].status;
> printk("DEBUG: fst=%d\n", fst);
> flen = urb->iso_frame_desc[i].actual_length;
> iso_buf = urb->transfer_buffer +
>urb->iso_frame_desc[i].offset;
> if (fst == 0) {
> printk("DEBUG: entering fst==0\n");
>...
> } else /* ..status == 0 */
> { /* fst status != 0 */
> printk("DEBUG: entering fst NOT= 0\n");
> printk("DEBUG: fst=%d, flen=%d\n", fst, flen);
> printk("DEBUG: urb->transfer_flags & USB_DISABLE_SPD
>=%d\n", urb->transfer_flags & USB_DISABLE_SPD ? 1 : 0);
> }
>
> And I get the following messages:
>
> Then there are a lot of line packets like this:
>
> A good one:
> May 25 16:26:44 mandala kernel: DEBUG: fst=0
> May 25 16:26:44 mandala kernel: DEBUG: entering fst==0
>
>
> And a bad one:
> May 25 16:26:44 mandala kernel: DEBUG: fst=-18
> May 25 16:26:44 mandala kernel: DEBUG: entering fst NOT= 0
> May 25 16:26:44 mandala kernel: DEBUG: fst=-18, flen=0
> May 25 16:26:44 mandala kernel: DEBUG: urb->transfer_flags &
> USB_DISABLE_SPD = 0
[fst is the status of each and every transfered URB]
> I always get fst = -18. Whatever this means.
I don�t know either; the maintainer of the OHCI driver can hopefully tell
us exactly what this means.
> I took a look into usb-ohci
> and found, that sometimes .status will be set by converting a value
> with cc_to_error[16], but printing out the values of cc_to_error does not
> give any -18.
>
> But I found (with gcc -E) the two places where -18 is set to the status:
>
> first is in usb-ohci.c around line 550:
> if (urb_priv->state != URB_DEL) {
> for (i = 0; i < urb->number_of_packets; i++) {
> urb->iso_frame_desc[i].actual_length = 0;
> urb->iso_frame_desc[i].status = -EXDEV;
>
> ^^^^^ is 18
>
> }
> td_submit_urb (urb);
>
> the second is around line 582:
> switch (usb_pipetype (pipe)) {
> case PIPE_BULK: /* one TD for every 4096 Byte */
> size = (urb->transfer_buffer_length - 1) / 4096 +
> 1;
> break;
> case PIPE_ISOCHRONOUS: /* number of packets from URB */
> size = urb->number_of_packets;
> if (size <= 0) {
> usb_dec_dev_use (urb->dev);
> return -EINVAL;
> }
> for (i = 0; i < urb->number_of_packets; i++) {
> urb->iso_frame_desc[i].actual_length = 0;
> urb->iso_frame_desc[i].status = -EXDEV;
>
> ^^^^^ is
> 18
>
> }
> break;
> case PIPE_CONTROL: /* 1 TD for setup, 1 for ACK and 1 for
> every
>
>
> And here ends my knowledge. Sorry.
Mine too :-( It seems related to re-submitting URBs to the ISOC chain, but
I�m not sure.
This is with 2.2.4-pre-5/6, btw, but the problem has been there with his
hardware for a long time.
- Nemosoft
-----------------------------------------------------------------------------
Try SorceryNet! One of the best IRC-networks around! irc.sorcery.net:9000
URL: never IRC: nemosoft IscaBBS (bbs.isca.uiowa.edu): Nemosoft
>> Never mind the daylight <<
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
