From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7a) Gecko/20040218 Description of problem: After some while of using some application that uses /dev/raw1394 (i.e. Coriander) to get live image from firewire camera, lots of kernel messages are going to /var/log/messages. After few hours of working on dual CPU machine with 1GB RAM whole host was dead. It's wery bad situation since image from this camera must be captured 24 hours 365 days a year. The messages look like: Dec 5 00:05:17 video kernel: Debug: sleeping function called from invalid context at include/asm/semaphore.h:107 Dec 5 00:05:17 video kernel: in_atomic():0[expected: 0], irqs_disabled():1 Dec 5 00:05:17 video kernel: [<0211df82>] __might_sleep+0x7d/0x87 Dec 5 00:05:17 video kernel: [<0220fda4>] dma_pool_destroy+0x1a/0x116 Dec 5 00:05:17 video kernel: [<4298bd97>] free_dma_rcv_ctx+0xdb/0x106 [ohci1394] Dec 5 00:05:17 video kernel: [<4298a048>] ohci_devctl+0x48c/0x4ad [ohci1394] Dec 5 00:05:17 video kernel: [<429dd047>] hpsb_unlisten_channel+0x3b/0x3e [ieee1394] Dec 5 00:05:17 video kernel: [<42b41a79>] handle_iso_listen+0x10b/0x153 [raw1394] Dec 5 00:05:17 video kernel: [<42b43d5f>] state_connected+0xf1/0x1c7 [raw1394] Dec 5 00:05:17 video kernel: [<42b43eb6>] raw1394_write+0x81/0x95 [raw1394] Dec 5 00:05:17 video kernel: [<0215439b>] vfs_write+0xb6/0xe2 Dec 5 00:05:17 video kernel: [<02154465>] sys_write+0x3c/0x62 My firewire camera is DFK41F02 by ImagingSource Version-Release number of selected component (if applicable): kernel-smp-2.6.9-1.681_FC3 libraw1394-0.10.1-3 How reproducible: Always Steps to Reproduce: 1. Buy FireWire camera 2. Type mknod /dev/raw1394 c 171 0 (why udev can't do that?!) 3. Compile libdc1394 (why FC can't provide that as an rpm?!) 4. Compile and run Coriander, wait some time and see /var/log/messages (warning! it'll start to grow very quickly!) Actual Results: /var/log/messages will be full of logs and whole host will be dead after few hours of such working. Additional info: I suspect it's a mem leak at kernel level
For those who actually need to use FireWire camera during 24/7 time I've found some workaround. The point is not to use /dev/raw1394 but /dev/video1394/0 instead. In Coriander there is a possibility to change device file. When I selected /dev/video1394/0 few days ago it started to work at full framerate that my camera can do (7.5FPS now while 5FPS using /dev/raw1394) and it didn't crash yet. Still dmesg is full of messages, this time one line is repeated all the time: ieee1394: unsolicited response packet received - no tlabel match Also to do things udev doesn't do I've put these lines into /etc/rc.d/rc.local file: echo ":firewire" modprobe ohci1394 modprobe raw1394 modprobe video1394 modprobe dv1394 mknod /dev/raw1394 c 171 0 mkdir /dev/video1394 mknod /dev/video1394/0 c 171 16
I'm getting a similar message when I start dvgrab (using dev/raw1394): Debug: sleeping function called from invalid context at mm/slab.c:2061 in_atomic():0, irqs_disabled():1 [<c011bb8d>] __might_sleep+0x7b/0x85 [<c013f92d>] kmem_cache_alloc+0x1b/0x50 [<c02137f3>] dma_pool_create+0x6e/0x13f [<f8c0ff37>] alloc_dma_rcv_ctx+0x196/0x389 [ohci1394] [<f8c0dd77>] ohci_devctl+0x1dc/0x4ad [ohci1394] [<f8c60eff>] hpsb_listen_channel+0x3f/0x46 [ieee1394] [<f92e19fc>] handle_iso_listen+0x8e/0x153 [raw1394] [<f92e3af6>] state_connected+0xf1/0x1c7 [raw1394] [<f92e3c4d>] raw1394_write+0x81/0x95 [raw1394] [<c0152424>] vfs_write+0xb6/0xe2 [<c01524ee>] vfs_write+0x3c/0x62 [<c0103c97>] syscall_call+0x7/0xb Fortunately, it only occurs once, and dvgrab appears to be working.
An update has been released for Fedora Core 3 (kernel-2.6.12-1.1372_FC3) which may contain a fix for your problem. Please update to this new kernel, and report whether or not it fixes your problem. If you have updated to Fedora Core 4 since this bug was opened, and the problem still occurs with the latest updates for that release, please change the version field of this bug to 'fc4'. Thank you.
I am not using /dev/raw1394 anymore, since I am using /dev/video1394/0 till this day and it works well for me. Fell free to close this bug.