libusb-devel Mailing List for libusb

#129: stray fprintf()
------------------------+----------------------
 Reporter:  fcusack     |       Owner:
     Type:  defect      |      Status:  closed
Component:  libusb-1.0  |  Resolution:  invalid
 Keywords:              |  Blocked By:
   Blocks:              |
------------------------+----------------------
Changes (by stuge):

 * status:  new => closed
 * resolution:   => invalid


Comment:

 The current linux_usbfs.c in libusb.git doesn't have any fprintf() calls.
 Please remember to always check the current code. The fprintf() was
 removed by commit 22d61cd0891d8304dfc1a70579cf154fd8e6644a.

-- 
Ticket URL: <http://libusb.org/ticket/129#comment:1>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace

#129: stray fprintf()
-------------------------+----------------
  Reporter:  fcusack     |     Owner:
      Type:  defect      |    Status:  new
 Component:  libusb-1.0  |  Keywords:
Blocked By:              |    Blocks:
-------------------------+----------------
 linux_usbfs.c:op_open()

 around line 1043 there is an fprintf().  This obviously doesn't honor
 LIBUSB_DEBUG and does not belong there.  This probably should be
 usbi_err().

-- 
Ticket URL: <http://libusb.org/ticket/129>
libusb <http://libusb.org/>
C library for writing portable USB drivers in userspace

Le 7 février 2012 18:07, Ludovic Rousseau <lud...@gm...> a écrit :
> 2012/2/7 Alan Stern <st...@ro...>:
>> On Tue, 7 Feb 2012, Ludovic Rousseau wrote:
>>
>>> 2012/2/7 Alan Stern <st...@ro...>:
>>> > On Tue, 7 Feb 2012, Peter Stuge wrote:
>>> >
>>> >> Ludovic Rousseau wrote:
>>> >> > > Is it a timeout? LIBUSB_ERROR_TIMEOUT is there.
>>> >> >
>>> >> > It is not a timeout. LIBUSB_ERROR_TIMEOUT is used for
>>> >> > kIOUSBTransactionTimeout. kIOReturnNotResponding is something else
>>> >> > like: the device is dead.
>>> >>
>>> >> Can we find out more specifically what this error means? Perhaps
>>> >> _NO_DEVICE would fit, but this guessing is not so useful without
>>> >> knowing exactly what the error really means.
>>> >
>>> > If Mac OS X is at all like Linux, this error means that there was a
>>> > low-level communications problem.  Most likely the device is dead or
>>> > was unplugged and therefore did not reply to a packet sent by the host,
>>> > but it's also possible (though unlikely) that electrical noise in a USB
>>> > cable interfered with the normal signals.
>>>
>>> We are debugging the issue. Maybe it is a device firmware or hardware bug.
>>>
>>> The problem happens (when it happens) always at the same exchange so
>>> an electrical noise would be strange. Unless the device _generates_
>>> the noise.
>>>
>>> We used a USB hardware analyser. After some (short) time the iMac
>>> stopped polling the device for no obvious reasons. So the device
>>> stopped NAKing and could not send the answer when ready.
>>
>> Have you tried testing the same program under Linux or Windows?
>
> Yes. No problem on Linux as far as I have tested.
> I also have no problem on the other Apple computers I could use. Only
> one iMac exhibits the problem. It is a iMac model 10,1 to be specific.
> And it looks like the problem is related to the USB port used to
> connect the device. Maybe it is related with the SD card reader also
> on the same USB bus.
>
> Another option is to install Linux on the iMac and try to reproduce the problem.

I tried this other option.
Using GNU/Linux on the same hardware do not show any problem.

I know OS X is more strict about USB specification. I also tried a
similar device (high speed CCID) from another manufacturer and have
the same problem, but not for the same command. The 2 devices have the
problem on 2 different commands, but always the same command.
On another iMac (model 11,1, more recent) I could reproduce the
problem for every try and not just in ~10% of executions.

I also installed the Mac OS X USB Debug kit [1] to have some/more
kernel logs. I have 15 MB of logs. The interesting part is (I think):

  868.150 [7]    +IOUSBInterfaceUserClientV2[0xffffff8014af4000]::_ReadPipe
  868.150 [7]
+IOUSBInterfaceUserClientV2[0xffffff8014af4000]::ReadPipe (Async)
(pipeRef: 2, 2000, 2000, buffer: 0x7fff625c31d6, size: 10, completion:
0xffffff80fe33bb80)
  868.150 [7]
IOUSBInterfaceUserClientV2[0xffffff8014af4000]::ReadPipe (Async)
creating IOMD:  buffer: 0x7fff625c31d6, size: 10
  868.150 [7]
IOUSBInterfaceUserClientV2[0xffffff8014af4000]::ReadPipe (async)
created IOMD 0xffffff8019bc9100
  868.150 [7]    IOUSBPipe[0xffffff8014b40a80]::Read #2
  868.150 [7]    IOUSBPipe[0xffffff8014b40a80]::Read #3 (addr 2:6 type
2) - reqCount = 10
  868.150 [7]    AppleUSBEHCI[0xffffff8013b11000]::Read - reqCount = 10
  868.150 [7]    AppleUSBEHCI[0xffffff8013b11000]::Read - setting
memory descriptor (0xffffff8019bc9100) into dmaCommand
(0xffffff801388fd80)
  868.150 [7]
AppleUSBEHCI[0xffffff8013b11000]::BulkTransaction(2:6(in))
buffer=0xffffff8019bc9100:a
cback=[0xffffff7f80ef75ea:0xffffff8013b11000:0xffffff8013b26d00])
  868.150 [7]
AppleUSBEHCI[0xffffff8013b11000]::UIMCreateBulkTransfer - adr=2:6(in)
cbp=0xffffff8019bc9100:a
cback=[0xffffff7f80ef75ea:0xffffff8013b11000:0xffffff8013b26d00])
  868.150 [3]    AppleUSBEHCI[0xffffff8013b11000]::allocateTDs - queue
for endpoint (6) halted - returning kIOUSBPipeStalled
  868.150 [1]
AppleUSBEHCI[0xffffff8013b11000]::UIMCreateBulkTransfer- allocateTDs
(adr=2:6(in))  returned error e000404f
  868.150 [3]    AppleUSBEHCI[0xffffff8013b11000]::BulkTransaction:
error queueing bulk packet (0xe000404f)
  868.150 [2]    AppleUSBEHCI[0xffffff8013b11000]::DoIOTransfer -
error 0xe000404f (Request returned a STALL) queueing request (Bus:
0x26, Addr: 2, EP: 6  Direction: 1, Type: 2)
  868.150 [2]    AppleUSBEHCI[0xffffff8013b11000]::Read - General
error (0xffffffffe000404f) - cleaning up - command(0xffffff8013b26d00)
dmaCommand(0xffffff801388fd80)
  868.150 [7]    AppleUSBEHCI[0xffffff8013b11000]::Read - sync xfer or
err return - clearing memory descriptor (0xffffff8019bc9100) from
dmaCommand (0xffffff801388fd80)
  868.150 [7]
IOUSBCommandPool[0xffffff8013b15f80]::gatedReturnCommand
0xffffff8013b26d00
  868.150 [2]    IOUSBPipe[0xffffff8014b40a80]::Read  - controller
returned stalled pipe, changing status
  868.150 [5]
IOUSBInterfaceUserClientV2[0xffffff8014af4000]::ReadPipe (async)
returned 0xe000404f (Request returned a STALL)
  868.150 [3]
IOUSBInterfaceUserClientV2[0xffffff8014af4000]::ReadPipe (async -
returning err 0xe000404f (Request returned a STALL)

I will keep you informed.
To be continued...

[1] https://developer.apple.com/hardwaredrivers/download/usbdebug.html

-- 
 Dr. Ludovic Rousseau

On Tue, Feb 28, 2012 at 11:25 PM, Alan Stern <st...@ro...> wrote:
> Under Linux (and under Windows too, I believe) the actual sequence of
> events is this:
>
> 1: The host does a bus reset
> 2: The host sends a Get-Device-Descriptor request
> 3: The device sends the descriptor
> 4: The host does another bus reset
> 5: The host sends a Set-Address request
> 6: The host sends a Get-Device-Descriptor request
> and so on...
>
> Notice there are no bus resets after the Set-Address.

Just a reconfirmation here the above is right for both Windows and Linux.
http://www.cygnal.org/ubb/Forum9/HTML/001325.html

Mac OS X does not seem to have the 2nd reset as per the
above findings by Tsuneo.

> By the way, timing is not very critical.  The device is allowed up to 5
> seconds to respond to the Get-Descriptor and Set-Address requests.
>



-- 
Xiaofan

The problems were mainly
1 - inaccurate values in descriptor
2 - The chip firmware has a function called WriteEP0();
 - The reason of the error was that I had a structure per descriptor and I
called WriteEndpoint() 4 times in this order (config descr , interface
descr , hid descr , ep descr)

- I fixed this by merging all the descriptors in a single structure and
calling WriteEp0() once .

On 28 February 2012 23:23, Ahmed Abdelfattah <
ahm...@gm...> wrote:

> I fixed them thank you :)
>
> On 28 February 2012 19:59, Tim Roberts <ti...@pr...> wrote:
>
>> Ahmed Abdelfattah wrote:
>> > Sorry , Your sequence is exactly right except that the repetition
>> > happens due to the wrong size of Packet size I set -I guess-
>> >
>> > Now I fixed it but I get the dmesg output :
>> >
>> > *config 1 has 0 interface different from the descriptor value : 1
>> > *
>>
>> Post your descriptors and we can critique them for you.
>>
>> --
>> Tim Roberts, ti...@pr...
>> Providenza & Boekelheide, Inc.
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Keep Your Developer Skills Current with LearnDevNow!
>> The most comprehensive online learning library for Microsoft developers
>> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
>> Metro Style Apps, more. Free future releases when you subscribe now!
>> http://p.sf.net/sfu/learndevnow-d2d
>> _______________________________________________
>> Libusb-devel mailing list
>> Lib...@li...
>> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>>
>
>
>
> --
> regards ,
> Ahmed Abdelfattah
>
>
>


-- 
regards ,
Ahmed Abdelfattah

I fixed them thank you :)

On 28 February 2012 19:59, Tim Roberts <ti...@pr...> wrote:

> Ahmed Abdelfattah wrote:
> > Sorry , Your sequence is exactly right except that the repetition
> > happens due to the wrong size of Packet size I set -I guess-
> >
> > Now I fixed it but I get the dmesg output :
> >
> > *config 1 has 0 interface different from the descriptor value : 1
> > *
>
> Post your descriptors and we can critique them for you.
>
> --
> Tim Roberts, ti...@pr...
> Providenza & Boekelheide, Inc.
>
>
>
> ------------------------------------------------------------------------------
> Keep Your Developer Skills Current with LearnDevNow!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-d2d
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel
>



-- 
regards ,
Ahmed Abdelfattah

Ahmed Abdelfattah wrote:
> Sorry , Your sequence is exactly right except that the repetition
> happens due to the wrong size of Packet size I set -I guess-
>
> Now I fixed it but I get the dmesg output :
>
> *config 1 has 0 interface different from the descriptor value : 1
> *

Post your descriptors and we can critique them for you.

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

On 2/28/12 17:25, "Alan Stern" <st...@ro...> wrote:
>
>By the way, timing is not very critical.  The device is allowed up to 5
>seconds to respond to the Get-Descriptor and Set-Address requests.

No disagreeing, but somewhere in that sequence there is a point where
timing is critical. Don't recall the exact point but it was pointed to
me at the spec. But looks like this is not the issue here.

br Kusti

On Tue, 28 Feb 2012, Ahmed Abdelfattah wrote:

> Sorry , Your sequence is exactly right except that the repetition happens
> due to the wrong size of Packet size I set -I guess-
> 
> Now I fixed it but I get the dmesg output :
> 
> *config 1 has 0 interface different from the descriptor value : 1
> *

Well, that's pretty clear isn't it?  When your device sends its 
configuration descriptor, it doesn't send the interface and endpoint 
descriptors at the same time.

Alan Stern

Sorry , Your sequence is exactly right except that the repetition happens
due to the wrong size of Packet size I set -I guess-

Now I fixed it but I get the dmesg output :

*config 1 has 0 interface different from the descriptor value : 1
*
On 28 February 2012 17:25, Alan Stern <st...@ro...> wrote:

> On Tue, 28 Feb 2012, Ahmed Abdelfattah wrote:
>
> > Hello ,
> >
> > I have a ques not related to libusb but to USB generally .
> >
> > I have an ISP1362 usb chip on a development kit , I modified its firmware
> > to act as as HID and I added some printfs to debug the code .
> > During the enumeration this happens :
> >
> > 1 - the host issues a getdescriptor request
> > 2- the device sends the descriptor
> > 3 - the host sets the address of the device
> > 4 - the host does a bus reset
> > 5 - the host issues a getdescriptor request
> > 6 - the device writes the descriptor to the endpoint buffer
> > *7 - the host does a bus reset and then repeat from 1 to 7 infinitely
> >
> > Anyone knows what could the problem be ?*
>
> That sequence of events is very unlikely.  You probably are missing
> something.  Furthermore, the repeats you see in step 7 are not normal;
> they are the result of errors in your device.
>
> Under Linux (and under Windows too, I believe) the actual sequence of
> events is this:
>
> 1: The host does a bus reset
> 2: The host sends a Get-Device-Descriptor request
> 3: The device sends the descriptor
> 4: The host does another bus reset
> 5: The host sends a Set-Address request
> 6: The host sends a Get-Device-Descriptor request
> and so on...
>
> Notice there are no bus resets after the Set-Address.
>
> By the way, timing is not very critical.  The device is allowed up to 5
> seconds to respond to the Get-Descriptor and Set-Address requests.
>
>
> > Thank you  ,
> >
> > I removed all printfs and tried to connect it again but to linux to see
> the
> > output of dmesg and it behaves exactly the same I said before it loops
> > infintely but it only loops for 4 times on windows or linux .
> >
> > dmesg output :
> >
> >
> >    1. [  229.190020] usb 6-1: new full speed USB device using uhci_hcd
> and
> >    address 6
> >    2. [  229.339036] usb 6-1: device descriptor read/all, error -75
>
> This indicates that your device is not sending its device descriptor
> correctly.  Error -75 is -EOVERFLOW, which means the device sent a
> packet that was too large.
>
> What is your device's bMaxPacketSize0?
>
> Alan Stern
>
>


-- 
regards ,
Ahmed Abdelfattah

On Tue, 28 Feb 2012, Ahmed Abdelfattah wrote:

> Hello ,
> 
> I have a ques not related to libusb but to USB generally .
> 
> I have an ISP1362 usb chip on a development kit , I modified its firmware
> to act as as HID and I added some printfs to debug the code .
> During the enumeration this happens :
> 
> 1 - the host issues a getdescriptor request
> 2- the device sends the descriptor
> 3 - the host sets the address of the device
> 4 - the host does a bus reset
> 5 - the host issues a getdescriptor request
> 6 - the device writes the descriptor to the endpoint buffer
> *7 - the host does a bus reset and then repeat from 1 to 7 infinitely
> 
> Anyone knows what could the problem be ?*

That sequence of events is very unlikely.  You probably are missing
something.  Furthermore, the repeats you see in step 7 are not normal;  
they are the result of errors in your device.

Under Linux (and under Windows too, I believe) the actual sequence of
events is this:

1: The host does a bus reset
2: The host sends a Get-Device-Descriptor request
3: The device sends the descriptor
4: The host does another bus reset
5: The host sends a Set-Address request
6: The host sends a Get-Device-Descriptor request
and so on...

Notice there are no bus resets after the Set-Address.

By the way, timing is not very critical.  The device is allowed up to 5
seconds to respond to the Get-Descriptor and Set-Address requests.


> Thank you  ,
> 
> I removed all printfs and tried to connect it again but to linux to see the
> output of dmesg and it behaves exactly the same I said before it loops
> infintely but it only loops for 4 times on windows or linux .
> 
> dmesg output :
> 
> 
>    1. [  229.190020] usb 6-1: new full speed USB device using uhci_hcd and
>    address 6
>    2. [  229.339036] usb 6-1: device descriptor read/all, error -75

This indicates that your device is not sending its device descriptor 
correctly.  Error -75 is -EOVERFLOW, which means the device sent a 
packet that was too large.

What is your device's bMaxPacketSize0?

Alan Stern

Thank you  ,

I removed all printfs and tried to connect it again but to linux to see the
output of dmesg and it behaves exactly the same I said before it loops
infintely but it only loops for 4 times on windows or linux .

dmesg output :


   1. [  229.190020] usb 6-1: new full speed USB device using uhci_hcd and
   address 6
   2. [  229.339036] usb 6-1: device descriptor read/all, error -75
   3. [  229.460024] usb 6-1: new full speed USB device using uhci_hcd and
   address 7
   4. [  229.609036] usb 6-1: device descriptor read/all, error -75
   5. [  229.730016] usb 6-1: new full speed USB device using uhci_hcd and
   address 8
   6. [  229.764034] usb 6-1: device descriptor read/all, error -75
   7. [  229.880018] usb 6-1: new full speed USB device using uhci_hcd and
   address 9
   8. [  229.914038] usb 6-1: device descriptor read/all, error -75
   9. [  229.916035] hub 6-0:1.0: unable to enumerate USB device on port 1


On 28 February 2012 16:30, Kustaa Nyholm <Kus...@pl...> wrote:

> On 2/28/12 15:57, "Ahmed Abdelfattah"
> <ahm...@gm...> wrote:
>
> >Hello ,
> >
> >I have a ques not related to libusb but to USB generally .
> >
> >I have an ISP1362 usb chip on a development kit , I modified its firmware
> >to act as as HID and I added some printfs to debug the code .
> >During the enumeration this happens :
> >
> >1 - the host issues a getdescriptor request2- the device sends the
> >descriptor
> >3 - the host sets the address of the device
> >4 - the host does a bus reset
> >5 - the host issues a getdescriptor request
> >6 - the device writes the descriptor to the endpoint buffer
> >7 - the host does a bus reset and then repeat from 1 to 7 infinitely
> >
> >Anyone knows what could the problem be ?
>
>
> This maybe totally of the mark, but some of this initial phase of device
> enumeration is really timing critical. You cannot have slow printfs
> there, it will not work. I don't recall the details but I wasted
> a few hours there debugging that until someone pointed out to me
> that in the USB spec one or the other of these steps really have
> to be fast.
>
> YMMV
>
> br Kusti
>
>
>
>


-- 
regards ,
Ahmed Abdelfattah

On 2/28/12 15:57, "Ahmed Abdelfattah"
<ahm...@gm...> wrote:

>Hello ,
>
>I have a ques not related to libusb but to USB generally .
>
>I have an ISP1362 usb chip on a development kit , I modified its firmware
>to act as as HID and I added some printfs to debug the code .
>During the enumeration this happens :
>
>1 - the host issues a getdescriptor request2- the device sends the
>descriptor
>3 - the host sets the address of the device
>4 - the host does a bus reset
>5 - the host issues a getdescriptor request
>6 - the device writes the descriptor to the endpoint buffer
>7 - the host does a bus reset and then repeat from 1 to 7 infinitely
>
>Anyone knows what could the problem be ?


This maybe totally of the mark, but some of this initial phase of device
enumeration is really timing critical. You cannot have slow printfs
there, it will not work. I don't recall the details but I wasted
a few hours there debugging that until someone pointed out to me
that in the USB spec one or the other of these steps really have
to be fast.

YMMV

br Kusti

Hello ,

I have a ques not related to libusb but to USB generally .

I have an ISP1362 usb chip on a development kit , I modified its firmware
to act as as HID and I added some printfs to debug the code .
During the enumeration this happens :

1 - the host issues a getdescriptor request
2- the device sends the descriptor
3 - the host sets the address of the device
4 - the host does a bus reset
5 - the host issues a getdescriptor request
6 - the device writes the descriptor to the endpoint buffer
*7 - the host does a bus reset and then repeat from 1 to 7 infinitely

Anyone knows what could the problem be ?*



-- 
regards ,
Ahmed Abdelfattah

The problem was indeed a bug in the EHCI.
The fix has been provided by Alan Stern:
http://marc.info/?l=linux-usb&m=133035621503476&w=2

Adrien

On Fri, Feb 24, 2012 at 12:40 AM, Peter Stuge <pe...@st...> wrote:
> Adrien Decostre wrote:
>> > Thank you very much for this very quick answer.
>> > In fact, I have seen this issue on 2 distinct platforms: on a x64
>> > Ubuntu distribution and on a x64 Angström distribution (the log
>> > reported in the previous mail was obtained on this last machine).
>>
>> I have also just observed that on the Angström machine, the
>> problem appears only when using a particular usb bus.
>
> That's a good find. You should post to the linux-usb mailing list
> which deals with all the kernel drivers for USB, including the EHCI
> controller driver. Make sure to send them all relevant hardware
> details including complete dmesg output and lspci output, along with
> your question.
>
>
>> Up to now, I was mainly looking for a bug in my userspace test
>> application. Apparently, the problem is much more deeper than I
>> thought.
>
> Yes, it's certainly a hardware problem.
>
>
>> collect detailed info about the USB host controller on the machines
>> I am using for this test.
>
> If the HCs connect via PCI or a derivative then lspci -v is basically
> what you need, but please create a new thread on linux-usb, even if
> some of the guys from there are also listening in over here, it's
> better to ask in the right place now that the problem area has been
> identified.
>
>
> //Peter
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

On Wed Jan 11, 2012 at 02:42 AM +0100 Peter Stuge wrote:
> > +		default:
> > +			return ERANGE;

(Sorry for the delay, I overseen your reply.)

> And where did this come from? I agree with the other translations, but
> my kernel devio.c never returns ERANGE?

Well, I supposed it will never be called (= error code out of range).
But looking at the libusb-1.0 source code again, we can also get
LIBUSB_ERROR_NOT_SUPPORTED on Windows and Darwin. ENOSYS seems to be
better.

> (It would be good to have a libusb-1.0 error for EHOSTUNREACH too,
> but oh well.)

op_detach_kernel_driver winn return LIBUSB_ERROR_OTHER and set global
variable errno. Wrapper would handle LIBUSB_ERROR_OTHER as return errno,
so the calling process will get EHOSTUNREACH.

The code can be written without "int r" variable, but I decided to keep
r there. It would make debugging easier and the code will be probably
optimized into the same binary.

>From 4c9f8bcad07a8b9e79a885d9d1d7bc86549cc868 Mon Sep 17 00:00:00 2001
From: Stanislav Brabec <sb...@su...>
Date: Mon, 27 Feb 2012 19:24:23 +0100
Subject: Fix usb_detach_kernel_driver_np() error mapping.
usb_detach_kernel_driver_np from the compat library returns different
error messages than the old libusb0. It causes problems for drivers
that expect exact error code.

Convert libusb1 errors to back to libusb0 errors to get 1:1 mapping of
kernel error codes.

Affected software:
lirc-0.8.7/daemons/hw_srm7500libusb.c: srm7500_initialize_usbdongle()
The function continues if usb_detach_kernel_driver_np() finishes with no
error or if it returns -ENODATA. But the compat layer returns -ENOENT
and the driver considers this error as fatal.

Downstream bug reference:
https://bugzilla.novell.com/show_bug.cgi?id=683307
---
 libusb/core.c |   18 +++++++++++++++++-
 1 files changed, 17 insertions(+), 1 deletions(-)

diff --git a/libusb/core.c b/libusb/core.c
index 04b1822..e26f21b 100644
--- a/libusb/core.c
+++ b/libusb/core.c
@@ -916,6 +916,22 @@ API_EXPORTED int usb_get_driver_np(usb_dev_handle *dev, int interface,
 
 API_EXPORTED int usb_detach_kernel_driver_np(usb_dev_handle *dev, int interface)
 {
-	return compat_err(libusb_detach_kernel_driver(dev->handle, interface));
+	int r = compat_err(libusb_detach_kernel_driver(dev->handle, interface));
+	switch (r) {
+	case LIBUSB_SUCCESS:
+		return 0;
+	case LIBUSB_ERROR_NOT_FOUND:
+		return ENODATA;
+	case LIBUSB_ERROR_INVALID_PARAM:
+		return EINVAL;
+	case LIBUSB_ERROR_NO_DEVICE:
+		return ENODEV;
+	case LIBUSB_ERROR_OTHER:
+		return errno;
+	/* default can be reached in libusb-1.0 only in non-Linux implementations,
+	 * mostly with LIBUSB_ERROR_NOT_SUPPORTED. */
+	default:
+		return ENOSYS;
+	}
 }
 
-- 
1.7.7


-- 
Best Regards / S pozdravem,

Stanislav Brabec
software developer
---------------------------------------------------------------------
SUSE LINUX, s. r. o.                          e-mail: sb...@su...
Lihovarská 1060/12                            tel: +49 911 7405384547
190 00 Praha 9                                  fax: +420 284 028 951
Czech Republic                                    http://www.suse.cz/

gokore wrote:
> I'm willing to develope to something to use libusb 
> now on my working there are some error like that "usb bulk write failed" 
> so I wanted to figuer it out 
>
> at a file that 'linux.c' 
>
> =====================================================================================
>
> ioctl(dev->fd, IOCTL_USB_SUBMITURB, &urb); 
> at that function, return value was '-1' 
> why was that??? 

You are diving in to the lowest level without thinking about the bigger
picture.  The problem is not inside libusb.  Show us YOUR source code.

What kind of device are you driving?  Is this a device you designed? 
Have you verified that there is a bulk pipe with the endpoint number you
are using?  Are you reading or writing?  Are you sure you are reading
from an IN pipe, or writing to an OUT pipe?

-- 
Tim Roberts, ti...@pr...
Providenza & Boekelheide, Inc.

On Mon, 27 Feb 2012, Satpal Chander wrote:

> Peter,
> Thanks for your reply. I have answered below.
> 
> Attached is a zip file contain the relevant information. The _clean logs are
> the ones when the device doesn't have the our usb firmware loaded.
> The others are the ones where the firmware has been loaded.

These lines appear in both of your logs:

libusb:debug [sysfs_scan_device] scan 1-1
libusb:debug [sysfs_scan_device] sysfs descriptors not available

That second one is odd; it shouldn't appear unless you're using a
ridiculously old Linux kernel.

What do you get from "ls -l /sys/bus/usb/devices/usb1"?

Alan Stern

Peter,
Thanks for your reply. I have answered below.

Attached is a zip file contain the relevant information. The _clean logs are
the ones when the device doesn't have the our usb firmware loaded.
The others are the ones where the firmware has been loaded.

Regards
Satpal

> -----Original Message-----
> From: Peter Stuge [mailto:pe...@st...]
> Sent: 23 February 2012 16:11
> To: lib...@li...
> Subject: Re: [Libusb-devel] libusb_get_active_config_descriptor returns
> error not found
> 
> Hi,
> 
> Satpal Chander wrote:
> > We have been using libusb for our linux drivers, we use winusb for the
> > windows.
> 
> So you may be interesting in trying the latest libusb.git code which works
also
> on Windows with WinUSB.
I don't think that is going to be possible as the current code is tried,
tested and rock solid.
One of the main reasons for using libusb is that we can get OSX/Linux in one
go.
 
> > A client asked us to provide a version of our driver that was
> > compatible with Scientific Linux(SL) 5.7, based around Red Hat.
> >
> > I installed SL and compiled the code, relativity straight forward,
> > even with gcc 4.1.2! However when the device is closed and then opened
> > again, the following error occurs:
> >
> > LIBUSB_ERROR_NOT_FOUND when calling
> libusb_get_active_config_descriptor.
> > This call is made after claiming the interface and setting the
> > alternate interface.
> 
> Please show code, lsusb -v for the device and dmesg output, for anyone to
> be able to help you. It would also be interesting to know what version of
> libusb-1.0 the distribution includes.

I have attached two versions of the lsusb -v once for a cold/clean device
with no usb firmware
And once for when the firmware has been loaded.
I am using my own version libusb I took version 1.0.8 as a base and patched
with the race condition fix.
This was to make sure that we controlled what version was used.
 
> > A little more information. First time round when we search for the
> > device it doesn't have any usb firmware so we download the firmware,
> > close the device, reopen the device
> 
> Please show code demonstrating this close and reopen. Does the device
> reset? Does it disconnect? How do you find it again? Etc.
 Basically what we do is:
	Get a device list
	Open the device
	Check the Device ID
	If non valid device id	
		Transfer firmware
		Close device
		Go back to begining
	Else
		Load custom fgpa code
		Start using device

I will get actual code, however I will need to strip out any company
specific items.	

> 
> > use it in the a console test application. When we exit the application
> > and then run it again we the error mentioned above.
> 
> Please provide more information so that someone can help you find the
> reason.
> 
> > Logs have been taken but there doesn't seem to be anything interesting
> > in there, to me anyway.
> 
> This is why you should send them when asking for help. Maybe someone
> else will see something interesting.
> 
> 
> //Peter
> 
>
----------------------------------------------------------------------------
--
> Virtualization & Cloud Management Using Capacity Planning Cloud computing
> makes use of virtualization - but cloud computing also focuses on allowing
> computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Libusb-devel mailing list
> Lib...@li...
> https://lists.sourceforge.net/lists/listinfo/libusb-devel

Hello. 

I am a student at Soongsil university in south korea 

I'm willing to develope to something to use libusb 

now on my working there are some error like that "usb bulk write failed" 

so I wanted to figuer it out 

at a file that 'linux.c' 

=====================================================================================
 
    ret = ioctl(dev->fd, IOCTL_USB_SUBMITURB, &urb); 

  




   if (ret < 0) { 

        printf("DBG>> dev->fd = %d request = %d
\n",dev->fd,IOCTL_USB_SUBMITURB);
 
        printf("DBG>>FIRST IOCTL FAILED\nreturn value = %d ",ret); 

        USB_ERROR_STR(-errno, "error submitting URB: %s", strerror(errno)); 

      return ret; 

    } 


in this part 


ioctl(dev->fd, IOCTL_USB_SUBMITURB, &urb); 

at that function, return value was '-1' 

why was that??? 

plz help me. 

--
View this message in context: http://libusb.6.n5.nabble.com/ioctl-dev-fd-IOCTL-USB-SUBMITURB-urb-returns-1-HELP-ME-PLZ-tp5514459p5514459.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

ㅗ

--
View this message in context: http://libusb.6.n5.nabble.com/I-have-some-trouble-at-iotcl-help-me-PLZ-tp5512639p5514451.html
Sent from the LibUSB Dev mailing list archive at Nabble.com.

On 23 February 2012 13:26, Peter Stuge <pe...@st...> wrote:
> Please describe this calibration in more detail. In particular, focus
> on interaction between the two independent endpoints. Please also
> describe the data being transfered.

I've described the protocol here:
https://gitorious.org/colorhug/firmware/blobs/master/README#line19

>> and seemingly randomly some transfers fail.
>
> "I have random failures. Help."
>
> You need to acquire more information so that you can find the cause
> of the errors. At the very least you could have made a quick
> statistic over request vs. reply failure.

Yes, sorry, I didn't provide anywhere near enough debugging details to
point the finger at libusb, but I was really after some kind of domain
knowledge, like "use a better quality hub" or "use better cables" or
something.

> This assumption is invalid. As Xiaofan already pointed out, this is
> much more likely a problem with the device. Do you also develop the
> device, or is it an off-the-shelf device?

I did indeed develop the device, although I used the Microchip PIC HID
stack as my start point.

> Please describe your bus topology in detail. You should already know
> what this means. Also describe your testing done with various
> topology changes. Different HCs, different hubs, etc.

root hub --> hub in my T510 laptop --> powered hub --> device

> Do you have a bus wire analyzer? Have you even looked with usbmon?

I will borrow a beagle analyser at the weekend and try to work out
what is going on, thanks.

Richard.

Fix the comment at the end of handle_iso_completion, we don't stop on urbs /
iso pkts with less data then requested, and this is a good thing since this
is a normal condition for iso transfers.

Signed-off-by: Hans de Goede <hde...@re...>
---
 libusb/os/linux_usbfs.c |    3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index 6ad48d6..922e597 100644
--- a/libusb/os/linux_usbfs.c
+++ b/libusb/os/linux_usbfs.c
@@ -2125,8 +2125,7 @@ static int handle_iso_completion(struct usbi_transfer *itransfer,
 		break;
 	}
 
-	/* if we're the last urb or we got less data than requested then we're
-	 * done */
+	/* if we're the last urb then we're done */
 	if (urb_idx == num_urbs) {
 		usbi_dbg("last URB in transfer --> complete!");
 		free_iso_urbs(tpriv);
-- 
1.7.7.6

Remove a useless check then set of status because:
1. The check is always true; and
2. The new value status gets set to never gets used

Signed-off-by: Hans de Goede <hde...@re...>
---
 libusb/os/linux_usbfs.c |    3 ---
 1 files changed, 0 insertions(+), 3 deletions(-)

diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index 4e6d784..6ad48d6 100644
--- a/libusb/os/linux_usbfs.c
+++ b/libusb/os/linux_usbfs.c
@@ -2093,9 +2093,6 @@ static int handle_iso_completion(struct usbi_transfer *itransfer,
 	if (tpriv->reap_action != NORMAL) { /* cancelled or submit_fail */
 		usbi_dbg("CANCEL: urb status %d", urb->status);
 
-		if (status == LIBUSB_TRANSFER_COMPLETED)
-			status = LIBUSB_TRANSFER_ERROR;
-
 		if (tpriv->num_retired == num_urbs) {
 			usbi_dbg("CANCEL: last URB handled, reporting");
 			free_iso_urbs(tpriv);
-- 
1.7.7.6

During testing of my usbredir code I hit a case where EOVERFLOW was not handled
in handle_control_completion. Instead of just fixing this one case I've audited
(and fixed where necessary) all handle_foo_completion functions to know about
all errors documented in linux/Documentation/usb/error-codes.txt.

Note that for handle_iso_completion this patch actually removes the handling
of some codes, since these can never occur on an iso urb (they can only
occur on the iso packets included in the urb, see the next patch in this
series). Also in case an unknown status is encountered on an iso urb, this
patch actually sets the urb's status to ERROR, rather then leaving it at
completed.

Signed-off-by: Hans de Goede <hde...@re...>
---
 libusb/os/linux_usbfs.c |   14 +++++++++-----
 1 files changed, 9 insertions(+), 5 deletions(-)

diff --git a/libusb/os/linux_usbfs.c b/libusb/os/linux_usbfs.c
index 099fc61..e5ab1e4 100644
--- a/libusb/os/linux_usbfs.c
+++ b/libusb/os/linux_usbfs.c
@@ -1952,6 +1952,7 @@ static int handle_bulk_completion(struct usbi_transfer *itransfer,
 	case -ENOENT: /* cancelled */
 	case -ECONNRESET:
 		break;
+	case -ENODEV:
 	case -ESHUTDOWN:
 		usbi_dbg("device removed");
 		tpriv->reap_status = LIBUSB_TRANSFER_NO_DEVICE;
@@ -1970,6 +1971,8 @@ static int handle_bulk_completion(struct usbi_transfer *itransfer,
 	case -ETIME:
 	case -EPROTO:
 	case -EILSEQ:
+	case -ECOMM:
+	case -ENOSR:
 		usbi_dbg("low level error %d", urb->status);
 		tpriv->reap_action = ERROR;
 		goto cancel_remaining;
@@ -2081,19 +2084,16 @@ static int handle_iso_completion(struct usbi_transfer *itransfer,
 	case 0:
 		break;
 	case -ENOENT: /* cancelled */
+	case -ECONNRESET:
 		break;
 	case -ESHUTDOWN:
 		usbi_dbg("device removed");
 		status = LIBUSB_TRANSFER_NO_DEVICE;
 		break;
-	case -ETIME:
-	case -EPROTO:
-	case -EILSEQ:
-		usbi_dbg("low-level USB error %d", urb->status);
-		break;
 	default:
 		usbi_warn(TRANSFER_CTX(transfer),
 			"unrecognised urb status %d", urb->status);
+		status = LIBUSB_TRANSFER_ERROR;
 		break;
 	}
 
@@ -2139,6 +2139,7 @@ static int handle_control_completion(struct usbi_transfer *itransfer,
 	case -ENOENT: /* cancelled */
 		status = LIBUSB_TRANSFER_CANCELLED;
 		break;
+	case -ENODEV:
 	case -ESHUTDOWN:
 		usbi_dbg("device removed");
 		status = LIBUSB_TRANSFER_NO_DEVICE;
@@ -2150,6 +2151,9 @@ static int handle_control_completion(struct usbi_transfer *itransfer,
 	case -ETIME:
 	case -EPROTO:
 	case -EILSEQ:
+	case -ECOMM:
+	case -ENOSR:
+	case -EOVERFLOW:
 		usbi_dbg("low-level bus error occurred");
 		status = LIBUSB_TRANSFER_ERROR;
 		break;
-- 
1.7.7.6