why does SMP in 2.1.38 lockup uniprocessor machines?

Jeffrey Wiegley (wiegley@usc.edu)
Sun, 18 May 1997 21:06:24 -0700


This is sort of like 1 trousers vs. 20 trousers I guess...

In a fit of anxiousness I moved from 2.0.30 to 2.1.38. Obtained all the
new
version of the necessary stuff as outlined in Doc.../Changes. I have a
simple
Pentium 166 machine and a simple make mrproper; make config; make dep;
make
clean; make zImage resulted in a kernel which would boot fine, seemed to
run
fine except for one thing.

v2.1.38 seems to lockup solid when running PPP. (Or at least the
combination
of PPP, X-Windows and Netscape 4.0) Also, local network stuff seemed to
be
slow or useless (such as the apache server on my machine wouldn't server
anything)

I moved back to 2.0.30 and then had a brain drizzle this morning. After
commenting out the SMP=1 define in the v2.1.38 makefile (and I also
applied
the 2.1.39 patch) it compiles fine and appears to run without any
problems at
all.

So in summary:

v2.1.38 with SMP defined locks up my uniprocessor machine,
v2.1.39 without SMP appears to run great.

Thats the info, now my question is:

Why does the SMP stuff break a uniprocessor machine? Why can't a
uniprocessor machine be treated like a lame SMP machine where the number
of CPUs is 1?

I would understand some changes in the boot stuff to detect the number
of CPUs available but after you know that why can't the other kernel
stuff be written to be independent of the actual number of CPUs present?

- Jeff