Bugzilla will be upgraded to version 5.0 on a still to be determined date in the near future. The original upgrade date has been delayed.
First Last Prev Next    This bug is not in your last search results.
Bug 58785 - Errors on SA1110 bulk IN transfers
Errors on SA1110 bulk IN transfers
Status: CLOSED WONTFIX
Product: eCos
Classification: Retired
Component: USB driver (Show other bugs)
CVS
strongarm Linux
low Severity medium
: ---
: ---
Assigned To: Bart Veer
eCos bugs internal list
:
Depends On:
Blocks:
  Show dependency tree / graph
 
Reported: 2002-01-24 09:51 EST by Bart Veer
Modified: 2007-03-26 23:51 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-01-24 10:46:42 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Add an attachment (proposed patch, testcase, etc.)

  None (edit)
Description Bart Veer 2002-01-24 09:51:14 EST 
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.
Comment 1 Bart Veer 2002-01-24 10:15:25 EST 
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.
Comment 2 Alex Schuilenburg 2002-01-24 10:46:36 EST 
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 :-/
Comment 3 Bart Veer 2002-01-24 12:04:58 EST 
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.
Comment 4 Alex Schuilenburg 2002-01-24 12:42:00 EST 
If the SA1110 is so broken that it cannot run automated tests, what about the
MIPS LAKI USB hardware?
Note You need to log in before you can comment on or make changes to this bug.
First Last Prev Next    This bug is not in your last search results.