Re: CONFIG_SMP patch available for 2.1.54

Ron McCormick (
Wed, 10 Sep 1997 10:30:31 -0500 (CDT)

I would have to second that as well, (that it could be a driver issue) on
the same machine, if I boot the machine with one CPU in it with a SMP
kernel, the system dies a hideous death of multiple oops, followed by a
full system reset. (It was ugly.) After the reboot, back on a non-smp
kernel, the advansys controller that came with my HP4020i CR writer, was
braindead. I needed to boot DOS, resetup the card, then Linux would
recognize it again (Only on non-SMP kernel)

If I put the second CPU in the machine (As it currently is) everything
works great.

Current machine is Tomcat IV MB w/2 P5 200Mhz MMX. 112 MB memory.
AHA-2940, Advansys ???, and 10GB disk.

-Ron McCormick

On Tue, 9 Sep 1997, Alan Cox wrote:

> > Mine does. I have an IBM SLC/486-33. Uniprocessor 2.1.54 works fine,
> > but SMP 2.1.54 gives me an unlimited number of "lock from interrupt
> > context at %p\n" messages. I don't mind because I don't expect 486 SMP
> > to work anyways. (But this did prevent me from testing my CONFIG_SMP
> > patch very well).
> What drivers. There is no reason for the problem you are seeing being a
> CPU specific bug - its most likely a driver flaw. What drivers do you
> use and does 2.0.x SMP work for your box
> > Personally I would like to get rid of about half these tests and just go
> > with the fractionally slower code with no configuration tests. I don't
> > mind having arch/i386/kernel/smp.c linked in or not depending on __SMP__,
> > but I don't like seeing __SMP__ in the middle of low-level include files.
> > Besides the code cleanup benefit, it would eliminate the distinction
> > between SMP and non-SMP modules.
> The difference on intel for non SMP with things like FPU heavy tasks can
> be over 100% gain. Its worth having SMP seperate.
> Alan