- I had made further investigations into why , after calling schedule(), the process hangs.
By added a few more printk() messages , this seems to be the reason:
When using the device with it's default USB setting (MxPS = 252), after
shecdule () ( which is in VIODICSYNC handler) we reach the
interrupt handler ( which is called pwc_isoc_handler() ).
We do reach this handler about 60 times;
It has a flag there which is called awake;
During a loop on the packets , after about 60 times entering the pwc_isoc_handler(),
some condition which is checked in that loop becomes , for the first time, to be TRUE,
and then we call wake_up_interruptible().
When using the device with it's default USB setting (MxPS = 196), this
conditions probably does not become TRUE , and we reach this callback endlessly.
This what causes the process to hang.
I do not have any idea wht this happens.
Could it be that there is some reason that this device, altough it have an alternate setting of MxPs of 196, could not be used with this MxPS ?
It seems to me unwise that a device will have alternate setting which cannot be used,
but I really don't know much about this.
Below is a part of that handler , which demonstartes what I am talking about.
(from pwc-if.c):
/* This gets called for the Isochronous pipe (video). This is done in
* interrupt time, so it has to be fast, not crash, and not stall. Neat.
*/
static void pwc_isoc_handler(struct urb *urb)
{
struct pwc_device *pdev;
int i, fst, flen;
int awake;
struct pwc_frame_buf *fbuf;
unsigned char *fillptr, *iso_buf;....................
....................
for (i = 0; i < urb->number_of_packets; i++) {
....................
....................
if (pdev->drop_frames)
pdev->drop_frames--;
else {
/* Check for underflow first */
if (fbuf->filled < pdev->frame_size) {
pdev->vframes_error++;
}
else {
/* Send only once per EOF */
awake = 1; /* delay wake_ups */
....................................
...................................
if (awake)
{
wake_up_interruptible(&pdev->frameq);
}
regards, John
From: Alan Stern <[EMAIL PROTECTED]>
To: John Que <[EMAIL PROTECTED]>
CC: [EMAIL PROTECTED], <[EMAIL PROTECTED]>
Subject: Re: [linux-usb-devel] usb_set_interface() to a different alternate setting
Date: Wed, 30 Jun 2004 11:18:36 -0400 (EDT)
On Wed, 30 Jun 2004, John Que wrote:
> Hello,
> I must now add , that it seems to me ,after adding some printk() messages,
> that after calling usb_set_interface() with alternate setting 1 (the
> alternate setting to which I
> try to change and with which the application hangs in ioctl () as I
> al;ready described in my fist post)
> the endpoint DOES NOT stall.
>
> What I did is:
> I added before , and after , usb_set_interface() , the following 2 printk():
>
> Err(KERN_ERR "[pwc-if.c] pdev->udev->halted[0]
> %d\n",pdev->udev->halted[0]);
> Err(KERN_ERR "[pwc-if.c] pdev->udev->halted[1]
> %d\n",pdev->udev->halted[1]);
>
> and both values are 0 , before and after the call.
>
> Also when I try to call usb_set_interface() with alternate setting 3, which
> succeeds and does not hang , all these halt flag values are 0.
>
> I don't know wheterh this check is accurate; after looking at
> usb_endpoint_halt macro in usb.h , it seems to me that possibly this
> means wheteher the endpoint is halted/stalled or not.
No it doesn't. The udev->halted[] arrays are unreliable and are due to be removed from the USB stack.
If you want to tell whether an endpoint is stalled, there are two possible ways to do it. You can try to send data to or from the endpoint. Or you can issue a Get-Status request for the endpoint (see Section 9.4.5 and Figure 9-6 in the USB 2.0 Specification).
Alan Stern
_________________________________________________________________
Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 - digital self defense, top technical experts, no vendor pitches, unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
