Hello, Thnxs. Alan wrote:
but when you added printk() statements there none of them got triggered. Doesn't that indicate that the hang occurs somewhere else, not where you thought?
I was a little inaccurate ; I added some printk() messages in pwc_video_ioctl()'s
VIDIOCSYNC handler , but they were at the end of the ioctl() case :
when I added more printk() today I trace exactly the place when the trouble is caused : there
is a call to schedule() in that VIDIOCSYNC handler ; we do not reach after that call (natuarally as control is passed to another thread by the scheduler).
I assume it shoul reach some callback in the pwc driver but I'm not sure , and do not know which.
I'll try adding printk() with the driver without changing its alternate setting.
Alan said:
One test you could do is simply to repeat the usb_set_interface() call; just issue the same call twice in a row.
I'll try it immediately tomorrow as I am not near my development envronment now.
I could not have imagined to think of a test like that. Thanks a lot !
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:11:05 -0400 (EDT)
On Wed, 30 Jun 2004, John Que wrote:
> Second:
> I did try to add usb_set_interface(pdev->udev, 0, 0)
> before usb_set_interface(pdev->udev, 0, 1); and it still hangs in the same
> place.
You said before that the driver was hanging in pwc_video_ioctl()'s VIDIOCSYNC handler, but when you added printk() statements there none of them got triggered. Doesn't that indicate that the hang occurs somewhere else, not where you thought?
> But still usb_pipeendpoint() and pdev->vendpoint returns 5 as before;
> I do not understand from where is this "5" , in all three cases: when using
> alternate
> setting 1 and 2 and 3. In fact I do not understand its meaning.
Every USB device can have up to 30 endpoints, and each endpoint is assigned a number between 1 and 15 (an input endpoint and an output endpoint may share the same number). But the numbers don't have to be consecutivee. So there's no reason why a camera with 2 endpoints might not choose to number them 2 and 5.
> Fourth : > Gerald said: > >Try getting the device status > >just after changing the setting to see if the setting that you choose > >did not stall the camera. > > If you can be more specific: what and how should I do it (which method > to call and what to check ) in order to find out if the setting that I > choose > did not stall the camera ,I will be thankful; I am quite a newbie in USB > matters.
One test you could do is simply to repeat the usb_set_interface() call; just issue the same call twice in a row. If the second one succeeds then the first one did not totally hang the camera.
Alan Stern
_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963
-------------------------------------------------------
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
