Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 27 Jun 1999 21:21:41 +0200 (CEST)
From:      Oliver Fromme <olli@dorifer.heim3.tu-clausthal.de>
To:        freebsd-smp@FreeBSD.ORG
Subject:   Freezes with 3.2-RELEASE (SMP)
Message-ID:  <199906271921.VAA16464@dorifer.heim3.tu-clausthal.de>

next in thread | raw e-mail | index | archive | help
First I'm going to reply to a few of Lars' statements, then I
will describe my own experiences with freezes on an SMP box
running 3.2-RELEASE.  These might or might not be related to
the problems that Lars is encountering.

Lars Koeller wrote:
 > I hope I'm not too fast with my conclusions (normally I am :-), but 
 > the instability seems to result from th missing option
 > 
 > options         FFS_ROOT                #FFS usable as root device [keep this!]

You definitely need that option if your root device is an
FFS/UFS partition.  I think the comment "keep this!" should
be pretty clear.  ;-)

 > After fiddeling with all this details, sometimes I wish myself a 
 > kernel configuration utility, which is able to avoid such problems 

Doing an update properly does avoid such problems, too.

For example, it's always a good idea to keep the old GENERIC
and LINT files, then make a diff between the old and new ones,
and then merge any changes which apply to you into your kernel
config file.  This takes only a few minutes, but it can save
you from hours of debugging strange problems.  Apart from that,
it brings any new features to your attention which might be
useful for you.

 > The next step is to activate the soundcard again .....

I have an AWE32 in a UP system, it works fine with both the
traditional Voxware drivers and Luigi's new PCM driver.  If the
former doesn't work for you, you might try the latter.

 > At the moment I'm just running a SMP kernel again and do a 'make 
 > world' for testing.

"make world" isn't always enough, unfortunately...  See below.

 > options		XSERVER			#include code for XFree86
 > [...]
 > options         "AUTO_EOI_2"

The XSERVER option applies only to the pcvt console driver, not
to syscons, so it's not needed.  However, more importantly, the
AUTO_EOI_2 option broke the system _badly_ when I tried it on
a box some time ago.  Since then I've never touched it again.
(AUTO_EOI_1 seems to work fine, though.)  Maybe I just had bad
luck.  But maybe you should try to remove that option.

Now this is my story:

When I built an SMP box last week (dual Celeron-466), I also
installed 3.2-RELEASE, just because I got the CD set in the
mail on the same day, so it was most convenient.  Everything
went well, even a "make world" (52 minutes, by the way, on a
slow old IBM DCAS drive connected to a Symbios-810 Fast-SCSI
controller -- this was probably the limiting factor).

However, when I installed the netpbm port, the box froze in the
middle of compiling.  No warning or error message, no panic, no
reboot, no ddb prompt.  It was as dead as it could be, no ping
replies, and pressing the NumLock key did not change the LED
anymore.  I rebooted, then did a "make clean" and tried to
compile netpbm again, which worked fine this time.  Then I
tried to compile gimp, and again the box froze after a few
minutes of compiling.

"Shit."  I removed everything from the kernel config file that
I didn't absolutely need (this box does _not_ have any sound
hardware!) and set the most conservative timings in the BIOS
setup.  It didn't make any difference -- it always froze after
some (varying) time of heavy load.  (BTW, interestingly,
compiling gimp seemed to cause the problem easier/earlier than
"make world".)

I rebooted with a UP kernel -- no problem, the system was rock-
solid.  Swapped the CPUs to check the other one -- same thing.
Rebooted with SMP kernel, compiled gimp -- freeze after 10
minutes.

There was not much left to do, and I tended to think that the
mainboard's SMP support was defective.  As a last resort, I
tried to install a recent 4.0-current snapshot (19990622, to be
exact).  Guess what -- the problem was gone.

The box now runs great -- I even overclocked both CPUs to 525
MHz (FSB running at 75 MHz).  I let it making world and compile
ports 24h/day to make sure it is stable.  I believe that the
first thing that's going to fail is the poor disk.  :-)

So my conclusion is that 3.2-RELEASE does not work reliably
with SMP under serious load.  At least, that was the case for
me.  Maybe the problem is also fixed in -stable, but now that
I'm running -current without apparent problems, I have no
reason to downgrade.

Regards
   Oliver

PS:  Using Celerons, it is possible to build dual-processor SMP
machines with serious processing power at a price that is not
much higher than a single-CPU system.  So let's all build SMP
boxes and help the FreeBSD team to improve the SMP efficiency
and kick NT's ass.  :)

-- 
Oliver Fromme, Leibnizstr. 18/61, 38678 Clausthal, Germany
(Info: finger userinfo:olli@dorifer.heim3.tu-clausthal.de)

"In jedem Stück Kohle wartet ein Diamant auf seine Geburt"
                                         (Terry Pratchett)


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-smp" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906271921.VAA16464>