Re: 'scheduling while atomic' during ppp connection on 2.6.37.1 and 2.6.38
From: Jiri Slaby <hidden>
Date: 2011-03-20 21:52:16
On 03/20/2011 07:42 PM, Jack Stone wrote:
Hi, On 03/19/2011 10:06 PM, Mac wrote:quoted
dmesg returned: [ 9229.131031] BUG: scheduling while atomic: firefox-bin/1992/0x10000800 [ 9229.131035] Modules linked in: ppp_async crc_ccitt ppp_generic slhc snd_hda_codec_realtek ath5k ath processor battery ac snd_hda_intel r8169 sdhci_pci sparse_keymap sdhci snd_hda_codec mmc_core nozomi container snd_hwdep [ 9229.131076] Pid: 1992, comm: firefox-bin Not tainted 2.6.38 #1 [ 9229.131079] Call Trace: [ 9229.131089] [] ? schedule+0x67/0x3db [ 9229.131095] [] ? nf_conntrack_tuple_taken+0xa2/0xad [ 9229.131102] [] ? __cond_resched+0x1c/0x25 [ 9229.131105] [] ? _cond_resched+0x16/0x20 [ 9229.131109] [] ? mutex_lock+0xe/0x21 [ 9229.131116] [] ? ntty_write+0x5d/0x192 [nozomi] [ 9229.131121] [] ? __mod_timer.clone.30+0xbe/0xcc [ 9229.131126] [] ? check_preempt_curr+0x60/0x6d [ 9229.131130] [] ? __nf_ct_refresh_acct+0x75/0xbe [ 9229.131135] [] ? ppp_async_push+0xa9/0x3bd [ppp_async] [ 9229.131140] [] ? ppp_async_send+0x34/0x40 [ppp_async] [ 9229.131146] [] ? ppp_push+0x6c/0x4f9 [ppp_generic] [ 9229.131152] [] ? selinux_ip_postroute+0x3d/0x210 [ 9229.131156] [] ? ipt_do_table+0x300/0x328 [ 9229.131162] [] ? _local_bh_enable_ip.clone.10+0x1f/0x88 [ 9229.131166] [] ? ipt_do_table+0x300/0x328 [ 9229.131171] [] ? ppp_xmit_process+0x3f5/0x472 [ppp_generic] [ 9229.131176] [] ? ppp_start_xmit+0x155/0x174 [ppp_generic] [ 9229.131181] [] ? dev_hard_start_xmit+0x3c7/0x4a0 [ 9229.131186] [] ? sch_direct_xmit+0x3e/0xee [ 9229.131190] [] ? dev_queue_xmit+0x1cd/0x322 [ 9229.131194] [] ? ip_queue_xmit+0x2d4/0x330 [ 9229.131200] [] ? file_update_time+0x30/0x101 [ 9229.131204] [] ? tcp_transmit_skb+0x6ee/0x721 [ 9229.131208] [] ? tcp_write_xmit+0x765/0x851 [ 9229.131213] [] ? __alloc_skb+0x81/0x121 [ 9229.131217] [] ? __tcp_push_pending_frames+0x18/0x44 [ 9229.131221] [] ? tcp_close+0x127/0x2f7 [ 9229.131226] [] ? inet_release+0x53/0x5c [ 9229.131231] [] ? sock_release+0x19/0x6e [ 9229.131234] [] ? sock_close+0x22/0x29 [ 9229.131239] [] ? fput+0xf8/0x19a [ 9229.131243] [] ? filp_close+0x5d/0x68 [ 9229.131246] [] ? sys_close+0x6f/0x9e [ 9229.131251] [] ? system_call_fastpath+0x16/0x1bCan you try the following patch? [ Greg, I think this is the correct fix but you know more than me.]
FWIW it looks good to me. Note that the very same problem is in rocket. And moxa enables bh interrupts unconditionally before it returns. This might (and likely will) make the ppp locking unhappy. Could you fix that too? (If not, I will take a look at what I can do about that.)
quoted hunk ↗ jump to hunk
diff --git a/drivers/tty/nozomi.c b/drivers/tty/nozomi.c index f4f1116..78a1ab3 100644 --- a/drivers/tty/nozomi.c +++ b/drivers/tty/nozomi.c@@ -364,8 +364,6 @@ struct port { u8 toggle_ul; u16 token_dl; - /* mutex to ensure one access patch to this port */ - struct mutex tty_sem; wait_queue_head_t tty_wait; struct async_icount tty_icount;@@ -1474,7 +1472,6 @@ static int __devinit nozomi_card_init(structpci_dev *pdev, struct device *tty_dev; struct port *port = &dc->port[i]; port->dc = dc; - mutex_init(&port->tty_sem); tty_port_init(&port->port); port->port.ops = &noz_tty_port_ops; tty_dev = tty_register_device(ntty_driver, dc->index_start + i,
thanks, -- js suse labs