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

Reply via email to