Bug 415841 - [firewire] Via VT6306 and VT6307 FireWire controllers unable to capture video
[firewire] Via VT6306 and VT6307 FireWire controllers unable to capture video
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
All Linux
low Severity low
: ---
: ---
Assigned To: Jarod Wilson
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-12-07 12:10 EST by Jarod Wilson
Modified: 2008-12-19 09:24 EST (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-12-19 09:15:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 10936 None None None Never

  None (edit)
Description Jarod Wilson 2007-12-07 12:10:58 EST
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.
Comment 1 Jarod Wilson 2007-12-07 12:11:53 EST
Whoops, meant to add Stefan to the CC list too.
Comment 2 Jarod Wilson 2007-12-07 12:22:26 EST
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.
Comment 3 Stefan Richter 2007-12-07 12:35:26 EST
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.
Comment 4 Stefan Richter 2007-12-07 12:40:59 EST
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.
Comment 5 Robin Theander 2007-12-08 05:09:41 EST
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?
Comment 6 Jarod Wilson 2007-12-08 12:24:48 EST
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. 
:\
Comment 7 Robin Theander 2007-12-09 06:35:16 EST
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!
Comment 8 Stefan Richter 2007-12-09 07:19:54 EST
> 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.
Comment 9 Stefan Richter 2007-12-09 08:10:27 EST
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.
Comment 10 Jarod Wilson 2008-04-15 15:33:32 EDT
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.
Comment 11 Jarod Wilson 2008-04-17 10:24:22 EDT
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).
Comment 12 Stefan Richter 2008-04-18 09:41:50 EDT
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.
Comment 13 Stefan Richter 2008-04-26 04:16:01 EDT
> 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.

Comment 14 Stefan Richter 2008-06-18 16:33:46 EDT
Funny.

dvgrab 3.1:  Fail.
kino 1.3.0:  Works!
Comment 15 Jarod Wilson 2008-07-02 12:23:20 EDT
(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...
Comment 16 Andy Pengelly 2008-09-13 05:15:49 EDT
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.
Comment 17 Bug Zapper 2008-11-26 03:53:33 EST
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
Comment 18 Vic Ricker 2008-12-17 20:18:46 EST
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?
Comment 19 Jarod Wilson 2008-12-17 20:37:37 EST
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.
Comment 20 Jarod Wilson 2008-12-17 20:47:54 EST
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.
Comment 21 Stefan Richter 2008-12-18 02:48:42 EST
Yes, "Error: no camera exists" is bug 441073, not bug 415841.
Comment 22 Stefan Richter 2008-12-18 02:50:40 EST
PS: Coriander is not for DV, it's for industrial cameras and a few webcams which send uncompressed video.
Comment 23 Robin Theander 2008-12-18 15:31:32 EST
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.
Comment 24 Stefan Richter 2008-12-18 17:10:35 EST
> 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.
Comment 25 Stefan Richter 2008-12-18 17:40:05 EST
> (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.)
Comment 26 Robin Theander 2008-12-18 18:12:22 EST
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
Comment 27 Stefan Richter 2008-12-18 18:22:35 EST
Robin, thanks for the heads-up.  Apparently somebody fixed this while we didn't look.
Comment 28 Vic Ricker 2008-12-18 21:42:55 EST
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.
Comment 29 Robin Theander 2008-12-19 03:25:48 EST
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.
Comment 30 Jarod Wilson 2008-12-19 09:15:25 EST
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.
Comment 31 Jarod Wilson 2008-12-19 09:24:09 EST
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.

Note You need to log in before you can comment on or make changes to this bug.