+++ 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 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 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 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 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 on 2006-10-19 14:31 EST -- *** Bug 196704 has been marked as a duplicate of this bug. *** -- Additional comment from krh 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 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 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 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 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 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 on 2006-11-10 12:51 EST -- With a good track record in FedoraCore, we can consider it for a RHEL5 update as well.
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.
Announced on LKML: http://lkml.org/lkml/2006/12/5/7
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.]
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.)
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
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.)
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.
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).
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
>> 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.
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
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.
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
> 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.
(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
> 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.
(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
> 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.
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
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...).
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
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
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
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...
Ah, I was thinking of bug 244576, but this is actually a different issue.
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!