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