Bug 215049 - Firewire (IEEE1394) needs improvements to work under Linux
Firewire (IEEE1394) needs improvements to work under Linux
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
8
All Linux
high Severity high
: ---
: ---
Assigned To: Jarod Wilson
Brian Brock
: FutureFeature, HardwareEnablement
Depends On:
Blocks: 182183
  Show dependency treegraph
 
Reported: 2006-11-10 13:28 EST by Larry Troan
Modified: 2016-04-18 05:45 EDT (History)
20 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-02-25 15:42:48 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Larry Troan 2006-11-10 13:28:26 EST
+++ This bug was initially created as a clone of Bug #182183 +++

It is expected to be a collection bug for FedoraCore support and will have both
kernel and user space components.

HISTORY..............................................................
-- Additional comment from tao@redhat.com on 2006-02-20 16:46 EST --

We still get requests for Firewire support in Linux, and I guess there will be a
1394b standard by this time also.  

The stability of code from ieee1394.org has varied from kernel to kernel.  This
feature request isn't for Red Hat to go make it wonderful.   Rather, it's to
take another look at it in Fedora and see whether things are cleaner and better.

-- Additional comment from riek@redhat.com on 2006-02-20 16:49 EST --
As FireWire use especially in the professional graphics and engineering area
seems to be increasing, we need to support it in both Fedora and RHEL. An area
where this support is critical e.g. is the automotive engineering workstations
market.



-- Additional comment from davej@redhat.com on 2006-06-06 22:33 EST --
It's marginally better than it was circa RHEL4, in that it doesn't explode
randomly even when not in use any more, but getting it working reliably is
another matter.

If we have a hope of shipping this, we need someone tasked with managing the
bugs that we'll get. (And we'll get a load, not necessarily all our fault or
ones we can fix either -- firewire drive enclosure firmware QA seems to be
non-existant).


-- Additional comment from peterm@redhat.com on 2006-06-14 14:58 EST --
Engineering determined the code base to not be stable enough for inclusion in
RHEL.  



-- Additional comment from ltroan@redhat.com on 2006-10-19 14:31 EST --
*** Bug 196704 has been marked as a duplicate of this bug. ***


-- Additional comment from krh@redhat.com on 2006-10-20 15:30 EST --
Also, specifically, what kind of use cases do our customers have?  What kind of
devices do they use?  And do they ask for the specific user space interfaces
provided by the current ieee1394 stack, or would they be happy with a stack that
provides the features they need but doesn't necessarily match the currents
stacks interfaces?




-- Additional comment from tao@redhat.com on 2006-11-07 10:51 EST --
The requirement for FireWire is pretty huge. In my experience
they use a large number of custom built control devices which they talk to
and receive data from over Firewire. 

Firstly they would like an official statement from Red Hat regarding our
position on FireWire support in Red Hat. If anyone can point me at this I
would really appreciate it.

More specifically, below I have pasted a specification from one of the key
developers, outlining exactly what they need out of ieee1394 support. They
are prepared to be involved in the community development process here if it
will help clarify things and smooth any testing - so if we can point them
at some specific developments available in FedoraCore then they are prepared to
consider testing their kit against it.


Here is the information:

1. Need the following to work correctly; isochronous reads from ieee1394a 
   devices, control stream reads and writes, to and from ieee1394a. To do
   this full support for raw1394 and video1394 is needed for isochronous
   reads with DMA. All the interface cards for this potential customer use
   the ohci1394 and ieee1394 drivers.

2. Customer does not use any mass bulk transfers that would be used in an 
   ieee1394 attached disk array.

3. Need support for more than one ieee1394a bus (i.e. more than one card). 
   While the drivers bind correctly in RHEL3 they are not usable as the
   video1394 driver device nodes are not correctly configured. In RHEL4
   with a custom built driver things look better but we have been unable
   to test.

4. Have custom kernel drivers that sit on top of the ieee1394 and
   ohci1394 driver in order provide a tty style interface to a RS232 to
   firewire interface box. Therefore the interface to these drivers needs
   to be fairly stable.

Need a working IEEE1394a interface with the raw1394 and video1394 drivers
supported. 


-- Additional comment from ltroan@redhat.com on 2006-11-09 16:11 EST --
Several of our partners have requested this function. 

Opening up this bugzilla as a requirements collection and discussion point. 

Key is a list of vendors/partners that have firewire requirements and the
specific devices they need supported. We will also be looking for
Community/partner help and for hardware (devices to be supported). Current
priorities are:
- Cameras and video
- Disks


-- Additional comment from krh@redhat.com on 2006-11-09 17:42 EST --
A few more questions:

  - Which camera and video devices are our customers using? DV/mpeg2 (iec61883
    based streaming), the 1934ta Digital Camera Spec, or custom protocols?
    Which user space libraries/applications?

  - Do any of our customers use custom/in-house developed firewire hardware
    with in-house drivers?

  - Does anybody use firewire audio and if so, which devices, which user space
    libraries and applications?

  - How important is fw800 (1394b)?  I imagine this is mainly relevant for
    customers using fw800 hard disks.


OPENING/INITIAL STATUS...............................................
-- Additional comment from krh@redhat.com on 2006-11-10 12:08 EST --
Here's a quick status on how we would like to enable firewire initially.

As mentioned in IT and BZ severeal times, the current upstream stack is not
shippable.  From there there are two options; fix the stack or write something
new.  Typically the former is preferrable, but in the firewire case a rewrite is
the better approach.  It's not at all infeasible, and fixing the current stack
would require substantial, destabilizing changes.

It's not a given that we can support the video1394 and raw1394 userspace
interfaces, but the functionality that these interfaces provide will be
available one way or another.  This means that in-house developed applications
will have to be moved over to the interfaces provided by the new stack.  It is
worth noting that we never supported any firewire interfaces in any RHEL release
after 2.1, so technically we're not breaking any API.

The proposed new stack is available here:

  http://gitweb.freedesktop.org/?p=users/krh/juju.git

and I'll be announcing it on LKML today.  It's usable with external hardisks and
cd drives at this point, the streaming interface is still being developed.  It
can be compiled as an out-of-tree driver provided the kernel-devel package is
installed.  For customers who only require external harddisk support, it is
probably interesting to test this already at this point.  Customers with more
advanced requirements should probably hold off for now.

-- Additional comment from krh@redhat.com on 2006-11-10 12:16 EST --
Here's a development snapshot SRPM:

  http://people.redhat.com/krh/juju/juju-0.0.1-1.src.rpm

-- Additional comment from ltroan@redhat.com on 2006-11-10 12:51 EST --

With a good track record in FedoraCore, we can consider it for a RHEL5 update as
well.
Comment 1 Stefan Richter 2006-11-17 05:25:14 EST
About the feature set:

 - 1394b support is certainly an absolute requirement for customers that you
have in mind. Not so much because of S800 vs. 1394/ 1394a's limit to S400 but
more so because of the choice of much longer copper cables and fiber optics. As
Kristian can certainly confirm, 1394b support isn't a big issue even though
mainline's stack fully supports it only since Linux 2.6.18. (Worked with S800B
but not S400B...S100B before.)

 - Security. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=201947#c2
Dan's patch mentioned there in #c3 is expected to be ready in a few weeks. It
will only address device security, not host security. For host security you have
to switch ohci1394 to phys_dma=0 but cannot really use sbp2 then, for now.

 - If customer want to develop or get developed custom protocol drivers, they
should be strongly encouraged to do this in userspace on top of libraries such
as libraw1394 and possibly even higher-level libraries. There is usually no need
to stuff such drivers into the kernel.


About the state of Linux' mainline FireWire drivers:

I (as current FireWire driver maintainer and long-term upstream sbp2 support
guy) am not closely in touch with the community in the video/ audio domain,
therefore can't tell how well or bad the mainline stack is working for them.
Whatever there is WRT support issues, it seems mostly going on in userspace --
as is actual development. We are very slowly migrating away from the kernel's
different isochronous APIs/ABIs to userspace --- amdtp was removed a while ago,
dv1394 is next, video1394 doesn't have a replacement yet. raw1394 behind
libraw1394 and higher-level libraries is the recommended interface for all
isochronous applications. This is fortunate for any plans to migrate away from
the existing driver stack.

 - eth1394 is currently nearly unmaintained. I may be able to maintain it during
the course of the next year but I am not experienced with networking drivers.
But I don't think eth1394 is of any importance to the customer base that is
discussed here.

 - sbp2 was in really bad shape until ca. end of 2005, early 2006, due to
massive bit-rot and Linux SCSI stack's permanent inability to properly support
hotplugging. (Cf. current problems with SAS for example.) I like to think that
sbp2 is working very well today although there are still some real non-trivial
TODOs: http://thread.gmane.org/gmane.linux.kernel.firewire.devel/8021/focus=8021

 - ohci1394 has some warts (cf. bug 144201) and there are occasionally enduser
reports about incompatibility issues of the "doesn't work" kind which are
impossible to fix without direct access to the hardware. Kristian probably has
much more concrete ideas of what ohci1394's issues are.

 - The whole ieee1394 stack doesn't properly suspend and resume. This is
currently slowly being worked on. But it is certainly not critical to the
customer base that is discussed here.

In the end, many of the problems of the IEEE 1394 driver stack are certainly
rooted in lack of manpower behind development and maintenance. The transition
from Linux 2.4 to 2.6 was a one-man effort and was probably severaly hurt by the
Linux 2.5 development model. Also, some unfortunate architectural choices may
have been made during this time. Shortly after early Linux 2.6 until most of
2005, the drivers became nearly unmaintained. I like to think the level of
maintenance improved in 2006 but we are still struggling with the ratio of
workload vs. manpower. Also, there have always been problems to synchronize the
linux1394 project with mainline; but this has been fixed recently.
Comment 2 Kristian Høgsberg 2006-12-05 12:28:21 EST
Announced on LKML:

  http://lkml.org/lkml/2006/12/5/7
Comment 3 Matthew Miller 2007-04-06 12:31:36 EDT
Fedora Core 5 and Fedora Core 6 are, as we're sure you've noticed, no longer
test releases. We're cleaning up the bug database and making sure important bug
reports filed against these test releases don't get lost. It would be helpful if
you could test this issue with a released version of Fedora or with the latest
development / test release. Thanks for your help and for your patience.

[This is a bulk message for all open FC5/FC6 test release bugs. I'm adding
myself to the CC list for each bug, so I'll see any comments you make after this
and do my best to make sure every issue gets proper attention.]
Comment 5 Scott Doty 2007-06-22 08:58:25 EDT
Hello,

Fedora 7 i386

kernel-2.6.21-1.3228.fc7
libraw1394-1.2.1-9.fc7

One program -- 6200ch -- is a channel-changer for MythTV that needs raw1394 in
order to work.  Seems that libraw1394 is in Fedora 7 release, but the
corresponding raw1394 module (kmod-raw1394 ?) isn't.

(I didn't even know there were two drivers until I went to build a kernel with
raw1394 support.)

(Points on the curve:  I use firewire for three things:  commanding a Motorola
DCT-6200/2005 cable box to change channels, capturing HDTV video from said cable
box (with mythtv), and working with my Sony HDR-HC3 HDV camcorder.)
Comment 6 Stefan Richter 2007-06-22 10:29:20 EDT
The fw-core driver in Fedora 7's kernel replaces raw1394.  Not as a drop-in
replacement, but regarding most of raw1394's features.  To my knowledge, Fedora
7's libraw1394 has been adapted to fw-core.

However, the Motorola DCT6200 needed a kernel feature which is present in the
old ieee1394 driver (which is also replaced by fw-core) but has not been brought
over to fw-core yet: 
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=48622b7bde008387218a416586e9d072b385f1ae
Comment 7 Stefan Richter 2007-06-22 10:39:50 EDT
PS:  It seems that 6200ch uses libraw1394 rather than directly raw1394, so it
should automagically work with kernel-2.6.21-1.3228.fc7's fw-core driver.  But
possibly the mentioned missing ieee1394 feature for device recognition and bug
240771 or/and bug 240774 might get in your way.

(The raw1394 driver was always meant to be used through libraw1394, so there
shouldn't be any programs out there that directly plug into raw1394.)
Comment 8 Scott Doty 2007-06-29 18:32:41 EDT
Okay, I've got 6200ch working with the new driver -- however, attempts to use
firewire to capture directly from the cable box have so far given me
problems...it looks like it _almost_ works, but the mpeg2ts stream doesn't sync up.

I'll try with the old driver, but this might be just general twitchiness with
the firewire capture reliability...in other words, I may need to go back to the
MythTV folks with the problem to isolate this as a driver issue.  I'll report
what happens.
Comment 9 Jarod Wilson 2007-12-03 20:43:41 EST
Could be related to bug 240774, which I'm finally going to have some time to dive into, now that my mac 
mini can actually do iso receive again (its got an ohci 1.0 controller, see bug 344851).
Comment 10 Brent R Brian 2007-12-28 12:51:16 EST
What kind of things do customers have?

DV Cameras and KINO, DVGRAB and such.

firewire_ohci: swap not done yet
firewire_core: giving up on config rom for node id ffc0
firewire_ohci: swap not done yet
firewire_ohci: swap not done yet
firewire_core: giving up on config rom for node id ffc0

when I cycle the power to my under FEDORA 7, nothing under Fedora 8, not even a
/dev/fw0 ..... Sharp WebCam - VL-WD450
Comment 11 Brent R Brian 2007-12-30 20:44:43 EST
>> Starting Editor
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
>>> iec61883Writer::iec61883Writer port 0 channel 63
>> Creating undo/redo buffer
>> Kino Common newFile
>>> Received playlist to store at position 0
>>>> Adding to end
>> Leaving Editor
>> Left Editor
>> Starting Capture
>> AV/C Enabled
>>> Using iec61883 capture
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
>>> iec61883Reader::StartThread on port 0
>> Trying XVideo at 720x480
>>> XvQueryAdaptors count: 0
>> Destroying XV Displayer
>> Trying XVideo at 360x240
>>> XvQueryAdaptors count: 0
>> Destroying XV Displayer
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
Reset Handler received
Stopping thread
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
>>> iec61883Reader::StartThread on port 0
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
>> Constructing File Capture tracker
>>> Trying /home/brent/capture001.dv
>>>> Registering /home/brent/capture001.dv with the tracker
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
Reset Handler received
rom1394_1 warning: read failed: 0x0000fffff0000414
Stopping thread
rom1394_0 warning: read failed: 0x0000fffff0000414
Reset Handler received
rom1394_0 warning: read failed: 0x0000fffff0000414
>>> iec61883Reader::StartThread on port 0
Stopping thread
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
>>> iec61883Reader::StartThread on port 0

Kino experienced a segmentation fault.
Dumping stack from the offending thread

Obtained 10 stack frames.
kino [0x807fbb1]
[0x110420]
/usr/lib/libraw1394.so.8 [0xc5bcf2]
/usr/lib/libraw1394.so.8 [0xc5be48]
/usr/lib/libraw1394.so.8(raw1394_iso_recv_start+0x27) [0xc5be87]
/usr/lib/libiec61883.so.0(iec61883_dv_recv_start+0x8c) [0xcde27c]
/usr/lib/libiec61883.so.0(iec61883_dv_fb_start+0x2a) [0xcde2da]
kino(_ZN14iec61883Reader12StartReceiveEv+0x24) [0x80b7e64]
kino(_ZN14iec61883Reader11StartThreadEi+0x9a) [0x80b6cea]
kino(_ZN11PageCapture12CheckDevicesEv+0x123) [0x80cc1e3]

Done dumping - exiting.
Comment 12 Brent R Brian 2007-12-30 20:54:31 EST
after the initial failure with kino, you get this every time you start it

>> Starting Editor
rom1394_0 warning: read failed: 0x0000fffff0000414
rom1394_0 warning: read failed: 0x0000fffff0000414
>>> iec61883Writer::iec61883Writer port 0 channel 63
>> Creating undo/redo buffer
>>> Received playlist to store at position 0
>>>> Adding to end
>>> Received playlist to store at position 1
>>>> Adding to end
>>> Received playlist to store at position 2
>>>> Adding to end
>>> Received playlist to store at position 3
>>>> Adding to end
>>> Received playlist to store at position 4
>>>> Adding to end
>>> Received playlist to store at position 5
>>>> Adding to end
>>> Received playlist to store at position 6
>>>> Adding to end
>>> Received request to undo from position 6
>> Trying XVideo at 720x480
>>> XvQueryAdaptors count: 0
>> Destroying XV Displayer
>> Trying XVideo at 360x240
>>> XvQueryAdaptors count: 0
>> Destroying XV Displayer
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=68
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=67
AC EOB marker is absent pos=87
AC EOB marker is absent pos=68
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=66
AC EOB marker is absent pos=65
AC EOB marker is absent pos=68
AC EOB marker is absent pos=64
AC EOB marker is absent pos=67
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=99
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=67
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=75
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=68
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=75
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=69
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=84
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=65
AC EOB marker is absent pos=65
AC EOB marker is absent pos=69
AC EOB marker is absent pos=73
AC EOB marker is absent pos=71
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=89
AC EOB marker is absent pos=67
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=68
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=67
AC EOB marker is absent pos=64
AC EOB marker is absent pos=65
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=68
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=67
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=68
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=66
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
AC EOB marker is absent pos=64
kino: ieee1394io.cc:1417: bool iec61883Writer::Open(bool): Assertion `m_handle
== 0' failed.
Aborted
Comment 13 Stefan Richter 2007-12-31 05:21:25 EST
Kino crash has also been reported in
https://bugzilla.redhat.com/show_bug.cgi?id=344851#c42 and
https://bugzilla.redhat.com/show_bug.cgi?id=344851#c45 .  It happens regardless
whether a DV device is connected or not, and regardless whether dvgrab works on
the same setup or not.  A separate bug entry should be opened for this.
Comment 14 Piergiorgio Sartor 2008-01-18 15:49:45 EST
So, I would like to join the chorus of the 1394 crying people too...

Just few days ago I tried to capture some DV tapes, using a Sony DCR PC-110 DV
camera (working somehow some Fedoras ago), without success... Of course...

The Fireware host is an a nVidia 6150 based motherboard, that is, "lspci" reports:

Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)

Which is an OHCI 1.1 (or 1.10, according to firewire-ohci) device.

The problem is that "kino" or "dvgrab" (crashes apart) can control the camera
(play, stop, ff, etc.), but cannot capture (the permission of /dev/fwX are set
properly).
Specifically, "dvgrab" reports:

"Error: no DV"

Now, I just installed the old 1394 stack (from ATrpms), with the required
libraw1394 (still from ATrpms) and, after removing & blacklisting the new
firewire stack, magically everything was working fine, "dvgrab" and "kino" were
both able to capture the DV stream from the camera. Without problems...

Obviously the new stack does not work in this setup and this is not an OHCI 1.0
vs. 1.1 problem, since the underlying hardware seems to be 1.1...

What would be wise, IMHO, is to provide _both_ stacks, with a proper libraw1394,
and, eventually with some /etc/sysconfig script or similar, give the user the
possibility to choose which stack to use (old <-> new). Similar to what is done
with the ATrpms third party repository.

This will have the following advantages:

1) people with the NEED of using the 1394 will be able to do so
2) people willing to experiment and test will be able to verify problems of the
new stack against the old one (and vice versa). Since this will reduce
significantly other sources of problems (cables, chipset, etc.).

Any possibility to have this done?

Thanks a lot in advance,

pg

Comment 15 Stefan Richter 2008-01-18 16:18:22 EST
> Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link)
...
> Specifically, "dvgrab" reports:
> 
> "Error: no DV"

Dvgrab /should/ work by now, except for (a) a harmless segfault on program exit
and (b) inability to grab from OHCI 1.0 variants of VIA VT630x.  Maybe try the
kernel from here: https://bugzilla.redhat.com/show_bug.cgi?id=271801#c20 if you
still have got the nerves to switch the stacks.  Kino still crashes for me,
already when entering the capture tab.

> What would be wise, IMHO, is to provide _both_ stacks, with a proper
> libraw1394, and, eventually with some /etc/sysconfig script or similar,
> give the user the possibility to choose which stack to use (old <-> new).

We will eventually manage to let libraw1394 and libdc1394 automatically switch
between ABIs at runtime to make this easier.  However, there some further issues
(initrd, ...) which makes a consequent dual-stack setup quite a bit involved.  I
don't know if a distributor would want to do that.
Comment 16 Piergiorgio Sartor 2008-01-18 16:49:55 EST
(In reply to comment #15)
> Dvgrab /should/ work by now, except for (a) a harmless segfault on program exit
> and (b) inability to grab from OHCI 1.0 variants of VIA VT630x.  Maybe try the

Well, it seems there is something more not working... :-)

BTW, could it be the new stack does not understand PAL DV streams?
This was happening somehow in the past, with dv1394.
Or is the stack content unaware?

> kernel from here: https://bugzilla.redhat.com/show_bug.cgi?id=271801#c20 if you

I'll try this one, but not immediately.

> still have got the nerves to switch the stacks.  Kino still crashes for me,
> already when entering the capture tab.

This is happening, with a certain probability, also to me.
I find it quite annoying, to be honest...

> We will eventually manage to let libraw1394 and libdc1394 automatically switch
> between ABIs at runtime to make this easier.  However, there some further issues

This would be great!
It will already make the stack switch a lot easier!

> (initrd, ...) which makes a consequent dual-stack setup quite a bit involved.  I
> don't know if a distributor would want to do that.

Well, I guess, before thinking about having the firewire at boot (I know, there
are cases when SBP2 devices have to be available soon), it would be better to
have a working firewire...

Anyhow, let's hope for the best...

bye,

pg
Comment 17 Stefan Richter 2008-01-18 17:19:11 EST
> BTW, could it be the new stack does not understand PAL DV streams?

I do tests with a PAL camcorder.

> This was happening somehow in the past, with dv1394.
> Or is the stack content unaware?

Dv1394 is specialized on DV and is aware of protocols and apparently to some
degree of contents.  The new firewire stack however has a single ABI for all
purposes, hence is agnostic WRT protocols or contents.  There are however
differences how isochronous streams look like depending on content and sometimes
depending on the sender:
  - fixed packet sizes vs. variable packet sizes,
  - senders who orderly send packets with zero payload during empty
    isochronous cycles vs. senders who skip a cycle now and then
    (at least so I remember to have heard).
Such differences may make driver bugs appear with one protocol and disappear
with another.
Comment 18 Piergiorgio Sartor 2008-01-19 06:06:42 EST
(In reply to comment #17)

> purposes, hence is agnostic WRT protocols or contents.  There are however
> differences how isochronous streams look like depending on content and sometimes
> depending on the sender:

So, there is more than meet the eyes...

Is there any way to "debug" the camera output in order to understand exactly how
it is behaving? Using the old stack, eventually...

This could point out an exact test case for the new stack.

Thanks,

pg
Comment 19 Stefan Richter 2008-01-19 07:35:49 EST
> Is there any way to "debug" the camera output in order to understand
> exactly how it is behaving? Using the old stack, eventually...

I am in danger to state the obvious, but:  One needs patience and energy,
certain knowledge of the application area and the implementations, a bunch of
printk()s here and there in the kernel, maybe a FireWire bus analyzer.
Comment 20 Piergiorgio Sartor 2008-01-21 14:14:18 EST
I tried the kernel-2.6.14-111.fc8 and the camera did not work, as before.

What about the FW bus analyzer, what could I do with it, assuming I had one?

pg
Comment 21 Stefan Richter 2008-01-21 15:44:44 EST
A FireWire bus analyzer would show you the traffic outside the box.  (Vice
versa, a PCI bus analyzer would show the traffic between controller and the rest
of the box...)  A FireWire bus analyzer is primarily interesting in developing
hardware or firmware.  It might also be useful to driver developers to
cross-check the driver's view of the traffic with the real traffic.

In case of non-working DV reception, the task is rather to find the responsible
layer in the stack (library not dealing properly with the kernel interface, or
kernel driver's DMA program getting stuck at some point, or...).
Comment 22 Christopher Brown 2008-02-03 15:54:34 EST
Re-assigning to Jarod, I guess this could be considered a bug of bug #271801 or
some such. Still, this bug is pretty messy - started out life as a clone and
there has been a lot of work done to improve firewire support over the last
month or so.

Could all reporters please test a rawhide kernel and update this bug as this is
where some patches currently reside for testing.

Cheers
Chris
Comment 23 Piergiorgio Sartor 2008-02-04 12:53:46 EST
Well, here we go:

tried kernel-2.6.23.14-128.fc8 and kernel-2.6.24-9.fc9, both give same results
as previously reported, i.e. no DV data is captured, while DV control works fine.

I cannot test the old stack with these ones, since no replacement module/library
seems to be available.

pg
Comment 24 Piergiorgio Sartor 2008-02-15 13:46:29 EST
It seems something new and strange popped up.

I installed kernel 2.6.23.15-137.fc8, latest from updates (and koji, for F8).

So I re-tried:

dvgrab -i -t -a -showstatus -debug all test

Sometimes I got the usual results, i.e. DV control OK, but no capture.
Once I got a complete system freeze (need to reset, no log entry).
Surprisingly, a couple of times the capture was somehow working.

Specifically a lot of "buffer underrun" errors, with "this means cannot write
fast enough" (I could not report the text due to the crash and I cannot
reproduce the thing, right now).

Interesting facts:

1) The errors were generated as soon as "dvgrab" started, since it was in
interactive mode, this means before play and before capture.
2) Something was effectively captured, even if the result is some "fast forward"
video (blocks and frames lost and skipped).
3) The file was captured in /tmp, which is, in my setup, tmpfs, i.e. RAM, so it
should not be a writing speed problem.

Any ideas? Suggestions?

Thanks,

pg
Comment 25 Jarod Wilson 2008-02-25 12:46:14 EST
Can't remember if I've noted this in any bugzilla or not, but it seems we have
various problems with all onboard FireWire controllers on nVidia chipset
motherboards, for some reason...
Comment 26 Jarod Wilson 2008-02-25 13:05:17 EST
Ah, I was thinking of bug 244576, but this is actually a different issue.
Comment 27 Jarod Wilson 2008-02-25 15:42:48 EST
Sounds a bit like either bug 243081 or bug 370931.

Piergiorgio, if your issues are similar to either of those, I'd like to track
your issues over there, rather than in this mess of a bug, which I'd like to
close, since the basics of the original bug have been satisfied. Recycling bugs
for multiple issues just gets too messy. If it doesn't look like either of
those, please open up a new bug, assign it to me and cc Stefan. Thanks much!

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