2009/9/27 Joris van Rantwijk <jorispubl@xxxxxxxxx>: > On 26 sep 2009, at 06:54, Alan Stern wrote: >>> >>> When reading data from a high speed device with usbserial.ko, I sometimes >>> get corruct data. > >> Have you tried using your device on a different computer with a >> different sort of motherboard? If the problem still occurs then most >> likely it's in the device, not in the computer hardware. > > My device is running home-made firmware so it can not be trusted. > > However, I'm quite sure that something bad happens in the computer. > I modified usb-serial to fill the transfer buffer with 0xFF just before > submitting the URB. This shows that sometimes the URB returns with status=0 > and the expected value in actual_length, but the last 4 bytes with respect > to actual_length still contain 0xFF. So clearly the host controller is > screwing up. > > The issue is related to alignment of the transfer_buffer address. > The problem does not occur when transfer_buffer is at least 64-byte aligned. > > usb-serial allocates its transfer buffers with kmalloc(). Normally this > would result in aligned buffers. But I was running with CONFIG_DEBUG_SLAB=y > which changes the alignment guarantees for kmalloc(). After turning off > CONFIG_DEBUG_SLAB, the problem disappeared. It is very odd, and how can you see the alignment of kmalloc is violated if CONFIG_DEBUG_SLAB=y? > > So it seems that my VT62xx EHCI controller will occasionally screw up > a DMA transfer if the transfer buffer is not favorably aligned. Not sure > what to do with that information. DMA transfer requires that the transfer buffer is cache aligned, or else your problem is understandable. > > I must say I am also surprised at the behaviour of kmalloc. I'd think there > are several drivers that implicitly expect aligned buffers from kmalloc. The buffer allocated by kmalloc should be cache aligned, and it is a basic requirement for kmalloc in fact. -- Lei Ming -- 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