Bug 215049
| Summary: | Firewire (IEEE1394) needs improvements to work under Linux | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Larry Troan <ltroan> |
| Component: | kernel | Assignee: | Jarod Wilson <jarod> |
| Status: | CLOSED RAWHIDE | QA Contact: | Brian Brock <bbrock> |
| Severity: | high | Docs Contact: | |
| Priority: | high | ||
| Version: | 8 | CC: | bjohnson, brentrbrian, chris.brown, fenlason, ichute, jarod, jjarvis, jrb, krh, ltroan, lwang, mattdm, peterm, piergiorgio.sartor, pm-rhel, rpacheco, rstrode, scott, stefan-r-rhbz, wtogami |
| Target Milestone: | --- | Keywords: | FutureFeature, HardwareEnablement |
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Enhancement | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2008-02-25 20:42:48 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 182183 | ||
|
Description
Larry Troan
2006-11-10 18:28:26 UTC
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! |