Bug 8457
Summary: | Iso xmit stops upon bus reset | ||
---|---|---|---|
Product: | Drivers | Reporter: | Robert Crocombe (rcrocomb) |
Component: | IEEE1394 | Assignee: | drivers_ieee1394 |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | protasnb |
Priority: | P2 | ||
Hardware: | i386 | ||
OS: | Linux | ||
Kernel Version: | 2.6.21 but main 2.6.20-rt8 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: | Test program to do iso xmit and bus resets |
Description
Robert Crocombe
2007-05-08 17:19:25 UTC
Created attachment 11440 [details]
Test program to do iso xmit and bus resets
Reply-To: stefanr@s5r6.in-berlin.de bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=8457 > > Summary: Iso xmit stops upon bus reset > Kernel Version: 2.6.21 but main 2.6.20-rt8 > Status: NEW > Severity: normal > Owner: drivers_ieee1394@kernel-bugs.osdl.org > Submitter: rcrocomb@ieee.org > > > Most recent kernel where this bug did *NOT* occur: None. > Distribution: Fedora Core 5 > Hardware Environment: 4-way Opteron: IWill H8502-based > Software Environment: > Problem Description: > > During some testing, we were encountering bus resets which caused programs doing > isochronous transmits to hang. Investigation with a bus analyzer showed that > isochronous traffic from the machine stopped when the bus reset occurred. It > seems likely that the programs were blocking at the read() in > raw1394_loop_iterate(). > > Further investigation using a small test program seemed to indicate that whether > transmission stops is directly dependent upon the frequency of the transmission: > higher frequency transmissions (1kHz) are more likely to stop than low frequency > (10Hz). Cycle starts are continuing through the reset (as much as they can), > and other sources of isochronous traffic do continue to transmit. > > Sticking calls to raw1394_iso_stop() and then raw1394_iso_xmit_start() inside > the bus reset handler make it more likely that the transmission will survive a > bus reset, but are not 100% effective. > > The behavior was first noticed with Unibrain Fireboard 800s, but appears > repeatable and the test program was run on a PCI-Express card from AvLab that > uses TI's 1394 chipset. > > There's a graph of reset behavior vs frequency at: > > http://rcrocomb.googlepages.com/isoxmitbehavioruponreset > > Most of this work was done under 2.6.20-rt8, but I can confirm that it does > occur under 2.6.21, though less frequently. I will run the numbers and report back. > > > Steps to reproduce: > > Run test program which accepts, via '-f' a transmission frequency. Bus resets > will start after a few seconds and the program will terminate once transmission > seems to have stalled. > > ------- You are receiving this mail because: ------- > You are the assignee for the bug, or are watching the assignee. Any progress on this bug? was any testing done with latest kernel, is the bug still there? Thanks. I am not aware of anyone working on this. Perhaps I should start sending ~monthly "known bugs" lists to linux1394-devel (maybe also linux1394-user) to motivate passers-by to join the effort. I should note that I no longer work at the same job, and no longer do 1394b development. I've passed the bug # along to the appropriate people who will presumably be picking up the effort. |