I'm trying to use 2.6.28 for the first time on an x86_64 box here
with devices controlled by libusb. The devices work on the first
access, but then fail on all subsequent accesses. Unplugging/replugging
causes them to work again for a single subsequent access.
This is with two completely different USB gadgets:
a VFD alphanumeric display, and an FTDI serial device in bitbang mode.
Did something break in 2.6.28 for libusb devices ??
Cheers
Mark Lord wrote:
> I'm trying to use 2.6.28 for the first time on an x86_64 box here
> with devices controlled by libusb. The devices work on the first
> access, but then fail on all subsequent accesses. Unplugging/replugging
> causes them to work again for a single subsequent access.
>
> This is with two completely different USB gadgets:
> a VFD alphanumeric display, and an FTDI serial device in bitbang mode.
>
> Did something break in 2.6.28 for libusb devices ??
..
Mmm.. broken only for 64-bit userspace, it seems.
I've recompiled the same app against 32-bit libs,
and it works just fine on that 64-bit system,
as well as on 32-bit systems.
But not when compiled for pure 64-bit operation on a 64-bit system.
Looks tricky .. must be a change somewhere that assumes
a pointer/long is 32-bits or something.
-ml
On Fri, Jan 02, 2009 at 02:01:21AM -0500, Mark Lord wrote:
> Mark Lord wrote:
>> I'm trying to use 2.6.28 for the first time on an x86_64 box here
>> with devices controlled by libusb. The devices work on the first
>> access, but then fail on all subsequent accesses. Unplugging/replugging
>> causes them to work again for a single subsequent access.
>> This is with two completely different USB gadgets:
>> a VFD alphanumeric display, and an FTDI serial device in bitbang mode.
>> Did something break in 2.6.28 for libusb devices ??
> ..
>
> Mmm.. broken only for 64-bit userspace, it seems.
>
> I've recompiled the same app against 32-bit libs,
> and it works just fine on that 64-bit system,
> as well as on 32-bit systems.
>
> But not when compiled for pure 64-bit operation on a 64-bit system.
>
> Looks tricky .. must be a change somewhere that assumes
> a pointer/long is 32-bits or something.
Which version of libusb, a new one was just released a few weeks ago
that fixes a lot of problems reported in the older libusb versions, and
made things much faster to boot. You might want to check it out.
Hope this helps,
greg k-h
Greg KH wrote:
> On Fri, Jan 02, 2009 at 02:01:21AM -0500, Mark Lord wrote:
>> Mark Lord wrote:
>>> I'm trying to use 2.6.28 for the first time on an x86_64 box here
>>> with devices controlled by libusb. The devices work on the first
>>> access, but then fail on all subsequent accesses. Unplugging/replugging
>>> causes them to work again for a single subsequent access.
>>> This is with two completely different USB gadgets:
>>> a VFD alphanumeric display, and an FTDI serial device in bitbang mode.
>>> Did something break in 2.6.28 for libusb devices ??
>> ..
>>
>> Mmm.. broken only for 64-bit userspace, it seems.
>>
>> I've recompiled the same app against 32-bit libs,
>> and it works just fine on that 64-bit system,
>> as well as on 32-bit systems.
>>
>> But not when compiled for pure 64-bit operation on a 64-bit system.
>>
>> Looks tricky .. must be a change somewhere that assumes
>> a pointer/long is 32-bits or something.
>
> Which version of libusb, a new one was just released a few weeks ago
> that fixes a lot of problems reported in the older libusb versions, and
> made things much faster to boot. You might want to check it out.
..
I might look at that someday, but in the meanwhile we have broken
userspace in 2.6.28, and that needs to be sorted out first.
I'm still poking around, but haven't spotted anything obvious
from working kernel 2.6.27.xx to failing kernel 2.6.28.
One minor nit did show up, though. The patch below
seems to make more sense than the code does without it.
Signed-off-by: Mark Lord <[email protected]>
--- old/drivers/usb/core/devio.c 2008-12-24 18:26:37.000000000 -0500
+++ linux/drivers/usb/core/devio.c 2009-01-02 02:44:57.000000000 -0500
@@ -1318,7 +1318,7 @@
if (__get_user(uptr, &uurb->buffer))
return -EFAULT;
kurb->buffer = compat_ptr(uptr);
- if (__get_user(uptr, &uurb->buffer))
+ if (__get_user(uptr, &uurb->usercontext))
return -EFAULT;
kurb->usercontext = compat_ptr(uptr);
Greg KH wrote:
> On Fri, Jan 02, 2009 at 02:01:21AM -0500, Mark Lord wrote:
>> Mark Lord wrote:
..
>> Mmm.. broken only for 64-bit userspace, it seems.
>>
>> I've recompiled the same app against 32-bit libs,
>> and it works just fine on that 64-bit system,
>> as well as on 32-bit systems.
>>
>> But not when compiled for pure 64-bit operation on a 64-bit system.
..
> Which version of libusb, a new one was just released a few weeks ago
> that fixes a lot of problems reported in the older libusb versions, and
> made things much faster to boot. You might want to check it out.
..
This is with libusb-0.1-4, which has been working fine with all prior kernels,
including the 2.6.27.xx series.
Userspace stuff like this is not supposed to be broken from kernel to kernel.
Cheers
On Fri, Jan 02, 2009 at 02:51:13AM -0500, Mark Lord wrote:
> Greg KH wrote:
>> On Fri, Jan 02, 2009 at 02:01:21AM -0500, Mark Lord wrote:
>>> Mark Lord wrote:
> ..
>>> Mmm.. broken only for 64-bit userspace, it seems.
>>>
>>> I've recompiled the same app against 32-bit libs,
>>> and it works just fine on that 64-bit system,
>>> as well as on 32-bit systems.
>>>
>>> But not when compiled for pure 64-bit operation on a 64-bit system.
> ..
>> Which version of libusb, a new one was just released a few weeks ago
>> that fixes a lot of problems reported in the older libusb versions, and
>> made things much faster to boot. You might want to check it out.
> ..
>
> This is with libusb-0.1-4, which has been working fine with all prior
> kernels,
> including the 2.6.27.xx series.
>
> Userspace stuff like this is not supposed to be broken from kernel to
> kernel.
No it shouldn't, I was thinking this was the first time you had tried
such a thing (64bit userspace apps.)
If using 2.6.27 works, then we need to fix this.
thanks,
greg k-h
Greg KH wrote:
> On Fri, Jan 02, 2009 at 02:51:13AM -0500, Mark Lord wrote:
>> Greg KH wrote:
>>> On Fri, Jan 02, 2009 at 02:01:21AM -0500, Mark Lord wrote:
>>>> Mark Lord wrote:
>> ..
>>>> Mmm.. broken only for 64-bit userspace, it seems.
>>>>
>>>> I've recompiled the same app against 32-bit libs,
>>>> and it works just fine on that 64-bit system,
>>>> as well as on 32-bit systems.
>>>>
>>>> But not when compiled for pure 64-bit operation on a 64-bit system.
>> ..
>>> Which version of libusb, a new one was just released a few weeks ago
>>> that fixes a lot of problems reported in the older libusb versions, and
>>> made things much faster to boot. You might want to check it out.
>> ..
>>
>> This is with libusb-0.1-4, which has been working fine with all prior
>> kernels,
>> including the 2.6.27.xx series.
>>
>> Userspace stuff like this is not supposed to be broken from kernel to
>> kernel.
>
> No it shouldn't, I was thinking this was the first time you had tried
> such a thing (64bit userspace apps.)
>
> If using 2.6.27 works, then we need to fix this.
..
Yup. I don't really see anything likely in kernel from 2.6.27 to 2.6.28,
other than perhaps the new "poisoning" code. I wonder if that could be it?
Kinda weird that the device works with libusb the first time it is used,
but then fails on all subsequent runs of the same app, until replugged.
But.. I can run the 32-bit compat app after a 64-bit failure,
and *that* does work. There's gotta be a useful clue in there somewhere.
Cheers
Mark Lord wrote:
> Greg KH wrote:
>> On Fri, Jan 02, 2009 at 02:51:13AM -0500, Mark Lord wrote:
>>> Greg KH wrote:
>>>> On Fri, Jan 02, 2009 at 02:01:21AM -0500, Mark Lord wrote:
>>>>> Mark Lord wrote:
>>> ..
>>>>> Mmm.. broken only for 64-bit userspace, it seems.
>>>>>
>>>>> I've recompiled the same app against 32-bit libs,
>>>>> and it works just fine on that 64-bit system,
>>>>> as well as on 32-bit systems.
>>>>>
>>>>> But not when compiled for pure 64-bit operation on a 64-bit system.
>>> ..
>>>> Which version of libusb, a new one was just released a few weeks ago
>>>> that fixes a lot of problems reported in the older libusb versions, and
>>>> made things much faster to boot. You might want to check it out.
>>> ..
>>>
>>> This is with libusb-0.1-4, which has been working fine with all prior
>>> kernels,
>>> including the 2.6.27.xx series.
>>>
>>> Userspace stuff like this is not supposed to be broken from kernel to
>>> kernel.
>>
>> No it shouldn't, I was thinking this was the first time you had tried
>> such a thing (64bit userspace apps.)
>>
>> If using 2.6.27 works, then we need to fix this.
> ..
>
> Yup. I don't really see anything likely in kernel from 2.6.27 to 2.6.28,
> other than perhaps the new "poisoning" code. I wonder if that could be it?
>
> Kinda weird that the device works with libusb the first time it is used,
> but then fails on all subsequent runs of the same app, until replugged.
>
> But.. I can run the 32-bit compat app after a 64-bit failure,
> and *that* does work. There's gotta be a useful clue in there somewhere.
..
It is failing on the very first submiturb call, getting -ENOENT back:
open("/dev/bus/usb/004/002", O_RDWR) = 3
ioctl(3, USBDEVFS_GETDRIVER, 0x7fff5d0486b0) = -1 ENODATA (No data available)
ioctl(3, USBDEVFS_CLAIMINTERFACE, 0x7fff5d0487bc) = 0
ioctl(3, USBDEVFS_CLEAR_HALT, 0x7fff5d0487c4) = 0
ioctl(3, USBDEVFS_SUBMITURB, 0x7fff5d0486c0) = -1 ENOENT (No such file or directory)
On Fri, Jan 02, 2009 at 03:15:20AM -0500, Mark Lord wrote:
> Greg KH wrote:
>> On Fri, Jan 02, 2009 at 02:51:13AM -0500, Mark Lord wrote:
>>> Greg KH wrote:
>>>> On Fri, Jan 02, 2009 at 02:01:21AM -0500, Mark Lord wrote:
>>>>> Mark Lord wrote:
>>> ..
>>>>> Mmm.. broken only for 64-bit userspace, it seems.
>>>>>
>>>>> I've recompiled the same app against 32-bit libs,
>>>>> and it works just fine on that 64-bit system,
>>>>> as well as on 32-bit systems.
>>>>>
>>>>> But not when compiled for pure 64-bit operation on a 64-bit system.
>>> ..
>>>> Which version of libusb, a new one was just released a few weeks ago
>>>> that fixes a lot of problems reported in the older libusb versions, and
>>>> made things much faster to boot. You might want to check it out.
>>> ..
>>>
>>> This is with libusb-0.1-4, which has been working fine with all prior
>>> kernels,
>>> including the 2.6.27.xx series.
>>>
>>> Userspace stuff like this is not supposed to be broken from kernel to
>>> kernel.
>> No it shouldn't, I was thinking this was the first time you had tried
>> such a thing (64bit userspace apps.)
>> If using 2.6.27 works, then we need to fix this.
> ..
>
> Yup. I don't really see anything likely in kernel from 2.6.27 to 2.6.28,
> other than perhaps the new "poisoning" code. I wonder if that could be it?
>
> Kinda weird that the device works with libusb the first time it is used,
> but then fails on all subsequent runs of the same app, until replugged.
>
> But.. I can run the 32-bit compat app after a 64-bit failure,
> and *that* does work. There's gotta be a useful clue in there somewhere.
Hm, care to run 'git bisect'?
Or do you have a simple (or complex) test program that I can run here to
do the same thing?
thanks,
greg k-h
Greg KH wrote:
..
> Hm, care to run 'git bisect'?
..
No, thanks. But the number of USB core changes in 2.6.28 is rather small,
so I just ended up looking at each of them in more detail.
This patch, below, FIXES it for me, by undoing a change from 2.6.28.
Signed-off-by: Mark Lord <[email protected]>
--- old/drivers/usb/core/driver.c 2008-12-24 18:26:37.000000000 -0500
+++ linux/drivers/usb/core/driver.c 2009-01-02 04:34:11.000000000 -0500
@@ -279,9 +279,7 @@
* altsetting means creating new endpoint device entries).
* When either of these happens, defer the Set-Interface.
*/
- if (intf->cur_altsetting->desc.bAlternateSetting == 0)
- ; /* Already in altsetting 0 so skip Set-Interface */
- else if (!error && intf->dev.power.status == DPM_ON)
+ if (!error && intf->dev.power.status == DPM_ON)
usb_set_interface(udev, intf->altsetting[0].
desc.bInterfaceNumber, 0);
else
In article <[email protected]> you wrote:
>
> Hm, care to run 'git bisect'?
>
> Or do you have a simple (or complex) test program that I can run here to
> do the same thing?
Greg, the same issue also happens with libgphoto2 / libusb.
I was pointed to this bug + fix:
http://article.gmane.org/gmane.linux.usb.general/13442
http://bugzilla.kernel.org/show_bug.cgi?id=12301
Ciao, Marcus
On Fri, 2 Jan 2009, Mark Lord wrote:
> Greg KH wrote:
> ..
> > Hm, care to run 'git bisect'?
> ..
>
> No, thanks. But the number of USB core changes in 2.6.28 is rather small,
> so I just ended up looking at each of them in more detail.
>
> This patch, below, FIXES it for me, by undoing a change from 2.6.28.
>
> Signed-off-by: Mark Lord <[email protected]>
>
> --- old/drivers/usb/core/driver.c 2008-12-24 18:26:37.000000000 -0500
> +++ linux/drivers/usb/core/driver.c 2009-01-02 04:34:11.000000000 -0500
> @@ -279,9 +279,7 @@
> * altsetting means creating new endpoint device entries).
> * When either of these happens, defer the Set-Interface.
> */
> - if (intf->cur_altsetting->desc.bAlternateSetting == 0)
> - ; /* Already in altsetting 0 so skip Set-Interface */
> - else if (!error && intf->dev.power.status == DPM_ON)
> + if (!error && intf->dev.power.status == DPM_ON)
> usb_set_interface(udev, intf->altsetting[0].
> desc.bInterfaceNumber, 0);
> else
For a proper fix, see
http://bugzilla.kernel.org/show_bug.cgi?id=12301#c13
A corresponding patch has been posted to linux-usb here:
http://marc.info/?l=linux-usb&m=123074111001861&w=2
I have no idea what's going on with the 64-bit vs. 32-bit stuff,
though.
Alan Stern
Alan Stern wrote:
> On Fri, 2 Jan 2009, Mark Lord wrote:
..
>> This patch, below, FIXES it for me, by undoing a change from 2.6.28.
>>
>> Signed-off-by: Mark Lord <[email protected]>
>>
>> --- old/drivers/usb/core/driver.c 2008-12-24 18:26:37.000000000 -0500
>> +++ linux/drivers/usb/core/driver.c 2009-01-02 04:34:11.000000000 -0500
>> @@ -279,9 +279,7 @@
>> * altsetting means creating new endpoint device entries).
>> * When either of these happens, defer the Set-Interface.
>> */
>> - if (intf->cur_altsetting->desc.bAlternateSetting == 0)
>> - ; /* Already in altsetting 0 so skip Set-Interface */
>> - else if (!error && intf->dev.power.status == DPM_ON)
>> + if (!error && intf->dev.power.status == DPM_ON)
>> usb_set_interface(udev, intf->altsetting[0].
>> desc.bInterfaceNumber, 0);
>> else
>
> For a proper fix, see
>
> http://bugzilla.kernel.org/show_bug.cgi?id=12301#c13
>
> A corresponding patch has been posted to linux-usb here:
>
> http://marc.info/?l=linux-usb&m=123074111001861&w=2
..
Mmm.. too bad linux-kernel wasn't CC'd on that, or I might have
found the patch and saved some sleep. Good to see that it has
been fixed down in a subsystem tree, though.
> I have no idea what's going on with the 64-bit vs. 32-bit stuff, though.
..
Yeah, something is very broken somewhere, because the _compat ioctl()s
should really produce the same behaviour as the 64-bit ones.
Looking forward to seeing this regression fixed in mainline ASAP.
Cheers