On Thursday 20 January 2005 8:07 am, Olav Kongas wrote: > > What happened for OUT transfers longer than > MAX_TRANSFER_SIZE_FULLSPEED was that the first PTD was sent > and then, without "break-ing" there, the urb was finished > with return code 0. With this bug, the usbtests worked (at > least in my case), because the g_zero driver at the other > end didn't care whether it got f.ex. 4096 or just first > 832 bytes.
Actually you can kick in some data pattern testing on both ends, which should catch some of these bugs. The "mod63" pattern for example would I think catch this one. > The aim is to get this stuff ready for inclusion into the > mainline. The 2.6.11-rc1 contains changes that made hcd-s > incompatible with 2.6.10. Therefore, the planning is to > debug the driver now on the 2.6.9-10 level, which allows > people to test and use it. But then I have to break the > compatibility to move on. As the backward compatibility, > perhaps even to 2.6.10, is not needed when already in > kernel then upstream kernel people would probably complain > about such an extra baggage in the driver. I would, if I > would be one of them :) I think those 2.6.11 changes can all be characterized as streamlining the HCD glue, which will make adding new HCDs easier in the future. Most of the 2.4.11 changes are ones that should trigger compile time errors with older code. So prepping a version to submit for 2.6.11 (please do!) should be easy, and most patches for one version should apply to the other. And while the downside of those changes is some code thrash right now, the upside includes not needing to worry about a lot of usbcore bugs -- sometimes dating back to 2.4.early or even earlier! -- going forward. > > Running test #11 > > TEST 11: unlink 1000 reads of 512 > > isp116x-hcd : Unlink after no-IRQ? Different ACPI or APIC settings may > > help. > > I have seen this particular error a lot. Mostly with timed > plug-upplug cycles. I have tried to chase down the cause, > but failed thus far. When you get the first IRQ, there's a flag to be set ... that's just a warning to catch IRQ misconfiguration, very common on PCs and something the USB developers can't help with. You must not be setting that flag. The latest kernels don't mention ACPI or APIC, so they make sense even on kernels that don't have such concepts. (Or on kernels that do, where there's a different root cause.) > Great that you see so many tests running flawless, at least > for 1000 cycles. Yes! Among other things, it means that when someone uses this HCD with a "real" USB device driver, it should be a lot easier to sort out any bug reports. Mostly, they won't be in the HCD ... ;) - Dave ------------------------------------------------------- This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting Tool for open source databases. Create drag-&-drop reports. Save time by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc. Download a FREE copy at http://www.intelliview.com/go/osdn_nl _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
