[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140509090642.GA4267@lianli>
Date: Fri, 9 May 2014 11:06:42 +0200
From: Emil Goode <emilgoode@...il.com>
To: Meelis Roos <mroos@...ux.ee>
Cc: netdev@...r.kernel.org
Subject: Re: cassini: possible recursive locking detected
On Fri, May 09, 2014 at 08:37:30AM +0300, Meelis Roos wrote:
> > > > It won't fix the deadlock that you mentioned though.
> > >
> > > Yes, the hang still happens, following a
> > > ERROR: System Hardware FATAL RESET from CPU0 CPU2
> > >
> >
> > Are you able to get the full dmesg output?
> > I think this could be hard to solve since I don't have
> > the hardware, but could take a look.
>
> There is sparc64 firmware-specific FATAL RESET only, inclugind pages of
> state dump for all 4 CPU-s and their MMUs etc. Nothing from Linux side.
>
> So it's like recursive fault or something similar.
>
I searched the net a bit and found these old threads:
http://lists.freebsd.org/pipermail/freebsd-sparc64/2010-January/006935.html
"FreeBSD currently crashes on older models of V480 when attempting
to use an on-board NIC due to what appears to be a CPU bug which
needs to be worked around."
http://marc.info/?l=linux-sparc&m=122220796209509&w=2
"I noticed the cassini network driver for the builtin gigabit
network is unstable and brings the kernel down on a dualprocessor sparc
SunFire 480R with a Hardware FATAL RESET"
I think you should ask about this on the sparclinux mailing list.
http://vger.kernel.org/vger-lists.html#sparclinux
I would say it's very unlikely that the problem is related to that lockdep warning.
> >
> > > >
> > > > Best regards,
> > > >
> > > > Emil Goode
> > > >
> > > > On Tue, May 06, 2014 at 12:39:48PM +0300, Meelis Roos wrote:
> > > > > While installing Linux on Sun Fire V480, any traffic on builtin cassini
> > > > > NIC caused a hang. Worked this around by using Broadcom NIC and tried a
> > > > > kernel with most debugging options. This resulted in the following
> > > > > warning. Maybe this is the deadlonck I was seeing?
> > > > >
> > > > > [ 88.316595] =============================================
> > > > > [ 88.316597] [ INFO: possible recursive locking detected ]
> > > > > [ 88.316603] 3.15.0-rc4-00202-g30321c7-dirty #11 Not tainted
> > > > > [ 88.316605] ---------------------------------------------
> > > > > [ 88.316608] swapper/3/1 is trying to acquire lock:
> > > > > [ 88.316644] (&(&cp->tx_lock[i])->rlock){..-...}, at: [<0000000000745da0>] cas_link_timer+0xa0/0x460
> > > > > [ 88.316646]
> > > > > [ 88.316646] but task is already holding lock:
> > > > > [ 88.316657] (&(&cp->tx_lock[i])->rlock){..-...}, at: [<0000000000745da0>] cas_link_timer+0xa0/0x460
> > > > > [ 88.316659]
> > > > > [ 88.316659] other info that might help us debug this:
> > > > > [ 88.316661] Possible unsafe locking scenario:
> > > > > [ 88.316661]
> > > > > [ 88.316662] CPU0
> > > > > [ 88.316664] ----
> > > > > [ 88.316668] lock(&(&cp->tx_lock[i])->rlock);
> > > > > [ 88.316671] lock(&(&cp->tx_lock[i])->rlock);
> > > > > [ 88.316672]
> > > > > [ 88.316672] *** DEADLOCK ***
> > > > > [ 88.316672]
> > > > > [ 88.316674] May be due to missing lock nesting notation
> > > > > [ 88.316674]
> > > > > [ 88.316677] 3 locks held by swapper/3/1:
> > > > > [ 88.316694] #0: ((&cp->link_timer)){+.-...}, at: [<0000000000465f80>] call_timer_fn+0x0/0xe0
> > > > > [ 88.316706] #1: (&(&cp->lock)->rlock){..-...}, at: [<0000000000745d80>] cas_link_timer+0x80/0x460
> > > > > [ 88.316716] #2: (&(&cp->tx_lock[i])->rlock){..-...}, at: [<0000000000745da0>] cas_link_timer+0xa0/0x460
> > > > > [ 88.316718]
> > > > > [ 88.316718] stack backtrace:
> > > > > [ 88.316724] CPU: 2 PID: 1 Comm: swapper/3 Not tainted 3.15.0-rc4-00202-g30321c7-dirty #11
> > > > > [ 88.316727] Call Trace:
> > > > > [ 88.316743] [00000000004a2c5c] __lock_acquire+0x10fc/0x1fa0
> > > > > [ 88.316749] [00000000004a406c] lock_acquire+0x4c/0x80
> > > > > [ 88.316760] [000000000083e07c] _raw_spin_lock+0x1c/0x40
> > > > > [ 88.316765] [0000000000745da0] cas_link_timer+0xa0/0x460
> > > > > [ 88.316769] [0000000000465fc8] call_timer_fn+0x48/0xe0
> > > > > [ 88.316775] [00000000004665d4] run_timer_softirq+0x214/0x280
> > > > > [ 88.316788] [000000000045f650] __do_softirq+0xf0/0x240
> > > > > [ 88.316800] [000000000042bd0c] do_softirq_own_stack+0x2c/0x40
> > > > > [ 88.316804] [000000000045fb44] irq_exit+0xc4/0xe0
> > > > > [ 88.316814] [000000000042fcc8] timer_interrupt+0x88/0xc0
> > > > > [ 88.316819] [0000000000426b84] valid_addr_bitmap_patch+0xbc/0x238
> > > > > [ 88.316826] [00000000004ab2f8] vprintk_emit+0x1d8/0x540
> > > > > [ 88.316842] [0000000000835fb8] printk+0x34/0x48
> > > > > [ 88.316847] [00000000004ac3e0] register_console+0x340/0x3e0
> > > > > [ 88.316862] [0000000000a74f2c] init_netconsole+0x180/0x20c
> > > > > [ 88.316867] [0000000000426eb0] do_one_initcall+0x110/0x1a0
> > > > >
> > > > > --
> > > > > Meelis Roos (mroos@...ux.ee)
> > > > > --
> > > > > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > > > > the body of a message to majordomo@...r.kernel.org
> > > > > More majordomo info at http://vger.kernel.org/majordomo-info.html
> > > >
> > >
> > > --
> > > Meelis Roos (mroos@...ux.ee)
> >
>
> --
> Meelis Roos (mroos@...ux.ee)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists