kernel-2.6.21-1.3167.fc7 (x86_64) libraw1394-1.2.1-7.fc7 After plugging in my DV camcorder, I ran test-dv (as root) and the kernel oopsed in fw_core: BUG: unable to handle kernel paging request at virtual address ffffffea full oops is attached.
Created attachment 155101 [details] oops (from dmesg) with a little extra context
I get a similar kernel "oops" when I attempt to run dvgrab as root on Fedora 7. If I run dvgrab as user, I get "No camera found" (permissions problem?). kernel-2.6.21-1.3194.fc7 libraw1394-1.2.1-7.fc7
I am experiencing a similar problem on two different machines - both running Fedora 7, both using different firewire capture devices and both using different cameras - same result. Here's a little more information. When I plug in the camera I get the following messages in the log: Jun 12 15:30:42 floyd kernel: fw_core: created new fw device fw1 (0 config rom retries) Jun 12 15:30:42 floyd kernel: fw_core: phy config: card 0, new root=ffc1, gap_count=5 Jun 12 15:31:13 floyd last message repeated 27 times Jun 12 15:32:14 floyd last message repeated 54 times At that point the system locks hard (can't ssh in, etc etc) and I need to hard reboot. When I plug a cam in and change the ownership of /dev/fw1 (its owned rw by root only) and run dvgrab I get the attached Oops (dmesg and messages attached although I think they show the same thing). Like I said, same issue on two machines,two capture cards, two cameras.
Created attachment 156832 [details] messages log of Ooops
Created attachment 156833 [details] dmesg log of Oops
I receive a similar kernel oops when trying to initialize capturing using libdc1394 as root (using the latest libraw1394) on Fedora 7. This is not using test-dv, but rather on any application using the latest libdc1394 and thus libraw1394 and the new FW stack. I am a computer vision researcher and basically all my dc1394 based applications no longer work with Fedora 7 due to the new broken FW stack. Looking at the oops-output (which will follow in an attachment) the error seems in fact to be generated somewhere down the line in the new firewire-stack and/or its libraw1394 support. Please let me know if you need any additional info, I would be glad to help track this thing down. Here are my specs: Fedora 7 Linux 2.6.21-1.3194.fc7 #1 SMP (i386) libraw1394 1.2.1-7.fc7 libdc1394 latest SVN (svn revision number 401) compiled with "juju" backend support
Created attachment 156901 [details] oops output attached is the oops error message. It seems like the bug is somewhere in the FW stack at fw_iso_context_destroy / fw_device_op_release
Ok, I did some more debugging to track down the place where the oops is originally triggered in user-space. I found that the oops is generated by the following ioctl in libdc1394 in file capture.c: ioctl(craw->iso_fd, FW_CDEV_IOC_CREATE_ISO_CONTEXT, &create) This call fails (returns -1) and it also triggers the oops. This ioctl's target is part of the firewire-stack and resides in linux/firewire- cdev.h, so the error should be somewhere in there. Also, libdc1394 will segfault afterwards when attempting to handle the failed ioctl with its error handler (it attempts to close the iso_fd, but that's not directly related to the oops since it happens afterwards). I hope this is of help.
I have opened bug 8623 in the kernel bug tracker. I would like to know who took the decision to change the FW stack in fedora without running appropriate regression tests and what was the rationale behind his decision.
(In reply to comment #9) > I would like to know who took the decision to change the FW stack in fedora The firewire maintainer made that decision. Seems pretty obvious that he's the one who knows best what the Right Thing To Do is with firewire. > without running appropriate > regression tests and what was the rationale behind his decision. How, exactly, do you know what tests we ran? Furthermore this was a well-publicized feature of Fedora 7 from the beginning: http://fedoraproject.org/wiki/Releases/FeatureFirewireJuJu There was 5 months of public testing, with four public test releases, and nobody filed a bug about this until it was too late to fix for Fedora 7. Given that we have neither the time nor resources to test everything, perhaps you will join us for Fedora 8 test releases to help ensure this doesn't happen again. In the meantime this bug is being tracked and updates will be posted here when there are fixes available.
For those who need to capture from their camera and do not want to wait for Fedora, here is a fix that will restore kernel, libraries and kino former and working FireWire stack: http://www.ezplanetone.com/xwiki/bin/view/KnowledgeBase/BrokenFC7FireWire
(In reply to comment #11) > For those who need to capture from their camera and do not want to wait for > Fedora, here is a fix that will restore kernel, libraries and kino former > and working FireWire stack: > > http://www.ezplanetone.com/xwiki/bin/view/KnowledgeBase/BrokenFC7FireWire [...] 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. [...] This is an outright lie, please stop spreading FUD. I am appaled that a member of the community would write something like that instead of helping fix the problem. You should've participated in the F7 test phase. If you didn't, you have no right to complain now.
(In reply to comment #12) I agree that the statements on that page are reactionary and overly harsh. However, it is true that this is a pretty big bug that seems to be affecting a lot of Fedora 7 users, and for which there is no workaround other than recompiling the kernel and some libraries, which is beyond many users. Moving forward, what can those of us who are experiencing this bug do to help get it resolved quickly?
The problem has been fixed upstream and the rawhide kernels has the fix. It's possible to upgrade to a rawhide kernel without affecting the rest of the system. Doing so will make the crash go away, but the underlying problem won't, unfortunately. The issue is that the new stack only works with an OHCI 1.1 compatible controller, but it turns out that these are more widely deployed than first assumed. 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.
Those who cannot or do not want to get involved with rebuilding kernel and libraries can follow the link and instructions in my previous comment #11. I have been using the updates for more than a week and all the problems have gone away. I am also monitoring the site that gets hundreds of downloads/day and so far no complaints. I hope this helps. M.
Would it have been possible to adopt the new firewire stack but leave the old raw1394 code in place and available as a fallback? (Perhaps activateable via a kernel boot option, much as APM survives in the shadow of ACPI)?
*** Bug 243081 has been marked as a duplicate of this bug. ***
I have just updated Fedora 7 to kernel 2.6.22.1-27.fc7 but the kino still does not recognize my firewire device. I working on a kernel with the good firewire stack to release with EzPlanet updates.
Confirm that my Via firewire fails w/ 2.6.22.1-41.fc7 kernel and yesterdays development (fc8) kernel. That is, kino, dvgrab, etc crash when talking to an attached device (immediately).
Follow-up: and same machine, same devices worked fine in FC6
I am using kernel-2.6.22.4-65.fc7
I am using kernel-2.6.22.4-65.fc7. Dvgrab says: $ dvgrab Found AV/C device with GUID 0x0000850001097ee3 "" 0.00 MB 0 frames Capture Stopped Error: no DV No oops. Nothing is captured, although the camera does start playing for a few seconds until dvgrab says "Capture Stopped." I also was able to use dvgrab with Fedora Core 6. Note: the device root permissions issue some people are reporting is documented in Bug #191670.
I have the same problem. The "update" on comment #11 didn't work for me. I'm torrenting the Fedora 8 Test 1 now, and I'll report results in a few days.
Created attachment 185451 [details] 2.6.22.4-65.fc7.x86_64 dvgrab oops this is from dvgrab, kino produces a similar situation.
Created attachment 188651 [details] dvgrab 2.6.22.4-65.fc7 dvgrab
I just tried ezplanet's repo and it is down... so how does one go about fixing this bug?
I get the same results as documented in comment #22 when using Fedora 8 Test 2.
(In reply to comment #26) > I just tried ezplanet's repo and it is down... so how does one go about fixing > this bug? Thank you for opening ezplanet's repo. It worked once I yum updated my kernel and other 1394 libraries from ez repository. Cheers, Duc
(In reply to comment #28) > (In reply to comment #26) > > I just tried ezplanet's repo and it is down... so how does one go about fixing > > this bug? > > Thank you for opening ezplanet's repo. It worked once I yum updated my kernel > and other 1394 libraries from ez repository. > > Cheers, > Duc > How does running the ez updates effect the other repo's packages and updates? And is it safe to run the ez kernel?
how i can get the kmod to ez kernel ???
Created attachment 208221 [details] dvgrab bug kernel-2.6.22.7-85.fc7 dvgrab-2.1-2.fc7
The kernel oops originally reported here seems to be fixed. The "oops" reported in comment #24 and later is a bug in libraw1394, not a kernel bug. I've filed the libraw1394 oops as bug #328011, but I believe the kernel bug is closed.
So.. fixed in rawhide and not stable? What about those of us running plain old F-7?
I believe the oops should be gone in F-7 too, using the latest kernel from updates-testing (2.6.23.1-4.fc7 as of this writing).
Its not clear that this problem, as articulated by the maintainer, has been resolved. Kristian Høgsberg's post #14 pointed out: "...The issue is that the new stack only works with an OHCI 1.1 compatible controller..." and implied that the planned fix in the new firewire stack would only be useful to certain controllers, and I see nothing posted here by Kristian to update that statement. My Via 1.0's failed w/ the original F7. I'm concerned that most of us so effected have moved on to a work around (custom kernels) and thus this latest is not tested. Does this new rawhide kernel purport to address the other controllers as well?
The oops is gone in rawhide kernels (and should be gone in the latest f7 updates-testing kernel, if not earlier kernels), as well as the double-free problem (bug 328011) recently being fixed. OHCI 1.0 controllers still don't work though, as noted in 328011, and now tracked in bug 344851.
in Fedora 8 it still dont working i have: [root@host-192]~# dvgrab -autosplit -format raw -size 0 -noavc -timestamp foo- Found AV/C device with GUID 0x08004601044380f6 ioctl call failed, retval = -1 ieee1394io.cc:460: In function "virtual bool iec61883Reader::StartReceive()": "iec61883_dv_fb_start( m_iec61883.dv, channel )" evaluated to -1 ieee1394io.cc:460: errno: 38 (Function not implemented) "" 0.00 MB 0 frames Capture Stopped