From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan Biocca)
Subject: testing new exploder
 

This is a test of the new vxworks exploder.

From rmk@iss-ipc3.ssd.ray.com Xxx Oct x xx:xx:xx 1991
From: rmk@iss-ipc3.ssd.ray.com
Subject: Scsi and/or Serial drivers
 
Greetings,

We are going to be adding SCSI and serial cards to our VME system that uses
Radstone modules.  Our current configuration is one of their dual-ethernet
EMPP cards with a CPU3A 68030 processor.  The SCSI and serial modules are
"intelligent" cards which are controlled through a dual-port RAM. Commands are
written into the dual-port memory, and the internal processor takes over and
does what is necessary.  When the command is complete, the module interrupts
the processor back via a VME interrupt.

We are trying to add this to VADSWorks 2.0, if that makes any difference.
It's based on VxWorks 5.0 with enhancments.  We've already done the ports to
the EMPP and CPU3A modules.

My question is, has anyone written a driver, either for SCSI or serial, that
communicates with an "intelligent" module of this sort. Any help or pointers
to sources would be appreciated. 

Thanks in advance.
Rich

  ----------------------------------------------------------------------
  *  Rich Kulakowski            *  Raytheon Submarine Signal Division  *
  *                             *  1847 West Main Road,  Mail Stop 177 *
  *  rmk@sgfb.ssd.ray.com       *  Portsmouth, RI  02871-1087          *
  *                             *  (401) 847-8000 (X4210)              *
  ----------------------------------------------------------------------


From wrs!yuba!carl@uunet.uu.net Xxx Oct x xx:xx:xx 1991
From: wrs!yuba!carl@uunet.uu.net (Carl Chesbrough)
Subject: Re:  Scsi and/or Serial drivers
 
Rich,

I have done a SCSI port to the Radstone SCSI-1 board for a customer in
Michigan.  I did this port as a consultant, before I joined WRS.  The
port was originally done to vxWorks 4.0.2, and then upgraded to 5.0.
I am not sure if this would help, but it might be a starting point.
I will make sure it is OK with my customer if I give you a copy if you
are interested.  Their target was a Sundstran (?) optical drive in a
full MIL spec. system.

Let me know if you are interested,
-Carl C. Chesbrough
 Wind River Systems
 1010 Atlantic Avenue
 Alameda, CA  94501
 (510) 814-2157


From interf!atlas!argus!brackett@uunet.uu.net Xxx Oct x xx:xx:xx 1991
From: interf!atlas!argus!brackett@uunet.uu.net (Todd Brackett)
Subject: new expolder
 
  I liked the the old exploder better.
  
The new exploder sends everything out with the same mail return address.
  
If I want to respond personally to the sender I have to enter his address
by hand.  This only works if the user has given me his address (I see the   Submitted by line in the header).  Upon occasion I have had better luck 
with the return address than the address given by the user.
  
I also keep track of things by the users address in my mailbox files.
  
What's the deal guys?
  
P.S. The request address is bogus!  It just bounces back to the sender.

  -------------------------------------------------------
  |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 biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan Biocca)
Subject: New Exploder
 
Thanks for the comments on the New Exploder, Todd.  (He likes the old one
better...)

We can make the return address on the exploder anything you (the user group)
wants.  I set it up (it was an original requirement) so that a reply goes
back to the exploder instead of the original author -- I think we want to
see more of the conversation than just the original request.

Todd was right about the vxwexplo-request adress -- it was crossed up in the
changeover and has been fixed now.  

The submitted-by header line is one I made up -- it is determined by scanning
the sender's message for one of the from lines -- it should be a pretty
good address.  

Perhaps there is another better use of header lines that would improve things
-- a reply-to or something along those lines.



Alan K Biocca
AKBiocca@lbl.gov


From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Subject: From and Reply exploder addresses
 
I can add a reply-to address to the exploder output.  What is the preference --
if I add this feature what should go in the 'from' vs the 'reply-to'
addresses?

'Votes to vxwexplo-request@lbl.gov'

Discussion to vxwexplo@lbl.gov


Alan K Biocca


From hebo@mbari.org Xxx Oct x xx:xx:xx 1991
From: hebo@mbari.org (Bob Herlien)
Subject: Re: From and Reply exploder addresses
 
> **********
> I can add a reply-to address to the exploder output.  What is the preference --
> if I add this feature what should go in the 'from' vs the 'reply-to'
> addresses?
> 
> 'Votes to vxwexplo-request@lbl.gov'
> 
> Discussion to vxwexplo@lbl.gov
> 

I think that the 'reply-to' field should point to the originator of the 
message.  For those messages in which a followup to the exploder is
appropriate, it's easy to enter 'cc: vxwexplo@lbl.gov'.  I remember that
address.  

The converse is not true.  For those messages in which a followup to the
exploder is not appropriate, I don't want to manually enter the originator's
address;  I want 'r' to send the message directly to him/her.

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From interf!atlas!argus!brackett@uunet.uu.net Xxx Oct x xx:xx:xx 1991
From: interf!atlas!argus!brackett@uunet.uu.net (Todd Brackett)
Subject: Re: From and Reply exploder addresses
 
Ditto to Bob Herlien's comments.


From mea@sparta.com (Mike Anderson) Xxx Oct x xx:xx:xx 1991
From: mea@sparta.com (Mike Anderson)
Subject: Re:  From and Reply exploder addresses
 
I'm infavor of which ever line will allow Sun mailers and mailtool to get the
sender's address when I say "reply to...".

Mike Anderson        "It is useless for sheep to pass resolutions in favor
SPARTA, Inc.          of vegetarianism while wolves remain of a different
mea@sparta.com        opinion."
(703) 448-0210                     William R. Inge, D.D.  1860-1954


From scotth@rocco.labs.tek.com Xxx Oct x xx:xx:xx 1991
From: scotth@rocco.labs.tek.com
Subject: Re: From and Reply exploder addresses 
 
> Ditto to Bob Herlien's comments.
> 

I feel exactly the opposite.

It's often the case that a posted query causes me to say to myself "That's
interesting, I wonder what the others will have to say." I usually don't have
the answer but am interested.  Not enough to ask the question in the first
place, but curious and hoping to grab a useful tidbit when it comes by.

If the return address is that of the submitter, then I'm forced to reply to
the sender with "please post summary to the mailing list" or "did you get
anything useful?". It's too easy  to underestimate others' interest and reply
only to the sender.

Whichever is the easiest is what we'll all do, most of the time. If it's
harder to reply to the list than to the individual, the list, in my opinion,
will suffer. It's easier to judge that a reply should only be sent to an
individual than it is that reply should be sent to the entire group. Therefore,
I'd like to suggest that we err on the side of sending to the entire group.

Like Bob says, it's easy to enter addresses. It sounds like it's a problem
that postings don't carry their submitter's return address unless it's
generated by the exploder as the return address.

Is there any other way of propogating the return address, so that it would be
easy to copy and paste into a "To: " string? This would eliminate the need to
remember addresses.

I want 'r' to send the message to the exploder.

Scott Herzinger   scotth@crl.labs.tek.com
                  Computer Research Lab, Tektronix, Inc.
                  PO Box 500 MS 50-662, Beaverton, OR 97077


From bard@ssd63.ssd.loral.com Xxx Oct x xx:xx:xx 1991
From: bard@ssd63.ssd.loral.com (James Woodyatt)
Subject: Re: From and Reply exploder addresses
 

I concur with Mr. Herzinger.

I vote to leave the From: line pointing to the Exploder for the reasons
he mentioned, and for the reason that it makes it easier for me to
separate the mail from the Exploder from the rest of my mail -- I don't
have to muck around with remembering subject lines.

 __________________________________________________________________
|
| James Woodyatt                 VOICE:  (415) 852-5429
| Space Systems/Loral (M/S G87)  FAX:    (415) 852-6286
| 3825 Fabian Way                E-MAIL: bard@cutter.ssd.loral.com
| Palo Alto, CA  9430
|


From lapp@waterloo.hp.com Xxx Oct x xx:xx:xx 1991
From: lapp@waterloo.hp.com (Dave Lapp)
Subject: Re: From and Reply exploder addresses 
 
I prefer 'reply' to send the message to the original poster not
the list. I also feel that its pretty easy to 'cc' the list.
(Its also what I'm used to with other lists which I'm on :-)

Dave Lapp
lapp@waterloo.hp.com


From cruise@cfht.hawaii.edu Xxx Oct x xx:xx:xx 1991
From: cruise@cfht.hawaii.edu (Bill Cruise)
Subject: From and Reply exploder addresses 
 
I cast my vote to have the "From:" line point back to the exploder.
 
Most of us do the easiest thing -- whatever our mailer does when we
hit "r".  If all replies go to the sender, all the exploder will be
is a series of questions with no answers.
 
Many of the replies are of general interest.  If not, it is easy
enough to get the sender's address and enter it in the reply, or in
a new message.  However, replying to the sender should be the
exception.
 
Bill Cruise
Canada-France-Hawaii Telescope


From jason@wrs.com Xxx Oct x xx:xx:xx 1991
From: jason@wrs.com (Jason Cotton)
Subject: reply address
 

My $.02:

I suspect that for the majority of the exploder community, the convenience
thing is over-rated. Both sunview and X allow one to quickly grab a snippet
of text (e.g., the original sender's e-mail address) and paste it back
as the destination address. Maybe I underestimate the number of users
who work from terminals primarily.

My own preference is for the reply-to to default to the Exploder. It's
easier for me to delete mail that I'm not interested in than to ken the
message of mail I never see. Also, I feel that we should be in the habit
of thinking "Do I really have something meaningful to say on this issue?".
Knowing that one's reply will be broadcast might eliminate some of the
casual banter kinds of replies.

Regarding the latest deluge of Exploder mail, I've seen several requests
from people wishing to be unsubscribed. It appears that they mailed to
the wrong address. Is this correct, or is the Exploder broadcasting mail
that it should not be? Also, what is the function of the address
"vxwexplo-list"? Is this an Exploder internal?

Lastly, maybe we should conduct a vote (to a non-broadcasted address)
on what the default reply-to should be. After 2-3 days, tally the votes,
and in the finest US tradition, the majority rules...

Sincerely, Jason Cotton
(jason@wrs.com)

p.S. Maybe the next generation mailers will have different reply commands
for getting to the sender or the destination (not always strictly yourself).
I wonder if there is some way to structure all of this so that the 
(g)roup reply command in elm could automatically broadcast back to the
exploder, while the (r)eply command would just target the originator of
the message. Of course, many people probably do not have or use elm. Sigh.


From smb@afterlife.ncsc.mil Xxx Oct x xx:xx:xx 1991
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Subject: Exploder vs. newsgroup
 
I suggest that the exploder be ditched altogether.  There's a wonderful Usenet
news system out there that will allow you to easily either follow up to the
news group or reply to the author.  This mail exploder is hardly efficient,
especially as the readership and volume continue to increase.  Let's get
into the 1990's.

However, until then, can the 8 lines of advertisement be removed from
exploded messages?  Also, there are 2 "Error" lines in the header.

Steve
smb@afterlife.ncsc.mil


From tweadon@lodestar.gb.nrao.edu Xxx Oct x xx:xx:xx 1991
From: tweadon@lodestar.gb.nrao.edu (TIM WEADON)
Subject: Re: From and Reply exploder addresses
 
I like the exploder just the way it is! I never remember any address, whether it
be the exploder or my own. I have often wanted to comment on a certain issue
or wanted to get comments on other issues that cross the exploder. The way
it was before was confusing, at least to me, as to "exactly" where do I send
this reply to. Presently it is spelled out very clearly and the default reply
goes to the exploder. I believe if it is asked on the exploder, taking up my time
to get curious about it, then it should be answered on the exploder.


	Tim Weadon
	National Radio Astronomy Observatory (NRAO)
	P.O. Box 2
	Green Bank, WV. 24944
	304-456-2120
	tweadon@nrao.edu


From tweadon@lodestar.gb.nrao.edu Xxx Oct x xx:xx:xx 1991
From: tweadon@lodestar.gb.nrao.edu (TIM WEADON)
Subject: VxWorks Driver for the National Instruments 1014B GPIB VME card.  I am looking for a software driver for the National Instruments 1014b GPIB card. I heard that David Lambert at SCC Laboratories has one available for the public. I don't have his proper e-mail address, if you have a driver for a GPIB card that would work in a 68030 system (mine is an mvme147s) or know David's e-mail could you let me know.  Thank you Tim Weadon tweadon@nrao.edu 304-456-2120
 

From dwells@fits.cx.nrao.edu Xxx Oct x xx:xx:xx 1991
From: dwells@fits.cx.nrao.edu (Don Wells)
Subject: Re: Exploder vs. newsgroup
 
the vxWorks Users Group Exploder writes:
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ People who want the From: line to
point to the exploder should consider this absurdity which is produced
by the default action of mail packages. The From: line _must_ point to
the originator, the Reply-To: line is the only question which should
be debated. The Sender: line should point to the exploder to direct
error messages back to the owner of the exploder, not to originators.

 > I suggest that the exploder by ditched altogether.  

We need an exploder to support the people who don't have newsfeeds.

 > ... Usenet news system ... allow[s] ... either follow up to the
 > news group or reply to the author.  

I myself prefer news to exploders, and you have given one of the
reasons.  Because I monitor a wide range of subjects, a more important
reason to prefer news is that it sorts the traffic into categories,
and my newsreader uses those categories for default folder names.

 > This mail exploder is hardly efficient,
 > especially as the readership and volume continue to increase.  

Actually, exploders _are_ fairly efficient in terms of bandwidth. The
VxWorks mailing list contains many entries which are mailing lists
(e.g., the exploder sends one message to NRAO, where it explodes
internally to a list of 15 individuals). In addition, smart mailers
like sendmail notice when there is more than one person on a
particular machine, and they only send one copy to the mailer daemon
on the other machine. However, exploders are inefficient in terms of
diskspace, because mail systems store a separate copy for each user,
unlike news which has only one copy. 

Experience shows that exploders are hard to maintain when lists hit
somewhere around 200 entries; this exploder is near to the limit right
now.

		=-=-= I second the motion ! =-=-=

I estimate that about 200 people are reading this traffic now, it
might even be 300. My guess is that perhaps half of this readership
have newsfeeds, and would use that means if given a chance. I also
estimate that with this number of readers we could win under the
requirements of the formal USENET voting procedure (100 more yes votes
than no votes).  

I recommend that we create the newsgroup "comp.realtime.vxworks".  I
further recommend that a bi-directional gateway to the exploder be
established so that people who don't have newsfeeds, or who don't like
news, can still be full participants. 

Meanwhile, I suggest that those of you who have newsfeeds check out
the "comp.realtime" newsgroup.  Many articles in "comp.realtime"
discuss VxWorks! I suspect that some of the authors of the articles
are unaware of this exploder.

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


From hmp@frc2.frc.ri.cmu.edu Xxx Oct x xx:xx:xx 1991
From: hmp@frc2.frc.ri.cmu.edu
Subject: Re: Exploder vs. newsgroup 
 

>I suggest that the exploder be ditched altogether.  There's a wonderful Usenet
>news system out there that will allow you to easily either follow up to the
>news group or reply to the author.  This mail exploder is hardly efficient,
>especially as the readership and volume continue to increase.  Let's get
>into the 1990's.

I agree that a newsgroup would be much more convenient for many, but there may
be some that for some reason can not access the usenet news system. 
This was discussed a while back, and the word at the time was that the group
wasn't quite large enough to warrant a newsgroup. Is this still the case?
Also, I think there are some newsgroups, like gnu.gcc.*, that exist in
parallel as a mailing list. Wouldn't that be the best of both worlds?

>However, until then, can the 8 lines of advertisement be removed from
>exploded messages?  Also, there are 2 "Error" lines in the header.

I agree. The extra header and footer lines surrounding exploder messages are,
IMHO, distracting and unnecessary.

-Henning


From JZ01%swtexas.bitnet@Csa3.LBL.Gov Xxx Oct x xx:xx:xx 1991
From: JZ01%swtexas.bitnet@Csa3.LBL.Gov
Subject:  RE: VxWorks Driver for the National Instruments 1014B
 
Labmert's e-mail address is:
        lambert@sscvx1.bitnet
        lambert@sscvx1.ssc.gov
     
Janusz Zalewski


From tadusa!tadtec!ma@uunet.uu.net Xxx Oct x xx:xx:xx 1991
From: tadusa!tadtec!ma@uunet.uu.net
Subject: Reply address
 
I vote for a vote !  I would vote for replies to the exploder, or
alternatively...

There could be one group for queries, and one for replies.  The exploder
would send replies to both the asker of the query, and the reply group. 
You could choose whether or not you wanted to subscribe to the reply group.

Maybe this is a bit OTT !


Mark Armitage                email:	ma@tadtec.uucp
Technical Projects Manager   phone: +44 223 423030
Tadpole Technology plc       fax:   +44 223 420772


From voreck@ssd49.ssd.loral.com Xxx Oct x xx:xx:xx 1991
From: voreck@ssd49.ssd.loral.com (Rick Voreck)
Subject: Re: From and Reply exploder addresses
 
Hey, Fellow Explodees,
    In regards to how to mark return addresses on exploder messages,
how about this little excerpt from the "man mail" page :

Reply       (R) Reply to originator. Does not reply to other
	    recipients of the original message.

reply       (r) Takes a message list and sends mail to the
	    sender and all recipients of the specified mes-
	    sage.  The default message must not be deleted.

    If I am not mistaken, this means that if we put the original message
creator in the "From:" field and the exploder in the "cc:" field,
then if you use "r" to respond (as I usually do and apparently most others,
too) then the exploder will get a copy, the originator will get 2 copies 
(slight bug) in the default, and if you want to make a private response,
you just use the alternate response command "R". I have not tested this.
    I think this answers almost all of the concerns I saw voiced on the
exploder except the one about sorting messages by originator.  In that
regard, is there some kind of a homebrew or other utility for this ?
Could it be modified to account for this ?

 _________________________________________________________________________
|									  |
| Rick Voreck				VOICE:  (415) 852-5939		  |
| Space Systems/Loral (M/S G87)		FAX:    (415) 852-6286		  |
| 3825 Fabian Way			E-MAIL: voreck@ssd49.ssd.loral.com|
| Palo Alto, CA  94306							  |
|									  |
|_________________________________________________________________________|


From froloff@pioneer.arc.nasa.gov Xxx Oct x xx:xx:xx 1991
From: froloff@pioneer.arc.nasa.gov (Walt Froloff)
Subject: Re:  From and Reply exploder addresses
 
i concurr with Bill Cruise ... the replies are very helpfull

Walt Froloff

LESC-NASA Life Sciences


From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Subject: Re:  Exploder vs. newsgroup
 
I endorse the idea that we work toward starting a newsgroup
'comp.realtime.vxworks'.  This discussion has taken place at the various
user group meetings and one thing is quite clear:  Many users don't have
the capability or the patience to deal with netnews.  It will be necessary
to have both a newsgroup and an exploder, perhaps with an interconnect.

Alan K Biocca

I have already removed the extra lines prior to the message -- and there is
only one errors-to line on the transmitted message -- something else must be
adding Steve M Burinsky's second one.


From froloff@pioneer.arc.nasa.gov Xxx Oct x xx:xx:xx 1991
From: froloff@pioneer.arc.nasa.gov (Walt Froloff)
Subject: vote to reply-to vxwexploder to we all benefit
 


my vote is to explode replies


walt


From mea@sparta.com Xxx Oct x xx:xx:xx 1991
From: mea@sparta.com (Mike Anderson)
Subject: East Coast VxWorks Users Group Meeting
 
Greetings!

  I have been reviewing the list of confirmed attendees to the East Coast
meeting and I know of several folks who have talked about attending, but 
haven't responded to Christina Goette from WRS as of yet (1 800 545-WIND).
In order for us to properly size the refreshments and lunch, we need to at 
least get a head count (you can then pay at the door).

  For folks who may have been missed by the mailing list or received
blank mail due to exploder illness, here are the details of the meeting:

:::::::::::::::::::::: Begin Included Message ::::::::::::::::::::::::::::
From wrs!mac_smtp!Christina_Goette@uunet.UU.NET Tue Aug 20 14:38:56 1991
Subject: None
To: vxwexplo@Csa2.LBL.Gov

                       Subject:                               Time:10:01 AM
  OFFICE MEMO                                                 Date:8/20/91
Dear VxWorks Users Group Members:

We are pleased to announce that the VxWorks Users Group is planning to meet
again on Tuesday, September 10, 1991, in conjunction with BUSCON East. 
Following is a tentative agenda for the meeting.

		  Welcome
			WRS Update
		  VxWorks Discussion
			Issues Forum/Birds of a Feather
			VxWorks UG Futures Discussion

Mike Anderson of Sparta, Inc. will chair the meeting.  If you have comments or
suggestions, please contact either myself at 800/545-WIND, or  Mike Anderson at
Sparta, 703/448-0210 ext.235 or by e-mail at mea@sparta.com.  If you have any
issues or applications to present, please contact Mike.  

The meeting will be held at:
The Madison Hotel
15th and M Streets Northwest
Washington D.C., 20005
800/424-8577 or 202/862-1740

The meeting is scheduled from 8:30 a.m.- 5 p.m. with luncheon at noon.  The
meeting room will be posted in the hotel lobby under - VxWorks Users Group.  To
cover facility expenses there will be a $50 charge to attend.  Please make
checks payable to the VxWorks Users Group.  

Hotel reservations may be made at The Madison Hotel at a special discounted
rate of $145.    You may call The Madison directly at 800/424-8577 or
202/862-1740 to reserve a room.  Please try to make your reservations by August
23, and be sure to let them know you are with the Wind River Systems group in
order to receive the reduced rate. 

Please be sure to RSVP to me at Wind River Systems, 800/545-WIND or by e-mail
at tina@wrs.com.

Sincerely,
Christina Goette
Wind River Systems, Inc.

:::::::::::::::::::::: End Included Message ::::::::::::::::::::::::::::

  If any of the attendees would be willing to present information about
their VxWorks applications (I've already contacted some of you who were
known to me, but this is a general call) or would like to discuss some 
issue in particular such as why signals under VxWorks are still so
pathetic and what are the users doing to circumvent these problems, please
contact me ASAP.  Those of us in the VxWorks user community are always eager to 
learn from others.  What may seem trivial to you may be decidedly non-trivial
to others.

The current list of speakers and topics looks like:

Jayne Johnson   Hughes Network Systems   Low-level IP-layer efforts on the i960
Patrick Wolf    Duke Univ Med Ctr        Duke's uses of VxWorks
Mike Anderson   Sparta                   device driver issues WRT i960 VxWorks

  We could certainly use 2-3 others to help round out the discussions.  It
doesn't have to be elaborate.

Thanks for your help and patience,

East Coast VxWorks Users Group Meeting Chairman and 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 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 pessamist
				 fears that this is true."

				    J.B. Cabell

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



From steve@titan.tsd.arlut.utexas.edu Xxx Oct x xx:xx:xx 1991
From: steve@titan.tsd.arlut.utexas.edu (Steve Glicker)
Subject: Re:  vote to reply-to vxwexploder to we all benefit
 
I vote _not_ to vote to the vxwexplo mailing list, but perhaps to vxwexplo-request or some other internet address.

-steve


From cruise@cfht.hawaii.edu Xxx Oct x xx:xx:xx 1991
From: cruise@cfht.hawaii.edu (Bill Cruise)
Subject: VxWorks Driver for the National Instruments 1014B GPIB VME card. 
 
We too remain interested in a driver for a National INstruments 1014 GPIB
card. If anyone follows up on Tim Weadon's request, please post it to
the exploder.
 
Our card doesn't have a 'b' suffix, and our system is a SparcEngine. 
However, any vxWorks code is of interest to us.

Bill Cruise
Canada-France-Hawaii Telescope


From fjr@iss-ipc1.ssd.ray.com Xxx Oct x xx:xx:xx 1991
From: fjr@iss-ipc1.ssd.ray.com
Subject: Re:  East Coast VxWorks Users Group Meeting
 
I saw Mike's agenda for the User Group meeting.  I'd like to throw out some
of the issues that we are interested in for consideration:

1) Toolset issues.  WRS plans for GNU support.  GDB policy; use as a task
   level debugger vs use as a system level debugger.  Possible X windows
   gdb version.  Potential profiling type tool support.

2) IO issues.  Need for efficient backplane IO (and possible multiprocessor
    support).  Aynchronous IO plans.  Support for other protocols and
   networks (e.g. XTP and FDDI).

3) Timing issues.  Support for synchronized time (possibly using NTP or
   XNTP).  Support for finer grained clock or possible countdown type
   scheduling.

4) Future release plans.  Plans for bug fixes vs major feature releases vs
   releases that are just for new target/host pairs.  Some idea of planned
   additions and their priorities.  Best methods for bug fix propagation.

5) Reliable system support.  What is planned to increase system reliability
   or allow improved error recovery.  As an example, how could resource
   reclamation be supported (e.g. memory recovery on process termination).

6) VxWorks archive status.  Wondering why archives of Exploder traffic
   no longer available.

7) Support for program unload allowing debugging using a load - test -
   unload development cycle.

8) VxWorks and Ada.  Usage level and interest in VADSWorks.

I realize this list is pretty rough but just thought it might serve as a
start for people to put together lists of other subjects there is interest
in discussing at next weeks user group meeting.  See everyone there.

    ______________________________________________________________
   |  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 OWENS@lodtm.llnl.gov Xxx Oct x xx:xx:xx 1991
From: OWENS@lodtm.llnl.gov
Subject: use of exploder
 
Since a separate address is provided for comments (ie. which address
goes where .. etc.) it would be appreciated (by me, anyway) if this
sort of thing could be kept off of the regular exploder.  It's getting
to be something of a bother to search through 15 or so messages I am
getting each day just to find the one or two that actually deal with
software/hardware issues.

  Thanks,
  Doug Owens


From hebo@mbari.org Xxx Oct x xx:xx:xx 1991
From: hebo@mbari.org (Bob Herlien)
Subject: Re:  East Coast VxWorks Users Group Meeting
 
Fred Roeber brings up a number of good issues for discussion at the East
Coast meeting.  Kind of makes me wish I were going.  I hope someone posts
a good summary onto the exploder.  Here's some more thoughts:

1) NTP.  I now have NTP sort of working on VxWorks.  I ported ntp, rather than
   xntp, because (a) it's smaller, and hence an easier port, and (b) xntp
   requires async I/O, which isn't available in VxWorks.  It's not in
   good enough shape yet to release to the archives, but I'll share it
   with anyone who can't wait.  I'm still considering a port of xntp
   (which conforms to version 2 of the NTP spec; ntp conforms to version 1).

2) Toolsets.  We're still waiting for gdb support on HP.  I'm very interested
   in WRS's long-term plans for tools and for HP support.

3) I'd like to see a change to sysClkConnect() and sysAuxClkConnect().
   Currently, you can't ADD yourself to the list of routines to be called
   at a clock tick; you can only REPLACE the routine that was called.
   Sure, you can call your function from usrClock(), but then your routine
   must be linked into the system; it's not loadable.  I'd like the
   connect functions to maintain a list of functions to call, and call
   them all at the clock tick.  Not too hard to do.  You can then also
   add a sysClockDisconnect() call.

4) A pet peeve of mine.  The directory structure of config/all and 
   config/target sucks.  config/all/configAll.h assumes you only have
   one target.  We have 4 target CPU's from 2 different vendors.  I've
   mercilessly hacked our Makefiles to look for different configAll's
   but it's non-standard.  Here's one vote for moving configAll.h into
   config/target and doing away with config/all.

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Subject: Double Articles, etc
 
DO NOT SUBMIT to vxwexplo-list@vxw.ee !!

Some of you may have noticed double-notes from some submitters, or notes that
did not come from the exploder but came from the submitter.  This happens when
the submitter incorrectly sends to vxwexplo-list@vxw.ee.  This may also happen
if the submitter does a 'reply all'.  Please DO NOT send via the -list
address -- this is an internal list address and it causes the sender to
receive all errors, skips the automatic archiving process, etc, and undermines
the new exploder capabilities.  

We realize (especially now) that not everyone agrees on how the addressing
should work on the exploder -- please send comments to the -request address,
we are collecting them.  We have received and processed a large number of
'unsubscribe' requests lately, so apparently lots of folks don't want to hear
about how to run the exploder, so lets keep the exploded comments to a real
low level.  How about this -- if you really want to explode your comments
on the exploder, you also must put a vxworks-related general-information
paragraph in the note just to keep the traffic on subject.

For those who have read this far I have a question -- is there much interest
in a speeded up float-to-ascii conversion routine?  We have done one that
uses the 68881/2 coprocessor and is vastly faster than vxWorks sprintf, 
though not as flexible.  We use it for writing floating point to ascii type
data files.  Any interest?  If so email me at AKBiocca@lbl.gov.

One more tidbit -- we are working on setting up anon ftp to make available
the exploder traffic -- it is being automatically archived in one month chunks
with an annual index.  In a few days I'll review all the exploder comments
received so far and make some adjustments to the exploder operations.

Thanks,

	Alan K Biocca  (AKBiocca@lbl.gov)


From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Subject: sublist exploders
 
We encourage users to form exploder sublists at their sites and make this
system more responsive and efficient for the vxworks community.  There are
already a number of such lists that help deliver our traffic.

One down side of this is bad addresses that exist on the sublists.  I need to
develop a list of the sublists so I can refer change requests and bouncing
addresses to the proper sublist.  This database will contain the mailing
address of the sublist and the mailing list of the local administrator
of the sublist.

In order to develop this list I request the sublist administrators to send
this info to vxwexplo-reqeust.

Thanks, 

	Alan K Biocca


From wrs!yuba!ricks@uunet.uu.net Xxx Oct x xx:xx:xx 1991
From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek)
Subject: Re:  configAll.h
 
Bob Herlien,

RE: configAll.h sucks

Hmmm...
We have over 50 targets in our config directory and it works fine for us.
Perhaps there is some mechanism you are misunderstanding?

Rick
ricks@wrs.com


From KADIONIK@frcpn11.in2p3.fr Xxx Oct x xx:xx:xx 1991
From: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik)
Subject:      Re:  configAll.h
 
We use different kinds of target CPU, and he have not problems with
configAll.h .
Perhaps, you may have troubles with the cc compiler because
VxWorks versions >= 5.0.1 use the Gnu cc , the other the cc compiler.

If you have different version of target BSP, be carefull because
they may use different kind of cc comilers (gcc, cc) !

Puisse cela vous aider....
       Sincerely ;

       Patrice Kadionik, doctor engineer student.
       C.E.N.B.G.
       Bordeaux, France.

From hebo@mbari.org Xxx Oct x xx:xx:xx 1991
From: hebo@mbari.org (Bob Herlien)
Subject: Re:  configAll.h
 
Ricks@wrs.com writes:
> Hmmm...
> We have over 50 targets in our config directory and it works fine for us.
> Perhaps there is some mechanism you are misunderstanding?
> 

OK, maybe I don't understand the intended use.  Since ALL targets include
<config/all/configAll.h>, how do you include different VxWorks facilities
in your load image?  Different boards in our system need different levels
of network support (NFS, RPC, none), file systems, etc.  We had one WRS
engineer tell us that we're supposed to create a generic configAll.h, and
#undef the stuff we don't want in config.h for each board.  That is, in my
opinion, bad coding practice; and in fact, violates our internal coding
standards.  Instead, I created different configAll.h's in different 
subdirectories of <config/all>, and hacked Makefile to point to them.

In a similar vein, how do you create different load images for CPU's of
the SAME type?  For each target type there's only one subdirectory and 
hence one Makefile and one config.h.  We have three CPUs of one type,
and need to build systems for each that are configured differently.
I created subdirectories of <config/target> and hacked the Makefile to
understand where it's at and create the vxWorks loadable image in the
subdirectory.

What am I missing?

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From harry@verdix.com Xxx Oct x xx:xx:xx 1991
From: harry@verdix.com
Subject: Re: configAll.h 
 
Rick:

>Bob Herlien,
>
>RE: configAll.h sucks
>
>Hmmm...
>We have over 50 targets in our config directory and it works fine for us.
>Perhaps there is some mechanism you are misunderstanding?
>
>Rick
>ricks@wrs.com

I also need to enable/disable select vxWorks features on a board by board
basis.  Having a single config/all/configAll.h for different boards needing
vxWorks kernels with different features required, for me, some hacking.  
Apparently WRS has evolved a way of supporting multiple and different vxWorks 
kernels since you are able  to configure over fifty targets with different 
vxWorks features using a single all/configAll.h file.

The key here is generating kernels with DIFFERENT features where configAll.h
provides the precompilation information to incorporate these features.  For
example, using all/configAll.h, how does one produce a kernel for one target 
having the vxWorks shell and produce a kernel not having the vxWorks shell 
for another target?

Is your method documented anywhere?  I am unable to find it in your programmers 
guide.  Will you share your method with Bob and I?

harry
harry@verdix.com


From hmp@frc2.frc.ri.cmu.edu Xxx Oct x xx:xx:xx 1991
From: hmp@frc2.frc.ri.cmu.edu
Subject: VxWorks header files
 

I'm discovering more inconsistencies in vxWorks header files, mostly in the
area of function prototype declarations that exist in more than one file.
We've seen other messages to this effect in this group; what I would like to
ask today is how people are working around this, presumbaly until WRS releases
an updated set. So far, I've been commenting out the duplicate declarations,
using an ad hoc method to determine which header file should contain the real
version. In some cases, the declarations are slightly different, so I'm not
real happy with this. What are others out there doing in this regard?

-Henning


From hebo@mbari.org Xxx Oct x xx:xx:xx 1991
From: hebo@mbari.org (Bob Herlien)
Subject: Re: VxWorks header files
 
We've noticed inconsistent header files, too, and have been dealing with it
the same way you have (ad hoc).  In many cases, it's obvious what the
declaration should be (e.g., const was added to the declaration).  Sometimes
you can look at the manual.  But it sure would be nice to get an authoritative
update from WRS.

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From lambert@grumpy.ssc.gov Xxx Oct x xx:xx:xx 1991
From: lambert@grumpy.ssc.gov (David Lambert)
Subject: VxWorks header files
 
We have had the same sort of problems. The "ANSIfication" of the header
files seems to be the base of the problem. All WRS fixes so far, are:
"patch and wait for the next release". Fortunately, so far, all are easy to
work around. At least WRS have given us most ANSI headers. We have had to
make our own for our host (SUN)!
Next: How about a C++ class library for VxWorks?


From fjr@iss-ipc1.ssd.ray.com Xxx Oct x xx:xx:xx 1991
From: fjr@iss-ipc1.ssd.ray.com
Subject: Re: configAll.h
 
Bob Herlien had some problems using configAll.h.  WRS gets it to work.
We also support multiple boards and don't find it too bad.  The key is
to set the "default" configuration in configAll and then use the local
config.h file to tailor the default to the particular board by using
a set of #define and #undefine statements.  It is a bit of a pain to
figure out all the possible option settings although it helps that all the
options start with "INCLUDE_".  It probably would be helpful if Wind River
included a brief synopsis of all the INCLUDE variables, their purpose, and
their default settings.     
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 cruise@cfht.hawaii.edu Xxx Oct x xx:xx:xx 1991
From: cruise@cfht.hawaii.edu (Bill Cruise)
Subject: VxWorks header files
 
>>   Subject: VxWorks header files
>>   Submitted-By: lambert@grumpy.ssc.gov (David Lambert)

>>   Next: How about a C++ class library for VxWorks?

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

Yes, please do full C++ support for vxWorks.  
 
The present system is to get the ANSI headers from the archive, put in
some C++ wrappers, and then keep tweeking this mess when bugs appear.
Also, each user must go through the experience of finding out which
C++ features work and which don't work in the target environment.
Some can be hacked in with workarounds (anyone interested in new,
free, or stdargs?), but many neat features are just not available to
us.
 
Any other votes for C++ support?  
This seems to be the time on the exploder when we vote.

Bill Cruise
Canada-France-Hawaii Telescope


From mclark@lodestar.gb.nrao.edu Xxx Oct x xx:xx:xx 1991
From: mclark@lodestar.gb.nrao.edu (MARK H. CLARK)
Subject: VxWorks header files
 

Yes, one strong vote for full C++ support for vxWorks.  I have been
delaying working on vxWorks and doing all my prototyping on our
host machines in C++ while waiting for vxWorks to give me the
compiler and proper header files.

					Mark H. Clark
					mclark@nrao.edu
					National Radio Astronomy Observatory
					P. O. Box 2
					Green Bank, WV 24944-0002



From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Subject: Re:  configAll.h
 
One solution to the multiple configuration problem is to use the provided
shadow facility from WRS.  This tool creates a mirrored directory structure
that contains links to the real files in the original structure.

To use that in this context you create shadows at the ../config directory
level, one for each target-group that will share a common configAll.h
arrangement -- a common set of facilities.  This is probably a smaller
collection since many targets will need the same facilities.

These shadow subdirectories would be named appropriately to reflect their
group-characteristics, perhaps like '../config_full', 'config_no_nfs', 
'config_nfs', etc.  

After building the shadow directory go into the shadow's config/all subdir,
where you'll find links to all the files including configAll.h.  Convert
configAll.h to a real file and change it according to the requirements.
Go to the target cpu subdirectory of the shadow tree and make the new
vxworks.

This requires no makefile hacking -- in fact you only have one copy of each
makefile and everything else uses symbolic links to share those copies.

The shadow tool is very useful to solve many classes of problem like this 
one.

Alan K Biocca
BEVALAC Controls Group


From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Subject: Re:  configAll.h
 
One solution to the multiple configuration problem is to use the provided
shadow facility from WRS.  This tool creates a mirrored directory structure
that contains links to the real files in the original structure.

To use that in this context you create shadows at the ../config directory
level, one for each target-group that will share a common configAll.h
arrangement -- a common set of facilities.  This is probably a smaller
collection since many targets will need the same facilities.

These shadow subdirectories would be named appropriately to reflect their
group-characteristics, perhaps like '../config_full', 'config_no_nfs', 
'config_nfs', etc.  

After building the shadow directory go into the shadow's config/all subdir,
where you'll find links to all the files including configAll.h.  Convert
configAll.h to a real file and change it according to the requirements.
Go to the target cpu subdirectory of the shadow tree and make the new
vxworks.

This requires no makefile hacking -- in fact you only have one copy of each
makefile and everything else uses symbolic links to share those copies.

The shadow tool is very useful to solve many classes of problem like this 
one.

Alan K Biocca
BEVALAC Controls Group


From scotth@rocco.labs.tek.com Xxx Oct x xx:xx:xx 1991
From: scotth@rocco.labs.tek.com
Subject: Re: VxWorks header files 
 
> Next: How about a C++ class library for VxWorks?

This is an interesting topic. Has anyone built such a library? We (Tektronix)
are working on a handful of data structures, tools, and application-domain-
specific class libraries that will be used with VxWorks, but no object-
oriented interface to VxWorks itself, yet.

I'd be interested in a discussion of what such a library would look like, what
model(s) of intertask synchronization/communication might be supported on top
of VxWorks primitives, etc..

I'm also interested in how other developers are approaching problems specific
to embedded systems where some special constraints exist. Here are a couple
issues worth discussing:

  - proprietary hardware; memory areas are not contiguous;
  - total memory size is limited, esp. RAM. System executes
    out of ROM; unused functions should not be linked;
  - constant objects should be in ROM;
  - efficient ways to write C++ code so that an unnecessarily expensive
    processor is not required to make the system "fast enough" and so that
    unnecessary memory requirements are eliminated.

The first two problems aren't C++ specific, but new solutions are possible and
necessary. The second issue is especially important: It is common practice to
implement many member functions in a single source file which is compiled to
produce a single object file. The UNIX a.out object file format and linker
don't support function granularity so the entire object file is linked even if
only one or two functions are used.

This is a common problem when using C++ class libraries.

The third problem has several dimensions. One is the desire to place invariant
data in ROM. The problem is that objects need to be constructed, initially. 
These implies run-time semantics and RAM. However, once constructed, they
remain unchanged, so it would be nice to put them in ROM.  Besides the "it
would be nice" reason, it is essential to minimize initialization time that an
user must wait when the instrument is powered on.  This can be several minutes
on some instruments' software when constructing complex networks of global
objects. Not a good selling point!

Do this topics interest others? Discussion?

Scott Herzinger   scotth@crl.labs.tek.com
                  Computer Research Lab, Tektronix, Inc.
                  PO Box 500 MS 50-662, Beaverton, OR 97077


From OWENS@lodtm.llnl.gov Xxx Oct x xx:xx:xx 1991
From: OWENS@lodtm.llnl.gov
Subject: 68040 floating point
 
This goes back to my interest in developing loadable programs with the
gcc compiler .. thanks to all that replied.  It turns out I had problems
getting ld to create an output file because the -o option was in
the wrong place in the command line.  This a.out type file was still
not quite what I wanted but I did manage to produce a loadable image
from it.  The main reason I want to be able to do this sort of thing
is to test some routines on a 68040 board (MVME 167), since vxWorks
is not yet available, I was looking for an alternative method to
load and test (benchmark) software.  I am using an MVME147 with the
Motorola ROMs at the present time since the 167 has not arrived.  These
ROMs provide an environment suitable for executing simple programs ( I
am hoping the 167 ROMs are similar ).

  In the meantime I have been reading the literature on the 68040 and
its floating point capabilities.  It does not provide the transcendentals
and this is not a problem in my application.  More bothersome is the
lack of FINT and FINTRZ which seem to show up regularly in gcc generated
code.  Is there a compiler available which can generate inline floating
point code compatible with the 68040?

  Thanks,
  Doug Owens   Lawrence Livermore National Lab 


From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Subject: fast float to ascii FPU function
 
There was quite a bit of interest in the fast floating to ascii routine
I mentioned last week, and it is fairly short, so I'll put it out here.

Send comments to AKBiocca@lbl.gov.

Alan K Biocca



/* here is a fast floating point to ascii converter we developed for the
** BEVALAC control system for storing control system state.
**
** This work done by Loren Shalz, Alan Biocca, and Maurice McEvoy.
**
**
** ftoa converts float to decimal ascii using the MC68881/2 Floating_Point
** Coprocessor.  It utilizes a single line of assembly language to access
** the FPU's floating point to packed BCD.  The remainder of the code is
** written in C.  The WRS 5.0.1 release gnu cross tools were used (based
** on gcc 1.37).  Your mileage may vary -- TEST THESE ROUTINES THOROUGHLY.
**
** ftoa must be compiled with the gnu compiler because cc's assembler
** does not recoginze the k factor(precision) in the inline fmovep command.
**           cc68k -c -o ftoa.vx ftoa.c
**
** If any code before the fmovep is changed be sure to get the assembler
** output and verify that value has been put into fp0, that a3 still
** has the address of packed_bcd and that d4 still has precision.
** Adjust fmovep appropriately if any changes are observed.
**
** See the MC68881 Floating-Point Coprocessor Users Manual for the
** packed decimal real format produced by the fmovep. The following
** defines aid in cracking that format to produce the decimal ascii.
*/

#define MANTISSA_SIGN ( ( unsigned char ) ( 1 << 7 ) )
#define EXPONENT_SIGN ( ( unsigned char ) ( 1 << 6 ) )
#define NAN_BITS      ( ( unsigned char ) ( 3 << 4 ) )
#define ASCII_ZERO    ( ( unsigned char ) 0x30 )
#define RIGHT_NIBBLE  ( ( unsigned char ) 0xf )
#define NIBBLE_SIZE   ( ( unsigned char ) 0x4 )
#define PACKED_BCD_SIZE  12

int
ftoa( value, precision, width, string )

float value;		/* value to be converted to decimal ascii */

int precision;          /* 1 <= precision(no. significant digits) <= 17 */

int width;              /* minimum size of returned string.  String is left */
			/* adjusted with blank fill if necessary */

char *string;		/* pointer to string to receive converted value */
                        /* format returned is [-]d.dddddddddddddddde[-]ddd */
			/* so string should be sized to hold at least the
			/* larger of width or  precision + 7 characters */
			/* plus a terminating null. Trailing zeros in the */
			/* mantissa and zero exponents are dropped */

/* ftoa returns the length of string */

{
    unsigned char packed_bcd[PACKED_BCD_SIZE];

    register float v = value;
    register int p = precision;
    register int w = width;
    register char *s = string;
    register unsigned char *c = &packed_bcd[0];
    int i;
    int trailing_zeros;
    int trailing_blanks;
    int right_adjuster;
    unsigned char next_digit;

    asm( " fmovep fp0,a3@{d4}" );	/* convert to packed bcd. */

    if ( precision < 1 ) precision = 1;
    if ( precision > 17 ) precision = 17;

    if ( ( c[0] & NAN_BITS ) != 0 )
    {
	strcpy( s, "NAN" );
	return;
    }

/* unpack mantissa--always return at least 1 digit and '.' */

    if ( ( c[0] & MANTISSA_SIGN ) != 0 ) *s++ = '-';	/* mantissa sign */
    *s++ = ( c[3] & RIGHT_NIBBLE ) + ASCII_ZERO;	/* most sign. digit */
    *s++ = '.';						/* decimal point */

    trailing_zeros = 0;
    --precision;			/* 1st digit unpacked above */
    right_adjuster = NIBBLE_SIZE;
    c = &packed_bcd[4];
    for ( i = 0; i < precision ; ++i )	/* unpack rest of digits */
    {
	 next_digit = ( c[i/2] >> right_adjuster ) & RIGHT_NIBBLE;

	if ( next_digit == '\0' )
	    ++trailing_zeros;
	else
	    trailing_zeros = 0;

	*s++ = next_digit + ASCII_ZERO;

	if ( right_adjuster == 0 ) 
	    right_adjuster = NIBBLE_SIZE;
	else
	    right_adjuster = 0;
    }
    s = s - trailing_zeros;

/* unpack exponent--drop it if it is zero.  */

    c = &packed_bcd[0];
    if ( ( ( next_digit = ( c[0] & RIGHT_NIBBLE ) ) + c[1] ) != 0 )
    {
        *s++ = 'e';					/* nonzero exponent */
        if ( ( c[0] & EXPONENT_SIGN ) != 0 ) *s++ = '-';

        if ( next_digit  != 0 )
        {
            *s++ = next_digit + ASCII_ZERO;		/* 3 digit exponent */
            *s++ = ( c[1] >> NIBBLE_SIZE ) + ASCII_ZERO;
        }
        else if ( ( next_digit = ( c[1] >> NIBBLE_SIZE ) ) != 0 )
            *s++ = next_digit + ASCII_ZERO;		/* 2 digit exponent */

        *s++ = ( c[1] & RIGHT_NIBBLE ) + ASCII_ZERO;	/* 1 digit exponent */
    }

    if ( ( trailing_blanks = width - ( s - string ) ) > 0 ) /* blank pad */
        for ( i = 0; i < trailing_blanks; ++i )
	    *s++ = ' ';
    *s = '\0';
    return s - string;
}


From maf@verdix.com Xxx Oct x xx:xx:xx 1991
From: maf@verdix.com
Subject: Re: VxWorks header files 
 
> I'm also interested in how other developers are approaching problems specific
> to embedded systems where some special constraints exist. Here are a couple
> issues worth discussing:
> 
>   - proprietary hardware; memory areas are not contiguous;
>   - total memory size is limited, esp. RAM. System executes
>     out of ROM; unused functions should not be linked;
>   - constant objects should be in ROM;
>   - efficient ways to write C++ code so that an unnecessarily expensive
>     processor is not required to make the system "fast enough" and so that
>     unnecessary memory requirements are eliminated.
> 
> The first two problems aren't C++ specific, but new solutions are possible and
> necessary. The second issue is especially important: It is common practice to
> implement many member functions in a single source file which is compiled to
> produce a single object file. The UNIX a.out object file format and linker
> don't support function granularity so the entire object file is linked even if
> only one or two functions are used.
> 
> This is a common problem when using C++ class libraries.
> 
> The third problem has several dimensions. One is the desire to place invariant
> data in ROM. The problem is that objects need to be constructed, initially. 
> These implies run-time semantics and RAM. However, once constructed, they
> remain unchanged, so it would be nice to put them in ROM.  Besides the "it
> would be nice" reason, it is essential to minimize initialization time that an
> user must wait when the instrument is powered on.  This can be several minutes
> on some instruments' software when constructing complex networks of global
> objects. Not a good selling point!

As a tool vendor selling Ada into the embedding systems community, we (Verdix)
have faced this exact set of problems. To provide our customers with the kind
of tools they wanted, we developed our own object format (based on a.out) and
linker.

To address the non-contiguous memory problem, the linker allows separate
specification of location for each section of each object file.

The linker permits mapping of sections to locations in ROM and RAM. Runtime
support is used to copy from ROM to RAM, if desired (see static data issues
below).

Our Ada compiler emits one object file for each Ada package, resulting in a
similar scenario in which many unused functions are linked in. To combat
this problem, our compiler generates additional information into our object
files which allows our linker to selectively eliminate routines (and data)
which are not referenced.

The data initialization/storage problem requires close cooperation between
compiler, linker, and runtime. Storing invariant data in ROM can be safely
achieved if the compiler knows the value of an object at compilation time
and also knows that the object will never change. In Ada, an object can be
declared explicitly as a "constant", even if its value is potentially
dynamically determined. Exactly which initializations a compiler can
reduce to statically initialized constants will depend on the compiler's
optimization capabilities.

Of course, we also want to initialize static objects which are not constants.
While the same compilation techniques are used to determine their initial
values, they cannot be stored in ROM because they must be writable. By
adding an additional "constants" section to our object format, we allow our
compiler to distinguish between true constants and static data. The linker
then allows separate specification of ROM locations for constants and static
data. For static data, a second location is given in RAM and runtime code
is used to copy the static data from ROM to RAM.

Concern about static initialization (called "pre-elaboration" in the Ada
community) has been significant enough that we recently added a directive
to our compiler which allows users to request generation of warnings for
any initialization that requires code generation.

I don't know how well these approaches would map onto C++, particular those
regarding constants and initialization. Ada allows explicit identification
of invariant data and associates an implicit (potentially null) initialization
with every entity. I don't know if C++ compilers receive sufficient information
for them to perform this type of optimization.

Marc Friedman
maf@verdix.com


From maf@verdix.com Xxx Oct x xx:xx:xx 1991
From: maf@verdix.com
Subject: Re: East Coast VxWorks Users Group Meeting 
 
> 4) A pet peeve of mine.  The directory structure of config/all and 
>    config/target sucks.  config/all/configAll.h assumes you only have
>    one target.  We have 4 target CPU's from 2 different vendors.  I've
>    mercilessly hacked our Makefiles to look for different configAll's
>    but it's non-standard.  Here's one vote for moving configAll.h into
>    config/target and doing away with config/all.

The all directory works well when one needs to build similar systems for
different targets.

I prefer the approach of using multiple all directories when differently
configured systems are required.

Marc Friedman
maf@verdix.com


From biocca@bevsun.bev.lbl.gov Xxx Oct x xx:xx:xx 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
To: vxworks_users
Subject: Subnets

The current vxWorks system requires multi-cpu crates to dedicate a whole
subnet to the backplane to communicate with the secondary processors there.
In many cases this is an undesirable waste of address space -- using 250+
addresses for one or two secondary processors.

One solution is referred to as 'proxy arp'.  In this mode the gateway cpu
recognizes more than one IP address on the its ethernet port and relays
these packets to the subsidiary processors on the secondary net.  It is then
acting as a 'bridge', in effect.

Is there much interest in this problem within the exploder community??

Alan K Biocca
BEVALAC Controls Group


From rg@msel.unh.edu  Wed Sep 11 17:00:25 1991
From: rg@msel.lbl.gov (Roger Gonzalez)
Date: Wed Sep 11 17:00:32 PDT 1991
Subject: Re: Subnets
> 
> The current vxWorks system requires multi-cpu crates to dedicate a whole
> subnet to the backplane to communicate with the secondary processors there.
> In many cases this is an undesirable waste of address space -- using 250+
> addresses for one or two secondary processors.

The Powers That Be have decreed that I may not have a subnet, because it
wastes too many addresses.  (Our subnet mask is 255.255.252.0.  Argh.)

Is it possible to use some "officially unassigned" throwaway addresses
for the backplane subnet?  Is there any address range that is designated
as temporary local addresses?  I was planning on using 90.0.0.*, having
my development system route all such addresses to the vxworks cage(s), and
also having a bridge upstream from me filter out all accesses to these
addresses.  (What is 90.0.0.*?  Anyone I might want to talk to? :-)

a) Would this work?
b) Is it a good idea?

I haven't had to try this yet because we still only have one target CPU.
We're planning on using passels (passles?) of them, though, so count me
in as another person interested in faster backplane communications!


-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
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)



From wrs!yuba!ricks@uunet.uu.net  Wed Sep 11 19:48:47 1991
From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek)
Date: Wed Sep 11 19:48:53 PDT 1991
Subject: Re: configAll.h
OK.

The intended use of the files all/configAll.h and target/config.h:

The combination of these two files, at compile time, determines the final
configuration of the vxWorks executable image. The optional modules that
may be added on top of the base kernel are specified in these files. Examples
are the shell, and network support.

The configAll.h file is used to define a standard baseline of functionality
that is to be shared between all targets that you work on. The delivered
version of this file is the same as the file used at WRS on a daily basis.
In this version, most features are "turned on". This is because we must test
these features on all targets, if applicable.

The config.h file is used to alter the baseline for a specific target, or
specific functionality set within targets. In this file, additional features
can be "turned on". Baseline features can also be "turned off", which is done
by the (dreaded) #undef statement.

If the "turn off feature" mechanism is distasteful to you, or you find that
you are turning off too many features, there is a simple solution. Simply edit
configAll.h and create your own baseline. You may even wish to deselect *ALL*
features! Note that when deselecting a feature in this file, do not erase the
line that selects it. Instead *move* the line down into the EXCLUDE area,
where it will not be compiled, but is still readily available for viewing.

An important point to note is that both the header files we have been
discussing are delivered in source form to you. This means you are free to
modify them however you wish to suit your tastes or peculiar environment. If
you do stike out on your own, keep in mind that you may make support issues
difficult.

If our documentation did not explain this mechanism effectively, our
apologies. Configuration management is an important issue here at WRS. We are
always looking at ways to make all our lives easier.

Rick



From smb@afterlife.ncsc.mil  Wed Sep 11 22:41:01 1991
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Date: Wed Sep 11 22:41:07 PDT 1991
Subject: Re:  Subnets
  Date: Wed, 11 Sep 91 15:45:56 PDT
  From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
  Subject: Subnets
  Submitted-By: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
  
  The current vxWorks system requires multi-cpu crates to dedicate a whole
  subnet to the backplane to communicate with the secondary processors there.
  In many cases this is an undesirable waste of address space -- using 250+
  addresses for one or two secondary processors.

Am I missing something here?  Netmasks need not align with octet boundaries.
You could specify your netmask to be 0xfffffffe, which creates a subnet
containing only 2 hosts.
  
  **********
  
  This is a user group mailing list for vxWorks related topics
  
  Submit articles to vxwexplo@lbl.gov for 'explosion'
  
  Send subscription requests & comments to vxwexplo-request@lbl.gov
    
Could we please dispense with this annoying advertisement!

Steve


From smb@afterlife.ncsc.mil  Wed Sep 11 22:55:02 1991
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Date: Wed Sep 11 22:55:08 PDT 1991
Subject: Re: Subnets
  Date: Wed, 11 Sep 91 17:00:35 PDT
  Subject: Re: Subnets
  Submitted-By: rg@msel.lbl.gov (Roger Gonzalez)
  
  Is it possible to use some "officially unassigned" throwaway addresses
  for the backplane subnet?  Is there any address range that is designated
  as temporary local addresses?  I was planning on using 90.0.0.*, having
  my development system route all such addresses to the vxworks cage(s), and
  also having a bridge upstream from me filter out all accesses to these
  addresses.  (What is 90.0.0.*?  Anyone I might want to talk to? :-)

From what I can find at nic.ddn.mil, the class A network 90.0.0.0 has not
been assigned (yet).  If you are connected to the internet, one of the
rules you must abide by is using only registered addresses.  If I chose
to use the network number 128.3.0.0 for my VxWorks cage(s), you folks
at lbl.gov would be a bit miffed because I would be using addresses
reserved for your use.  There are plenty of unassigned addresses, but
none of them are throw-aways.  The internet lives with a single, 32-bit
address space.  Just play in you own little (reserved) corner, please :-).

Steve


From bernard@aar.alcatel-alsthom.fr  Thu Sep 12 05:49:09 1991
From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
Date: Thu Sep 12 05:49:15 PDT 1991
Subject: TAS problem ?

It seems I have problems with multi-processor TAS on MV147:

/*---------------------------------------------------------------------------*/

target 1                             target 2    

char tasByte                         tasBusAdr = offset (target1) + &tasByte

while ( vxTas (&tasByte) == 0 );     while ( sysBusTas (tasByteAdr) == 0 );
                                
.                                    .
. using critical resource            .
. (no blocking operations)           .

tasByte = 0                          *tasByteAdr = 0

/*---------------------------------------------------------------------------*/

... it works a few moments and then target1 and target2 loops
in the while statement. Can anybody help ?


Thanks for comments, any help would be appreciated ..

  -- Olivier


 -----------------------------------------------------------
!                                                           !
! Olivier BERNARD                                           !
! Alcatel Alsthom Recherche                                 !
! Route de Nozay                                            !
! 91460 Marcoussis                                          !
! France                                                    !
!                                                           !
! mail: bernard@aar.alcatel-alsthom.fr                      !
!                                                           !
 -----------------------------------------------------------



From bernard@aar.alcatel-alsthom.fr  Thu Sep 12 05:59:53 1991
From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
Date: Thu Sep 12 06:00:00 PDT 1991
Subject: bug with select 5.0
I think there is a bug in the select function with VxWorks 5.0. This
bug seems to occur when file descriptors exceed 31. In this case, select does
the following:

 - waits for an event on file descriptors (OK)
 - returns 1 + (number of file descriptors > 31) - 1 !!
 - flags ALL file descriptors > 31 as ready

 
I join the code which show the problem. Am I doing something wrong or is
it really a bug ? 

Thanks for comments.

-- Olivier

 -----------------------------------------------------------
!                                                           !
! Olivier BERNARD                                           !
! Alcatel Alsthom Recherche                                 !
! Route de Nozay                                            !
! 91460 Marcoussis                                          !
! France                                                    !
!                                                           !
! mail: bernard@aar.alcatel-alsthom.fr                      !
!                                                           !
 -----------------------------------------------------------




/*---------------------------------------------------------------------------*/
                                  PROGRAM
/*---------------------------------------------------------------------------*/

#include "vxWorks.h"
#include "stdioLib.h"
#include "ioLib.h"
#include "types.h"
#include "selectLib.h"
#include "pipeDrv.h"

/*---------------------------------------------------------------------------*/

void selectTest (fdMax)
     int fdMax;
{
  fd_set set;
  int firstFd, fd;
  int res;
  
  FD_ZERO (&set);
  pipeDevCreate ("pipeTest1", 10, 100);
  pipeDevCreate ("pipeTest2", 10, 100);
  
  firstFd = open ("pipeTest1", O_RDWR);
  FD_SET (firstFd, &set);
  printf ("first fd = %d, ", firstFd);

  /* I open file descriptors until fd = fdMax */

  do
    {
      fd = open ("pipeTest2", O_RDONLY);
      FD_SET (fd, &set);
      printf ("fd = %d, ", fd);
    }
  while (fd < fdMax);

  res = select (fd, &set, NULL, NULL, NULL);

  printf ("\nselect = %d\n", res);
  for (fd = firstFd; fd <= fdMax; fd++)
    if (FD_ISSET (fd, &set)) printf ("file #%d ready\n", fd);
}

/*---------------------------------------------------------------------------*/

/* I use this function to send a message to "firstFd" */

void selectSend (fd)
     int fd;
{
  write (fd, "mes", 4);
}



/*---------------------------------------------------------------------------*/
                                  RESULTS
/*---------------------------------------------------------------------------*/

LouisI > sp selectTest,31
LouisI > first fd = 14, fd = 17, fd = 18, fd = 19, fd = 20, fd = 21, fd = 22, 
fd = 23, fd = 24, fd = 25, fd = 26, fd = 27, fd = 28, fd = 29, fd = 30, fd = 31,

LouisI > selectSend 14
value = 4 = 0x4
LouisI >
select = 1                 <- OK, one fd was selected
file #14 ready             <- OK, this fd was # 14


THIS WORKS !!! (no fd > 31)

/*---------------------------------------------------------------------------*/

LouisI > sp selectTest,32
LouisI > first fd = 13, fd = 17, fd = 18, fd = 19, fd = 20, fd = 21, fd = 22, 
fd = 23, fd = 24, fd = 25, fd = 26, fd = 27, fd = 28, fd = 29, fd = 30, 
fd = 31, fd = 32,

LouisI > selectSend 13
select = 1                 <- OK, one fd was selected
file #13 ready             <- OK, this fd was # 13
file #32 ready             <- ERROR !!! this one was not selected !

THIS DOES NO WORK (fd > 31)

/*---------------------------------------------------------------------------*/

LouisI > sp selectTest,33
LouisI > first fd = 13, fd = 17, fd = 18, fd = 19, fd = 20, fd = 21, fd = 22, 
fd = 23, fd = 24, fd = 25, fd = 26, fd = 27, fd = 28, fd = 29, fd = 30, 
fd = 31, fd = 32, fd = 33,

LouisI > selectSend 13
select = 2                  <- ERROR !!, one fd was selected !!
file #13 ready              <- it was this one
file #32 ready              <- ERROR !!
file #33 ready              <- ERROR !!

THIS DOES NOT WORK (fd > 31)

/*---------------------------------------------------------------------------*/





From jjohnson@hns.com  Thu Sep 12 06:06:08 1991
From: jjohnson@hns.com (Jayne Johnson)
Date: Thu Sep 12 06:06:17 PDT 1991
Subject: Re: Subnets 
Yes!yes!yes! 
In the system we're putting together a network of multiple subnets. I
have a similiar situation the current Vxworks networking configuration
is inadequate. The networking in our configuration doesn't have VME to
access other networks , I have T1 bridge. I have been looking into
implementing Proxy Arp also. Yes, I am interested and would like
Vxworks to incorporate this standard.

Please keep me informed. Thanks in advance.

Jayne Johnson
Hughes Network Systems
11717 Exploration Lane
Germantown , Md 20874
tel : 301-428-2714
email : jjohnson@hns.com


From bernard@aar.alcatel-alsthom.fr  Thu Sep 12 06:13:11 1991
From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
Date: Thu Sep 12 06:13:17 PDT 1991
Subject:  f68881


We had this bug a few months ago. I join the answer which helped us
a lot:


  From marc@sun-valley.Stanford.EDU Fri Sep  7 21:45:40 1990
  Received: from crcge1.cge.fr by ouragan.cge.fr, Fri, 7 Sep 90 21:45:39 +0200
  Received: from inria.UUCP by crcge1.cge.fr, Fri, 7 Sep 90 21:45:36 +0200
  Received: from Sun-Valley.Stanford.EDU by inria.inria.fr (5.64+/89.0.8)
	via Fnet-EUnet id AA12929; Fri, 7 Sep 90 18:58:09 +0200 (MET)
  Received: by sun-valley.Stanford.EDU (4.1/inc-1.0)
	id AA13667; Fri, 7 Sep 90 09:39:56 PDT
  From: marc@sun-valley.Stanford.EDU (Marc Ullman)
  Message-Id: <9009071639.AA13667@sun-valley.Stanford.EDU>
  To: bernard@ouragan (Olivier Bernard)
  Cc: vxwexplo@csa1.LBL.Gov
  Subject: Re: problems with IT routines and -f68881 flag 
  In-Reply-To: Your message of "Fri, 07 Sep 90 13:55:12 +0100."
             <9009071155.AA06468@ouragan.cge.fr> 
  Date: Fri, 07 Sep 90 09:39:55 MDT
  Status: R

>
>However this routine can make the system reboot
>if it is compiled with the -f68881 option. You should note that this
>routine does *not* use any float. In fact, as far as I can understand,
>the compiler puts a "FMOVEM.X    #<>,($00000,A6,D0.W*1)" assembler line
>at the beginning of EACH function. Why ? and why does this reboot VxWorks ?
>Moreover, it seems that the system fails on particular conditions 
>(eg: when another task is running, etc ...)
>
>/*---------------------------------------------------------------------------*
> /
>
>// compiled with -f68881 option
>
>                        _auxClkRoutine:
>74f4dc  4e56 0000                LINK  .W    A6,#0
>74f4e0  dffc 0000 0000           ADDA  .L    #$00000,A7
>74f4e6  48d7 0000                MOVEM .L    #<>,(A7)
>74f4ea  f236 f000 0170 0000 0000 FMOVEM.X    #<>,($00000,A6,D0.W*1) // ???????
> ???
>74f4f4  52b9 0074 f500           ADDQ  .L    #1,tickAuxLib.o_data
>74f4fa  7000                     MOVEQ       #$0,D0
>74f4fc  4e5e                     UNLK        A6
>74f4fe  4e75                     RTS
>
>// compiled without -f68881 option
>
>                        _auxClkRoutine:
>74f368  4e56 0000                LINK  .W    A6,#0
>74f36c  dffc 0000 0000           ADDA  .L    #$00000,A7
>74f372  48d7 0000                MOVEM .L    #<>,(A7)
>74f376  52b9 0074 f388           ADDQ  .L    #1,tickAuxLib.o_data
>74f37c  7000                     MOVEQ       #$0,D0
>74f37e  4e5e                     UNLK        A6
>74f380  4e75                     RTS
>
>/*---------------------------------------------------------------------------*
> /
>
>
>So ... don't mix in the same module functions treating floats (and thus
>needing the -f68881 flag) with functions called at interrupt level ... (am I r
> ight)
>
>
>Any comments ?

This is a well known problem.  The cause:  YOU ARE USING THE WRONG COMPILER!
Use GCC rather than CC.  CC, in is infinite wisdom, sticks unecessary floating
point instructions in every subroutine and does not remove them unless you
turn on optimization (-O) which unfortunately you can't do if you need the -g
option (in case you are using dbxWorks).  The reason the system reboots (or
hangs) is that the ISR is being invoked while the 68881/2 is in the middle of
executing a FP instruction.  In order to save the state of the FP coprocessor
so that the interrupted FP instruction can be resumed, a FSAVE instruction
must be executed BEFORE any new floating point operations can be performed.
Failing to do so will cause the CPU to issue FP coprocessor Protocol Violation
exception which is bad news.

If your ISR really neeeds to do FP operations, it has to execute an FSAVE
instruction in its prolog.  (I believe WRS has added an option to intConnect
that now allows you to do this).  When switching tasks, this step is performed
for you automatically by the kernel when the new task has the FP_USED bit set.

--Marc Ullman
  Stanford University



From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Thu Sep 12 06:17:48 1991
From: fjr@iss-ipc1.ssd.ray.com
Date: Thu Sep 12 06:17:55 PDT 1991
Subject: Re: Subnets
The subject of subnets was addressed at the East Coast user group meeting
this week.  Mike Anderson gave a very good talk on how to set up networking
by dedicating a class C IP address to each crate and each network.  For
those who can't afford to do this and need to use subnets to conserve
IP addresses, Dave Wilner of Wind River said that they were going to be
putting in the proxy arp support that would allow people to use one IP
address without having to explicitely set up subnets.  A few months ago
we went through the grief of setting up subnetting correctly.  It was not
trivial to get it all working since nobody seems to have written down all
the rules that must be followed (we did get a lot of good pointers from
people on the exploder and usenet).  Using proxy arp would be the easiest
approach if you can wait for the WRS implementation.  It was not clear to
me when that might be available.   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 hmp@frc2.frc.ri.cmu.edu  Thu Sep 12 06:40:00 1991
From: hmp@frc2.frc.ri.cmu.edu
Date: Thu Sep 12 06:40:08 PDT 1991
Subject: Re: VxWorks header files 

>
>We have had the same sort of problems. The "ANSIfication" of the header
>files seems to be the base of the problem. All WRS fixes so far, are:
>"patch and wait for the next release". Fortunately, so far, all are easy to
>work around. At least WRS have given us most ANSI headers. We have had to
>make our own for our host (SUN)!

Would you be willing to share those SUN header files with us? 

-Henning


From mkannan@hns.com  Thu Sep 12 07:15:37 1991
From: mkannan@hns.com (Mangala Kannan)
Date: Thu Sep 12 07:15:47 PDT 1991
Subject: Re: Subnets 

 I am very much interested in knowing about this. I raised a question in the 
 East coast users group meeting to know more about it.  We have
multiple interfaces in our project for which this concept might be
useful. Please keep 
me posted. Thanks in advance

Mangala Kannan
Hughes Network systems
11717 Exploration Lane, Germantown MD 20878

email : mkannan@hns.com

mangala


From hill@luke.atdiv.lanl.gov  Thu Sep 12 08:02:46 1991
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Thu Sep 12 08:02:53 PDT 1991
Subject: Re:  TAS problem ?
Some huerikon CPUs dont implement vxTas() properly on the VME bus. 
The problem occured because they didnt force the test and set to
occur without intervening VME cycles. The result was a test at the
desired location and a set at a spurious location left by the
last VME access.


From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Thu Sep 12 08:16:48 1991
From: fjr@iss-ipc1.ssd.ray.com
Date: Thu Sep 12 08:16:59 PDT 1991
Subject: Re:  TAS problem ?
Oliver,  It appears that you may be using a local dual port memory location
on one of your boards for the TAS byte.  The alternative would be to use
some location on a global memory card.  With the approach I think you are
taking then the MVME147 has to have the HW support for indivisible operations
and contention from both the backplane and the local processor.  We don't
use 147s but our RADSTONE boards have options (in their VME interface
controller) as to whether to support indivisible operations to local
dual port.  If possible, it is better to put multiprocessor variables
in global memory since it keeps access to the flags from one CPU from
affecting local operation of the other (if the flag is in one procs dual
port, then attempts to get the flag by the other should lock out memory access
from the local CPU too which can really slow down operation).  Hope this
helps.    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 biocca@bevsun.bev.lbl.gov  Thu Sep 12 08:57:21 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Thu Sep 12 08:57:31 PDT 1991
Subject: Re: Subnets

----- Begin Included Message -----

From rg@msel.unh.edu  Wed Sep 11 17:00:25 1991

The Powers That Be have decreed that I may not have a subnet, because it
wastes too many addresses.  (Our subnet mask is 255.255.252.0.  Argh.)

Is it possible to use some "officially unassigned" throwaway addresses
for the backplane subnet?  Is there any address range that is designated
as temporary local addresses?  I was planning on using 90.0.0.*, having
my development system route all such addresses to the vxworks cage(s), and
also having a bridge upstream from me filter out all accesses to these
addresses.  (What is 90.0.0.*?  Anyone I might want to talk to? :-)

a) Would this work?
b) Is it a good idea?

----- End Included Message -----

The best alternative at the moment is to use part of a legal subnet for your
backplane.  To do this set up the vme crate as though it has a legal subnet
for your network.  Set up your host with host routes only for those
specific addresses in use on your backplane, and point those routes to the
vxWorks gateway processor for that crate.  The subnet addresses should be
unique -- they should not be used by any other hosts.

This way you use only as many addresses as you need.  One arrangement is to
have a single subnet assigned to you for all your crates -- you can divide it
up and thus only use one subnet for them all.  Another solution is to use some
addresses from a special purpose subnet.  For example, at LBL we have a
number of point-to-point links that need IP addresses even though no one
ever sees the addresses except the link ends.  A subnet is used for all of 
these addresses and some of them could be used for purposes like vxWorks.

The downside of this solution is that only that host can reach those
secondary processors.  Other hosts needing to reach them must also have
the host routes, and this becomes a maintenance problem if very many are
involved.  Additionally, the secondaries will have difficulty talking with
hosts that are really on the subnet they think they're on -- they'll expect
these hosts to be on the backplane.

We need a better solution, but this does work for now.

----- Begin Included Message -----

Subject: Re:  Subnets
Submitted-By: smb@afterlife.ncsc.mil (Steve M. Burinsky)
 
Am I missing something here?  Netmasks need not align with octet boundaries.
You could specify your netmask to be 0xfffffffe, which creates a subnet
containing only 2 hosts.
  
    
Could we please dispense with this annoying advertisement!


----- End Included Message -----

Steve is correct -- netmasks need not align with octets.  The netmask must
be constant for the net, though, so you cannot move it on the wire unless you
have your own wire.  We ran that way at the BEVALAC for awhile and found that
we had to hack SunOS in our router to handle differing netmasks -- there is
a field in the ifconfig to specify netmask but in the kernel there was only
one variable for all interfaces.  This could be solved by buying a real
router, or perhaps newer SunOS or some other OS would not have this problem.
If you don't have your own wire you can still change the netmask of the
backplane.  Two bits probably isn't enough for most things, because 00 and 11
are reserved for broadcasts leaving only room for two hosts and one must be
the gateway.

The host and routers still have a major problem.  They have difficulty 
differentiating packets headed toward the secondaries and determining which
gateways to point them at.  To do this each route needs its own netmask, or
host routes are necessary (one route for each secondary processor).  Per
route netmasks aren't supported by most workstations, but many routers would
handle this.  Host routes are, as mentioned above, a maintenance hassle.

The biggest problem with all of this is the confusion factor.  It doesn't
seem all that complicated but it turns out to be hard to diagnose problems
and seemingly unimportant changes in configuration often cause subtle problems
or total deadlock.  The vxWorks manager must work closely with site network
administration, and educate them in the complexities of routing lots of small
networks.  I have found in practice that this complexity leads to single-
person maintenance -- backup people cannot debug failures.

I'll condense the advertisement.

Alan K Biocca
BEVALAC Controls Group


From hebo@mbari.org  Thu Sep 12 08:57:25 1991
From: hebo@mbari.org (Bob Herlien)
Date: Thu Sep 12 08:57:37 PDT 1991
Subject: Re:  Subnets
> 
> Am I missing something here?  Netmasks need not align with octet boundaries.
> You could specify your netmask to be 0xfffffffe, which creates a subnet
> containing only 2 hosts.
>   

In answer to Alan Biocca's original question, YES!, we're quite interested
in proxy arping to allow routing through vxWorks.

In response to Steve Burinsky's reply above, I don't know enough about
routing and subnetting to know whether your solution is adequate in general,
but I suspect not.  As an example, let me describe our system.

We have two buildings, a ship, and are building an ROV (robot submarine)
to be deployed from the ship, all of which have or need Internet connectivity.
To get from the outside world to the CPU's on the ROV (doing so is a goal
of the design) requires getting to our router on the Internet, routing via
a T1 microwave link to the ship, going though its router to a vxWorks
crate on board ship, going through a vxWorks-vxWorks SLIP link (using
a 4MB synchronous fiber-optic connection to the ROV), and finally reaching
the vxWorks crate on the ROV, which may have multiple CPU's communicating
via backplane IP.

Our standard subnetting is 8 bits.  We use an 8-bit subnet for each building,
and one for the ship (which has other computers connected to Internet).  I'm
not sure how many subnets I need in the above scenario, but I suspect that it
will not be possible to assign only a 2-bit subnet mask at the final level,
and still be able to reach it from the upstream levels.  Can anybody clarify
for me?  I am interested in proxy arping, aren't I?

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From hebo@mbari.org  Thu Sep 12 09:26:28 1991
From: hebo@mbari.org (Bob Herlien)
Date: Thu Sep 12 09:26:34 PDT 1991
Subject: Re: bug with select 5.0
> 
> I think there is a bug in the select function with VxWorks 5.0. This
> bug seems to occur when file descriptors exceed 31. In this case, select does
> the following:
> 
 [description deleted]

I can verify that there is a select() bug in 5.0.  I haven't been able to
fully characterize it, which is why I haven't turned in a bug report.  But
I can describe its behavior in NTP (Network Time Protocol), which I have 
been porting to vxWorks.

After initialization, the ntpd task goes into a forever loop in which it
calls select() looking for a read from two file descriptors.  When I first
ported it, there were quite a few files open, so the two bits in question
formed the mask 0x11000 (33 bits long).  Things worked correctly; that is,
it would return with a mask of either 0x1000 or 0x10000 (only one read
completes at a time).

I then deleted a couple of open files, and NTP broke!  What happened is
that the readfds mask became 0x5000 (31 bits).  When select() returned,
it always returned both bits set, even though only one read had completed.
I made NTP work by using a global variable to indicate which read really
completed, but the erroneous select() behavior is still there.

My bug report seems to differ from Oliver's though, in that in my case,
it only works if fds > 32, while Oliver says it breaks in that case.
In any case, I'm happy that Oliver has found a test case to demonstrate
the bug.  When WRS fixes the bug, will somebody please post the patch?
I'll then try it out on NTP to see if it's the same bug.  Thanks.

P.S.  NTP is now basically working, with a few bugs.  I'll put it on the
      archive within the next few weeks.

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From biocca@bevsun.bev.lbl.gov  Thu Sep 12 09:33:38 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Thu Sep 12 09:33:46 PDT 1991
Subject: Re:  TAS problem ?

----- Begin Included Message -----

Subject: TAS problem ?
Submitted-By: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
 

It seems I have problems with multi-processor TAS on MV147:

... it works a few moments and then target1 and target2 loops
in the while statement. Can anybody help ?

----- End Included Message -----

A Good quick check of how good the documentation and hardware on a CPU
is to look up TAS in the card's manual.  If they have not included a 
section on this problem area they may not have given enough care to have
solved the tricky problems correctly...

There is a control register on the MV147 that causes TAS to work correctly
with on-board memory.  It effectively causes all TAS instructions to arbitrate
the VME bus even if the address of the location is onboard.  This is required
to insure that TAS is uninterrupted by remote access to local memory.  There 
is a discussion of the problem and solution in the MV147 manuals.

Using external memory avoids this problem since all processors must arbitrate
the VME bus to gain access.

Alan K Biocca
BEVALAC Controls Group


From ddrg%mentor.gandalf.ca@Csa2.LBL.Gov  Thu Sep 12 09:41:35 1991
From: ddrg%mentor.gandalf.ca@Csa2.LBL.Gov (Duncan Glendinning)
Date: Thu Sep 12 09:41:43 PDT 1991
Subject: Re: Subnets
jjohnson@hns.com writes:

> Yes!yes!yes! 
> In the system we're putting together a network of multiple subnets. I
> have a similiar situation the current Vxworks networking configuration
> is inadequate. The networking in our configuration doesn't have VME to
> access other networks , I have T1 bridge. I have been looking into
> implementing Proxy Arp also. Yes, I am interested and would like
> Vxworks to incorporate this standard.
> 
> Please keep me informed. Thanks in advance.
> 
> Jayne Johnson
> Hughes Network Systems
> 11717 Exploration Lane
> Germantown , Md 20874
> tel : 301-428-2714
> email : jjohnson@hns.com

We too woulld be very interested in solving this problem.  Requiring a
private subnet poses a number of problems, particularly when producing
a product that may end up in someone else's network.
-- 
Duncan Glendinning         CAnet: ddrg@mentor.gandalf.ca, ddrg@gandalf.ca
Gandalf Data Ltd.          Voice: (613) 723-6500
Nepean, Ontario              Fax: (613) 226-1717
Canada  K2E 7M4


From marc@sun-valley.stanford.edu  Thu Sep 12 10:32:16 1991
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Thu Sep 12 10:32:22 PDT 1991
Subject: Re: Subnets 

>> Am I missing something here?  Netmasks need not align with octet boundaries.
>> You could specify your netmask to be 0xfffffffe, which creates a subnet
>> containing only 2 hosts.
>>   
>We have two buildings, a ship, and are building an ROV (robot submarine)
>to be deployed from the ship, all of which have or need Internet connectivity.
>To get from the outside world to the CPU's on the ROV (doing so is a goal
>of the design) requires getting to our router on the Internet, routing via
>a T1 microwave link to the ship, going though its router to a vxWorks
>crate on board ship, going through a vxWorks-vxWorks SLIP link (using
>a 4MB synchronous fiber-optic connection to the ROV), and finally reaching
>the vxWorks crate on the ROV, which may have multiple CPU's communicating
>via backplane IP.
>
>Our standard subnetting is 8 bits.  We use an 8-bit subnet for each building,
>and one for the ship (which has other computers connected to Internet).  I'm
>not sure how many subnets I need in the above scenario, but I suspect that it
>will not be possible to assign only a 2-bit subnet mask at the final level,
>and still be able to reach it from the upstream levels.  Can anybody clarify
>for me?  I am interested in proxy arping, aren't I?

We have been using a four bit subnet mask (ffffff0) for over two years.
This provides up to sixteen levels of subnets below one class C network.
We have networks that are curretly four layers deep and they work fine
with full interconnection between every host both on the subnets and
above.  The trick is to get the routing tables set up corectly.  The
VxWorks targets all have a default route to pass any packet destined for
a host they don't know about to the target just upstream.  And they have
a route for each subnet below them specifying that said packets should be
forwarded to the processor immediately down stream of them.

--Marc Ullman
  Stanford University


From SMEG%bnr.ca@Csa2.LBL.Gov  Thu Sep 12 11:15:59 1991
From: SMEG%bnr.ca@Csa2.LBL.Gov (M.A.)
Date: Thu Sep 12 11:16:06 PDT 1991
Subject:    re: Subnets

Here is an IP addressing scheme that may be what you are looking for...

The 127.* network is available for use within your
host only.  Just define your hosts to be the whole rack.
The one thing that you *cannot* do is send or receive a packet
with 127 network source or destination address outside of your
host.

Consider a rack of 4 vxWorks targets, one of which has an
ethernet chip.  Each card talks to the others using backplane
IP with the 127 net addresses.  External equipment can talk
to one of the cards using the external IP address that is
consistent with that sites subnetting scheme.

Of course, if you had an external host that wanted to reach a card
other than card 0 (see diagram below), it would be a two step
operation.  Eg. to log in to the shell on card 2 from a workstation
out on the ethernet, the user would have to rlogin (or telnet) to
card 0 (90.128.0.3) and then rlogin to card 2 (127.0.1.2).

ie. cards 1, 2 and 3 could never send a packet to or receive a packet
from the ethernet directly.

The IP address configuration of the interfaces would be as follows:
(Looking down at the rack from above)

    :---------------------------------------------------------------:
    :   127.0.1.0   :   127.0.1.1   :   127.0.1.2   :   127.0.1.3   :
    :  (backplane)  :  (backplane)  :  (backplane)  :  (backplane)  :
    :---------------------------------------------------------------:
    :               :               :               :               :
    :               :               :               :               :
    :               :               :               :               :
    :               :               :               :               :
    :               :               :               :               :
    :   card 0      :    card 1     :    card 2     :    card 3     :
    :               :               :               :               :
    :               :               :               :               :
    :               :               :               :               :
    :               :               :               :               :
    :               :               :               :               :
    :               :               :               :               :
    :---------------------------------------------------------------:
        47.0.1.2
        (ethernet)

The nice thing is that you only have to configure one IP address
per rack (the externally visible ethernet interface) and your system
knows how to contact each card without configuration.

Hope this helps
...Maarten...

ps. don't assign 127.0.0.1 to a backplane interface, that is typically
    used for local loopback.

--
Maarten Koning - Bell-Northern Research - Ottawa, Canada - smeg@bnr.ca



From biocca@bevsun.bev.lbl.gov  Thu Sep 12 11:19:22 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Thu Sep 12 11:19:30 PDT 1991
Subject: Newsgroup Creation
I have been asked to consider making a Usenet newsgroup Comp.realtime.vxworks.

While I endorse the newsgroup idea, and if one is created will consider
the task of building the connection between the newsreader and the mailing
list (which will shrink but not go away).

I have my hands full with the exploder, however, and someone who is more
familiar with the newsgroup creation process should take that task.

Do we have a volunteer who is experienced with this???

Alan K Biocca
BEVALAC Controls Group


From lapp@waterloo.hp.com  Thu Sep 12 14:07:28 1991
From: lapp@waterloo.hp.com (Dave Lapp)
Date: Thu Sep 12 14:07:35 PDT 1991
Subject: Re:  Subnets
>We have two buildings, a ship, and are building an ROV (robot submarine)
>to be deployed from the ship, all of which have or need Internet connectivity.
>To get from the outside world to the CPU's on the ROV (doing so is a goal
>of the design) requires getting to our router on the Internet, routing via
>a T1 microwave link to the ship, going though its router to a vxWorks
>crate on board ship, going through a vxWorks-vxWorks SLIP link (using
>a 4MB synchronous fiber-optic connection to the ROV), and finally reaching
>the vxWorks crate on the ROV, which may have multiple CPU's communicating
>via backplane IP.
>
>Our standard subnetting is 8 bits.  We use an 8-bit subnet for each building,
>and one for the ship (which has other computers connected to Internet).  I'm
>not sure how many subnets I need in the above scenario, but I suspect that it
>will not be possible to assign only a 2-bit subnet mask at the final level,
>and still be able to reach it from the upstream levels.  Can anybody clarify
>for me?  I am interested in proxy arping, aren't I?

Subnetting should do what you want. The important things are, as someone
already mentioned, getting the routes set up correctly and getting the
subnet masks within your subnetted network correctly set.

Subnetting does everything proxy arp can do and is considered the 'proper'
way of doing things.

If I understand correctly your configuration is something like:

    router (on dry land)
      |
      |
 microwave
  link
      |
      V
    router (on the ship)
      |
   --------------------------------
    |               |            |
    |             Other computers on
    |                  the ship
    |       
 vxWorks crate
  on ship
  |  |    |
  |  |    |
  |  |    |
  |  |    |
        fiber
          to
          ROV
          |
          |
      vxWorks crate
        on ROV
      |   |   |   |
     CPUs in ROV

The way subnetting works is to split a network up (surprise surprise).
It sounds as though you have a class C (or equivalent) range of addresses
assigned to this ship. Lets assume that this network is 193.1.1.0 
To the land based router the ship will still appear to be a single
class C network. What you need is a seperate subnet for each crate and
the another subnet (or maybe more) for the network of host systems on
the ship.

Lets assume that you have no more then 14 CPUs in any one crate.
(Why 14 ? Because its best to avoid hosts with addresses of 0 or 1's :-)
Lets further assume you have no more then 14 systems on the ship
(counting the router and one vxWorks CPU (which is really another
router) but excluding the other CPUs in the crates).
These assumptions aren't needed to make subnetting work but help in
explaining it.

Given these assumptions you can use a subnet mask of 255.255.255.240
This splits your class C network into 16 subnets (193.1.1.0 to 193.1.1.240)
That is subnet 0 has addresses from 193.1.1.0 to 193.1.1.15, subnet 1
has addresses in the range 193.1.1.16 to 193.1.1.31, ... and subnet 16
has addresses in the range 193.1.1.240 to 193.1.1.255.

Now:

1) Assign the backplane interface on th CPUs in the ROV crate addresses 
in the range 193.1.1.0 to 193.1.1.15 (ie. subnet 1 (avoid 193.1.1.0 
and 193.1.1.15 :-))

2) Assign the backplane interface on the CPUs on the ship addresses 
on subnet 2. (Avoid .16 and .31)

3) Assign the all systems on the ship connected to the router (including 
the vxWorks board) addresses on the 3rd subnet. (Avoid ...)

4) Assign the point to point interfaces (ie the 2 ends of the fiber
link and the 2 ends of the microwave link) addresses from the 4th subnet.

5) Set the subnet mask (on all interfaces) for all systems, vxWorks 
CPUs and the router on the ship and ROV to 255.255.255.240.

6) Set a default route on all the CPUs in the ROV pointing to the
board which has the fiber link. (Except the board with the fiber link)

7) Set a default route on the CPU in the ROV which has the fiber link
which points to the other side of the fiber link. (ie the address on 
subnet 4)

8) Set a default route on all the CPUs in the crate on the ship pointing
to the board connected to the router. (Except once again the board
connected to the router)

9) Set a route to subnet 1 on all the CPUs in the crate on
the ship pointing to the board with the fiber link. (Except
the board with the fiber link.)

10) Set a route to subnet 1 on the fiberlink board in the crate on the 
ship which points to the other side of the fiber link. (ie points to
the address of the other end of the fiberlink on subnet 4)

11) Set default routes in all the systems on the ship pointing to 
the router.

12) Set routes to subnet 1 and 2 in all the systems  and the router on 
the ship pointing to the vxWorks board connected to the router.

13) On the router on the ship make the default route point to the
router on land.


The routes on land don't need to change. Its the job of the equipment
on the ship/ROV to route the messages appropriately. 

That (or some variation) should do what you want. That all looks 
pretty complicated but once its set up it should work properly.

Hope I haven't confused you (and that I got it all right :-)

Dave Lapp
lapp@waterloo.hp.com            Standard Disclaimer etc...


From wrs!schuylkill!bob@uunet.uu.net  Thu Sep 12 16:05:01 1991
From: wrs!schuylkill!bob@uunet.uu.net
Date: Thu Sep 12 16:05:08 PDT 1991
Subject: Re: bug with select 5.0 

There is indeed a known bug in VxWorks 5.0 select, which can be worked
around by setting the width argument to select to its maximum value
(FD_SETSIZE = 256).
The bug causes the read and write fd_sets to be zero'ed incorrectly, so the
bits initially set sometimes are incorrectly returned to the user. 
Setting width = 256
will cause all the bits to be zero'ed correctly.

Bob Cohen
Wind River Systems


From wrs!yuba!kent@uunet.uu.net  Thu Sep 12 18:29:56 1991
From: wrs!yuba!kent@uunet.uu.net (Kent Long)
Date: Thu Sep 12 18:30:02 PDT 1991
Subject: Re: bug with select 5.0
 > 
 > There is indeed a known bug in VxWorks 5.0 select, which can be worked
 > around by setting the width argument to select to its maximum value
 > (FD_SETSIZE = 256).
 > The bug causes the read and write fd_sets to be zero'ed incorrectly, so the
 > bits initially set sometimes are incorrectly returned to the user. 
 > Setting width = 256
 > will cause all the bits to be zero'ed correctly.
 > 
 > Bob Cohen
 > Wind River Systems


I just want to add that this bug is now fixed in the
VxWorks 5.0.2 (for gcc) and 5.0b (for native tools)
releases.

 - kent

   Kent Long
   Wind River Systems


From KADIONIK@frcpn11.in2p3.fr  Thu Sep 12 22:31:01 1991
From: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik)
Date: Thu Sep 12 22:31:07 PDT 1991
Subject:      subnet problems

***************************************************
*            Subjet : subnet problems             *
***************************************************


Hi !

I have actually problems with the subnet addressing.


We have an IP class B address for all the CNRS Nuclear Physic labs (134.158.)
and have a subnet mask that permit to distinguish each lab from the other.
It have been attributed to us the submask : 255.255.248.0 (0xfffff800).


I have a VME crate with a MVME 147 card for Ethernet acces and a MVME 165
card for its VSB possibilities (and other VME/VSB cards for data acquisition).


I have declared my two targets in the /etc/hosts and /etc/hosts.equiv .

The host IP address is : 134.158.83.1 (subnet mask :0xfffff800)
The MVME card IP address is : 134.158.84.2 . It is the gateway for access
to the backplane network.
I actually have choosen to attribute to the backplane network the IP address
134.158.144.00 with a subnet mask of 255.255.255.0 .
The MVME 147 card has also the backplane IP address 134.158.144.1 and the
MVME 165 card, the backplane IP address 134.158.144.2 .

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

On the Unix side, I have declared the MVME 147 card as gateway.
( # route add 134.158.144.0 134.158.84.2 1)

For the MVME 147 boot parameters, I have entered :
inet on ethernet  : 134.158.84.2:fffff800
inet on backplane : 134.158.144.1:ffffff00
host inet         : 134.158.83.1


For the MVME 165 boot parameters, I have entered :
inet on backplane : 134.158.144.2:ffffff00
host inet         : 134.158.83.1
gateway           : 134.158.144.1


All the two cards boot properly.
I have after declared a default routing for the MVME 165 :
vw_165-> routeAdd  "0", "134.158.144.1"

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

I can acces to the host (134.158.83.1) and the MVME 147 card (134.158.144.1
and 134.158.84.2) from the MVME 165 card but I can't acces to the other
hosts (for example 134.158.83.2) from the MVME 165 card.
I can from the MVME 147 card.

So, what is the problem ?
Why can I not reach the 134.158.83.2 host from the MVME 165 for example ?


Thank's.


 Patrice.
 kadionik@frcpn11.in2p3.fr



               ------                      ------
              | lys  |                    | rose |
              | SUN  |                    | SUN  |
               ------                      ------
                 ** 134.158.83.1             ** 134.158.83.2
                 **                          **
                 **                          **
        **************************************************
                        ** Ethernet network 134.158.80.0:fffff800
                        **
                        ** 134.158.84.2
                      ------
                     | lily | GATEWAY
                     |VME147|
                      ------
                        ** 134.158.144.1
                        **
                        **  backplane network 134.158.144.0:ffffff00
        **************************************************
                                    **
                                    ** 134.158.144.2
                                  ------
                                 | rosy |
                                 |VME165|
                                  ------


From pat@wrs.com  Fri Sep 13 02:26:58 1991
From: pat@wrs.com (Patrick Boylan)
Date: Fri Sep 13 02:27:08 PDT 1991
Subject: Re: subnet problems
Patrice,

In refernce to your question:

> 
> On the Unix side, I have declared the MVME 147 card as gateway.
> ( # route add 134.158.144.0 134.158.84.2 1)
> 
...
> 
> I can acces to the host (134.158.83.1) and the MVME 147 card (134.158.144.1
> and 134.158.84.2) from the MVME 165 card but I can't acces to the other
> hosts (for example 134.158.83.2) from the MVME 165 card.
> I can from the MVME 147 card.
> 
> So, what is the problem ?
> Why can I not reach the 134.158.83.2 host from the MVME 165 for example ?
> 
> 
> Thank's.
> 
> 
>  Patrice.
>  kadionik@frcpn11.in2p3.fr
> 

Your gateway from the boot host must be working if both targets are
booting correctly.
To access other hosts you may need to add the gateway to the route table of
these hosts also.

Is the gateway registered in the route table on the other host ("rose")?
If not try adding it.

Use:
rose% route add net 134.158.144.0 134.158.84.2 1

Hope that helps.


- Patrick
-- 
 Patrick Boylan
 Wind River Systems
 1010 Atlantic Ave. Alameda, CA 94501
 pat@wrs.com	(415)748-4100


From mea@sparta.com  Fri Sep 13 04:42:19 1991
From: mea@sparta.com (Mike Anderson)
Date: Fri Sep 13 04:42:26 PDT 1991
Subject: Re:  Subnets
Alan,

  Yes, judging from the responses at the East Coast VxWorks Users Group
meeting (thanks to all that attended and especially the folks I was able
to sucker err... convince to speak for us!) there is a considerable interest
in proxy arp as well as other solutions to solve some of the problems
associated with deep network heirarchies.  Having subnets does solve some
of the problems such as the address space issue, but for many of the 
current SBCs that have on 128 Bytes of NV RAM then the new 5.x NV RAM
options (target name, etc.) make the use of subnets untenable 
(e.g., 192.9.200.1:FFFFFFC0 is a lot of bytes).  Clearly, something like
proxy arp would be a viable alternative.  

  I find it interesting that a fair amount of the discussions I've been 
having lately with folks seem to center around the use of VxWorks as a 
general purpose operating system rather than just a real-time environment.
Evidence this discussion.  The true real-time purists believe that
real-time and networks are mutually exclusive terms.  But here we are
talking about a proxy arp daemon for use under VxWorks.  A decidedly
non real-time sort of facility.  In fact, I'm seeing more of a push for things
like MMU support (virtual memory on a real-time system !?!) and other such
elements that would have been unthinkable 1-2 years ago.  Mind you, I don't
think these directions are bad (I was using VxWorks as a general purpose
O/S 4 years ago in Ada as the alpha site for VADSWorks running distributed
simulations) I just find it curious.

  BTW, for those folks out there who where using ProNet-80 boards under
4.0.2 and were disappointed to find that WRS discontinued support under
5.x, I have some good news.  I have just finished re-integrating ProNet
support back into 5.0.1 (including boot ROMs to boot from ProNet) and
would be happy to send the hacked Makefiles and resurrected ProNet
code (there's a lot of non-obvious stuff you have to do to get it to 
work with 5.x) to anyone who's interested.


===============================================================================
    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 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 pessamist
				 fears that this is true."

				    J.B. Cabell

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


**********

This is a user group mailing list for vxWorks related topics

Submit articles to vxwexplo@lbl.gov for 'explosion'

Send subscription requests & comments to vxwexplo-request@lbl.gov



From mea@sparta.com  Fri Sep 13 04:50:28 1991
From: mea@sparta.com (Mike Anderson)
Date: Fri Sep 13 04:50:35 PDT 1991
Subject: Re: Subnets
Greetings,

  One thing that I used at one point in time was class "D" addresses.  The
addresses looked like "224.xxx.xxx.xxx" and seemed to work with VxWorks
and SunOS just fine.  As I understand it, 224 addresses are experimental
ones and are typically used for testing IP Multicast internally on LANs
(i.e., no one on the Internet has a registered class D address).  This
might be O.K. for you to use without worrying about sucking up someone's
mail.  Also, just make sure that your gateway doesn't advertise any routes
to these addresses (i.e., static entries in routing tables rather than using
routed or gated on those machines that will talk to your VxWorks hosts) and
the Internet will be unaware of the existence of your real-time boxes.

Good Luck,


===============================================================================
    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 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 pessamist
				 fears that this is true."

				    J.B. Cabell

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


**********

This is a user group mailing list for vxWorks related topics

Submit articles to vxwexplo@lbl.gov for 'explosion'

Send subscription requests & comments to vxwexplo-request@lbl.gov



From KADIONIK@frcpn11.in2p3.fr  Fri Sep 13 05:06:50 1991
From: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik)
Date: Fri Sep 13 05:06:58 PDT 1991
Subject:      subnet problems, precision
Hi !

I have omitted to say in my request that the host "lys" (134.158.83.1)
uses the NIS for the network administration. So, the host "rose"
(134.158.83.2) should know that "lily" (134.158.84.2) is the gateway
for the backplane network (134.158.144.0)...


From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Fri Sep 13 06:17:20 1991
From: fjr@iss-ipc1.ssd.ray.com
Date: Fri Sep 13 06:17:26 PDT 1991
Subject: Re:  Subnets
Below are two different questions about subnets.
> Am I missing something here?  Netmasks need not align with octet boundaries.
> You could specify your netmask to be 0xfffffffe, which creates a subnet
> containing only 2 hosts.
>   

>Our standard subnetting is 8 bits.  We use an 8-bit subnet for each building,
>and one for the ship (which has other computers connected to Internet).  I'm
>not sure how many subnets I need in the above scenario, but I suspect that it
>will not be possible to assign only a 2-bit subnet mask at the final level,
>and still be able to reach it from the upstream levels.  Can anybody clarify
>for me?  I am interested in proxy arping, aren't I?

As I said in an earlier posting, we could find no published rules on
subneting but after a lot of research, and trying something like the scheme
above to no avail but getting a different subnetting scheme to work,
I think some pertinent rules are:

1) Subnets are meant to break a flat address space into a two level hierarchy
   where there is a single network connecting a bunch of independent networks.
   For example, an ethernet connecting a bunch of crates with backplane
   networks.  There has to be a consistent value for the subnet mask value
   throughout a subnetted network.  You can't keep splitting the address to
   get a tree type interconnection.
2) The main interconnection network is one subnet and each of the independent
   nets is a network.  In the example the ethernet is one subnet and the
   backplanes are each subnets.
3) To the outside world, the whole network looks like it is all part of one
   IP address; the subnets are transparent.  If you have a host (e.g. a SUN)
   bridging between the embedded ethernet and the outside world, then it is
   the only  host that needs to know that the embedded network is subnetted.
4) While subnet masks don't need to be octet aligned, there is some question
   as to whether all network SW will handle unaligned masks.  In particular,
   we have heard that SUNs can't.
5) The "host" part of a subnetted address should not take on the values
   0 or all ones since these are used in various implementations for
   broadcasts.

The main point above is two.  If you have a lot of crates connected by
ethernet, your subnet mask has to allow enough host identifiers to address
all of the ethernet interfaces on all of the crates.  This basically means
that you never could have more subnets than hosts on a given subnet since
you wouldn't be able to satisfy the interconnection rule if you did.  For
all intents and purposes, you will always have as many of more bits in the
host part of the subnet mask than in the subnet part if you want to make
maximum use of subnets.  Hope this helps (I'm assuming its right but like
I said, its hard to get the real facts on this stuff).    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 biocca@bevsun.bev.lbl.gov  Fri Sep 13 08:38:56 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Fri Sep 13 08:39:01 PDT 1991
Subject: Re: Subnets
> Submitted-by: Fred Roeber (fjr@iss-ipc1.ssd.ray.com): (Condensed)
>
> I think some pertinent rules are:
> 
> 1) Subnets are meant to break a flat address space into a two level hierarchy
>    where there is a single network connecting a bunch of independent networks.
>    For example, an ethernet connecting a bunch of crates with backplane
>    networks.  There has to be a consistent value for the subnet mask value
>    throughout a subnetted network.  You can't keep splitting the address to
>    get a tree type interconnection.

Actually, you can.  The depth of the tree is limited, but the model of the
internet is based on these addresses and is certainly not limited to two 
levels.  In fact, if you have 254 subnets in your address you can build any
tree that has that many nodes.  It is not limited to two levels.

Subnetting makes the routing easier -- looking at a few bits tells which
gateway to forward to.

The subnet mask must be consistent on each wire -- not throughout the entire
system.  It is in fact possible to change subnet masks each time you cross
a router.  We ran the BEVALAC on a labwide 6 bit subnet, 10 bit host net and
we made our control wire 10 bit subnet, 6 bit host.  This allowed us to
take each subnet given us by the network folks on the 6/10 net and turn it
into 16 10/6 subnets.  The primary difficulty here is having a router that
can handle differing subnets on different interfaces.  We hacked SunOS 3.5
to handle this correctly.  It may be fixed in later versions, we haven't
done that since we moved to a 8/8 subnets where there was more address
space before upgrading.  Using a commercial router instead of a server
would solve this problem in any case.

> 4) While subnet masks don't need to be octet aligned, there is some question
>    as to whether all network SW will handle unaligned masks.  In particular,
>    we have heard that SUNs can't.

We have significant experience here with Suns, and this is not a problem.
Suns handle unaligned netmasks fine.  The labwide 6/10 network has 700+ hosts
and many of those are Suns.

Alan K Biocca
BEVALAC Controls Group


From biocca@bevsun.bev.lbl.gov  Fri Sep 13 08:46:29 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Fri Sep 13 08:46:37 PDT 1991
Subject: Re: subnet problems, precision
	Submitted-by: KADIONIK@frcpn11.in2p3.fr (Patrice Kadionik)
	
	I have omitted to say in my request that the host "lys" (134.158.83.1)
	uses the NIS for the network administration. So, the host "rose"
	(134.158.83.2) should know that "lily" (134.158.84.2) is the gateway
	for the backplane network (134.158.144.0)...

I don't see how NIS is going to help here.  NIS doesn't install routing
in the kernel.  That must be done with route add commands at boot time
or by root.

The problem is that you have added 'networks' to your environment by
adding secondary processors.  The boot host has a route, but the other
hosts also need one.  The hosts in your net should have a default route
pointing to a router that connects to the next layer up of network.  IF that
router has a route to your backplane network via the gateway then all hosts
everywhere will be able to get to the crate.

In summary, either each host must have a route, or the gateway they point to
must have one.

Alan K Biocca
BEVALAC Controls Group


From lapp@waterloo.hp.com  Fri Sep 13 09:25:44 1991
From: lapp@waterloo.hp.com (Dave Lapp)
Date: Fri Sep 13 09:25:50 PDT 1991
Subject: Re: Subnets
> 
> Submitted-by biocca@bevsun.bev.lbl.gov  Fri Sep 13 08:38:56 1991
> Submitted-by: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
>  
> > Submitted-by: Fred Roeber (fjr@iss-ipc1.ssd.ray.com): (Condensed)
> >
> > I think some pertinent rules are:
> > 
> > 1) Subnets are meant to break a flat address space into a two level hierarchy
> >    where there is a single network connecting a bunch of independent networks.
> >    For example, an ethernet connecting a bunch of crates with backplane
> >    networks.  There has to be a consistent value for the subnet mask value
> >    throughout a subnetted network.  You can't keep splitting the address to
> >    get a tree type interconnection.
> 
> Actually, you can.  The depth of the tree is limited, but the model of the
> internet is based on these addresses and is certainly not limited to two 
> levels.  In fact, if you have 254 subnets in your address you can build any
> tree that has that many nodes.  It is not limited to two levels.
>
Multi level subneting is certainly possible.
 
> 
> The subnet mask must be consistent on each wire -- not throughout the entire
> system.  It is in fact possible to change subnet masks each time you cross
> a router.  We ran the BEVALAC on a labwide 6 bit subnet, 10 bit host net and
> we made our control wire 10 bit subnet, 6 bit host.  This allowed us to
> take each subnet given us by the network folks on the 6/10 net and turn it
> into 16 10/6 subnets.  The primary difficulty here is having a router that
> can handle differing subnets on different interfaces.  We hacked SunOS 3.5
> to handle this correctly.  It may be fixed in later versions, we haven't
> done that since we moved to a 8/8 subnets where there was more address
> space before upgrading.  Using a commercial router instead of a server
> would solve this problem in any case.
> 

And given the BSD based network code in the vxWorks it is best
if the subnet mask is consistent for all interfaces when using a
vxWorks system as a router as well.

Dave Lapp
                        Standard Disclaimer etc...


From wrs!mac_smtp!Leigh_Barker@uunet.uu.net  Fri Sep 13 09:47:59 1991
From: wrs!mac_smtp!Leigh_Barker@uunet.uu.net (Leigh Barker)
Date: Fri Sep 13 09:48:06 PDT 1991
Subject: Christina Goette :Unknown M
GatorMail-Q                   Christina Goette :Unknown M
Received: by mac_smtp.wrs.com; 13 Sep 91 07:09:11
Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86)
	id AA20876; Fri, 13 Sep 91 07:00:48 PDT
Received: from vxw.ee.lbl.gov by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA24346; Fri, 13 Sep 91 05:53:43 -0400
Received: by vxw.ee.lbl.gov (4.1/s2.2)
	id AA12679; Fri, 13 Sep 91 02:27:13 PDT
Date: Fri, 13 Sep 91 02:27:13 PDT
Message-Id: <9109130927.AA12679@vxw.ee.lbl.gov>
Errors-To: uunet!lbl.gov!vxwexplo-errs
To: vxworks_users@vxw.ee.lbl.gov
From: uunet!lbl.gov!vxwexplo (the vxWorks Users Group Exploder)
Subject: Re: subnet problems

Submitted-by pat@wrs.com  Fri Sep 13 02:26:58 1991
Submitted-by: pat@wrs.com (Patrick Boylan)
 
Patrice,

In refernce to your question:

> 
> On the Unix side, I have declared the MVME 147 card as gateway.
> ( # route add 134.158.144.0 134.158.84.2 1)
> 
..
> 
> I can acces to the host (134.158.83.1) and the MVME 147 card (134.158.144.1
> and 134.158.84.2) from the MVME 165 card but I can't acces to the other
> hosts (for example 134.158.83.2) from the MVME 165 card.
> I can from the MVME 147 card.
> 
> So, what is the problem ?
> Why can I not reach the 134.158.83.2 host from the MVME 165 for example ?
> 
> 
> Thank's.
> 
> 
>  Patrice.
>  kadionik@frcpn11.in2p3.fr
> 

Your gateway from the boot host must be working if both targets are
booting correctly.
To access other hosts you may need to add the gateway to the route table of
these hosts also.

Is the gateway registered in the route table on the other host ("rose")?
If not try adding it.

Use:
rose% route add net 134.158.144.0 134.158.84.2 1

Hope that helps.


- Patrick
-- 
 Patrick Boylan
 Wind River Systems
 1010 Atlantic Ave. Alameda, CA 94501
 pat@wrs.com	(415)748-4100

**********

    This is a user group mailing list for vxWorks related topics
    Submit articles to vxwexplo@lbl.gov for 'explosion'
    Send subscription requests & comments to vxwexplo-request@lbl.gov





From wrs!mac_smtp!Leigh_Barker@uunet.uu.net  Fri Sep 13 09:48:07 1991
From: wrs!mac_smtp!Leigh_Barker@uunet.uu.net (Leigh Barker)
Date: Fri Sep 13 09:48:19 PDT 1991
Subject: Christina Goette :Unknown M
GatorMail-Q                   Christina Goette :Unknown M
Received: by mac_smtp.wrs.com; 13 Sep 91 07:11:38
Received: by wrs.wrs.com (5.51/UUCP-Project/05.09.86)
	id AA20911; Fri, 13 Sep 91 07:03:16 PDT
Received: from vxw.ee.lbl.gov by relay1.UU.NET with SMTP 
	(5.61/UUNET-internet-primary) id AA08347; Fri, 13 Sep 91 07:55:23 -0400
Received: by vxw.ee.lbl.gov (4.1/s2.2)
	id AA12862; Fri, 13 Sep 91 04:42:30 PDT
Date: Fri, 13 Sep 91 04:42:30 PDT
Message-Id: <9109131142.AA12862@vxw.ee.lbl.gov>
Errors-To: uunet!lbl.gov!vxwexplo-errs
To: vxworks_users@vxw.ee.lbl.gov
From: uunet!lbl.gov!vxwexplo (the vxWorks Users Group Exploder)
Subject: Re:  Subnets

Submitted-by mea@sparta.com  Fri Sep 13 04:42:19 1991
Submitted-by: mea@sparta.com (Mike Anderson)
 
Alan,

  Yes, judging from the responses at the East Coast VxWorks Users Group
meeting (thanks to all that attended and especially the folks I was able
to sucker err... convince to speak for us!) there is a considerable interest
in proxy arp as well as other solutions to solve some of the problems
associated with deep network heirarchies.  Having subnets does solve some
of the problems such as the address space issue, but for many of the 
current SBCs that have on 128 Bytes of NV RAM then the new 5.x NV RAM
options (target name, etc.) make the use of subnets untenable 
(e.g., 192.9.200.1:FFFFFFC0 is a lot of bytes).  Clearly, something like
proxy arp would be a viable alternative.  

  I find it interesting that a fair amount of the discussions I've been 
having lately with folks seem to center around the use of VxWorks as a 
general purpose operating system rather than just a real-time environment.
Evidence this discussion.  The true real-time purists believe that
real-time and networks are mutually exclusive terms.  But here we are
talking about a proxy arp daemon for use under VxWorks.  A decidedly
non real-time sort of facility.  In fact, I'm seeing more of a push for things
like MMU support (virtual memory on a real-time system !?!) and other such
elements that would have been unthinkable 1-2 years ago.  Mind you, I don't
think these directions are bad (I was using VxWorks as a general purpose
O/S 4 years ago in Ada as the alpha site for VADSWorks running distributed
simulations) I just find it curious.

  BTW, for those folks out there who where using ProNet-80 boards under
4.0.2 and were disappointed to find that WRS discontinued support under
5.x, I have some good news.  I have just finished re-integrating ProNet
support back into 5.0.1 (including boot ROMs to boot from ProNet) and
would be happy to send the hacked Makefiles and resurrected ProNet
code (there's a lot of non-obvious stuff you have to do to get it to 
work with 5.x) to anyone who's interested.


===============================================================================
    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 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 pessamist
				 fears that this is true."

				    J.B. Cabell

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


**********

This is a user group mailing list for vxWorks related topics

Submit articles to vxwexplo@lbl.gov for 'explosion'

Send subscription requests & comments to vxwexplo-request@lbl.gov


**********

    This is a user group mailing list for vxWorks related topics
    Submit articles to vxwexplo@lbl.gov for 'explosion'
    Send subscription requests & comments to vxwexplo-request@lbl.gov





From kevinf@verdix.com  Fri Sep 13 10:15:57 1991
From: kevinf@verdix.com (D. Kevin Faust)
Date: Fri Sep 13 10:16:04 PDT 1991
Subject: VxWorks ethernet drivers

  Does anybody out there have source code, in the public domain, for
  a Motorola 374 ethernet card (MVME374) ?

                                              Kevin Faust

                                              kevinf@verdix.com


From rjn@snowbird.labs.tek.com  Fri Sep 13 10:23:30 1991
From: rjn@snowbird.labs.tek.com (Jim Nusbaum)
Date: Fri Sep 13 10:23:38 PDT 1991
Subject:  Subnets

Mike Anderson wrote:

>  I find it interesting that a fair amount of the discussions I've been 
>having lately with folks seem to center around the use of VxWorks as a 
>general purpose operating system rather than just a real-time environment.
>Evidence this discussion.  The true real-time purists believe that
>real-time and networks are mutually exclusive terms.  But here we are
>talking about a proxy arp daemon for use under VxWorks.  A decidedly
>non real-time sort of facility.  In fact, I'm seeing more of a push for things
>like MMU support (virtual memory on a real-time system !?!) and other such ...
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Actually I doubt MMU support is desired for virtual memory
implementations.  It is desireable for memory protection and
segmentation.  MMU's allow one to set up memory spaces on which the
MMU will enforce access constraints.  This is very desireable for
mission critical systems, systems where more than one 'application'
must run on the same processor and use the same memory and for
situations where user code is going to be downloaded into a system
which is also running an oem application (we don't want the user code
to crash our software, just theirs).  It does however require a
different kernel implementation strategy.  Kernel calls can generally
no longer be just function calls, but must be processor traps that put
the processor into supervisory mode.

Jim Nusbaum, Computer Research Lab, Tektronix, Inc.  
[ucbvax,decvax,allegra,uw-beaver,hplabs]!tektronix!crl!rjn
rjn@crl.labs.tek.com
(503) 627-4612



From bernard@aar.alcatel-alsthom.fr  Fri Sep 13 10:43:28 1991
From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard )
Date: Fri Sep 13 10:43:39 PDT 1991
Subject: C++ on VxWorks

We've been developping a mobile robot research project with C++ for now
two years and are very pleased with this language. 
We are very interested in a C++ class library for VxWorks which
gives access to the system components via class interface (semaphores,
tasks, etc). 

Maybe a difficult point of the language is that the user
may sometimes lose the control of the code produced by the compiler:
a few time ago, we were very surprised because a task was taken 90 %
of the CPU. This was because this task called a method which declares
an array of objects:

In "C"                             In "C++"

struct bar                         class bar
{                                  {
  int x;                            public:
  int y;                              bar () { x = y = 0; }
};
                                    protected:
                                      int x,y;
                                    };

void foo ()                        void foo ()
{                                  {
   bar barTable[10000];               bar barTable[10000];
   ....                               ...
}                                  }

function cost = a few micro-sec    function cost = a few SECONDS !!!
                                   (10000 constructor and destructor call each time)

... of course there is a solution to avoid this .. but it is not always
easy to think of what the compiler is doing. It would be nice to have tools which
give the programmer the complexity of the generated code.

A problem with ATT 2.0 C++

- problems with static data (class members) which are declared as
  common in the a.out file 


 -----------------------------------------------------------
!                                                           !
! Olivier BERNARD                                           !
! Alcatel Alsthom Recherche                                 !
! Route de Nozay                                            !
! 91460 Marcoussis                                          !
! France                                                    !
!                                                           !
! mail: bernard@aar.alcatel-alsthom.fr                      !
!                                                           !
 -----------------------------------------------------------



From rg@msel.unh.edu  Fri Sep 13 10:46:33 1991
From: rg@msel.lbl.gov (Roger Gonzalez)
Date: Fri Sep 13 10:46:45 PDT 1991
Subject: Re: Subnets

I'm getting lost.

All I want is this:

__________________________________________________ campus net - netmask 0xfffffc00
         | le0                     |        |
sparc 132.177.131.33   other workstations for development
         | le1
         |______________________________________________ internal development net
          |                           |
          ======= vme crate           ======= vme crate
          |||||||                     |||||||
        target cpus                 target cpus
      running vxworks             running vxworks


I have no control over the campus net.  I have to request an address whenever
I want to put a new machine up.  The campus Net Dictators have told me that
they don't want to let me have any subnets.

How can I set this up?  All this subnetting talk has made my head swim.
Can I request a range of addresses from the Dictators, and set up routing on a
per-host basis?  Please help me!  (All I have right now is one target CPU -
but I'm trying to plan for the future)

-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
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)



From biocca@bevsun.bev.lbl.gov  Fri Sep 13 14:13:52 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Fri Sep 13 14:13:59 PDT 1991
Subject: Subnet Confusion

From Roger Gonzalez   -  rg@msel.unh.edu:
 
> All I want is this:
> 
> __________________________________________________ campus net - netmask 0xfffffc00
>          | le0                     |        |
> sparc 132.177.131.33   other workstations for development
>          | le1
>          |______________________________________________ internal development net
>           |                           |
>           ======= vme crate           ======= vme crate
>           |||||||                     |||||||
>         target cpus                 target cpus
>       running vxworks             running vxworks
> 
> 
> I have no control over the campus net.  I have to request an address whenever
> I want to put a new machine up.  The campus Net Dictators have told me that
> they don't want to let me have any subnets.
 
Then request addresses for your secondary processors on some subnet.  If they
won't give you the whole subnet you'll just have to work with host routes
and a piece of a subnet.  Each crate's secondaries must be within one
subnet, but the crates don't have to have the same subnets.

It doesn't matter much which subnet.  They must have one subnet for special
purposes like links that is nearly empty.  Perhaps you could convince them
to setup one subnet for all the vxWorks users on the entire campus.  Or for
all the special networks.  Shiva/Fastpath boxes often need subnets, and
they waste most of the addresses.  Use part of one of those that they're
not using.  You need valid onsite unique addresses.

Normally with a subnet in each crate you'd just setup your gateway with a
single net route for each backplane pointed at the vxworks gateway for that
crate.  You will instead have to put a host route in your .33 gateway
for each secondary processor pointing to the crate that cpu is in.

You'll have to put a host route for each of those secondary processors in
every development workstation pointing to your .33 router.

You'll also need default routes in the vx gateways pointing to .33, and
defaults in the secondaries pointing to their gateway.

Just remember that in order for a packet to be delivered each node it passes
through must correctly figure out where to send it next.  One hop at a time.
Either it must match a host route exactly or the netmasks are applied to find
a net route to use.  If nothing matches it forwards to 'default' which is
the route to host 0.0.0.0.  VxWorks doesn't assume a default route so you'll
have to install one where you want it.

Alan K Biocca
BEVALAC Controls Group


From wrs!yuba!ricks@uunet.uu.net  Fri Sep 13 14:25:42 1991
From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek)
Date: Fri Sep 13 14:25:58 PDT 1991
Subject: Re:  Subnets or is it MMU?
Hey you folks have splintered this subnet discussion into an MMU discussion.
Please use an appropriate subject line for those of us without ESP!

Tanks,
Rick



From psm%helios.nosc.mil@nosc.mil  Fri Sep 13 15:43:07 1991
From: psm%helios.nosc.mil@nosc.mil
Date: Fri Sep 13 15:43:14 PDT 1991
Subject: Re: Subnet Confusion
> >From Roger Gonzalez   -  rg@msel.unh.edu:
>  
> > All I want is this:
> > 
> > __________________________________________________ campus net - netmask 0xfffffc00
> >          | le0                     |        |
> > sparc 132.177.131.33   other workstations for development
> >          | le1
> >          |______________________________________________ internal development net
> >           |                           |
> >           ======= vme crate           ======= vme crate
> >           |||||||                     |||||||
> >         target cpus                 target cpus
> >       running vxworks             running vxworks
> > 
> > 
> > I have no control over the campus net.  I have to request an address whenever
> > I want to put a new machine up.  The campus Net Dictators have told me that
> > they don't want to let me have any subnets.

We had much the same situation and solved it by creating a bootleg
net (we made up our own net ID) for our internal development net. The
only machines that knew about it were the gateway sparc and the other
development machines. Assuming that you have system administration
priviledges on your development sparcs, you should be able to do the same.
The gateway was, obviously, the passive variety.






From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Mon Sep 16 05:15:41 1991
From: fjr@iss-ipc1.ssd.ray.com
Date: Mon Sep 16 05:15:49 PDT 1991
Subject: Re:  Subnets
Last week I sent out a post on subnet "rules".  As several people pointed
out you can make the TCP/IP software handle networks that break some of the
rules I had proposed.  I should have mentioned that one of our intents was
to have a network that required minimal additional configuration.  If you
set up your network according to the rules I outlined, you can run the
systems with no additional configuration information beyond what is supplied
on the boot line (i.e. backplane address, ethernet address, gateway address).
I think one of the good things about the network software is that it can
be set up, as people have shown in some of the postings, to do so much more
than originally intended.    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 Christina_Goette@mac_smtp.WRS.COM  Tue Sep 17 11:15:30 1991
From: Christina_Goette@mac_smtp.WRS.COM (Christina Goette)
Date: Tue Sep 17 11:15:45 PDT 1991
Subject: East Coast Users Group Meet
                       Subject:                               Time:11:22 AM
  OFFICE MEMO          East Coast Users Group Meeting         Date:9/17/91
A hearty thanks to Mike Anderson and Sparta for orchestrating and chairing an
interesting Users Group meeting!  Minutes and an attendee list are currently in
progress and will be sent out (over the exploder if the minutes are not too
lengthy) soon.
If you have any questions in the mean time please don't hesitate to contact me
via e-mail at tina@wrs.com or telephone:  800/545-9463.
Christina Goette




From marc@sun-valley.stanford.edu  Tue Sep 17 15:05:11 1991
From: marc@sun-valley.stanford.edu (Marc Ullman)
Date: Tue Sep 17 15:05:22 PDT 1991
Subject: Re: building bootroms for 68k using gcc on SPARC 

>Has anyone made the necessary changes to the vxWorks makefiles to sucessfully
>build bootroms on SPARC stations for 68K targets, using "gcc" configured as a
>cross compiler?

>I've successfully built working kernels, but my bootroms don't work.

I have modified the source code for config/mv133 and config/mv147 so that
I can build boot roms with "gcc -O -Wall".  My 147 roms work.  My 133 ones
don't.  I have not tracked down why.  If any one knows what the problem is
I'd be interested in hearing about it.  Let me know if you are using either of
these two targets.

--Marc Ullman
  Stanford University


From rg@msel.unh.edu  Wed Sep 18 05:27:10 1991
From: rg@msel.lbl.gov (Roger Gonzalez)
Date: Wed Sep 18 05:27:21 PDT 1991
Subject: another bootrom question
I am faced with having to reprogram new boot roms in order to include
the ethernet driver for my hardware.  Unfortunately, my prom burner (a
Bytek S-125) is only a 16 bit machine and can only burn up to two
proms at once.  Has anyone written any code to make hex files suitable
for downloading in two steps to a 16 bit burner?

-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
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)



From hebo@mbari.org  Wed Sep 18 08:40:45 1991
From: hebo@mbari.org (Bob Herlien)
Date: Wed Sep 18 08:40:51 PDT 1991
Subject: Re: another bootrom question

I've written a small program to take an S-record file and split it into
n pieces at every nth byte (for n=2, into even-odd bytes; for n=4, 
low-middle-middle-high bytes, etc).

Unfortunately, I didn't have the S record specification when I wrote it,
so by the time I made it work, it was pretty well hacked.  But you're
welcome to try it.

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From stan@rti.com  Wed Sep 18 11:33:38 1991
From: stan@rti.com (Stan Schneider)
Date: Wed Sep 18 11:33:45 PDT 1991
Subject: Re: another bootrom question

Some time ago, I also wrote an S-record to rom-image program.  You're welcome
to it as well.  It accepts multiple s-record files, and produces rom images of
any size for any width bus.

        -- 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 rg@msel.unh.edu  Wed Sep 18 11:52:42 1991
From: rg@msel.unh.edu (Roger Gonzalez)
Date: Wed Sep 18 11:52:49 PDT 1991
Subject: Re: another bootrom question
Bob-

Sounds good... I'd love to look at it!


-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
UNH Marine Systems Engineering Laboratory, Durham, NH  03824-3525
(603) 862-4600 -4399 (fax)



From marc@aplpy.jhuapl.edu  Thu Sep 19 09:57:15 1991
From: marc@aplpy.jhuapl.edu (Marcus Gates)
Date: Thu Sep 19 09:57:25 PDT 1991
Subject: Please add me to vxWorks mailing list
    We are using vxWorks 5.0.2 with development on sun workstations.


From proton!baumann@ucrmath.ucr.edu  Thu Sep 19 10:20:16 1991
From: proton!baumann@ucrmath.ucr.edu (Michael Baumann)
Date: Thu Sep 19 10:20:26 PDT 1991
Subject: 1553 card/driver
Hello all:
I am searching for one of 2 things:
A driver or pointers to assitance in developing same for a
Radstone PMV 68EE MBI-1  1553 Bus interface.

-or-

I am also willing to accept pointers to other board/driver
pairs (Same functionality)

Adv-Thanks-ance

Michael Baumann
Radiation Research Lab		|Internet: baumann%proton.UUCP@ucrmath.UCR.EDU
Loma Linda Universtiy Medical Center |        UUCP: ...ucrmath!proton!baumann
Loma Linda, California. (714)824-4077|


From biocca@bevsun.bev.lbl.gov  Thu Sep 19 11:02:47 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Thu Sep 19 11:02:54 PDT 1991
Subject: Welcome new users

Last night I put out a notice on comp.realtime advertising our exploder.

This morning I added about twenty new users (and one is a list) to the
list.

Welcome to the new users of the vxWorks exploder.

Alan K Biocca
BEVALAC Controls Group
VxWorks Users Group Exploder Maintainer



From hill@luke.atdiv.lanl.gov  Thu Sep 19 16:52:48 1991
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Thu Sep 19 16:52:58 PDT 1991
Subject: Re:  1553 card/driver
sorry, we dont use 1553 IO here. However I used to do 1553 over GPIB
when I worked for an aircraft manufactuer. Do you use 1553 as a
multidrop IO bus? If so why did you choose 1553 over comercial multidrops
like the one provided by allen bradley?

Jeff


From hebo@mbari.org  Mon Sep 23 11:09:58 1991
From: hebo@mbari.org (Bob Herlien)
Date: Mon Sep 23 11:11:57 PDT 1991
Subject: NTP for VxWorks
I have just uploaded a port of NTP (Network Time Protocol) version 1
to the archives at thor.atd.ucar.edu.  I placed it in file ntp.vx.tar.Z
(a compressed tar file) in directory /pub/incoming.  This is the first
time I've put anything in the archives, so I don't know how it gets
from /pub/incoming to /pub/vx.  If I need to notify the archive administrator,
or I need to send a different type of file (shar?), someone please
let me know.

The ntp.vx.tar.Z file contains two different but related pieces of code.
When you unpack it, you'll find directories ./usrTime and ./ntp.

UsrTime contains a set of Unix-compatible functions to maintain time.
It includes gettimeofday(), settimeofday(), time(), stime(), asctime(),
ctime(), gmtime(), localtime(), and adjtime().  It also contains a couple
of user interface functions (date(), gmtset()) to get/set time from the
user level, as well as drivers for the MK48T02 real-time clock chip as
configured for the SBE VPU-30 (yes, I know that the archives already
had MK48T02 drivers.  I did mine before I saw them).

The ./ntp directory contains, of course NTP.

NTP requires usrTime -- it needs the Unix time functions.  Even if you
don't want the complexity and accuracy of NTP, though, usrTime is quite
useful by itself.  I like having "date" available from the vxWorks shell.

The NTP port probably still has some bugs.  I won't be able to work on it
for at least a month, so I'm uploading it now so that the people who have
been waiting for it can get started; maybe even fix some bugs :-). I've
been able to keep clock sync with my Unix host with sub-millisecond
accuracy, though.

-----------------------------------------------
Bob Herlien
MBARI (Monterey Bay Aquarium Research Institute)
hebo@hp850.mbari.org


From hill@luke.atdiv.lanl.gov  Tue Sep 24 11:12:38 1991
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Tue Sep 24 11:12:48 PDT 1991
Subject: program access to vxWorks system information
We would like to obtain the information printed by memShow() in binary 
form. I dont see any way to get the number of free bytes into my variable
other than reassigning stdout, calling memShow(), and then parsing the
text in the file.

Has anyone solved this problem? Could WRS rearrange the memShow
routine so that it first calls a routine which fetches the info
in binary form and then another which printf's it on std out?

I believe that a similar problem exists with the information
available from spy.

Jeff


From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Tue Sep 24 11:15:38 1991
From: fjr@iss-ipc1.ssd.ray.com
Date: Tue Sep 24 11:15:56 PDT 1991
Subject: LANCE bugs
Greetings,   We have been having sporadic problems with our ethernet
software hanging up.  Others have mentioned this in the past.  In an
effort to find out what the problem was, I posted a question to the
Usenet tcp/ip group.  I received some helpful responses that may be of
information to others in this group.  The bottom line is that if your
ethernet board is not designed just right, the LANCE interface to the
ethernet can freeze and nothing short of a HW reset will fix it.  Thats
the breaks I guess.    Fred

----------

Article: 17449 of comp.protocols.tcp-ip
From: fjr@sgfb.ssd.ray.com (Fred J. Roeber)
Subject: LANCE chip bug
Date: 20 Sep 91 15:48:21 GMT

I am not sure this is the correct news group but figured I would give it
a try.  We are using certain hardware cards for our ethernet network.  These
cards use the AMD LANCE chips for packet generation.  What we are finding
is that periodically the LANCE seems to hang and stops sending and receiving
packets.  In some cases, a software chip reset clears things up but in others
only a HW reset will fix things.  I have heard from others of rumors
of similar problems.  Indeed, I have noticed in the SGI ethernet driver that
they have support for software access to the chip reset line and take a lot
of care to work around "LANCE problems".  What I am wondering is whether
there is some known LANCE bug that causes these problems.  I find it hard
to believe that this would be the case since typical workstations don't
seem to hang for this reason and I can't imagine that all the vendors drivers
have the special error recovery stuff that SGI put in.  Does anybody have
any pointers on this subject.  If people send to me I'll post a summary.
Thanks in advance.   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 ching@brahms.AMD.COM Sat Sep 21 15:24:29 1991
From: ching@brahms.AMD.COM (Mike Ching)
To: fjr@sgfb
Subject: Re: LANCE chip bug
Newsgroups: comp.protocols.tcp-ip
In-Reply-To: <472@sgfb.ssd.ray.com>
Organization: Advanced Micro Devices; Sunnyvale, CA
Cc: 
Status: R


The LANCE requires a system that can guarantee that maximum memory latency
does not exceed 25.6us for a single transaction. The latency requirement
can be as low as 3.7us for worst case conditions, ie., data chaining, large
packet, and polling required. The bug is that the LANCE does not fail
gracefully when denied access to memory and a reset is required to restore
operation.

Mike Ching

From lars@cmc.com Sun Sep 22 02:22:31 1991
59:35 PDT
Date: Sat, 21 Sep 91 22:59:35 PDT
From: lars@cmc.com (Lars Poulsen)
To: fjr@sgfb
Subject: Re: LANCE chip bug
Organization: CMC (a Rockwell Company), Santa Barbara, California, USA
Status: R

(1) Do you ever have memory bus contention ? LANCE does not recover well
    from bus timeouts.
(2) Do you do segmented buffer chaining ?
    Segments under a hundred bytes are prone to hang in hardware race
    conditions.

SGI have my respect - the kluge you describe is justified with LANCE
hardware. But USUALLY a chip reset software sequence will get it
going again. (Our code, too, has many comments referring to "deaf lance
problem".)
-- 
/ Lars Poulsen, SMTS Software Engineer
  CMC Rockwell  lars@CMC.COM


From dennis@westford.ccur.com Mon Sep 23 11:23:32 1991
To: "Fred J. Roeber" <fjr@sgfb>
Subject: Re: LANCE chip bug 
In-Reply-To: Message from fjr@sgfb.ssd.ray.com (Fred J. Roeber) 
	<472@sgfb.ssd.ray.com> .
Date: Mon, 23 Sep 91 11:10:48 EDT
From: dennis@westford.ccur.com
Message-Id:  <9109231110.aa24505@nexus.westford.ccur.com>
Status: R

	From: fjr@sgfb.ssd.ray.com (Fred J. Roeber)
	Date: 20 Sep 91 15:48:21 GMT

	[ ... ]
	is that periodically the LANCE seems to hang and stops sending and receiving
	packets.  In some cases, a software chip reset clears things up but in others
	only a HW reset will fix things.
	[ ... ]

The major problem with the LANCE is that it requires very
short latencies to get to its memory; this is a result of
having a tiny I/O silo.  This is why you get LANCE
implementations with private memory for the chip (SGI,
Concurrent, certainly others).  This causes the chip to just
give up.  In some implementations, the private memory is
used only for the descriptors; access to descriptors is, in
fact, more critical than for data buffers (when chaining,
you must get to the next descriptor and then the data to
find the next byte to send).

You can sense this problem by checking the TXON and RXON
bits in csr 0, and resetting the chip if either are reset.

Dennis Rockwell
Concurrent Computer
Westford MA



From bdoerr@aplpy.jhuapl.edu  Tue Sep 24 12:59:03 1991
From: bdoerr@aplpy.jhuapl.edu (Bryan S. Doerr)
Date: Tue Sep 24 12:59:12 PDT 1991
Subject: Serial Driver for Z8530


	Hi:

	We're using VxWorks 5.0.1 on a MVME-147S board and have a question
about interfacing to serial I/O devices (asynchronous). It uses the Z8530
chip for serial I/O.

	It appears that that VxWorks serial driver (tyCoDrv & tyLib) returns
through the kernel after every interrupt. This causes excessive time to be
spent in the kernel and results in poor performance overall for the board.

	My question is this. Has anybody written a serial driver that
doesn't return through the kernel. It doesn't have to be written to supply
a stdio interface - it just has to be efficient. 

        Bryan S. Doerr
	JHU/APL   bdoerr@aplpy.jhuapl.edu
        301-953-5000 x8920



From hmp@frc2.frc.ri.cmu.edu  Tue Sep 24 14:57:52 1991
From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
Date: Tue Sep 24 14:58:07 PDT 1991
Subject: Unreliable sigRaise() 'code' parameter delivery

I'm using sigRaise() calls to signal a type of event, identifying the
particular instance by supplying different values for the 'code' parameter.
The trouble is, the signal handler does not always receive this code
correctly; sometimes it appears as 0. In the sigRaise call, the
'code' parameter is hardwired, and in the signal handler, I have put a logMsg
right at the beginning to print out the value, so I don't think there's a way
my code could be corrupting it.

Has anyone else run into this? How about advice on debugging it?

Thanks,

-Henning


From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net  Wed Sep 25 06:19:52 1991
From: fjr@iss-ipc1.ssd.ray.com
Date: Wed Sep 25 06:20:06 PDT 1991
Subject: Re:  Serial Driver for Z8530

----- Begin Included Message -----

 Bryan S. Doerr writes
	It appears that that VxWorks serial driver (tyCoDrv & tyLib) returns
through the kernel after every interrupt. This causes excessive time to be
spent in the kernel and results in poor performance overall for the board.

	My question is this. Has anybody written a serial driver that
doesn't return through the kernel. It doesn't have to be written to supply
a stdio interface - it just has to be efficient. 

----- End Included Message -----

I think that the issue is simply that if you use the VxWorks driver to do
raw terminal IO, the driver will return to the task with an outstanding
read request after every character is input; indeed this is not fast.  The
solution is to modify the user task to do a block read periodically.  In
this case, the driver will return any data that it has buffered in its
internal buffers all at once.  This greatly reduces the scheduling overhead
and seems to be almost as efficient as possible (note, terminal should be
set to raw mode).  The trick is figuring out how often to read the data.
Read it too fast and you introduce more scheduling overhead, too slow and the
internal buffers can overflow.  If you know the IO rate on the channel you
should be able to figure out how long it would take to overflow the terminal
buffers.  The buffer size is also configurable so you could use bigger
buffers if you want.  Hope this helps.    Fred



From gordon@tpocc.gsfc.nasa.gov  Wed Sep 25 06:34:41 1991
From: gordon@tpocc.gsfc.nasa.gov (Gordon Miller)
Date: Wed Sep 25 06:34:52 PDT 1991
Subject: Re: Unreliable sigRaise() 'code' parameter delivery
I too have experienced this problem with sigRaise.  In my tests, the 
parameter passed is only zeroed out if the signal is blocked when 
sigRaise is called.  I have a open call to WRS about this.  I will post
more information/work around (I hope) when I get it.  I worked around
the problem, by not calling sigBlock.  Not a good fix, but I was able to
move some things around to get it to work for now.

If you want to talk about it more, drop me a line.

Gordon Miller			gordon@tpocc.gsfc.nasa.gov
				Integral Systems, Inc.
				1100 West Stree
				Laurel, MD 20707
				(301) 497-2416
				fax:  (301) 498-8260


From jjohnson@hns.com  Wed Sep 25 07:02:32 1991
From: jjohnson@hns.com (Jayne Johnson)
Date: Wed Sep 25 07:02:49 PDT 1991
Subject: Connection failure detection with Berkeley sockets
I have noticed strange behaviour from the socket api and was wondering
if anyone in the Users group has seen this already.

Given the following scenario:
     1. card A creates a non-blocking socket for listening
     2. card B creates a non-blocking socket and initiates a connection 
        request to card A.
     3. card A receives a connection indication from the select() from card B
     4. card A accepts the connection request from card B.
     5. card B receives a connection confirmation from the select() from 
        card A.
     6. card A and card B exchange messsages 
     7. an operator resets card A ( on purpose , to simulate card failures )
     8. card B gets an indication from the select() 

My question is as follows , how can an application determine when a connection
has been broken ? Should select() get an indication? Should I set a socket 
option (like out-of-band data ? ). Should I read the socket control block 
structure state field? Is there a message passed between the TCP and socket api
which can be forwarded up to the application interface when connections are
closing?
I need to find out when a connection has failed as soon as possible since my
system has redundant cards ( which already have connections established ) and I
can easily switch over to the redundant card when a connection indication
is received. I prefer to treat the socket api like a black box and not read
the socket control block structure.

I have been reading the RFCs , Steven's book on UNIX network
programming, Lefler's book on BSD , Comer's book on TCP/IP and there
doesn't seem to have any literature on this subject. 

I also have instituted a failure management scheme which uses 'ping'
and periodic echo messages to determine who is alive and well in the
network. However the failure management system is much slower than
connection indications. Any thoughts? Any literature?
 
Thanks in advance for your help and insight. 

Jayne F. Johnson
Hughes Network Systems
11717 Exploration Lane
Germantown, Md 20874

email : jjohnson@hns.com
phone : 301/428-2714


From biocca@bevsun.bev.lbl.gov  Wed Sep 25 08:00:38 1991
From: biocca@bevsun.bev.lbl.gov (Alan K Biocca)
Date: Wed Sep 25 08:00:44 PDT 1991
Subject: VxExploder Article Rejection

Incoming articles that contain the exploder trailer are rejected.  This
helps prevent errant bounces from being re-exploded.  

This also means that when editing articles for resubmission make sure to
remove the trailers -- ...


Thanks,

Alan K Biocca

PS: Mike Anderson -- please edit and resubmit your article.


From OWENS@lodtm.llnl.gov  Wed Sep 25 08:58:00 1991
From: OWENS@lodtm.llnl.gov
Date: Wed Sep 25 08:58:09 PDT 1991
Subject: Printing From vxWorks targets
  Being somewhat new to Unix, I am not sure of the best method
to access the printer connected to my host Sun workstation from
a target system.  I know that there are ways such as rcmd() or
rlogin(); the documentation on rcmd is sketchy (an example would
be nice).  It seems likely that someone else has already found
the best approach or maybe already implemented a vxWorks 'lpr'
command.  If so I would appreciate hearing about how it was done.

  Thanks,
  Doug Owens  , Lawrence Livermore National Labs 415 422-7616


From hill@luke.atdiv.lanl.gov  Wed Sep 25 09:41:54 1991
From: hill@luke.atdiv.lanl.gov (Jeff Hill)
Date: Wed Sep 25 09:42:06 PDT 1991
Subject: Re:  Connection failure detection with Berkeley sockets
> how can an application determine when a connection has been broken?

I assume we are talking about TCP here. If so, 
the only way I have been able to determine if a TCP/IP connection 
has been lost is to periodically send a NOOP message over the connection.
TCP/IP seems to give timely notification of disconnect only if it
has a message to deliver. You can also try the socket option `KEEPALIVE'.
However the internal delay associated with it seems to be very long 
(hours or even days).


Jeff


From hmp@frc2.frc.ri.cmu.edu  Wed Sep 25 10:53:58 1991
From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
Date: Wed Sep 25 10:54:08 PDT 1991
Subject: i960 boards?

Hello all,

I was recently asked about VxWorks support of i960-based boards, and had only
a vague answer to offer - I am aware of a Heurikon VME board that fits the
bill, but that's it. Specific questions:
a) Are there any other vendors who make i960-based boards that are supported
   by VxWorks?

b) Could active users of the Heurikon (or other) board share their experience?
   What's the development environment? Is there a cross compiler (gcc),
   debugger etc?


Thanks,

-Henning


From omni!hwajin@apple.com  Wed Sep 25 11:08:46 1991
From: hwajin@omni.com (Hwa-Jin Bae)
Date: Wed Sep 25 11:09:00 PDT 1991
Subject: Re: Serial Driver for Z8530 
Your message dated: Wed, 25 Sep 91 06:20:11 PDT

>I think that the issue is simply that if you use the VxWorks driver to do
>raw terminal IO, the driver will return to the task with an outstanding
>read request after every character is input; indeed this is not fast.  The
>solution is to modify the user task to do a block read periodically.  In
>this case, the driver will return any data that it has buffered in its
>internal buffers all at once.>  This greatly reduces the scheduling overhead
>and seems to be almost as efficient as possible (note, terminal should be
>set to raw mode).  The trick is figuring out how often to read the data.
>Read it too fast and you introduce more scheduling overhead, too slow and the
>internal buffers can overflow.  If you know the IO rate on the channel you
>should be able to figure out how long it would take to overflow the terminal
>buffers.  The buffer size is also configurable so you could use bigger
>buffers if you want.  Hope this helps.    Fred

In VxWorks 5.0 or later there is a hook routine that lets you specify
a flag character to look for before returning ty input to the task.
All input is buffered until this flag character is encountered,
at which point the buffer data is passed onto the task.  This is 
handy for implementing a protocol like SLIP but can also be used
to implement a line-mode ty discipline for the shell (by telling
the ty driver to buffer input until a newline character is read).
If your application can use this facility it will greatly reduce
CPU overhead.

--
Hwa-Jin Bae		Interphase West
hwajin@omni.com		Santa Clara, California


From lapp@waterloo.hp.com  Wed Sep 25 11:33:27 1991
From: lapp@waterloo.hp.com (Dave Lapp)
Date: Wed Sep 25 11:33:38 PDT 1991
Subject: Re: i960 boards?
> 
> Submitted-by hmp@frc2.frc.ri.cmu.edu  Wed Sep 25 10:53:58 1991
> Submitted-by: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
>  
> 
> Hello all,
> 
> I was recently asked about VxWorks support of i960-based boards, and had only
> a vague answer to offer - I am aware of a Heurikon VME board that fits the
> bill, but that's it. Specific questions:
> a) Are there any other vendors who make i960-based boards that are supported
>    by VxWorks?
>
Yes I believe Tadpole makes a 960 based board. They have ported vxWorks 
to it. We had one to look at but I didn't us it so I can't comment
on it. I don't have their address but they advertise in various trade
rags (they're in England but have an office in the states)

> b) Could active users of the Heurikon (or other) board share their experience?
>    What's the development environment? Is there a cross compiler (gcc),
>    debugger etc?
> 

We use HP9000's (surprise, surprise) but the tools seem to be available
on a lot of other machines including DEC, Sun, IBM, and PC's running
Interactive Unix. This I'm concluding from the directories on the 
distrib. tapes we get with the tools.

The tools are gnu. You get a pretty complete set of tools and some
people prefer the gnu stuff. The tools do seem to work very well.
There is a (beta) version of vxgdb for the 960 and it works OK as well.

I've never used vxWorks on a 68K but I gather that the functionality
is quite similar on a '960 although new stuff is available for 68K a bit 
before the '960.

We used Heurikon boards as development targets for a while 'til
we got our own hardware. They worked quite well. We did have
a problem with Heurikon's interpretation of little-endian and 
big-endian - they were swapping 16 bit words but not bytes 
when going across the buss or something but that was to be fixed
in (at the time) future revs.

> 
> Thanks,
> 
> -Henning
> 

Your welcome.

Dave Lapp
                        Standard Disclaimer etc.
                        The above are my opinions - not
                        Hewlett's or Packard's or necessarily
                        anybody else who works for HP.


From omni!hwajin@apple.com  Wed Sep 25 11:34:23 1991
From: hwajin@omni.com (Hwa-Jin Bae)
Date: Wed Sep 25 11:34:47 PDT 1991
Subject: Re: Connection failure detection
Your message dated: Wed, 25 Sep 91 07:02:53 PDT

>My question is as follows , how can an application determine when a connection
>has been broken ? 

In TCP based applications there is really no quick way to discover
"when a connection has been broken".  The reason is that you really
don't know that the connection is broken.  Berkeley based TCP's
have a timeout (I forget the exact value but several minutes)
routine that eventually detects that absence of traffic on
a given connection and closes the connection.  A commonly praticed
kludge for better dectection of this situation is to use socket
option SO_KEEPALIVE, which causes TCP code to send out a TCP
segment which contains a lie (receive_next field is less than
what's actually received -- N.B. 4.2 and 4.3 have different
definitions of this message).  The other side should respond
to this message if it's alive.  After several trials of sending
KEEPALIVE TCP will abort the connection if nothing is received.
This is really a necessary hack in TCP because people who designed
the protocol seems to think that you're never supposed to assume
that the other side is dead without conclusive evidence (i.e.
using simple timeout routine is not sufficient), which is 
very important in fact if you're on Internet (or worse milnet)
and try to telnet to a host in Spain.  A slow ACK or lack of
data transfer over a telnet connection doesn't mean that the
other side is gone.

Given the realtime constraint of the application, an acceptable
kludge would be:

1. measure the worst case transmit time of a minimal TCP segment
   in your environment (e.g. ethernet)

2. decide how much delay you can tolerate in your application before
   finding out if the remote peer is gone.

3. code your application to send an application level I'm-Alive message
   to the other side as often as the delay you can derive from #1 and #2.

4. if you don't get I'm-Alive message, you can assume that the
   other guy is gone.  (with certain amount of risk)

--
Hwa-Jin Bae		Interphase West
hwajin@omni.com		Santa Clara, California


From jjohnson@hns.com  Wed Sep 25 11:37:07 1991
From: jjohnson@hns.com (Jayne Johnson)
Date: Wed Sep 25 11:37:22 PDT 1991
Subject: Re: i960 boards? 
Greetings,
I have been working in the i960 environment for about 1 year. So far
the only vendors of Vxworks BSP seem to be Heurikon and Cyclone. Both
manufacturers supply various single board computer cards and VME based
I/O cards .

As far as the development environment tools: Intel supplies a GNU compiler
with the VxWorks development license. So far the biggest complaint I have
is the gdb tools aren't stable, but this isn't Intel's fault. GNU tools
aren't mature to date.

The development environment we have here at Hughes is Apollo workstations
supporting BSD 4.3 and merging towards OSF tools. We already use Motif
and have ported GNU onto the apollo. 

There are other compilers which support the i960 family (KA, KB, CA, SA )
one that really looks good is of course the Microtek C compiler which supports
ANSI and it's debugger, but it sure is expensive. All in all the GNU tools
are good and Intel has a special staff in Oregon optimizing the compiler for
the RISC architecture. 

As far as emulators , so far we are using the STEP,Inc ICE. It's a pretty 
basic emulator nothing to write home about. I would suggest Applied
Microsystems Emulator it sure looks and feels good. It's got alot more 
analysis tools. You should call them up for a demo. 

Let me know how it goes, I feel so all alone . VxWorks is starting to migrate
to RISC so I'm sure the kinds of experiences we are having are going to be
shared by the SPARC and MIPS users. 


From omni!hwajin@apple.com  Wed Sep 25 12:10:24 1991
From: hwajin@omni.com (Hwa-Jin Bae)
Date: Wed Sep 25 12:10:38 PDT 1991
Subject: Re: Printing From vxWorks targets 
Your message dated: Wed, 25 Sep 91 08:58:13 PDT

>  Being somewhat new to Unix, I am not sure of the best method
>to access the printer connected to my host Sun workstation from
>a target system.  I know that there are ways such as rcmd() or
>rlogin(); the documentation on rcmd is sketchy (an example would
>be nice).  It seems likely that someone else has already found
>the best approach or maybe already implemented a vxWorks 'lpr'
>command.  If so I would appreciate hearing about how it was done.

SunOS man page (man 3 rcmd) gives:

	int rcmd(ahost, inport, locuser, remuser, cmd, fd2p)
	char **ahost;
	int inport;
	char *locuser, *remuser, *cmd;
	int *fd2p
			  
The only difference in VxWorks version seems to be the first arg, which is
a "char *" rather than "char **".

So to use "lpr" to print "file" which is on a UNIX machine,

	rcmd("machinename", 514, "username", "username", 
		"/usr/ucb/lpr < file", &error_fd);

514 is the remote shell daemon's port number (as in /etc/services for
the "shell" entry).  The usual permission authentication using /etc/hosts.equiv
and ~/.rhosts are done by the rcmd() and rshd so be sure to have
proper permission stuff in those files.

If you want to write a command that passes stdin input to the remote
command you'll need to save the socket returned by rcmd() and pass
the data read from stdin to that socket.  Result of the command can
be read from this socket (stdin) and error_fd (stderr).

--
Hwa-Jin Bae		Interphase West
hwajin@omni.com		Santa Clara, California


From ast0!monolith!mak@ub.com  Wed Sep 25 12:12:48 1991
From: ast0!monolith!mak@ub.com (Mark Kroft)
Date: Wed Sep 25 12:13:01 PDT 1991
   I recently started using the FP co-processor, and have another 
problem with it.  None of the standard FPCP vectors are initialized
with VxWorks, so when I get a FPCP inexact result, I get a 
'Trap to uninitialized vector number 49'
error.  Is there something I am not doing to that should initialize
these vectors?  What is supposed to be done in this case
Mark Kroft
Applied Signal Technology



From wrs!yuba!ricks@uunet.uu.net  Wed Sep 25 12:42:04 1991
From: wrs!yuba!ricks@uunet.uu.net (Rick Sustek)
Date: Wed Sep 25 12:42:14 PDT 1991
Subject: Re:  i960 boards?

We at WRS have been working with the Heurikon, Tadpole, and Cyclone VME boards,
which are all based on the i960ca.
Our product support for the i960 is based on the GNU C compiler as delivered
from Intel.
The boards and tools all seem to be working fine and exhibit very good
performance.

Rick


From wrs!schuylkill!bob@uunet.uu.net  Wed Sep 25 15:45:41 1991
From: wrs!schuylkill!bob@uunet.uu.net
Date: Wed Sep 25 15:45:53 PDT 1991
Subject: Re: Unreliable sigRaise() 'code' parameter delivery 



>      
>     I too have experienced this problem with sigRaise.  In my tests, the 
>     parameter passed is only zeroed out if the signal is blocked when 
>     sigRaise is called.  I have a open call to WRS about this.  I will post
>     more information/work around (I hope) when I get it.  I worked around
>     the problem, by not calling sigBlock.  Not a good fix, but I was able to
>     move some things around to get it to work for now.
>     
>     If you want to talk about it more, drop me a line.
>     
>     Gordon Miller			gordon@tpocc.gsfc.nasa.gov
>     				Integral Systems, Inc.
>     				1100 West Stree
>     				Laurel, MD 20707
>     				(301) 497-2416

Gordon is right - this is a known bug in our signal implementation.  We have a
mechanism that keeps track of "pending" signals - ie if a signal is raised while
the signal is blocked (for example, if the handler for that signal is currently
running), the signal is marked as pending, and the handler will be called when
the signal becomes unblocked (when the current signal handler completes). 
Unfortunately, the implementation doesn't keep track of the code that's passed in 
to sigRaise when the signal is blocked, and a default code of NULL is passed to
the signal handler when the signal becomes unblocked.  This is internal spr #723.
Sorry for all the confusion.

Bob Cohen
Wind River Systems, Inc.
bob@wrs.com



From leonid@amil.co.il  Thu Sep 26 00:37:18 1991
From: leonid@amil.co.il (Leonid Rosenboim)
Date: Thu Sep 26 00:37:30 PDT 1991
Subject: Re:  Printing From vxWorks targets

I have written a simple function that reads the SUN's YP hosts table
into VxWorks using rcmd. Should be fairly simple to convert it to lpr
or whatever else you might wish for.

------------
#include <vxWorks.h>
#include <stdioLib.h>
#include <strLib.h>
#include <remLib.h>
#include <sysLib.h>

hostRead()
{
    char server[16], user[16] ;
    char line[80] ;
    char addr[20], name[4][16] ;
    char cmd[] = "ypcat hosts" ;
    char *p ;
    FILE *f ;
    register int fd, i ;

    strcpy(server, sysBootHost) ;
    remCurIdGet( user, NULL ) ;

    printf("Host: %s, User: %s\n", server, user) ;

    fd = rcmd (server,
	/*remotePort*/ 514,
	/*localUser*/ user,
	/*remoteUser*/ user,
	cmd,
	/*fd2p*/ NULL ) ;

    if( fd < 0 ) {
	perror("rcmd") ;
	return(fd);
    }

    f = fdopen(fd, "r") ;

    while( fgets(line, 79, f) == line ) {
	/* puts(line) ; */

	p = index(line, '#') ;
	if( p != NULL ) *p = '\0' ;

	fd = sscanf(line, "%s %s %s %s %s", addr, name[0], name[1], name[2],
	    name[3] ) ;

	for( i=0, fd--; fd>0; fd--) {
	    (void) hostAdd(name[i++], addr) ;
	} /*for*/

    } /* while */


    return(fclose(f));
}
--------


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


From hmp@frc2.frc.ri.cmu.edu  Thu Sep 26 05:01:43 1991
From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
Date: Thu Sep 26 05:01:54 PDT 1991
Subject: Re: Unreliable sigRaise() 'code' parameter delivery 

>Gordon is right - this is a known bug in our signal implementation.  We have a
>mechanism that keeps track of "pending" signals - ie if a signal is raised while
>the signal is blocked (for example, if the handler for that signal is currently
>running), the signal is marked as pending, and the handler will be called when
>the signal becomes unblocked (when the current signal handler completes). 
>Unfortunately, the implementation doesn't keep track of the code that's passed in 
>to sigRaise when the signal is blocked, and a default code of NULL is passed to
>the signal handler when the signal becomes unblocked.  This is internal spr #723.
>Sorry for all the confusion.

Thanks for the official word on that, Bob. Now, I'm curious: Could I have
found this out via some other way (read: documentation) before actually
running into the problem? The 5.0 release notes don't seem to mention it,
neither do the man page or technotes 1-23. I'm wondering what other kind of
known bugs are out there waiting for me; I'd love to just browse a list of
them so I don't waste my time trying to track them down myself.
This forum sort of serves in that capacity, but in the end it's WRS who know
these things much better than any of us users.

-Henning


From tadusa!tadtec!ma@uunet.uu.net  Thu Sep 26 05:16:06 1991
From: tadusa!tadtec!ma@uunet.uu.net
Date: Thu Sep 26 05:16:15 PDT 1991
Subject: Re: i960 boards?
Hi,

>a) Are there any other vendors who make i960-based boards that are supported
>   by VxWorks?

Yes, Tadpole Technology sells the TP960V, an i960CA VME board with SCSI +
Ethernet, and a variety of SRAM, DRAM, EPROM & Flash EEPROM configurations.
 For more info, either email me or contact our Austin,TX office on
512-338-4221, or our San Jose office on 408-441-7920. (Sorry for the Ad.)



Mark Armitage                email:	ma@tadtec.uucp
Technical Projects Manager   phone: +44 223 423030
Tadpole Technology plc       fax:   +44 223 420772



From srm%matrx@mcnc.org  Thu Sep 26 07:48:27 1991
From: srm@matrx.matrix.com (Steve Morris)
Date: Thu Sep 26 07:48:36 PDT 1991


>Gordon is right - this is a known bug in our signal implementation.  We have a
>
> [description deleted]
>
>the signal handler when the signal becomes unblocked.  This is internal spr #723.
>Sorry for all the confusion.

>Bob Cohen
>Wind River Systems, Inc.
>bob@wrs.com

This brings up something I've been wanting for a long time...
A *buglist* would save everyone hours/days/nights/weekends of
grief.  As it is now, we all are rediscovering bugs that are
probably known bugs.

Steve Morris
Matrix Corp.
srm@matrix.com


From thor@surt.atd.ucar.edu  Thu Sep 26 08:16:24 1991
From: thor@surt.atd.ucar.edu (Richard Neitzel)
Date: Thu Sep 26 08:16:37 PDT 1991
Subject: Ntp


Thanks to Bob Herlien of the Monterey Bay Aquarium Research Institute, 
ntp has been ported to VxWorks. Currently the ONLY way you can get it
from the archive is via ftp. The file is /pub/vx/ntp.vx.tar.Z. I will
try and get a version that can be emailed ready by week's end.

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 ast0!monolith!mak@ub.com  Thu Sep 26 09:36:18 1991
From: ast0!monolith!mak@ub.com (Mark Kroft)
Date: Thu Sep 26 09:36:29 PDT 1991
Subject: FPCP trap to uninit vector

>   I recently started using the FP co-processor, and have another 
>problem with it.  None of the standard FPCP vectors are initialized
>with VxWorks, so when I get a FPCP inexact result, I get a 
>'Trap to uninitialized vector number 49'
>error.  Is there something I am not doing to that should initialize
>these vectors?  What is supposed to be done in this case
>Mark Kroft
>Applied Signal Technology

   In response to my own article, I found out what the problem is.
In the function irint, there is a bug that sets the floating point
Exception enable byte register to random values.  Here is the
disasembled code:
				
                        _irint:
00e034  4e56 0000                LINK  .W    A6,#0
00e038  f227 6b80                FMOVE .X    F7,-(A7)
00e03c  f22e 5780 0008           FMOVE .D    ($8,A6),F7
00e042  f22e 6380 0008           FMOVE .L    F7,($8,A6)
00e048  202e 0008                MOVE  .L    ($8,A6),D0

00e04c  f201 9000                FMOVE .L    D1,#<FPCR>

00e050  504f                     ADDQ  .W    #8,A7
00e052  4e5e                     UNLK        A6
00e054  4e75                     RTS         

   Line 0e04c is the line that sets the FPCR to some random value,
as D1 is unknown going into the function.  I rewrote the routine,
without line 0e4c, and everything works fine.
   If anyone out there knows why this line was put in, I would
appreciate knowing.  Hope this may keep someone else from spending
a couple of days tracking down this problem.

Mark Kroft
Applied Signal Technology
mak!ast0@ub.com


From Glen_Nakamoto.G034@qmgate.mitre.org  Thu Sep 26 13:43:59 1991
From: Glen_Nakamoto.G034@qmgate.mitre.org (Glen Nakamoto)
Date: Thu Sep 26 13:44:20 PDT 1991
Subject: Vxworks System Memory
                       Subject:                               Time:4:35 PM
  OFFICE MEMO          Vxworks System Memory                  Date:9/26/91
Does anyone know how to shift system memory around under VxWorks?  I am using a
Radstone 68-33 CPU (68030) with two memory banks.  The system memory (PLB)
starts at 0x0 and goes up to 0x0FFFFF (1 Mbyte).  I also have a second memory
bank (ILB) that starts at 0x100000 and goes up to 0x4FFFFF (4 Mbytes).  I want
the system memory to start at 0x100000 and extend upwards 4 Mbytes.  I'm
willing to have the PLB RAM available for partitioning (via memPartCreate)
later if needed.  According to Radstone and WRS, all I need to do is to change
the following macros in /config/RS33target/config.h (and make corresponding
changes in Makefile):

                                                   From              To

LOCAL_MEM_LOCAL_ADRS           0x0             0x100000
LOCAL_MEM_SIZE                        0x10000     0x400000
RAM_TEXT_LOW_ADRS                0x001000   0x101000
RAM_TEXT_HIGH_ADRS               0x090000   0x190000

When I make these changes, I cannot boot the system.  Is there other parameters
that need to be tweeked before this works or is it just not possible?

In case you want to know, the PLB RAM is not visible from the VMEbus but the
ILB is.  VxWorks creates some buffers (mbufs) in system memory and passes these
addresses to my FDDI controller for DMA purposes.  Because the memory is not
visible, the controller (in master mode across the VMEbus) does not
successfully transfer/read the data.  If I can move system memory to the ILB
RAM section, I should be able to eliminate this problem.

Thanks for any assist.

Glen Nakamoto
MITRE Corporation
Bedford, MA
(617) 271-3032
(617) 271-2721 (fax)






From muts@fysap.fys.ruu.nl  Fri Sep 27 06:01:25 1991
From: muts@fysap.fys.ruu.nl (Peter Mutsaers)
Date: Fri Sep 27 06:03:36 PDT 1991
Subject: Switched from version 4.x to 5.0: ls and ll problem
We just switched from 4.x to 5.0; cd and pwd work fine, and when I am
in the right directory I can load an object, so cd really functions.
However, ls and ll give an error and tell they cannot find ".".

Is this a (known) bug, or have I forgotten something?
_________________________________________________________________________
Peter Mutsaers.    RUU physics dept. Heidelberglaan 5, Utrecht, Nederland
muts@fysap.fys.ruu.nl   |================================================
tel: (+31)-(0)30-533880 |    " Trust me; I know what I'm doing. "


From georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov  Fri Sep 27 08:20:26 1991
From: georg%sgl.ists.ca%ists.ists.ca@Csa2.LBL.Gov (Georg Feil)
Date: Fri Sep 27 08:22:38 PDT 1991
Subject: Re: Vxworks System Memory
> When I make these changes, I cannot boot the system. Is there other parameters
> that need to be tweeked before this works or is it just not possible?

Sounds like you need to rebuild your boot PROMS, since they'll still
try to use the old memory.

Georg.


From heyes@dadev.cebaf.gov  Fri Sep 27 09:06:48 1991
From: heyes@dadev.cebaf.gov
Date: Fri Sep 27 09:07:06 PDT 1991
Subject: Re: Switched from version 4.x to 5.0: ls and ll problem 
Hi,
   it is a known bug I think. Try lsOld...


From matthieu@vega.laas.fr  Fri Sep 27 09:24:51 1991
From: matthieu@vega.laas.fr (Matthieu Herrb)
Date: Fri Sep 27 09:25:09 PDT 1991
Subject: Re: Switched from version 4.x to 5.0: ls and ll problem

We had the same problem with an NFS server that was a gould (encore)
PN 6040 under UTX 2.1 and not a sun. And never found a workaround
other than not using it with wxworks.

It must be some incompatiblity in the NFS client code that is not
fully conformant to sun's definition. 

					Matthieu


From litwin@robotics.jpl.nasa.gov  Fri Sep 27 09:37:35 1991
From: litwin@robotics.jpl.nasa.gov (Todd Litwin)
Date: Fri Sep 27 09:37:45 PDT 1991
Subject: Re:  Switched from version 4.x to 5.0: ls and ll problem
I don't know about ll, but the problem with ls has something to do with
VxWorks supporting a local file system -- maybe compatible with MSDOS?
At any rate, WRS tells me that the command "lsOld" should be used by
us for now. I don't know what their future plans are concerning this.

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


From muts@fysap.fys.ruu.nl  Fri Sep 27 09:58:50 1991
From: muts@fysap.fys.ruu.nl (Peter Mutsaers)
Date: Fri Sep 27 09:59:09 PDT 1991
Subject: Switched from version 4.x to 5.0: ls and ll problem 
>>Op Fri, 27 Sep 91 09:07:10 PDT schreef u:

  >    it is a known bug I think. Try lsOld...

Indeed, lsOld works. ls and ll work after I added 'nfsMount' too. I
was looking in the old manpages accidently. Thanks,

_________________________________________________________________________
Peter Mutsaers.    RUU physics dept. Heidelberglaan 5, Utrecht, Nederland
muts@fysap.fys.ruu.nl   |================================================
tel: (+31)-(0)30-533880 |    " Trust me; I know what I'm doing. "


From muts@fysap.fys.ruu.nl  Fri Sep 27 10:31:17 1991
From: muts@fysap.fys.ruu.nl (Peter Mutsaers)
Date: Fri Sep 27 10:31:28 PDT 1991
Subject: Thanks for replies concerning ls and ll
I got already several replies concering ls not working on 5.0. Thanks
for that.
However, a cause was that I still was looking in the 4.x man pages. In
the new man-pages I found lsOld, which worked, and found out that for
ls and ll to work I must have an nfs mounted filesystem.
After I mounted the filesystems with nfs, everything was fine.

_________________________________________________________________________
Peter Mutsaers.    RUU physics dept. Heidelberglaan 5, Utrecht, Nederland
muts@fysap.fys.ruu.nl   |================================================
tel: (+31)-(0)30-533880 |    " Trust me; I know what I'm doing. "


From omni!hwajin@apple.com  Fri Sep 27 12:15:04 1991
From: hwajin@omni.com (Hwa-Jin Bae)
Date: Fri Sep 27 12:15:14 PDT 1991
Subject: Re: Switched from version 4.x to 5.0: ls and ll problem 
>I don't know about ll, but the problem with ls has something to do with
>VxWorks supporting a local file system -- maybe compatible with MSDOS?

I think you're right.  As I recall the old ls() used to
open the filesystem device and send down dir-entry ioctl to the
device specific ioctl routine.  The new one does something
different which works for locally supported filesystems (MSDOS, RT11) but
not for NFS or FTP/RSH files.  Indeed a very old and well known problem.

--
Hwa-Jin Bae		Interphase West
hwajin@omni.com		Santa Clara, California


From omni!hwajin@apple.com  Fri Sep 27 12:23:09 1991
From: hwajin@omni.com (Hwa-Jin Bae)
Date: Fri Sep 27 12:23:21 PDT 1991
Subject: Re: FPCP trap to uninit vector 
>00e04c  f201 9000                FMOVE .L    D1,#<FPCR>

>   Line 0e04c is the line that sets the FPCR to some random value,
>as D1 is unknown going into the function.  I rewrote the routine,
>without line 0e4c, and everything works fine.

The code looks pretty suspicious.  Since floating point libraries
are written differently in most cases it's hard to tell what
happened here.  If you used SunOS C compiler with -f68881 option,
the compiler would have probably used the ".il" stuff (inline
FP assembly code).  I think in some old versions of their code FPCR 
was used to set the rounding mode (in mode control part of FPCR)
and the code you mention looks like an attempt to set the value
back to the original value.  Looking at the new inline code in
/usr/lib/f68881/libm.il, there seem to be a better way with 
fewer instructions anyway.  Perhaps someone knowledgable about FP
stuff can clarify?  I'm pretty intrigued...

--
Hwa-Jin Bae		Interphase West
hwajin@omni.com		Santa Clara, California


From wrs!yuba!kent@uunet.uu.net  Fri Sep 27 18:55:25 1991
From: wrs!yuba!kent@uunet.uu.net (Kent Long)
Date: Fri Sep 27 18:55:41 PDT 1991
Subject: Re:  FPCP trap to uninit vector
 > In the function irint, there is a bug that sets the floating point
 > Exception enable byte register to random values.  Here is the
 > disasembled code:
 > 				
 >                         _irint:
 > 00e034  4e56 0000                LINK  .W    A6,#0
 > 00e038  f227 6b80                FMOVE .X    F7,-(A7)
 > 00e03c  f22e 5780 0008           FMOVE .D    ($8,A6),F7
 > 00e042  f22e 6380 0008           FMOVE .L    F7,($8,A6)
 > 00e048  202e 0008                MOVE  .L    ($8,A6),D0
 > 
 > 00e04c  f201 9000                FMOVE .L    D1,#<FPCR>

<insert audible groan here>
 
 > 00e050  504f                     ADDQ  .W    #8,A7
 > 00e052  4e5e                     UNLK        A6
 > 00e054  4e75                     RTS         
 > 
 >    Line 0e04c is the line that sets the FPCR to some random value,
 > as D1 is unknown going into the function.  I rewrote the routine,
 > without line 0e4c, and everything works fine.
 >    If anyone out there knows why this line was put in, I would
 > appreciate knowing.  Hope this may keep someone else from spending
 > a couple of days tracking down this problem.

I have confirmed that this is a bug in all 5.x versions of VxWorks for
the 68k.  (In fact, it's in 4.0.2 as well.)  As Mark correctly observed, 
the problem is that the FPCR register is erroneously being set.

This was a simple cut-and-paste error in the VxWorks source module.
The line which sets the FPCR should instead be restoring the value
of FP7, which was saved on the stack earlier (as you can see in the
code above).  So, it would appear that another side effect of this
bug is to clobber FP7.

The fix is pretty simple.  The following patch scripts should get things
back to what they should be.  (You can just include the appropriate lines
in your startup script, or enter them from the VxWorks shell.)

For VxWorks 4.0.2, 5.0 and 5.0b:

	pMathPatch = irint + 0x18;
	*pMathPatch = (short) 0xf21f;
	pMathPatch = irint + 0x1a;
	*pMathPatch = (short) 0x4b80;


For VxWorks 5.0.1 and 5.0.2:

	pMathPatch = mathHardIrint + 0x18;
	*pMathPatch = (short) 0xf21f;
	pMathPatch = mathHardIrint + 0x1a;
	*pMathPatch = (short) 0x4b80;


I think the quick unraveling of this ancient bug demonstrates 
that this exploder, and the User's Group in general, are valuable
resources to us here at Wind River, as well as our customers.
Thanks for your (collective) interest and diligence!

 - kent

   Kent Long	(kent@wrs.com)
   Wind River Systems



From smb@afterlife.ncsc.mil  Sun Sep 29 19:07:51 1991
From: smb@afterlife.ncsc.mil (Steve M. Burinsky)
Date: Sun Sep 29 19:08:00 PDT 1991
Subject: Status of comp.realtime.vxworks?
What's the status of trying to establish a news group (comp.realtime.vxworks?)
and the necessary link to keep the mailing list available for those without
news feeds?  Exploder traffic volume seems to be increasing; and I'd much
prefer reading it as news than as mail.

Steve
smb@afterlife.ncsc.mil


From hmp@frc2.frc.ri.cmu.edu  Mon Sep 30 10:49:51 1991
From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
Date: Mon Sep 30 10:50:04 PDT 1991
Subject: {MIN,MAX}DOUBLE

Hello all,

what would you say is the proper header file to reference for the definition
of MINDOUBLE and MAXDOUBLE? I'm cross-compiling with gcc, on a
SparcStation,for a 68k board, and the default values in  /usr/include/values.h
are too large (according to gcc). I've looked in the vxWorks and gcc-include
trees, to no avail. 
Short of a standard header file, what would be the correct values to use?

Thanks,

-Henning
+-------------------+-----------------------------+--------------------------+
|Henning Pangels    |hmp@frc2.frc.ri.cmu.edu      |     Field Robotics Center|
|Research Programmer|(412) 268-7088               |Carnegie-Mellon University|
+-------------------+-----------------------------+--------------------------+
      If you aren't part of the solution, you're part of the precipitate.


From dmorse@sun-valley.stanford.edu  Mon Sep 30 18:56:58 1991
From: dmorse@sun-valley.stanford.edu
Date: Mon Sep 30 18:57:08 PDT 1991
Subject: Re: {MIN,MAX}DOUBLE 
>Submitted-by hmp@frc2.frc.ri.cmu.edu  Mon Sep 30 10:49:51 1991
>Submitted-by: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels)
>
>Hello all,
>
>what would you say is the proper header file to reference for the definition
>of MINDOUBLE and MAXDOUBLE? I'm cross-compiling with gcc, on a
>SparcStation,for a 68k board, and the default values in  /usr/include/values.h
>are too large (according to gcc). I've looked in the vxWorks and gcc-include
>trees, to no avail. 
>Short of a standard header file, what would be the correct values to use?
>
>Thanks,
>
>-Henning

Henning,

You should be using the ANSI Standard C macros defined in the header file
"float.h", which is included with "gcc".  The macros in question are DBL_MIN
and DBL_MAX.  The double-precision values are

#define DBL_MIN 2.225073858507201e-308
#define DBL_MAX 1.797693134862316e+308

which should be correct for any floating-point processor that conforms to the
IEEE floating-point standard.   The macros for single-precision floats are

#define FLT_MIN 1.17549435e-38f
#define FLT_MAX 3.40282347e+38f

The header file containing all the integer macros is "limits.h".  Two
excellent references for the Standard C library and all the standard header
files (15 total) are

1.  ``Standard C, Quick Reference Series,'' P. J. Plauger and Jim Brodie,
    Microsoft Press, 1989.
2.  ``The Standard C Library,'' P. J. Plauger, Prentice-Hall, 1992.

The first one is relatively cheap.

Dennis Morse					Office: 415.723.1260
Stanford Aerospace Robotics Laboratory		Lab:	415.723.3608
Department Aeronautics & Astronautics
Durand Building, Room 250
Stanford, CA  94305

E-mail:	dmorse@sun-valley.stanford.edu


From omni!hwajin@apple.com  Mon Sep 30 20:26:18 1991
From: hwajin@omni.com (Hwa-Jin Bae)
Date: Mon Sep 30 20:26:27 PDT 1991
Subject: Re: {MIN,MAX}DOUBLE 
Your message dated: Mon, 30 Sep 91 10:50:08 PDT

>what would you say is the proper header file to reference for the definition
>of MINDOUBLE and MAXDOUBLE? I'm cross-compiling with gcc, on a
>SparcStation,for a 68k board, and the default values in  /usr/include/values.h
>are too large (according to gcc). I've looked in the vxWorks and gcc-include
>trees, to no avail. 
>Short of a standard header file, what would be the correct values to use?

Try looking at SunOS file /usr/lib/f68881/libm.il which contains
IEEE/ANSI floating point standard interface routines in assembly.
Routines max_normal() and min_normal() tell you normalized numbers
you should be able to use for MINDOUBLE and MAXDOUBLE.
Since my version of VxWorks is very old and doesn't have mathALib
I don't know if VxWorks supports these functions.

--
Hwa-Jin Bae		Interphase West
hwajin@omni.com		Santa Clara, California