Description of problem: The Via VT6306 and VT6307 FireWire controllers do not work reliably (if at all) with the juju firewire stack. OHCI 1.0 Isochronous Receive support was recently added to the kernel (see bug 344851), but these controllers frequently fail to capture any video with dvgrab. Both controllers show up as simply "VIA Technologies, Inc. IEEE 1394 Host Controller" in lspci, but rev 46 are the VT6306, rev 80 (and possibly others) are the VT6307. The VT6306 is OHCI 1.0 only, the VT6307's EEPROM can be programmed for either OHCI 1.0 or OHCI 1.1 (again, see bug 344851 for more details on this). Version-Release number of selected component (if applicable): kernel-2.6.23.9-78.fc8 How reproducible: dvgrab -d 2 ctrl-c after seeing it sit there for much longer than 2 seconds, notice that dvgrab reports capturing one or two frames. Nb: I typically can capture for slightly longer with test-dv from libiec61883-utils, but it usually ends up hanging as well.
Whoops, meant to add Stefan to the CC list too.
I've got reproducing hardware here: 1) a VT6306 PCI card that works just fine in a core 2 duo system (x86_64 kernel), but fails to work in a dual Pentium III system (i686 kernel). 2) an OHCI 1.0 VT6307s onboard a Via EPIA M10000 motherboard that doesn't work (i686 kernel). 3) an OHCI 1.0 VT6307 onboard a Shuttle FN85 (Athlon64) motherboard that doesn't work (x86_64 kernel). Best as I can tell, the controller isn't queueing up packets fast enough and/or when its supposed to. When dvgrab is first invoked, there are a bunch of packets queued up, including three that have their IRQ bit set. We start processing packets and handle those first three IRQ's just fine, but the queue function never starts queueing new packets as we handle the already queued ones, until *after* we've already handled all the queued packets and IRQs, meaning the DMA program has already got to what it things was the end of the packet stream -- an INPUT_LAST packet with a zero Z value and branch address (knowing the OHCI specs helps that last sentence make a lot more sense, btw... :). Since the DMA program thinks its done, no more queued packets ever get handled. With other OHCI 1.0 controllers, I typically see the queue function start queueing up more packets as soon as the first IRQ packet is handled, so we don't get to an INPUT_LAST/zero Z packet until we're supposed to.
Here (as mentioned on linux1394-devel): - VT6306 CardBus card in a core 2 duo system doesn't work (at least lspci's output seems to indicate that this is a VT6306), - NEC CardBus card in the same system and same slot works, - VT6307 OHCI 1.1 onboard adapter in the same system works with dvgrab fetched recently from CVS.
PS: The NEC card is OHCI 1.0 too, so it's not related to the CardBus bridge which in turn sits behind a PCIe bridge. I haven't tried to coerce fw-ohci into 1.0 mode with the 1.1 VT6307, but my guess is that this would get stuck just like my and Jarod's 1.0 VT6306/6307s.
Additional observations: All with identical HW - just different kernels. Old FC6 with old stack: working flawlessly. Grabbed entire 1h tapes end to end without a single frame lost. With kernel-2.6.23.1-53.ohci1_0.fc8: I got something grabbed but the video was garbled with missing data so the image was scrolling slowly just like an old CRT loosing vertical sync. Grabbing performance was not consistent, though. With 2.6.23.9-78.fc8: Nothing gets grabbed. Details in: https://bugzilla.redhat.com/show_bug.cgi?id=344851#c42 Combined with the other observations I get the feeling of some timing issue with the HW. PCI problem?
Yeah, I was able to get video off my VT6307 controllers with the first edition of OHCI 1.0 support, which was grossly inefficient code and produced slightly corrupted video as a result, but at least it was working on these chipsets... A timing issue is definitely a possibility -- the bulk of the latency was in the packet handling routine, which might have meant the queue function was actually able to fire back up fast enough to keep enough packets queued up. I have a few things I want to try on my Via controllers, but of course, the VT6306 is working just fine in the box I threw it in here at home for poking over the weekend. :\
OK, just had to get 8h worth of footage off the tapes for the xmas DVD of the kid... Found an old P3 600MHz running FC5 (2.6.20-1.2316.fc5), slapped the VT6306 in and grabbed to the HD without problems (dvgrab 2.0). Not wanting to copy the stuff to the editing box afterwards, I nfs mounted the other and grabbed directly to the other box' HD. I had to increase buffers in dvgrab to 1000 to not loose frames. This also worked without problems - perfect video. Only thing I saw was sporadic: ohci1394: fw-host0: isochronous cycle too long ohci1394: fw-host0: IR DMA error - packet too long for buffer Usually in pairs but also either one of them alone. Only one instance per dvgrab run and in no particular time during the run. dvgrab never reported lost frames. Now, I know you could not care less for my reports of the old stack. This is just to ascertain that the HW can function in different scenarios and to add to the general weirdness ;-) The kernel output above might also hint some corner cases in the old stack that we might miss in the new (if anyone can make sense of it). So, now I just have to edit 8h into 2h... If I knew *anything* about FW and the OHCI spec. it would be much more fun to fiddle with some code!
> This also worked without problems - perfect video. > Only thing I saw was sporadic: > ohci1394: fw-host0: isochronous cycle too long > ohci1394: fw-host0: IR DMA error - packet too long for buffer > Usually in pairs but also either one of them alone. Hmm, the controller could have mistaken two isochronous packets for one, or the camcorder could have wrongly sent two packets as one, I don't know... The Google index contains only few mentions of "isochronous cycle too long", but that's because kernels before 2.6.18 did not log this condition. With older kernels, the controller silently stopped to initiate isochronous cycles whenever this condition occurred. Only somebody with a bus analyzer would have had a chance to see that no cycle start packets were going over the bus anymore. I don't know if this is relevant to firewire-ohci's trouble with VT6306/6307, but firewire-ohci does not yet have the "isochronous cycle too long" handling which ohci1394 got in kernel 2.6.18: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=57fdb58fa5a140bdd52cf4c4ffc30df73676f0a5 (Author is Jean-Baptiste Mur, contrary to the git log.) I will try a similar event handler for firewire-ohci and test it with my VT6306 card. I have doubts that it will help though because iso reception does stop very early.
Here is a patch to detect and handle the "cycle too long" condition in the new driver: http://marc.info/?l=linux1394-devel&m=119720541327505 But as I suspected, it does not help with this bug here at all.
Finally started poking at one of my Via controllers again. Very quickly, the IR context moves from active to inactive. I get between 6 and 8 runs through handle_ir_packet_per_buffer() with the context active, then it goes inactive. Thus far, I don't see why its going inactive though.
It goes inactive, because we reach the end of the list of descriptors we initially put together before we start appending new ones. So the controller encounters a descriptor with branch=0x11 and z=0, which is one of the conditions under which a controller well make a context inactive. The troubling part is that when we append new descriptors and set the run and/or wake bits, the context *should* go active again. Other OHCI 1.0 controllers I've looked at do indeed reactivate the context in this situation (at least an NEC OrangeLink controller does, and pretty sure the Agere FW323 does too).
We could check how the DMA program looks like in case of libiec61883--(libraw1394--raw1394--ieee1394)--ohci1394, or/and dv1394--ohci1394. AFAICT they do packet-per-buffer as well.
> We could check how the DMA program looks like in case of > libiec61883--(libraw1394--raw1394--ieee1394)--ohci1394, or/and > dv1394--ohci1394. AFAICT they do packet-per-buffer as well. Also, IIDC capture already works with VT630x/1.0 since David Moore's "Dynamically allocate buffers for DMA descriptors". We need to look at what the difference between IIDC capture and DV capture is.
Funny. dvgrab 3.1: Fail. kino 1.3.0: Works!
(In reply to comment #14) > Funny. > > dvgrab 3.1: Fail. > kino 1.3.0: Works! Ngggh. Wonder if Dan has any insight into what the two might be doing differently...
I've been having problems capturing from my DV camera ever since the new stack was introduced. Using the following configuration: uname -a Linux localhost.localdomain 2.6.25.10-86.fc9.i686 #1 SMP Mon Jul 7 20:46:03 EDT 2008 i686 athlon i386 GNU/Linux lspci | grep VIA 02:06.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 46) dvgrap -v dvgrab 3.0 I can usually capture data from the camera: dvgrab -a -f dv2 test I have recently captured two, one hour tapes using the above. Sometimes it does still hang during the capture, but I can't find a pattern.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Has there been any progress on this? I have tried my Panasonic DV camcorder on a few different Firewire cards under Fedora 9 and Fedora 10 Live CD. I experienced total failure. uname -a Linux nightmare.ricker.us 2.6.27.7-53.fc9.i686 #1 SMP Thu Nov 27 02:29:03 EST 2008 i686 athlon i386 GNU/Linux lshw reports: *-firewire:0 description: FireWire (IEEE 1394) product: SB Audigy FireWire Port vendor: Creative Labs physical id: 6.2 bus info: pci@0000:01:06.2 version: 04 width: 32 bits clock: 33MHz capabilities: pm ohci bus_master cap_list configuration: driver=firewire_ohci latency=32 maxlatency=4 mingnt=2 module=firewire_ohci *-firewire:1 description: FireWire (IEEE 1394) product: IEEE 1394 Host Controller vendor: VIA Technologies, Inc. physical id: 7 bus info: pci@0000:01:07.0 version: 43 width: 32 bits clock: 33MHz capabilities: pm ohci bus_master cap_list configuration: driver=firewire_ohci latency=32 maxlatency=32 module=firewire_ohci *-firewire:2 description: FireWire (IEEE 1394) product: IEEE 1394 Host Controller vendor: VIA Technologies, Inc. physical id: 9 bus info: pci@0000:01:09.0 version: 80 width: 32 bits clock: 33MHz capabilities: pm ohci bus_master cap_list configuration: driver=firewire_ohci latency=32 maxlatency=32 module=firewire_ohci I assume the VIA ones use the same or similar chipsets. One is on the motherboard, the other is a 3 port PCI card that I had laying around. I don't know what chipset the Soundblaster Audigy has. I also tried on a Windows box using Fedora 10 live CD. That system has a TI TSB43AB22/A. It failed also. I tried again under windows. The camera was detected and I was able to capture video from it. dvgrab says: Error: no camera exists kino and coriander don't see any cameras Can this issue be bumped up to F9 or F10 to keep it open?
Bumping to rawhide. No progress to report on Via controllers at the moment. But if your camera is failing with the Via controllers, the Audigy controller and the TI controller, then there's something else going on too. I've got Audigy controllers and TSB43AB22/A controllers, both of which work just fine with the cameras I have available to me.
Ah, forgot... We still have to fix a permissions issue... So its quite possible that dvgrab as root, or any of the progs after chowning the /dev/fw* nodes will work with at least the TI and Audigy controllers. Only dvgrab has issues w/the Via in ohci 1.0 mode, while kino and coriander should still work, as should dvgrab if its an ohci 1.1 Via.
Yes, "Error: no camera exists" is bug 441073, not bug 415841.
PS: Coriander is not for DV, it's for industrial cameras and a few webcams which send uncompressed video.
It is that time of year again, so I fired up the same crap VIA card as above (see #5 and also https://bugzilla.redhat.com/show_bug.cgi?id=344851#c42) in the same box as above, and ... it works!!! (after a quick and dirty chmod 777 /dev/fw*) kernel 2.6.27.7-53.fc9.x86_64 kino 1.2.0 dvgrab 3.2 Both kino and dvgrab works. Kernel says this when the camcorder is plugged: firewire_core: phy config: card 0, new root=ffc1, gap_count=5 firewire_core: phy config: card 0, new root=ffc1, gap_count=5 firewire_core: created device fw1: GUID 0000f0000b5a35ba, S400, 1 config ROM retries And an occational: firewire_ohci: context_stop: still active (0x40000411) when I stop grabbing. Nothing else. The chip was previously (a year ago) in ohci 1.0 mode, and that did not work. Are we in 1.1 mode now? How do I find out (in case it should interest any of you)? I am currently 45 minutes into grabbing tape one and no problems.
> It is that time of year again, so I fired up the same crap VIA card as > above (see #5 and also https://bugzilla.redhat.com/show_bug.cgi?id=344851#c42) > in the same box as above, and ... it works!!! Indeed, dvgrab suddenly receives iso on my OHCI 1.0 VT6306. (Otoh I now have a problem to make dvgrab and kino recognize the camera as AV/C device, so I tested iso with "dvgrab -guid ..." for now.) It's Gentoo's dvgrab 3.1 + libavc 0.5.3 + libiec61883 1.1.0, together with either vanilla libraw1394 v2.0.0 or liraw1394 git head; kernel drivers as in linux1394-2.6.git. > The chip was previously (a year ago) in ohci 1.0 mode, and that did not > work. Are we in 1.1 mode now? No, that's either immutable or wired up in the card's EEPROM which could only be changed by a special reprogramming tool. > How do I find out (in case it should interest any of you)? "dmesg | grep firewire_ohci" shows the card's initialization message with OHCI revision, unless loading the driver is longer ago than the dmesg ringbuffer can retain.
> (Otoh I now have a problem to make dvgrab and kino recognize the > camera as AV/C device, so I tested iso with "dvgrab -guid ..." > for now.) Nevermind, problem found. (Regression in a new firewire-patch which isn't in git yet.)
Got it: firewire_ohci 0000:00:0a.0: PCI INT A -> GSI 18 (level, low) -> IRQ 18 firewire_ohci: Added fw-ohci device 0000:00:0a.0, OHCI version 1.0 libiec61883-1.1.0-4.fc9.x86_64 libraw1394-1.3.0-11.fc9.x86_64 libavc1394-0.5.3-2.fc9.x86_64
Robin, thanks for the heads-up. Apparently somebody fixed this while we didn't look.
I have been doing some more testing. The SB Audigy does not create a /dev/fw* device when the camera is plugged in and nothing is shown in /var/log/messages. I suspect that the front panel may not be properly connected to the card. I will check that shortly. The VIA card creates /dev/fw3: Dec 18 20:06:11 nightmare kernel: firewire_core: created device fw3: GUID 00804580b0c6e001, S100 Dec 18 20:06:11 nightmare kernel: firewire_core: phy config: card 1, new root=ffc1, gap_count=5 Dec 18 20:07:55 nightmare kernel: firewire_ohci: context_stop: still active (0x40000400) I tried dvgrab with --guid but no luck: [root@nightmare vic]# dvgrab --guid 00804580b0c6e001 libiec61883 warning: iec61883_cmp_create_p2p_output: Failed to set the oPCR[0] plug for node 1. Established connection over channel 63 send oops send oops send oops send oops "" 0.00 MiB 0 frames Capture Stopped Error: no DV With plugreport, I was able to get this: Node 1 GUID 0x00804580b0c6e001 ------------------------------ oMPR n_plugs=1, data_rate=0, bcast_channel=63 oPCR[0] online=1, bcast_connection=0, n_p2p_connections=0 channel=63, data_rate=0, overhead_id=15, payload=122 iMPR n_plugs=1, data_rate=0 iPCR[0] online=1, bcast_connection=1, n_p2p_connections=0 channel=63 I'm not sure what it means, though... :-) This is all done as root, under F9, no selinux, with Panasonic PV-DV401D I get similar results from dvgrab --guid under F10 live CD and the TI fw chipset.
Always happy to "help" ;-) I have been grabbing 4 full tapes now in kino. Everything works rock solid. Thanks for fixing this - whoever you are.
Best guess right now is that we have Jay Fenlason to thank -- he sent a number of locking enhancements upstream, one of which likely resolved a subtle race that for some reason was only triggering on Via chips.
Vic, if you would, please open a new bug, the Via chipset isn't your problem. Seems to be something specific to your camera that we need to figure out.