Re: possible recursive locking detected

Re: possible recursive locking detected

[Christian Kujau]

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.

Re: possible recursive locking detected

[Jiri Kosina]

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-AlSwsSmVLrQ@public.gmane.org>

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;

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: possible recursive locking detected

[Jean Delvare]

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-AlSwsSmVLrQ@public.gmane.org>
> 
> 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

_______________________________________________
i2c mailing list
i2c-GZX6beZjE8VD60Wz+7aTrA@public.gmane.org
http://lists.lm-sensors.org/mailman/listinfo/i2c

Re: possible recursive locking detected

[bruno.roussel]

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
>