RE: SMP system panic with down/up calls for locking. Need help o

WANG,YIDING (yiding_wang@am.exch.hp.com)
Mon, 4 Oct 1999 19:18:58 -0600


Bryan,

Thanks for quick response. It is good suggestion to doawload kernel from
website for development. I will do it in later development.

To answer your question,

1, I don't have down/up in ISR routine. System panic during making file
system.
I have 32 Fibre Channel 32 HD connected on 4 FC HBA. If using driver
without
down/up for locking, no problem ever seen on making file system and IO
running
for a quite while before system panic.
2, The locking rquired in driver is for :
a) Driver local queue, say free ccb list. When on cpu is trying to put
a ccb back to freelist and another is getting a free ccb, it requires
lock.
b) Lower level (firmware level) reentrancy protection.
3, Our customer is using RH6.0 which is 2.2.5-15smp. I have to support it
till
the customer upgrade their Linux.

Many thanks!

-eddie

-----Original Message-----
From: B. James Phillippe [mailto:bryan@terran.org]
Sent: Monday, October 04, 1999 3:29 PM
To: WANG,YIDING (HP-SanJose,ex1)
Cc: 'linux_kernel'
Subject: Re: SMP system panic with down/up calls for locking. Need help
on as sembly compiling.

On Mon, 4 Oct 1999, WANG,YIDING (HP-SanJose,ex1) wrote:

> Under SMP (8 CPUs) system with 2.2.5-15smp kernel, when adding down()/up()
> pair for critical section locking purpose in my fibre channel driver (to
> system, it is scsi), system panic. Acutually even under UP system,

1.) you can't call down() at interrupt time, as it is basically going to
put the caller to sleep/schedule() if the count goes below 0. Sleeping at
interrupt-time is not allowed. You're almost certainly using this at
interrupt-time context, right? I'm not certain exactly what kind of
locking you need, but investigate spinlocks:
linux/Documentation/spinlocks.txt

2.) 2.2.5-15smp is not a kernel version, but a particular packaging of a
particular kernel version by a particular vendor. You should really be
downloading and working with the latest kernels "by-hand" if you're going
to do development. This way you won't be chasing bugs that have already
been fixed, and you won't be relying on faith in someone elses idea of a
valid kernel configuration.

-bp

--
# bryan at terran dot org
# http://www.terran.org/~bryan

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/