Created attachment 12863 [details]
dmesg

Created attachment 12864 [details]
kernel config

Created attachment 12865 [details]
lspci

In 2.6.23-rc8-mm1:

=======================================================
[ INFO: possible circular locking dependency detected ]
2.6.23-0.199.rc8.mm1.1.fc8 #1
-------------------------------------------------------
totem/2945 is trying to acquire lock:
 (&itv->serialize_lock){--..}, at: [<ffffffff88101d0d>] ivtv_v4l2_open+0x93/0x2b3 [ivtv]

but task is already holding lock:
 (videodev_lock){--..}, at: [<ffffffff880ed08e>] video_open+0x38/0x1e2 [videodev]

which lock already depends on the new lock.


the existing dependency chain (in reverse order) is:

-> #1 (videodev_lock){--..}:
       [<ffffffff802529e8>] __lock_acquire+0xa79/0xc72
       [<ffffffff80252fce>] lock_acquire+0x5a/0x73
       [<ffffffff8044ef8c>] __mutex_lock_slowpath+0xe6/0x2b6
       [<ffffffff880ea1da>] video_register_device+0x9c/0x232 [videodev]
       [<ffffffff8810aff3>] ivtv_streams_setup+0x25b/0x3e8 [ivtv]
       [<ffffffff881010c4>] ivtv_probe+0x1105/0x12f9 [ivtv]
       [<ffffffff8033e96b>] pci_device_probe+0x4c/0x74
       [<ffffffff8039b452>] driver_probe_device+0xf6/0x17f
       [<ffffffff8039b614>] __driver_attach+0x86/0xc3
       [<ffffffff8039a82a>] bus_for_each_dev+0x43/0x6e
       [<ffffffff8039ab5e>] bus_add_driver+0x7a/0x1c4
       [<ffffffff8033eb0e>] __pci_register_driver+0x68/0x9a
       [<ffffffff880fff46>] module_start+0x8b/0xb7 [ivtv]
       [<ffffffff8025addf>] sys_init_module+0x16ec/0x1889
       [<ffffffff8020b7ae>] system_call+0x7e/0x83
       [<00007f9dacb423aa>] 0x7f9dacb423aa
       [<ffffffffffffffff>] 0xffffffffffffffff

-> #0 (&itv->serialize_lock){--..}:
       [<ffffffff802528e9>] __lock_acquire+0x97a/0xc72
       [<ffffffff80252fce>] lock_acquire+0x5a/0x73
       [<ffffffff8044ef8c>] __mutex_lock_slowpath+0xe6/0x2b6
       [<ffffffff88101d0d>] ivtv_v4l2_open+0x93/0x2b3 [ivtv]
       [<ffffffff880ed184>] video_open+0x12e/0x1e2 [videodev]
       [<ffffffff80294376>] chrdev_open+0x181/0x1be
       [<ffffffff80290230>] __dentry_open+0x12d/0x205
       [<ffffffff802903bf>] do_filp_open+0x2d/0x3d
       [<ffffffff80290415>] do_sys_open+0x46/0xc3
       [<ffffffff8020b945>] tracesys+0xdc/0xe1
       [<00007ff1d2c3dd9f>] 0x7ff1d2c3dd9f
       [<ffffffffffffffff>] 0xffffffffffffffff

other info that might help us debug this:

1 lock held by totem/2945:
 #0:  (videodev_lock){--..}, at: [<ffffffff880ed08e>] video_open+0x38/0x1e2 [videodev]

stack backtrace:

Call Trace:
 [<ffffffff8020cf30>] show_trace+0x34/0x4f
 [<ffffffff8020cf5d>] dump_stack+0x12/0x17
 [<ffffffff80250e0d>] print_circular_bug_tail+0x69/0x72
 [<ffffffff802528e9>] __lock_acquire+0x97a/0xc72
 [<ffffffff80252fce>] lock_acquire+0x5a/0x73
 [<ffffffff8044ef8c>] __mutex_lock_slowpath+0xe6/0x2b6
 [<ffffffff88101d0d>] :ivtv:ivtv_v4l2_open+0x93/0x2b3
 [<ffffffff880ed184>] :videodev:video_open+0x12e/0x1e2
 [<ffffffff80294376>] chrdev_open+0x181/0x1be
 [<ffffffff80290230>] __dentry_open+0x12d/0x205
 [<ffffffff802903bf>] do_filp_open+0x2d/0x3d
 [<ffffffff80290415>] do_sys_open+0x46/0xc3
 [<ffffffff8020b945>] tracesys+0xdc/0xe1
 [<00007ff1d2c3dd9f>]

INFO: lockdep is turned off.
ivtv0: Loaded v4l-cx2341x-enc.fw firmware (376836 bytes)
ivtv0: Encoder revision: 0x02060039
cx25840 2-0044: loaded v4l-cx25840.fw firmware (16382 bytes)

Created attachment 12939 [details]
2.6.23-rc8-mm1 kernel config

Created attachment 12940 [details]
2.6.23-rc8-mm1 dmesg

Nicolas,

I'm unable to reproduce this. Can you verify that this still happens with a vanilla 2.6.23 kernel? It loads without problems for me (and yes, I've turned on all the lock debugging options).

Can you also tell me how you load the driver?

Thanks,

       Hans

PS: apologies for the delay, I didn't have much time for ivtv in the past few weeks, very busy at work.

I'll retry with vanilla - but note that mm has all sorts of debugging checks which may hit vanilla only months later

I don't load the driver in any special way, it's modprobed by the system automatically (don't remember if I had to add a line in modprobe.conf specifically)

What's specific is I have a udev rule that tries to switch ivtv to svideo input as soon as the kernel declares the device ready

Don't worry about the delay - I don't always have time to follow up timely either. mm testing is not production-critical, just there to fix things before they hit mainline and most users

Can you give me that udev line? I suspect that that might be the trigger.

If you remove the switch to S-Video from udev, does the lock error disappear?

Hans

Ok, will do this evening when I have access to my home ivtv box

Here is the udev rule I use

# Use S-VIDEO input by default for ivtv cards
KERNEL=="video[0-9]*", SUBSYSTEM=="video4linux", SYSFS{name}=="ivtv[0-9]* encoder MPEG", RUN+="/usr/bin/v4l2-ctl -d /dev/%k -i 1"

Ah, yes. It is indeed triggered by the udev rule. I've changed the ivtv driver to postpone the actual registration of the v4l devices until everything is initialized, so that the new devices can be used immediately.

The fix is available in my tree at http://www.linuxtv.org/hg/~hverkuil/ivtv and will be pulled into the master v4l-dvb tree sometime next week.

Thanks for the fix!