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 -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
