PDA

View Full Version : Firewire issues in Fedora 7 (kino/dvgrab can't find /dev/raw1394)



ellocogato
10th June 2007, 01:52 AM
I cannot seem to get kino and dvgrab to see my camcorder in Fedora 7. It seems that Fedora 7 uses a new firewire stack (modules fw_core, fw_ohci), but kino and dvgrab seem to want to work with the old way of doing things.

lsmod shows both fw_core and fw_ohci, and when I plug in my camcorder, I see the following via dmesg:

fw_core: created new fw device fw1 (0 config rom retries)
fw_core: phy config: card 0, new root=ffc1, gap_count=5

/dev/fw0 exists, and /dev/fw1 appears when I plug in the camera.

However, dvgrab and kino don't see the camera. dvgrab simply reports "Error: no camera exists". kino reports "WARNING: raw1394 kernel module not loaded or failure to read/write /dev/raw1394!"

/dev/raw1394 does not exist, and there is no raw1394 kernel module in Fedora 7.

I do have libraw1394 libavc1394 and libdc1394 installed.

Are kino/dvgrab not compatible with the new firewire stack? Have I missed something? This is a fresh Fedora 7 install. I was able to work with this camera under Fedora Core 6.

Tim Watson
10th June 2007, 08:54 PM
I'd like to know about this too. I've just got hold of an ieee 1394 board (the motherboard doesn't have support) because my wife wants to import video from our DV camera (Canon MV6i) and my plan was to do a fresh install of F7 since it has improved firewire support. If dvgrab and kino won't play with the new firewire stack that will cause problems.

I'm waiting for a new HDD and a firewire cable to be delivered, as soon as they are, if there's no more information on this thread, I'll go ahead and let you kow how I get on.

Tim Watson
10th June 2007, 09:07 PM
Reading the man page for dvgrab, I don't suppose that the following works?:

dvgrab --dv1394 /dev/fw0 ...

or

cat /dev/fw0 | dvgrab --stdin ...

ellocogato
11th June 2007, 03:13 AM
Yeah, I thought of that too, but the --dv1394 seems to be for one of the modules from the old firewire stack, dv1394. In any case, it didn't work.

Tim Watson
11th June 2007, 03:32 PM
Hard disks and firewire cable arrived today so I'll upgrade a machine tomorrow and have a play.

The information on the new stack suggests that it works alongside the old IEEE1394 stuff so if nothing works I may well try building a kernel with the old firewire support enabled. I'll let you know how I get on.

ellocogato
11th June 2007, 10:58 PM
OK, so I tried running dvgrab as root, as per comment #1 in this bug report: <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243081>.

However, when I did that, I got a kernel "oops", which is very similar to that reported in this bug report: <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240771>.

Tim Watson
12th June 2007, 08:17 PM
I've upgrading my machines and installed and configured F7 but haven't had time to try firewire capture yet (wife too busy on eBay!). As soon as I get a chance I'll let you know how it goes.

The kernel oops doesn't look good. A new, reliable firewire stack is good but of limited value if kino and dvgrab can't use it. I would have thought that the old stack should have been included in the kernel build released with F7 unless the view is taken that every user is comfortable with patching, configuring, building and installing a new kernel.

Tim Watson
12th June 2007, 08:31 PM
I've just been trawling the mailing lists and the following looks promising:

https://www.redhat.com/archives/fedora-list/2007-June/msg02420.html
https://www.redhat.com/archives/fedora-list/2007-June/msg02435.html

From the posts:
I execute the following commands as root to get IEEE 1394 up and running:

* modprobe raw1394
* modprobe ohci1394
* modprobe video1394 - this last one only seems necessary to export edited
video back onto the tape.

That comes from here:
http://www.robfisher.net/video/index.html

> Thanks (Claude
>
> however, that's what I am getting:
>
> # /sbin/modprobe raw1394
> FATAL: Module raw1394 not found.
> # /sbin/modprobe ohci1394
> FATAL: Module ohci1394 not found.
> # /sbin/modprobe video1394
> FATAL: Module video1394 not found.
>
> I am not sure how ti fix that?

try yum install libraw1394

ellocogato
12th June 2007, 09:08 PM
Nope, no good. That's the first thing I tried. The problem is that none of those modules are shipped with Fedora 7 (which is why the "Module not found" errors). And libraw1394 doesn't contain the modules, so that's not the solution.

I'm currently trying to build a new kernel with those modules, but there's no kernel-source RPM like there used to be (to give me a full kernel source tree under /usr/src/kernels/). And I haven't figured out what to do with the kernel.src.rpm yet.

Tim Watson
12th June 2007, 09:21 PM
Is this any help?

http://www.mjmwired.net/resources/mjm-fedora-f7.html#kernelsrc

ellocogato
12th June 2007, 09:41 PM
Actually, that article links to another article with a more complete set of instructions:
<http://fedoraproject.org/wiki/Docs/CustomKernel>

Yes, this should be a great help building a new kernel, though it looks like a rather involved process.

leadgolem
12th June 2007, 09:49 PM
This thread (http://forums.fedoraforum.org/forum/showthread.php?t=157407) is a related issue and may help you resolve the problem.

ellocogato
12th June 2007, 10:03 PM
I fail to see how that thread is related.

Tim Watson
12th June 2007, 10:07 PM
Thanks for the suggestion leadgolem, although it doesn't seem to help with the new firewire stack problem.

ellocogato: does this mean that we shouldn't really include DV camera support in F7 under the heading 'It Just Works'? :-)

leadgolem
12th June 2007, 10:43 PM
The guy in that thread cannot get his external firewire video device, in this case a tvr card, to run without running
plugctl -n 1 "oPCR[0].n_p2p_connections=1" prior to starting the application. It does not address the firewire kernel stack issue. I found it possible that command would allow you to use your external firewire video device, in this case video camera, if it was run prior to launching kino.

No guarantees of course, since to be honest, I don't really understand what the command does.:)

ellocogato
12th June 2007, 11:32 PM
>> ellocogato: does this mean that we shouldn't really include DV camera support in F7 under the heading 'It Just Works'? :-)

Absolutely not. It really seems that the Fedora folks didn't work out all of the kinks with the new firewire stack before releasing F7. Though it's odd that some people report success with tricks like running as root, or using 'dvgrab --noavc', etc while I'm completely hosed. Fedora folks should have just used the old firewire stack, which worked fine for me in FC6. Or at least they could have included them both so that we could fall back to the old stack.

I can't even compile the stupid modules for the old firewire stack. The very last section of <http://fedoraproject.org/wiki/Docs/CustomKernel>, "Building Only Kernel Modules" looks perfect, but there's one hitch: the kernel-devel package doesn't include any .c files! I then tried the process of building the whole thing, but I got a make error.

Ugh!

Tim Watson
12th June 2007, 11:57 PM
To say that I'm not looking forward to following in your footsteps tomorrow when I attempt to get firewire working would be a vast understatement. I was planning on building a module too.

Tim Watson
13th June 2007, 12:30 AM
Some more from the mailing lists:
------------------
https://www.redhat.com/archives/fedora-list/2007-June/msg02437.html
To get my camera (JVC GR-DVL510EA) working in F7, I did the
following...

sudo modprobe fw-ohci

Connect the camera.

Change permissions on device file - see below.

Start kino - The camera should be shown and operational now.

I've also changed permission on file "/dev/fwX" (/dev/fw0 on my machine)
to allow non-root access to the firewire device.
I've edited "/etc/security/console.perms.d/50-default.perms" and then I
ran "sudo pam_console_apply" afterwards to achieve this.
---------------------
https://www.redhat.com/archives/fedora-list/2007-June/msg02894.html
Apologies for breaking the thread.


On Sunday June 10 2007 2:33:17 am Manal Helal wrote:
> Thanks (Claude
>
> however, that's what I am getting:
>
> # /sbin/modprobe raw1394
> FATAL: Module raw1394 not found.
> # /sbin/modprobe ohci1394
> FATAL: Module ohci1394 not found.
> # /sbin/modprobe video1394
> FATAL: Module video1394 not found.
>
> I am not sure how ti fix that?

try yum install libraw1394

Nope, that doesn't help.


The raw1394, etc. modules are not included in Fedora 7. There is a completely new firewire stack (modules fw-core, fw-ohci, fw-sbp2).

The version of libraw1394 shipped with Fedora is supposed to support the new firewire stack so that kino, dvgrab, et al don't know the difference, but I am also having the same problems as Manal, and there are other reports.

Generally, it seems that there are problems with the new firewire stack in Fedora 7. I have yet to find a solution, but I am tracking a few bugs that seem to be related:

<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240770>
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240771>
<https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243081>

ellocogato
13th June 2007, 01:54 AM
Well, aside from permissions issues, that's how it's supposed to work.

There seem to be multiple issues going on here. The first is a permissions issue, which I guess is what this bug is tracking: <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240770 >, and I suppose explains Comment #1 in this bug: <https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=243081 >.

Obviously that's not all that's going on, though, because I have issues even when I try to access my camera as root.

I hope you have better luck, Tim.

Tim Watson
13th June 2007, 09:30 PM
Just tried the firewire interface - kino recognised the camera but after switching to capture I got the kernel oops.

To be fair to the new firewire stack developer, his suggestion was to include both old and new for a few releases until it's proven to be stable and functional. I imagine that someone has since decided that that time has already arrived. I would beg to differ.

What is needed is a kernel module with the old stack in it. The options would seem to be recompile the kernel (not attractive), find or compile a kernel module for the old firewire stack or work out how the API to the new stack works and then write a simple capture program (life would seem to be too short). Another, increasingly attractive option would be to switch to Ubuntu or Debian for better firewire support.

I'll have a think and decide what to do. Any help would be gratefully received.

ellocogato
13th June 2007, 10:21 PM
Well I'd say we certainly have to fault the Fedora folks for the permissions issue. Bug 240770 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240770) shows that it was a known issue back in May and that it was considered a non-blocking issue for release.

It is also possible that the new firewire stack is completely stable on a vanilla kernel, but that it wasn't properly tested with all the kernel patching done for Fedora. The oops bug (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240771) was also filed back in May, so I have to fault the Fedora folks for releasing an OS that effectively has no support for firewire.

I've been using RedHat/Fedora since RedHat 4, so it will take a lot to make me switch to another distro. I'm willing to wait for the next kernel update from Fedora, but eventually I need to get video off of my camera!

Tim Watson
13th June 2007, 11:24 PM
Like you, I have been using Fedora/RH for years and am a big supporter - I'm the course leader for a number of MScs and have made Fedora the operating system used in the MSc lab. It seems that the reasons behind the poor/non-existent firewire support is that the old stack is deemed a security risk and unshippable, so they went with the new stack rather than have no support. While understandable for enterprise linux systems, in a community distro this seems like a poor choice - given the chance I imagine that most people would opt for stable firewire support (although the old stack is a bit flaky) rather than the current situation.

I will almost certainly install and run Ubuntu on my wife's machine until Fedora firewire support improves. This won't be ideal - I prefer Fedora's stance on free software and security - but it will be practical.

cloneu2
16th June 2007, 01:41 AM
had anyone come up with a fix yet. I need firewire to work so that my mythtv works with my hd cable tuner.. I have googled everyplace and all i find is that it is broken

tia
john

armastaja
16th June 2007, 06:38 AM
After loading the new firewire stack modules (fw-core, fw-ohci, fw-sbp2) for my kernel (kernel-2.6.21-1.3228.fc7), Kino (kino-0.9.5-2.lvn7) still complained that there was no /dev/raw1394. So I made a symbolic link for it (ln -s /dev/fw0 /dev/raw1394).

After I restarted Kino as root, it detected my Sony DCR-TRV730 and everything worked fine.

I know it's a long way from the proper fix, but it solved my immediate problem.

Tim Watson
16th June 2007, 08:30 AM
I'll try creating a link later today (I can't get near the computer in question at the moment) - if it's that easy I can live with the kludge for now. When I tried kino with the previous F7 kernel it didn't complain about the raw1394 device and recognised my camera, it was trying to capture that caused the kernel oops. I wouldn't have thought that an application not finding a device would cause such a serious problem.

armastaja lists the new kernel modules and while fw_core and fw_ohci are loaded, it looks like fw_sbp2 isn't (as root, lsmod doesn't show it but it is in /lib/modules/2.6.21-1.3228.fc7/kernel/drivers/firewire/fw-sbp2.ko). The module appears to provide support for SBP2 protocol drivers over firewire, allowing storage devices such as hard disks, DVD drives and even some scanners to be connected by firewire. It doesn't necessarily look relevant to cameras but I'll see what happens when I load it with modprobe and try a capture with kino.

I've been slowly working through building a new kernel the fedora way - the official instructions are plain wrong so it's slow going but if I manage it and get the older firewire stack working I'll post here with how I did it. Mind you, if all you need is a link then I guess that most people will opt for that approach!

ellocogato
16th June 2007, 07:26 PM
It looks like armastaja is suffering from the permissions bug, but not the kernel oops bug. I have tried all kinds of 'chown'ing and 'ln'ing and it always leads to "oops".

In particular, if I chown /dev/fw* as myself (without having any /dev/raw1394), kino recognizes that a camera is there when I switch to capture mode, but then immediately locks up because of the kernel oops. (Same with dvgrab; it sees the camera but immediately "oops".)

FYI, I upgraded to the 2.6.21-1.3228 kernel, with no change (and still no modules for the old firewire stack).

Tim Watson
16th June 2007, 07:39 PM
Having read a number of sources on rebuilding the kernel, the following seems to be the best:

http://forums.fedoraforum.org/showpost.php?p=769367&postcount=40

It's for FC6 but works as expected for F7. I've not been able to try it on the machine with the firewire card but a dry run on another machine looks straightforward - say no to the new stack and yes (or m to create a kernel module) to the old.

I'll try it for real as soon as I get a chance.

brian
18th June 2007, 07:10 AM
HowTo fix a Fedora 7 installation with broken FireWire

Fedora supplies bleeding edge Linux in the real sense and this time someone over there managed to replace a fairly good working FireWire stack with a broken one that is not even included in the main stream Kernel. Why? Who knows, at Fedora they are too arrogant to admit that they have made a mistake, and to listen to their user base.

Anyway, here we have rebuilt a new kernel and libraries including the former working FireWire stack.

Copy the content below and save it in /etc/yum.repos.d/ezplanet-updates.repo

[ezplanet-updates]
name=Fedora EzPlanet Updates $releasever - $basearch
baseurl=http://ftp.ezplanetone.com/pub/updates/fedora/$releasever/$basearch/
enabled=1
gpgcheck=0

Run a yum update and you will get:

* Latest Fedora Kernel with the working FireWire
* libavc1394
* libraw1394
* kino

As a bonus you will get also the latest clamav not included in Fedora, so that your logger will stop moaning about it being out-of-date.

The updates are for both i386 and x86_64 kernel and binaries, at the moment there is not a fix for xen kernel.

brian
18th June 2007, 07:13 AM
forgot to credit:

thanks to:
http://www.ezplanetone.com/xwiki/bin/view/KnowledgeBase/BrokenFC7FireWire

it may break your cinelerra install though.

brian

Tim Watson
18th June 2007, 10:13 AM
Thanks Brian, that will save me some work!

There seem to be some genuine security concerns with the original firewire stack so I don't blame the fedora developers too much, although it would have been nice if they had flagged firewire in F7 as improved code, not necessarily improved performance, rather than fantastic new firewire support.

cloneu2
18th June 2007, 01:45 PM
Thanks Brian
I haven't had so much fun since os2 came out!... Firewire now works so I can play with my mythtv.. Only the nvidia drivers are now broken and the system quits my session when I quit mythtv.. One fixed two or three broken... Guess it's just going to take a while....
Thanks for your efforts
john

Isbeorn
18th June 2007, 10:35 PM
Can anyone give me a clue on how to compile these modules myself? I tried the ezplanet kernel but it doesn't play nice with ATrpms nvidia, ivtv, and lirc modules.

I'd like to just use the source to build the old firewire modules and then blacklist the new ones.

According to this (http://fedoraproject.org/wiki/Docs/CustomKernel) I should be able to do this but their instructions don't seem to apply.

I have kernel-devel install but there are no *.c files in any of the module directories.

What am I doing wrong? Does the howto above work for anybody?

ellocogato
18th June 2007, 11:33 PM
Isbeorn, did you try the instructions that Tim linked to in post #27? Unfortunately, I get an internal compiler error when I attempt to build the kernel.

I noticed the same thing with the CustomKernel article on the Wiki, and I notified the original poster of the "Building Only Kernel Modules" section. He hopes to update it soon.

brian
18th June 2007, 11:59 PM
i use the livna nvidia drivers, i had no problems with the firewire fix.

but the livna mjpegtools conflicts with the at rpms cinelerra install. so you have to juggle a bit to get it installed.

brian

brian
19th June 2007, 12:02 AM
[QUOTE=cloneu2]Thanks Brian
I haven't had so much fun since os2 came out!...

this is better than OS2. i was a fan up until W4, but les and less worked and when they started charging for usb drivers, well there weren't any coupons for usb drivers.

brian

cloneu2
19th June 2007, 01:12 AM
I use the kernel mod nvidia drivers. They load on boot BUT will not start X... Get the old message tried to start X 3 times... Load new video drivers stuff...With the firewire stuff I get to change channels on the cable box but no video. Think it is looking for dv1394... Guess I'll play a bit more... Just want to record some HD tv and then make dvd's for my brother...

john

Isbeorn
19th June 2007, 09:18 PM
Isbeorn, did you try the instructions that Tim linked to in post #27? Unfortunately, I get an internal compiler error when I attempt to build the kernel.

I noticed the same thing with the CustomKernel article on the Wiki, and I notified the original poster of the "Building Only Kernel Modules" section. He hopes to update it soon.

Post 27 was very helpful, I read several other sites with instructions on compiling fedora kernels, but none of them worked. I think the trick of putting "# i386" at the top of the config file is what finally let me successfully compile a kernel.

However, my original goal was to compile _just_ the old ieee1394 modules, without having to compile the entire kernel. Since I couldn't get that to work, I followed Tim's post and rebuilt the entire 2.6.21-1.3228 kernel.

Basically at the make menuconfig part I went in and enabled the old ieee1394 as modules and left the new stack modules in there too. Once the kernel was completed I copied "~/rpmbuild/BUILD/kernel-2.6.21/linux2.6.21/drivers/ieee1394/*.ko" to my working kernels module directory (/lib/modules/2.6.21-1.3228.fc7/kernel/drivers/ieee1394/). Then do a depmod -ae (or reboot) Finally in /etc/modprobe.d/blacklist I blocked fw_core and fw_ohci from loading on boot.

So now, when I boot up, the new firewire stuff is blacklisted so they don't load, instead all the old ones are loaded.

Some may ask why I didn't just install the new kernel I built, but since my new kernel had a new revision yum would never be able to get compatible external modules like nvidia, ivtv, and lirc. Like I said, I would have liked to of built just those few modules instead of an entire kernel, but can't seem to find good docs how to do that.

ellocogato
19th June 2007, 10:11 PM
Isbeorn, that was exactly my plan, but unfortunately the kernel build failed for me. I'm glad it worked out for you. Maybe I'll try going through the whole process again in case I missed something.

Isbeorn
19th June 2007, 10:47 PM
Isbeorn, that was exactly my plan, but unfortunately the kernel build failed for me. I'm glad it worked out for you. Maybe I'll try going through the whole process again in case I missed something.
If it helps, here's a quick run down of the steps I did.

$su -c 'yum install rpmdevtools sparse yum-utils'
$rpmdev-setuptree
$su -c 'yumdownloader --source kernel'
$rpm -Uhv kernel-<version>.src.rpm
$vi ~/rpmbuild/SPECS/kernel-2.6.21
Now edit the spec file and add change this line:

from this - %define release %(R="$Revision: 1.3228 $"; RR="${R##: }"; echo ${RR%%?})%{?dist}%{?buildid}
to this -%define release %(R="$Revision: 1.3228 $"; RR="${R##: }"; echo ${RR%%?}).test%{?dist}%{?buildid}

Here's where I differed from post #27. The lines he says to edit weren't there. So I just ran this instead of changing the flags inside the spec file.

$rpmbuild -bp --target=`uname -m` --with baseonly ~/rpmbuild/SPECS/kernel-2.6.spec
$cd ~/rpmbuild/BUILD/kernel-<version>/linux-<version>/
$make mrproper
$cp configs/kernel-<version>-<arch>.config .config
$make oldconfig
$make menuconfig
$cp .config ~/rpmbuild/SOURCES/kernel-<version>-<arch>.config
$vi ~/rpmbuild/SOURCES/kernel-<version>-<arch>.config

Add the "# i386" to the top of this file.


$rpmbuild -bb --target=`uname -m` --with baseonly ~/rpmbuild/SPECS/kernel-2.6.spec

That took a good long while, but it will take 4 times as long if you don't do that "--with baseonly" because it will do the Xen and other kernels. So if yours is trying to do those kernels then it may be crapping on modules for a kernel you don't need anyway.

When that was done, I went into the BUILD directory and found the ieee1394 *.ko files like I mentioned before and so on.

Hope that helps. Its possible, that once you do the rpmbuild -bp you can just manually make just the *.c files in the ieee1394 directory. But I'm not a kernel hacker or even a programmer so I built the whole kernel.

Maybe next time I'll try just running make modules after I do make menuconfig. That would make all modules but still quicker than waiting for the rpm to build.

zkbzh
19th June 2007, 10:56 PM
Isbeorn/ellocogato - you shouldn't have to compile the whole kernel; try the following:

1. Download and install the source for the kernel, I used kernel-2.6.21-1.3228.fc7.src.rpm which is the same as my currently running kernel (for some reason which I didn't take the time to investigate, when I did the install on this file it didn't put the source .c .h files etc into the kernel tree, so I manually pulled the linux-2.6.21.tar.bz2 from the rpm file, untarred it and then copied the contents of linux-2.6.21/drivers/ieee1394 to /usr/src/kernels/2.6.21-1.3228.fc7-i686/drivers/ieee1394 )

2. Drop into /usr/src/kernels/2.6.21-1.3228.fc7-i686 and run make menuconfig - enable the old module files etc.

3. Then run - make drivers/ieee1384 && make M=drivers/ieee1394 - this will compile only the ieee drivers.

4. copy drivers/ieee1384/*.ko to /lib/modules/2.6.21-1.3228.fc7/kernel/drivers/ieee1394 (I had to create the ieee1394 folder)

5. run depmod -a

6. Blacklist the new drivers causing the problem

You should be ready to go - shouldn't take more than 5 minuters to do

Jamie

ellocogato
20th June 2007, 02:10 PM
Thanks, zkbzh. That process worked great for me and did take less than 5 minutes. I've got the old stack's modules loaded. Next time I'm physically at the machine, we'll see if I can capture video now...

cloneu2
20th June 2007, 03:36 PM
Thanks, zkbzh. That process worked great for me and did take less than 5 minutes. I've got the old stack's modules loaded. Next time I'm physically at the machine, we'll see if I can capture video now...
How did you get the tar file out of the source rpm?
tks
john

cloneu2
20th June 2007, 04:13 PM
How did you get the tar file out of the source rpm?
tks
john

zkbzh
20th June 2007, 08:31 PM
The easiest way to extract the tar file from the RPM is to just right click on the file and select 'Open with Archive Manager' - you will then see the contents of the RPM - just locate the tar file and select 'extract'.

ellocogato
20th June 2007, 08:49 PM
Argh, still no go. I now have the *1394 modules loaded and the fw_* modules blacklisted, but kino and dvgrab don't see the camera.

ddennedy
22nd June 2007, 04:44 AM
libraw1394 is patched to work with the new kernel. Therefore, you need an unpatched libraw1394. I believe it is API and ABI compatible so you would not need to recompile libs and apps, but I am not certain if they changed the libtool version. In any case, you could get libraw1934 compiled for ieee1394 (instead of firewire) at the ezplanet yum repo.

Isbeorn
26th June 2007, 02:34 PM
Don't have an answer for you Ellocogato, but this link ties in with some stuff mentioned in this thread. Apparently Fedora has finally taken notice that their kernel building Howto is severely out dated.

http://samfw.blogspot.com/2007/06/custom-kernels-in-fedora.html

https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240878

ellocogato
27th June 2007, 07:44 PM
According to this comment in bug 240771 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240771#c14), a fix for the "oops" bug is known, but that doesn't solve the underlying problem.

Apparently the new firewire stack only properly supports OHCI 1.1 devices, and OHCI 1.0 devices aren't going to work properly. (In particular, cards with VIA chipsets seem to be common offenders.) I don't quite understand the whole comment, but it looks like we'll be waiting a bit for a complete fix.

ellocogato
25th July 2007, 02:49 PM
Just an update to say that this still isn't resolved for me.

Comment 14 of bug 240771 (https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=240771#c14) states:

The plan is to issue an F7 update once 2.6.22 comes out. I'm planning a
software fallback for the feature that the OHCI 1.0 controllers doesn't provide,
but it won't make it into the official 2.6.22 kernel. We may be able to ship it
as a patch in the 2.6.22 kernel RPM, which would bring back test-dv in F7.
Well, I just upgraded to 2.6.22.1-27.fc7 and tested my camera. Indeed, the kernel oops issue appears to be resolved, but apparently they didn't ship a patch for OHCI 1.0 controllers in this kernel, as dvgrab simply crashes in a different way now.

cloneu2
25th July 2007, 03:35 PM
Been a long time trying to get my HD cable box working with firewire. Still no luck... Tried a yum update for the new EZ kernel and got this message

10:28:07 : Packages to update
10:28:07 : ---> kernel - 2.6.22.1-1027.ez.fc7.i686
10:28:07 : ---> kernel-devel - 2.6.22.1-1027.ez.fc7.i686
10:28:07 : Preparing for install/remove/update
10:28:07 : --> Preparing for a full update
10:28:07 : --> Running transaction check
10:28:07 : ---> Package kernel.i686 0:2.6.22.1-1027.ez.fc7 set to be updated
10:28:08 : ---> Package kernel-devel.i686 0:2.6.22.1-1027.ez.fc7 set to be updated
10:28:08 : --> Processing Dependency: kernel-i686 = 2.6.22.1-27.fc7 for package: kmod-nvidia
10:28:08 : --> Finished Dependency Resolution
10:28:08 : --> Running transaction check
10:28:09 : ---> Package kernel-devel.i686 0:2.6.22.1-1027.ez.fc7 set to be updated
10:28:09 : ---> Package kernel-devel.i686 0:2.6.21-2.3228.fc7.ez set to be erased
10:28:09 : ---> Package kernel.i686 0:2.6.22.1-1027.ez.fc7 set to be updated
10:28:09 : ---> Package kernel.i686 0:2.6.21-1.3228.fc7 set to be erased
10:28:10 : --> Processing Dependency: kernel-i686 = 2.6.21-1.3228.fc7 for package: kmod-nvidia
10:28:10 : --> Processing Dependency: kernel-i686 = 2.6.22.1-27.fc7 for package: kmod-nvidia
10:28:10 : --> Restarting Dependency Resolution with new changes.
10:28:10 : --> Running transaction check
10:28:10 : ---> Package kernel.i686 0:2.6.21-1.3228.fc7 set to be erased
10:28:10 : ---> Package kmod-nvidia.i686 0:100.14.11-1.2.6.21_1.3228.fc7 set to be erased
10:28:10 : --> Processing Dependency: kernel-i686 = 2.6.22.1-27.fc7 for package: kmod-nvidia
10:28:10 : --> Finished Dependency Resolution
10:29:37 : Error in Dependency Resolution
10:29:37 : Missing Dependency: kernel-i686 = 2.6.22.1-27.fc7 is needed by package kmod-nvidia

Can't seem to find a driver for Nvidia that will work

????????

John :mad:

martinellison
9th November 2007, 09:25 AM
Does anyone know whether Firewire is working on Fedora 8? for older (OHCI 1.0) devices?

fedorax
18th November 2007, 07:44 AM
Does anyone know whether Firewire is working on Fedora 8? for older (OHCI 1.0) devices?

Unfortunately not for kion. Try to use AVC on a camescope just give an error message:


>>> iec61883Reader::StartThread on port 0
ioctl call failed, retval = -1
ieee1394io.cc:437: In function "virtual bool iec61883Reader::StartReceive()": "iec61883_dv_fb_start( m_iec61883dv, channel )" evaluated to -1
ieee1394io.cc:437: errno: 38 (Fonction non implantée)
ieee1394io.cc:437: In function "virtual bool iec61883Reader::StartReceive()": "iec61883_dv_fb_start( m_iec61883dv, channel )" evaluated to -1
ieee1394io.cc:437: errno: 38 (Fonction non implantée)

rapiddescent
27th May 2008, 08:12 AM
does anyone know if kino is working for Fedora 9? - I have one machine with a custom kernel being held back just for kino !

ellocogato
27th May 2008, 01:46 PM
does anyone know if kino is working for Fedora 9? - I have one machine with a custom kernel being held back just for kino !

I just upgraded to Fedora 9 from Fedora 8. My initial tests of Kino show no change. I haven't investigated any potential workarounds yet. I've just been using dvgrab, which works fine for me.

rokit
14th September 2009, 10:47 AM
Ok, we're on FC11 now. Does anyone know how to get the old drivers?

rokit
14th September 2009, 11:15 AM
I just realized video is working in the new drivers, so this probably doesn't apply to you guys anymore. I'm just going to start a new thread.