"Nemosoft Unv." wrote:
>
> 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.
>
Which driver, which hardware?
> 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.
>
-EXDEV (-18) means that the frame descriptor is empty
(has not been processed).
May be the URB never really come to the HCD?
Does the completion handler reads only its own URB or also
other URBs?
What does the webcam driver expect from the ->next pointer stuff?
Do you use start frame numbers or ASAP flag in the URBs.
- Roman
> > 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
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
http://lists.sourceforge.net/lists/listinfo/linux-usb-devel
