From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755838Ab0EaOcx (ORCPT ); Mon, 31 May 2010 10:32:53 -0400 Received: from cantor2.suse.de ([195.135.220.15]:41772 "EHLO mx2.suse.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754873Ab0EaOcv (ORCPT ); Mon, 31 May 2010 10:32:51 -0400 Subject: Re: aha1542 oops caused by new request_irq routines From: James Bottomley To: Tedheadster Cc: linux-scsi@vger.kernel.org, linux-kernel , Thomas Gleixner In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Date: Mon, 31 May 2010 09:32:44 -0500 Message-ID: <1275316364.2823.22.camel@mulgrave.site> Mime-Version: 1.0 X-Mailer: Evolution 2.28.2 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, 2010-05-31 at 10:03 -0400, Tedheadster wrote: > I'm reliably getting this oops: > > Configuring Adaptec (SCSI-ID 6) at IO:334, IRQ 10, DMA priority 6 > BUG: sleeping function called from invalid context at mm/slub.c:1598 > in_atomic(): 0, irqs_disabled(): 1, pid: 4782, name: modprobe > Pid: 4782, comm: modprobe Not tainted 2.6.30.10-105.2.23.RODATA.fc11.i586 #1 > Call Trace: > [] ? request_threaded_irq+0x85/0x145 > [] __might_sleep+0xc4/0xc9 > [] kmem_cache_alloc_notrace+0x29/0xb0 > [] request_threaded_irq+0x85/0x145 > [] ? do_aha1542_intr_handle+0x0/0x2be [aha1542] > [] aha1542_detect+0x631/0x76f [aha1542] > [] init_this_scsi_driver+0x59/0xc7 [aha1542] > [] ? init_this_scsi_driver+0x0/0xc7 [aha1542] > [] do_one_initcall+0x51/0x13f > [] sys_init_module+0x8b/0x192 > [] syscall_call+0x7/0xb > scsi5 : Adaptec 1542 So this one's a bit tricky. aha1542 uses a global spinlock to give it thread safety and various other things. In this case it's trying to use the lock to hold off the interrupt until everything is set up. Now that we're doing a GFP_KERNEL allocation in the interrupt handler code you can't disable interrupts while calling request_irq since this is an old card liable to spurious interrupts as it gets poked in setup. I think a possible solution is this, since the mere act of installing an interrupt handler shouldn't trigger the problem. However, I thought the pattern of disabling interrupts and setting up the handler and registers was a common one ... is there some way this is supposed to work now that doesn't involve altering the drivers? James --- diff --git a/drivers/scsi/aha1542.c b/drivers/scsi/aha1542.c index 2a8cf13..0852079 100644 --- a/drivers/scsi/aha1542.c +++ b/drivers/scsi/aha1542.c @@ -1190,13 +1190,12 @@ fail: DEB(aha1542_stat()); DEB(printk("aha1542_detect: enable interrupt channel %d\n", irq_level)); - spin_lock_irqsave(&aha1542_lock, flags); if (request_irq(irq_level, do_aha1542_intr_handle, 0, "aha1542", shpnt)) { printk(KERN_ERR "Unable to allocate IRQ for adaptec controller.\n"); - spin_unlock_irqrestore(&aha1542_lock, flags); goto unregister; } + spin_lock_irqsave(&aha1542_lock, flags); if (dma_chan != 0xFF) { if (request_dma(dma_chan, "aha1542")) { printk(KERN_ERR "Unable to allocate DMA channel for Adaptec.\n");