Re: [PATCH] pch_dma: Fix channel locking

[Tomoya MORINAGA]

(2011/06/23 0:05), Alexander Stein wrote:
> Fix for the following INFO message
> 
> =================================
> [ INFO: inconsistent lock state ]
> 2.6.39+ #89
> ---------------------------------
> inconsistent {HARDIRQ-ON-W} ->  {IN-HARDIRQ-W} usage.
> rs232/822 [HC1[1]:SC0[0]:HE0:SE1] takes:
>   (&(&pd_chan->lock)->rlock){?.....}, at: [<c123b9a1>] pdc_desc_get+0x16/0xab
> {HARDIRQ-ON-W} state was registered at:
>    [<c104fe28>] mark_irqflags+0xbd/0x11a
>    [<c1050386>] __lock_acquire+0x501/0x6bb
>    [<c1050945>] lock_acquire+0x63/0x7b
>    [<c131c51d>] _raw_spin_lock_bh+0x43/0x51
>    [<c123bee4>] pd_alloc_chan_resources+0x92/0x11e
>    [<c123ad62>] dma_chan_get+0x9b/0x107
>    [<c123b2d1>] __dma_request_channel+0x61/0xdc
>    [<c11ba24b>] pch_request_dma+0x61/0x19e
>    [<c11bb3b8>] pch_uart_startup+0x16a/0x1a2
>    [<c11b8446>] uart_startup+0x87/0x147
>    [<c11b9183>] uart_open+0x117/0x13e
>    [<c11a5c7d>] tty_open+0x23c/0x34c
>    [<c1097705>] chrdev_open+0x140/0x15f
>    [<c10930a6>] __dentry_open.clone.14+0x14a/0x22b
>    [<c1093dfb>] nameidata_to_filp+0x36/0x40
>    [<c109f28b>] do_last+0x513/0x635
>    [<c109f4af>] path_openat+0x9c/0x2aa
>    [<c109f6e4>] do_filp_open+0x27/0x69
>    [<c1093f02>] do_sys_open+0xfd/0x184
>    [<c1093fad>] sys_open+0x24/0x2a
>    [<c131d58c>] sysenter_do_call+0x12/0x32
> irq event stamp: 2522
> hardirqs last  enabled at (2521): [<c131ca3b>] _raw_spin_unlock_irqrestore+0x36/0x52
> hardirqs last disabled at (2522): [<c131db27>] common_interrupt+0x27/0x34
> softirqs last  enabled at (2354): [<c102fa11>] __do_softirq+0x10a/0x11a
> softirqs last disabled at (2299): [<c10041a4>] do_softirq+0x57/0xa4
> 
> other info that might help us debug this:
> 2 locks held by rs232/822:
>   #0:  (&tty->atomic_write_lock){+.+.+.}, at: [<c11a4b7a>] tty_write_lock+0x14/0x3c
>   #1:  (&port_lock_key){-.....}, at: [<c11bad72>] pch_uart_interrupt+0x17/0x1e9
> 
> stack backtrace:
> Pid: 822, comm: rs232 Not tainted 2.6.39+ #89
> Call Trace:
>   [<c1319f90>] ? printk+0x19/0x1b
>   [<c104f893>] print_usage_bug+0x184/0x18f
>   [<c104e5b1>] ? print_irq_inversion_bug+0x10e/0x10e
>   [<c104f943>] mark_lock_irq+0xa5/0x1f6
>   [<c104fc9c>] mark_lock+0x208/0x2d7
>   [<c104fdc0>] mark_irqflags+0x55/0x11a
>   [<c1050386>] __lock_acquire+0x501/0x6bb
>   [<c10042ee>] ? dump_trace+0x92/0xb6
>   [<c1050945>] lock_acquire+0x63/0x7b
>   [<c123b9a1>] ? pdc_desc_get+0x16/0xab
>   [<c131c2d0>] _raw_spin_lock+0x3e/0x4c
>   [<c123b9a1>] ? pdc_desc_get+0x16/0xab
>   [<c123b9a1>] pdc_desc_get+0x16/0xab
>   [<c10504d8>] ? __lock_acquire+0x653/0x6bb
>   [<c123bb2c>] pd_prep_slave_sg+0x7c/0x1cb
>   [<c1006c3f>] ? nommu_map_sg+0x6e/0x81
>   [<c11bace6>] dma_handle_tx+0x2cf/0x344
>   [<c11bad72>] ? pch_uart_interrupt+0x17/0x1e9
>   [<c11baebb>] pch_uart_interrupt+0x160/0x1e9
>   [<c10642fb>] handle_irq_event_percpu+0x25/0x127
>   [<c1064429>] handle_irq_event+0x2c/0x43
>   [<c1065e0d>] ? handle_fasteoi_irq+0x84/0x84
>   [<c1065eb9>] handle_edge_irq+0xac/0xce
>   <IRQ>   [<c1003ecb>] ? do_IRQ+0x38/0x9d
>   [<c131db2e>] ? common_interrupt+0x2e/0x34
>   [<c105007b>] ? __lock_acquire+0x1f6/0x6bb
>   [<c131ca3d>] ? _raw_spin_unlock_irqrestore+0x38/0x52
>   [<c11b798b>] ? uart_start+0x2d/0x32
>   [<c11b7998>] ? uart_flush_chars+0x8/0xa
>   [<c11a7962>] ? n_tty_write+0x12c/0x1c6
>   [<c1027a73>] ? try_to_wake_up+0x251/0x251
>   [<c11a4d0b>] ? tty_write+0x169/0x1dc
>   [<c11a7836>] ? n_tty_ioctl+0xb7/0xb7
>   [<c1094841>] ? vfs_write+0x91/0x10d
>   [<c11a4ba2>] ? tty_write_lock+0x3c/0x3c
>   [<c1094a69>] ? sys_write+0x3e/0x63
>   [<c131d58c>] ? sysenter_do_call+0x12/0x32
> 

To: Yong Y
You wrote these spin_lock_bh(s), right ?
Could you tell us your opinion ?

To: Alexander
Thank you for your report.
How can I see the above kernel error log ?
Let me know your test condition.


-- 
tomoya
OKI SEMICONDUCTOR CO., LTD.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/