Bug 4567
| Summary: | capturing from dv-camera (firewire) while any USB2 device is connected causes lockup | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | tommi uimonen (tuimonen) |
| Component: | IEEE1394 | Assignee: | Stefan Richter (stefanr) |
| Status: | REJECTED UNREPRODUCIBLE | ||
| Severity: | high | CC: | stefanr |
| Priority: | P2 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.15.1 | Subsystem: | |
| Regression: | --- | Bisected commit-id: | |
Correction: magic sysrq did not work I reproduced this also from console, stopped all unneccessary daemons to rule them out. And, the capturing needs to be at least few seconds before it hangs. Capture can be stopped with Ctrl-c within the few seconds, but if you let it run, it will eventually hang. Also, grabbing to local disk and just accessing the usb-disk (doing ls or something more) will cause the same errors, but does not lock up (unless the usb-disk is heavily used) OHCI error code 0x5 is "receive FIFO overflowed". I'll try and determine how this can happen and why it would crash the machine. The receive FIFO may overflow because of the PCI bus being too busy, or perhaps too much time spent in an interrupt handler when accessing the USB disk. Does the system still lock up in Linux 2.6.12? If possible, try also 2.6.12 + drivers from linux1394.org, rev 1299. Still happens with 2.6.13.3 All it needs to crash is just any usb device connected. I was capturing to local hard drive and usb card reader was connected -> lockup. I'll try someday to compile all debug options to the kernel and see if I can find any hints. Also I haven't tried with USB1 ports, whether those cause lockups too. My USB2 ports are on a PCI card which has VIA chip (VIA6202 if I remember correctly) I can confirm this bug as well. I was trying to get my new iSight webcam running on 2.6.12 (Mandrake vendor kernel, it is not really vanilla kernel.org one, but the Firewire stuff seems to be identical). After a short while (from few seconds to 2-3 minutes) of viewing the data from the camera using Coriander, the machine simply hangs hard - not even the magic Sysrq key works. I have this hw, using ohci driver: 04:0c.0 FireWire (IEEE 1394): Texas Instruments TSB12LV26 IEEE-1394 Controller (Link) The machine has only USB 1.1 ports (DELL Precision 820), without anything connected. The problem could be actually unrelated to USB. Still happens. Version 2.6.15.1 How could I debug this? Tommi, can you reproduce the lockup if you do not load ehci_hcd? (I.e. only uhci_hcd and the 1394 drivers.) No lockup when I unloaded the ehci_hcd module. Frames still dropped when usb is connected, if usb is removed, no frames get dropped. Capture Started "foo001.avi": frame dropped: timecode 45:85:85.45 date 2006.02.19 21:43:28 This error means that the ieee1394 driver received an incomplete frame. "foo001.avi": frame dropped: timecode 45:85:85.45 date 2006.02.19 21:43:28 This error means that the ieee1394 driver received an incomplete frame. "foo001.avi": frame dropped: timecode 45:85:85.45 date 2006.02.19 21:43:28 This error means that the ieee1394 driver received an incomplete frame. "foo001.avi": frame dropped: timecode 45:85:85.45 date 2006.02.19 21:43:29 Do the lock-ups happen with dvgrab 1.x over dv1394 as well as with dvgrab 2.x over raw1394 (i.e. _without_ the dv1394 loaded nor compiled in)? Is a panic message printed if you run dvgrab from a text console, i.e. switched away from X11? If so, please write the message down or take a photo of the screen and attach it here. My motherboard died, so I'm not able to reproduce this with the same setup. I have the pci cards (USB2 card and IEE1394 card) still, so I could plug them to the new mobo (Asus P5B-VM) and try. No panic message was printed when I grabbed under console. For the record: Asus P5B-VM has integrated IEEE1394 (by Texas Instruments) and it works fine with the onboard USB2.0. So I don't have this issue anymore since my current hardware works, but I'm willing to help to solve the problem. If you have the time and don't mind to take the PC down to insert the old cards, please try with these cards. If the problem is still there, we need a panic message or sprinkle the drivers with printks to get closer to the cause. CONFIG_IEEE1394_VERBOSEDEBUG a.k.a. "Excessive debugging output" could perhaps help too. But maybe the problem occurs outside the FireWire drivers. I installed the cards to my new motherboard, but wasn't able to reproduce the lockup. I was able to record to usb hard disk. dvgrab 1.8 dv1394 loaded When I unloaded dv1394, dvgrab did not recognize the camera anymore. I could send the cards to you (if you are willing to debug and send them back eventually)? The open question is whether the bug depended on the motherboard or has been fixed in the meantime. I doubt that I could reproduce this even if you sent me the cards. I don't have the same motherboard, and I don't have a camera (could set up a second PC as a streamer though). Note that we will mark dv1394 as deprecated from Linux 2.6.20 onwards, and hope to remove it some time next year. This is because raw1394 + libraw1394/libiec61883 are meant to replace dv1394. In light of that and the inability to reproduce the bug, how about closing the matter by "Reject bug, changing resolution to UNREPRODUCIBLE"? Unless Jan can still reproduce it with Linux 2.6.18 or better yet 2.6.19. BTW, dvgrab 1.x works via dv1394 and dvgrab 2.x via raw1394 + libraw1394. That's why dvgrab 1.8 didn't recognize the camera anymore after you unloaded d1394. (If I'm not seriously mistaken.) Jan notified me that he too doesn't have his old hardware setup anymore and didn't see the bug on the current hardware. In his case, the bug was during capture from an IIDC camera via raw1394, not a DV camera via dv1394. |
Distribution: Debian unstable Hardware Environment: Athlon XP pci firewire card: 0000:00:0c.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) (prog-if 10 [OHCI]) Subsystem: VIA Technologies, Inc. IEEE 1394 Host Controller Flags: bus master, medium devsel, latency 32, IRQ 3 Memory at ee002000 (32-bit, non-prefetchable) [size=2K] I/O ports at c800 [size=128] Capabilities: [50] Power Management version 2 pci usb2.0-card: 0000:00:0d.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 51) (prog-if 20 [EHCI]) Subsystem: VIA Technologies, Inc. (Wrong ID): Unknown device 1234 Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at ee003000 (32-bit, non-prefetchable) [size=256] Capabilities: [80] Power Management version 2 Software Environment: dvgrab 1.7 & 2.0 Problem Description: I'm using dvgrab to capture digital video from dv-camera by firewire. It works fine, unless I capture the video directly to an external USB2.0 hard disk. System log says: ohci1394: fw-host0: IR DMA error - OHCI error code 0x05 multiple times (around 20) and then comes the lockup. Magic sysrq works, but I don't have the output to put here. Steps to reproduce: Connect dv-camera to firewire port Connect external hard drive to usb2 port use dvgrab to capture video directly to the external hd output from scripts/ver_linux: Gnu C 3.3.5 Gnu make 3.80 binutils 2.15 util-linux 2.12p mount 2.12p module-init-tools 3.2-pre1 e2fsprogs 1.37 reiserfsprogs 3.6.19 reiser4progs line nfs-utils 1.0.7 Linux C Library 2.3.2 Dynamic linker (ldd) 2.3.2 Procps 3.2.5 Net-tools 1.60 Console-tools 0.2.3 Sh-utils 5.2.1 udev 056 Modules Loaded radeon iptable_filter ehci_hcd uhci_hcd snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_cs8427 snd_ac97_codec snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_i2c snd_mpu401_uart snd_rawmidi snd_seq_device snd parport_pc lp thermal processor realtime iptable_nat sbp2 dv1394 raw1394 ohci1394 ieee1394 vfat fat ide_scsi sg sr_mod cdrom usb_storage scsi_mod 8139too mii crc32 parport