On 16-11-24 11:43 AM, Mark Lord wrote: ..
But how does this ASCII data end up at offset zero of the rx buffer?? Not possible -- this isn't even stale data, because only an rx_desc could be at that offset in that buffer.
Answering my own question here, I suspect it ends up there as a result of overrunning the previous URB. So I have updated the test copy of the driver here now to check for that exact situation. It's running now, but could take hours or a day for the bug to occur again. It seems I am being overly helpful here. Perhaps I should have just stopped with the original regression report (driver works in 3.12.xx, fails on all newer kernels, as a result of enabling hardware checksums). Had I left it there, one might reasonably expect the onus to be on the driver developer to sort it out, with me providing retests of supplied patches as need be. But I've gone WAY BEYOND that, even questioning the sanity of the platform on which it is being used, just to avoid blaming a buggy USB dongle for some other issue. And this is leading people to suspect that I really think the platform is buggy. It isn't. It's been running for years, with a variety of USB hardware attached, and nary a problem. Except with this r8152 dongle on kernels > 3.12. So, yeah, the driver is fixed in our local tree, and has been for some time now. I just was hoping that perhaps others might be interested in it too, since the bug (whatever it is) corrupts data on the NFS server. Cheers -- 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
