On Tue, 13 Apr 1999, Ivan Van Laningham wrote:
> > You don't think 2.0.>>36<< is supportable, although it is so stable it
> > is basically moribund and abandoned, but you think that 2.2.(x \approx
> > 5) (a brand new "stable" release) is, in spite of the fact that your
> > existing 5.2 release runs 2.0.36 flawlessly in nearly all SMP boxes in
> > existence (including the Dells under primary discussion, never forget!)
> > while installing 2.2.x requires upgrading a half dozen key systems
> > components irreversibly, some of which are >>still<< broken for 2.2 in
> > the most recent "experimental" 2.2.x RPM's? Brother, we have very
> > different definitions of the word supportable and stable...
> >
>
> Interesting. I guess I won't using the 2.2.x kernel when I install
> Linux on my UnixWare system at home.
I'm not dissing 2.2.x -- it works very well on most systems also. But
it definitely requires upgrades/changes in a lot of key 5.2 system
components, and in particular still breaks RH 5.2. RH has a set of
2.2.x upgrade RPM's, but my last pass through this set still left me
with a dysfunctional kerneld (and this is my second pass), so I'm still
hand loading my networking modules after a boot. The kerneld, in turn,
is fixed by an rpm set recently contributed by somebody that figured out
the problem. The point isn't that 2.2 SMP (or UP -- my problems thus
far have all been UP) cannot be made to work under RH -- of course it
can, and if you figure out how to do so it is a better kernel by design.
It is just that at this moment it requires considerable expertise to get
2.2 going under 5.2, while 2.0.36 SMP in most cases requires only a
kernel recompile and in most cases will work flawlessly.
Sure, as several RH folks have pointed out -- wait for 5.9 (or the next
release number) -- 2.2.x, SMP autodetection and lots of other things.
Well, we'll see. I think that what they are REALLY saying is that 5.2
and incrementals available via RH is as frozen as 2.0.36 -- unlikely to
significantly change anymore and no way in hell will it support SMP.
> OK. I have a UnixWare box at home: Micronics M54Pe motherboard, dual
> P100s; Adaptec 2940W (not 2940UW, notice), with one 4.3GB and two 1.0GB
> drives attached, plus a CDROM and a zip drive; #9 Motion 330 2mb Video.
> I'm dumping the video card and replacing it with a Diamond Stealth S220,
> 4mb. The reason I joined the SMP list was to see what problems I was
> going to have running SMP on my UW system once I converted it to Linux.
> [N.B.: I *like* UnixWare, but don't like SCO, and don't fancy paying
> $600 bucks to upgrade from UW2.03 to UW7 to maintain the same license
> I've already got. *Plus* the system hangs every 2-5 days & must be
> rebooted, forcefully;-(] Now, I've hacked both BSD & SYSV kernels, and
> done quite a lot of it, too, but that's not where my interests are these
> days. *But* if necessary I'd like to be able to if forced. An option
> button in the install process seems like a *trivial* addition,
> especially since RH installs a bunch of weirdo stuff/daemons I didn't
> want if I checked the `install everything' button. ...
>
> So, if Red Hat came out with a new Deluxe CD set tomorrow, offering
> UP/SMP installation options and optional installation of source--I'd buy
> it in a minute. When I wipe my UW system, it would delight me if I
> could pop a CD in and install a working 2.0.36 SMP kernel. It would
> delight me even more if I could push another button and tell it to
> install the complete SMP kernel source in exactly the configuration
> required to build the kernel I just installed. The install process
> could check, too, to see if there's more than one SCSI controller on the
> system, and warn the user if there's a possible conflict.
>
> So, Red Hat, what's the big deal about providing an extra kernel on the
> CD, and a little button on the installer? You provide the CD set, and
> I'll buy it. Guaranteed repeat sale. What kind of a business risk is
> that?
>
> I bet a lot more people read those manuals than you think, and even read
> and pay attention to warnings like, ``try SMP at your own risk.''
My point(s) exactly. Thank you.
rgb
Robert G. Brown http://www.phy.duke.edu/~rgb/
Duke University Dept. of Physics, Box 90305
Durham, N.C. 27708-0305
Phone: 1-919-660-2567 Fax: 919-660-2525 email:[EMAIL PROTECTED]
-
Linux SMP list: FIRST see FAQ at http://www.irisa.fr/prive/mentre/smp-faq/
To Unsubscribe: send "unsubscribe linux-smp" to [EMAIL PROTECTED]
