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
