On Thu, 20 Jan 2005, Philipp Schmid wrote:
> > Yes ... that did it. I've got my USB hard drive back and can do kernel > compiles on it. However, I don't quite see how that change would affect > anything except for preventing the break call under the USB_PID_IN/OUT case > ... 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. Also, reading from sticks worked fine and obviously I tested only reading from real devices after this change (which, I thought, was just a cleanup, while it introduced such an obvious bug). In your case a large urb was submitted for ep3out. The driver pushed first 832 bytes successfully to ep3out and then finished the urb reporting about having successfully sent all the data. The storage driver then requested 13 bytes from ep2in, but your device didn't give it, because it was still waiting for the rest of the data on ep3out. > that done, I will try to minimize the code changes I had to introduce and I am very much interested in your changes. However, it would be preferable, if you could send your functional changes or bug fixes one by one whenever possible. This would make it easier for me to understand and integrate them (e.g. BE stuff separately etc.). > pass them along to you. I would appreciate if you could accomodate them, so > that your driver can just be dropped into my code. Most of it are functions > that don't exist in 2.6.6 and a few minor USB changes, as well as, the 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 :) IOW, I propose that you maintain the changes to bring the driver from 2.6.9-10 to 2.6.6 yourself. By the way, why can't you upgrade from 2.6.6? > 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. Great that you see so many tests running flawless, at least for 1000 cycles. Olav ------------------------------------------------------- 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
