From owner-freebsd-smp Sun Jun 27 12:21:58 1999 Delivered-To: freebsd-smp@freebsd.org Received: from dorifer.heim3.tu-clausthal.de (dorifer.heim3.tu-clausthal.de [139.174.243.252]) by hub.freebsd.org (Postfix) with ESMTP id 45CB715091 for ; Sun, 27 Jun 1999 12:21:45 -0700 (PDT) (envelope-from olli@dorifer.heim3.tu-clausthal.de) Received: (from olli@localhost) by dorifer.heim3.tu-clausthal.de (8.8.8/8.8.8) id VAA16464 for freebsd-smp@FreeBSD.ORG; Sun, 27 Jun 1999 21:21:41 +0200 (CEST) (envelope-from olli) Date: Sun, 27 Jun 1999 21:21:41 +0200 (CEST) From: Oliver Fromme Message-Id: <199906271921.VAA16464@dorifer.heim3.tu-clausthal.de> To: freebsd-smp@FreeBSD.ORG Subject: Freezes with 3.2-RELEASE (SMP) Organization: Administration Heim 3 Reply-To: olli@incogni.to MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Newsreader: TIN [version 1.2 RZTUC(3) PL2] Sender: owner-freebsd-smp@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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