On 16-11-13 03:34 PM, Mark Lord wrote: > > The system I use it with is a 32-bit ppc476, with non-coherent RAM, > and using 16KB page sizes. > > The dongle instantly becomes a lot more reliable when r8152.c is updated > to use usb_alloc_coherent() for URB buffers, rather than kmalloc(). > > Not sure why that would be though, as the USB stack normally would handle > kmalloc'd buffers just fine. It is calling the appropriate routines, > which boil down to invalidating the dcache lines (for inbound bulk xfers) > as part of usb_submit_urb(), and yet the problem there persists. > > It could be caused by cache-line sharing with other allocations, but that > seems > unlikely as the kmalloc() size is 16384 bytes per buffer. Perhaps the driver > is somehow accessing the buffer space again after doing usb_submit_urb()? > That would certainly produce this kind of behaviour. > > Or maybe there's just a memory barrier missing somewhere in path. > > The really weird thing is that ASIX-based dongles (which use a different > driver) > don't have this problem, and yet they also use kmalloc'd buffers. > > I have access to the test system only for a day or two a week, > and it takes a few hours to do a good test as to whether something helps or > not. > I'll continue to poke at it as time and New Ideas permit.
Oh, and the problems did not exist with the 3.14.xx kernels and earlier. They began to show up when we tried 3.16.xx and all newer kernels. The difference there is that RX checksums were enabled in hardware as of 3.16.xx, and thus the network stack began accepting bad packets from the r8152 driver. I don't know if the ASIX driver uses hardware checksums or just software checksums. That might explain why it is more reliable here. -- Mark Lord Real-Time Remedies Inc. ml...@pobox.com -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
