From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1161006AbWJDFig (ORCPT ); Wed, 4 Oct 2006 01:38:36 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1161008AbWJDFig (ORCPT ); Wed, 4 Oct 2006 01:38:36 -0400 Received: from mx.go2.pl ([193.17.41.41]:46518 "EHLO poczta.o2.pl") by vger.kernel.org with ESMTP id S1161006AbWJDFif (ORCPT ); Wed, 4 Oct 2006 01:38:35 -0400 Date: Wed, 4 Oct 2006 07:43:08 +0200 From: Jarek Poplawski To: "Axel C\. Voigt" Cc: linux-kernel@vger.kernel.org, David Kubicek , Greg Kroah-Hartman Subject: Re: Problems with hard irq? (inconsistent lock state) Message-ID: <20061004054308.GA994@ff.dom.local> Mail-Followup-To: Jarek Poplawski , "Axel C. Voigt" , linux-kernel@vger.kernel.org, David Kubicek , Greg Kroah-Hartman Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <46E81D405FFAC240826E54028B3B02953B13@aixlac.qosmotec.com> User-Agent: Mutt/1.4.2.2i Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On 29-09-2006 13:45, Axel C. Voigt wrote: > > Hello all, > > today I received the following stack backtrace using debian-2.6.18 with our communications driver accessing a ACM device. This happened when removing (powering off and/or on) the mobile phone (nokia 6630) at /dev/ttyACMx > > Are someone able to get a hint for me? > > --schnipp-- > Sep 29 13:29:53 mcs70 kernel: > Sep 29 13:29:53 mcs70 kernel: ================================= > Sep 29 13:29:53 mcs70 kernel: [ INFO: inconsistent lock state ] > Sep 29 13:29:53 mcs70 kernel: --------------------------------- > Sep 29 13:29:53 mcs70 kernel: inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. > Sep 29 13:29:53 mcs70 kernel: startDV24/3864 [HC1[1]:SC0[0]:HE0:SE1] takes: > Sep 29 13:29:53 mcs70 kernel: (&acm->read_lock){++..}, at: [] acm_read_bulk+0x60/0xde [cdc_acm] > Sep 29 13:29:53 mcs70 kernel: {hardirq-on-W} state was registered at: > Sep 29 13:29:53 mcs70 kernel: [] lock_acquire+0x56/0x73 > Sep 29 13:29:53 mcs70 kernel: [] _spin_lock+0x1a/0x25 > Sep 29 13:29:53 mcs70 kernel: [] acm_rx_tasklet+0x52/0x2be [cdc_acm] > Sep 29 13:29:53 mcs70 kernel: [] tasklet_action+0x6d/0xd7 > Sep 29 13:29:53 mcs70 kernel: [] __do_softirq+0x79/0xf2 ... > Sep 29 13:29:53 mcs70 kernel: stack backtrace: > Sep 29 13:29:53 mcs70 kernel: [] show_trace+0x16/0x18 > Sep 29 13:29:53 mcs70 kernel: [] dump_stack+0x19/0x1b > Sep 29 13:29:53 mcs70 kernel: [] print_usage_bug+0x1e1/0x1eb > Sep 29 13:29:53 mcs70 kernel: [] mark_lock+0xa4/0x4d9 > Sep 29 13:29:53 mcs70 kernel: [] __lock_acquire+0x41a/0x841 > Sep 29 13:29:53 mcs70 kernel: [] lock_acquire+0x56/0x73 > Sep 29 13:29:53 mcs70 kernel: [] _spin_lock+0x1a/0x25 > Sep 29 13:29:53 mcs70 kernel: [] acm_read_bulk+0x60/0xde [cdc_acm] ... > Sep 29 13:29:53 mcs70 kernel: [] do_IRQ+0x4e/0x5f > Sep 29 13:29:53 mcs70 kernel: [] common_interrupt+0x25/0x2c ... It looks in drivers/usb/class/cdc-acm.c acm_rx_tasklet could be preempted with acm->read_lock by acm_read_bulk which uses the same lock from hardirq context. So probably spin_lock_irqsave is needed. > Mit freundlichen Grüssen/ with kind regards, > > Axel C. Voigt Serdecznie pozdrawiam/ cheers, Jarek P. >