Menu
▾
▴
libusb-devel
|
From: <sha...@ya...> - 2007-11-27 14:08:34
|
Hi,
I'm writing a test application on Linux 2.6.10 running
on a ARM based platform. This application uses libusb
to talk to a Microsoft's device from user space. When
I run this app for the first time it detects the
device and performs the I/O normally. But when I stop
the application and start again, it is unable to
detect the device (but the kernel has not
re-enumerated it and the entries in
/proc/bus/usb/devices are intact). I detect the device
as a Microsoft device by reading the device's string
descriptor.
The following is the pseudo code.
Device_detect_function
{
usb_open
read string descriptor and find out whether it
has Microsoft OS descriptor
usb_close
}
Device_io_function
{
usb_open
usb_claim_interface
:
:
usb_release_interface
usb_close
}
I'm using usb_claim_interface before performing any
I/Os as per libusb documentation. During application
exit irrespective of whether usb_release_interface is
called or not I get a error message
usb 1-1: a.out timed out on ep0out
This message is coming from usb/core/message.c -
Function usb_start_wait_urb. But I'm not sure which
urb is timing out on the control endpoint because we
are not scheduling any control out message explicitly
from the application. After this when I re-run the
application its unable to read the string descriptor
properly. I assume this is because I haven't cleaned
up something during my first application exit. I
modified the code by commenting the
usb_claim_interface and usb_release_interface and this
time I was not getting that time out message and I was
able to detect the device properly even after stopping
and starting the application. But this is of no use
since I cannot do any I/O to the device without
claiming its interface. I tried the same with
different devices and the behavior is same.
Can some one please tell me what is the correct way to
claim and release the interface ? Any help on
debugging this problem will be of great help.
Warm Regards,
Shankar
____________________________________________________________________________________
Be a better pen pal.
Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/
|
|
From: Tim R. <ti...@pr...> - 2007-11-27 17:38:31
|
sha...@ya... wrote: > I'm using usb_claim_interface before performing any > I/Os as per libusb documentation. During application > exit irrespective of whether usb_release_interface is > called or not I get a error message > > usb 1-1: a.out timed out on ep0out > > This message is coming from usb/core/message.c - > Function usb_start_wait_urb. But I'm not sure which > urb is timing out on the control endpoint because we > are not scheduling any control out message explicitly > from the application. Are you using select_interface or select_configuration? Both of those send control messages. > After this when I re-run the > application its unable to read the string descriptor > properly. I assume this is because I haven't cleaned > up something during my first application exit. What type of device is it? Is it possible the device is being handled by some other driver? You might try calling usb_clear_halt on endpoint 0 just after claiming the interface, in case some request did cause confusion. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: <sha...@ya...> - 2007-11-28 13:39:59
|
> Are you using select_interface or > select_configuration? Both of those > send control messages. > What type of device is it? Is it possible the > device is being handled > by some other driver? I'm not calling select_interface, select_configuration APIs from the application. The device talks MTP (Media Transfer Protocol) and in the interface descriptor the Class, protocol, sub-class fields are all 0xFF (Vendor specific). This means no other standard class driver has claimed this device. I tried calling usb_clear_halt without much success. But what I observed is that when I try to close the application "Set Inteface" control request is sent to the device. I'm surprised that this happens when we close the application and not when I call usb_claim_interface. I assume that this is from the USB stack since its not sent from the application. I tried my application with a Sandisk PMP (Sansa) which is also an MTP device. There is no time out happenning as it happens in the other one, but its control endpoint becomes un-usable after receiving the "Set Interface" control request. This gives me a feeling that we shouldn't be sending this request in the first place, but I don't know how to prevent this from the application. Any suggestions would of great help. -Shankar --- Tim Roberts <ti...@pr...> wrote: > sha...@ya... wrote: > > I'm using usb_claim_interface before performing > any > > I/Os as per libusb documentation. During > application > > exit irrespective of whether usb_release_interface > is > > called or not I get a error message > > > > usb 1-1: a.out timed out on ep0out > > > > This message is coming from usb/core/message.c - > > Function usb_start_wait_urb. But I'm not sure > which > > urb is timing out on the control endpoint because > we > > are not scheduling any control out message > explicitly > > from the application. > > Are you using select_interface or > select_configuration? Both of those > send control messages. > > > After this when I re-run the > > application its unable to read the string > descriptor > > properly. I assume this is because I haven't > cleaned > > up something during my first application exit. > > What type of device is it? Is it possible the > device is being handled > by some other driver? > > You might try calling usb_clear_halt on endpoint 0 > just after claiming > the interface, in case some request did cause > confusion. > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio > 2005. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > ____________________________________________________________________________________ Get easy, one-click access to your favorites. Make Yahoo! your homepage. http://www.yahoo.com/r/hs |
|
From: Tim R. <ti...@pr...> - 2007-11-28 17:22:08
|
sha...@ya... wrote: > I tried calling usb_clear_halt without much success. > But what I observed is that when I try to close > the application "Set Inteface" control request is sent > to the device. I'm surprised that this happens > when we close the application and not when I call > usb_claim_interface. I assume that this is from the > USB stack since its not sent from the application. No, neither usb_claim_interface nor usb_release_interface triggers any bus traffic. They're all just driver housekeeping. The libusb routines just call a single ioctl each, and you can trace through the kernel code to convince yourself. There's only one libusb call that triggers a "set interface" request, and that's usb_set_altinterface. You might try running strace, to see if you can identify exactly where this request comes from. > I tried my application with a Sandisk PMP (Sansa) > which is also an MTP device. There is no time out > happenning > as it happens in the other one, but its control > endpoint becomes un-usable after receiving the "Set > Interface" control request. Well, if a device doesn't have any alternate settings, it is supposed to stall the "set interface" request. However, if that was the case, usb_clear_halt should have fixed it up. > This gives me a feeling > that we shouldn't be sending this request in the first > place, but I don't know how to prevent this from the > application. Any suggestions would of great help. All I can suggest is posting a copy of your shutdown code. -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: <sha...@ya...> - 2007-12-05 08:01:04
Attachments:
usb_test.c
|
Hi, Part of the problem got fixed. The issue was with the firmware. The device was supporting only default interface but was not handling SET_INTERFACE request properly and was getting into a loop. We made it to return STALL on this request and things are working now. But i've not figured out who sends the SET_INTERFACE request from the Host. I'm attaching the the shut down code here. By any chance does the USB Stack sends this request by itself? Warm Regards, Shankar --- Tim Roberts <ti...@pr...> wrote: > sha...@ya... wrote: > > I tried calling usb_clear_halt without much > success. > > But what I observed is that when I try to close > > the application "Set Inteface" control request is > sent > > to the device. I'm surprised that this happens > > when we close the application and not when I call > > usb_claim_interface. I assume that this is from > the > > USB stack since its not sent from the application. > > No, neither usb_claim_interface nor > usb_release_interface triggers any > bus traffic. They're all just driver housekeeping. > The libusb routines > just call a single ioctl each, and you can trace > through the kernel code > to convince yourself. There's only one libusb call > that triggers a "set > interface" request, and that's usb_set_altinterface. > > You might try running strace, to see if you can > identify exactly where > this request comes from. > > > I tried my application with a Sandisk PMP (Sansa) > > which is also an MTP device. There is no time out > > happenning > > as it happens in the other one, but its control > > endpoint becomes un-usable after receiving the > "Set > > Interface" control request. > > Well, if a device doesn't have any alternate > settings, it is supposed to > stall the "set interface" request. However, if that > was the case, > usb_clear_halt should have fixed it up. > > > This gives me a feeling > > that we shouldn't be sending this request in the > first > > place, but I don't know how to prevent this from > the > > application. Any suggestions would of great help. > > All I can suggest is posting a copy of your shutdown > code. > > -- > Tim Roberts, ti...@pr... > Providenza & Boekelheide, Inc. > > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux > Business White Paper > from Novell. From the desktop to the data center, > Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs |
|
From: Lei C. <Ray...@Su...> - 2007-12-05 08:37:45
|
sha...@ya... wrote: > Hi, > Part of the problem got fixed. The issue was with > the firmware. The device was supporting only default > interface but was not handling SET_INTERFACE request > properly and was getting into a loop. We made it to > return STALL on this request and things are working > now. But i've not figured out who sends the > SET_INTERFACE request from the Host. I'm attaching the > the shut down code here. By any chance does the USB > Stack sends this request by itself? > I have ever encountered similar issue on a Nokia phone - N93. On Linux, the usb_set_altinterface is called at a session end to set the syncml interface's alternate setting to 0. But this function on Solaris doesn't really send SET_INTERFACE to the device. That causes the device's internal status doesn't return to a right state after a session, though I believe that's a bug in the device's firmware. From experience of that bug, I think only usb_set_altinterface can send SET_INTERFACE request to a device on Linux. Are you sure you didn't call usb_set_altinterface() during the process? Regards, Lei Chen > Warm Regards, > Shankar > > --- Tim Roberts <ti...@pr...> wrote: > > >> sha...@ya... wrote: >> >>> I tried calling usb_clear_halt without much >>> >> success. >> >>> But what I observed is that when I try to close >>> the application "Set Inteface" control request is >>> >> sent >> >>> to the device. I'm surprised that this happens >>> when we close the application and not when I call >>> usb_claim_interface. I assume that this is from >>> >> the >> >>> USB stack since its not sent from the application. >>> >> No, neither usb_claim_interface nor >> usb_release_interface triggers any >> bus traffic. They're all just driver housekeeping. >> The libusb routines >> just call a single ioctl each, and you can trace >> through the kernel code >> to convince yourself. There's only one libusb call >> that triggers a "set >> interface" request, and that's usb_set_altinterface. >> >> You might try running strace, to see if you can >> identify exactly where >> this request comes from. >> >> >>> I tried my application with a Sandisk PMP (Sansa) >>> which is also an MTP device. There is no time out >>> happenning >>> as it happens in the other one, but its control >>> endpoint becomes un-usable after receiving the >>> >> "Set >> >>> Interface" control request. >>> >> Well, if a device doesn't have any alternate >> settings, it is supposed to >> stall the "set interface" request. However, if that >> was the case, >> usb_clear_halt should have fixed it up. >> >> >>> This gives me a feeling >>> that we shouldn't be sending this request in the >>> >> first >> >>> place, but I don't know how to prevent this from >>> >> the >> >>> application. Any suggestions would of great help. >>> >> All I can suggest is posting a copy of your shutdown >> code. >> >> -- >> Tim Roberts, ti...@pr... >> Providenza & Boekelheide, Inc. >> >> >> >> > ------------------------------------------------------------------------- > >> SF.Net email is sponsored by: The Future of Linux >> Business White Paper >> from Novell. From the desktop to the data center, >> Linux is going >> mainstream. Let it simplify your IT future. >> >> > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > >> _______________________________________________ >> Libusb-devel mailing list >> Lib...@li... >> >> > https://lists.sourceforge.net/lists/listinfo/libusb-devel > > > > > ____________________________________________________________________________________ > Never miss a thing. Make Yahoo your home page. > http://www.yahoo.com/r/hs > > ------------------------------------------------------------------------ > > ------------------------------------------------------------------------- > SF.Net email is sponsored by: The Future of Linux Business White Paper > from Novell. From the desktop to the data center, Linux is going > mainstream. Let it simplify your IT future. > http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 > > ------------------------------------------------------------------------ > > _______________________________________________ > Libusb-devel mailing list > Lib...@li... > https://lists.sourceforge.net/lists/listinfo/libusb-devel > |
|
From: Tim R. <ti...@pr...> - 2007-12-05 17:34:55
|
sha...@ya... wrote: > Part of the problem got fixed. The issue was with > the firmware. The device was supporting only default > interface but was not handling SET_INTERFACE request > properly and was getting into a loop. We made it to > return STALL on this request and things are working > now. But i've not figured out who sends the > SET_INTERFACE request from the Host. I'm attaching the > the shut down code here. By any chance does the USB > Stack sends this request by itself? > No. Remember that this is Linux -- you can go look at the source code yourself. Looking through the Linux driver, the only call that sends the SET_INTERFACE request is usb_set_interface. The only place that's called in the usbfs driver is from the USBDEVFS_SETINTERFACE ioctl. The only place that ioctl is called from libusb is in usb_set_altinterface. The 2.4 kernels never sent this request at all unless you had multiple alternate settings. Is this device in a class that has a standard kernel driver? -- Tim Roberts, ti...@pr... Providenza & Boekelheide, Inc. |
|
From: Karl O. P. <ko...@me...> - 2007-12-05 17:58:01
|
On 12/05/2007 11:34:46 AM, Tim Roberts wrote:
> No. Remember that this is Linux -- you can go look at the source code
> yourself. Looking through the Linux driver, ...
Oooh, oooh, oooh! I know! ctags/etags is your friend!
(grep, etc., is so handy I always forget and am excited
again when I use etags to poke around the source.
Yes, it's basic. I guess I'm just simple. :)
Karl <ko...@me...>
Free Software: "You don't pay back, you pay forward."
-- Robert A. Heinlein
|
