On Mon, Oct 17, 2011 at 5:53 PM, Alan Stern <stern@xxxxxxxxxxxxxxxxxxx> wrote: > On Sun, 16 Oct 2011, Steve Calfee wrote: > >> >> The device transfers data in the "not working" case, it's just that >> >> the MPEG TS sync byte is not where Markus expects it, which could >> >> be explained by a partial MPEG TS packet left in the device's FIFO >> >> from previous interaction. >> > >> > But why does this happen only when the transfer size is different from >> > 24064? Why doesn't it also happen when the transfer size _is_ 24064? >> > >> > Alan Stern >> > >> Hi Johannes, Alan, >> >> My $.02. The problem is bulk packet size is 512 bytes. The moronic >> device wants packets of 188 bytes. The least common divisor of those >> two numbers is 24064. > > That's not how I'd describe it. The device sends blocks of 188 bytes, > and it packs these blocks into 512-byte packets. > >> Somewhere way back in this thread, I think it said this device sent >> data to the host via IN packets. So if you asked for anything less >> than 24062 bytes, say 188*2=376, because the moronic device has to >> send its 188 packets in 512 byte usb packets, it would do a data >> overrun, because it would send 512 bytes (device does not know the urb >> size). Asking for two urbs one of 376 and the other 24064-376 would >> not work because the first urb would get a transfer error. > > But that's not what Markus did. He asked for 12288 (= 512*24) bytes > and then asked for 11776 (= 512*23) bytes. The device did send that > much data (it adds up to 24064 bytes), but for some unknown reason the > data values were wrong. > >> The solution for this kind of broken device is either, change limits > > It's not clear that the device is broken. Indeed, it's not clear at > all how the device managed to send bad data when asked for 12288 + > 11776 bytes but good data when asked for 24064 bytes. In principle it > should have had no way of knowing how big the transfers were; it should > have sent the same 47 packets in either case. Maybe there's something > Markus hasn't told us. > >> in the usbdevfs (which of course will only fix this one particular >> weirdo - what if the next weird device chose 187 or even 511?), or >> make the vendor/community come up with a kernel driver for the bad >> device. The kernel driver, is of course what they must have used in >> windows. I would really like to know what virtual machine writers do >> for guest hosts on this device, I suspect problems. I suspect it would >> not work with vmware even for a windows guest on a windows host. Maybe >> it would work if windows allow really big (24064 byte) transfers. >> >> In any case, the ability of a windows driver (written of course by the >> vendor) to work around really broken devices is no help in getting >> rational, useful devices into the world. > > The increased limits allowed by my upcoming patches should help. We'll > see what happens. > HW engineers are checking the device again also with bus analyzer. I also end up that there must be some issue with the device as the other devices just work fine with bulk and small buffers. I'll see what will come up for that one. For the other device I wonder why the no interrupt flag doesn't seem to help, does a short transfer automatically trigger an interrupt when the device is set to use small buffers? BR, Markus > Alan Stern > > -- 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
