LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* possible recursive locking detected
@ 2008-03-09 17:08 bruno.roussel
  2008-03-09 21:16 ` Christian Kujau
  0 siblings, 1 reply; 5+ messages in thread
From: bruno.roussel @ 2008-03-09 17:08 UTC (permalink / raw)
  To: linux-kernel


Hi !

Sorry for the next message without object !


I have this report in dmesg :


saa7146_vv: saa7146 (0): registered device video0 [v4l2]
saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
dvb-usb: found a 'Hauppauge WinTV-NOVA-T usb2' in warm state.
dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
DVB: registering new adapter (Hauppauge WinTV-NOVA-T usb2)
dvb-usb: MAC address: 00:0d:fe:00:00:00
DVB: registering frontend 1 (DiBcom 3000MC/P)...

=============================================
[ INFO: possible recursive locking detected ]
2.6.24.2-1mdv #1
---------------------------------------------
modprobe/2082 is trying to acquire lock:
 (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]

but task is already holding lock:
 (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]

other info that might help us debug this:
1 lock held by modprobe/2082:
 #0:  (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b
[i2c_core]

stack backtrace:
Pid: 2082, comm: modprobe Not tainted 2.6.24.2-1mdv #1
 [<c01054c2>] show_trace_log_lvl+0x1a/0x2f
 [<c0105ccf>] show_trace+0x12/0x14
 [<c0105fd7>] dump_stack+0x6a/0x70
 [<c0139e5b>] __lock_acquire+0x16b/0xc32
 [<c013ad80>] lock_acquire+0x70/0x92
 [<c02c937f>] mutex_lock_nested+0xf9/0x2a4
 [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
 [<eef611fb>] dibx000_i2c_gated_tuner_xfer+0x172/0x18c [dibx000_common]
 [<eeed4140>] i2c_transfer+0x39/0x4b [i2c_core]
 [<eefbc17c>] mt2060_readreg+0x48/0x68 [mt2060]
 [<eefbc486>] mt2060_attach+0x49/0x1ef [mt2060]
 [<eefa3527>] dibusb_dib3000mc_tuner_attach+0x145/0x1fb [dvb_usb_dibusb_common]
 [<eef83c49>] dvb_usb_adapter_frontend_init+0xc4/0xe8 [dvb_usb]
 [<eef837aa>] dvb_usb_device_init+0x3e8/0x4ce [dvb_usb]
 [<eef7f01c>] nova_t_probe+0x1c/0x1e [dvb_usb_nova_t_usb2]
 [<eeeb1f51>] usb_probe_interface+0xd5/0x112 [usbcore]
 [<c02420bb>] driver_probe_device+0xca/0x14d
 [<c0242225>] __driver_attach+0x4a/0x7f
 [<c024164f>] bus_for_each_dev+0x38/0x5a
 [<c0241f25>] driver_attach+0x19/0x1b
 [<c0241966>] bus_add_driver+0x76/0x194
 [<c02423dd>] driver_register+0x67/0x6c
 [<eeeb1ae7>] usb_register_driver+0x7e/0xe5 [usbcore]
 [<eef8d01b>] nova_t_module_init+0x1b/0x38 [dvb_usb_nova_t_usb2]
 [<c0140e78>] sys_init_module+0x12c6/0x1394
 [<c0103e12>] sysenter_past_esp+0x6b/0xc9
 =======================
input: IR-receiver inside an USB DVB receiver as /class/input/input2
dvb-usb: schedule remote query interval to 100 msecs.
dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully initialized and connected.
usbcore: registered new interface driver dvb_usb_nova_t_usb2
DVB: registering frontend 0 (ST STV0299 DVB-S)...
input: DVB on-card IR receiver as /class/input/input3
dvb-ttpci: found av7110-0.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: possible recursive locking detected
  2008-03-09 17:08 possible recursive locking detected bruno.roussel
@ 2008-03-09 21:16 ` Christian Kujau
  2008-03-09 22:41   ` Jiri Kosina
  0 siblings, 1 reply; 5+ messages in thread
From: Christian Kujau @ 2008-03-09 21:16 UTC (permalink / raw)
  To: bruno.roussel; +Cc: LKML, i2c, jikos

On Sun, 9 Mar 2008, bruno.roussel@free.fr wrote:
> I have this report in dmesg :
>
> saa7146_vv: saa7146 (0): registered device video0 [v4l2]
> saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
> usb-storage: device found at 2
> usb-storage: waiting for device to settle before scanning
> dvb-usb: found a 'Hauppauge WinTV-NOVA-T usb2' in warm state.
> dvb-usb: will pass the complete MPEG2 transport stream to the software demuxer.
> DVB: registering new adapter (Hauppauge WinTV-NOVA-T usb2)
> dvb-usb: MAC address: 00:0d:fe:00:00:00
> DVB: registering frontend 1 (DiBcom 3000MC/P)...
>
> =============================================
> [ INFO: possible recursive locking detected ]
> 2.6.24.2-1mdv #1
> ---------------------------------------------

Hm, strange: a similiar looking issue has been reported back in 2006, it
even comes with a patch: http://lkml.org/lkml/2006/10/14/38

..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
folks, maybe they can tell what's going on here.

C.

> modprobe/2082 is trying to acquire lock:
> (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
>
> but task is already holding lock:
> (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
>
> other info that might help us debug this:
> 1 lock held by modprobe/2082:
> #0:  (&adap->bus_lock){--..}, at: [<eeed4133>] i2c_transfer+0x2c/0x4b
> [i2c_core]
>
> stack backtrace:
> Pid: 2082, comm: modprobe Not tainted 2.6.24.2-1mdv #1
> [<c01054c2>] show_trace_log_lvl+0x1a/0x2f
> [<c0105ccf>] show_trace+0x12/0x14
> [<c0105fd7>] dump_stack+0x6a/0x70
> [<c0139e5b>] __lock_acquire+0x16b/0xc32
> [<c013ad80>] lock_acquire+0x70/0x92
> [<c02c937f>] mutex_lock_nested+0xf9/0x2a4
> [<eeed4133>] i2c_transfer+0x2c/0x4b [i2c_core]
> [<eef611fb>] dibx000_i2c_gated_tuner_xfer+0x172/0x18c [dibx000_common]
> [<eeed4140>] i2c_transfer+0x39/0x4b [i2c_core]
> [<eefbc17c>] mt2060_readreg+0x48/0x68 [mt2060]
> [<eefbc486>] mt2060_attach+0x49/0x1ef [mt2060]
> [<eefa3527>] dibusb_dib3000mc_tuner_attach+0x145/0x1fb [dvb_usb_dibusb_common]
> [<eef83c49>] dvb_usb_adapter_frontend_init+0xc4/0xe8 [dvb_usb]
> [<eef837aa>] dvb_usb_device_init+0x3e8/0x4ce [dvb_usb]
> [<eef7f01c>] nova_t_probe+0x1c/0x1e [dvb_usb_nova_t_usb2]
> [<eeeb1f51>] usb_probe_interface+0xd5/0x112 [usbcore]
> [<c02420bb>] driver_probe_device+0xca/0x14d
> [<c0242225>] __driver_attach+0x4a/0x7f
> [<c024164f>] bus_for_each_dev+0x38/0x5a
> [<c0241f25>] driver_attach+0x19/0x1b
> [<c0241966>] bus_add_driver+0x76/0x194
> [<c02423dd>] driver_register+0x67/0x6c
> [<eeeb1ae7>] usb_register_driver+0x7e/0xe5 [usbcore]
> [<eef8d01b>] nova_t_module_init+0x1b/0x38 [dvb_usb_nova_t_usb2]
> [<c0140e78>] sys_init_module+0x12c6/0x1394
> [<c0103e12>] sysenter_past_esp+0x6b/0xc9
> =======================
> input: IR-receiver inside an USB DVB receiver as /class/input/input2
> dvb-usb: schedule remote query interval to 100 msecs.
> dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully initialized and connected.
> usbcore: registered new interface driver dvb_usb_nova_t_usb2
> DVB: registering frontend 0 (ST STV0299 DVB-S)...
> input: DVB on-card IR receiver as /class/input/input3
> dvb-ttpci: found av7110-0.
> --

-- 
BOFH excuse #274:

It was OK before you touched it.

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: possible recursive locking detected
  2008-03-09 21:16 ` Christian Kujau
@ 2008-03-09 22:41   ` Jiri Kosina
  2008-03-10 13:29     ` Jean Delvare
  0 siblings, 1 reply; 5+ messages in thread
From: Jiri Kosina @ 2008-03-09 22:41 UTC (permalink / raw)
  To: Christian Kujau; +Cc: bruno.roussel, LKML, i2c

On Sun, 9 Mar 2008, Christian Kujau wrote:

> > =============================================
> > [ INFO: possible recursive locking detected ]
> > 2.6.24.2-1mdv #1
> > ---------------------------------------------
> Hm, strange: a similiar looking issue has been reported back in 2006, it 
> even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> ..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
> folks, maybe they can tell what's going on here.

I don't recall this, but from looking at the source it seems that only 
part of my patch made it upstream for some reason ... 

Bruno, does the patch below remove the warning for you? (we should rather 
used lockdep_set_class() now, when this is already available ... it wasn't 
in the time I was doping the original patch back in 2006).



Set locking depth properly (level == 0 for DVB frontend, level == 1 for 
DVB adapter).

Signed-off-by: Jiri Kosina <jkosina@suse.cz>

diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
index 23428cd..8c5dc35 100644
--- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
+++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
@@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
 #endif
 	d->i2c_adap.algo      = d->props.i2c_algo;
 	d->i2c_adap.algo_data = NULL;
+	d->i2c_adap.level = 1;
 	d->i2c_adap.dev.parent = &d->udev->dev;
 
 	i2c_set_adapdata(&d->i2c_adap, d);
diff --git a/drivers/media/dvb/frontends/dibx000_common.c b/drivers/media/dvb/frontends/dibx000_common.c
index 315e09e..a3ed8cf 100644
--- a/drivers/media/dvb/frontends/dibx000_common.c
+++ b/drivers/media/dvb/frontends/dibx000_common.c
@@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter *i2c_adap, struct i2c_algorithm *
 	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
 	i2c_adap->algo      = algo;
 	i2c_adap->algo_data = NULL;
+	i2c_adap->level = 0;
 	i2c_set_adapdata(i2c_adap, mst);
 	if (i2c_add_adapter(i2c_adap) < 0)
 		return -ENODEV;

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: possible recursive locking detected
  2008-03-09 22:41   ` Jiri Kosina
@ 2008-03-10 13:29     ` Jean Delvare
  2008-03-15 17:00       ` bruno.roussel
  0 siblings, 1 reply; 5+ messages in thread
From: Jean Delvare @ 2008-03-10 13:29 UTC (permalink / raw)
  To: Jiri Kosina; +Cc: Christian Kujau, bruno.roussel, LKML, i2c

On Sun, 9 Mar 2008 23:41:50 +0100 (CET), Jiri Kosina wrote:
> On Sun, 9 Mar 2008, Christian Kujau wrote:
> 
> > > =============================================
> > > [ INFO: possible recursive locking detected ]
> > > 2.6.24.2-1mdv #1
> > > ---------------------------------------------
> > Hm, strange: a similiar looking issue has been reported back in 2006, it 
> > even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> > ..but I cannot tell if the patch made it into mainline. I've Cc'ed the i2c
> > folks, maybe they can tell what's going on here.
> 
> I don't recall this, but from looking at the source it seems that only 
> part of my patch made it upstream for some reason ...

I applied the i2c-core part:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6ea23039cb1cc7c379eb5fba0ed2c53291e9bea7

But I have no idea what happened to the DVB device-driver specific part.

> 
> Bruno, does the patch below remove the warning for you? (we should rather 
> used lockdep_set_class() now, when this is already available ... it wasn't 
> in the time I was doping the original patch back in 2006).
> 
> 
> 
> Set locking depth properly (level == 0 for DVB frontend, level == 1 for 
> DVB adapter).
> 
> Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> 
> diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> index 23428cd..8c5dc35 100644
> --- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> +++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> @@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
>  #endif
>  	d->i2c_adap.algo      = d->props.i2c_algo;
>  	d->i2c_adap.algo_data = NULL;
> +	d->i2c_adap.level = 1;
>  	d->i2c_adap.dev.parent = &d->udev->dev;
>  
>  	i2c_set_adapdata(&d->i2c_adap, d);
> diff --git a/drivers/media/dvb/frontends/dibx000_common.c b/drivers/media/dvb/frontends/dibx000_common.c
> index 315e09e..a3ed8cf 100644
> --- a/drivers/media/dvb/frontends/dibx000_common.c
> +++ b/drivers/media/dvb/frontends/dibx000_common.c
> @@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter *i2c_adap, struct i2c_algorithm *
>  	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
>  	i2c_adap->algo      = algo;
>  	i2c_adap->algo_data = NULL;
> +	i2c_adap->level = 0;
>  	i2c_set_adapdata(i2c_adap, mst);
>  	if (i2c_add_adapter(i2c_adap) < 0)
>  		return -ENODEV;

Also note:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cea443a81c9c6257bf2d00f1392f7d1d4ce03b75

This patch that was applied recently to i2c-core might cause lockdep
issues. For some reason there's no "nested" variant of mutex_trylock?

-- 
Jean Delvare

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: possible recursive locking detected
  2008-03-10 13:29     ` Jean Delvare
@ 2008-03-15 17:00       ` bruno.roussel
  0 siblings, 0 replies; 5+ messages in thread
From: bruno.roussel @ 2008-03-15 17:00 UTC (permalink / raw)
  To: Jean Delvare; +Cc: Jiri Kosina, Christian Kujau, bruno.roussel, LKML, i2c

I have switch to the new 2.6.24.3 kernel version and it's OK now
Strange ...

Thank's for all

Selon Jean Delvare <khali@linux-fr.org>:

> On Sun, 9 Mar 2008 23:41:50 +0100 (CET), Jiri Kosina wrote:
> > On Sun, 9 Mar 2008, Christian Kujau wrote:
> >
> > > > =============================================
> > > > [ INFO: possible recursive locking detected ]
> > > > 2.6.24.2-1mdv #1
> > > > ---------------------------------------------
> > > Hm, strange: a similiar looking issue has been reported back in 2006, it
> > > even comes with a patch: http://lkml.org/lkml/2006/10/14/38
> > > ..but I cannot tell if the patch made it into mainline. I've Cc'ed the
> i2c
> > > folks, maybe they can tell what's going on here.
> >
> > I don't recall this, but from looking at the source it seems that only
> > part of my patch made it upstream for some reason ...
>
> I applied the i2c-core part:
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=6ea23039cb1cc7c379eb5fba0ed2c53291e9bea7
>
> But I have no idea what happened to the DVB device-driver specific part.
>
> >
> > Bruno, does the patch below remove the warning for you? (we should rather
> > used lockdep_set_class() now, when this is already available ... it wasn't
> > in the time I was doping the original patch back in 2006).
> >
> >
> >
> > Set locking depth properly (level == 0 for DVB frontend, level == 1 for
> > DVB adapter).
> >
> > Signed-off-by: Jiri Kosina <jkosina@suse.cz>
> >
> > diff --git a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> > index 23428cd..8c5dc35 100644
> > --- a/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> > +++ b/drivers/media/dvb/dvb-usb/dvb-usb-i2c.c
> > @@ -27,6 +27,7 @@ int dvb_usb_i2c_init(struct dvb_usb_device *d)
> >  #endif
> >  	d->i2c_adap.algo      = d->props.i2c_algo;
> >  	d->i2c_adap.algo_data = NULL;
> > +	d->i2c_adap.level = 1;
> >  	d->i2c_adap.dev.parent = &d->udev->dev;
> >
> >  	i2c_set_adapdata(&d->i2c_adap, d);
> > diff --git a/drivers/media/dvb/frontends/dibx000_common.c
> b/drivers/media/dvb/frontends/dibx000_common.c
> > index 315e09e..a3ed8cf 100644
> > --- a/drivers/media/dvb/frontends/dibx000_common.c
> > +++ b/drivers/media/dvb/frontends/dibx000_common.c
> > @@ -111,6 +111,7 @@ static int i2c_adapter_init(struct i2c_adapter
> *i2c_adap, struct i2c_algorithm *
> >  	i2c_adap->class     = I2C_CLASS_TV_DIGITAL,
> >  	i2c_adap->algo      = algo;
> >  	i2c_adap->algo_data = NULL;
> > +	i2c_adap->level = 0;
> >  	i2c_set_adapdata(i2c_adap, mst);
> >  	if (i2c_add_adapter(i2c_adap) < 0)
> >  		return -ENODEV;
>
> Also note:
>
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=cea443a81c9c6257bf2d00f1392f7d1d4ce03b75
>
> This patch that was applied recently to i2c-core might cause lockdep
> issues. For some reason there's no "nested" variant of mutex_trylock?
>
> --
> Jean Delvare
>



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2008-03-15 17:00 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-09 17:08 possible recursive locking detected bruno.roussel
2008-03-09 21:16 ` Christian Kujau
2008-03-09 22:41   ` Jiri Kosina
2008-03-10 13:29     ` Jean Delvare
2008-03-15 17:00       ` bruno.roussel

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).