Bug 8254
| Summary: | dvgrab 2.1 exposes bug in raw1394 driver/module | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Brad (madderbrad) |
| Component: | IEEE1394 | Assignee: | drivers_ieee1394 |
| Status: | REJECTED INVALID | ||
| Severity: | low | CC: | madderbrad |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.19.1 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
ctrl[4000880e] i.e. IR DMA ContextControl.event_code = 0xe = evt_unknown means "An error condition has occurred that cannot be represented by any other event codes defined [in OHCI 1.1 table 3-2 pp 18-19]." It's a pity that the controller is unable to signal more detailed error information to the drivers. I lodged this bug in error. I have since realised that my slow system (800MHz Pentium III Coppermine CPU) was slowed down ever further due to my storing the fetched digital video data on an *encrypted* filesystem. Encryption (using loop-AES) consumes significant CPU and adds considerably to the processing required for disk I/O. Using a 'plain' ext2 filesystem dvgrab worked much better. dvgrab 1.2, using dv1394, still seems a little better - failing twice in fetching 60 minutes of video with the errors originally logged - than dvgrab 2.1 and raw1394, which failed four times. When I originally logged this bug report I stated that dvgrab 1.2 & dv1394 'worked'; in actuality it would fail on my system after 3-5 minutes. Still, the comparison between dvgrab 1.2 & dvgrab 2.1 on my system, with and without the load of using an encrypted filesystem, would seem to suggest that dvgrab 2.1 & raw1394 puts more of a load on the machine than dvgrab 1.2 & dv1394, and so will fail more easily/often on a loaded machine. But on a more modern PC I doubt the difference would be of any significance. In any case, without the added load of storing data to an encrypted filesystem, dvgrab 2.1 and the raw1394 driver, while still failing - presumably still due to performance problems/latency - is usable on my old machine. |
Distribution: Slackware 11.0 Hardware Environment: Generic 2001 PC Software Environment: Linux 2.6.19.1 kernel, dvgrab 2.1, libraw1394 1.2.1 Problem Description: dvgrab 2.1 won't work on my (six-year-old) PC; it fails with these error messages logged: kernel: ohci1394: fw-host0: Unrecoverable error! kernel: ohci1394: fw-host0: Iso Recv 0 Context died: ctrl[4000880e] cmdptr[1644454f] match[f000003f] On the advice of Stefan Richter of the Linux 1394 project I regressed back to dvgrab 1.2, which works. Stefan says that dvgrab 1.2 uses dv1394, while dvgrab 2.1 uses (lib)raw1394, and suggested that I log this bug report so it's noted that there are still problems with raw1394, forcing at least one application/user to regress to using dv1394. Steps to reproduce: With dvgrab 2.1 I run the command and see output as follows: # dvgrab --noavc --autosplit --format raw t. Found AV/C device with GUID 0x080046010258baad "" -4424042283008.00 MB 0 frames Capture Stopped Error: no DV These kernel messages are logged: kernel: ohci1394: fw-host0: Unrecoverable error! kernel: ohci1394: fw-host0: Iso Recv 0 Context died: ctrl[4000880e] cmdptr[1644454f] match[f000003f] Using a newly-compiled dvgrab 1.2 (to link in the current libraries for dv1394 etc) I run the same command, which works as expected with no error messages. OTHER DETAILS: - *control* of the Sony DVR-TR17E camcorder - causing it to PLAY or STOP - with both dvgrab 2.1 and also 'gscanbus', works fine. - An 'lspci -v' lists this for my 1394 controller card: 00:0e.0 FireWire (IEEE 1394): Agere Systems FW323 (rev 04) (prog-if 10 [OHCI]) Subsystem: Pinnacle Systems Inc. Unknown device 000e Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at de800000 (32-bit, non-prefetchable) [size=4K] Capabilities: [44] Power Management version 2