Hide Forgot
Description of Problem: With an SA1110-based board such as the PLC2, the USB testing infrastructure reveals problems with bulk IN transfers. There appear to be two separate error conditions: sometimes the host reports receiving a short packet, even though the target believes that the whole transfer completed; and sometimes the host detects a stall condition, even though the target-side device driver has not set that condition. The problem is sporadic and typically only happens after some hundreds of transfers. Enabling any kind of diagnostics in the target makes the problem much less likely to appear, although occasional failures have still been detected. Version-Release number of selected component (if applicable): How Reproducible: Every time. Steps to Reproduce: 1.use the following test script in conjunction with the USB testing infrastructure (call it e.g. bulk.tcl) usbtest::bulktest 2 in 4000 txsize1 900 txsize+ 1 format=byteseq data1 0 data+ 1 \ rxdelay1 20000000 if { [usbtest::start 240] } { puts "Test successful" } else { puts "Test failed" foreach result $usbtest::results { puts $result } } 2. run usbtarget on e.g. a PLC2 board. Do not enable any diagnostics, but optionally enable the heartbeat thread to be sure that the target stays up. 3. run "usbhost -V -V bulk.tcl" on the host. Actual Results: After some random number of iterations, (60, 900, ...) the testing infrastructure reports a failure. Expected Results: The test should run to completion and perform 4000 bulk transfers, then report success. Additional Information: The host is running a 2.4.9-12 kernel, single-processor, with the usb-uchi module driving the USB bus.
Unfortunately there is no way of knowing whether this is a problem with the SA11x0 USB hardware (yet another one), with the Linux host, with the target-side USB driver, or with either the target-side or host-side USB testing infrastructure. Even with proper debugging tools such as a CATC USB protocol analyser it would not be easy to track down this problem. Without such tools it is nearly impossible. Using the best estimation tools available to me for this kind of problem, i.e. a set of dice, I believe that fixing this will take nine months, one week, 3 days, and 7 hours.Approximately.
If you have seriously no idea on how long it will take to find and fix this problem, then no time can be allocated to fix this. Estimation needs to be taken seriously and until it is done so, no time can be allocated to fixing this problem. No sane manager will allocate time to an unknown entity. Please come up with a realistic estimate or change the status to WONTFIX :-/
Realistic estimation is only possible on the basis of certain assumptions, for example that the hardware mostly conforms to the specification. If you cannot make such assumptions then no sane engineer is going to commit to any kind of estimate. In this case the problem is most likely caused by another bug in the SA11x0 silicon. It is impossible to predict how long it will take to work around this bug, or even whether or not a viable workaround can be developed at all. Previous experience with the SA1110 USB device suggests that it could take hours, days, weeks, or even months to make any kind of progress. There is no way of knowing, so the existing estimate is just as valid as any other I might put forward. So as instructed I am marking this bug as WONTFIX and closing the report. Note that this will make it impossible to do any type of automated USB testing in the testfarm, at least not with SA11x0 hardware.
If the SA1110 is so broken that it cannot run automated tests, what about the MIPS LAKI USB hardware?