Bug 141898 - Tons of kernel messages afrer while of using /dev/raw1394
Tons of kernel messages afrer while of using /dev/raw1394
Status: CLOSED WORKSFORME
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Jones
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-12-04 18:18 EST by Paul Osmialowski
Modified: 2015-01-04 17:13 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-09-05 02:15:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Osmialowski 2004-12-04 18:18:38 EST
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
Comment 1 Paul Osmialowski 2004-12-21 12:32:39 EST
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
Comment 2 Ian Pilcher 2005-02-03 10:02:17 EST
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.
Comment 3 Dave Jones 2005-07-15 13:51:51 EDT
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.
Comment 4 Paul Osmialowski 2005-09-02 06:41:43 EDT
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.


Note You need to log in before you can comment on or make changes to this bug.