🚀 go-pugleaf

In article <15814@topaz.rutgers.edu> hedrick@topaz.rutgers.edu (Charles Hedrick) writes:
>We have found a fairly serious problem with 3.4.88.

To clarify, this is a release built out of source at Rutgers, based on
Celerity release 3.4.77, which did indeed contain the improper RARP
code.  Do not confuse this with a *Celerity* 3.4.88 or later.  The 
problem code was disabled in binary release 3.4.78 and all later 3.4
versions.  RARP will be implemented fully and properly in a later
release.
-- 
 ///==\\   (Your message here...)
///        Roger B.A. Klorese, CELERITY (Northeast Area)
\\\        40 Speen St., Framingham, MA 01701  +1 617 872-1552
 \\\==//   celtics!roger@necntc.nec.com - necntc!celtics!roger

mea culpa! The code in if_ether.c implementing a RARP capability in the
kernel in Celerity UNIX field release 3.4.77 is not, and was not intended
to be, a general purpose implementation. It was included as a consequence
of some diskless Sun work I have been doing and became part of the release
by accident. It stayed part of the release because it wasn't supposed to
do any harm.  My apologies for the difficulty it caused. Using my highly
developed 20/20 hindsight, I rather wish it hadn't gone out. 

We became aware of the problem within a few days of the first installations
of 3.4.77 and we quickly released 3.4.78 with the "feature" (rhymes with
creature) disabled and distributed the corrected release to the complaining
sites.

It has always been our intention to implement and release a RARP capability
functionally equivalent to Sun's, including /etc/ethers.

An additional issue disclosed by this problem is the potential confusion
in identifying release levels for source-licensed customers. The RARP
problem existed in 3.4.77, was corrected in 3.4.78 and was reported on
the net as being in 3.4.88. We haven't gotten to 3.4.88 yet!
To avoid this confusion, I would suggest that source-license holders
adopt the convention of naming their kernels as:
'local-orgination.celerity-release-level.local-release-level',
e.g., vmunix.rutgers.3.4.77.88. This may be accomplished by setting the
'version' file in the root of the source directory to the string;

			rutgers 3.4.77 88

The last field in the 'version' file is incremented by the script, 'newvers.sh'
each time a build is done, so subsequent builds will have an ascending
revision number. If you want to change the punctuation, take a look at
'newvrs.sh'.



Ron McDaniels

CELERITY COMPUTING . 9692 Via Excelencia Way . San Diego, California . 92126
(619) 271-9940 . {decvax || ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ron
"Yes, my Precious. . . we hates them socket(2)eses!"

I (we) saw the announcement, shich sounds very exciting,
and are now *VERY* interested in finding more information!

1:  Is the 60MFLOPS for the 1kx1k "any method" linpak
    done in 32 or 64 bit presision ????

1.5: If Single, what are the Double rates ???

2:  We *DESPARATELY* want timeings for the LLNL loop set
    (24 prefered)

3:  Does anyone have any timings for any other benchmarks,
    specifially the "normal-LINPAK" and "DoDuc"

4:  Any real numbers for *ANY* benchmarks would be appreciated!
    (Yes, we'll even take drystones.....)


-- 
					John Wardale
... {seismo | harvard | ihnp4} ! {uwvax | cs.wisc.edu} ! astroatc!johnw

To err is human, to really foul up world news requires the net!