[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <200906051201.04185.isdn@linux-pingi.de>
Date: Fri, 5 Jun 2009 12:01:03 +0200
From: Karsten Keil <isdn@...ux-pingi.de>
To: Andrew Morton <akpm@...ux-foundation.org>
Cc: Mathias Kretschmer <psoting@...4.net>,
linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: mISDN: WARNING: at kernel/softirq.c:124 local_bh_enable+0x8f/0xb0()
Hi,
I'm currently see this too from time to time, but have no idea about it.
On Freitag, 5. Juni 2009 04:59:48 Andrew Morton wrote:
> (cc's added)
>
> On Fri, 5 Jun 2009 00:07:12 +0200 Mathias Kretschmer <psoting@...4.net>
wrote:
> > Hi *,
> >
> > the following pops up from time to time when I place a call (might also
> > happened on incoming calls).
> >
> > machine is an AMD K8 dual core running a x86_64 2.6.29.4-grsec kernel.
> >
> > please, let me know if you need more details.
> >
> > cheers,
> >
> > Mathias
> >
> > [88563.318126] ------------[ cut here ]------------
> > [88563.318129] WARNING: at kernel/softirq.c:124
> > local_bh_enable+0x8f/0xb0() [88563.318130] Hardware name: empty
> > [88563.318132] Modules linked in: usbtouchscreen dvb_usb_cinergyT2 dummy
> > bonding snd_emu10k1 snd_rawmidi snd_ac97_codec ath9k ac97_bus snd_pcm
> > snd_page_alloc snd_util_mem forcedeth snd_hwdep
> > [88563.318141] Pid: 826, comm: mISDN_hfc-pci.1 Not tainted 2.6.29.4-grsec
> > #13 [88563.318142] Call Trace:
> > [88563.318147] [<ffffffff8025909a>] warn_slowpath+0xea/0x160
> > [88563.318149] [<ffffffff8025ee0f>] local_bh_enable+0x8f/0xb0
> > [88563.318152] [<ffffffff8065f284>] sk_filter+0x44/0xa0
> > [88563.318154] [<ffffffff8064548d>] sock_queue_rcv_skb+0x5d/0x120
> > [88563.318156] [<ffffffff8060410f>] mISDN_send+0x4f/0xa0
> > [88563.318159] [<ffffffff8060790e>] l2up_create+0x7e/0x100
> > [88563.318161] [<ffffffff8060b6e0>] l2_got_tei+0x0/0x90
> > [88563.318163] [<ffffffff8060b722>] l2_got_tei+0x42/0x90
> > [88563.318164] [<ffffffff80602d32>] mISDN_FsmEvent+0x82/0x100
> > [88563.318167] [<ffffffff8060cb00>] tei_id_assign+0x0/0x120
> > [88563.318168] [<ffffffff80602d32>] mISDN_FsmEvent+0x82/0x100
> > [88563.318170] [<ffffffff8060e373>] mgr_send+0x4d3/0x660
> > [88563.318172] [<ffffffff8061ac8e>] hfcpci_l2l1D+0x19e/0x2f0
> > [88563.318174] [<ffffffff80606591>] mISDNStackd+0x431/0x680
> > [88563.318177] [<ffffffff80270950>] autoremove_wake_function+0x0/0x30
> > [88563.318179] [<ffffffff80606160>] mISDNStackd+0x0/0x680
> > [88563.318181] [<ffffffff80270547>] kthread+0x47/0x80
> > [88563.318183] [<ffffffff802226fa>] child_rip+0xa/0x20
> > [88563.318185] [<ffffffff80270500>] kthread+0x0/0x80
> > [88563.318186] [<ffffffff802226f0>] child_rip+0x0/0x20
> > [88563.318188] ---[ end trace 2a7bb9b2f669de5a ]---
>
> hm, tricky, who disabled interrupts?
Yes, indeed I have no idea what exactely is going on.
> It could be
>
> spin_lock_irqsave(&hc->lock, flags);
>
> in hfcpci_l2l1D().
I do not think that this function is really in the call trace, in my dumps I
see also traces without hfcpci_l2l1D in it.
And I see no way back to mgr_send from hfcpci_l2l1D from the design
the HW functions are decoupled from the stack thread via queues, so
here should be no direct callback.
The common part is, that it seems always happen on successful TEI
assign.
Karsten
--
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