RE: eata irq abuse (was: Re: Linux 2.5.60)

RE: eata irq abuse (was: Re: Linux 2.5.60)

[Ballabio_Dario]

Yes, you are correct. I used spin_unlock in order to release the local
driver lock
during the scsi_register call, but I forgot that I had the irq disabled as
well.
SO the correct fix is to use spin_unlock_irq/spin_lock_irq around the
scsi_register call. Same fix applies to the u14-34f driver.

Cheers,

*********************************
Ph.D. Dario Ballabio
EMC Computer Systems Italia spa
Mobile phone +393487978851
Office phone +390244571315
Mobile fax   +393487951622

*** Si vis pacem, para bellum ***


-----Original Message-----
From: Manfred Spraul [mailto:manfred@colorfullife.com]
Sent: Tuesday, February 11, 2003 6:46 PM
To: Zephaniah E. Hull
Cc: linux-kernel@vger.kernel.org; linux-scsi@vger.kernel.org;
linux-eata@i-connect.net
Subject: eata irq abuse (was: Re: Linux 2.5.60)


Zephaniah wrote:

>kernel BUG at mm/slab.c:1102!

Slab notices that a function that expects enabled local interrupts is called
with disabled local interrupts.


>Call Trace:
> [<c014a3b3>] do_tune_cpucache+0x83/0x240

do_tune_cpucache:
the function call smp_call_function(), and that is only permitted with
enabled local interrupts. The complain is correct.


> [<c014a300>] do_ccpupdate_local+0x0/0x30
> [<c014a5c1>] enable_cpucache+0x51/0x80
> [<c0148ea5>] kmem_cache_create+0x4a5/0x560

Within kmem_cache_create. kmem_cache_create checks for in_interrupt(), thus
someone probably does

	spin_lock_irqsave();
	kmem_cache_create();


> [<c0285dd2>] scsi_setup_command_freelist+0xa2/0x130

calls kmem_cache_create()

> [<c02887e0>] scsi_register+0x3c0/0x660

calls scsi_setup_command_freelist


> [<c02919a1>] get_pci_dev+0x31/0x50

?? probably stale

> [<c0291df2>] port_detect+0x3c2/0xe50

Do you have an eata scsi controller?

Ugs.
eata2x_detect():
* spin_lock_irqsave();
* calls port_detect();
* * spin_unlock();
* * scsi_register.

Eata maintainers: Is that necessary?
Why do the interrupts remain disabled across scsi_register?
Is that a bug workaround, or an oversight?
I'd use

	spin_unlock_irq();
	scsi_register();
	spin_lock_irq();

--
	Manfred


-
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: eata irq abuse (was: Re: Linux 2.5.60)

[Jeff Garzik]

Ballabio_Dario@emc.com wrote:
> Yes, you are correct. I used spin_unlock in order to release the local
> driver lock
> during the scsi_register call, but I forgot that I had the irq disabled as
> well.
> SO the correct fix is to use spin_unlock_irq/spin_lock_irq around the
> scsi_register call. Same fix applies to the u14-34f driver.


scsi_register may want to sleep, so that is not a fix at all...

Re: eata irq abuse (was: Re: Linux 2.5.60)

[Jeff Garzik]

Jeff Garzik wrote:
> Ballabio_Dario@emc.com wrote:
> 
>> Yes, you are correct. I used spin_unlock in order to release the local
>> driver lock
>> during the scsi_register call, but I forgot that I had the irq 
>> disabled as
>> well.
>> SO the correct fix is to use spin_unlock_irq/spin_lock_irq around the
>> scsi_register call. Same fix applies to the u14-34f driver.
> 
> scsi_register may want to sleep, so that is not a fix at all...


Ooops, I missed the order.  You (and Manfred) are right, 
unlock-register-lock is desired.

ENOCAFFEINE, I plead...

eata irq abuse (was: Re: Linux 2.5.60)

[Manfred Spraul]

Zephaniah wrote:

>kernel BUG at mm/slab.c:1102!

Slab notices that a function that expects enabled local interrupts is called with disabled local interrupts.


>Call Trace:
> [<c014a3b3>] do_tune_cpucache+0x83/0x240

do_tune_cpucache:
the function call smp_call_function(), and that is only permitted with enabled local interrupts. The complain is correct.


> [<c014a300>] do_ccpupdate_local+0x0/0x30
> [<c014a5c1>] enable_cpucache+0x51/0x80
> [<c0148ea5>] kmem_cache_create+0x4a5/0x560

Within kmem_cache_create. kmem_cache_create checks for in_interrupt(), thus someone probably does

	spin_lock_irqsave();
	kmem_cache_create();


> [<c0285dd2>] scsi_setup_command_freelist+0xa2/0x130

calls kmem_cache_create()

> [<c02887e0>] scsi_register+0x3c0/0x660

calls scsi_setup_command_freelist


> [<c02919a1>] get_pci_dev+0x31/0x50

?? probably stale

> [<c0291df2>] port_detect+0x3c2/0xe50

Do you have an eata scsi controller?

Ugs.
eata2x_detect():
* spin_lock_irqsave();
* calls port_detect();
* * spin_unlock();
* * scsi_register.

Eata maintainers: Is that necessary?
Why do the interrupts remain disabled across scsi_register?
Is that a bug workaround, or an oversight?
I'd use

	spin_unlock_irq();
	scsi_register();
	spin_lock_irq();

--
	Manfred

Re: eata irq abuse (was: Re: Linux 2.5.60)

[Zephaniah E. Hull]

[-- Attachment #1: Type: text/plain, Size: 780 bytes --]

On Tue, Feb 11, 2003 at 06:45:35PM +0100, Manfred Spraul wrote:
> >[<c0291df2>] port_detect+0x3c2/0xe50
> 
> Do you have an eata scsi controller?

Yes I do, does exactly what I need most of the time.

The problem goes away if I compile SCSI as modules, however it happens
when I try to load the modules, so..

Anything I can do to help?

Zephaniah E. Hull.

-- 
	1024D/E65A7801 Zephaniah E. Hull <warp@babylon.d2dc.net>
	   92ED 94E4 B1E6 3624 226D  5727 4453 008B E65A 7801
	    CCs of replies from mailing lists are requested.

"This system operates under martial law. The constitution is suspended. You
 have no rights except as declared by the area commander. Violators will be
  shot. Repeat violators will be repeatedly shot...."       -from "A_W_O_L"

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]