[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: errors when compiling 2.6 kernel source

On Wed, 9 Mar 2005, Michael Schmitz wrote:

Looks like it hasn't been touched in ages, then. BenH should correct me
if I'm way off base, but you basically need to replace, at a minimum:

save_flags(flags)+cli()	by 	local_irq_save(flags)
restore_flags(flags)	by	local_irq_restore(flags)
sti()			by	local_irq_enable()

for uniprocessor use (are there any SMP capable machines with SWIM3??).
if that compiles and runs, you can proceed to using proper spinlock
functions (a spinlock has already been added to the driver but isn't
currently used).

This code needs to be SMP safe (see Bug#271517). You'll need proper

That's why I asked about SMP machines with SWIM3.

locking primitives (ie. spin_lock_irqsave(), etc...). The locks will
compile away on UP machines.


Keep in mind that this isn't a simple case of search and replace.
You should understand what data needs mutual exclusion. The stray
sti() looks like a hack.  Enabling interrupts with sti() before
return is bad

The PC floppy driver does things in much the same way, from a quick
glance. Most notably, the spinlock is never used in that driver either.
Same for the swim_iop driver.  I conclude there's not much need for
mutual exclusion here. Yes, I'm aware that the interrupt handling isn't
the same for Intel and PowerPC hardware ...

practice because your function could be returning to a function that
expects interrupts to still be disabled.

The driver should make sure this doesn't happen, naturally. Seems to
have worked at some time in the past.

I'm aware that my suggestions are just a first thing to try. If the
machine freezes, or other bad things happen, look more closely. Don't try this on mission critical hardware :-)

Well, this machine finished up its last "critical mission" (helping me through my thesis ;-) more than a year ago, so it can be "beaten up" to test things like this. My better half is already smiling at me due
to the number of reboots this machine has suffered through in just the
last few weeks testing kernels and installers :)

I'll take a look at the SWIM3 driver, with all your suggestions in mind,
and I'll post back here with the results, good, bad, or desperate pleas
when I get lost in kernel code :-)


Reply to: