Messages in this thread | | | From | "Boerner, Brian" <> | Subject | Modules vs. Resident Kernel | Date | Tue, 11 Jul 2000 13:32:45 -0700 |
| |
Howdy Folks
I'm working on a hw raid driver for some of the Dell and HP raid controllers. I'm running into a problem on the 2.2.16-3 kernel when my driver is built as part of the resident kernel on an SMP system.
The driver panics in a routine that attempts to acquire a spinlock. Basically, the same CPU comes along and tries to acquire the same lock twice, but that's neither here nor there. What I curious about is why I would see the same behavior when the driver is built as a module.
This driver has seen a fair amount of testing (months and months) as a binary RPM before the code was shipped off to RH as a module.
My basic question is, what are the major differences between being part of the resident kernel and being a loadable module?
For people who are interested, I've included the acquire and release spinlock routines. Just to make sure I'm not doing something stupid here that just hasn't been picked up before.
OS_SPINLOCK is defined as: typedef struct OS_SPINLOCK { spinlock_t spin_lock; unsigned cpu_lock_count[NR_CPUS]; long cpu_flag; long lockout_count; } OS_SPINLOCK;
My spinlock acquire routine basically does: void OsSpinLockAcquire( OS_SPINLOCK *SpinLock) { unsigned cpu_id;
if( SpinLock ) { cpu_id = smp_processor_id(); if( SpinLock->cpu_lock_count[ cpu_id ] ){ panic( "CPU %d trying to acquire lock again: lock count = %d\n", cpu_id, SpinLock->cpu_lock_count[ cpu_id ] ); } spin_lock_irqsave( &( SpinLock->spin_lock ), SpinLock->cpu_flag ); SpinLock->cpu_lock_count[ cpu_id ]++; } else cmn_err( CE_WARN, "OsSpinLockAcquire: lock does not exist" );
}
My spinlock release routine basically does: void OsSpinLockRelease( OS_SPINLOCK *SpinLock ) { unsigned cpu_id; if( SpinLock ) { cpu_id = smp_processor_id(); SpinLock->cpu_lock_count[ cpu_id ]--; spin_unlock_irqrestore( &( SpinLock->spin_lock ), SpinLock->cpu_flag ); } else cmn_err( CE_WARN, "OsSpinLockRelease: lock does not exist" ); }
Brian M. Boerner System Software Developer Adaptec, Inc. Nashua, NH 03060 (603) 579-4625
- 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/
| |