Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757301Ab1F1LPf (ORCPT ); Tue, 28 Jun 2011 07:15:35 -0400 Received: from webbox687.server-home.net ([195.149.74.151]:50696 "EHLO webbox687.server-home.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757242Ab1F1LOy (ORCPT ); Tue, 28 Jun 2011 07:14:54 -0400 From: Alexander Stein To: Tomoya MORINAGA Subject: Re: [PATCH] pch_dma: Fix channel locking Date: Tue, 28 Jun 2011 13:14:51 +0200 User-Agent: KMail/1.13.7 (Linux/2.6.38-gentoo-r6; KDE/4.6.3; x86_64; ; ) Cc: "Wang, Yong Y" , Vinod Koul , Dan Williams , linux-kernel@vger.kernel.org, "Wang, Qi" , "toshiharu-linux@dsn.okisemi.com" References: <1308755133-8605-1-git-send-email-alexander.stein@systec-electronic.com> <201106271622.52763.alexander.stein@systec-electronic.com> <4E09AE3A.8050306@dsn.okisemi.com> In-Reply-To: <4E09AE3A.8050306@dsn.okisemi.com> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-2022-jp" Content-Transfer-Encoding: 7bit Message-Id: <201106281314.51722.alexander.stein@systec-electronic.com> Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4947 Lines: 100 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: [] > pd_prep_slave_sg+0x92/0x26d > [ 148.011509] {HARDIRQ-ON-W} state was registered at: > [ 148.011516] [] __lock_acquire+0x2d9/0xbcc > [ 148.011533] [] lock_acquire+0x94/0xb7 > [ 148.011546] [] _raw_spin_lock_bh+0x25/0x34 > [ 148.011561] [] pd_alloc_chan_resources+0xb2/0x165 > [ 148.011577] [] dma_chan_get+0x63/0xbb > [ 148.011591] [] __dma_request_channel+0x168/0x246 > [ 148.011606] [] pch_uart_startup+0x16b/0x2c4 > [ 148.011622] [] uart_startup+0x8b/0x158 > [ 148.011636] [] uart_open+0x13f/0x168 > [ 148.011649] [] tty_open+0x2c2/0x3cc > [ 148.011663] [] chrdev_open+0xf4/0x118 > [ 148.011678] [] __dentry_open+0x167/0x255 > [ 148.011694] [] nameidata_to_filp+0x4a/0x58 > [ 148.011708] [] do_last+0x45d/0x573 > [ 148.011722] [] path_openat+0x9b/0x2b5 > [ 148.011735] [] do_filp_open+0x26/0x62 > [ 148.011749] [] do_sys_open+0x59/0xd2 > [ 148.011762] [] sys_open+0x23/0x2b > [ 148.011775] [] sysenter_do_call+0x12/0x38 > [ 148.011791] irq event stamp: 485514 > [ 148.011799] hardirqs last enabled at (485513): [] > sysexit_audit+0x11/0x50 > [ 148.011815] hardirqs last disabled at (485514): [] > common_interrupt+0x2e/0x3c > [ 148.011832] softirqs last enabled at (485398): [] > __do_softirq+0x153/0x162 > [ 148.011849] softirqs last disabled at (485375): [] > 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: [] > 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] [] ? printk+0x25/0x29 > [ 148.011962] [] valid_state+0x133/0x141 > [ 148.011976] [] mark_lock+0xcf/0x1b3 > [ 148.011990] [] ? print_irq_inversion_bug+0xe9/0xe9 > [ 148.012004] [] __lock_acquire+0x265/0xbcc > [ 148.012019] [] ? __lock_acquire+0x52f/0xbcc > [ 148.012034] [] ? pd_prep_slave_sg+0x92/0x26d > [ 148.012047] [] lock_acquire+0x94/0xb7 > [ 148.012061] [] ? pd_prep_slave_sg+0x92/0x26d > [ 148.012076] [] _raw_spin_lock+0x20/0x2f > [ 148.012090] [] ? pd_prep_slave_sg+0x92/0x26d > [ 148.012104] [] pd_prep_slave_sg+0x92/0x26d > [ 148.012120] [] pch_uart_interrupt+0x560/0x804 > [ 148.012138] [] handle_irq_event_percpu+0x53/0x174 > [ 148.012153] [] handle_irq_event+0x31/0x49 > [ 148.012167] [] ? handle_simple_irq+0x59/0x59 > [ 148.012180] [] handle_fasteoi_irq+0x6b/0x89 > [ 148.012189] [] ? do_IRQ+0x3c/0x87 > [ 148.012213] [] ? common_interrupt+0x35/0x3c > [ 148.012219] [] ? enqueue_task_fair+0x319/0x4cd > [ 148.012219] [] ? dput+0xc5/0xca > [ 148.012219] [] ? path_put+0x13/0x1d > [ 148.012219] [] ? audit_free_names+0x45/0x5e > [ 148.012219] [] ? audit_syscall_exit+0x96/0x114 > [ 148.012219] [] ? 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/