From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753741AbYE1JqR (ORCPT ); Wed, 28 May 2008 05:46:17 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1751455AbYE1JqH (ORCPT ); Wed, 28 May 2008 05:46:07 -0400 Received: from viefep31-int.chello.at ([62.179.121.49]:53307 "EHLO viefep31-int.chello.at" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751414AbYE1JqH (ORCPT ); Wed, 28 May 2008 05:46:07 -0400 Subject: Re: MPTSAS problems in 2.6.26-rc2-mm1 From: Peter Zijlstra To: balbir@linux.vnet.ibm.com Cc: linux-scsi@vger.kernel.org, Andrew Morton , linux kernel mailing list In-Reply-To: <483D28C5.4060406@linux.vnet.ibm.com> References: <483D28C5.4060406@linux.vnet.ibm.com> Content-Type: text/plain Date: Wed, 28 May 2008 11:45:58 +0200 Message-Id: <1211967958.12349.65.camel@twins> Mime-Version: 1.0 X-Mailer: Evolution 2.22.1 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2008-05-28 at 15:11 +0530, Balbir Singh wrote: > I have 2.6.26-rc2-mm1 with Rik's splitvm patches. While booting the kernel, I > ran into the following. I searched my email quickly to see that no one else has > reported this problem. Lockdep seems to be complaining about the same lock being > held at the same location (the message is a bit confusing to me). looks like device_add() recursing - most likely with a different device though. > ============================================= > [ INFO: possible recursive locking detected ] > 2.6.26-rc2-mm1 #2 > --------------------------------------------- > insmod/1072 is trying to acquire lock: > (&cls->mutex){--..}, at: [] device_add+0x46e/0x5d7 > > but task is already holding lock: > (&cls->mutex){--..}, at: [] device_add+0x46e/0x5d7 > > other info that might help us debug this: > 3 locks held by insmod/1072: > #0: (&ioc->sas_discovery_mutex){--..}, at: [] > mptsas_probe+0x3a1/0x442 [mptsas] > #1: (&shost->scan_mutex){--..}, at: [] > scsi_scan_target+0x71/0xb0 > #2: (&cls->mutex){--..}, at: [] device_add+0x46e/0x5d7 > > stack backtrace: > Pid: 1072, comm: insmod Not tainted 2.6.26-rc2-mm1 #2 > > Call Trace: > [] __lock_acquire+0x911/0xc4c > [] ? __lock_acquire+0xc01/0xc4c > [] ? device_add+0x46e/0x5d7 > [] lock_acquire+0x8e/0xb2 > [] ? device_add+0x46e/0x5d7 > [] mutex_lock_nested+0xf2/0x27f > [] ? device_add+0x46e/0x5d7 > [] ? _spin_unlock+0x26/0x2a > [] device_add+0x46e/0x5d7 > [] device_register+0x19/0x1d > [] device_create+0xdf/0x110 > [] ? trace_hardirqs_on_caller+0xf9/0x124 > [] ? trace_hardirqs_on+0xd/0xf > [] ? mutex_unlock+0x9/0xb > [] ? kobj_map+0x119/0x12e > [] ? exact_lock+0x0/0x14 > [] ? exact_match+0x0/0x9 > [] sg_add+0x262/0x394 > [] ? _spin_unlock+0x26/0x2a > [] device_add+0x4bd/0x5d7 > [] scsi_sysfs_add_sdev+0xde/0x200 > [] scsi_probe_and_add_lun+0x847/0x977 > [] __scsi_scan_target+0xbf/0x522 > [] ? trace_hardirqs_on_caller+0xf9/0x124 > [] ? debug_mutex_free_waiter+0x46/0x4a > [] ? mutex_lock_nested+0x270/0x27f > [] ? scsi_scan_target+0x71/0xb0 > [] scsi_scan_target+0x9c/0xb0 > [] :scsi_transport_sas:sas_rphy_add+0x14c/0x15b > [] :mptsas:mptsas_probe_one_phy+0x364/0x3a9 > [] :mptsas:mptsas_probe_hba_phys+0x5bb/0x614 > [] ? :mptbase:mpt_timer_expired+0x0/0x2e > [] ? :mptbase:mpt_timer_expired+0x0/0x2e > [] ? :mptbase:mpt_timer_expired+0x0/0x2e > [] :mptsas:mptsas_probe+0x3a9/0x442 > [] pci_device_probe+0xbd/0x116 > [] driver_probe_device+0xdb/0x162 > [] __driver_attach+0x4f/0x79 > [] ? __driver_attach+0x0/0x79 > [] bus_for_each_dev+0x4d/0x7e > [] driver_attach+0x1c/0x1e > [] bus_add_driver+0xba/0x212 > [] driver_register+0x93/0x10a > [] __pci_register_driver+0x73/0xad > [] :mptsas:mptsas_init+0xe2/0xfa > [] sys_init_module+0x9e/0x1b2 > [] system_call_after_swapgs+0x7b/0x80 > > >