Re: [PATCH] pch_dma: Fix channel locking

[Alexander Stein]

On Tuesday 28 June 2011 12:34:34 Tomoya MORINAGA wrote:
> (2011/06/27 23:22), Alexander Stein wrote:
> > Ok. I have a 2.6.39 kernel with the following patches:
> > pch_phub: Don't panic if dmi_get_system_info returns NULL
> > drivers/tty/serial/pch_uart.c: don't oops if dmi_get_system_info returns
> > NULL pch_uart: Add console support
> > 
> > I need these to get a booting board with console support on pch_uart.
> > After boot (dma and pch_uart compiled into kernel), I do
> > * setserial /dev/ttyPCH0 ^low_latency
> > * ./raise_dma_fault
> > <- Here I get the message
> 
> Thank you for your information.
> I could see the kernel message.
> However using your patch, it seems the message remains to be seen.
> 
> [  142.401597] pch_uart 0000:02:0a.1: PCH UART : Use DMA Mode
> [  148.011410]
> [  148.011415] =================================
> [  148.011428] [ INFO: inconsistent lock state ]
> [  148.011439] 2.6.39.2+ #5
> [  148.011446] ---------------------------------
> [  148.011455] inconsistent {HARDIRQ-ON-W} -> {IN-HARDIRQ-W} usage.
> [  148.011467] gnome-terminal/1759 [HC1[1]:SC0[0]:HE0:SE1] takes:
> [  148.011477]  (&(&pd_chan->lock)->rlock){?.....}, at: [<c0710cc5>]
> pd_prep_slave_sg+0x92/0x26d
> [  148.011509] {HARDIRQ-ON-W} state was registered at:
> [  148.011516]   [<c04618a1>] __lock_acquire+0x2d9/0xbcc
> [  148.011533]   [<c0462594>] lock_acquire+0x94/0xb7
> [  148.011546]   [<c07cec85>] _raw_spin_lock_bh+0x25/0x34
> [  148.011561]   [<c07110d0>] pd_alloc_chan_resources+0xb2/0x165
> [  148.011577]   [<c070f447>] dma_chan_get+0x63/0xbb
> [  148.011591]   [<c070f7a0>] __dma_request_channel+0x168/0x246
> [  148.011606]   [<c0655ff4>] pch_uart_startup+0x16b/0x2c4
> [  148.011622]   [<c064f2df>] uart_startup+0x8b/0x158
> [  148.011636]   [<c0650149>] uart_open+0x13f/0x168
> [  148.011649]   [<c063b561>] tty_open+0x2c2/0x3cc
> [  148.011663]   [<c04e8113>] chrdev_open+0xf4/0x118
> [  148.011678]   [<c04e3a68>] __dentry_open+0x167/0x255
> [  148.011694]   [<c04e477b>] nameidata_to_filp+0x4a/0x58
> [  148.011708]   [<c04ee74b>] do_last+0x45d/0x573
> [  148.011722]   [<c04ef75c>] path_openat+0x9b/0x2b5
> [  148.011735]   [<c04ef99c>] do_filp_open+0x26/0x62
> [  148.011749]   [<c04e47e2>] do_sys_open+0x59/0xd2
> [  148.011762]   [<c04e487e>] sys_open+0x23/0x2b
> [  148.011775]   [<c07d4bdf>] sysenter_do_call+0x12/0x38
> [  148.011791] irq event stamp: 485514
> [  148.011799] hardirqs last  enabled at (485513): [<c07d4c59>]
> sysexit_audit+0x11/0x50
> [  148.011815] hardirqs last disabled at (485514): [<c07d51ae>]
> common_interrupt+0x2e/0x3c
> [  148.011832] softirqs last  enabled at (485398): [<c043f585>]
> __do_softirq+0x153/0x162
> [  148.011849] softirqs last disabled at (485375): [<c040430a>]
> do_softirq+0x65/0xba
> [  148.011866]
> [  148.011869] other info that might help us debug this:
> [  148.011879] 1 lock held by gnome-terminal/1759:
> [  148.011886]  #0:  (&port_lock_key){-.-...}, at: [<c06555ab>]
> pch_uart_interrupt+0x19/0x804
> [  148.011912]
> [  148.011915] stack backtrace:
> [  148.011926] Pid: 1759, comm: gnome-terminal Not tainted 2.6.39.2+ #5
> [  148.011934] Call Trace:
> [  148.011949]  [<c07ccca4>] ? printk+0x25/0x29
> [  148.011962]  [<c0461407>] valid_state+0x133/0x141
> [  148.011976]  [<c04614e4>] mark_lock+0xcf/0x1b3
> [  148.011990]  [<c0460e57>] ? print_irq_inversion_bug+0xe9/0xe9
> [  148.012004]  [<c046182d>] __lock_acquire+0x265/0xbcc
> [  148.012019]  [<c0461af7>] ? __lock_acquire+0x52f/0xbcc
> [  148.012034]  [<c0710cc5>] ? pd_prep_slave_sg+0x92/0x26d
> [  148.012047]  [<c0462594>] lock_acquire+0x94/0xb7
> [  148.012061]  [<c0710cc5>] ? pd_prep_slave_sg+0x92/0x26d
> [  148.012076]  [<c07ceacb>] _raw_spin_lock+0x20/0x2f
> [  148.012090]  [<c0710cc5>] ? pd_prep_slave_sg+0x92/0x26d
> [  148.012104]  [<c0710cc5>] pd_prep_slave_sg+0x92/0x26d
> [  148.012120]  [<c0655af2>] pch_uart_interrupt+0x560/0x804
> [  148.012138]  [<c04894fa>] handle_irq_event_percpu+0x53/0x174
> [  148.012153]  [<c048964c>] handle_irq_event+0x31/0x49
> [  148.012167]  [<c048b160>] ? handle_simple_irq+0x59/0x59
> [  148.012180]  [<c048b1cb>] handle_fasteoi_irq+0x6b/0x89
> [  148.012189]  <IRQ>  [<c0404028>] ? do_IRQ+0x3c/0x87
> [  148.012213]  [<c07d51b5>] ? common_interrupt+0x35/0x3c
> [  148.012219]  [<c043007b>] ? enqueue_task_fair+0x319/0x4cd
> [  148.012219]  [<c04f4a12>] ? dput+0xc5/0xca
> [  148.012219]  [<c04ecacc>] ? path_put+0x13/0x1d
> [  148.012219]  [<c047e0e2>] ? audit_free_names+0x45/0x5e
> [  148.012219]  [<c047e985>] ? audit_syscall_exit+0x96/0x114
> [  148.012219]  [<c07d4c71>] ? sysexit_audit+0x29/0x50

Odd. What does addr2line report for 0xc0710cc5 and for 0xc07110d0?

Regards,
Alexander
--
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/