On Sat, Feb 27, 2010 at 06:38:09AM +0100, Markus Rechberger wrote: > On Sat, Feb 27, 2010 at 6:26 AM, Greg KH <greg@xxxxxxxxx> wrote: > > On Fri, Feb 26, 2010 at 09:17:37PM -0800, Greg KH wrote: > >> On Sat, Feb 27, 2010 at 05:34:27AM +0100, Markus Rechberger wrote: > >> > On Sat, Feb 27, 2010 at 5:29 AM, Linus Torvalds > >> > <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote: > >> > > > >> > > > >> > > On Fri, 26 Feb 2010, Greg KH wrote: > >> > >> > >> > >> Yes, and that patch didn't touch the iso frames. ?That happens later on > >> > >> in the functions that were modified. ?The patch should not have had any > >> > >> affect on iso transfers. ?Unless I'm missing something? > >> > > > >> > > Hmm. What seems to happen is that for an isochronous transfer, the buffer > >> > > is split for each microframe. No? > >> > > > >> > > >> > exactly. and each microframe has its own buffer length identifier. > >> > > >> > the current behaviour breaks VMware, QEMU and virtualbox .. probably > >> > other things too. > >> > > >> > > >> > > So the total length may be in 'urb->actual_length', but the actual data in > >> > > the buffer may not be contiguous, because it's created from multiple > >> > > smaller frames, some of which might not be full length? > >> > > > >> > > >> > yes, it's only contiguous for BULK. > >> > > >> > > I dunno. That would explain the problem - actual_length is correct, but > >> > > the 'copy_to_user()' still doesn't copy all the data, because it's > >> > > fragmented. > >> > > > >> > > >> > no you got it, but your patch does not work. The best way would be to > >> > revert it if someone wants to speed up BULK it should go down another > >> > path, leaving the old working implementation untouched. > >> > >> Hm, so it's back to the original idea of just doing a kzalloc of the > >> initial buffer, that should solve the problem that Marcus found. > >> > >> I'll go dig that back up and if you could test it, that would be most > >> appreciated. > > > > Here, can you try this on top of everything? > > > > just tested it, everything's back to normal again now! Thanks for testing, I'll queue it up for Linus and then add it back to .32-stable. Linus, I know you didn't want to do a kzalloc, but it looks like this is the easiest/simplest thing to do, unless you can think of something else? 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
