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
...

In any case, I have USB tests 1 to 10 working on my end with this change.
Tests 11 to 14 seem to fail, but I haven't looked into those yet.  I want to
run these tests longer and with more varied packet lengths.  Once I have
that done, I will try to minimize the code changes I had to introduce and
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
remaining big endian/little endian swaps.

Test reults so far (using keyspan USBserial device):

Kernel messages:
TEST 0:  NOP
Running test #1
TEST 1:  write 512 bytes 1000 times
Running test #2
TEST 2:  read 512 bytes 1000 times
Running test #3
TEST 3:  write/512 0..512 bytes 1000 times
Running test #4
TEST 4:  read/512 0..512 bytes 1000 times
Running test #5
TEST 5:  write 1000 sglists 32 entries of 512 bytes
Running test #6
TEST 6:  read 1000 sglists 32 entries of 512 bytes
Running test #7
TEST 7:  write/512 1000 sglists 32 entries 0..512 bytes
Running test #8
TEST 8:  read/512 1000 sglists 32 entries 0..512 bytes
Running test #9
TEST 9:  ch9 (subset) control tests, 1000 times
Running test #10
TEST 10:  queue 32 control calls, 1000 times
Running test #11
TEST 11:  unlink 1000 reads of 512
isp116x-hcd : Unlink after no-IRQ?  Different ACPI or APIC settings may
help.
Running test #12
TEST 12:  unlink 1000 writes of 512
Running test #13
TEST 13:  set/clear 1000 halts
Running test #14

Test script:
bash-2.05# ./suite.sh
Testing USB device at /proc/bus/usb/001/002
microcontroller type: fx
single stage:  load on-chip memory
open RAM hexfile image testfw.hex
stop CPU
write on-chip, addr 0x0000 len    3 (0x0003)
write on-chip, addr 0x0043 len    3 (0x0003)
write on-chip, addr 0x0128 len    3 (0x0003)
write on-chip, addr 0x012c len    3 (0x0003)
write on-chip, addr 0x0200 len  206 (0x00ce)
... WROTE: 218 bytes, 5 segments, avg 43
reset CPU
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 0,    0.035345 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 1,    1.061372 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 2,    1.060375 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 3,    1.069374 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 4,    1.068374 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 5,   32.075662 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 6,   32.074663 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 7,   32.079662 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 8,   32.078660 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 9,   27.070864 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 10,  102.057484 secs
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 11 --> 104 (error 104)
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 12 --> 104 (error 104)
./testusb: /proc/bus/usb/001/002 may see only control tests
/proc/bus/usb/001/002 test 13 --> 22 (error 22)
./testusb: /proc/bus/usb/001/002 may see only control tests



-----Original Message-----
From: Olav Kongas [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 20, 2005 9:35 AM
To: Philipp Schmid
Cc: linux-usb-devel@lists.sourceforge.net
Subject: RE: [linux-usb-devel] isp116x-hcd update




On Wed, 19 Jan 2005, Philipp Schmid wrote:

> I have captured a few dumps when this failure is happening.  It ~always~
> happens to the same type of transfer:
>
> Enqueue: FA 2 ep2in bulk: len 13 short_ok
> pack_fifo @ c5d6/2e9c fmrem
> CC=f EP=2 DIR=2 CNT=0 LEN=13 MPS=64 TGL=1 ACT=1 FA=2 SPD=0 LST=1 B5=0
>   fc00 2840 080d 0002
> unpack_fifo @ c5d7/73 fmrem
> CC=f EP=2 DIR=2 CNT=0 LEN=13 MPS=64 TGL=1 ACT=1 FA=2 SPD=0 LST=1 B5=0
>   fc00 2840 080d 0002

Philipp, thank you for the failure logs. Could you please
try whether the patch below cures the problem, if applied to
the latest driver version.

Olav

--- linux-2.6.9-isp/drivers/usb/host/isp116x-hcd.c.or   2005-01-20
14:21:53.000000000 +0200
+++ linux-2.6.9-isp/drivers/usb/host/isp116x-hcd.c      2005-01-20
15:14:38.000000000 +0200
@@ -344,7 +344,7 @@ static void postproc_atl_queue(struct is
                cc = PTD_GET_CC(ptd);

                spin_lock(&urb->lock);
-        short_not_ok = urb->transfer_flags & URB_SHORT_NOT_OK;
+        short_not_ok = 1;

         /* Data underrun is special. For allowed underrun
            we clear the error and continue as normal. For
@@ -353,9 +353,10 @@ static void postproc_atl_queue(struct is
            we do a STATUS stage.
         */
                if (cc == TD_DATAUNDERRUN){
-          if (! short_not_ok){
+          if (! (urb->transfer_flags & URB_SHORT_NOT_OK)){
                        DBG("Allowed data underrun\n");
                        cc = TD_CC_NOERROR;
+            short_not_ok = 0;
           }else{
             ep->error_count = 1;
                        if (usb_pipecontrol(urb->pipe))




-------------------------------------------------------
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