From smb@afterlife.ncsc.mil  Fri Jan  3 23:31:34 1992
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Date: Fri Jan  3 23:31:41 PST 1992
Subject: multiple initiators with scsiLib(1)?
The man page for scsiLib (1) states (version 5.0.2):

	It implements only the SCSI initiator function, i.e., the
	concept of a VxWorks target acting as a SCSI target is not
	currently supported.  Furthermore, in the current
	implementation, a VxWorks target is assumed to be the only
	initiator on the SCSI bus, although there may be multiple
	targets (SCSI peripherals) on the bus.

I need multiple initiators on a single SCSI bus to allow using a disk as
a rather large FIFO written by one processor and read by another.
Can anyone (WRS) tell me if there are any plans to extent scsiLib's
functionality to allow for multiple initiators?  How about VxWorks targets
as SCSI targets?

Thanks,
Steve Burinsky
smb@afterlife.ncsc.mil

From visicom!VisiCom.COM!trest@nosc.mil  Sat Jan  4 08:52:35 1992
From: trest@visicom.com (Mike Trest)
Date: Sat Jan  4 08:52:43 PST 1992
Subject: Re:  multiple initiators with scsiLib(1)?
Steve:

>>Can anyone (WRS) tell me if there are any plans to extent scsiLib's
>>functionality to allow for multiple initiators? 

While I do not presume to speak for WRS or Jason, I have used 
the existing WRS scsiLib since before it was a public product.
I have sucessfully used it to perform for several controllers
on the same physical SCSI against a common pool of disks.

One of VisiCom's customers us using it with a MVME326 controller
(a Mil variation of the Interphase Jaguar) with 5 controllers
talking to two disks.

This works because (1) scsiLib is re-entrant enough and (2)
the SCSI bus itself allows this capability.  HOWEVER, you have
to observe some reasonable rules:

	A. A Single Controller should be the only one UPDATING
	   a specific area of the disk as delimited in your
	   scsiDevCreate().  This does not preclude multiple
	   processes from updating files on this controller.
	   It does, however, preclude a process on a different
	   controller updating the same disk area.  In other
	   words, use disk partitioning as well as controller
	   separation.

	B. DO NOT EXPECT THAT MULTIPLE INITIATORS KNOW ABOUT EACH 
	   OTHER UNLESS YOU TELL THEM.  I have one application
	   where multiple VME cages are used against a single
	   disk & tape pool in a mixed RAW and MSDOS modes.  A 
	   small server is used to distribute a global index
	   to the other VME cages and to request global mutual
	   exclusion.  This is a distributed locks methodology
	   without all the overhead of NFS and truly distributed
	   locks.

	C. DO NOT EXPECT scsiLib or SCSI bus to do things which
	   are not supported by the target device.  For example,
	   I have seen attempts to use multiple initiator controllers
	   to issue a second request to the same disk spindle.
	   The programmer wondered why the second request from
	   the other initiator was denied.  Well, the disk's
	   target firmware was single request only.  All subsequent
	   requests are rejected by the device until the in-process
	   command is completed.  Prior to SCSI-2, multiple request
	   devices are expensive DISK SUBSYSTEMS, RAIDs, or SCSI SERVER
	   products with very intelligent controllers.   ALAS, SCIS-2 
	   and TAG QUEUE operating devices will extend this to
	   more devices in the near future.
	   devices are not far away.  

VisiCom is working on an OEM scsi controller driver for VxWorks which
is SCSI-2 and supports full TAG QUEUE operation and multiple request
driven.  The multiple commands are fed immediately to the controller
which is responsible for controlling all requests from all processes.
Multiple controllers are supported on the same SCSI bus.  The above rules 
and comments still apply.

>> How about VxWorks targets as SCSI targets?

I am already doing this to.  However, it depends on the firmware
and SCSI chip used on the controller itself.  I do not know of 
any plans to put this kind of stuff in scsiLib.  It is obviously
software that we need and use when VxWorks is embedded into products.
Perhaps VisiCom will consider a "ADVANCED SCSI CAPABILITIES" library
for the general VX market like the X server and Motif product.

>>I need multiple initiators on a single SCSI bus to allow using a disk as
>>a rather large FIFO written by one processor and read by another.

The answer to your problem is twofold.  First is appropriate data 
structuring on the SCSI disk.  Second is adequate communication
between the producer task and the consumer task.  I will assume that
you also want this FIFO to sustain the highest possible speed.  I
will also assume that you are willing to control the inherent
latency involved because you cannot write to the disk by the
producer while a read is in process by the consumer.  And, that
you are using a dumb controller which cannot queue requests for
either producer or consumer.

Therefore, let your producer task use RAW disk organization with
a single link list data structure imbedded in you data.  Include
in that data structure a unique block/serial number.  Let your
consumer task read the link list data.  Share the current
producer and consmer block numbers between the two processors via
shared memory (or communications).  Treat all of the disk as
if it were a large ring buffer with a traditional HEAD/TAIL
algorithm.

Depending on your data rates, and the relative processing overhead
of the the consumer task, you seek activity should be minimal
since the TAIL should be following the HEAD quite closely.  Even
if the two processors only loosly coupled and network communications
must be used, the exchange of HEAD and TAIL pointers can be done
if the SCSI driver is well written and does not spin-loop internally
while the disk transfer is in process. 

UNFORTUNATELY not all drivers are well written and do not lend
themselves to overlapped operation.  For example using a relatively
dumb SCSI chip and then not using DMA happen more times than you
want to know about.  Driver for stand-alone VME SCSI controllers
are generally tuned to take advantage of the co-processor overlap
and yeild much higher performance.  If, however, your producer
and consumer processes are on different processor boards with their
own private SCSI chip, they should still be up to the job.

Sorry about taking so much of the net traffic time, but I thought
you needed to hear some of these things.  I hope that I have
given you some hope rather than despair.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

From hmp@frc2.frc.ri.cmu.edu  Sat Jan  4 13:34:16 1992
From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
Date: Sat Jan  4 13:34:25 PST 1992
Subject: RESULT: comp.os.vxworks passes 295:17

The voting period for comp.os.vxworks is now officially over, resulting
in 295 votes in favor vs. 17 votes opposed to creation of
comp.os.vxworks. 

Since these results meet the criteria for group creation, 
and barring any serious objections or errors in the vote-taking on my
part, comp.os.vxworks should be created after the customary 5 day
waiting period (beginning with the appearance of this message in
news.announce.newgroups). 

Thanks to everyone who voted.

-Henning Pangels

##############################################################################
Votes OPPOSED to creation of comp.os.vxworks were received from:

Purnam (P.A.)Sheth <PASHETH@BNR.CA>
Walt Froloff <froloff@pioneer.arc.nasa.gov>
Harald Nordgard-Hansen <hhansen@kjemi.unit.no>
Richard Kulawiec <rsk@gynko.circ.upenn.edu>
Memphis_TN <memphis-tn@uiuc.edu>
"Richard H. Miller" <rick@crick.ssctr.bcm.tmc.edu>
Paul Eggert <eggert@bi.twinsun.com>
Quincey Koziol <koziol@ncsa.uiuc.edu>
Jeff Beadles <jeff@onion.rain.com>
"Prashant V. Waknis" <waknispv@vuse.vanderbilt.edu>
Steve Rogers <srogers@tad.eds.com>
John G Dobnick <jgd@csd4.csd.uwm.edu>
"Gregory G. Woodbury" <wolves!ggw@duke.cs.duke.edu>
Tom Fitzgerald <fitz@wang.com>
Hans Olov Eriksson <hanse@enea.se>
"Kenton A. Hoover" <shibumi@turbo.bio.net>
"Leonard J. Reder" <reder@arete>

##############################################################################
Votes IN FAVOR of creation of comp.os.vxworks were received from:

James Woodyatt <bard@cutter.ssd.loral.com>
Alan K Biocca <biocca@bevsun.bev.lbl.gov>
Andrew (A.J.)McGregor <MCGREGR@BNR.CA>
heyes@dadev.cebaf.gov
Andy Kozubal <kozubal@luke.ATdiv.Lanl.GOV>
Jeff Hill <hill@luke.ATdiv.Lanl.GOV>
Jim Nusbaum <rjn@snowbird.labs.tek.com>
George Osmolski <osmolski@ireq-robot.hydro.qc.ca>
Pam Otsuka (Pam Woods) <pam@sr.hp.com>
Tracy Erkkila <erkkila@delorean.meediv.lanl.gov>
"Terry A. Jones" <jones@cs.Buffalo.EDU>
Ken Seymour <seymour@ast.saic.com>
Gerry Roston <gerry>
Steven king (503)627-2736 DS 50-662 <sjk@crl.labs.tek.com>
"Paul R. Bade" <prb@aplexus.jhuapl.edu>
Bill Randle <billr@saab.cna.tek.com>
Jim Newman <neji@mbari.org>
Phil Kester <philk@verdix.com>
Bob Lawhead <rml@mpl.UCSD.EDU>
Todd Brackett <interf!atlas!argus!brackett@uunet.UU.NET>
glb@s1.gov
Marc Ullman <marc@sun-valley.Stanford.EDU>
Bret Goodrich <goodrich@noao.edu>
Chris Nickles <jcn@mpl.UCSD.EDU>
Dan Merget <danm@hpnmdlc0.sr.hp.com>
projoe@zip.eecs.umich.edu
rmk@iss-ipc3.ssd.ray.com
Marcus Gates <marc@aplpy.jhuapl.edu>
"George M. Howard" <howard@marlin.nosc.mil>
Kevin Damour <damour@ral.rpi.edu>
Mike Trest <trest@VisiCom.COM>
Bob Kibrick <kibrick%helios.UCSC.EDU@ucscc.ucsc.edu>
Richard Neitzel <thor@thor.atd.ucar.EDU>
steveu@tv.tv.tek.com
Olivier Bernard <bernard@aar.alcatel-alsthom.fr>
Stan Schneider <stan@rti.com>
fjr@iss-ipc1.ssd.ray.com
"J. Russell Noseworthy" <jrnosewo@ral.RPI.EDU>
Brian Quigley <bmq@jet.ESL.COM>
Gordon Miller <gordon@tpocc.gsfc.nasa.gov>
"Lance A. Page" <page@ral.RPI.EDU>
Kim Gillies X246 <gillies@noao.edu>
Dave Gawley <dgawley@chasles.UVic.CA>
Chris Maio <chris@boxhill.com>
Rob -Not from Bloom County- Binkley <binkley@skipper.dfrf.nasa.gov>
June Liesch <bilbo.heurikon.com!junel%heurikon.UUCP@cs.wisc.edu>
Cynthia Ward - CRL Support Line <ellis@crl.labs.tek.com>
------------ <waldref@hum.tv.tek.com>
Peter Chu <peterc@tv.tv.tek.com>
crispen <@ada3.ca.boeing.com:crispen@amber.boeing.com>
"Dave St.Clair" <dave@exlog.com>
Don Berlin <berlin@erim.org>
pierre@Helios.McRCIM.McGill.EDU
David Lim <lim@telerobotics.jpl.nasa.gov>
Cory Fasbender <ast0!caf@UB.com>
chrise@hpsrcje.sr.hp.com
Jim Horstkotte <jhorstko@ccc.CX.NRAO.EDU>
Jim Jones <jimj@hpnmdlc0.sr.hp.com>
Lou Salz <lous@hpnmdlc0.sr.hp.com>
moritz@hpsrjam.sr.hp.com
pardo@sun-valley.stanford.edu
Dennis Morse <dmorse@sun-valley.Stanford.EDU>
houchin@wind.wv.tek.com
Tom Wilson <twilson@friar.gandalf.ca>
MICHAEL RICHARDS <mar@swlrap.msd.ray.com>
Mark Baranowski <markb@slc.unisys.com>
Jon Hull <hull@cs.Buffalo.EDU>
Cheryl Troester <bilbo.heurikon.com!cherylt%heurikon.UUCP@cs.wisc.edu>
Hwa-Jin Bae <hwajin@omni.com>
abekas!mikep
Dave Norris <dnorris@ichips.intel.com>
"Steve M. Burinsky" <smb@afterlife.ncsc.mil>
6585 <bh@crnsu1>
Sandra Harimoto <sandra@nanko.digital.co.jp>
skoft@itk.unit.no
ojr@itk.unit.no
Eric Knox <knox@aplexus.jhuapl.edu>
Steve Harpster <sharpster@hns.com>
John Baldwin <johnb@searchtech.com>
Georg Feil <georg@sgl.ists.ca>
Kevin Rumbaugh <ceco!kevinr@uunet.UU.NET>
bob geer <bgeer@beorn.sim.es.com>
Ross McAree <ross@ecr.mu.oz.au>
"Trygg A. Eliassen" <trygg@nordic-offshore.no>
Paul Palumbo <palumbo@cs.Buffalo.EDU>
Steve Lewis <lewis@bevsun.bev.lbl.gov>
Edwin Wilder <ewilder@hns.com>
Lonnie Cole <cole@noao.edu>
Darrell Call <dc@navstar.lanl.gov>
Bill Brown <wbrown@bevsun.bev.lbl.gov>
maf@verdix.com
Clark Briggs <briggs@thalia.Jpl.Nasa.Gov>
Robert Belshe <rab@srv1.gam.lbl.gov>
Loren Shalz <shalz@bevsun.bev.lbl.gov>
Dan Warburton <faatcrl!warb@gvlv2.gvl.unisys.com>
D'Anne Thompson <dat@noao.edu>
Steve Morris <srm@matrx.matrix.com>
vanandel@rsf.atd.ucar.EDU
Steven S Smith <steve@cfht.hawaii.edu>
Fei-Yue Wang <feiyue@sie.arizona.edu>
Rick Voreck <voreck@pordvl.ssd.loral.com>
Jim Beyer <beyer@erim.org>
jose@ncar.ucar.edu
Rob Marchand <array!rob@uunet.UU.NET>
Don Wells <dwells@fits.CX.NRAO.EDU>
Paul Gittings <paulg@tplrd.tpl.oz.au>
rcm@iss-ipc2.ssd.ray.com
aspect!mike@uunet.uu.net
aspect!kevinc@uunet.uu.net
bean@pslnm.NMSU.Edu
Bill Cruise <cruise@cfht.hawaii.edu>
rjk@mlb.dmt.csiro.au
James Moore <james%seine@wrsec.wrsec.fr>
Graulle Christophe <kiki@FERRARI.matra-espace.fr>
"Girard R. Ramsay" <grr@iscnvx.lmsc.lockheed.com>
jvdwerf@mmra1.ms.philips.nl
sb@itk.unit.no
Mike Anderson <mea@sparta.com>
Geoff Espin <geoff@wrs.com>
Glenn Tarbox <tarbox@cat.rpi.edu>
deena-strauss@orl.mmc.com
digiac <digiac@callisto.imag.fr>
Ebbe Petersen <ebbep@tplrd.tpl.oz.au>
Dragisha Miladinovic <dragisha@tplrd.tpl.oz.au>
Pierre Mathieu <mathieu@sun470.geod.emr.ca>
Gary Trimble <trimble@laic.rdd.lmsc.lockheed.com>
Chris Frank <chris@landru.pac.sc.ti.com>
Ed Vielmetti <emv@ox.com>
David Berg <berg@fndaup.fnal.gov>
murphy (Bill Murphy) <murphy@smc>
Gabor Karsai <gabork@vuse.vanderbilt.edu>
John Cromer <cro@Deimos.Caltech.Edu>
Louis Gray <hlg@matrx.matrix.com>
Al Maillet <maillet@wrs.com>
Hugh Fader <hugh@slee01.srl.ford.com>
AnnMichele Lobello <alj@sunsrvr1.cci.com>
"Jonathan M. Cameron" <jmc@robotics.jpl.nasa.gov>
Jerry Fiddler <jerry@wrs.com>
tran@sun-valley.stanford.edu
Bob Marino <ram@mr.picker.com>
Bruce Nelson <nelson@ll.mit.edu>
Russell Sheehan <rgs@mr.picker.com>
Thomas Ljubi <tml@eng9.mr.picker.com>
Vic Potter <vlp@eng1.mr.picker.com>
Marty Marra <marra@jargon.whoi.edu>
Todd Litwin <litwin@robotics.jpl.nasa.gov>
Roger Gonzalez <rg@msel.unh.edu>
Richard Saunders <richard@wrsec.wrsec.fr>
Susanna Jacobson <susanna@tomato.lbl.gov>
Scott Huddleston <scott@ferrari.labs.tek.com>
billh@assip.csasyd.oz.AU
Al Conrad <aconrad@keck.hawaii.edu>
kevin d bonifield <kevnb@world.std.com>
"William Lupton: WLupton@Keck.Hawaii.Edu" <WILLIAM@keck.hawaii.edu>
Bob Cohen <bob@wrs.com>
Alan Stanier <alan@essex.ac.uk>
favre eric <favre@medsun.unige.ch>
Matthieu Herrb <matthieu@vega.laas.fr>
Mike Heley <mike@ste.dyn.bae.co.uk>
Tom Wetherbee <tmw@mr.picker.com>
Gary Haas (IBD) <haas@BRL.MIL>
Edward Hinton <gca!hinton@uunet.UU.NET>
Chris Beasley <cb1p+@andrew.cmu.edu>
tmelen@itk.unit.no
Carl Lionberger <carl@rtsg.ee.lbl.gov (Carl Lionberger)>
Dean Tucker <tucker%helios.UCSC.EDU@ucscc.ucsc.edu>
Wayne D Michael <wdm@world.std.com>
NOELL T E <tna@stc06.ctd.ornl.gov>
"J. Porter Clark" <jpc@avdms8.msfc.nasa.gov>
roos@imasun.lbl.gov (Mark S. Roos)
Emmanuel Fleishman <ntmtv!fleishma@ames.arc.nasa.gov>
"Taso N. Devetzis" <devetzis@thumper.bellcore.com>
Mitch Hendrickson <mitchh@hops.gvg.tek.com>
"hlewis@keck.hawaii.edu" <HILTON@keck.hawaii.edu>
"Thomas J. Trebisky" <tom@as.arizona.edu>
Jeff Fitzgerald <jjf@fibercom.com>
barry n nelson <barryn@world.std.com>
Brian Carlton <bdc@bdcsys.suvl.ca.us>
christ@mordor.wr.tek.com
"Kenneth Holmstr\\Nm" <@mail.swip.net:hkh@abbaut>
Mark Linimon <linimon@nominil.lonestar.org>
MHAMILTON@cooper.bbn.com
"Larry E. Peruski" <PERUSKI%RCSMPB@gmr.com>
Bob Herlien <hebo@mbari.org>
ramap@wow.tv.tek.com (Rama Pailoor)
Andrew Pearce <pean@mbari.org>
rgonzale@ccc.CX.NRAO.EDU (Ray Gonzalez)
Patrick Boylan <pat@wrs.com>
mike-i green <mighty@styx.lbl.gov>
pfeffer@sun-valley.stanford.edu
Rahul Shah <rhs@fibercom.com>
Dick Smith <smithr@ast.dsd.northrop.com>
djc@oxygen.aps1.anl.gov (Daniel J. Ciarlette)
dbocek@doc.jhuapl.edu (Dawn B. Schepleng)
aspect!richard@uunet.UU.NET
ronb@duke.labs.tek.com
Scott Herzinger <scotth@rocco.labs.tek.com>
simon@wrs.com (Simon Leong)
Mike Oliver <moliver@shadow.eng.pyramid.com>
crs@gmrt.ernet.in (CR Subrahmanya)
"John Archbold (dubdoob" <jarch@dubdoob.ssd.loral.com>
Stuart Stirling <silver@mathcs.emory.edu>
Peter Corke <pic@mlb.dmt.csiro.au>
bobf@verdix.com
Ted Rypma <rypma@waterloo.hp.com>
miked@wrs.com (Mike Deliman)
mrk@phebos.aps.anl.gov (Marty Kraimer)
frl@phebos.aps.anl.gov (Frank Lenkszus)
wpm@phebos.aps.anl.gov (Bill McDowell)
Charlie Singer <etnibsd!charlie@uunet.UU.NET>
George Plourde <etnibsd!george@uunet.UU.NET>
Rick Rousseau <etnibsd!rick@uunet.UU.NET>
Neil Demario <etnibsd!neil@uunet.UU.NET>
Norbert Hofmann <etnibsd!norbert@uunet.UU.NET>
Doug Balek <etnibsd!djb@uunet.UU.NET>
Patrice Kadionik <KADIONIK@FRCPN11.IN2P3.FR>
Dominique Leveque <leveque@aar.alcatel-alsthom.fr>
chochon@aar.alcatel-alsthom.fr ( Helene Chochon )
Mike Swears <etnibsd!mike@uunet.UU.NET>
Peter Trenning <trenning@fwi.uva.nl>
Al Pariante <etnibsd!albert@uunet.UU.NET>
Charles Harrington <etnibsd!charles@uunet.UU.NET>
winans@phebos.aps.anl.gov (John R. Winans)
John Curry <curry@tc.fluke.COM>
Monica Skidmore <monica@searchtech.com>
Kenneth Holmstr\Nm <@mail.swip.net:hkh@abbaut>
usenet user <@mail.swip.net:usenet@abbaut>
Christer Hansson <@mail.swip.net:cha@abbaut>
Mats Molander <@mail.swip.net:mm@abbaut>
gunther@luke.ATdiv.Lanl.GOV (Betty Gunther)
mcevoy@srv1.bcs.lbl.gov (Maurice McEvoy)
gdfwc3!kuwait!tod@texsun.Central.Sun.COM (Tod Chapman)
Kim DeVaughn <ked01@juts.ccc.amdahl.com>
Eric Stromberg <sybase!icer@Sun.COM>
scr@UK.ATE.SLB.COM
Neil McKay <mckay@ndm.cs.gmr.com>
vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
andy@sealink1.oe.fau.edu (Mr.Andrew_Shein)
David Bruce <deb@cassir.UCSD.EDU>
Michael Bordua <bordua@bevsun.bev.lbl.gov>
Tom Pendleton - Sun South Bay Region SE <tpendleton@sunwest2.West.Sun.COM>
Hesham (H.)El Bakoury <HESHAM@BNR.CA>
Minoru Nakamura <mnr@tkl.iis.u-tokyo.ac.jp>
"David N. Wilner" <dave@wrs.com>
Leonid Rosenboim <leonid@amil.co.il>
vxWorks@digitailor.se
Po Shan Cheah <pc30@cunixb.cc.columbia.edu>
Randall Atkinson <atkinson@itd.nrl.navy.mil>
Kragh Hertel <kragh@wybbs.mi.org>
"Craig A. Franklin" <caf@sparta.com>
Steven Smith <gca!smith@uunet.UU.NET>
Jayne Johnson <jjohnson@hns.com>
"Harold N. Rosenstock" <hal@synnet.com>
Maarten (M.A.)Koning <SMEG@BNR.CA>
Jose Alvistur <jose@rsf.atd.ucar.EDU>
William Dere <will@wrs.com>
Randy Motyka <motyka@erim.org>
"VADSWorks/VxWorks 2.0.1c-5.0.1" <vxworks@csd.nad.northrop.com>
Elias Pavlakos <pavlakos@mosaic.NYU.EDU>
Hali Lindbloom <hali@interactive.com>
bebek@Csa2.LBL.Gov
Jo Schambach <jschamba@na35.lbl.gov>
ntmtv!daemon@ames.arc.nasa.gov
Bud Hensley <budh@budlite.gvg.tek.com>
David Blackman <blackman@hodgkin.med.upenn.edu>
"Alex L. Bangs" <abg@mars.EPM.ORNL.GOV>
klaus@sol.ced.utah.edu
Rick Sustek <ricks@wrs.com>
djanssen@mmra1.ms.philips.nl
hunt@s6550b.nrl.navy.mil
Nigel Standing <nigel@wrs.com>
Kent Long <kent@wrs.com>
Jeffrey Lee <jeffrey@piemast.portal.com>
Lee S Wilfinger <lswilfin@ral.rpi.edu>
George den Boer <boer@fwi.uva.nl>
Sypko Andreae <sypko@rtsg.ee.lbl.gov (Sypko Andreae)>
Rhonda Gaines <rrg@fibercom.com>
Travis Craig <travis@cs.washington.edu>
VxWorks Realtime System <vx@johanna4.hsr.no>
Chuck Broadwell <cbroadwe@ccc.CX.NRAO.EDU>
Shobha Erramilli <shobha@athens.cc.bellcore.com>
"Brian G. Harper" <BHARPER@RALVM11.VNET.IBM.COM>
Ray Lampman <moose.heurikon.com!lampman%heurikon.UUCP@cs.wisc.edu>
KYWONG@SJEVM5.VNET.IBM.COM
Chuck Cox <chuck@bose.com>
kddlab!advanced-software.co.jp!yoriyuki@uunet.UU.NET
Mike Ryan <mryan@ral.rpi.edu>
Webster Dove <dove@rocket.sanders.com>
Steven Lynch <sl@iconix.oz.au>
Carl Symborski <carl@umd5.umd.edu>
Ken Saruwatari <ken@cos.cos.info.kobelco.co.jp>
Sigeo Hasegawa (ONTAKE) <has@cos.cos.info.kobelco.co.jp>
"Ben T. Eguchi" <wrskk!wrssun!ben@uunet.UU.NET>
Tim Page <jtwp@spearmint.SINet.SLB.COM>
Joe Orichella <jfo@vqdd11.mr.picker.com>

##############################################################################
Henning Pangels    |hmp@frc2.frc.ri.cmu.edu        |     Field Robotics Center
Research Programmer|(412) 268-7088                 |Carnegie-Mellon University
------------------------------------------------------------------------------
		      It's later than you think

From whorner@vlsi9.gsfc.nasa.gov  Mon Jan  6 10:27:54 1992
From: whorner@vlsi9.gsfc.nasa.gov (Ward Horner)
Date: Mon Jan  6 10:28:02 PST 1992
Subject: subscription request

Please place me on the Exploder mailing list.
My address is: whorner@vlsi9.gsfc.nasa.gov
My name is: Ward Horner, NASA/GSFC, Code 521.1, Greenbelt, MD 20771
My phone is: (301) 286-5804

Thank you

From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Mon Jan  6 21:20:01 1992
From: fjr@iss-ipc1.ssd.ray.com
Date: Mon Jan  6 21:20:12 PST 1992
Subject: Re:  multiple initiators with scsiLib(1)?
 Mike Trest writes:
 
>  This works because (1) scsiLib is re-entrant enough and (2)
>  the SCSI bus itself allows this capability.  HOWEVER, you have
>  to observe some reasonable rules:
>  
>  	A. A Single Controller should be the only one UPDATING
>  	   a specific area of the disk as delimited in your
>  	   scsiDevCreate().  This does not preclude multiple
>  	   processes from updating files on this controller.
>  	   It does, however, preclude a process on a different
>  	   controller updating the same disk area.  In other
>  	   words, use disk partitioning as well as controller
>  	   separation.
 
>  	C. DO NOT EXPECT scsiLib or SCSI bus to do things which
>  	   are not supported by the target device.  For example,
>  	   I have seen attempts to use multiple initiator controllers
>  	   to issue a second request to the same disk spindle.
>  	   The programmer wondered why the second request from
>  	   the other initiator was denied.  Well, the disk's
>  	   target firmware was single request only.  All subsequent
>  	   requests are rejected by the device until the in-process
>  	   command is completed.  Prior to SCSI-2, multiple request
>  	   devices are expensive DISK SUBSYSTEMS, RAIDs, or SCSI SERVER

We are looking to also use multiple hosts on the same SCSI bus.  We want
to have one processor on one bus reading and writing a SCSI disk while
another processor on another bus just reads the same disk.  We thought
that by using the Auto Sync option of the disk driver that gets the MSDOS
FAT table output after every transaction that things would work.  We have
not, however, taken any precautions for scheduling usage of the disk.  Mike,
do I understand that you implement some queueing on the host side of the
SCSI interfaces to order the attempts to communicate with a shared disk?
If you just let multiple controller cards attempt to work with the same
disk might the controllers handle the contention?
  
>  Sorry about taking so much of the net traffic time, but I thought
>  you needed to hear some of these things.  I hope that I have
>  given you some hope rather than despair.

It was useful seeing the discussion.  Thanks.    Fred

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

From visicom!VisiCom.COM!trest@nosc.mil  Tue Jan  7 09:37:24 1992
From: Mike Trest <trest@visicom.com>
Date: Tue Jan  7 09:37:31 PST 1992
Subject: Re:  multiple initiators with scsiLib(1)?
Fred:

>>... by using the Auto Sync option of the disk driver that gets the MSDOS
>>FAT table output after every transaction that things would work.  We have
>>not, however, taken any precautions for scheduling usage of the disk.

This approach assumes that the FAT writing operation is atomic.  This
cannot be guaranteed. However, FATs are only part of the problem.
What about directory entries? What of reading a file on processor B
until what appears to be EOF while processor A is in the act of extending
the file with new data? 

>>do I understand that you implement some queueing on the host side of the
>>SCSI interfaces to order the attempts to communicate with a shared disk?

Yes, for controllers which have multiple queues, a queue per spindle, or
significant linked command capabilities.  However, the queue is not 
"... to order ..." but to maximize I/O and processing overlap.

>>If you just let multiple controller cards attempt to work with the same
>>disk might the controllers handle the contention?

The controllers and SCSI selection/arbitration do indeed handle the
physical contention.  My original suggestion regarding the FIFO
application was to provide a coherent handler for a single producer
on one processor and a single consumer on another processor which
minimized software overhead and maximized throughput.

I appreciate the use of the exploder as an open forum of discussion.
We need occasional review and outside suggestions.  Otherwise we shall
suffer the malady of aging programmers: "Hardening of the categories"

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

From mea@sparta.com  Tue Jan  7 10:58:59 1992
From: mea@sparta.com (Mike Anderson)
Date: Tue Jan  7 10:59:06 PST 1992
Subject: MSDOS file systems > 32MB?
Greetings!

  Has anyone heard of or developed a way to support MSDOS filesystems
under VxWorks > 32MB in size?  I have a 1GB Wren VII that I would like to 
support under the MSDOS filesystem and it appears that for now, I have to
set up a 32MB MSDOS partition and then access the rest in Raw mode or
as a handfull of other 32MB partitions (yuk!).  Any pointers would be
appreciated.  BTW, I have looked at the RT11 and it doesn't fit my 
requirements either.

Thanks,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From kent@wrs.com  Tue Jan  7 15:16:49 1992
From: kent@wrs.com (Kent Long)
Date: Tue Jan  7 15:17:07 PST 1992
Subject: dosFs: big disks & config tips
Hi, Folks -

Mike Anderson (mea@sparta.com) writes:
 > 
 >   Has anyone heard of or developed a way to support MSDOS filesystems
 > under VxWorks > 32MB in size?  I have a 1GB Wren VII that I would like to 
 > support under the MSDOS filesystem and it appears that for now, I have to
 > set up a 32MB MSDOS partition and then access the rest in Raw mode or
 > as a handfull of other 32MB partitions (yuk!).

Fortunately, this is not the case!

There is no special work which must be done to use large disks with 
the standard VxWorks dosFs file system.  The dosFs library supports 
the disk format changes introduced in MS-DOS 4.0 which include a 32-bit 
sector count.  (Earlier versions of DOS only had a 16-bit sector count, 
giving the infamous 32M limit, assuming 512-byte sectors.)  So, it can
handle up to 4 billion sectors, which is pretty darned big.

What may be confusing things is that there is an independent limit, based 
on the size of FAT table entries.  Since each FAT entry is only 16 bits, 
there can only be 64K clusters defined on a disk.  (A cluster is the unit 
of allocation on a DOS disk, consisting of one or more sectors; each FAT 
entry describes one cluster.)

So, what happens with a large disk such as Mike describes is that
the sectors per cluster goes up.  This means that there is less
granularity when allocating portions of the disk, but it does not
impose an overall size limit.

By the way, the dosFsMkfs() call will initialize a disk using
default values, including calculating the appropriate number of
sectors per cluster.  The values which are generated can then be
used as a starting point for more application-specific config
values.  There should be no problem using dosFsMkfs() on a large
disk.

There are two calls in dosFsLib which were not originally documented
(but will be made official in a future release) which may be helpful.
These are "dosFsConfigShow()" and "dosFsConfigGet()".  These calls provide
configuration data about an intiialized dosFs disk.  

The dosFsConfigShow() routine will display the config info on standard 
output.  It's single input parameter is the name of the device, e.g.:

	status = dosFsConfigShow ("DISK1:");

The dosFsConfigGet() routine is similar, but returns the configuration
data in a manner suitable for use in a C program.  It takes two parameters,
a pointer to the volume descriptor (DOS_VOL_DESC) of the disk, and a
pointer to a DOS_VOL_CONFIG structure to be filled with the current
config data:

	DOS_VOL_DESC	*pVolDesc;
	DOS_VOL_CONFIG	*pConfig;

	status = dosFsConfigGet (pVolDesc, pConfig);

The DOS_VOL_CONFIG structure pointed to by pConfig must have already been 
allocated!  It is only filled in by dosFsConfigGet().

Anyway, how all this relates back to the issue of initializing a big disk 
(or any dosFs disk, for that matter) is that you can first get the volume 
initialized using dosFsMkfs() with the default values it calculates.
Then, use either dosFsConfigShow() or dosFsConfigGet() to find out what
values were actually used.  These configuration values can then be used
as a basis for more application-specific values, which should be provided
using the regular dosFsDevInit() method of initialization.

 > BTW, I have looked at the RT11 and it doesn't fit my 
 > requirements either.

That's right.  The RT-11 format again imposes a 16-bit sector count,
thereby limiting disks to 32Meg.  Given the other RT-11 restrictions
(inability to append to a file, even more restrictive file names, etc.),
there is no situation in which I can really recommend using rt11Fs
over dosFs.

I hope this sheds some light on all of this....

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com

From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Wed Jan  8 22:24:07 1992
From: fjr@iss-ipc1.ssd.ray.com
Date: Wed Jan  8 22:24:15 PST 1992
Subject: Re:  dosFs: big disks & config tips
Kent Long (kent@wrs.com) writes:

>  What may be confusing things is that there is an independent limit, based 
>  on the size of FAT table entries.  Since each FAT entry is only 16 bits, 
>  there can only be 64K clusters defined on a disk.  (A cluster is the unit 
>  of allocation on a DOS disk, consisting of one or more sectors; each FAT 
>  entry describes one cluster.)
>  
>  So, what happens with a large disk such as Mike describes is that
>  the sectors per cluster goes up.  This means that there is less
>  granularity when allocating portions of the disk, but it does not
>  impose an overall size limit.

While large disks can be handled under MSDOS, the granularity issue seems
quite important.  My understanding is that a cluster is the smallest unit
that can be accessed on an MSDOS disk.  With large cluster sizes, disk
fragmentation goes up and effective disk usage goes down.  Typically,
the amount of wasted space in a disk partition will be:
  total files * .5 * cluster size
This isn't necessarily a problem, it just has to be considered.  If you
are going to have lots of little files you probably don't want to put them
into a partition that is set up with a large cluster size; use large
partitions for large files and little partitions for little files.
  The question I have is whether clusters are always read and written
using a single disk request?  I would want the driver to do a single
disk operation to access all the sectors in the cluster.  Also, do drivers
optimize beyond that?  Do they read/write multiple contiguous clusters
when possible?  This would improve disk IO rates if it was supported.
  Thanks for any information.

    ______________________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division          |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr             |
   |______________________________________________________________|

From visicom!VisiCom.COM!trest@nosc.mil  Thu Jan  9 09:22:55 1992
From: Mike Trest <trest@visicom.com>
Date: Thu Jan  9 09:23:02 PST 1992
Subject: Re:  dosFs: big disks & config tips
Fred:
>>  The question I have is whether clusters are always read and written
>>using a single disk request?  I would want the driver to do a single
>>disk operation to access all the sectors in the cluster.  Also, do drivers
>>optimize beyond that?  Do they read/write multiple contiguous clusters
>>when possible?

Based on my observation of MSDOS to the driver,  I cannot confirm that
clusters do not ALWAYS read/write as a whole.  Perhaps WRS will
comment definitively.  However, my observation in a >100MB MSDOS
partition booting VxWorks, the FS requests enough SCSI blocks to
equal the cluster size (ALMOST ALWAYS).  The scsiLib() itself
imposes no real limit on the number of blocks to read/write.
The drivers will usually pass the number of blocks right on to the
controller.  HOWEVER not all controllers and targets support multiblock 
operation.  These FS/scsiLib() requests and must be broken into individual
read/writes to the limit of the controller/target.  Sometimes, the
culprit is a DMA controller which can move only 64K bytes at a time
or which cannot cross some magical 1MB or 16MB memory address boundary.

Driver optimize?  What a good idea! Unfortunately, the requests to the 
driver by the FS are serialized as they pass thru the present scsiLib().
Since Disonnect/Reconnect is not supported in scsiLib() and each
SCSI TRANSACTION is expected to be atomic by scsiLib(), the driver
writer has no other choice when using the convience of scsiLib().

In defense of scsiLib() and Jason, its overhead and the restrictions
imposed are trivial in most real world cases.  Multiple simultaneous
request from many processes PASSING THRU THE SAME scsiLib() on a
single processor are properly protected for multi-thread operation.
One technique which I advise in a multi-processor and single
SCSI controller environment, is to have one processor do all the
Read/Write DISK processing but to point the buffers to address
spaces on the requesting processor card.  This may sound a little
slow but the IPC overhead between the processors is orders of
magnitude less than the drive seek time and your requesting application
must compensate for this anyway.

If your SCSI controller is up to the performance you demand of it
and your target devices are capable of delivering the goods, then
you will see VERY GOOD PERFORMANCE with scsiLib() and the DOS file
system if you use contiguous allocation when a file is created.

Without resorting to crass salesmanship, I strongly suggest that
when your application truly needs operation with multiple requesting 
initiators you really need a powerful stand-alone SCSI controller
rather than the "on the board" SCSI chip.  Even then you have to
observe reasonable design rules.  In the really high performance
requirements (i.e. > 10MB/sec average in bursts) with multi-MB
data transfers, you really need to balance the total application
design and task priorities carefully.  If you do, your performance
will be outstanding!

..mike..

From interf!atlas!argus!brackett@uunet.uu.net  Fri Jan 10 05:10:41 1992
From: interf!atlas!argus!brackett@uunet.uu.net (Todd Brackett)
Date: Fri Jan 10 05:10:52 PST 1992
Subject: Windays and User Groups
Hi!

I just heard from Stan Schneider at RTI that WinDays has been scrubbed
due to lack of interest (or maybe response).  How many people could scare
up the conference "fee" as well as getting the boss to get you travel and time?
I was wondering if the "National" user group meeting has been scrubbed 
as well?

For everybody's reference I was anointed (by default) to organize the east
coast meeting sometime in the fall.  As of right now there is no scheduled 
time or place.  If you have comments, ideas & suggestions
please feel free to get them to me.

Regards,

-------------------------------------------------------
|Todd S. Brackett                 |Voice:703 790 8500 |
|Interferometrics, Inc.           |FAX:  703 848 2492 |
|8150 Leesburg Pike               |                   |
|Vienna, VA 22182                 |                   |
|-----------------------------------------------------|
|U. S. Naval Observatory          |Voice:202 653 0945 |
|34th and Massachusetts Ave. NW   |FAX:  202 653 0941 |
|Building 52                      |                   |
|Washington, DC 20392-5100        |                   |
|-----------------------------------------------------|
|Internet:brackett@interf.com                         |
|Uunet:   uunet!interf!brackett                       |
-------------------------------------------------------

From jjohnson@hns.com  Fri Jan 10 05:54:02 1992
From: jjohnson@hns.com (Jayne Johnson)
Date: Fri Jan 10 05:54:09 PST 1992
Subject: Re:  Windays and User Groups
In reference to ideas about the East Coast Users Group Meeting I would like
to say that I find that paying for such a conference was a bad idea since 
we the Users are organizing the event. If we want why don't we organize the
meeting to occur in a place that isn't too expensive and hard to get to.

Is this year going to be in Boston? If so is anyone attending a college around
the Boston area where we could use the campus resources? 

As far as subjects go I would like to hear alot about C++ and POSIX . Let's 
have a seminar to teach the fundamentals of C++. Let's have a seminar about
the POSIX standards VxWorks is compliant and what it means. 

Has anyone mentioned the possibility of Users Group dues to pay for the
conferences? 

Well, that's my two cents for now....

From heyes@dadev.cebaf.gov  Fri Jan 10 06:52:21 1992
From: heyes@dadev.cebaf.gov
Date: Fri Jan 10 06:52:31 PST 1992
Subject: Re: Windays and User Groups 
can someone in the know verify if Windays has indeed been canceled due
to lack of interest??

I am just looking at the invitation which has no deadline for 
subscription printed on it. I am sure there are many people like 
myself who could not "rush" a subscription off before the holidays,
because their companys travel department does not work that far in
advance, but would have done something if there had been a deadline.
We all know some psychology is needed, especially in goverment labs,
so get the beurocracy moving.

Graham Heyes

CEBAF

From wesw@fog.wv.tek.com  Fri Jan 10 09:05:45 1992
From: wesw@fog.wv.tek.com
Date: Fri Jan 10 09:05:51 PST 1992
Subject: Streams for VxWorks Available?
   Some software we are evaluating is written for a System V implementation
   of streams.  Is there a streams interface available for VxWorks (third-
   party or otherwise)?

   Wes Whitnah

From jim@cave.arc.nasa.gov  Fri Jan 10 22:09:14 1992
From: Jim Pantaleo x45347 <jim@cave.arc.nasa.gov>
Date: Fri Jan 10 22:09:22 PST 1992
Subject: serial problems with 5.0.2 on 1E
We've run into a problem in our recent installation of 5.0.2b (released
version).  Long rapid output (like a memory dump) over the serial port
to a terminal or host suffers from missing, altered, and/or extra characters.
We've tried both our ROM sets on both of our 1E's and the result is exactly
the same.  A monitor dump like "d 300000,1000" with no user code loaded will
demonstrate the problem.  We've tried all combinations of parity, data bits,
stop bits, and soft and hard flow control without any improvement.  The
original Sun ROMs and the VxWorks 4.0.2 ROMs work just fine under the same
test conditions.  It almost looks like something in an interrupt service
routine is screwed up.  WRS tech support has been unable to reproduce the
problem.  The only difference in our systems seems to be that WRS uses the
Force 1E wit2 MB Roms, while we use older Sun 1Es with 1 MB ROMs.  We just
got a new 1E from Sun with 2MB ROMs, but we can't get that one to boot
VxWorks (using a 5.0.2 2MB ROM) at all.  Any ideas would be greatly
appreciated!

  Thanks in advance -
   Jim Pantaleo
   Sterling Software
   jim@cave.arc.nasa.gov

From visicom!VisiCom.COM!trest@nosc.mil  Sat Jan 11 11:31:38 1992
From: Mike Trest <trest@visicom.com>
Date: Sat Jan 11 11:31:46 PST 1992
Subject: VX-SERVER PERFORMANCE MEAUREMENT?

Someone asked me how the VX-SERVER compares to X running on the SUN?
I decided to try a small comparison test to let him decide.  I know
what I did is not a definitive benchmark.  I chose to set a decicated
VxWorks display along side a SUN display and let him judge by visual
performance.

The VX-Server was v5.0.2 on a FORCE CPU-30 (25MHZ, 4MB) with a Vigra
MMI-150 1MB video card.  The SUN/OS 4.0.3 was a SUN 4/300 32MB with a
cgsix video frame buffer.  Both machines were booted and were reduced
to minimum deamons and limited net inteference. (Not perfect but
reasonable). 

The demonstration was to start xclock and six individual occurances
of the Kaleidascope client.  Kaleids were all 200x200. The were all 
fully exposed on both screens.  All clients were working against X 
servers on their respective CPU.  No network activity was occuring to
or from outside servers.

Once everything was running, all the visual ovservers voted that the
X server on the FORCE CPU-30 had a slight edge on the SUN 4/300.  The
programmers in the group thought this was FANTASTIC since the 68030
has 1/3 the MIPS rating of the SPARC, 1/4 the memory size and 
(someone guessed) 1/10 of the cost.

My question of the VxWorks community is:  What is a fair comparison?
Should we fight through the technical datails to try for a truly equitable
comparison environment or is it appropriate to use the human observer?
After all, for a man-machine interface like the X-Windows System, how 
fast is "fast enough"?

If you have any thoughts or simple clients which can be made into a
reasonably universal benchmark, I would be interested in hearing from
you.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
->
-> The remainder of this item is some of the VxWorks commands to show you
-> the actual task environment and socket activity between the clients 
-> and the server.  If you do not care about this stuff, STOP NOW.
->
->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-> i

  NAME        ENTRY       TID    PRI   STATUS      PC       SP     ERRNO  DELAY
---------- ------------ -------- --- ---------- -------- -------- ------- -----
tExcTask   _excTask       3fb600   0 PEND           bf90   3fb564       0     0
tLogTask   _logTask       3fa0b8   0 PEND           bf90   3fa018       0     0
tShell     _shell         3b5890   1 READY         1b5d8   3b553c       0     0
tRlogind   _rlogind       3e2844   2 PEND          335e6   3e264c       0     0
tTelnetd   _telnetd       3e09d8   2 PEND          335e6   3e090c       0     0
tNetTask   _netTask       3f5dc8  50 PEND          335e6   3f5d70       0     0
t_Xvxvigra1_main          2afba0  75 PEND+T        335e6   2af804       0 26052
t_xclock2  _main          39024c 100 PEND+T        335e6   38ff50       0  2084
t_kaleid3  _main          37054c 100 READY         29b8c   3700bc       0     0
t_kaleid4  _main          364b84 100 PEND          335e6   3647f8       0     0
t_kaleid5  _main          358180 100 READY         2baa4   357db8       0     0
t_kaleid6  _main          34cd34 100 PEND          335e6   34c9a8       0     0
t_kaleid7  _main          341e6c 100 PEND          335e6   341b00       0     0
t_kaleid8  _main          3358dc 100 PEND          335e6   335570  3d0002     0

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
spy 10

NAME          ENTRY         TID   PRI   total % (ticks)  delta % (ticks)
--------     --------      -----  ---   ---------------  ---------------
tExcTask     _excTask     3fb600    0     0% (       0)    0% (       0)
tLogTask     _logTask     3fa0b8    0     0% (       0)    0% (       0)
tShell       _shell       3b5890    1     0% (      14)    0% (       0)
tRlogind     _rlogind     3e2844    2     0% (       0)    0% (       0)
tTelnetd     _telnetd     3e09d8    2     0% (       0)    0% (       0)
tSpyTask     _spyTask     3766dc    5     5% (     750)    5% (      34)
tNetTask     _netTask     3f5dc8   50     9% (    1326)    9% (      61)
t_Xvxvigra1  _main        2afba0   75    44% (    5963)   46% (     287)
t_xclock2    _main        39024c  100     0% (       1)    0% (       0)
t_kaleid3    _main        37054c  100     4% (     589)    3% (      24)
t_kaleid4    _main        364b84  100     5% (     727)    4% (      28)
t_kaleid5    _main        358180  100     5% (     683)    3% (      20)
t_kaleid6    _main        34cd34  100     5% (     684)    4% (      25)
t_kaleid7    _main        341e6c  100     4% (     638)    5% (      33)
t_kaleid8    _main        3358dc  100     4% (     659)    6% (      39)
KERNEL                                   10% (    1441)    9% (      61)
INTERRUPT                                 0% (       3)    0% (       0)
IDLE                                      0% (       0)    0% (       0)
TOTAL                                    95% (   13478)   94% (     612)

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-> memShow 

SUMMARY:
 status   bytes    blocks   ave block  max block
 ------ --------- -------- ---------- ----------
current
   free   1968964       18     109386   1856556
  alloc   1926184    10164        189        -
cumulative
  alloc   3923044    17732        221        -

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-> inetstatShow

Active Internet connections (including servers)
PCB      Proto Recv-Q Send-Q  Local Address      Foreign Address    (state)
-------- ----- ------ ------  ------------------ ------------------ -------
377a0c   TCP       76      0  137.247.112..6000  137.247.112..1031  ESTABLISHED
37d60c   TCP        0    380  137.247.112..1031  137.247.112..6000  ESTABLISHED
377e0c   TCP        0      0  137.247.112..6000  137.247.112..1030  ESTABLISHED
3f770c   TCP        0     92  137.247.112..1030  137.247.112..6000  ESTABLISHED
35e50c   TCP        0      0  137.247.112..6000  137.247.112..1029  ESTABLISHED
37d50c   TCP        0     92  137.247.112..1029  137.247.112..6000  ESTABLISHED
37d58c   TCP       92      0  137.247.112..6000  137.247.112..1028  ESTABLISHED
377d0c   TCP        0     92  137.247.112..1028  137.247.112..6000  ESTABLISHED
37730c   TCP        0      0  137.247.112..6000  137.247.112..1027  ESTABLISHED
3f710c   TCP        0      0  137.247.112..1027  137.247.112..6000  ESTABLISHED
3f800c   TCP       76      0  137.247.112..6000  137.247.112..1026  ESTABLISHED
3f748c   TCP        0    152  137.247.112..1026  137.247.112..6000  ESTABLISHED
3f778c   TCP        0      0  137.247.112..6000  137.247.112..1025  ESTABLISHED
3f758c   TCP        0      0  137.247.112..1025  137.247.112..6000  ESTABLISHED
3f7b0c   TCP        0      0  0.0.0.0.6000       0.0.0.0.           LISTEN
3f7c8c   TCP        0      0  0.0.0.0.23         0.0.0.0.           LISTEN
3f7d8c   TCP        0      0  0.0.0.0.513        0.0.0.0.           LISTEN

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-> tcpstatShow

TCP:
        2353937 packets sent
                2039925 data packets (157874957 bytes)
                6 data packets (2300 bytes) retransmitted
                289464 ack-only packets (289303 delayed)
                0 URG only packet
                0 window probe packet
                24429 window update packets
                114 control packets
        2354493 packets received
                313163 acks (for 157874462 bytes)
                71 duplicate acks
                0 ack for unsent data
                2041508 packets (159471927 bytes) received in-sequence
                7 completely duplicate packets (2301 bytes)
                0 packet with some dup. data (0 byte duped)
                2 out-of-order packets (0 byte)
                0 packet (0 byte) of data after window
                0 window probe
                0 window update packet
                1 packet received after close
                0 discarded for bad checksum
                0 discarded for bad header offset field
                0 discarded because packet too short
        43 connection requests
        42 connection accepts
        85 connections established (including accepts)
        104 connections closed (including 0 drop)
        0 embryonic connection dropped
        312813 segments updated rtt (of 312865 attempts)
        6 retransmit timeouts
                0 connection dropped by rexmit timeout
        0 persist timeout
        0 keepalive timeout
                0 keepalive probe sent
                0 connection dropped by keepalive

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-> ipstatShow

               total 2388939
              badsum    0
            tooshort    0
            toosmall    0
             badhlen    0
              badlen    0
           fragments    0
         fragdropped    0
         fragtimeout    0
             forward    0
         cantforward    0
        redirectsent    0

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-> udpstatShow
UDP:
        0 incomplete header
        0 bad data length field
        0 bad checksum

->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->
-

From johnb@srchtec.searchtech.com  Mon Jan 13 06:40:58 1992
From: johnb@srchtec.searchtech.com
Date: Mon Jan 13 06:41:05 PST 1992
Subject: Re: Windays and User Groups

(Jayne Johnson wrote:)

> Is this year going to be in Boston? If so is anyone attending a college around
> the Boston area where we could use the campus resources? 
> 
> As far as subjects go I would like to hear alot about C++ and POSIX . Let's 
> have a seminar to teach the fundamentals of C++. Let's have a seminar about
> the POSIX standards VxWorks is compliant and what it means. 

   If you decide to make Boston the location, I'm interested.  (My wife has
family in the area.)  If you have trouble finding someone to teach your
"starter seminar" in C++, I'd be willing to do it for free, provided that
the trip doesn't cost me anything (i.e. somehow an airplane ticket would
have to be provided).

   I could also possibly talk about experiences using C++ and VxWorks to
do "shared instantiations" of objects across processor boards... we've been
doing that on a couple of chassis' with FORCE CPU-30's, CPU-40's, and
MIPS r3000 boards.

   Since I only get the daily exploder digest, I haven't been following all
of this thread.  If anyone has saved all/most of it, could you either forward
it to me, or bring me up to date about what's happening with the meeting?

Regards,

John Baldwin                                        johnb@searchtech.com
search technology, inc.                             uupsi!srchtec!johnb
4725 peachtree corners cir., ste 200                johnb@srchtec.uucp
norcross, georgia  30092

From root@borsu6.lbl.gov  Mon Jan 13 06:59:59 1992
From: root@borsu6.lbl.gov (PK System Administrator)
Date: Mon Jan 13 07:00:05 PST 1992
Subject: don't care

Don't care

From mea@sparta.com  Mon Jan 13 07:05:52 1992
From: mea@sparta.com (Mike Anderson)
Date: Mon Jan 13 07:06:02 PST 1992
Subject: Re: Windays and User Groups
Greetings!

  For what it's worth, my company had volunteered a meeting place for
last year's East Coast User's group meeting and WRS opted for downtown
D.C.  We are still willing to volunteer our conference facilities for
the 1992 meeting provided folks don't mind McLean, VA (about 7 Miles
in towards D.C. from Dulles Airport in the Tyson's Corner area) as 
a site (maybe $10 each to offset refreshment costs).  As usual Todd,
if you need any assistance organizing this year's meeting, just let 
me know and I'll pitch in to help.

Last Year's East Coast Meeting Stuckee,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From prb@aplexus.jhuapl.edu  Mon Jan 13 08:09:19 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Mon Jan 13 08:09:25 PST 1992
Subject: Windays, C++, and shared instantiations 

John Baldwin wrote:

>   I could also possibly talk about experiences using C++ and VxWorks to
> do "shared instantiations" of objects across processor boards... we've been
> doing that on a couple of chassis' with FORCE CPU-30's, CPU-40's, and
> MIPS r3000 boards.

I would be very interested in a seminar on using C++ and VxWorks;
especially your implementation of "shared instantiations" of objects 
across processor boards...

		Paul Bade
		prb@aplexus.jhuapl.edu

		Life is what happens while you're planning something else.

From Christina_Goette@wrs.com  Mon Jan 13 08:11:37 1992
From: Christina_Goette@wrs.com (Christina Goette)
Date: Mon Jan 13 08:11:49 PST 1992
Subject: WINDAYS USA
                       Subject:                               Time:8:17 AM
  OFFICE MEMO          WINDAYS USA                            Date:1/13/92
Recently there have been some questions posted to the exploder about the status
of the WINDAYS USA conference that was to be held in March in San Jose. 
WINDAYS USA was designed to be an exciting series of technical and marketing
programs held over the course of two days at the Fairmont Hotel.  The audience
was targeted as much at new prospects as existing customers.   Although the
program was shaping up nicely, Wind River Systems has decided to postpone the
conference due to the current economic pressures affecting many company's
travel budgets.   There were simply not enough people that could commit to
attend.  The concept of WINDAYS USA is a good one, and we look forward to
holding this event in the near future, although a new date and time have not
yet been decided on.  

The annual West Coast VxWorks Users Group will be held in the early spring. 
Details for this event are being worked out even as you are reading this
message, so stay tuned for more information.  

Mitch Bishop
Director Marketing

From biocca@bevsun.bev.lbl.gov  Mon Jan 13 10:26:51 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Mon Jan 13 10:26:57 PST 1992
Subject: Re: RESULT:  comp.os.vxworks passes 295: 17
I just want to thank Henning for his efforts in getting this newsgroup
creation processed.  I'm working on the list-newsgroup connection software,
though I suspect it won't work for a few weeks yet.

Alan K Biocca
Exploder Maintainer

From mea@sparta.com  Mon Jan 13 10:41:21 1992
From: mea@sparta.com (Mike Anderson)
Date: Mon Jan 13 10:41:28 PST 1992
Subject: Re:  serial problems with 5.0.2 on 1E
Greetings!

  Sounds to me as though you're overrunning the receive buffer on your 
display device.  I've typically seen this sort of behaviour when the
handshakes weren't coordinated (one end was using X-ON/X-OFF and the other
was expecting RTS/CTS, etc.) or when the ring buffer for output was being
overrun by too many tasks writing to it simultaneously.  You might try
and just up the ring buffer size on your tyCoDevCreate call.  However,
if it is a handshake problem, this will only serve to mask it.  What 
you need to do is to put a breakout box on the serial line and watch the
signals as you generate this problem.  If you see the DTR, RTS, CTS, or
DSR lines toggle state, then someone on the line is trying to use
hardware handshakes and the other one is ignoring it.  I suspect that you
probably want to set up both sides for software handshakes (X-ON/X-OFF).
As much as I prefer hardware handshakes (it's tough to miss a line
voltage change :-), software handshakes are typically easier to implement
and they are the default on Sun workstations as they come out of the 
box (hardware handshakes had to be enabled via a kernel mod under most
releases of SunOS).

Hope this helps,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From dit@melchor.jhuapl.edu  Mon Jan 13 13:41:38 1992
From: dit@melchor.jhuapl.edu (Daryl I. Tewell)
Date: Mon Jan 13 13:41:44 PST 1992
1)  Why is the entryPt parameter of taskSpawn() type FUNCPTR
    instead of type VOIDFUNCPTR ?

Discussion:  Since tasks never return, or, at least, aren't
called with the idea of providing a return value, it makes sense 
to cast them as pointers to functions returning void.  Doing
otherwise, I think, is confusing.

2)  Why is the type that malloc() returns (VOID*) NOT the
    same as the type that free() takes (char*) ?

Discussion:  These two types should be the same.  After all,
the application programmer is required to pass free() the same
value returned by malloc().  Having two different types for 
the same value is bad style and confusing.

From whorner@vlsi7.gsfc.nasa.gov  Mon Jan 13 15:05:19 1992
From: whorner@vlsi7.gsfc.nasa.gov (Ward Horner)
Date: Mon Jan 13 15:05:25 PST 1992
Subject: Re:  Streams for VxWorks Available?

From susanna@tomato.lbl.gov  Tue Jan 14 12:43:17 1992
From: susanna@tomato.lbl.gov (Susanna Jacobson)
Date: Tue Jan 14 12:43:24 PST 1992
Subject: MVME-165 boot problem
Has anyone else had problems booting the MVME-165 with the VxWorks boot
PROM's?  We have an intermittent boot failure that looks like this:

	At power-on, the 165 board's status lights show it apparently
	starting as usual.  At about the time when the banner page and
	boot countdown should appear on the console screen, the red
	FAIL light on the board lights and stays on.  Nothing ever
	appears on the console screen.

If we cycle power a few times, the 165 may eventually come up
successfully.  Once the 165 succeeds on power-up, warm boots (via
software or RESET button) always succeed, but if the crate is powered
off, we can never tell whether the 165 will fail on the next power-up.
We have seen this on all the 165's we have tried (six so far) in two
different kinds of VME crate.  A 165 alone in a crate will behave this
way, as well as with other boards in the crate.

If the 165 has the Motorola BUG PROM instead of the VxWorks boot PROM,
it comes up successfully every power-up without fail.  We have even
tried booting two 165's - one with BUG and one with VxWorks -- in the
same crate:  the VxWorks board failed and the BUG 165 came up
successfully.

We're pursuing this with Motorola and with WRS, of course.  Has anyone
else had this experience or, conversely, used 165's with WRS PROM's
without problems?

========================================================================
Susanna Jacobson			MS 46A-1123
					Lawrence Berkeley Laboratory
SRJacobson@LBL.Gov			1 Cyclotron Road
(510) 486-7801				Berkeley, CA 94720
========================================================================

From jim@cave.arc.nasa.gov  Tue Jan 14 12:54:47 1992
From: Jim Pantaleo x45347 <jim@cave.arc.nasa.gov>
Date: Tue Jan 14 12:54:53 PST 1992
Subject: 5.0.2b boot problems on 1E
While we can get around the serial problems we've been having, another problem
has come up that's a stopper.  We have two Sun 1E boards - one is an older
board with 1MB EPROMs and one is a new board with 2MB EPROMs.  The problem is
that both of these boards will only boot 5.0.2 in one of our four VME chassis.  Both
boards will boot in any of the chassis with their original Sun EPROMs installed,
and one will boot anywhere with 4.0.2 installed (we don't have a 2MB 4.0.2 EPROM
to test the other board).  Both boards have 4MB of memory.  We also have a third
4MB board with 1MB EPROMs - it has failure problems when it heats up, but it boots
in all four chassis with Sun or 4.0.2 installed.  With 5.0.2 installed, it will
boot in the same chassis the other boards boot OK in, plus one additional chassis.
But then it fails after 10-15 minutes because of its heat-related problems...

Two of the chassis are 20-slot open cardcages used only for development work,
while the other two are enclosed chassis with 17- or 20-slot backplanes.  We
tried the 1Es both alone in the chassis and with several memory boards in case
power supplies were load-sensative - but when they booted they booted regardless
of the number of boards.

I've spoken to WRS tech support, and they indicated they also found the 1Es to
be very sensative to chassis configuration.  Does anyone else have any ideas
what we can do to get 5.0.2 up and running on those other chassis?  Since Sun
and 4.0.2 EPROMs boot fine, it's hard not to point a finger at 5.0.2...

From ntmtv!fleishma@ames.arc.nasa.gov  Tue Jan 14 19:36:04 1992
From: ntmtv!fleishma@ames.arc.nasa.gov (Emmanuel Fleishman)
Date: Tue Jan 14 19:36:11 PST 1992
Subject: Re:MVME-165 boot problem

Susanna Jacobson writes
>  Submitted-by susanna@tomato.lbl.gov  Tue Jan 14 12:43:17 1992
>  Submitted-by: susanna@tomato.lbl.gov (Susanna Jacobson)
>   
>  Has anyone else had problems booting the MVME-165 with the VxWorks boot
>  PROM's?  We have an intermittent boot failure that looks like this:
>  
>  	At power-on, the 165 board's status lights show it apparently
>  	starting as usual.  At about the time when the banner page and
>  	boot countdown should appear on the console screen, the red
>  	FAIL light on the board lights and stays on.  Nothing ever
>  	appears on the console screen.
>  
>  If we cycle power a few times, the 165 may eventually come up
>  successfully.  Once the 165 succeeds on power-up, warm boots (via
>  software or RESET button) always succeed, but if the crate is powered
>  off, we can never tell whether the 165 will fail on the next power-up.

We too experienced intermitent boot failure although we are using proprietary
boards. Recently we identified what was our problem:
	refference to uninitialized variable during kernelInit
This problem has been checked and confirmed by WRS (BTW they were very
cooperative and responsive)

The problem is kindof rear since most boards probably zero their memory
on power-up and this seems to be the *right* value for uninitialized variable.
However, since this particular variable resides on stack - all depends what
has been done prior to entering scope of this variable... :-(

If you suspect any of above then the following patch may help:

	prior to calling kernelInit(...) call kernelInitPatch(...)
	which will zero certain area to be used by local variables of
	kernelInit.

Here is modified invocation of kernelInit(..):

----------------------------------------------------------------------------

      /* initalize kernel and spawn RootTask
       *
       * the following patch zeros space where "initTCB" block will be
       * located in the kernelInit() procedure.
       *
       * Note that Patch always returns OK but it is "tested" to 
       * force compiler to pop SP after return from the Patch.
       */

   if (kernelInitPatch(0,0,0,0,0,0) != OK)
	return;

   kernelInit(... 6 kernelInit parameters ...);

----------------------------------------------------------------------------
 
STATUS kernelInitPatch( int dummy0, int dummy1, int dummy2,
			int dummy3, int dummy4, int dummy5)
{
   WIND_TCB dummyTCB;

   bzero((char *)&dummyTCB, sizeof dummyTCB);
   return (OK);
}

----------------------------------------------------------------------------

Hope this helps
 
-----------------------------------------------------------
Emanuel Fleishman		voice: (415) 940-2346
Northern Telecom,		  fax: (415) 966-1067
685 E. Middlefield Road		 UUCP: ames!ntmtv!fleishma
Mountain View, CA 94039		 ARPA: fleishma@ntmtv.com
------------------------------------------------------------

From hmp@frc2.frc.ri.cmu.edu  Wed Jan 15 08:54:31 1992
From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
Date: Wed Jan 15 08:54:42 PST 1992
Subject: comp.os.vxworks is alive

... but I haven't seen anything but my own first post on it.
Perhaps some of you would like to make trial posts to see if things are
working; maybe it takes a while to propagate to everyone.

From my post, then:
What's up with the promised kernel patch that will fix the
synchronization bug with message queues? This bug appeared in a most
surprising manner almost simultaneously at several sites last
November. 

-Henning

Henning Pangels     |   hmp@frc2.frc.ri.cmu.edu   |      Field Robotics Center
Research Programmer |       (412) 268-7088        | Carnegie-Mellon University
------------------------------------------------------------------------------
		    Do you really know what time it is?

From prb@aplexus.jhuapl.edu  Wed Jan 15 10:13:53 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Wed Jan 15 10:14:00 PST 1992
Subject: Re: comp.os.vxworks is alive

Henning wrote:

>What's up with the promised kernel patch that will fix the
synchronization bug with message queues? This bug appeared in a most
surprising manner almost simultaneously at several sites last
November. 

I have received and tested the patch for msgQ's. It works!
You will have to talk to WRS to get a copy of the patch.

			Paul Bade
			JHU/APL
			(301)-953-6000 x8681

From francis@wrs.com  Wed Jan 15 10:28:23 1992
From: francis@wrs.com (Francis St. Amant)
Date: Wed Jan 15 10:28:29 PST 1992
Subject: Re:MVME-165 boot problem

Emmanuel Fleishman writes:

> We too experienced intermitent boot failure although we are using proprietary
> boards. Recently we identified what was our problem:
>         reference to uninitialized variable during kernelInit

WRS verified this problem a few days ago and has built a patch quite similar
to the one Emmanuel includes.  I am just finished the README file and
will formally release the patch to WRS Tech Support this morning.  To get
it, ask for the kernelInit patch.

We had originally characterized this as a warm boot problem only, which is
why Susanna Jacobson's initial mail didn't prompt me to reply sooner with
this solution.  Thanks to Emmanuel for pointing out that some boards may not
zero memory on cold boot, so there could be junk on the stack upon cold
boot also.

Since the patch is relatively short, in source (thus is ascii), and is a
current discussion item, I'll put the patch on the exploder in a couple of
hours.

------------------------------------------------------------------------------
  Francis St. Amant             |       800-872-4977 / FAX 510-814-2010
  Director of Customer Services |       510-814-2165 bbs
  Wind River Systems            |       1010 Atlantic Avenue
  francis@wrs.com               |       Alameda, California, 94501 USA
------------------------------------------------------------------------------

From francis@wrs.com  Wed Jan 15 10:44:25 1992
From: francis@wrs.com (Francis St. Amant)
Date: Wed Jan 15 10:44:31 PST 1992
Subject: Message queue patch

Henning Pangels writes:

> What's up with the promised kernel patch that will fix the
> synchronization bug with message queues? 

In mid-December, WRS mailed (US mail, i.e. real hardcopy) a description of
this problem and notification of a fix to every customer who had ever
bought VxWorks.

A small number of these have been returned to us as undeliverable.  Most
often, this is because we have not been updated when the contact-of-record
has changed jobs or left a customer's company.  Please be sure that when
this happens, you notify us so we can change our records.  We depend on
correct addresses to communicate with you.  Contact WRS sales department
at 510-748-4100 to notify us.

It can also happen that the person designated to receive official 
communications from WRS may not be an engineer on the project.  So if you
didn't receiv word of this fix, please check with your management to
see if perhaps they did.

If you need the patch, please contact WRS tech support at 800-872-4977
and ask for the message queue patch.  It can be shipped to you via email
or tape, or you can download it from the WRS BBS at 510-814-2165.

------------------------------------------------------------------------------
  Francis St. Amant             |       800-872-4977 / FAX 510-814-2010
  Director of Customer Services |       510-814-2165 bbs
  Wind River Systems            |       1010 Atlantic Avenue
  francis@wrs.com               |       Alameda, California, 94501 USA
------------------------------------------------------------------------------

From jimt@wrs.com  Wed Jan 15 11:30:22 1992
From: jimt@wrs.com (Jim Talbot)
Date: Wed Jan 15 11:30:33 PST 1992
Subject: SPARC 5.0.2b Summary

    There have been a lot of questions (both internally and from
customers) about the differences in VxWorks 68K and VxWorks 5.0.2b for
the SPARC.  The main areas of interest are between 68K and SPARC, and
VxWorks/SPARC changes from 4.0.2 to 5.0.2b.  Most of this is fairly
well documented in:

	Guide to VxWorks / SPARC
	Architecture-Specific Reference for VxWorks / SPARC
	Board Support Documentation (Sun SPARCengine 1E, Ironics iv-SPRC).

    I will summarize some of the changes below (by document) and try
to highlight the areas that cause the most difficulty for application
developers.  To our knowledge, there are no serious bugs in 5.0.2b
SPARC.  Our beta sites were extremely helpful in finding (and fixing)
the few bugs reported.  Bug fixes, enhancements, and clean up efforts
continued throughout the SPARC VxWorks development and release phases.

Guide to VxWorks / SPARC
------------------------
Section 1.0	Introductory stuff.

Section 2.0	Getting started, installation, and documentation.

Section 3.0	Differences between VxWorks for 68K and SPARC

Section 3.1	Compile application modules with -DCPU=SPARC.

Section 3.2	bALib can be pulled in to get 8-byte versions
		(faster execution) of bzero(), bfill(), and bcopy().

Section 3.3	bLib provides an unaligned swap routine call uswab().

Section 3.4	dbgLib has some changes and caveats for SPARC.  Affected 
		routines are: c(), s(), cret(), so(), psrShow(), and tt().

Section 3.5	Addition of fppEnable() to fppALib.

Section 3.6	Addition of fsrShow() to fppLib.

Section 3.7	intALib functions intLevelSet() and intLock() differ 
		for the SPARC which has 15 interrupt levels (68K has 7).

Section 3.8	malloc() returns a pointer that is 8-byte aligned.

Section 3.9	scsiPhysDevCreate() parameter change:
			selTimeOut replaced by reqSenseLength.

Section 3.10	Some SPARC signal definition changes - see sigLib.h

Section 3.11	taskRegsSet() and taskRegsGet() in taskArchLib differ 
		from 68K.

Section 3.12	The register functions in usrLib differ for SPARC (of course):
			g0() - g7(), o0() - o7(), l0() - l7(), i0() - i7(),
			pc(), npc(), psr(), wim(), y().

Section 3.13	The vxTas() routine uses the SPARC LDSTUB instruction - 
		reference vxALib and/or the SPARC Architecture Manual
		(note the TAS/backplane configuration for the Sun-1E).

Section 3.14	vxLib contains an additional function to access alternate
		space indices (ASI) called vxMemProbeAsi().

Section 3.15	The vector table base address is 0x1000 for all SPARC targets.

Section 3.16	This is a lengthy discussion of SPARC interrupts.  In brief,
		there are 15 levels, an interrupt stack is implemented in 
		software, and there is optional vectored interrupt handling.

		In 4.0.2 vectored interrupts were not supported (the SPARC 
		uses autovectoring) which made porting from 68K targets 
		difficult.  In 5.0.2 vectored interrupts are the default for 
		seamless porting for 68K types and applications.  In sysLib.c 
		look at sysIntAckTable[].  There are two options based on 
		"addresses" or "functions".  Also, the vector size and ASI 
		space are selectable for levels that specify an IACK address.

		Note that 4.0.2 applications that want to remain autovectored 
		should fill the table entries to NULL (one entry for each 
		interrupt level).  A NULL entry suppresses the IACK cycle 
		(or call) for that interrupt level.  The call table method 
		allows more powerful and flexible interrupt acknowledgement
		but has adds overhead.

		The mapping of the 7 VMEbus interrupt levels to the 15 SPARC 
		levels may vary with each target (see hardware manual).  VME
		interrupts must be acknowledged to clear the signal line.

Section 4.0	This is the floating-point section for SPARC.  Areas covered 
		include:  floating-point contexts, exception definitions and 
		options, exception handlers, deferred exceptions, and 
		floating-point exception simulation.

		A list of SPARC floating-point instructions follows, as does 
		the VxWorks math library for the SPARC.  There is a 
		tutorial on how to incorporate a higher performance math 
		library (SunOS libm.a) for certain SPARC targets.

Architecture-Specific Reference for VxWorks / SPARC
---------------------------------------------------
This document contains replacement "libraries" for:

	bALib		Buffer manipulation (assembly)
	fppALib		Floating-Point (assembly)
	fppLib		Floating-Point (C)
	intLib		Interrupt subroutines
	taskArchLib	Architecture-specific task management routines
	trcLib		Stack trace support

The "drivers" section contains two additions:

	l64853Lib	Sbus DMA Controller
	ncr5390Lib	NCR 5390 Advanced SCSI Controller (ASC)

Board Support Documentation (Sun SPARCengine 1E)
------------------------------------------------ 
The Sun-1E is the most popular of the SPARC VxWorks targets to date.
This board can be very difficult to develop applications with if one
needs to work at the board level.  Higher level applications can
benefit greatly from the wealth of SPARC code.  VxWorks on the Sun-1E
has attempted to buffer the user from the Sun hardware, but it is
impossible to do so for everybody.  Some key topics are touched upon,
but refer to the VxWorks documentation, the 1E documentation, and the
BSP code for more detail and code samples.

EPROM Sockets -
Some boards have 1Mbit (27010) daughter boards (256K total), others
support 2Mbit (27020) ROMs (512K bytes).  The ROMs are sequential, not
interleaved.  Code starts in U101 and continues in U102, if necessary.
See ROM_SIZE in config.h, and check your hardware manual for the
daughter board size.

Boot ROMs -
The standard VxWorks boot ROMs are compressed.  This results in a very
long boot sequence (>30s) on the 1E since the execution of the
decompression code and the writing of the resultant data are done
while caching is still turned off.  Sorry, but that's as fast as the
hardware can go.  If this is too annoying use uncompressed ROMs (make
bootrom_uncmp.hex) - 40% more code space but faster booting.  Also
note the debug option RESET_WINDOW_UNROLLING in romInit.s.

Non-Volatile RAM - 
The VxWorks boot parameters are saved in NVRAM.  Previous versions of
the 1E BSP saved this information at offset 0, trashing the SunOS boot
parameters.  In an effort to help those who freely interchange SunOS
and VxWorks on 1Es the boot parameters were moved to an unused area of
the NVRAM (see NV_BOOT_LINE in config.h).  5.0.2b ROMs will not find
your old boot parameters so copy them the new area or re-enter them
from the boot prompt.

The old ethernet address was created in usrConfig.c (and bootConfig.c)
to try to come up with a unique physical address.  Now that we know
where Sun puts the address in NVRAM it is pulled from there and given
to the LANCE.  Since many of us are doing development and our code may
go astray, this six-byte address can get trashed.  I suggest you write
it down somewhere so you can restore it by modifying the bytes
directly.  There are two parts: the three-byte Sun prefix, and the
three-byte suffix.  See sysHwInit() and the initialization of
lnEnetAddr[] in sysLib.c.  For those who have already lost the
address, try using the last digits of the board's serial number to get
a unique pattern for the last three bytes.  The virtual addresses and
data are as follows:

	0xFFD047DA	= 0x08		/* Sun Microsystems */
	0xFFD047DB	= 0x00
	0xFFD047DC	= 0x20

	0xFFD047DD	= 0x??		/* Board-specific */
	0xFFD047DE	= 0x??
	0xFFD047DF	= 0x??

You can also attempt to write-protect the NVRAM using the Sun-4 MMU.

Jumpers - 
There are only a few jumpers on the board and are seldom set more than
once.  The bus arbiter function is enabled/disabled by the
inclusion/exclusion (respectively) of the J1701 jumper between the
VMEbus connectors.  Use the "jump" tool, it really works!

Devices - 
The serial ports use a 15-pin connector in the DB-9 footprint.  There
are two standard serial ports, a keyboard/mouse interface, LANCE chip,
SCSI controller, a time-of-day clock, Sbus, P2 bus, VMEbus, and front
panel LEDs.  Please note the interactions between the MMU, the cache,
DMA devices, VME slave accesses, and Sun DVMA space.

Memory Maps - 
There are several memory maps in the manual, including: Control Space,
System Space, Device Space, the DRAM Map, and the MMU table.  Note
that use of the MMU is required, and also provides some of the cache
support.

Memory Management Unit - The Sun-4 MMU can be fun (just kidding) to
program, so VxWorks has set up default mappings.  Since this will not
cover all applications, changes should be made to sysMmuInit() in
sysLib.c.  Note the interactions between the MMU, the cache, DMA
devices, and VME slave accesses (DVMA).  The MMU can only map 64M
bytes at any given time.  The MMU can make development difficult, but
can also serve as a powerful extension when used effectively.  Working
with the MMU is tricky so use extreme caution, and consider side
effects.

Key terminology: context, segment, page, PMEG, PTE, type, virtual
address, physical address, DMA, and DVMA.  See the 1E manual for the
gory details.  The MMU operation is required, so learn it well if you
must program at that level.

In an effort to minimize the user's knowledge of the MMU an alternate
library (sysMmuLib.c) has been developed.  There is an excerpt from a
paper describing how one can create architecture-independent MMU and
cache libraries for all VxWorks targets.

Note that malloc() and other accesses to high DRAM on 16M boards for
DMA devices (LANCE, SCSI) may create virtual address that are not
mapped (0xFF400000 - 0xFFCFFFFF), already used (0xFFD00000 -
0xFFD1BFFF), or conflict with DVMA space (0xFFFxxxxx).

Cache - 
The Sun-1E contains a 64K byte write-through virtual address cache
with several flushing options - see sysCacheSet().  Be wary of cache
coherency of DMA and VMEbus slave operations since things are cached
by virtual address.  The rule of thumb is to flush the data cache 
and then invalidate the instruction cache.  Short cuts can be made 
for different cache implementations, especially mixed instruction/
data caches in write-through mode like on the Sun-1E.

VMEbus -
The VMEbus supports a restricted set of master and slave accesses.
Other features include 32 mailbox addresses, a bus locker, a jumper
for system controller, and a loopback cycle.  Note that there is a
512K byte master access window, and a 1M byte slave access window with
DVMA (MMU mapping).  The default window number is set to the 
processor number.  Note that this affects the backplane driver for
on-board buffering.

Interrupts - 
On-board interrupts do not need to be acknowledged.  However, 
VMEbus interrupts must be acknowledged.  See sysIntAckTable[] or
sysBusIntAck() in sysLib.c.

Floating-Point -
Floating-point operations are supported with a coprocessor chip that
allows the pipelining of operations.  Floating-point exceptions are
deferred, i.e., they must be pushed through the queue to generate an
error.

In summary for the 1E, understand the MMU and caches, the interactions
of them with DMA devices and slave DVMA.  Also note that the early
Sun-1E manual had several errors and typos.

Board Support Documentation (Ironics iv-SPRC)
---------------------------------------------
The Ironics SPARC runs at 25MHz or 33MHz, which must be selected in
ivSPRC.h with CPU_CLOCK_xxMHZ.  Remake the VxWorks image to run on
33MHz boards (the default is 25MHz).

EPROM and NVRAM - 
The ROMs are interleaved and require two (2) 27210s or 271024s
(16-bit) ROMs.  The most significant word is in U57; the least
significant word is in U60.  The board does not have non-volatile RAM
to preserve the boot parameters.  One can use function keys to aid in
boot parameter entry, or burn a new bootline in the boot ROMs.  Non-
volatile memory may be supported in future releases of the hardware.

Jumpers - 
There are a few jumpers of interest in the iv-SPRC.  One must select
the EPROM size, the system controller function, and enable/disable the
abort and reset switches.

Devices - 
The ivSPRC board has the two serial ports, VIC, VAC, and LED
registers.  A hexadecimal rotary switch, a reset switch, and an abort
switch are available for the application programmer.  Support for a
daughter board (seti) may be added in future releases.  It provides
on-board ethernet, SCSI, and non-volatile memory.

Ethernet - 
The current configuration only supports ENP-based networks.  The seti
daughter board (if/when supported) would allow on-board ethernet.

Interrupts -
The ivSPRC requires an acknowlegement of all interrupts.  This has
been made easier with the 5.0.2b release - see sysIntAckTable[] in
sysLib.c.

MMU and Cache -
The default configuration is with the MMU and cache enabled,
write-through mode.  This can be set to copyback mode to increase
performance, but at the added risk of cache coherency problems.  The
rule of thumb is to flush the data cache and then invalidate the
instruction cache.  Short cuts can be made for different cache
implementations.

Memory Maps - 
The memory map is established by the MMU.  The DRAM map for VxWorks
differs slightly for the ivSPRC, but the vector table is still at
address 0x1000.  One can customize the default MMU setup by changing
sysMmuInit() in sysLib.c.

Problems
--------
* Some versions of the Force CPU-1E have been having trouble booting.  
  Wind River Systems and Force Computers are working together to find 
  the source of the problem(s), hardware and/or software.  Force 
  is investigating the revisions of ROM daughter board, the gate arrays, 
  and other hardware configurations that seem to be troublesome.  All
  Sun/Force 1Es here at WRS boot fine with the 5.0.2b boot ROMs.

* Remember, most network related problems are simply due to configuration 
  on the host and/or target.  See the network section of the VxWorks 
  Programmers Guide.

Patches
-------
Since the release in November there have been a few improvements
to the SPARC release.  None are critical, but may be helpful to
know about.  These are in the patches directory of the release tree.

In h/sparc/esf.h there should be parentheses around the "n" in the
following macros: SF_LOCAL, SF_IN, ESF_GLOBAL, ESF_OUT, ESF_LOCAL, and
ESF_IN.  This helps avoid unexpected sizing assumptions that the
compiler might make.

The stack tracing code has been upgraded to allow more stacks to be
traced.  The SPARC had code that forced and early exit of some traces
that involved calling absolute (register-based) addresses, as opposed
to PC-relative calls (most calls are relative).  This debugging aid
has been fixed so that these cases are supported.  As a result ^C from
the shell now works and tt() is more robust.

There is a bug in the initialization code for all of VxWorks 5.X that
can affect boot ROMs and VxWorks image booting.  Uninitialized
variables in kernelInit() that serve as the initial TCB can prevent
the root task from finishing its configuration.

All of the above are rarely encountered, so getting the patches should
not be critical unless you have already been affected.  Contact Wind
River Systems Technical Support for more information and/or upgrades.

Be creative in your debugging efforts.  There is always a solution -
the information gathering and design efforts are only limited by your
imagination and effort!  Remember, read those manuals and try
different configurations and tests before calling Technical Support.
The more homework that you do the better able tech support will be
help you to solve your problem.

* Both VxGDB and windX are available as separate products for the SPARC.

    +-------------------------------------------------------------------+
    | James W. Talbot                        Wind River Systems         |
    | Architecture Porting Group Lead        1010 Atlantic Avenue       |
    |    and SPARC Project Lead              Alameda, California  94501 |
    |                                                                   |
    | (510) 814-2087                         TEL: (510) 748-4100, x2087 |
    |  jimt@wrs.com                          FAX: (510) 814-2010        |
    +-------------------------------------------------------------------+

From francis@wrs.com  Wed Jan 15 12:41:38 1992
From: francis@wrs.com (Francis St. Amant)
Date: Wed Jan 15 12:41:45 PST 1992
Subject: kernelInit patch, as promised
Here's the official patch from WRS.  The text mentions the source file
sprFix1272.c, which I have included after the README file.

I hope this solves the 165 booting problems.  Please call Tech Support
if you have continuing problems.

------------------------------------------------------------------------------
  Francis St. Amant             |       800-872-4977 / FAX 510-814-2010
  Director of Customer Services |       510-814-2165 bbs
  Wind River Systems            |       1010 Atlantic Avenue
  francis@wrs.com               |       Alameda, California, 94501 USA
------------------------------------------------------------------------------

This is the README file for the kernelInit patch.
This patch applies to Wind River Systems' VxWorks versions 5.0.2, 5.0.2b,
5.0.3, and 5.0.4 on the architecture families of 68k, 683xx, SPARC, and TRON.
This patch is not necessary for the architectures of 68040, 960, or MIPS.

Any questions or problems should be directed to Wind River Systems Technical 
Support.

Presenting Symptoms
-------------------
Warm boot using control-X can fail intermittently.  If warm boot succeeds,
all is well.  Hardware reset or cold boot may also experience this problem if
your board does not zero memory when reset or powered up.

Patch Contents
--------------
This patch contains the following files:
  (1)  This README file;
  (2)  The file sprFix1272.c

Patch Installation Instructions:
--------------------------------
This is a source code patch which will zero an uninitialized stack variable 
used by the routine kernelInit().

(1) Edit the function usrInit in both the files config/all/usrConfig.c and 
    config/all/bootConfig.c to include a new function call, as shown below.

(2) Add the new function sprFix1272, which is the entire contents of the
    file sprFix1272.c, to config/all/usrConfig.c and config/all/bootConfig.c.

(3) In the target directory for each of your targets, execute the commands
      make
      make bootrom.hex
    to generate new vxWorks and bootrom.hex files

(4) Make new boot ROMs from the new bootrom.hex file.

-------------------------------------------------------------------------------
The following code fragment from the usrInit function shows the code to be
added according to step 1, above.  Insert the lines specified between
the  >>>>   <<<<  marks just before the call to kernelInit, as shown.
(Do not insert the  >>>>   <<<<  marks themselves.)
-------------------------------------------------------------------------------

VOID usrInit (startType)
    int startType;

    {
    ...

    /* start the kernel specifying usrRoot as the root task */

>>>>									<<<<
>>>>sprFix1272 (usrRoot, ROOT_STACK_SIZE, FREE_RAM_ADRS, sysMemTop (),  <<<<
>>>>		ISR_STACK_SIZE, INT_LOCK_LEVEL);			<<<<

    kernelInit (usrRoot, ROOT_STACK_SIZE, FREE_RAM_ADRS, sysMemTop (),
		ISR_STACK_SIZE, INT_LOCK_LEVEL);
    }

==============End of README file for the kernelInit patch======================

/*******************************************************************************
*
* sprFix1272 - fix SPR #1272
*
* This routine will zero an unitialized stack variable used by kernelInit().
* It achieves this by mimicking the kernelInit () stack frame and zeroing the
* variable in question.
*
* This patch is necessary for the versions 5.0.2, 5.0.2b, 5.0.3, and 5.0.4 on
* the architecture families of 68k, 683xx, SPARC, and TRON.
*
* This patch is not necessary for the architectures of 68040, 960, or MIPS.
*
* CAVEAT
* This patch must be compiled with the same compiler switches and optimization
* level as was shipped with the original Makefile.
*
* ARGSUSED
* NOMANUAL
*/

sprFix1272 (rtn, size1, base1, base2, size2, level)
    FUNCPTR     rtn;
    unsigned    size1;
    char *      base1;
    char *      base2;
    unsigned    size2;
    int         level;

    {
    WIND_TCB	tcb;
    WIND_TCB *	pTcb;
    unsigned	lsize;
    char *	lbase1;
    char *	lbase2;

    bzero ((char *) &tcb, sizeof (WIND_TCB));
    }

From litwin@robotics.jpl.nasa.gov  Wed Jan 15 13:41:53 1992
From: litwin@robotics.jpl.nasa.gov (Todd Litwin)
Date: Wed Jan 15 13:42:00 PST 1992
Subject: TCP/IP timeouts
I know that this issue has been brought up before, but I want to ask a very
specific question that I don't think has been covered. We are using TCP/IP
both over ethernet and over a SLIP channel. If one of the channels is
disconnected, then my socket times out after somewhere between 5 and 10
minutes. What I want to do is to reduce this to some reasonable minimum,
such as 1 minute or 30 seconds. From previous discussions, it seems that
the variables to set are probably one of

	tcp_maxidle
	tcp_keepidle
	tcp_maxintvl

but that changing these affects many things, and not just timeout. Does
anyone know how to manipulate these (or other) variables to adjust when
TCP/IP will timeout a socket? And what would the side effects be of doing
this?

Thanks.

 		Todd Litwin
 		Jet Propulsion Laboratory
 		(818) 354-5028
 		litwin@robotics.jpl.nasa.gov

From biocca@bevsun.bev.lbl.gov  Wed Jan 15 15:43:10 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Wed Jan 15 15:43:17 PST 1992
Subject: Connecting list to newsgroup

In article <1992Jan15.184722.26046@acsu.buffalo.edu> jones@acsu.buffalo.edu (Terry A. Jones) writes:
 
>       Any ideas when the exploder will be connected to the news group?
 
As soon as I get things working.  Perhaps a couple of weeks, depending on
workload..  Anyone have a robust program that collects news from a specific
newsgroup and puts it into a pipe or files or ...??  I picked up one from the 
new awhile back but it is buggy... 
 
Alan K Biocca
Exploder Maintainer

From dave@exlog.com  Thu Jan 16 06:20:56 1992
From: dave@exlog.com (Dave St.Clair)
Date: Thu Jan 16 06:21:02 PST 1992
Subject: Unsubscribe me
Please unsubscribe me from the exploder since
I get USENET (comp.os.vxworks).

dave st.clair

From prb@aplexus.jhuapl.edu  Thu Jan 16 08:11:02 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Thu Jan 16 08:11:09 PST 1992
Subject: Re: kernelInit patch, as promised

Francis St. Amant wrote:

>I hope this solves the 165 booting problems. 

>This patch applies to Wind River Systems' VxWorks versions 5.0.2, 5.0.2b,
5.0.3, and 5.0.4 on the architecture families of 68k, 683xx, SPARC, and TRON.
This patch is not necessary for the architectures of 68040, 960, or MIPS.

I am confused. The 165 board has a 68040. I will soon be using
MVME-165 and MVME-167 boards. I assume I need the patch?

		Paul Bade

From biocca@bevsun.bev.lbl.gov  Thu Jan 16 08:25:29 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Thu Jan 16 08:25:35 PST 1992
Subject: Re:  Unsubscribe me
Two comments about unsubscribing from the exploder due to the availability of
comp.os.vxworks:

1.  Please wait until they are cross-connected (perhaps two weeks).

2.  Please don't send these requests through the exploder -- there are
    separate addresses at the end of each exploder message that give the
    correct addresses for administrative requests.

Thanks,

Alan K Biocca
Exploder Maintainer

From sky!copeland@uunet.uu.net  Thu Jan 16 08:46:03 1992
From: sky!copeland@uunet.uu.net (Darrell Copeland )
Date: Thu Jan 16 08:46:10 PST 1992
Subject: Unsubscribe me

From francis@wrs.com  Thu Jan 16 11:21:48 1992
From: francis@wrs.com (Francis St. Amant)
Date: Thu Jan 16 11:21:53 PST 1992
Subject: Re: kernelInit patch and 68040
I wrote:

> >I hope this solves the 165 booting problems. 
> 
and then later in the patch itself:

> >This patch applies to Wind River Systems' VxWorks versions 5.0.2, 5.0.2b,
> 5.0.3, and 5.0.4 on the architecture families of 68k, 683xx, SPARC, and TRON.
> This patch is not necessary for the architectures of 68040, 960, or MIPS.
> 
And Paul Bade writes:

> I am confused. The 165 board has a 68040. I will soon be using
> MVME-165 and MVME-167 boards. I assume I need the patch?
> 

I apologize for the momentary confusion.  This fix had been suggested by
a user as potential help for the 165 booting problem.  The main text of
that message was a patch for kernelInit.

I thus hastened to put up the "official" WRS patch, so WRS could more
easily support customers, as they'd all have our version of it.  My
thanks to Emmanuel Fleishman for graciously providing essentially the
same fix.  I'm simply trying to standardize this as much as possible
for ease of supporting you all.

In rushing to focus on the patch/support issue, I overlooked the fact that
this had started out as a discussion of mv165 booting, to which this
patch doesn't apply.  We're dealing directly with LBL on their booting
problems.  It's possible that the issue is simply LBL having an early
beta release.  We'll soon find out.

So once again, sorry for any confusion generated.  The patch and the mv165
booting are separate issues; their lifelines in "information space"
momentarily intersected on the exploder, and hopefully they will now
cleanly diverge.

------------------------------------------------------------------------------
  Francis St. Amant             |       800-872-4977 / FAX 510-814-2010
  Director of Customer Services |       510-814-2165 bbs
  Wind River Systems            |       1010 Atlantic Avenue
  francis@wrs.com               |       Alameda, California, 94501 USA
------------------------------------------------------------------------------

From MCGREGR@bnr.ca  Thu Jan 16 13:08:03 1992
From: Andrew (A.J.) McGregor <MCGREGR@bnr.ca>
Date: Thu Jan 16 13:08:11 PST 1992
Subject:    Re: kernelInit patch, as promised
I am suprised that the patch is not required for the 960 as I
had similar problems (which I fixed by zeroing the memory).

How sure are you of this, or was it rolled into the latest 960
release?

        Regards,
             Andrew.

Andrew McGregor (MCGREGR@BNR.CA)	Phone:	(613) 763-7236
Bell-Northern Research		
P.O. Box 3511, Station C, Ottawa, Ontario, Canada, K1Y 4H7

From hill@luke.atdiv.lanl.gov  Fri Jan 17 08:19:11 1992
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Fri Jan 17 08:19:18 PST 1992
Subject: Re:  TCP/IP timeouts
I solved this problem by periodically sending a noop message over the 
TCP/IP connection. Please send me a copy of any interesting responses 
to your message.

Jeff

From biocca@bevsun.bev.lbl.gov  Fri Jan 17 12:38:36 1992
From: randyw@theopolis.orl.mmc.com (Randy Walker)
Date: Fri Jan 17 12:38:43 PST 1992
Subject: targeting custom boards

Our team recently targeted VxWorks to a SPARC based processing board 
which was designed in-house. We ran into problems while integrating
an Ethernet driver. We needed information about the VxWorks network
communication layers of software so that we could interface our software.

We experienced great difficulty in getting support from Wind River.
It seems that their customer support organization was either not capable
or not willing to answer questions of this sort.

Finally, Wind River told us that they would not support the targeting of
VxWorks to custom hardware through their normal customer service. We 
were told that we had three options:

1.  We could buy their source code.  ( no guarantees of support )

2.  We could pay for a Wind River consultant to come to our site and
    help us.

3.  We could pay Wind River to write custom software for us.

I am curious about other groups' experiences in targeting VxWorks to
custom hardware. Also, do other groups expect to try this in the future?
If enough pressure is applied to Wind River, maybe they will be more
flexible in the future. Sales can be won and lost over supporting a
customer's needs.

From sjk@emerald.labs.tek.com  Fri Jan 17 16:06:18 1992
From: Steven King (503) 627-2736 <sjk@emerald.labs.tek.com>
Date: Fri Jan 17 16:06:26 PST 1992
Subject: NFS Server for VxWorks

Does anyone have a publicly available (or cheap) NFS Server ported
to VxWorks?

Steven

----------------------------------------------------------------------
e-mail: sjk@crl.labs.tek.com    Steven King
phone: 503-627-2736             Computer Research Lab, Tektronix, Inc.
voice mail: 503-727-6651        P.O. Box 500  MS 50-662
fax: 503-627-5502               Beaverton, OR  97077
----------------------------------------------------------------------

From visicom!VisiCom.COM!trest@nosc.mil  Fri Jan 17 16:10:56 1992
From: Mike Trest <trest@visicom.com>
Date: Fri Jan 17 16:11:03 PST 1992
Subject: Re:  targeting custom boards

>>I am curious about other groups' experiences in targeting VxWorks to
>>custom hardware.

VisiCom Labs has "targeted" VxWorks to several OEM boards including
three NON-VME custom boards.  We have a team of 40 VxWorks programmers
10 of whom are board level GURU types. 

Our decision to do custom work is done on a case-by-case basis.  Some
ports have taken only 4 days (a recent 68040) effort.  Others have taken
several weeks.  We are presently working on custom 68302 and 68340 jobs.

We usually do custom work because (1) we need it for ourselves, (2)
one of our customers requests it or, (3) an OEM organization needs it
done faster than in-house staff can do it.

Our two years+ experience with WRS has been quite good.  Since we have
done 14 such "targeting" jobs, we have had a fruitful exchange at the
formal corporate level and at the more personal working level.  Perhaps
our friendly relationship is because we are contractor to several of
WRS's biggest customers and are a reseller of VxWorks ourselves.

Understand this.  There is no free lunch.  We have paid our share of
prices for licenses and annual maintenance contracts, and such (we have 
several full and half licenses present in our shop ... some ours ... 
some being customized awaiting delivery to the final customer).  We have 
also recprocated whenever asked for technical assistance, joint marketing 
opportunities, or BETA site testing of new software.  Having worked with 
the people in Customer Support myself, I understand what my money has
purchased and what it has not. 

Alas, like you, I would some times like to have the full sources. 
We cannot afford it.  But we get the job done by asking questions
carefully.  Having been involved, personally, in UNIX kernel support
and device driver writing for 15 years, I have found that the last
two years dealing with WRS has been quite pleasant (in comparision to
others who shall not be named).

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

From carl@umd5.umd.edu  Fri Jan 17 21:32:03 1992
From: Carl Symborski <carl@umd5.umd.edu>
Date: Fri Jan 17 21:32:09 PST 1992
Subject: re: targeting custom hardware

On Fri Jan 17, 1992 randyw@theopolis.orl.mmc.com (Randy Walker) writes:

> Our team recently targeted VxWorks to a SPARC based processing board 
> which was designed in-house. We ran into problems....
> . . .
> We experienced great difficulty in getting support from Wind River.
> . . .
> I am curious about other groups' experiences in targeting VxWorks to
> custom hardware. Also, do other groups expect to try this in the future?

I have personally managed the development of three VxWorks board support
packages last fall.  All of these were custom hardware designs with custom
interfaces, one with a VME interface.  Prior to starting we spent some time
trying to figure out how to go about doing this.  Like you we did not (and 
still don't) have sources for VxWorks.  Also like you, we experienced 
difficulty getting information on the work required.  

First off, I should point out that our targets were for the i960 and so we
bought our OS (Vx960) and support from Intel.  The Intel factory organization
*was* supportive of us but the main problem was that there was just no 
black and white documentation which Intel or WR could hand to us.  Since we
didn't deal directly with WR on this I can't comment on the WR support
organization.  So we studied the example BSPs in the config directory.
Asked careful questions.  Considered the answers.  Looked at the code
again.  Then repeat.  At one point I considered contacting one of those
contractor companies with WR experience you occasionally see here on the net.
But naaa, we were having to much fun!  

You may actually have to be concerned with three types of software.  A 
low level monitor (in our case NINDY), the board support package proper
(including backplane interfaces and the infamous sysLib), and the development
of network drivers for any custom hardware on your board (like T1 or whatever).
Oh and don't forget, you have to do this and debug virgin hardware at the
same time! ;->

Today it is my understanding that WR has a class on how to do the board support
package part.  Or maby this was from Sparta... don't remember but I'm sure
Mike will fill you in.  Can't say how good these would be. I also know that 
WR has developed a document which discusses how to develop a network driver.  
Not sure if this is officially released, but we got a copy through Intel. This
was very helpfull.  It also helped to read plain old BSD code to get an 
understanding of mbufs and what IP generally expects out of a piece of network
code. That is, if you are going to write a network driver.  Getting a copy of 
an example VxWorks network driver was also crucial.  Note that if you are just
porting an existing network driver to your hardware most likely all that is 
needed are sysLib changes.  My suggestion is to look at the hardware boards
represented with board support packages in your config directory.  Find one
which matches your actual hardware the best.  Then start your modifications
using that package.

I can relate to the problems you mention.  Seems that the "typical" Vx 
customer simply buys commercially available single board computers (Hurikon,
Cyclone, what ever) and uses the board support software which those vendors
supply.  It is probably not profitable for WR to have to train the few
of us who feel the need to roll our own.  No, this is not a justification,
its just the way it is.  Soooo, keep on calling them with questions.

Carl

From chinacat!nominil!linimon@cs.utexas.edu  Sat Jan 18 08:15:37 1992
From: linimon@nominil.lonestar.org (Mark Linimon)
Date: Sat Jan 18 08:15:49 PST 1992
Subject: re: targeting custom hardware
Basically there are three levels to porting vxWorks.

1. Porting to a new architecture.  You will find that the level of difficulty
will vary from medium to hard; however, it is my humble opinion that without
the sources, and a close working relationship (or parternship) with Wind River,
this is infeasible.

2. Porting to a new variant of the same architecture (68040 vs 68030 or
68302 vs 68000).  Although this may seem to be easy, there can be subtle issues
involved, especially if one wants to take appropriate advantage of all the
features of the new architecture.  The above comments apply.

3. Porting to a new peripheral chipset.  It's most likely that you only need
some sample driver code for these.  The gotchas mostly lurk in network drivers,
although serial and disk drivers have their fair share.  Prior Unix driver
experience will save you the steepest part of the learning curve.

4. Porting to a new board using the same architecture.  Given that you leave
out virtual memory and DMA (a common condition in many of the real-time VMEbus
board ports), this will be the easiest of the set, and can be learned without
source (although it's certainly helpful and will save head-scratching time).
The first one's hard, the second one's medium, and after that they get easy
(given that the comments in 3 also apply here).

5. Virtual memory and/or DMA?  Multiple masters on the same backplane?  New
floating point architecture?  I would recommend laying in a heavy stock of
Maalox and tranquilisers before starting.

These are all only my personal opinions, of course, but I can reassure you
that I've paid for them with personal experience.
-- 
Mark Linimon / Lonesome Dove Computing Services / Austin, Texas
{balkan,chinacat,uunet}!nominil!linimon  || " ...so you've got to pay attention,
linimon@nominil.lonestar.org             || ... a D-10 can be the death of you."

From iphasew!hwajin@uunet.uu.net  Sun Jan 19 15:37:47 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Sun Jan 19 15:37:54 PST 1992
Subject: VxWorks network drivers

WRS should have various technical documents regarding the network
drivers.  I have written a few while I was there, so I know they
should have it somewhere.  If you can't get them from WRS, you can
learn by reading freely available 4.3 BSD code which is available
various places (e.g. uunet.uu.net).  For an example of how a CMC
ENP-10 ethernet board driver can be written for 4.3 BSD based TCP/IP
such as VxWorks', you can read
"packages/bsd-sources/sys/tahoe/if/if_enp.c" available on uunet.  The
latest VxWorks also includes SunOS compatible routines such as
ether_attach(), do_protocol(), and copy_to_mbufs(), etc., which are
included in the post-Reno 4.3 BSD code on uunet in file
"packages/bsd-sources/sys/net/if_ethersubr.c".  As most have guessed,
VxWorks network driver uses essentially the same interfaces to the
upper level protocols via "struct ifnet" based interface.  There are,
however, a few notable differences between the UNIX and VxWorks
network drivers:

1. In VxWorks, network interrupt handlers do minimal amount of work at
interrupt level.  Pretty much all that happens inside the interrupt
handler routine is to queue a call to the routine that does the actual
work of handling the interrupt by calling netJobAdd().  netJobAdd()
queues a funtion pointer and arguments to a ring buffer queue which is
handled by the network task.  The network task dequeues the queued job
requests and carry out the request by issuing the calls at the task
level.  This minimizes the interrupt latency.  In contrast, UNIX
drivers may go as far as scheduling ipintr() and liberally lock out lower
level interrupts using spl routines.  VxWorks never locks out
interrupt levels; spl routines are implemented using semaphores.
VxWorks does not use schednetisr().  Task level routines call ipintr()
directly; interrupt level routines queue the call using netJobAdd().

2. The mbuf's are implemented a little differently in VxWorks.  The
driver writer needs to pay a bit more attention to on-board network devices
if he/she wants to use VxWorks mbuf clusters to avoid unnecessary
copying of data.  If local arbiter allows both CPU and network chip to
access the buffer memory without any special restriction, you can use 
mbuf clusters to initialize the buffer memory for the network device
and use cluster specific routines to share the same buffer between
the CPU and network chip.  You should be able to figure out how to
do this by reading "net/mbuf.h" and perhaps one of the drivers that
actually does this such as the LANCE driver or the backplane driver.
VxWorks mbuf clusters are implemented without any paged VM support, but
the code that implements it is available in "mbuf.h" so you should
be able make use of this if you want performance out of your drivers.

3. VxWorks lacks SunOS NIT or BSD packet filter style hooks to the
drivers, but includes support for "etherLib" style hooks to allow
access to the raw network data.  Driver writers who want to allow
etherHook support should add some code to output and input routines
of the driver that checks the existence of etherHook routines for
input and output.  If they exist a copy of the input or output data
should be sent to the hook routines.  Documentation for etherLib
explains this further.

--
Hwa-Jin Bae
Interphase West

From leonid@amil.co.il  Mon Jan 20 07:49:20 1992
From: leonid@amil.co.il (Leonid Rosenboim)
Date: Mon Jan 20 07:49:27 PST 1992
Subject: MMU Usage
Now that VxWorks runs on a couple of CPUs that have integral MMUs (e.g.
68030) it looks pretty interesting if the MMU can be exploited to
acheive some extent of memory protection scheme to improve overall
software reliability, and shorten development time.

I would like to hear your opinion and ideas on this subject, and even
more we would like to hear about people that really implemented any of
their ideas.

To start the discussion rolling, here are some ideas we here have come
up with:

1. Text Write Protection

Protect the portions of memory that contain program text from
accidental corruption by part of the program - identify portions of
memory that contain text and protect them read-only. Alternatively
prellocate a portion of memory for text and make sure to load text into
that part and write protect it after load finished.

2. Stack Overflow Protection

Any scheme that can guarantee a bus error (or other trap) in case a
task's stack pointer has exceeded the stack's allocated space, to
prevent accidental curruption of unrelated data areas, and help
identify tasks which have a wrong stack size.

3. Hardware Breakpoints

A feature most ICEs provide - stop task execution (Suspend Task) on
attempt to access (Read Wrote or Execute) a particular address or
address range.

4. Resource Manager

To protect all writable data items on a system from accidental
access/writing due to uninitialized pointers or other program error,
there should be some kind of central broker to pass through, like the
MacOS Resource Manager. This typically adds some overhead to program
portions that share data with other tasks.

-----

The 4th item is rather far-tetched I understand, but it looks promising
in the longer term. We are not planning to implement any of these yet,
but would like to know what other WRS users think about. Sure, WRS
developers' point of view is most welcome.

---------------------------------------------------------------------
| Leonid Rosenboim			Internet: leonid@amil.co.il |
| System Administrator			Fax:    +972-3498-078       |
| Applied Materials (Israel) LTD.	Voice:  +972-3499-573       |
|                                               +972-3498-201       |
---------------------------------------------------------------------

From mea@sparta.com  Mon Jan 20 09:07:52 1992
From: mea@sparta.com (Mike Anderson)
Date: Mon Jan 20 09:08:01 PST 1992
Subject: Re:  NFS Server for VxWorks
Greetings!

  There's a public domain NFS Server implementation called SOS (Steve's Own
Server, I believe) that runs on PCs using PC-NFS.  Its available from
the Simtel20 anonymous FTP archives in the UNIX-C directories.  It doesn't
target VxWorks directly, but it is source that should come close.

Good Luck and please send a working version to the user's group archives,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From PK5685%MAX.U.WASHINGTON.EDU@UWAVM.U.WASHINGTON.EDU  Mon Jan 20 09:58:09 1992
From: PK5685@MAX.U.WASHINGTON.EDU
Date: Mon Jan 20 09:58:17 PST 1992
Subject: VxWorks users' group

I'm interested in joining the VxWorks users' group -- What do I do?

Thanks for your help

--Jens Quistgaard
pk5685@max.u.washington.edu

From mea@sparta.com  Mon Jan 20 11:29:25 1992
From: mea@sparta.com (Mike Anderson)
Date: Mon Jan 20 11:29:32 PST 1992
Subject: Re:  MMU Usage
Greetings!

  All of the mentioned targets (with the possible exception of option 4)
seem interesting.  However, my question with regards to the use of MMUs
in real-time systems is "How much does it cost?".  This means not only
the $$ required to implement, but also the time hit on context switches,
memory accesses, etc. required for the MMU to do its thing.  If the MMU
can do these things in 10s of nanoseconds, then I'm all for it.  On the
other hand, if it takes 10s of microseconds, then I wonder.  My opinion
is that a late answer is a wrong answer.  

  I've also seen many e-mail messages from folks who are struggling with 
the SPARC 1E MMUs. These messages lead me to believe that MMUs could 
be more trouble than they're worth given the days of lost time 
trying to figure out how to get a board to even boot let alone run
with the MMU.  Granted, I'd love to have a mechanism that would protect 
my code against errant pointers, stack overflows, bad programmers and 
the like.  Who wouldn't if we can get it for free ;-).  I'd also be 
supportive of MMU support in VxWorks if I had a #define that would allow
me to turn it off for really time-critical applications.

  If it were my money, I'd rather see a good interprocessor communications
mechanism ala pSOS+M than an MMU implementation.  That would help me with
the 683XX, 68E030, i960 and few other CPUs as well.

So much for my $0.02

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From hmp@frc2.frc.ri.cmu.edu  Tue Jan 21 07:01:27 1992
From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
Date: Tue Jan 21 07:01:34 PST 1992
Subject: Fdtos and Fstod under 5.0.2

We've run into a situation here where an application being ported to
5.0.2 wants the OS to supply the symbols Fdtos and Fstod, which are
not there under 5.0.2. After some poking around, I've come up with some clues:

It seems that before the GNU cross-building tools became the default, i.e.
pre-5.0.2, a kernel build on a Sun3 would pull in the native libc.a
from the sun. This was specified in the Makefile by the HOST_LIB
macro, and the sun3's libc.a contains Fdtos and Fstod. 

In the new Makefile, you'll find HOST_LIB = $(HOST_LIB_MC68020)
but HOST_LIB_MC6802 is not defined anywhere that I can see. 
My guess is that WRS moved the C support functions into the main library
(all.a, perhaps) but forgot the modules Fdtos and Fstod.

Can anyone confirm this theory or blast it to pieces with the right
explanation? 

-Henning

Henning Pangels     |   hmp@frc2.frc.ri.cmu.edu   |      Field Robotics Center
Research Programmer |       (412) 268-7088        | Carnegie-Mellon University
------------------------------------------------------------------------------
			  The Door is a Jar

From kent@wrs.com  Tue Jan 21 12:15:48 1992
From: kent@wrs.com (Kent Long)
Date: Tue Jan 21 12:15:55 PST 1992
Subject: Re:  Fdtos and Fstod under 5.0.2
Hi, Folks -

 Henning M. Pangels writes:
 > 
 > We've run into a situation here where an application being ported to
 > 5.0.2 wants the OS to supply the symbols Fdtos and Fstod, which are
 > not there under 5.0.2.
 > 
 > It seems that before the GNU cross-building tools became the default, i.e.
 > pre-5.0.2, a kernel build on a Sun3 would pull in the native libc.a
 > from the sun. This was specified in the Makefile by the HOST_LIB
 > macro, and the sun3's libc.a contains Fdtos and Fstod. 

This is correct.  In all VxWorks that used the native Sun tools (including 
the Sun4-based cross-compiler), floating point functions were obtained by
linking with Sun libraries.  However, with 5.0.1 (the first Gnu tools 
version), this was no longer an option.  The floating point library calls
generated by gcc are completely different than those from the Sun native
compiler.  So, a completely new floating point library was included with
VxWorks.  This library should provide a full set of subroutines for gcc-
compiled code.

 > 
 > My guess is that WRS moved the C support functions into the main library
 > (all.a, perhaps) but forgot the modules Fdtos and Fstod.

Well, these names appear to be Sun floating point routines, not gcc style.
(Corresponding gcc names might be "truncdfsf2" and "extendsfdf2".)  From
this, I would assume that the code has not been recompiled under gcc.

There are two options:

    1.  Recompile the code using gcc.  This would be my first choice, since
        it eliminates any reliance on the now-obsolete Sun libraries, and in
        the long run will make maintenance more straight forward.

    2.  Link the application modules with /usr/lib/libc.a directly on the
	Sun host, leaving a relocatable object.  That can then be loaded 
        or linked with VxWorks.

        This second alternative will also work for folks who want to use
        the Sun3 Fortran compiler, etc.

Good luck,

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com

From steele@telerobotics.jpl.nasa.gov  Tue Jan 21 15:11:29 1992
From: steele@telerobotics.jpl.nasa.gov (Rob Steele)
Date: Tue Jan 21 15:11:35 PST 1992
Subject: questions from JPl

We are using vxWorks on Heurkion 68020 boards in a VME chassis. We have
6 of the boards in the one chassis. Does anyone have an answere to one
or more of the following questions:

1. Is it possible to set our system up so we boot and execute downloads
   via a Bit-3 interface to our Sun4 instead of the Ethernet connection
   we are currently using.

2. Is there a known fix for the memory leakage problem when download a
   second image of an executable after the first one crashes.

3. (related to 2) Is there a software mechanism to reinitialize a board.

4. Does anyone have experiencing using an oscilloscope to perform timing
   estimates of software running on the Heurikon boards.

					Rob Steele
					steele@telerobotics.jpl.nasa.gov

From visicom!VisiCom.COM!trest@nosc.mil  Tue Jan 21 21:27:19 1992
From: Mike Trest <trest@visicom.com>
Date: Tue Jan 21 21:27:26 PST 1992
Subject: Re:  questions from JPl
Rob

>>2. Is there a known fix for the memory leakage problem when download a
>>   second image of an executable after the first one crashes.

I assume "memory" leakage is loss of memory occupied by first copy of
program when second ld < pgm.o is run.  We use several techniques:

A. Early on we used a unload command in which we chase the symbol table
  for the primary "txt" and "data" segments related and free them.  We
  had no really easy to chase all variables in the symbol table as well.

B. Today we use a wrapper around the loadModuleAt command and load NO
  symbols, only GLOBAL symbols, or ALL symbols depending on the task.
  We continue to unload the "txt" and "data" via the original symbol
  table lookup and free approach.

>>3. (related to 2) Is there a software mechanism to reinitialize a board.

I do not now use the Heurikon 020 boards you referenced.  But I do use
software to re-initialize boards from  Performance Technologies Inc,
FORCE, and MOTOROLA.  The technique varies but generally reboot(2) does
the trick for a complete reboot of the board via BOOT from ROM.

>>4. Does anyone have experiencing using an oscilloscope to perform timing
>>   estimates of software running on the Heurikon boards.

I have done this by inserting an otherwise un-needed movement of the
UART handshake line (DTR,RTS or the like) and probing at the external
serial interface pin.  I have also tied this line to Freq Counter
and to detect variations in averaged over longer periods than could 
be detected by a scope probe and a few samples.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com  Wed Jan 22 04:50:50 1992
From: Carl Lacy <lacy@draper.com>
Date: Wed Jan 22 04:50:58 PST 1992
Subject: Sparc 1E Comments

   Has anyone experience with Force's Sparc 1E processor?  We are thinking
of getting a few, initially using VxWorks or SunOS/1E, depending on the
context.  There is some fuzzyness in Force's literature about whether the
VxWorks port is planned or real.

From visicom!VisiCom.COM!trest@nosc.mil  Wed Jan 22 08:11:25 1992
From: Mike Trest <trest@visicom.com>
Date: Wed Jan 22 08:11:31 PST 1992
Subject: Re:  Sparc 1E Comments
I have used the Force Sparc processor under VxWorks and recommend
them highly to my customers.  Earlier, version 5.0.x was not available
for it.  It is now available.

..mike..

From mea@sparta.com  Wed Jan 22 08:21:49 1992
From: mea@sparta.com (Mike Anderson)
Date: Wed Jan 22 08:21:58 PST 1992
Subject: Re:  Sparc 1E Comments
Greetings!

  I'm not sure of other folks experiences with the SPARC 1E boards, but I've
had a very lukewarm response to the SPARC 1E.  First, the ones I've used
where from Sun not from Force, but I understand that they're essentially
the same board.  Second, although they seem to run SunOS fine, I've been
collecting all of the mail from folks using the 1E for VxWorks, and as
a VxWorks platform the 1E apparently leaves much to be desired.

  A few points that have come up:

   --  The 1E is locked at bus grant level 3.  This means that more than
       3-4 boards in a backplane that are heavy users of the bus pose
       an arbitration problem leading to bus errors, failure of the cards
       down the daisy chain to boot and a whole host of other bugs.  
       Remember that the 1E was designed to be the only processor on the
       backplane (i.e., multi-CPU systems were not on Sun's mind when they
       built the card).  However, I am hopeful that Force's SPARC 2E board
       will be designed to better allow for multi-processing (although this
       might conflict with Sun's 600MP processor line and Sun might 
       therefore require Force to produce a hobbled card so as not to 
       compete with this new line).

   --  The bus speeds of the 1E are dismally slow.  32-bit transfers are
       rated at about 6MB/s.  8-bit transfers are less than 2 MB/s.  Since
       the speed of multi-processor systems is largely limited by the slowest
       board on the bus, it would seem to me that a 1E represents a
       significant bottleneck in the system.

   --  Many users seem to be having lots of trouble with the 1E MMU under
       VxWorks.  I've got a dozen messages from people struggling to deal
       with the 1E MMUs just to get the boards to boot.  Also, I'm not sure
       whether the on-board SBUS slot is a plus or a minus.  My experience
       with adding Sun's 64MB RAM card through this interface was not
       pleasant.  The lack of a VSB interface also limits the board's
       ability for high-speed CPU<->CPU transfers.

   --  Of course, if the goal of the 1E board is simply to run SunOS to
       boot boards from and to provide disk service, then I would also 
       suggest a different course of action.  Running a UNIX CPU with
       such a slow bus interface in a real-time (i.e., ideally, deterministic)
       backplane seems to be a contradiction in terms.  I would instead
       suggest a setup similar to AP Labs' VxWorks box where a SPARC 2
       motherboard in mounted inside the chassis to provide the user
       interface and disks but kept off of the VMEBus.  Or, you could also
       buy the OPUS Systems OPUSEngine SPARC motherboard and use that
       if you didn't want to buy a Sun SPARCStation and gut the box.  I
       have seen several vendors using this approach.

   --  Finally, there is the cost of the SPARC 1E.  My Sun reseller's guide
       still shows the 1E price at $9,000 each minimum quantity 3.  Now
       there is an OEM discount associated with the board and you might be
       able to purchase them in quantities less than 3 from Force, but
       the bottom line is that these boards are still expensive when
       compared to 68Ks or i960s.  Even more so when you consider that
       you're paying 25-50% more for a 12 MIP 1E than you're paying for
       a 20 MIP SPARCStation ELC and with the ELC you're getting a monitor
       keyboard and mouse as well.

   --  Don't get me wrong.  I applaud WRS for porting VxWorks to the SPARC
       environment.  I think that it might be a neat idea, for instance, 
       to be able to run VxWorks as the native O/S on a SPARCStation 2
       workstation.  Coupled with WindX or Visicom's X-Windows solutions
       you'd have an incredible single user data acquisition station with
       a nice interactive display capability.  Alternatively, if the
       SPARC manufacturers (Force, Ironics and Mizar to date) could come
       up with a good VME implementation targeted at real-time, multi-
       processing systems at a reasonable price, I'd be happy to 
       incorporate them into both my company's and my customer's designs.

  In short, one can always hope that the new 2E will be better ;-).

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From kibrick@helios.ucsc.edu  Wed Jan 22 09:38:45 1992
From: "Bob Kibrick -- kibrick@helios.ucsc.edu" <kibrick@helios.ucsc.edu>
Date: Wed Jan 22 09:38:51 PST 1992
Subject: Re: Sparc 1E Comments 
The Sparc 1E from Force is interchangeable with that made by Sun.  We have
been running the identical vxWorks 4.0.2 and 5.0.2b on Sparc 1E's made by
both Force and Sun and find no differences.

Bob Kibrick
UCO/Lick Observatory
University of California
Santa Cruz, CA 95064
kibrick@helios.ucsc.edu

From diarra@borsu6.in2p3.fr  Wed Jan 22 09:59:00 1992
From: diarra@borsu6.lbl.gov (Christophe Vinima 399)
Date: Wed Jan 22 09:59:12 PST 1992
Hi !
Could you please add me to the VxWorks User's Group...

                    Christophe Diarra.
                    diarra@borsu6.in2p3.fr

=========================================================
           ####   ######  #    #  #####    ####
          #    #  #       ##   #  #    #  #    #
          #       #####   # #  #  #####   #
          #       #       #  # #  #    #  #  ###
          #    #  #       #   ##  #    #  #    #
           ####   ######  #    #  #####    ####    FRANCE

          Centre   
               d' Etudes   
                          Nucleaires   
                               de Bordeaux   
                                          Gradignan  
=========================================================
"Tout doit etre aussi simple que possible, pas seulement
plus simple"    A. Einstein
=========================================================
Christophe Diarra        Voice : +33 56891800
   C.E.N.B.G.            Fax   : +33 56751180
Le Haut Vigneau          Email : diarra@borsu6.in2p3.fr
33175 Gradignan cedex
FRANCE
=========================================================

From rasolofo@borsu6.in2p3.fr  Wed Jan 22 10:02:03 1992
From: rasolofo@borsu6.lbl.gov (Heriniaina Rasolofo)
Date: Wed Jan 22 10:02:10 PST 1992
Hi folks !

Please add me to the VxWorks User's Group.
Thanks.

            H. Rasolofo.
            rasolofo@borsu6.in2p3.fr

=========================================================
           ####   ######  #    #  #####    ####
          #    #  #       ##   #  #    #  #    #
          #       #####   # #  #  #####   #
          #       #       #  # #  #    #  #  ###
          #    #  #       #   ##  #    #  #    #
           ####   ######  #    #  #####    ####    FRANCE

          Centre   
               d' Etudes   
                          Nucleaires   
                               de Bordeaux   
                                          Gradignan  
=========================================================
"Tout doit etre aussi simple que possible, pas seulement
plus simple"    A. Einstein
=========================================================
Heriniaina Rasolofo      Voice : +33 56891800
   C.E.N.B.G.            Fax   : +33 56751180
Le Haut Vigneau          Email : rasolofo@borsu6.in2p3.fr
33175 Gradignan cedex
FRANCE
=========================================================

From stan@rti.com  Wed Jan 22 11:09:30 1992
From: stan@rti.com (Stan Schneider)
Date: Wed Jan 22 11:09:41 PST 1992
Subject: Re:  questions from JPl

steele@telerobotics.jpl.nasa.gov writes:
>>
>> 4. Does anyone have experiencing using an oscilloscope to perform timing
>>    estimates of software running on the Heurikon boards.
>> 
>> 
Depending on what you mean by "timing estimates", StethoScope's new "Profile"
module might be able to help you out.  It's out in beta test now; I could send
you an advance copy...   

A snippet from the man pages: 

DESCRIPTION
     Profile is a dynamic execution profiler for use with VxWorks
     and StethoScope.  It allows monitoring the execution flow of
     VxWorks programs on a procedure-by-procedure basis.  Profile
     allows a systems programmer to analyze exactly how a VxWorks
     program is utilizing the processor.

     Profile works by sampling the execution state (both  program
     counter  and  stack).   The sampling is done by an interrupt
     service routine.  These ``random'' samples are then analyzed
     by  a  low-priority  background task to determine which rou-
     tines were active at the time of the sample.

     The output of the analysis  procedure  is  used  to  keep  a
     dynamic  record of the system activity.  The output consists
     of a "frequency" for  each  routine.   Frequencies  are  the
     fraction  of  time  spent  in that routine, and are normally
     within the range 0.0 (never active) to 1.0 (always  active).
     Both current and cumulative frequencies are reported.

     The current frequencies of procedures may  be  installed  as
     signals to StethoScope, letting you watch how your system is
     using the  CPU  in  real-time.   Perhaps  more  importantly,
     StethoScope  may  be  used to monitor the profiler progress,
     detect conditions that would give  inaccurate  results,  and
     explore  the  system  reaction to events.  Together, Profile
     and StethoScope allow a much more accurate  picture  of  the
     system's activities than either could provide alone.

     Profile is designed for minimal impact on the real-time code
     it  analyzes.  No special compilation is required.  The sam-
     pling  is  quick  and  efficient.   The  analysis  uses  the
     resident  VxWorks symbol table to decide which procedure was
     active.  Profile can therefore be used  to  analyze  already
     running code.

...

I'll provide more details to anyone interested...

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From iphasew!hwajin@apple.com  Wed Jan 22 13:09:57 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Wed Jan 22 13:10:04 PST 1992
Subject: RE: Fdtos and Fstod under 5.0.2
>>>>> On Wed, 22 Jan 92 04:00:08 PST, Kent Long said:

Kent> Well, these names appear to be Sun floating point routines, not
Kent> gcc style.  (Corresponding gcc names might be "truncdfsf2" and
Kent> "extendsfdf2".)  From this, I would assume that the code has not
Kent> been recompiled under gcc.

Perhaps I'm missing something, but don't truncdfsf2 and extendsfdf2
come from gnulib.c ?  Since gnulib.c is supposed to be compiled with a
native C compiler when building gcc, they will reference native
library calls, namely Fdtos and Fstod.  I thought the whole point of
compiling gnulib.c with native compiler (e.g. Sun's) was to use the
routines in the native C library.  Since compiling gnulib.c with gcc
results in cyclic calls to the callers themselves, I assume that the
gcc distributed by WRS doesn't do this.  Which leads me to believe
that either WRS is providing their own replacement routines for the
Sun routines, or require linking with Sun's libc.a, or WRS is
providing their own replacement for gnulib routines.  I'm curious
because it *is* possible for gcc compiled code to reference routines
from native libc.a.  Anyone care to enlighten me?

From srm%matrx@mcnc.org  Wed Jan 22 13:14:58 1992
From: srm@matrx.matrix.com (Steve Morris)
Date: Wed Jan 22 13:15:07 PST 1992
Subject: scsiLib and the CPU-1E (aka SPARC-1E)

Does VxWorks 5.0.2b for the CPU-1E support (on-board) SCSI
via scsiLib ?

Has anyone used it?

Thanks,
Steve

From hali@interactive.com  Wed Jan 22 18:11:06 1992
From: hali@interactive.com (Hali Lindbloom)
Date: Wed Jan 22 18:11:13 PST 1992
Subject: .profile file
Has anyone else experienced the following problem and/or has
any insight into it:

When we create a .profile file in the home directory of the user
as which our board is logging into the host, the board can no
longer boot properly.  It reports a bus error after partially
loading VxWorks.

The only thing in the .profile is the setting and exporting of
environment variables.

I know that a .cshrc can mess up a board's booting if it causes any
standard output, but this seems like something else.

Thanks for any help!

	Hali Lindbloom
   Interactive Network
   (415) 903-4052
   hali@interactive.com

From thor@surt.atd.ucar.edu  Thu Jan 23 07:12:53 1992
From: thor@surt.atd.ucar.edu (Richard Neitzel)
Date: Thu Jan 23 07:13:00 PST 1992
Subject: Tp41V & VME addresses
We've got a Tadpole TP41V under 5.0.2. Unfortunately, we cannot make
it access any off board addresses. I know about the 3 paging bits, but
they don't seem to have any effect. I have 2 boards, one at 0x20000000
& one at 0x2000000. According to what we understand, they should
therefore be addressed by the TP41 as 0xa0000000 and 0xa2000000
respectively. The paging bits should then be 0x1 for the first board &
0x0 for the second. However, cycling through all 8 posssible cases
makes no difference. Are there other CIO bits that must be changed
before this can work? What are we doing wrong?

Richard Neitzel thor@thor.atd.ucar.edu	     	Torren med sitt skjegg
National Center For Atmospheric Research	lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000			Gjo'i med sitt shinn
303-497-2057					jagar borni inn.

From visicom!VisiCom.COM!trest@nosc.mil  Thu Jan 23 11:11:10 1992
From: Mike Trest <trest@visicom.com>
Date: Thu Jan 23 11:11:17 PST 1992
Subject: Re:  Tp41V & VME addresses
Richard:

>>We've got a Tadpole TP41V under 5.0.2. Unfortunately, we cannot make
>>it access any off board addresses.

The TP41-V with our VX-SERVER references the video frame buffer off
card  with no difficulty.  We also have mixed TP41-V and FORCE cpu
cards in the same chassis talking.  We did re-compile the distribution
vxWorks to add envoronmental variables used by the server, otherwise
nothing exotic.  The video card is in STD address space so all
references off the TP41 must be adjusted with sysBusToLocalAdrs();
The server has a line like this buried in the device dependent
portion which determines the TP41's address for the frame buffer
as:
	char *fb;
	...
	sysBusToLocalAdrs(VME_AM_STD_USR_DATA,videoVmeAddr,&fb);
	...
	return( fb );

ONE WAY TO KNOW FOR SURE is to do something like the following on each card:

	whereOnBus(localAddress)
	char *localAddress;
	{
		char *onBusAt;

		if (sysLocalToBusAdrs( VME_AM_EXT_SUP_DATA,
				localAddress,&onBusAt) == OK)
			printf("LocalAddress 0x%x   on VME 0x%x\n",
				localAddress,onBusAt);
		else	printf("ERROR!\n");
	}

This will tell you the TP41's opinion of his own address on the
bus.  Card 1 should use card 2's address (and vice-versa).

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

From biocca@bevsun.bev.lbl.gov  Thu Jan 23 11:26:00 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Thu Jan 23 11:26:07 PST 1992
Subject: contract consultant needed

Jeff Gold at United Source Services is looking for a Diagnostic Software
Engineer.  The six month contract with a Sunnyvale firm to develop ASIC/VLSI
diagnostic software in the Sun workstation/vxWorks environment in C
requires working with hardware engineers, writing test specifications, etc.
Contact Jeff at 818-991-2277.

I have no connection with these firms.

Alan K Biocca

From brancato@hercules.calspan.com  Thu Jan 23 12:32:21 1992
From: brancato@hercules.calspan.com (Tony Brancato)
Date: Thu Jan 23 12:32:28 PST 1992
Subject: VME to GPIB interface boards under VxWorks 5.0
Does anyone have experiences with VME-to-GPIB interface boards that they
would mind sharing?  We are building an RF simulation system and are
using an HP8902A measuring receiver and an HP voltmeter to perform
diagnostics and calibration.  We'd like to write software to control the
voltmeter and measuring receiver from the main CPU over the GPIB.  The
system is built around a Motorola M147 VME CPU board running VxWorks 5.0
(as part of VADS 2.0.1c).

We have looked at an interface board from American Eltec, and found that
their driver would not arbitrate service requests from the GPIB.
Specifically, if a command was sent which caused a service request and
the controller attempted to talk to the requesting node before the
request was handled, the driver would hang because the requesting node
would never respond.  Is this normal for these types of boards, or do
other drivers detect and handle this condition?

We also have the driver for the MZ7500 board from Mizar, but have not
had a chance to look at it yet.  

Any suggestions, impressions, or past experiences about quality of
product and support are appreciated.  Thanks in advance.

-- 
Tony Brancato
Calspan Corporation ATC  Buffalo, NY
...!uupsi!calspan!brancato
brancato@calspan.com

From bobf@verdix.com  Thu Jan 23 12:39:49 1992
From: Bob Foery <bobf@verdix.com>
Date: Thu Jan 23 12:39:55 PST 1992
Subject: Re: contract consultant needed 
> Jeff Gold at United Source Services is looking for a Diagnostic Software
> Engineer.  The six month contract with a Sunnyvale firm to develop ASIC/VLSI
                                                                       
               ^^^^^^^^^^^^^^^^^^

> diagnostic software in the Sun workstation/vxWorks environment in C
> requires working with hardware engineers, writing test specifications, etc.
> Contact Jeff at 818-991-2277.

Sounds pretty neat, eh?

From kadionik@borsu6.in2p3.fr  Thu Jan 23 13:39:57 1992
From: kadionik@borsu6.lbl.gov (Patrice Kadionik)
Date: Thu Jan 23 13:40:05 PST 1992
Subject: Love
Love is a wondering feeling...

From hmp@frc2.frc.ri.cmu.edu  Thu Jan 23 14:56:23 1992
From: "Henning M. Pangels" <hmp@frc2.frc.ri.cmu.edu>
Date: Thu Jan 23 14:56:32 PST 1992
Subject: Re: Love 

-- On Thu, 23 Jan 92 13:40:19 PST, you wrote:

>
>
>Submitted-by kadionik@borsu6.in2p3.fr  Thu Jan 23 13:39:57 1992
>Submitted-by: kadionik@borsu6.lbl.gov (Patrice Kadionik)
> 
>Love is a wondering feeling...

Ya, but is there a public domain package available for it?

:-)

Henning Pangels     |   hmp@frc2.frc.ri.cmu.edu   |      Field Robotics Center
Research Programmer |       (412) 268-7088        | Carnegie-Mellon University
------------------------------------------------------------------------------
		      It's later than you think

From scr@uk.ate.slb.com  Fri Jan 24 00:00:15 1992
From: scr@uk.ate.slb.com
Date: Fri Jan 24 00:03:40 PST 1992
Subject: Re:  VME to GPIB interface boards under VxWorks 5.0
> 
> Submitted-by brancato@hercules.calspan.com  Thu Jan 23 12:32:21 1992
> Submitted-by: brancato@hercules.calspan.com (Tony Brancato)
>  
> Does anyone have experiences with VME-to-GPIB interface boards that they
> would mind sharing?  .......

Tony,

Have you looked at National Instruments' product range. They have a number of
VME / IEEE interface cards.

Contact them at :-

	6504 Bridge Point Parkway
	Austin
	Texas 76730-5039

	Tel: (512) 794-0100
	Fax: (512) 794-8411

Stephen.

--------------------------------------------------------------------
Stephen Rothwell,                  | email :
Schlumberger Technologies,         | rothwell%ukfca1@sj.ate.slb.com
Ferndown Industrial Estate,        |
Wimborne,                          | phone :
Dorset, BH21 7PP                   | +44-202-893535
England.                           |
-------------------------------------------------------------------

From biocca@bevsun.bev.lbl.gov  Fri Jan 24 08:00:51 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Fri Jan 24 08:01:03 PST 1992
Subject: comp.os.vxworks articles

Comp.os.vxworks lives!  Here's the current article set (hand collected,
the exploder to news link is working in a test group at lbl, but the news to
exploder link isn't up yet...)

Alan K Biocca

From dog.ee.lbl.gov!pasteur!ames!elroy.jpl.nasa.gov!usc!wupost!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells Fri Jan 24 08:00:14 PST 1992
Article: 3 of comp.os.vxworks
Newsgroups: comp.realtime,comp.os.vxworks
Path: dog.ee.lbl.gov!pasteur!ames!elroy.jpl.nasa.gov!usc!wupost!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells
From: dwells@fits.cx.nrao.edu (Don Wells)
Subject: C++ class library for RT?
Message-ID: <DWELLS.92Jan15130206@fits.cx.nrao.edu>
Sender: news@nrao.edu
Organization: National Radio Astronomy Observatory, Charlottesville, VA
Distribution: comp
Date: Wed, 15 Jan 1992 18:02:06 GMT
Lines: 10
Xref: dog.ee.lbl.gov comp.realtime:1973 comp.os.vxworks:3

Is there a C++ class library for RT applications under some RT OS? 

In particular, is there such a thing for VxWorks?

--

Donald C. Wells             Associate Scientist        dwells@nrao.edu
National Radio Astronomy Observatory                   +1-804-296-0277
520 Edgemont Road                                 Fax= +1-804-296-0278
Charlottesville, Virginia 22903-2475 USA            78:31.1W, 38:02.2N 

From dog.ee.lbl.gov!overload.lbl.gov!agate!stanford.edu!rutgers!ub!acsu.buffalo.edu!usenet Fri Jan 24 08:00:16 PST 1992
Article: 2 of comp.os.vxworks
Path: dog.ee.lbl.gov!overload.lbl.gov!agate!stanford.edu!rutgers!ub!acsu.buffalo.edu!usenet
From: jones@acsu.buffalo.edu (Terry A. Jones)
Newsgroups: comp.os.vxworks
Subject: This is a test...
Message-ID: <1992Jan15.184722.26046@acsu.buffalo.edu>
Date: 15 Jan 92 18:47:22 GMT
Sender: usenet@acsu.buffalo.edu
Organization: State University of New York at Buffalo/Comp Sci
Lines: 7
Nntp-Posting-Host: cursa.cs.buffalo.edu

	This is a test....like the Subject line says.

	Any ideas when the exploder will be connected to the news group?

	Terry Jones

From dog.ee.lbl.gov!biocca Fri Jan 24 08:00:17 PST 1992
Article: 4 of comp.os.vxworks
Path: dog.ee.lbl.gov!biocca
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Newsgroups: comp.os.vxworks
Subject: Connecting list to newsgroup
Date: 15 Jan 1992 23:46:52 GMT
Organization: Lawrence Berkeley Laboratory, California
Lines: 11
Message-ID: <20658@dog.ee.lbl.gov>
References: <1992Jan15.184722.26046@acsu.buffalo.edu>
NNTP-Posting-Host: 131.243.192.12

In article <1992Jan15.184722.26046@acsu.buffalo.edu> jones@acsu.buffalo.edu (Terry A. Jones) writes:

>	Any ideas when the exploder will be connected to the news group?

As soon as I get things working.  Perhaps a couple of weeks, depending on
workload..  Anyone have a robust program that collects news from a specific
newsgroup and puts it into a pipe or files or ...??  I picked up one from the
new awhile back but it is buggy...

Alan K Biocca
Exploder Maintainer

From dog.ee.lbl.gov!network.ucsd.edu!pacbell.com!ames!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmail!randyw Fri Jan 24 08:00:19 PST 1992
Article: 5 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!pacbell.com!ames!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmail!randyw
From: randyw@iplmail.orl.mmc.com (Randy Walker)
Subject: targeting custom boards
Message-ID: <1992Jan15.213120.19694@iplmail.orl.mmc.com>
Keywords: SPARC, custom
Sender: randyw@iplmail (Randy Walker)
Organization: Martin Marietta
Date: Wed, 15 Jan 1992 21:31:20 GMT

Our team recently targeted VxWorks to a SPARC based processing board 
which was designed in-house. We ran into problems while integrating
an Ethernet driver. We needed information about the VxWorks network
communication layers of software so that we could interface our software.

We experienced great difficulty in getting support from Wind River.
It seems that their customer support organization was either not capable
or not willing to answer questions of this sort.

Finally, Wind River told us that they would not support the targeting of
VxWorks to custom hardware through their normal customer service. We 
were told that we had three options:

1.  We could buy their source code.  ( no guarantees of support )

2.  We could pay for a Wind River consultant to come to our site and
    help us.

3.  We could pay Wind River to write custom software for us.

I am curious about other groups' experiences in targeting VxWorks to
custom hardware. Also, do other groups expect to try this in the future?
If enough pressure is applied to Wind River, maybe they will be more
flexible in the future. Sales can be won and lost over supporting a
customer's needs.

From dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!uwm.edu!zazen!uwvax!meteor!scrap.ssec.wisc.edu!bt Fri Jan 24 08:00:20 PST 1992
Article: 8 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!uwm.edu!zazen!uwvax!meteor!scrap.ssec.wisc.edu!bt
From: bt@scrap.ssec.wisc.edu (Bill Taylor)
Subject: Re: targeting custom boards
Message-ID: <1992Jan16.170247.8042@meteor.wisc.edu>
Keywords: SPARC, custom
Sender: @meteor.wisc.edu
Organization: Space Science and Engineering Center, UW Madison
References:  <1992Jan15.213120.19694@iplmail.orl.mmc.com>
Date: Thu, 16 Jan 92 17:02:47 GMT

In article <1992Jan15.213120.19694@iplmail.orl.mmc.com>, randyw@iplmail.orl.mmc.com (Randy Walker) writes:
|> 
|> Our team recently targeted VxWorks to a SPARC based processing board 
|> which was designed in-house. We ran into problems while integrating
|> an Ethernet driver. We needed information about the VxWorks network
|> communication layers of software so that we could interface our software.
|> 
Unitl almost 2 years ago I worked for Heurikon. As a leading supplier
for VxWorks even we had problems like that. When Heurikon's Intel 960
board was new, They had to do most of the VxWorks work even though hardware for this was supplied to WindRiver.  Policy developed over time to support
their(Heurikon's) customer's inhouse after having each customer buy
a development kit with many sources to minimize support issues.
|> We experienced great difficulty in getting support from Wind River.
|> It seems that their customer support organization was either not capable
|> or not willing to answer questions of this sort.
|> 
I think they are stretched(or were) pretty thin like most people
in a growing market with a good product. I still think its a good product
for software development.
|> Finally, Wind River told us that they would not support the targeting of
|> VxWorks to custom hardware through their normal customer service. We 
|> were told that we had three options:
|> 
|> 1.  We could buy their source code.  ( no guarantees of support )
|> 
|> 2.  We could pay for a Wind River consultant to come to our site and
|>     help us.
|> 
|> 3.  We could pay Wind River to write custom software for us.
|> 
|> 
This is not a bad response. If you were designing a board for this application
you could have found out which ethernet chips set they support, and chosen
one. It may not have been "ideal", but it would have been cheaper in time and $.
|> 
|> I am curious about other groups' experiences in targeting VxWorks to
|> custom hardware. Also, do other groups expect to try this in the future?
|> If enough pressure is applied to Wind River, maybe they will be more
|> flexible in the future. Sales can be won and lost over supporting a
|> customer's needs.
Unfortunately they make BIG $$ on each customer from places like 
above mentioned firm, and Force, Sun, Mizar, etc...... The number of $$
generated from in house hardware is relatively small.
At least you could port the basic product. I once tried to get
Word Perfect for Heurikon's Unix Systems. The sales folks there said for less
than several million dollars they really couldn't be bothered.

Good luck.... Isn't engineering fun?

From dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!batcomputer!cornell!rochester!rocksanne!thingy!leisner Fri Jan 24 08:00:21 PST 1992
Article: 13 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!batcomputer!cornell!rochester!rocksanne!thingy!leisner
From: leisner@thingy.henr801@xerox.com (Marty Leisner x76704 siena)
Subject: Re: targeting custom boards
Message-ID: <1992Jan19.222735.15679@spectrum.xerox.com>
Keywords: SPARC, custom
Sender: news@spectrum.xerox.com
Organization: Xerox
References: <1992Jan15.213120.19694@iplmail.orl.mmc.com> <1992Jan16.170247.8042@meteor.wisc.edu>
Date: Sun, 19 Jan 1992 22:27:35 GMT

In article <1992Jan16.170247.8042@meteor.wisc.edu> bt@scrap.ssec.wisc.edu (Bill Taylor) writes:
>
>Good luck.... Isn't engineering fun?

Whoever said software is engineering?

marty leisner
leisner.henr801c@xerox.com

From dog.ee.lbl.gov!nosc!manta!psm Fri Jan 24 08:00:23 PST 1992
Article: 6 of comp.os.vxworks
Path: dog.ee.lbl.gov!nosc!manta!psm
From: psm@manta.NOSC.MIL (Scot Mcintosh)
Newsgroups: comp.os.vxworks
Subject: Rumor regarding Ada
Keywords: Ada, Verdix
Message-ID: <2615@manta.NOSC.MIL>
Date: 16 Jan 92 18:15:28 GMT
Organization: Naval Ocean Systems Center, San Diego
Lines: 11

I've heard a rumor that Verdix will no longer be offering an
Ada product that runs with vxWorks. Supposedly, they'll be
furnishing their own operating system. I've also heard that
Wind River is talking with Telesoft about furnishing Ada.
Anyone know the real story?

----
Scot McIntosh
Internet: psm@helios.nosc.mil
UUCP:     {ihnp4,akgua,decvax,decwest,ucbvax}!sdscvax!nosc!psm
"It's not a bug, it's a limitation" - Microsoft Tech Assistant

From dog.ee.lbl.gov!network.ucsd.edu!ames!elroy.jpl.nasa.gov!usc!rpi!zaphod.mps.ohio-state.edu!wupost!uunet!dove!dove.nist.gov!przemek Fri Jan 24 08:00:24 PST 1992
Article: 7 of comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!ames!elroy.jpl.nasa.gov!usc!rpi!zaphod.mps.ohio-state.edu!wupost!uunet!dove!dove.nist.gov!przemek
From: przemek@rrdstrad.nist.gov (Przemek Klosowski)
Newsgroups: comp.os.vxworks
Subject: VxWorks running VME experimental hardware
Message-ID: <PRZEMEK.92Jan16142006@rrdstrad.nist.gov>
Date: 16 Jan 92 19:20:06 GMT
Sender: news@dove.nist.gov
Organization: U. Notre Dame/NIST
Lines: 28

Hello!
We are currently considering moving from CAMAC crates controlled by VMS Vaxes
to VME hardware ran by in-crate controllers under VxWorks, interfaced with
Unix hardware (currently Ultrix, but this may change). Our application is
experimental data collection, so our VME modules are histogramming memories,
scalers, counters etc. I have couple of questions to you: 
 - Does VME look like a good choice for the task (we need the speed, but
   I have heard that controlling it is tricky)
 - How well does VxWorks support running the VME stuff? By looking through
   the manual I did not notice system calls dealing with VME transactions.
   How does one run a particular hardware device? do we need drivers from
   each VME module manufacturer? if yes, how easy is it to get a good quality
   drivers working under VxWorks? We were told that it might be the problem, 
   and that we might have to write the drivers ourselves. How hard is it to
   write a VxWorks device driver?
 - How tightly is the VxWorks tied to a particular development platform? is
   it conceivable to initially develop stuff from workstation A on target B 
   and then process the data collected by the standalone target over the network
   to various hosts C?

Thanks for the info. Please feel free either to post or to e-mail, and I'll 
summarize in a little while if there is sufficient response. Please also 
suggest some other appropriate newsgroups where those questions could be 
also appropriate.
--
			przemek klosowski (przemek@ndcvx.cc.nd.edu)
			Physics Department
			University of Notre Dame IN 46556

From dog.ee.lbl.gov!network.ucsd.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!THD-News!adams Fri Jan 24 08:00:25 PST 1992
Article: 10 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!THD-News!adams
From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams)
Subject: Re: VxWorks running VME experimental hardware
Sender: news@infoserver.th-darmstadt.de (The Usenet-News System)
Message-ID: <ADAMS.92Jan18022319@PDV2.pdv2.fmr.maschinenbau.th-darmstadt.de>
In-Reply-To: przemek@rrdstrad.nist.gov's message of 16 Jan 92 19: 20:06 GMT
Date: Sat, 18 Jan 1992 02:23:19 GMT
References: <PRZEMEK.92Jan16142006@rrdstrad.nist.gov>
Nntp-Posting-Host: pdv2.fmr.maschinenbau.th-darmstadt.de
Organization: TH-Darmstadt
Lines: 50

In article <PRZEMEK.92Jan16142006@rrdstrad.nist.gov> przemek@rrdstrad.nist.gov (Przemek Klosowski) writes:

>   Hello!
>   We are currently considering moving from CAMAC crates controlled by VMS Vaxes
>   to VME hardware ran by in-crate controllers under VxWorks, interfaced with
>   Unix hardware (currently Ultrix, but this may change). Our application is
>   experimental data collection, so our VME modules are histogramming memories,
>   scalers, counters etc. I have couple of questions to you: 

We run similiar tasks together with control tasks on VME-Bus hardware under
pSOS interfaced over shared memory with an Unix host (SysV68).

>    - Does VME look like a good choice for the task (we need the speed, but
>      I have heard that controlling it is tricky)

Other faculties and we run similiar setups successfully since years.
Nuclear Physics run their linear accelarator with VME-Bus harddware under
pSOS.
It is even comparable easy to build your own VME-Bus hardware, a
couple of companies offer interface chips etc. 

>    - How well does VxWorks support running the VME stuff? By looking through
>      the manual I did not notice system calls dealing with VME transactions.
>      How does one run a particular hardware device? do we need drivers from
>      each VME module manufacturer? if yes, how easy is it to get a good quality
>      drivers working under VxWorks? We were told that it might be the problem,      and that we might have to write the drivers ourselves. How hard is it to
>      write a VxWorks device driver?

We do not use VxWorks --- no glue.

All peripherals are seen memory mapped on the VME-Bus. No system calls
are necessary to initiate transcactions. Transactions (atomic
read/writes) should be handled properly by the hardware, lock via
BBUSY* - line. In the past, problems occured at this point.

Writing device drivers was never fancy stuff, but as the OS provides
signals, events and queues, it is not as hard as most will fear.
 	
>      - How tightly is the VxWorks tied to a particular development
>      platform? is it conceivable to initially develop stuff from
>      workstation A on target B and then process the data collected by
>      the standalone target over the network to various hosts C?

GNU-gdb 4.3 allows remote debugging of VxWorks targets.

Nuclear Physics run a setup comparable to that you described,
but under pSOS. It is a common setup.

best regards, adams

From dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!ispd-newsserver!psinntp!ptsys1!rcw Fri Jan 24 08:00:27 PST 1992
Article: 9 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!ispd-newsserver!psinntp!ptsys1!rcw
From: rcw@ptsys1.pt.com (Ray Ward)
Subject: Looking For General Info On VxWORKS
Message-ID: <1992Jan16.203702.477@pt.com>
Sender: rcw@pt.com (Ray Ward)
Organization: Performance Technologies, Incorporated
Date: Thu, 16 Jan 1992 20:37:02 GMT

We are close to finishing the port of OS-9 to our line of single board computers.
I am gathering information on doing a port of another operating system and am 
interested in VxWORKS.  Would anyone who has any experience, good or bad, with
VxWORKS please email me your experience(s).  Please send any replies to:

		rcw@ptsys1.pt.com

Thanks to all....

From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!cs.utexas.edu!uunet!fernwood!portal!exloghou!mcdowell Fri Jan 24 08:00:28 PST 1992
Article: 11 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!cs.utexas.edu!uunet!fernwood!portal!exloghou!mcdowell
From: mcdowell@exloghou.exlog.com (Steve McDowell)
Subject: Async Sockets
Message-ID: <1992Jan18.024429.19937@exlog.com>
Keywords: sockets, ipc, signals
Sender: mcdowell@exlog.com (Steve McDowell)
Organization: Exploration Logging, Inc.
Date: Sat, 18 Jan 92 02:44:29 GMT

Has anyone out there done any work in adding asyncronous
socket support for VxWorks? Is the signalling mechanism too 
terribly unreliable (any more than UN*X)? With this glaring 
exception, WRS seems to have delivered a pretty complete 
implementation of BSD sockets.......

-- 
Steve McDowell             . . . . o o o o o 		Opinions are 
Exlog, Inc.	                  _____      o     	mine, not my 
mcdowell@exlog.com      _____====  ]OO|_n_n__][.    	employers..
		       [_________]_|__|________)<   

From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!usc!elroy.jpl.nasa.gov!ncar!hsdndev!adm!afterlife!smb Fri Jan 24 08:00:29 PST 1992
Article: 15 of comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!usc!elroy.jpl.nasa.gov!ncar!hsdndev!adm!afterlife!smb
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Newsgroups: comp.os.vxworks
Subject: Re: Async Sockets
Keywords: sockets, ipc, signals
Message-ID: <1992Jan20.165631.18648@afterlife.ncsc.mil>
Date: 20 Jan 92 16:56:31 GMT
References: <1992Jan18.024429.19937@exlog.com>
Organization: The Great Beyond
Lines: 8

VxWorks does not support any asynchronous I/O.  However, AP Labs in San Diego,
who does quite a bit of VxWorks development and integration, offers an
asynchronous I/O library for VxWorks.  I have not done business with them
yet, but they seem to have a good reputation.
-- 

Steve M. Burinsky
smb@afterlife.ncsc.mil

From dog.ee.lbl.gov!network.ucsd.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!netnews-2.srv.cs.cmu.edu!dac Fri Jan 24 08:00:30 PST 1992
Article: 12 of comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!netnews-2.srv.cs.cmu.edu!dac
From: dac@frc.ri.cmu.edu (Daniel Christian)
Newsgroups: comp.os.vxworks
Subject: SunOs+VxWorks on same VME bus?
Message-ID: <DAC.92Jan19140914@locust.frc.ri.cmu.edu>
Date: 19 Jan 92 19:09:14 GMT
Reply-To: dac@ri.cmu.edu (Dan Christian)
Distribution: comp
Organization: Field Robotic Center, CMU
Lines: 16
Nntp-Posting-Host: locust.frc.ri.cmu.edu

Does anyone have experience with running SunOs (on a SparcEngine xx)
and real-time processors (68K, Sparc, i960) under VxWorks on the same
VME bus?

I have seen split bus setups that use still use ethernet to
communicate; but I want to avoid TCP bottle necks.

I know people were working on this, but I never found out if a
workable system has been produced yet.

Thanks,
-Dan Christian
--
___________________________________________________________________________
Dan Christian		Field Robotics Center	Carnegie Mellon University
			(412) 268-6562		dac@ri.cmu.edu

From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!news.cs.indiana.edu!lynx!chama.eece.unm.edu!ele Fri Jan 24 08:00:31 PST 1992
Article: 14 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!news.cs.indiana.edu!lynx!chama.eece.unm.edu!ele
From: ele@chama.eece.unm.edu (Erik L. Ellis)
Subject: Request for advice on error message
Message-ID: <=1mg-xn@lynx.unm.edu>
Date: Mon, 20 Jan 92 04:45:04 GMT
Organization: University of New Mexico, Albuquerque
Keywords: error messages
Lines: 43

SYSTEM DESCRIPTION:
I am running VxWorks on a Force CPU30 board which is controlling
a Datacube image processing board (MaxVideo20).  I am developing
code on a Sun3 and porting the object code to the CPU30.

THE PROBLEM:
My program will run just fine until I attempt to exit the program.
At this point, the system crashes with the message.

workQPanic: Kernel work queue overflow.

To get things working again, it's not enough to reboot.  I actually
have to power down the VME bus and restart.

HELP REQUEST:
As you may have guessed by the question, I am fairly new to VxWorks
(and Datacube and Force hardware/software for that matter).  I havn't
been able to find much in the documentation to guide me.  Any 
suggestions would be appreciated.

Here is the end of my code (where the crash occurs).

	printf("type [Return] to freeze:\n");
	getchar();
	dqHaltPipe(oAcqPipe);
	printf("type [Return] to end program:\n");
	getchar();

	dqDisposeSys(oSystem);
}

The 1st printf works fine, but we never get to the 2nd one.
The obvious guess is that something screws up in trying
to halt the Acquisition Pipe.  (dqHaltPipe is an
ImageFlow/Datacube command, and, you guessed it, Datacube 
does not officially support VxWorks environments).

Any idea what's going on?

- Erik L. Ellis
  Dept. of EECE
  Univ. of New Mexico
  Albuquerque, NM

From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!spool.mu.edu!umn.edu!src.honeywell.com!whillock Fri Jan 24 08:00:33 PST 1992
Article: 16 of comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!spool.mu.edu!umn.edu!src.honeywell.com!whillock
From: whillock@src.honeywell.com (Rand Whillock)
Newsgroups: comp.os.vxworks
Subject: Re: Request for advice on error message
Keywords: error messages
Message-ID: <1992Jan21.163029.26957@src.honeywell.com>
Date: 21 Jan 92 16:30:29 GMT
Article-I.D.: src.1992Jan21.163029.26957
References: <=1mg-xn@lynx.unm.edu>
Sender: news@src.honeywell.com (News interface)
Organization: Honeywell Systems & Research Center
Lines: 34
Nntp-Posting-Host: dienbienphu.src.honeywell.com

In article <=1mg-xn@lynx.unm.edu> ele@chama.eece.unm.edu (Erik L. Ellis) writes:
>SYSTEM DESCRIPTION:
>I am running VxWorks on a Force CPU30 board which is controlling
>a Datacube image processing board (MaxVideo20).  I am developing
>code on a Sun3 and porting the object code to the CPU30.
>
>THE PROBLEM:
>My program will run just fine until I attempt to exit the program.
>At this point, the system crashes with the message.
>
>workQPanic: Kernel work queue overflow.
>
    ...
>
>Any idea what's going on?
>
>- Erik L. Ellis
>  Dept. of EECE
>  Univ. of New Mexico
>  Albuquerque, NM

We have had a similar problem with our system running VxWorks on a MVME147 CPU
with a Datacube Max20 in the system.  We also had to power down to reset the
boards.  The problem went away when we installed the 5.0.2b bug fix sent out
by Wind River. 

					  Good Luck,

-- 
Rand Paul Whillock                     Phone: 612-782-7654
Signal Processing Systems              Fax  : 612-782-7438
Systems and Control Sciences           Net  : whillock@src.honeywell.com

From dog.ee.lbl.gov!nosc!network.ucsd.edu!sdd.hp.com!wupost!uwm.edu!rutgers!ub!galileo.cc.rochester.edu!rochester!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!netnews.srv.cs.cmu.edu!hmp Fri Jan 24 08:00:35 PST 1992
Article: 17 of comp.os.vxworks
Path: dog.ee.lbl.gov!nosc!network.ucsd.edu!sdd.hp.com!wupost!uwm.edu!rutgers!ub!galileo.cc.rochester.edu!rochester!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!netnews.srv.cs.cmu.edu!hmp
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Newsgroups: comp.os.vxworks
Subject: Fdtos and Fstod under 5.0.2
Message-ID: <HMP.92Jan21100009@deimos.frc.ri.cmu.edu>
Date: 21 Jan 92 15:00:09 GMT
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Lines: 25
Nntp-Posting-Host: deimos.frc.ri.cmu.edu

We've run into a situation here where an application being ported to
5.0.2 wants the OS to supply the symbols Fdtos and Fstod, which are
not there under 5.0.2. After some poking around, I've come up with some clues:

It seems that before the GNU cross-building tools became the default, i.e.
pre-5.0.2, a kernel build on a Sun3 would pull in the native libc.a
from the sun. This was specified in the Makefile by the HOST_LIB
macro, and the sun3's libc.a contains Fdtos and Fstod. 

In the new Makefile, you'll find HOST_LIB = $(HOST_LIB_MC68020)
but HOST_LIB_MC6802 is not defined anywhere that I can see. 
My guess is that WRS moved the C support functions into the main library
(all.a, perhaps) but forgot the modules Fdtos and Fstod.

Can anyone confirm this theory or blast it to pieces with the right
explanation? 

-Henning

--
Henning Pangels     |   hmp@frc2.frc.ri.cmu.edu   |      Field Robotics Center
Research Programmer |       (412) 268-7088        | Carnegie-Mellon University
------------------------------------------------------------------------------
			  The Door is a Jar

From dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes Fri Jan 24 08:00:36 PST 1992
Article: 18 of comp.os.vxworks
Path: dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes
From: heyes@dadev.cebaf.gov (Graham Heyes)
Newsgroups: comp.os.vxworks
Subject: Age old 800k vs 1400k problem...
Message-ID: <1992Jan21.182100.29996@murdoch.acc.Virginia.EDU>
Date: 21 Jan 92 18:21:00 GMT
Sender: usenet@murdoch.acc.Virginia.EDU
Reply-To: heyes@dadev.cebaf.gov (Graham Heyes)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Lines: 28

Last week I posted about a problem I was having with system 7 tune-up but got
no replies. 

When printing with a tuned system 7.01 on a laserwriter SC my Mac+ locks up
completely with the tune-up extension in the system. With tune-up removed I
got corrupted output, lines of dots over text. 

	I re-built system 7.01 and found that the printing problem is still there
so I guess that my system 7.01 installation kit is corrupt, 7.0 was fine.   
  
The problem is that my poor old Mac only has an 800k drive so I can't use real
disks.  I used Mount Image to mount disk images then dragged the disks onto my
hard disk to create folders from which I installed. Some people have written
to say that MountImage is still a little shaky so I am blaming the problem on
that and going back to 7.0 for now. There are some irritating bugs etc in 7.0
which I have read are fixed in 7.01 but since 7.01 is availible as 1400k disk
images only I don't seem able to get 7.01 without going through mountImage and
perhaps getting in the same mess again.

	Is there any way to extract the files from a disk Image without using
mountimage or real disks?
  
	Does anyone know if System 7 tune-up fixes the disk eject bug where
when you eject a floppy the Mac asks for it back again??

	thanks,

	Graham Heyes

From dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes Fri Jan 24 08:00:38 PST 1992
Article: 19 of comp.os.vxworks
Path: dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes
From: heyes@dadev.cebaf.gov (Graham Heyes)
Newsgroups: comp.os.vxworks
Subject: IGNORE EARLIER POST!!
Message-ID: <1992Jan21.182951.204@murdoch.acc.Virginia.EDU>
Date: 21 Jan 92 18:29:51 GMT
Sender: usenet@murdoch.acc.Virginia.EDU
Reply-To: heyes@dadev.cebaf.gov (Graham Heyes)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Lines: 1

This mxrn news reader is a real pain in the ^##&&^ sometimes. 

From dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cosmic.physics.utah.edu!corbato Fri Jan 24 08:00:39 PST 1992
Article: 20 of comp.os.vxworks
Newsgroups: comp.os.vxworks
Path: dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cosmic.physics.utah.edu!corbato
From: corbato@cosmic.physics.utah.edu (Steve Corbato)
Subject: On-campus (U of Utah) test of vxworks group -- please disregard
Message-ID: <1992Jan22.224043.25212@fcom.cc.utah.edu>
Originator: corbato@cosmic.physics.utah.edu
Sender: news@fcom.cc.utah.edu
Organization: University of Utah Computer Center
Distribution: slc
Date: Wed, 22 Jan 92 22:40:43 GMT

-- 
Steve Corbato			     corbato@cosmic.physics.utah.edu (Internet)
Cosmic Ray Physics Group	     utahco::corbato, 47623::corbato (HEPnet)
Physics Dept., Univ. of Utah	     corbato@utahcca (BITnet)
Salt Lake City UT 84112 USA	     (801) 581-5053 (office), -4801 (Fax)

From dog.ee.lbl.gov!network.ucsd.edu!usc!elroy.jpl.nasa.gov!swrinde!mips!samsung!uunet!psinntp!calspan!smc!brancato Fri Jan 24 08:00:40 PST 1992
Article: 21 of comp.os.vxworks
Path: dog.ee.lbl.gov!network.ucsd.edu!usc!elroy.jpl.nasa.gov!swrinde!mips!samsung!uunet!psinntp!calspan!smc!brancato
From: brancato@calspan.com (Tony Brancato)
Newsgroups: comp.os.vxworks
Subject: VME to GPIB interface boards under VxWorks
Keywords: VME GPIB HPIB interface driver
Message-ID: <1992Jan23.171925.10881@calspan.com>
Date: 23 Jan 92 17:19:25 GMT
Sender: usenet@calspan.com
Organization: Calspan Advanced Technology Center, Buffalo, NY
Lines: 28
Originator: brancato@smc
Nntp-Posting-Host: smc

Does anyone have experiences with VME-to-GPIB interface boards that they
would mind sharing?  We are building an RF simulation system and are
using an HP8902A measuring receiver and an HP voltmeter to perform
diagnostics and calibration.  We'd like to write software to control the
voltmeter and measuring receiver from the main CPU over the GPIB.  The
system is built around a Motorola M147 VME CPU board running VxWorks 5.0
(as part of VADS 2.0.1c).

We have looked at an interface board from American Eltec, and found that
their driver would not arbitrate service requests from the GPIB.
Specifically, if a command was sent which caused a service request and
the controller attempted to talk to the requesting node before the
request was handled, the driver would hang because the requesting node
would never respond.  Is this normal for these types of boards, or do
other drivers detect and handle this condition?

We also have the driver for the MZ7500 board from Mizar, but have not
had a chance to look at it yet.  

Any suggestions, impressions, or past experiences about quality of
product and support are appreciated.  Please e-mail and I will post a
summary.  Thanks in advance.

-- 
Tony Brancato
Calspan Corporation ATC  Buffalo, NY
..!uupsi!calspan!brancato
brancato@calspan.com

From briggs@thalia.jpl.nasa.gov  Fri Jan 24 08:43:05 1992
From: briggs@thalia.jpl.nasa.gov (Clark Briggs)
Date: Fri Jan 24 08:43:11 PST 1992
Subject: Re: TP & VME addresses
The question
>>We've got a Tadpole TP41V under 5.0.2. Unfortunately, we cannot make
>>it access any off board addresses.
lead to discussions about the local to bus & bus to local maps.  While I dont
think the following really bears upon the original problem, I wondered about
the general state of things other than in the world of Heurikon BSPs where I
spend my time.

I found that HK only maps the local ram to a VME address if the SBC is
Processor 0.  This is explicitly checked in the mapping functions.  Slot 0 is
mapped to support the on-board memory used for backplane message passing. 
Since the other SBCs use the memory on the slot 0 processor, they dont need 
to set up the map to expose themselves to slave accesses from the VMEbus.

This does not mean all the processors cant go out and be bus masters and access
others, just that they wont respond if accessed.  So this does not appear to
be the original problem.

So, is there any standard for placing the other procs in VME space?  Are folks
using A32 or A24?  Mapping small parts, or all of the onboard memory?  Do folks
use a simple formula that is a function of the processor number (which can be
obtained via the BSP)?

I have various uses for this that might lead to different address allocation
schemes.  Sometimes we simply want to set up a few semaphore-like locations for
synchronization.  Sometimes we need to share (fairly large) data arrays.  To
date we have placed everything in a large VMEbus RAM board, but I have begun
to worry about the bus traffic for the future in some of these uses.

In one use, I need multiple HK V4Fs, 2 TASCO 1750s, and a 4MB RAM board
in the same address space.  Since the 1750s take 2Mb in A24 and thats their
only possible configuration, things get tight quickly. There is room enough
but I would like to follow some standard scheme.

From mea@sparta.com  Fri Jan 24 09:48:01 1992
From: mea@sparta.com (Mike Anderson)
Date: Fri Jan 24 09:48:08 PST 1992
Subject: Re: TP & VME addresses
Greetings!

   When playing memory mapping games with the Heurikon HK80G/V960E board
(i960CA), I use the processor number to map my slave memory segments into 
A32 space.  A32 space is the only area where most manufacturers don't 
add additional "address modifier" bits so 0x40000000 on one board 
is the same 0x40000000 on any other board in the system.  This makes
life much easier because anyone can calculate the extended address segment
by a formula such as 0x40000000 + (processor_number * 0x1000000).  This
formula maps slave RAM into even 16MB segments which may have to be
adjusted for particular applications.  

  In general, I try to avoid the A24 space for slave memory when
possible because A) there's not much of it; B) vendors have different
address ranges for standard space that may vary from card to card
(e.g., Heurikon maps standard space at 0x1000000 on the V3E but maps
that same address at 0x2000000 on the V30); and C) there's always some
card that comes along that needs 128K or so of RAM right in the middle
of A24 space that can't be moved ;-).

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE TM
   A   A  D   D  D   D  E      M M M M    // A   A R   R   TT   S     E
  AAAAAA  D   D  D   D  EEEEE  M  M  M   // AAAAAA RRRR    TT    SSS  EEEEE
 A     A  D   D  D   D  E      M     M  // A     A R  R    TT       S E
A      A  D D    D D    EEEEE  M     M // A      A R   R   TT   SSSSS EEEEE

Process Distribution/Control and Communications for Distributed Systems

Mike Anderson                       Voice: (703) 448-0210 ext. 235
Director, ADDEM(TM) Project Office  FAX:   (703) 734-3323
SPARTA, Inc.                        EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "The optimist proclaims that we live in the
McLean, VA  22102               best of all possible worlds, and the pessimist
                                fears that this is true."

                                    J.B. Cabell

==============================================================================

From kevinf@verdix.com  Fri Jan 24 11:26:36 1992
From: "D. Kevin Faust" <kevinf@verdix.com>
Date: Fri Jan 24 11:26:46 PST 1992
Subject: Re: comp.os.vxworks articles 

  Does VxWorks provide any way to direct output to a null device,
  in other words, the equivalent of "/dev/null" ???

From nelson@wrs.com  Fri Jan 24 15:52:53 1992
From: nelson@wrs.com (Nelson Stubbins)
Date: Fri Jan 24 15:53:00 PST 1992
Subject: VxWorks equivalent to "/dev/null"

> Does VxWorks provide any way to direct output to a null device,
>  in other words, the equivalent of "/dev/null" ???

Yes, there is a "/null" device.  To see a list of devices, use the
devs() routine.  You will see the null device listed there.

Nelson Stubbins
Training Manager
Wind River Systems

From bdoerr@aplpy.jhuapl.edu  Sat Jan 25 13:46:58 1992
From: bdoerr@aplpy.jhuapl.edu (Bryan S. Doerr)
Date: Sat Jan 25 13:47:06 PST 1992
Subject: MMU Follow-up

Hi:

	I have used the MMU on our MVME-147S to provide some of the features
described in the last MMU query (poster's name forgotten, sorry). It is a simple
implementation but a first step into the MMU world.

	Without getting real specific, I divided the VxWorks image into
specified text and data segments at link time. I then mapped the following
areas using the MMU translation tables:

		VxWorks reserved          0-     FFFH   R/W, cache on
		VMEbus global ram      1000-    2FFFH   R/W, cache off
                MMU Trans Tables       3000-    4FFFH   RO , cache on
		application text       5000-   7FFFFH   RO , cache on
		VxWorks text          80000-   FFFFFH   RO , cache on
		application data     100000-  14FFFFH   R/W, cache on
		VxWorks data         150000-   ?        R/W, cache on
		system memory pool     ?   -  3FFFFFH   R/W, cache on
		VMEbus space         400000-FF7FFFFFH   R/W, cache off

	Also mapped were the EPROM banks and VMEbus Short I/O. I was a little
generous with some of the space allocations as a first pass. I plan to change
this when the application matures. Also, the hardware cache inhibits
VMEbus accesses but just for completness, I did it also.

	The translation tables are created in usrRoot after everything else
has completed initialization. To start the application running, I load it
from a script that uses the vxWorks routine 'loadModuleAt()' and specify 
the the application text and data base addresses.

	The code consists of one C module. The MMU initializations were 
done using ASM in-line calls. The translation tables were written in C.
I had to do one hack to get this working and that was to change the boot 
ROMs to load the VxWorks segments correctly. The data address is hardcoded,
hence the hack. In addition, I had to change to boot ROMs to run from a 
different (higher) part of memory because the new mappings caused the system
image to clobber the currently running ROM code. Also, I wrote a short routine to turn the MMU off from the shell and another routine to search all addressable space and print a summary of the access and cache mode specifications at the 
transition points.

	There are some notable weaknesses with this approach, specifically 
no task protection, no smart handling of bus errors caused by the various 
no-no's (access violation, not mapped space vs board not responding etc),
and breakpoints can't be set. It does work well for what we needed though
which was cache coherency after VMEbus-local RAM access by an alternate
master and code protection. I think most of these deficiencies could be
overcome with a little more work.

	One final note, a co-worker took this idea and ported to a MVME-167
board and used the 040 MMU to control things such as serialized I/O reqs. and 
cache mode. The port wasn't a drop in because the 040 MMU is a good bit
different.

        Regards,
	Bryan
	

From wdf@uk.ate.slb.com  Mon Jan 27 00:08:16 1992
From: wdf@uk.ate.slb.com
Date: Mon Jan 27 00:08:33 PST 1992
Subject: NFS read very slow

We have a configuration consisting of a Motorola mv147 running
VxWorks 5.0.2 connected to a host Sun SparcStation over ethernet,
there are no other nodes on the ethernet. We boot the mv147 over
the ethernet from an image which is VxWorks linked with our
application, this is quite large (about 1.6 Mbytes) and is loaded
to start at 0xd0000. Our application is started from the end of
usrRoot(). VxWorks is configured to use NFS.

When we stop our application at it's start, so that none of our
code has been executed and type the following commands to the
shell, the read() takes about a minute !

-> nfsMount ("host","/directory","/directory")
-> cd "/directory/sub_dir"
-> x = open("file",0)
-> y = malloc(600000)
-> read (x,y,550000)

Where "file" is a file of 590000 bytes.

If we link the image without our code, but configured in exactly
the same way (which gives an image of less than 400Kbytes) the
same sequence of commands results in the read() taking about
3 seconds.

If we put the mv147 and Sun onto our factory ethernet, which has
over 50 nodes and is quite busy, the read() is again faster than
a minute, although not as good as 3 seconds.
 
If anyone out there has any idea what may be causing read() to
take so long, we will be gratefull to hear from you !

Bill Frewing
Principal Engineer
Schlumberger Technologies, Ferndown, UK.
Email:  wdf@ukfca1.uk.ate.slb.com
Voice:  (+44) 202 893535
Fax:    (+44) 202 897097

From bernard@aar.alcatel-alsthom.fr  Mon Jan 27 02:24:55 1992
From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
Date: Mon Jan 27 02:25:02 PST 1992
Subject: msgQueue Patch ...

Is it possible to get the msgQueue patch ?

Thanks

-- Olivier

From visicom!VisiCom.COM!trest@nosc.mil  Mon Jan 27 09:08:47 1992
From: Mike Trest <trest@visicom.com>
Date: Mon Jan 27 09:08:54 PST 1992
Subject: Re:  NFS read very slow

>>when we stop our application at it's start, so that none of our
>>code has been executed and type the following commands to the
>>shell, the read() takes about a minute !

  . . .

>>If we link the image without our code, but configured in exactly
>>the same way (which gives an image of less than 400Kbytes) the
>>same sequence of commands results in the read() taking about
>>3 seconds.

The former uses NFS which goes thru the additional protocol
of NFS daemons and competetion for your workstation's processing
resources.  The full client/server processing is involved at
both ends of the connection.

The latter uses rcmd() from your workstation.  The command
is a simple "cat filename" to an open file descriptor "read"
on the VxWorks card. 

The NFS is about 40 or 50 times "heavier" in processing load
than the rcmd() which is a strait TDP connection.  Secondly,
the "cat filename" on your workstation is significantly
buffered and will produce many times fewer disk acesses than
the NFS.

Remember, the virtue of NFS is to provide the FULL FILE HANDLING
capabilities in a multiuser, shared, network environment.  The
rcmd() "cat filename" only provides a sequential output to your
sequential input.  The choice is up to you the application
designer.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

From daemon@vxw.ee.lbl.gov  Mon Jan 27 10:16:15 1992
From: daemon@vxw.ee.lbl.gov
Date: Mon Jan 27 10:16:22 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 27 10:16:08 PST 1992

        Subject: specifying boot parameters
        Subject: Wind River contact
        Subject: low power disk?

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: specifying boot parameters
Date: 24 Jan 92 20:16:25 GMT
From: heyes@dadev.cebaf.gov (Graham Heyes)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Message-ID: <1992Jan24.201625.6160@murdoch.acc.Virginia.EDU>
Reply-To: heyes@dadev.cebaf.gov (Graham Heyes)

Some time ago I ported VxWorks to a FERMILAB - FSCC fastbus controller now the
time has come to release the system to some real users and we have hit a 
problem. 

	The board has only 50 bytes of NV ram to store the VxWorks boot-line.
Up to now for testing we have been using one board with a cryptic boot
line like:

fe(0,0)c: e=xxx.xx.x.xx h=xxx.xx.x.x u=vxw s=/vb

Where I have replaced digits by xxx in the internet addresses for security of 
this posting. The boot script /vb has to be in the root directory since
there is
no space to specify a path. The user name is cut down to three
characters but
presents a security loophole in our system, we would prefer longer
names. 
			   These boards are intended to be imbedded processors
in a large scale system and 50 bytes is too small to store a boot line
with
enough versatility to specify unique options for each VxWorks node.
The block of internet addresses reserved for VxWorks at our lab has a
format
like xxx.xx.xx.xx some of the hosts already have addresses like
xxx.xxx.xx.xx
which looses us 4 bytes compared with the test system, also three
characters
gives little scope for username allocation and putting a boot script in
the 
root directory is messy.

	Other users must have had similar problems. Of course we could blow a
unique set of EPROMS for each VxWorks target, or perhaps put a case statement
in a common startup script which switches on inet address and branches to 
target specific scripts. 
                    The ideal solution would be to re-define the boot line as
a parameter block, the fe(0,0) network interface specifier is redundant and
could be thrown out, the two network addresses could be stored in long word
format instead of dot notation taking only 4 bytes each, with one byte of flags
the other 41 bytes can be split between username and boot script path.

	Has anyone already done this? I would be interested to know of any
potential problems, is bootLib only called from usrConfig.c leaving it open
for modification/removal???

Any advice gratefully accepted.

	Graham Heyes   

- -------------------------------------------------------------------------------
	Graham Heyes					CEBAF
							Physics Division MS 12H
Internet: heyes@dadev.cebaf.gov			        12000 Jefferson Ave
DECnet  : dadev::heyes, cebaf::heyes			Newport News VA 23606
BITNET  : heyes@cebaf					Tel: (804) 249-7030
						

---------------------------

Newsgroups: comp.os.vxworks
Subject: Wind River contact
Date: Mon, 27 Jan 92 16:46:41 GMT
From: selic@bqnws23ca (Bran Selic)
Organization: Bell-Northern Research Ltd.
Message-ID: <1992Jan27.164641.2290@bqnes74.bnr.ca>

- -- 
Does anyone have the name of a contact in the marketing group
at Wind River (e-mail or phone)?

- --------------------------------------------------------------
* Bran Selic                 Bell-Northern Research Ltd.     *
* e-mail: selic@bnr.ca       PO Box 3511, Station C          *
* phone: (613) 763-3954      Ottawa, Ont. CANADA K1y 4H7     * 
- --------------------------------------------------------------

---------------------------

Newsgroups: comp.realtime,comp.os.vxworks
Subject: low power disk?
Date: Mon, 27 Jan 1992 17:10:48 GMT
From: rg@msel.unh.edu (Roger Gonzalez)
Organization: UNH Marine Systems Engineering Lab
Message-ID: <RG.92Jan27121048@nymph.msel.unh.edu>

This is not a realtime specific question, but lacking a comp.sys.embedded:

Does anyone have any information on low power scsi disk drives?  Now that I've
purchased low power cmos 3u vme boards, I need a similarly low-powered disk.

Thanks,
- -Roger
- --
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsgar W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)

From biocca@bevsun.bev.lbl.gov  Mon Jan 27 11:13:44 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Mon Jan 27 11:13:55 PST 1992
Subject: crossconnection to comp.os.vxworks

I am currently testing the interconnection between comp.os.vxworks and
the exploder.  Posting from the exploder to netnews occurs hourly, but of
course newsfeeds will determine when your site receives them.  Explosion
of comp.os.vxworks occurs once daily early in the morning in digest form,
just before the exploder daily digest goes out.

Alan K Biocca
Exploder maintainer

From maf@verdix.com  Mon Jan 27 13:19:36 1992
From: maf@verdix.com
Date: Mon Jan 27 13:19:51 PST 1992
Subject: Re: Rumor regarding Ada
> From dog.ee.lbl.gov!nosc!manta!psm Fri Jan 24 08:00:23 PST 1992
> From: psm@manta.NOSC.MIL (Scot Mcintosh)
> Newsgroups: comp.os.vxworks
> Subject: Rumor regarding Ada
> Keywords: Ada, Verdix
> Date: 16 Jan 92 18:15:28 GMT
> 
> I've heard a rumor that Verdix will no longer be offering an
> Ada product that runs with vxWorks.

Verdix and Wind River recently announced a four-year extension to the
reselling agreement under which Verdix distributes VxWorks as part of
our VADSworks product (see page 6 of Wind River's September, 1991 edition
of "Windword" for details).

There are no plans to discontinue the VADSworks product. On the contrary,
we are continuing to support and enhance existing versions of VADSworks,
and we are porting the product to new processors. 

Marc Friedman
Verdix Technical Sales

From visicom!VisiCom.COM!trest@nosc.mil  Mon Jan 27 14:08:58 1992
From: Mike Trest <trest@visicom.com>
Date: Mon Jan 27 14:09:09 PST 1992
Subject: RE:  specifying boot parameters
Graham Heyes writes:

>>The board has only 50 bytes of NV ram to store the VxWorks boot-line.
>>Up to now for testing we have been using one board with a cryptic boot
>>line like:
  . . .
>>Other users must have had similar problems. Of course we could blow a
>>unique set of EPROMS for each VxWorks target, or perhaps put a case statement
>>in a common startup script which switches on inet address and branches to
>>target specific scripts.
  . . .
>>Has anyone already done this? I would be interested to know of any
>>potential problems, is bootLib only called from usrConfig.c leaving it open
>>for modification/removal???

>>Any advice gratefully accepted.

Graham, we faced the same problem with ZERO NV ram on a custom board
used in a cluster of 12 cpu boards in the same chassis and a network
of 4 to 12 chassis.  The prsopect of burning 144 unique ROM sets was
very negative.

Our solution (which might apply to your posting) was to put a small
function in the bootConfig.c file which "Requested Permission To Boot"
from a "Boot Monitor Service".  The BMS service assigned a network address,
board id, user id, ETC ....  A (unplanned) side benefit was a much faster 
boot process for all boards and chassis because it eliminated the instant 
depletion of Q entries in the boot host's TCP/IP which was caused when
every board in every chassis booted at the same time.   

A designed-in benefit of this was "Dynamic Assignment Of Boot Host Role".
We wrote our bootConfig.c function to be independent of the actual boot
host's identity.  This allowed for booting from any of a group multiple 
workstations to eliminate single point failures.  We are presently
extending this capability with VxWorks cards booting themselves from
SCSI disks and then providing additional "Boot Service" to the remaining 
boards and chassis.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

?

From wdf@uk.ate.slb.com  Tue Jan 28 01:39:00 1992
From: wdf@uk.ate.slb.com
Date: Tue Jan 28 01:41:46 PST 1992
Subject: Re: NFS read very slow
I asked for help on a problem where read() using NFS on a mv147 was 
taking too long, this happened on a lightly loaded ethernet, and
seemed to depend on the ammount of object code (text, not data)
loaded at the time, even though that object is not executed. We link
the object code with vxWorks and boot from that combined image over
the network. If the image was about 400K read() takes 3seconds, if
it was 1.1M read() takes over a minute (to read 550K).

I have had a some replies, as follows.

Leonid Rosenboim suggested putting the net task priority to 0 or 1,
this didn't have any effect. He also suggested trying etherfind on
a different Sun on the network, I haven't tried that yet.

We received the message queue patch from Wind River yesterday, and
that has fixed the problem, although I don't know why. Actually it
has only partially fixed the problem... we are experiencing this on
two types of board, the mv147 mentioned in my earlier mailing, and
a National Instruments VXIcpu-030. This is a mv147 look-alike which
lives on a VXI backplane, the message queue patch did improve matters
on that, but not significantly (the read() now takes about 40 seconds).

Mike Trest suggested that the two cases (where the read took 3 seconds
and over a minute) were different, in that one used NFS and the other
didn't. I cannot understand why that should be the case, as the two
read()s are done in exactly the same manner from the shell after 
usrRoot() returns. The sequence of commands was as follows:

-> nfsMount ("host","/directory","/directory")
-> cd "/directory/sub_dir"
-> x = open("file",0)
-> y = malloc(600000)
-> read (x,y,550000)

Bill Frewing
Principal Engineer
Schlumberger Technologies, Ferndown, UK.
Email:  wdf@ukfca1.uk.ate.slb.com
Voice:  (+44) 202 893535
Fax:    (+44) 202 897097

From leonid@amil.co.il  Tue Jan 28 02:52:09 1992
From: leonid@amil.co.il (Leonid Rosenboim)
Date: Tue Jan 28 02:52:17 PST 1992
Subject: Re: NFS read very slow
> Submitted-by wdf@uk.ate.slb.com (Bill Frewing) Tue Jan 28 01:39:00 1992
> ...
> Mike Trest suggested that the two cases (where the read took 3 seconds
> and over a minute) were different, in that one used NFS and the other
> didn't. I cannot understand why that should be the case, as the two
> read()s are done in exactly the same manner from the shell after 
> usrRoot() returns. The sequence of commands was as follows:
> -> nfsMount ("host","/directory","/directory")
> ...

Mike was wrong. True that usually VxWorks comes from WRS configured without
NFS support, but the above "nfsMount" command clearly shows that the
smaller kernel does include the NFS option, otherwise "nfsMount" would
have failed.

Leonid

From daemon@vxw.ee.lbl.gov  Tue Jan 28 04:00:33 1992
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 28 04:00:39 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 28 04:00:25 PST 1992

        Subject: Re: Rumor regarding Ada

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Rumor regarding Ada
Date: Tue, 28 Jan 1992 01:47:53 GMT
From: tony@wrs.com (Tony Barbagallo)
Organization: Wind River Systems, Inc. Alameda, CA
Keywords: Ada, Verdix
Message-ID: <1992Jan28.014753.3591@wrs.com>
References: <2615@manta.NOSC.MIL>

In article <2615@manta.NOSC.MIL> psm@manta.NOSC.MIL (Scot Mcintosh) writes:
>I've heard a rumor that Verdix will no longer be offering an
>Ada product that runs with vxWorks. Supposedly, they'll be
>furnishing their own operating system. I've also heard that
>Wind River is talking with Telesoft about furnishing Ada.
>Anyone know the real story?
>

Just to clarify the recent postings regarding the relationship between Verdix
and Wind River Systems, I'd like to point out that in September of 1991 the two
companies signed a four year extension to this successful agreement which
brought VADSworks to the market. Included in the extended agreement are rights
for Verdix to sell VADSworks on a worldwide basis. Furthermore, the marketing
organization at Wind River is not pursuing relationships with any other Ada
vendors at this time.

Tony Barbagallo
Manager of Product Marketing
Wind River Systems, Inc.
tony@wrs.com

---------------------------

End of New-News digest
**********************

From visicom!VisiCom.COM!trest@nosc.mil  Tue Jan 28 07:56:39 1992
From: Mike Trest <trest@visicom.com>
Date: Tue Jan 28 07:56:46 PST 1992
Subject: Re: NFS read very slow
Obviously I did not read the posting carefully enough to determine
that both reads were NFS reads.  Sorry about the confusion.

However, the difference in performance between NFS reads and
remote command execution of "cat filename" remains true.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 592 0353
Technology Group                Fax:   619 673 0307
VisiCom Laboratories            San Diego, CA
====================================================

From phil%kerSs2@wrsec.wrsec.fr  Tue Jan 28 10:52:10 1992
From: phil%kerSs2@wrsec.wrsec.fr (Philippe Le Foll)
Date: Tue Jan 28 10:52:18 PST 1992
Subject: Mv165 and VSB
hello,

Does anybody already used VSB on a Motorola MV165 ?
If yes thank for the initialisation sequence used.

thank you Philippe

From thor@thor.atd.ucar.edu  Tue Jan 28 11:06:42 1992
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Tue Jan 28 11:06:50 PST 1992
Subject: Job offer
Do not reply to sender!!!!!

Contract diagnostics engineer needed immediately in Bay area. 6+
months. S/W diagnostics, Sun, UNIX, VxWorks.

Contact:

Jeff Gold
United Source Services
28310 Roadside Dr.
Suite 237
Agoura Hills, CA 91301

818-991-227 (voice)
818-991-3413 (fax)

From prb@aplexus.jhuapl.edu  Tue Jan 28 12:13:07 1992
From: prb@aplexus.jhuapl.edu (Paul R. Bade)
Date: Tue Jan 28 12:13:14 PST 1992
Subject: Re: Mv165 and VSB

We also are planning to use the MV165 and its VSB in the near future.
We will be using it only as a temporary solution until the MV166 boards
become available this summer.This is partially because the MV165 board
has such poor VME performance. In addition to its normal poor VME performance,
the MV165 does not support VME64. THe MV166 board is essentially a MV167 
(software compatible) with the addition of the VSBchip2 interface.
Please let me know if you find anything about the MV165 board
which may be useful.

		Thanks,

		Paul Bade
		Johns Hopkins University / Applied Physics Lab
		prb@aplexus.jhuapl.edu

PS I wrote some MMU code for the MV167 board, let me know if you are interested.

From comtec!jack@ucsd.edu  Tue Jan 28 12:15:11 1992
From: comtec!jack@ucsd.edu (Jack McRoberts)
Date: Tue Jan 28 12:15:19 PST 1992
Subject: Re:  memory board, VSB part. slave I/F
We use a board by MicroMemory. It has 64 Megs and is accessible as a slave
across both VSB and VME. Addresses are selectable on 1M boundaries, and it
responds to both A24 and A32.  

jack mcroberts
ORINCON Corp
9363 Towne Center Drive
San Diego, Ca 92121

From biocca@bevsun.bev.lbl.gov  Tue Jan 28 13:01:42 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Tue Jan 28 13:01:49 PST 1992
Subject: Re:  Job offer REPEATED

Hmmm.  This is the second time this job offer has been on here.

Alan K Biocca

From iphasew!hwajin@apple.com  Tue Jan 28 13:28:22 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Tue Jan 28 13:28:29 PST 1992
Subject: RE: NFS read very slow

Bill Frewing writes...
>I asked for help on a problem where read() using NFS on a mv147 was 
>taking too long, this happened on a lightly loaded ethernet, and
>seemed to depend on the ammount of object code (text, not data)
>loaded at the time, even though that object is not executed. We link
>the object code with vxWorks and boot from that combined image over
>the network. If the image was about 400K read() takes 3seconds, if
>it was 1.1M read() takes over a minute (to read 550K).

When this happens try various network related "Show" routines to
see if you see any excessive input errors are happening either
at the network interface level or protocol level.  You can use

-> lkup "Show"

to see a list of Show routines and "help" command to see what they do.

Of course, the final "read()" command will need to be "sp" (spawned), so that
you can run "Show" commands from the shell.

And also, try using TCP based read() on the same file -- use either
FTP or RSH based netDrv.  See if this makes any difference.

On some eariler rev's of mv147's (there were a number of rev's) and
other '030 based SBC's there were some hardware problems (the LANCE
would report CRC and Frame error when in fact the packet received
was okay -- caused by power glitch due to insufficient capacitance)
that only occurred when a lot of back-to-back packets were received
from the network.  A lot of packets get dropped at the LANCE driver
level when this happens.  Thus, my suggestions for further investigation...

Good luck.

-
Hwa-Jin Bae
Interphase West

From iphasew!hwajin@apple.com  Tue Jan 28 13:32:42 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Tue Jan 28 13:32:50 PST 1992
Subject: RE: specifying boot parameters

Graham Heyes writes...

>                    The ideal solution would be to re-define the boot line as
>a parameter block, the fe(0,0) network interface specifier is redundant and
>could be thrown out, the two network addresses could be stored in long word
>format instead of dot notation taking only 4 bytes each, with one byte of flags
>the other 41 bytes can be split between username and boot script path.

If you do throw out the network interface specifier two things will need
to be changed:

1. the call to bootStringToParams() in usrConfig.c and bootConfig.c 
will need to be replaced with your own (or fake the bootString input).
The bootStringToParams() is rather strict about the format it accepts.

2. bypass the code that attaches a particular network interface based
on either a bunch of "if" blocks (if you're using old version of VxWorks)
or a table.  Attach your device directly and skip that part.

The network addresses can be in hex format but you need to specify '0x'
or '0X' prefix.  The hex digits still need to be ascii format so you'll
waste a byte per digit.  Still, this will save you a few bytes.
Due to a "bug" in inet_addr() routine in VxWorks, you could 
actually save a byte if you don't specify '0' in front of 'x' or 'X'.
That is "0x12345678" = "x12345678".  I think this "bug" is still in there
so a couple of additional bytes can be saved.

Alternatively you could add a host table entry using hostAdd()
for the "host" you're booting from (if it doesn't change).  And delete
the corresponding hostAdd() used in bootConfig.c and usrConfig.c.
No more space wasted for the host IP address. Save a bunch of bytes there.

Also if you do away with bootStringToParams() entirely, you make it
do what you want.

If you want to get rid of the boot line dependency all together, you can
write either RARP or BOOTP.

>	Has anyone already done this? I would be interested to know of any
>potential problems, is bootLib only called from usrConfig.c leaving it open
>for modification/removal???

Routines in bootLib.c are called from usrConfig.c and bootConfig.c.
I don't think they're used anywhere else, but I'm not 100% sure.
I'm using an ancient version of VxWorks here -- version 4.0.1.

Of course, if you remove bootLib, you won't be able to do things
like bootParamsShow() from the shell.

Good luck!

--
Hwa-Jin Bae
Interphase West

From thor@thor.atd.ucar.edu  Tue Jan 28 13:49:49 1992
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Tue Jan 28 13:49:56 PST 1992
Subject: TP41 booting problems
When we boot our TP41V, the following error message appears:

Format Error
Program Counter: 0x4003be60
Status Register: 0x3010
Task: 0x401d34e4 "tShell"

and VxWorks hangs - no startup script processing, ^C & ^X don't work,
etc. Actually, what's more confusing is that ^X works for the eprom
WRS sent with the board support package, but our own proms cannot even
service ^X. Any ideas?

Richard Neitzel thor@thor.atd.ucar.edu	     	Torren med sitt skjegg
National Center For Atmospheric Research	lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000			Gjo'i med sitt shinn
303-497-2057					jagar borni inn.

From votava@fndaue.fnal.gov  Tue Jan 28 13:51:46 1992
From: votava@fndaue.fnal.gov (Margaret Votava)
Date: Tue Jan 28 13:51:54 PST 1992
Subject: vxworks for an lr33000

Hi,

	I know LSI is in the process of doing a vxworks port for the LR33000
MIPS microprocessor. Has anyone else already done the port?

		Thanks,
		Margaret Votava
		Fermilab

From bob@wrs.com  Tue Jan 28 13:59:15 1992
From: bob@wrs.com (Bob Cohen)
Date: Tue Jan 28 13:59:24 PST 1992
Subject: Re:  NFS read very slow
I think what you're seeing is the lance bug that appeared on earlier versions
of the 147 which caused it to drop incoming packets under certain conditions.
The symptom we saw here at wind river (and elsewhere - this was a widespread
problem) was exactly as you describe.  If you run etherfind, you'll see
the target transmit the nfs request, the reply comes back immediately, then
the nfs retransmission period elapses (5 seconds default), and it retransmits
the request.  I believe Motorola is aware of the problem, and they can 
update your board.  

From kent@wrs.com  Tue Jan 28 15:01:12 1992
From: kent@wrs.com (Kent Long)
Date: Tue Jan 28 15:01:29 PST 1992
Subject: Re:  TP41 booting problems
Hi, Folks -

thor@thor.atd.ucar.edu (Richard Neitzel) writes:
 >  
 > When we boot our TP41V, the following error message appears:
 > 
 > Format Error
 > Program Counter: 0x4003be60
 > Status Register: 0x3010
 > Task: 0x401d34e4 "tShell"
 > 
 > and VxWorks hangs - no startup script processing, ^C & ^X don't work,
 > etc. Actually, what's more confusing is that ^X works for the eprom
 > WRS sent with the board support package, but our own proms cannot even
 > service ^X. Any ideas?

Well, I suspect that this TP-41 uses the new mask of the 68040.  This
can be confirmed by looking for the ID "04D50D" on the cpu chip.

This newer mask included some changes in the floating point exception
format, which can cause the "format error" which Richard describes.
The beta/pre-release version of VxWorks 5.0.2/68040 (i.e. the version
in general circulation) does not correctly deal with this new chip
mask.  The new 5.0.2b/68040 release should be available within a couple
weeks, and it does include changes for the D50D mask.

As for the reboot problem, it is quite possible that this is also
due to the mask revision.  There is also an unrelated fix in the 5.0.2b/
68040 release which corrects a general problem with rebooting.

So, please be patient and see if the new version fixes your problems.

 - kent

   Kent Long
   Wind River Systems
   kent@wrs.com

From Enterprise!arete!reder@uu.psi.com  Tue Jan 28 18:04:22 1992
From: reder@arete.lbl.gov (Leonard J. Reder)
Date: Tue Jan 28 18:04:28 PST 1992
Subject: RE: NFS read very slow

> On some eariler rev's of mv147's (there were a number of rev's) and
> other '030 based SBC's there were some hardware problems (the LANCE
> would report CRC and Frame error when in fact the packet received
> was okay -- caused by power glitch due to insufficient capacitance)
> that only occurred when a lot of back-to-back packets were received
> from the network.  A lot of packets get dropped at the LANCE driver
> level when this happens.  Thus, my suggestions for further investigation...
> 
> Hwa-Jin Bae
> Interphase West
> 
At one point we had a problem of unreliable data com with our
MV147S board due to a problem with the LANCE hardware on the
board. This caused very slow net data rates. Finally it was
fixed by sending the board back to Motorola for an upgrade
to Rev. E (I think..). Everything with the board and socket
level communications seems to function normally now. I originally
recall reading about this problem in one of the WindWord news letters
from WRS. You may wish to contact WRS for the specifics.

Len Reder
Arete Associates

From daemon@vxw.ee.lbl.gov  Wed Jan 29 04:00:36 1992
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 29 04:00:43 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 29 04:00:23 PST 1992

        Subject: vxworks development organization
        Subject: Unimplemented Opcode error
        Subject: Re: comp.os.vxworks newsdigest reposting
        Subject: Re: Unimplemented Opcode error

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: vxworks development organization
Date: 28 Jan 92 14:16:44 GMT
From: rg@msel.unh.edu (Roger Gonzalez)
Organization: UNH Marine Systems Engineering Lab
Message-ID: <RG.92Jan28091644@nymph.msel.unh.edu>

I've just gotten VxWorks up and running, and I'm trying to figure out a way
to let several people work on coding pieces of the same project, without
leaving all the directories wide open.

I was considering something like the following:

users a, b, and c are all working on project p.  the vxworks library/binary
tree is in v.  Assume that a, b, c, p, and v all are in /etc/passwd, but p and
v have disabled passwords.

a, b, and c have hooks in their .cshrc's that, if they newgrp to group "p",
will change their home directory to ~p, and run ~p/.setup.  ~p/.setup will add

Now that seems to be ok for the unix side.  What about vxworks?
Should they do an "iam p" on that side?

Any comments would be appreciated.

- -Roger

- --
"The question of whether a computer can think is no more interesting
 than the question of whether a submarine can swim" - Edsger W. Dijkstra 

Roger Gonzalez   -  rg@msel.unh.edu
Division of Bit Banging and Reluctant Robotics
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)

---------------------------

Newsgroups: comp.os.vxworks
Subject: Unimplemented Opcode error
Date: 28 Jan 92 19:10:23 GMT
From: cole@noao.edu (Lonnie Cole)
Organization: National Optical Astronomy Observatories, Tucson, AZ, USA
Keywords: BOMB
Message-ID: <1992Jan28.191023.3382@noao.edu>

We are running vxWorks 5.0.2 on a Motorola MV147 board which is running
some instrumentation we have. The tasks run along fine most of the time,
but if I rlogin into the vxWorks system, sometimes I get something like
the following actual example:

rlogin sonora-i

inst >
Unimplemented Opcode 1111
Program Counter: 0x0075f2c8
Status Register: 0x3000
Task: 0x76d8a8 "tRotator"

The a dump of the offending code from vxWorks looks like:

75f2aa  f22e 5438 ffa0           FCMP  .D    (0xffa0,A6),F0
75f2b0  f29d 00fa                FB    .W    #0xfaf22e
75f2b4  f22e 4400 ffdc           FMOVE .S    (0xffdc,A6),F0
75f2ba  f22e 5423 fff8           FMUL  .D    (0xfff8,A6),F0
75f2c0  f200 0003                FDB         D0,#0xf22e
75f2c4  f22e 6000 ffd8           FMOVE .L    F0,(0xffd8,A6)
75f2ca  0cae 0000 7fff ffd8      CMPI  .L    #0x07fff,(0xffd8,A6)
75f2d2  6f08                     BLE         0x75f2dc
75f2d4  2d7c 0000 7fff ffd8      MOVE  .L    #0x07fff,(0xffd8,A6)
value = 7729884 = 0x75f2dc = _updateRotator + 0x1a0

Has anybody else had any similar problems. This happens fairly
frequently and I don't know if my code is doing or not-doing something
to cause this behavior.

Lonnie
cole@noao.edu

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: comp.os.vxworks newsdigest reposting
Date: 28 Jan 1992 19:36:08 GMT
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Organization: Lawrence Berkeley Laboratory, California
Message-ID: <20916@dog.ee.lbl.gov>
References: <9201281200.AA26055@vxw.ee.lbl.gov>

Sorry about that.  A bug in the exploder reposted the newsdigest of the
previous postings.  Repairs have been made.

Alan K Biocca
Exploder Maintainer

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Unimplemented Opcode error
Date: 28 Jan 92 20:40:10 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Jan28154010@deimos.frc.ri.cmu.edu>
References: <1992Jan28.191023.3382@noao.edu>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

I've found that often times when things get this bad, the cause is
actua

From heyes@dadev.cebaf.gov  Wed Jan 29 05:50:49 1992
From: heyes@dadev.cebaf.gov
Date: Wed Jan 29 05:50:57 PST 1992
Subject: Re: specifying boot parameters 
Many thanks for the mails. I've had several on the subject, the most elegant is 
as follows.
     Start with a short boot string specifying only the host and your own network
address. Edit the network initialisation code to attach our interface directly
rather thn looking it up so we don't need the fe(0,0) part of the boot string.
Next, when the network is up, do an RPC call to a server on the specified host.
The server recognises the address of the caller and sends back an extended boot
line with any number of arguments of arbitrary length. (Alternatively open a flat
file in a known place which contains entries keyed by network address).
A second call to bootStringToParams can then be made to update the boot 
parameters, or since the format of the boot parameter structure is known, a user 
decode routine can be put into usrConfig.c allowing more user options to be 
specified.
	This gets us nicely out of the problem. By the way I keep mentioning 
usrConfig.c and not bootConfig.c because our board only has limited RAM but a
large amount of EPROM. As much of our kernel and symbol table as possible is 
in EPROM. Only the Data and Bss segments in RAM. We have to do some playing with 
the linker here since the Data and Bss must be forced into RAM for execution but
the Data segment must initially be contained in the EPROMS then copied to RAM
during the boot procedure. 

Also look at the assembler code for the symbol table, you will see that all the
name strings of symbols are in the Data segment i.e. RAM. They don't need to be
since they never change. Awk or Sed can be used to edit the assembly code to
put these definitions in the Text Segment, forcing them into EPROM. You can't 
force the whole symbol table into EPROM since it is hashed later.

Many thanks again for advice on the boot line problem,

		Graham Heyes

-------------------------------------------------------------------------------
	Graham Heyes					CEBAF
							Physics Division MS 12H
Internet: heyes@dadev.cebaf.gov			        12000 Jefferson Ave
DECnet  : dadev::heyes, cebaf::heyes			Newport News VA 23606
BITNET  : heyes@cebaf					Tel: (804) 249-7030

From heyes@dadev.cebaf.gov  Wed Jan 29 06:19:14 1992
From: heyes@dadev.cebaf.gov
Date: Wed Jan 29 06:19:21 PST 1992
Subject: Re: specifying boot parameters 
Many thanks for the mails. I've had several on the subject, the most elegant is 
as follows.
     Start with a short boot string specifying only the host and your own network
address. Edit the network initialisation code to attach our interface directly
rather thn looking it up so we don't need the fe(0,0) part of the boot string.
Next, when the network is up, do an RPC call to a server on the specified host.
The server recognises the address of the caller and sends back an extended boot
line with any number of arguments of arbitrary length. (Alternatively open a flat
file in a known place which contains entries keyed by network address).
A second call to bootStringToParams can then be made to update the boot 
parameters, or since the format of the boot parameter structure is known, a user 
decode routine can be put into usrConfig.c allowing more user options to be 
specified.
	This gets us nicely out of the problem. By the way I keep mentioning 
usrConfig.c and not bootConfig.c because our board only has limited RAM but a
large amount of EPROM. As much of our kernel and symbol table as possible is 
in EPROM. Only the Data and Bss segments in RAM. We have to do some playing with 
the linker here since the Data and Bss must be forced into RAM for execution but
the Data segment must initially be contained in the EPROMS then copied to RAM
during the boot procedure. 

Also look at the assembler code for the symbol table, you will see that all the
name strings of symbols are in the Data segment i.e. RAM. They don't need to be
since they never change. Awk or Sed can be used to edit the assembly code to
put these definitions in the Text Segment, forcing them into EPROM. You can't 
force the whole symbol table into EPROM since it is hashed later.

Many thanks again for advice on the boot line problem,

		Graham Heyes

-------------------------------------------------------------------------------
	Graham Heyes					CEBAF
							Physics Division MS 12H
Internet: heyes@dadev.cebaf.gov			        12000 Jefferson Ave
DECnet  : dadev::heyes, cebaf::heyes			Newport News VA 23606
BITNET  : heyes@cebaf					Tel: (804) 249-7030

From jritchie@wrs.com  Wed Jan 29 09:32:09 1992
From: jritchie@wrs.com (Jim Ritchie)
Date: Wed Jan 29 09:32:15 PST 1992
Hello,

Has anyone written a VxWorks' driver for the Motorola MVME328 Dual-channel 
SCSI Adapter VME card that they would be willing to share with another
VxWorks' customer?

Thanks!

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ James Ritchie                                  Wind River Systems        +
+ Western Region Field Application Engineer      19925 Stevens Creek Blvd  +
+ jritchie@wrs.com                               Cupertino, CA  95014      +
+                                                (408)973-7857             +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

From sjk@emerald.labs.tek.com  Wed Jan 29 09:33:31 1992
From: Steven King (503) 627-2736 <sjk@emerald.labs.tek.com>
Date: Wed Jan 29 09:33:40 PST 1992

> Hi,

> I know LSI is in the process of doing a vxworks port for the LR33000
> MIPS microprocessor. Has anyone else already done the port?
>
>		Thanks,
>		Margaret Votava
>		Fermilab

LSI has performed a board port of 5.0.4 (beta) for the LSI Pocket
Rocket.

The 5.0.4 (beta) distribution comes with a BSP for the Lockheed/
Sanders STAR MVP.

It is my understanding that 5.0.4 will be officially released in
February.  I suggest you contact your Wind River salesperson 
regarding the availability of 5.0.4 (for the MIPS), and any 
specific BSPs.  

Steven

----------------------------------------------------------------------
e-mail: sjk@crl.labs.tek.com       |  Steven King
phone: 503-627-2736                |  Software Technology Research Lab
voice mail: 503-727-6651           |  Tektronix, Inc.
fax: 503-627-5502                  |  P.O. Box 500   MS 50-662
                                   |  Beaverton, OR  97077
----------------------------------------------------------------------

From stan@rti.com  Wed Jan 29 10:51:21 1992
From: stan@rti.com (Stan Schneider)
Date: Wed Jan 29 10:51:27 PST 1992
Subject: Re:  comp.os.vxworks newsdigest
>> From: rg@msel.unh.edu (Roger Gonzalez)
>> Organization: UNH Marine Systems Engineering Lab
>> Message-ID: <RG.92Jan28091644@nymph.msel.unh.edu>
>> 
>> 
>> I've just gotten VxWorks up and running, and I'm trying to figure out a way
>> to let several people work on coding pieces of the same project, without
>> leaving all the directories wide open.
>> 
>> ...
>>
>> Now that seems to be ok for the unix side.  What about vxworks?
>> Should they do an "iam p" on that side?
>> 

We use a simple shell script that copies the user's login file out to a file
that's sourced by the VxWorks startup script.  It's simple & it works, but it
does assume you're willing to reboot your target.

>> ---------------------------
>> 
>> Newsgroups: comp.os.vxworks
>> Subject: Re: Unimplemented Opcode error
>> Date: 28 Jan 92 20:40:10 GMT
>> From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
>> Organization: Field Robotics Center, CMU
>> Message-ID: <HMP.92Jan28154010@deimos.frc.ri.cmu.edu>
>> References: <1992Jan28.191023.3382@noao.edu>
>> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
>> 
>> 
>> I've found that often times when things get this bad, the cause is
>> actua
>> 

Is anyone else losing messages like this?

        -- Stan

===============================================================================
=                                           =                                 =
=   Stan Schneider                          =   email: stan@rti.com           =
=   Real-Time Innovations, Inc.             =   Phone: (408) 720-8312         =
=   954 Aster, Sunnyvale, CA 94086          =   Fax:   (408) 720-8419         =
=                                           =                                 =
===============================================================================

From susanna@tomato.lbl.gov  Wed Jan 29 14:34:05 1992
From: susanna@tomato.lbl.gov (Susanna Jacobson)
Date: Wed Jan 29 14:34:12 PST 1992
Subject: Re:  Mv165 and VSB
Philippe Le Foll writes:
> 
>Does anybody already used VSB on a Motorola MV165 ?
>If yes thank for the initialisation sequence used.
> 

and Paul R. Bade adds:
> 
>We also are planning to use the MV165 and its VSB in the near future.
...
>Please let me know if you find anything about the MV165 board
>which may be useful.
> 

We use the following shell commands at the beginning of the
startup.cmd script:

	# Enable VSB access on MVME 165
	m 0xfffa0000
	0xfebe
	0xfebe
	.
	m 0xfff9002a
	0x1c
	.

The first "m" writes to the VSB chip; the second to the Bus Control
Register of the Local Resource Controller.  The idea is to enable
VSB access and set the longest timeout; see the VSBchip manual and
the LRC section of the mv165 documentation.

========================================================================
Susanna Jacobson			MS 46A-1123
					Lawrence Berkeley Laboratory
SRJacobson@LBL.Gov			1 Cyclotron Road
(510) 486-7801				Berkeley, CA 94720
========================================================================

From daemon@vxw.ee.lbl.gov  Thu Jan 30 04:00:35 1992
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 30 04:00:42 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 30 04:00:26 PST 1992

        Subject: boot parameters + vxwexplo problems...
        Subject: Re: NFS read very slow
        Subject: Re: specifying boot parameters
        Subject: Re: Mv165 and VSB

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: boot parameters + vxwexplo problems...
Date: 29 Jan 92 15:02:44 GMT
From: heyes@dadev.cebaf.gov (Graham Heyes)
Organization: CEBAF (Continuous Electron Beam Accelerator Facility)
Message-ID: <1992Jan29.150244.25360@murdoch.acc.Virginia.EDU>
Followup-To: boot parameters + vxwexplo problems...
Reply-To: heyes@dadev.cebaf.gov (Graham Heyes)

I would just like to point out that although the vxwexplo E-mail
sent me a correct copy of my last posting (29 Jan) the copy which 
appears here has the first part missing and so doesn't make any
sense at all... 

	... Is there a problem with the vxwexplo to comp.os.vxworks connection??

Here is the complete article

- ------------------------------------------------------------------------
- ----------
Many thanks for the mails. I've had several on the subject, the most
elegant is 
as follows.
     Start with a short boot string specifying only the host and your
own network
address. Edit the network initialisation code to attach our interface
directly
rather thn looking it up so we don't need the fe(0,0) part of the boot
string.
Next, when the network is up, do an RPC call to a server on the
specified host.
The server recognises the address of the caller and sends back an
extended boot
line with any number of arguments of arbitrary length. (Alternatively
open a flat
file in a known place which contains entries keyed by network address).
A second call to bootStringToParams can then be made to update the boot
parameters, or since the format of the boot parameter structure is
known, a user 
decode routine can be put into usrConfig.c allowing more user options to
be 
specified.
	This gets us nicely out of the problem. By the way I keep mentioning 
usrConfig.c and not bootConfig.c because our board only has limited RAM
but a
large amount of EPROM. As much of our kernel and symbol table as
possible is 
in EPROM. Only the Data and Bss segments in RAM. We have to do some
playing with 
the linker here since the Data and Bss must be forced into RAM for
execution but
the Data segment must initially be contained in the EPROMS then copied
to RAM
during the boot procedure. 

Also look at the assembler code for the symbol table, you will see that all the
name strings of symbols are in the Data segment i.e. RAM. They don't need to be
since they never change. Awk or Sed can be used to edit the assembly code to
put these definitions in the Text Segment, forcing them into EPROM. You can't 
force the whole symbol table into EPROM since it is hashed later.

Many thanks again for advice on the boot line problem,

		Graham Heyes

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: NFS read very slow
Date: 29 Jan 92 01:27:09 GMT
From: rypma@hppad.waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <27550002@hppad.waterloo.hp.com>
References: <9201270810.AA04153@pickle.UK.ATE.SLB.COM>

We load a 2.5 Mb file with NFS and it takes no more than 10 to 20 
seconds.  Is there some kind of memory limitation when your application
is linked in?

Ted Rypma
HP Panacom Division

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: specifying boot parameters
Date: 29 Jan 92 01:10:11 GMT
From: rypma@hppad.waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <27550001@hppad.waterloo.hp.com>
References: <1992Jan24.201625.6160@murdoch.acc.Virginia.EDU>

The bootp protocol is designed to do this, is supported (I think)
by VxWorks and is a standard facility provided on many hosts.

Ted Rypma
HP Panacom Division

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Mv165 and VSB
Date: 30 Jan 92 03:49:17 GMT
From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)
Organization: Field Robotics Center, CMU
Message-ID: <HMP.92Jan29224917@squash.frc.ri.cmu.edu>
References: <9201292237.AA07232@tomato.lbl.gov>
Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels)

This is just a generic comment regarding the method described by
Susanna Jacobson which involves modifying hardware registers via "m"
commands from a script: I once tried the same thing and it took me a
while to realize that the "m" command performs (I believe) 16-bit
accesses, while the particular device I was trying to tinker with only
responded to byte access. In a similar vein, hardware registers like that may
be read-only, write-only or sometimes even have different  purposes
depending on the direction of transfer; simply reading a whole 16
bit word and rewriting it with those bits of interest set or cleared
may have subtle side effects. 

Admittedly, this was some time ago and I was just starting out with
vxWorks, but it just came back to me as one of those early lessons.

- -Henning
- --
Henning Pangels     |   hmp@frc2.frc.ri.cmu.edu   |      Field Robotics Center
Research Programmer |       (412) 268-7088        | Carnegie-Mellon University
- ------------------------------------------------------------------------------
		    Do you really know what time it is?

---------------------------

End of New-News digest
**********************

From matthieu@vega.laas.fr  Thu Jan 30 08:02:01 1992
From: Matthieu Herrb <matthieu@vega.laas.fr>
Date: Thu Jan 30 08:02:10 PST 1992
Subject: Re:  Mv165 and VSB

Susanna Jacobson writes:

 > We use the following shell commands at the beginning of the
 > startup.cmd script:
 >
 >	# Enable VSB access on MVME 165
 >	m 0xfffa0000
 >	0xfebe
 >	0xfebe
 >	.
 >	m 0xfff9002a
 >	0x1c
 >	.
 >
 > The first "m" writes to the VSB chip; the second to the Bus Control
 > Register of the Local Resource Controller.  The idea is to enable
 > VSB access and set the longest timeout; see the VSBchip manual and
 > the LRC section of the mv165 documentation.

Our problem is that we need to initialize the VSB chip with 0xfeae
(with the BOUNCE bit at zero) to access our UIC03 I/O card (from
MicroSys). When we initialize the VSB chip with this particular value,
the backplane interface of the 165 hangs.

Has anyone else experienced this problem and/or a solution to it ?

Thank you in advance.

					Matthieu Herrb

-- 
	Matthieu Herrb             CNRS - LAAS 
	matthieu@laas.fr     	   7, avenue du Colonel Roche
        	                   31077 Toulouse Cedex - France

From wdf@uk.ate.slb.com  Thu Jan 30 08:10:25 1992
From: wdf@uk.ate.slb.com
Date: Thu Jan 30 08:10:39 PST 1992
Subject: Slow NFS read
My last mailing on this subject started thus:

> I asked for help on a problem where read() using NFS on a mv147 was 
> taking too long, this happened on a lightly loaded ethernet, and
> seemed to depend on the ammount of object code (text, not data)
> loaded at the time, even though that object is not executed. We link
> the object code with vxWorks and boot from that combined image over
> the network. If the image was about 400K read() takes 3seconds, if
> it was 1.1M read() takes over a minute (to read 550K).

Since then a few contributers have suggested that there may be a problem
with the Lance ethernet chip(s) on the SBC we are using (a National 
Instruments VXIcpu-030). This may be borne out by the following findings:

1. When run on a loaded network (30+ suns) the problem does not occur.
2. When the host is an HP9000 (as opposed to the usual Sun Sparc) again
   the problem does not occur.
3. Using etherfind on the Sun when the read is taking a long time, shows
   that every 5th packet is followed by a wait of 5 seconds before the
   identical packet (with a packet number 1 greater!) is sent again.
4. If the nfsReXmitSec & nfsReXmitUSec globals are altered to hold the
   time of 0.5 seconds instead of the default 5.0 seconds then the read
   takes a 10th of the slow read time.

From 1 & 2 we conclude that the SBC cannot handle the higher transfer
rate possible due to light loading of network and server.

3 & 4 seem to indicate that the SBC is retrying but why it is doing
so is a mystery to us! When using the vxWorks ???Show commands none
of the reports show any errors. We have tried ipstatShow(), tcpstatShow(),
icmpstatShow() & udpstatShow() (in each case we called the function from
the vxWorks shell without any parameters).

Bill Frewing
Principal Engineer
Schlumberger Technologies, Ferndown, UK.
Email:	wdf@ukfca1.uk.ate.slb.com
Voice:	(+44) 202 893535
Fax:	(+44) 202 897097

From biocca@bevsun.bev.lbl.gov  Thu Jan 30 15:04:16 1992
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Thu Jan 30 15:04:23 PST 1992
Subject: missing article fragment
I found the missing article fragment Stan@rti.com mentioned.  The bug has
(likely) been fixed.

In case you haven't noticed, I turned on the cross-coupling of the newsgroup
and exploder on monday, and aside from this problem it appears to be working.

Please send any requests to vxwexplo-request (rather than the exploder) for
changes in your subscriptions.

Alan K Biocca
Exploder Maintainer

From daemon@vxw.ee.lbl.gov  Fri Jan 31 04:00:25 1992
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 31 04:00:32 PST 1992
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 31 04:00:18 PST 1992

        Subject: Re: Unimplemented Opcode error
        Subject: Re: Mv165 and VSB

-------------------------------------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Unimplemented Opcode error
Date: 30 Jan 92 15:57:55 GMT
From: winans@xray.aps.anl.gov (John R. Winans)
Organization: Argonne National Laboratory, Chicago Illinois
Message-ID: <1992Jan30.155755.6183@mcs.anl.gov>
References: <1992Jan28.191023.3382@noao.edu> <HMP.92Jan28154010@deimos.frc.ri.cmu.edu>

In article <HMP.92Jan28154010@deimos.frc.ri.cmu.edu> hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:
>
>I've found that often times when things get this bad, the cause is
>actually somewhere else, and usually involves some memory locations
>having been trashed. For all you know, your task may be executing data
>at that point. Notice in your code dump that during normal
>execution flow, the program counter should not be 0x0075f2c8, but
>either 0x75f2c4 or 0x75f2ca. 
>I'd look for stack overflows (checkStack()) or other stack corruption.
>Since the rlogin requires CPU cycles (and netTask is usually higher
>than application code, by default), your application may not get
>enough cycles and, if you are using interrupts, the interrupt stack
>might be exceeded. The first thing to try might be to increase your
>application task priority above that of the netTask and see if that
>makes any difference.

I agree with your comments.  But let me add an observation:

The origionator of this thread mentions that he is using version 5.0.2.  We 
here recently converted from a 4.x release to 5.0.2.  We recompiled all our
code to find that every now and then we were crashing for no reasonable cause.
After some poking around, we noticed that all tasks have stacks that are about
0x800 bytes smaller than they did under 4.x.  Some poking around the new manual
showed that a task's TCB is now cut out of its stack.

So, if you are a byte counter... don't forget about the TCB size too!

- -- 
! John Winans                     Advanced Photon Source  (Controls)    !
! winans@mcs.anl.gov              Argonne National Laboratory, Illinois !
!                                                                       !
!"The large print giveth, and the small print taketh away." - Tom Waits !

---------------------------

Newsgroups: comp.os.vxworks
Subject: Re: Mv165 and VSB
Date: Thu, 30 Jan 1992 19:50:14 GMT
From: james@wrs.com (James Moore)
Organization: Wind River Systems, Inc.
Message-ID: <james.696801014@wrs.com>
References: <9201292237.AA07232@tomato.lbl.gov> <HMP.92Jan29224917@squash.frc.ri.cmu.edu>

hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes:

>...it took me a
>while to realize that the "m" command performs (I believe) 16-bit
>accesses, while the particular device I was trying to tinker with only
>responded to byte access.

True, but don't forget that the source to 'm' is sitting in
somedir/vw/config/all/usrLib.c (and bootLib.c), which you've got.
Easy to modify if you need something non-standard.

- --
James Moore                                 | james@wrs.com
Wind River Systems Engineering              |

---------------------------

End of New-News digest
**********************

From abenett@lodestar.gb.nrao.edu  Fri Jan 31 06:06:51 1992
From: abenett@lodestar.gb.nrao.edu (ARON BENETT)
Date: Fri Jan 31 06:07:00 PST 1992
Subject: Vxworks cross-compiler and GNU g++ Version 1.40.3

Could anyone give me some tips on getting GNU g++ V1.40.3 to work with the
Vxworks V5.0.1 GNU Toolkit. We are currently using the VxWorks cross compiler 
V5.0.1 with gcc 1.37.1. I notice in the makefile there is a section to make 
cplus but the cplus .o objects are not included on the tape. When I talk 
with tech support at Wind River, they say that a supported version will not 
be out until 4th quarter 92. Does anyone know if I just take the objects from 
g++ 1.40.3 and link them in via the makefile will they work. I also see that 
there are a set of class libraries and header file on the NETLIB index. 
Are these needed to get the system up and running.  Any information would be 
greatly appreciated. Thanks.

----------------------------------------------------------------------------

Aron Benett
National Radio Astronomy Observatory
P.O. Box 2
Green Bank, W.Va. 24944

voice:    (304)456-2214
Internet: abenett@lodestar.gb.nrao.edu

From iphasew!hwajin@apple.com  Fri Jan 31 12:34:52 1992
From: hwajin@iphasew.com (Hwa-Jin Bae)
Date: Fri Jan 31 12:34:58 PST 1992
Subject: Re: Slow NFS read

>>>>> On Fri, 31 Jan 92 04:05:31 Bill Frewing said:

Bill> 3 & 4 seem to indicate that the SBC is retrying but why it is
Bill> doing so is a mystery to us! When using the vxWorks ???Show
Bill> commands none of the reports show any errors. We have tried
Bill> ipstatShow(), tcpstatShow(), icmpstatShow() & udpstatShow() (in
Bill> each case we called the function from the vxWorks shell without
Bill> any parameters).

You should also try ifShow() which reports statistics available for
a all network interface drivers.  Pay special attention to "ierrors" (input
errors) field.

As I said before, I have found out by working with board manufacturers that
on some boards that have on-board LANCE devices, CRC and/or Frame errors
are generated for perfectly good frames received; that is, the LANCE
lies about the error condition.  When this happens the VxWorks LANCE 
driver drops the packet and increments input error count.  This problem
was attributed to the use of too low farad capacitors between the
power source and the LANCE VCC/VSS pins.

--
Hwa-Jin Bae
Interphase West

From Christina_Goette@wrs.com  Fri Jan 31 13:59:51 1992
From: Christina Goette <Christina_Goette@wrs.com>
Date: Fri Jan 31 13:59:58 PST 1992
Subject: West Coast Users Group Meet
                       Subject:                               Time:1:43 PM
  OFFICE MEMO          West Coast Users Group Meeting         Date:1/31/92
The next annual West Coast VxWorks Users Group Meeting is scheduled to be held
in Southern California this April.  Tentatively, the date has been set for
April 10, 1992.  We are looking for a VxWorks user to chair the meeting. 
Chairing a meeting involves setting the agenda, inviting users to present, and
running the meeting.  Time commitment on the volunteer's part is fairly minimal
as Wind River Systems will handle the administrative details such as mailings,
registration, and facilities.  

Watch this space for more information about the meeting.

If you are interested in chairing this meeting or have questions, please
contact me via e-mail at tina@wrs.com,  or at 1-800-545-9463 x2050.  

Thank you.
Christina Goette
Wind River Systems

From news@fdm.fujitsu.co.jp  Fri Jan 31 14:53:17 1992
From: news@fdm.fujitsu.co.jp
Date: Fri Jan 31 14:53:25 PST 1992
Subject: Rejected news: No send to JUNET
----- Unsent reason follows -----
User "vxwexplo@lbl.gov" is not authorized.

----- Unsent message follows -----
Path: fdm!fdm-cnews!fgw!sh.wide!wnoc-tyo-news!rena!tdo!tkymail!nddsun1!spsgate!uunet!uunet!elroy.jpl.nasa.gov!ames!agate!dog.ee.lbl.gov!lbl.gov!vxwexplo
From: vxwexplo@lbl.gov (vxWorks Exploder)
Newsgroups: comp.os.vxworks
Subject: RE: NFS read very slow
Message-ID: <9201290056.AA25895@arete>
Date: 29 Jan 92 00:56:30 GMT
Sender: vxwexplo@lbl.gov
Organization: Lawrence Berkeley Laboratory, Berkeley CA
Lines: 22
NNTP-Posting-Host: 128.3.112.16
Submitted-by: reder@arete.lbl.gov (Leonard J. Reder)
Originator: daemon@vxw.ee.lbl.gov

> On some eariler rev's of mv147's (there were a number of rev's) and
> other '030 based SBC's there were some hardware problems (the LANCE
> would report CRC and Frame error when in fact the packet received
> was okay -- caused by power glitch due to insufficient capacitance)
> that only occurred when a lot of back-to-back packets were received
> from the network.  A lot of packets get dropped at the LANCE driver
> level when this happens.  Thus, my suggestions for further investigation...
> 
> Hwa-Jin Bae
> Interphase West
> 
At one point we had a problem of unreliable data com with our
MV147S board due to a problem with the LANCE hardware on the
board. This caused very slow net data rates. Finally it was
fixed by sending the board back to Motorola for an upgrade
to Rev. E (I think..). Everything with the board and socket
level communications seems to function normally now. I originally
recall reading about this problem in one of the WindWord news letters
from WRS. You may wish to contact WRS for the specifics.

Len Reder
Arete Associates

From jupiter!bob@uunet.uu.net  Fri Jan 31 18:46:49 1992
From: bob@jupiter.com (Bob Schulman)
Date: Fri Jan 31 18:47:01 PST 1992
Subject: RE: NFS read very slow
> On some eariler rev's of mv147's (there were a number of rev's) and
> other '030 based SBC's there were some hardware problems (the LANCE
> would report CRC and Frame error when in fact the packet received
> was okay -- caused by power glitch due to insufficient capacitance)
> that only occurred when a lot of back-to-back packets were received
> from the network.  A lot of packets get dropped at the LANCE driver
> level when this happens.  Thus, my suggestions for further investigation...
Actually, *all* rev's of the 147 have this problem. We had to use a
WRS-supplied hack to get our 5.0.2 NFS reads running at (more or
less) full speed. The WRS-supplied hack was to change LN_DATA_WIDTH from
"NONE" to "4" (in mv147.h). This was verified with the latest rev board.

bob

From thor@thor.atd.ucar.edu  Fri Jan 31 22:56:53 1992
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Fri Jan 31 22:57:01 PST 1992
Subject: Monthly VxWorks archive posting
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:

total 1604
-rw-r--r--  1 thor        22132 Jun 18  1990 ansi.p1
-rw-r--r--  1 thor        22717 Jun 18  1990 ansi.p2
-rw-r--r--  1 thor        24174 Jun 18  1990 ansi.p3
-rw-r--r--  1 thor         8108 Jun 18  1990 ansi.patch1
-rw-r--r--  1 thor         2671 Jan  2  1990 benchmarks
-rw-r--r--  1 thor         7168 Jul 13  1989 bitcnt
-rw-r--r--  1 thor        11437 Feb 15  1991 c++builtin.shar
-rw-r--r--  1 thor        22330 Apr  4  1990 c++headers.p1
-rw-r--r--  1 thor        22775 Apr  4  1990 c++headers.p2
-rw-r--r--  1 thor        29052 Dec  6  1989 camaclib1
-rw-r--r--  1 thor        25095 Dec  6  1989 camaclib2
-rw-r--r--  1 thor        31005 Dec  6  1989 camaclib3
-rw-r--r--  1 thor        37770 Dec 21  1989 cbench.shar
-rw-r--r--  1 thor         7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--  1 thor         5853 May 31  1989 crc.shar
-rw-r--r--  1 thor         8917 Oct  9  1990 deadman.shar
-rw-r--r--  1 thor        41669 Dec  6 14:07 dhrystones01
-rw-r--r--  1 thor        25681 Aug 29  1989 dt1451
-rw-r--r--  1 thor         5944 Apr 26  1989 fcompress.shar
-rw-r--r--  1 thor        11561 Nov  1 12:12 flags_class.shar
-rw-r--r--  1 thor        44762 Jul 18  1990 force.p1
-rw-r--r--  1 thor        40154 Jul 18  1990 force.p2
-rw-r--r--  1 thor        80491 May  8  1989 force.shar
-rw-r--r--  1 thor         6106 Oct 10  1989 getdate
-rw-r--r--  1 thor         9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--  1 thor         8807 Jan 16 13:30 index
-rw-r--r--  1 thor         2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--  1 thor        27824 May 30  1989 jobCondLib
-rw-r--r--  1 thor        25014 May 30  1989 jobLib
lrwxrwxrwx  1 root           10 Aug 14 07:11 jobcondlib -> jobCondLib
lrwxrwxrwx  1 root            6 Aug 14 07:11 joblib -> jobLib
-rw-r--r--  1 thor        35245 Oct  9  1990 joblib2.p1
-rw-r--r--  1 thor        18110 Oct  9  1990 joblib2.p2
-rw-r--r--  1 thor         9079 Apr  2  1990 lclflag.shar
drwxr-xr-x  2 thor          512 Oct 31  1990 libX11
lrwxrwxrwx  1 root            6 Aug 14 07:11 libx11 -> libX11
-rw-r--r--  1 thor        25077 Oct  9  1990 loadmeter.shar
-rw-r--r--  1 thor        10399 May  4  1989 math.shar
-rw-r--r--  1 thor        11950 May 30  1989 math2
-rw-r--r--  1 ftp         26655 Nov 15  1990 monitor.shar
-rw-r--r--  1 thor        18733 Jun 14  1990 msgque_class.shar
-rw-r--r--  1 thor        55175 Oct 21 09:11 ntpvx01
-rw-r--r--  1 thor        55174 Oct 21 09:11 ntpvx02
-rw-r--r--  1 thor        50076 Oct 21 09:11 ntpvx03
-rw-r--r--  1 thor        39603 Oct 21 09:11 ntpvx04
-rw-r--r--  1 thor        28719 Oct 21 09:11 ntpvx05
-rw-r--r--  1 thor        32494 Oct 21 09:11 ntpvx06
-rw-r--r--  1 thor        37097 Oct 21 09:11 ntpvx07
-rw-r--r--  1 thor        41621 Oct 21 09:11 ntpvx08
-rw-r--r--  1 thor        20494 Oct 31 12:06 pipe.shar
-rw-r--r--  1 thor        15418 May 30  1989 poolLib
lrwxrwxrwx  1 root            7 Aug 14 07:11 poollib -> poolLib
-rw-r--r--  1 thor        13204 Oct 31 08:19 ring.shar
-rw-r--r--  1 thor         6614 May 31  1989 semCnt
lrwxrwxrwx  1 root            6 Aug 14 07:11 semcnt -> semCnt
-rw-r--r--  1 thor         2308 Jan  2  1990 ss1.bnch
-rw-r--r--  1 thor        16225 Oct 10  1989 string.shar
-rw-r--r--  1 thor        15096 Oct  2 08:55 task_class.shar
-rw-r--r--  1 thor        16171 Oct  9  1990 taskmon.shar
-rw-r--r--  1 thor        10523 May 31  1989 tod.shar
-rw-r--r--  1 thor        25790 Nov  8  1990 ty335.shar
-rw-r--r--  1 thor        25814 Apr 26  1989 vtape.shar
-rw-r--r--  1 thor        43671 Nov 22 14:05 vwcurses01
-rw-r--r--  1 thor        40180 Nov 22 14:05 vwcurses02
-rw-r--r--  1 thor        38308 Nov 22 14:05 vwcurses03
-rw-r--r--  1 thor        31181 Nov 22 14:05 vwcurses04
-rw-r--r--  1 thor        31798 Nov 22 14:05 vwcurses05
-rw-r--r--  1 thor        31459 Nov 22 14:05 vwcurses06
-rw-r--r--  1 thor        24279 Nov 22 14:05 vwcurses07
-rw-r--r--  1 thor        29720 Aug 28 14:10 vxrsh.p1
-rw-r--r--  1 thor        26002 Aug 28 14:10 vxrsh.p2
-rw-r--r--  1 thor        13713 Aug 28 14:10 vxrsh.p3
-rw-r--r--  1 thor         4702 Jan 16 13:28 wdog_class
-rw-r--r--  1 thor         4168 Jan 16 13:30 xxx
Unix sources:

total 82
-rw-r--r--  1 thor         1192 Mar 13  1990 index
drwxr-xr-x  2 thor          512 Oct 26  1989 patch
-r--r--r--  1 thor        11744 Apr 11  1989 shar.shar
-rw-r--r--  1 thor        19698 Nov 15  1989 vxtool
-rw-r--r--  1 thor        21934 Jan 31  1990 vxview
-rw-r--r--  1 thor        14151 Feb  9  1990 vxview.patch
-r--r--r--  1 thor         9869 Feb  1  1989 xc.shar
drwxr-xr-x  2 thor          512 Feb 11  1990 xdbx

Richard Neitzel thor@thor.atd.ucar.edu	     	Torren med sitt skjegg
National Center For Atmospheric Research	lokkar borni under sole-vegg
Box 3000 Boulder, CO 80307-3000			Gjo'i med sitt shinn
303-497-2057					jagar borni inn.