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
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 <[email protected]>
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"
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:[email protected]]
Sent: Tuesday, February 11, 2003 6:46 PM
To: Zephaniah E. Hull
Cc: [email protected]; [email protected];
[email protected]
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
[email protected] 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...
Jeff Garzik wrote:
> [email protected] 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...