From daemon@vxw.ee.lbl.gov  Fri Jan  1 04:00:33 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan  1 04:00:41 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan  1 04:00:24 PST 1993

        Subject: No one minding the store

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

Newsgroups: comp.os.vxworks
Subject: No one minding the store
Date: Thu, 31 Dec 1992 21:10:05 GMT
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Organization: National Center for Atmospheric Research
Message-ID: <1992Dec31.211005.19714@ncar.ucar.edu>
Sender: news@ncar.ucar.edu (USENET Maintenance)

I will gone on a field project in the Solomon Islands until about the 4-5 of Feb. During this
time there will be no human in charge of the archive, so complaints, requests, etc. will have
to wait.

See ya!
- -- 
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.

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

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

From root@sr.hp.com  Sat Jan  2 23:26:57 1993
From: Postmaster <postmaster@sr.hp.com>
Date: Sat Jan  2 23:27:06 PST 1993
Subject: Mail delayed on sr.hp.com (queue id: AA22003)
After 3 days and 18 hours, your message to:

  vxworks_users@vxw.ee.lbl.gov

has not yet been fully delivered for the following reason:

  Deferred: No route to host

Delivery is still pending for the following address(es):

  pam@hpsrmjs

Your message was received Wednesday, 30 December 1992 04:51:20 PST
by sr.hp.com.  sr.hp.com will continue to attempt to deliver
your message for an additional 11 days and 5 hours.  If it has not
been delivered by the end of that time it will be returned to you.

No further action is required by you.

Your message began as follows:
--------------------

To: vxworks_users@vxw.ee.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: comp.os.vxworks newsdigest
Message-Id: <9212301203.AA10941@vxw.ee.lbl.gov>

Submitted-by daemon@vxw.ee.lbl.gov  Wed Dec 30 04:03:22 1992
Submitted-by: daemon@vxw.ee.lbl.gov
 
Comp.Os.Vxworks Daily Digest    Wed Dec 30 04:03:12 PST 1992

From root@sr.hp.com  Sat Jan  2 23:33:57 1993
From: Postmaster <postmaster@sr.hp.com>
Date: Sat Jan  2 23:34:06 PST 1993
Subject: Mail delayed on sr.hp.com (queue id: AA27531)
After 3 days and 9 hours, your message to:

  vxworks_users@vxw.ee.lbl.gov

has not yet been fully delivered for the following reason:

  Deferred: No route to host

Delivery is still pending for the following address(es):

  pam@hpsrmjs

Your message was received Wednesday, 30 December 1992 13:53:24 PST
by sr.hp.com.  sr.hp.com will continue to attempt to deliver
your message for an additional 11 days and 14 hours.  If it has not
been delivered by the end of that time it will be returned to you.

No further action is required by you.

Your message began as follows:
--------------------

To: vxworks_users@vxw.ee.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Where are recent archives?
Message-Id: <9212302105.AA11211@vxw.ee.lbl.gov>

Submitted-by psm%helios.nosc.mil@nosc.mil  Wed Dec 30 13:04:46 1992
Submitted-by: psm%helios.nosc.mil@nosc.mil (Scot McIntosh)
 
The vxworks archives on thor.ucar.edu seem to have stopped in 1991. Is
there another archive where more recent material is kept?

From root@sr.hp.com  Sat Jan  2 23:44:26 1993
From: Postmaster <postmaster@sr.hp.com>
Date: Sat Jan  2 23:44:34 PST 1993
Subject: Mail delayed on sr.hp.com (queue id: AA05561)
After 1 day and 23 hours, your message to:

  vxworks_users@vxw.ee.lbl.gov

has not yet been fully delivered for the following reason:

  Deferred: No route to host

Delivery is still pending for the following address(es):

  pam@hpsrmjs

Your message was received Friday, 1 January 1993 00:04:59 PST
by sr.hp.com.  sr.hp.com will continue to attempt to deliver
your message for an additional 13 days.  If it has not
been delivered by the end of that time it will be returned to you.

No further action is required by you.

Your message began as follows:
--------------------

To: vxworks_users@vxw.ee.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Mail delayed on sr.hp.com (queue id: AA27531)
Message-Id: <9301010732.AA11973@vxw.ee.lbl.gov>

Submitted-by root@sr.hp.com  Thu Dec 31 23:32:38 1992
Submitted-by: Postmaster <postmaster@sr.hp.com>
 
After 1 day and 9 hours, your message to:

From root@sr.hp.com  Sat Jan  2 23:44:51 1993
From: Postmaster <postmaster@sr.hp.com>
Date: Sat Jan  2 23:45:01 PST 1993
Subject: Mail delayed on sr.hp.com (queue id: AA05530)
After 1 day and 23 hours, your message to:

  vxworks_users@vxw.ee.lbl.gov

has not yet been fully delivered for the following reason:

  Deferred: No route to host

Delivery is still pending for the following address(es):

  pam@hpsrmjs

Your message was received Thursday, 31 December 1992 23:58:24 PST
by sr.hp.com.  sr.hp.com will continue to attempt to deliver
your message for an additional 13 days.  If it has not
been delivered by the end of that time it will be returned to you.

No further action is required by you.

Your message began as follows:
--------------------

To: vxworks_users@vxw.ee.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: Mail delayed on sr.hp.com (queue id: AA22003)
Message-Id: <9301010726.AA11891@vxw.ee.lbl.gov>

Submitted-by root@sr.hp.com  Thu Dec 31 23:25:45 1992
Submitted-by: Postmaster <postmaster@sr.hp.com>
 
After 1 day and 18 hours, your message to:

From root@sr.hp.com  Sat Jan  2 23:48:42 1993
From: Postmaster <postmaster@sr.hp.com>
Date: Sat Jan  2 23:48:53 PST 1993
Subject: Mail delayed on sr.hp.com (queue id: AA19282)
After 1 day and 19 hours, your message to:

  vxworks_users@vxw.ee.lbl.gov

has not yet been fully delivered for the following reason:

  Deferred: No route to host

Delivery is still pending for the following address(es):

  pam@hpsrmjs

Your message was received Friday, 1 January 1993 04:36:50 PST
by sr.hp.com.  sr.hp.com will continue to attempt to deliver
your message for an additional 13 days and 4 hours.  If it has not
been delivered by the end of that time it will be returned to you.

No further action is required by you.

Your message began as follows:
--------------------

To: vxworks_users@vxw.ee.lbl.gov
From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder)
Subject: comp.os.vxworks newsdigest
Message-Id: <9301011200.AA12258@vxw.ee.lbl.gov>

Submitted-by daemon@vxw.ee.lbl.gov  Fri Jan  1 04:00:33 1993
Submitted-by: daemon@vxw.ee.lbl.gov
 
Comp.Os.Vxworks Daily Digest    Fri Jan  1 04:00:24 PST 1993

From daemon@vxw.ee.lbl.gov  Wed Jan  6 04:00:44 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan  6 04:00:55 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan  6 04:00:35 PST 1993

        Subject: VME based controllers and drivers for other buses?
        Subject: Looking for contact info for IBM/PC based realtime o/s vendors
        Subject: database for VxWorks
        Subject: Re: VME based controllers and drivers for other buses?

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

Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus
Subject: VME based controllers and drivers for other buses?
Date: Tue, 5 Jan 1993 15:57:50 GMT
From: mcgehee@noao.edu (Peregrine McGehee)
Organization: National Optical Astronomy Observatories, Tucson AZ
Message-ID: <1993Jan5.155750.14107@noao.edu>
References:  <9301030745.AA01864@hpmwtd.sr.hp.com>
Sender: news@noao.edu

Aloha,

For part of control system for the Gemini 8 meter telescopes project, we are
looking for VMEbus-based controllers for other buses. The purpose of using 
non-VME systems for some of our subsystems is to avoid placing a full VME
crate in locations that are both remote and only performing simple, relatively
low bandwidth tasks.

My current list is:

For BitBus:
	IST/DATEM DMC804 (the old XYCOM XVME-402)
	PEP Modular Computers Inc PB-BIT

For GESPAC FILBUS:
	??

For Profilbus (German standard fieldbus DIN 19245): 
	??

For CAN:
	??

I understand that some of the buses can be controlled via various serial I/O 
cards but it would be alot more helpful to have a VMEbus module that understood
the bus controller logic at the firmware level.

Also, any known VxWorks drivers for the above could be useful as well. I have
access to drivers for serial controllers and for the XVME-402.

Thanks for your help,
Peregrine
- -- 
Peregrine M. McGehee			Instrument Control Software Engineer
Gemini 8-m Telescopes Project		Internet: mcgehee@noao.edu

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

Newsgroups: comp.os.vxworks
Subject: Looking for contact info for IBM/PC based realtime o/s vendors
Date: Wed, 6 Jan 1993 00:00:29 GMT
From: gday@ignatz.inde.bc.ca (Gordon Day)
Organization: INDE Electronics, Inc.
Message-ID: <GDAY.93Jan5160029@ignatz.inde.bc.ca>
Sender: news@inde.bc.ca

The Subject: line says it all.  I am currently looking for any
information I can get on available realtime o/s' based on the 80386
ISA bus IBM/PC platform.  Any contact addresses or recommendations
(for or against) would be _greatly_ appreciated.  This is a new area
for me (being primarily a Unix programmer) so I have no idea where to
start looking.  Some products I already have in mind (but no contact
addresses) are:

VXworks -- I know this is available for 68000-based systems, but IBM/PCs?
iRMX    -- available for IBM/PC
QNX     -- available for IBM/PC

Others?

Ta,

Gordon.

P.S.: I _will_ summarise if there is interest.

_______________________________________________________________________________
gordon day, inde electronics, +1-403-430-1446.

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

Newsgroups: comp.os.vxworks
Subject: database for VxWorks
Date: 6 Jan 93 01:29:17 GMT
From: tzou@almaden.ibm.com (Shin-Yuan Tzou)
Organization: IBM Almaden Research Center
Keywords: vxworks, database, vendor software
Message-ID: <2131@coyote.UUCP>
Reply-To: tzou@almaden.ibm.com (Shin-Yuan Tzou)
Sender: news@ibmarc.UUCP

Are there vendors that provide database software for VxWorks?

Thanks,
Shin-Yuan Tzou
tzou@almaden.ibm.com

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

Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus
Subject: Re: VME based controllers and drivers for other buses?
Date: 6 Jan 93 11:12:51 GMT
From: kai@ade.no (Kai Atle Myrvang)
Organization: AD Elektronikk AS, Norway
Message-ID: <oF4XwB2w165w@ade.no>
References: <1993Jan5.155750.14107@noao.edu>

mcgehee@noao.edu (Peregrine McGehee) writes:

> 
> My current list is:
> 
> For BitBus:
> 	IST/DATEM DMC804 (the old XYCOM XVME-402)
> 	PEP Modular Computers Inc PB-BIT
> 
> For GESPAC FILBUS:
> 	??
> 
> For Profilbus (German standard fieldbus DIN 19245): 
> 	??    
What about PEP Modular Computer's VIUC and VIUC30.  They use the 68302 
for the Profibus.  Check with them regarding the software issue.  I know 
it's there for OS-9.

> Also, any known VxWorks drivers for the above could be useful as well. I have
> access to drivers for serial controllers and for the XVME-402.

There is a VxWorks driver for PEP's PB-BIT, according to their pricelist.

kai@ade.no (Kai Atle Myrvang)
AD Elektronikk AS, Norway    |  Keywords:  VMEbus
Phone:  Int+479 869 970      |             OS-9
Fax:    Int+479 869 920      |             VRTX

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

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

From calypso@palantir.gsfc.nasa.gov  Wed Jan  6 06:34:03 1993
From: Dave Kim <calypso@palantir.gsfc.nasa.gov>
Date: Wed Jan  6 06:34:12 PST 1993
Subject: Gnu assember manual
Hello everyone,
I am looking for a good manual for gnu assembler manual, preferably one that is better
 than the one offered by WRS.  I am an new comer to 68xxx assembly programming and
 having to port an assembly program written under PDOS operating system to VxWorks.
If anyone out there have a good gnu as manual with examples and can share, I would 

appreciate it.

In the mean time, can anyone help me convert following PDOS assembly code to gnu as:

LEA   0(A4,D1.W),A1

Please send any response to calypso@palantir.gsfc.nasa.gov

Thank you in advance.
David Kim

ps: I have already got gnu as distribution ftp files from MIT and found manuals are not part
of the distribution.

 

From visicom!VisiCom.COM!trest@nosc.mil  Wed Jan  6 08:11:48 1993
From: Mike Trest <trest@visicom.com>
Date: Wed Jan  6 08:12:05 PST 1993
Subject: Re: database for VxWorks

>Shin-Yuan Tzou:
>Are there vendors that provide database software for VxWorks?

The real-time environment is not the ideal model for a DBMS.
What we do is use client/server or RPC capabilities of VxWorks
to talk to DBMS services elsewhere in a network.

I have probably put as much SCSI disk & DAT tape on VxWorks
as anyone, however, I would not attempt anything more than
a symplistic DBMS where it is supported exclusively by
VxWorks.  

Therefore, I suggest a marriage between a SUN/OS or UNIX
DBMS embedded in the same cage with VxWorks real time boards.
We have designed this solution into our customer systems which
need access to DBMS by hard real-time applications.

The real design critical issues are:

	1. What is the allowable latency between the real-time
	   need for data and DBMS data availability?

	2. What is the frequency of DBMS read vice update?

	3. Do you need multiple requesting real-time processes?

	4. Do the requestors operate under a common "user"
	   access profile?
	   
	5. Where will data integrity locks be handled?

The conclusion offered of a marriage between VxWorks and
a good DBMS still requires many *APPLICATION* design decisions.

Good luck!  And please keep me/us posted on your progress.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From daemon@vxw.ee.lbl.gov  Thu Jan  7 04:00:54 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan  7 04:01:04 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan  7 04:00:43 PST 1993

        Subject: Help! (75 seconds to connect() after reboot)
        Subject: Re: VME based controllers and drivers for other buses?
        Subject: Re: Help! (75 seconds to connect() after reboot)

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

Newsgroups: comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip
Subject: Help! (75 seconds to connect() after reboot)
Date: 6 Jan 93 19:14:11 GMT
From: burch@seas.smu.edu (Chris Burchett)
Organization: SMU - School of Engineering & Applied Science - Dallas
Message-ID: <1993Jan6.191411.4535@seas.smu.edu>
Sender: news@seas.smu.edu (USENET News System)

Help!  I've found a situation in which I'm unsure of the best 
solution.  The problem has to do with a 75 second timeout in the 
connect() system call.  This occurs after one of two previously
connected machines is rebooted and an attempt is subsequently
made to reestablish communication.

I am using TCP/IP via Berkeley sockets to communicate between a Sun
workstation and an embedded system running VxWorks.  After communi-
cation is established, the embedded system is rebooted.  Once the
reboot is finished an attempt is made to reestablish the connection,
at which point, the connect() system call on the embedded system is
unable to reconnect and times out after 75 seconds.  

I believe this may happen because the embedded system is using the 
same port number that was used for a connection before the reboot 
occured (while the remote machine still maintains an established 
connection on that port).  It appears that (after a reboot) if the 
embedded system attempts to connect() using a port number which was
not previously connected, the connection is immediately established; 
this is the desired behavior.  However, if the embedded system uses 
a port which was previously connected, the connect() system call 
times out after 75 seconds.

Unfortunately, in my application 75 seconds is somewhat too long 
to wait.  I have a potential work around, but it seems to be
sort of a kludge and I felt certain that this problem must be a 
known one with known solutions.  (I'm relatively new to NEWS and if
this is a topic which has already been discussed in depth or I have
improperly used this service in any way, I appologize.)  But if 
someone with insight into this problem would enlighten me on the 
issues involved, or documentation to be studied, or potential 
solutions, I would greatly appreciate the help.

Chris Burchett
email: burch@seas.smu.edu
voice: (214) 205-8065

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

Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus
Subject: Re: VME based controllers and drivers for other buses?
Date: 6 Jan 93 12:37:03 GMT
From: meindert@inducom.nl (Meindert Kuipers)
Organization: Inducom Systems BV, Oss, Netherlands
Message-ID: <3450@inducom.nl>
References: <1993Jan5.155750.14107@noao.edu>
Followup-To: comp.os.vxworks

From article <1993Jan5.155750.14107@noao.edu>, by mcgehee@noao.edu (Peregrine McGehee):
> Aloha,
> 
> For part of control system for the Gemini 8 meter telescopes project, we are
> looking for VMEbus-based controllers for other buses. The purpose of using 
> non-VME systems for some of our subsystems is to avoid placing a full VME
> crate in locations that are both remote and only performing simple, relatively
> low bandwidth tasks.
> For BitBus:
> For GESPAC FILBUS:
> For Profilbus (German standard fieldbus DIN 19245): 
> For CAN:

M304 Bitbus controller with 8044
M360 CAN controller
M314 Intelligent serial controller with MC68302, should work with FILbus
     or Profibus, also an alternative for Bitbus
The above boards come with driver software in source code. All boards are
M-modules. Four can be plugged on a 6U VMEbus baseboard. There are currently
six manufacturers for M-modules.

- --
Meindert Kuipers             PO Box 627, NL 5340 AP  OSS       /\    /~~~\
meindert@inducom.nl          Phone: (31)4120-51055            /--\  |     |
AcQuisition Techonoly BV     Fax:   (31)4120-51050           /    \  \__\/
******  Manufacturers of M-modules and VMEbus boards                C     \  

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

Newsgroups: comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip
Subject: Re: Help! (75 seconds to connect() after reboot)
Date: 6 Jan 93 23:44:22 GMT
From: hwajin@iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <C0GHvI.3qI@iphasew.com>
References: <1993Jan6.191411.4535@seas.smu.edu>

In article <1993Jan6.191411.4535@seas.smu.edu> burch@seas.smu.edu (Chris Burchett) writes:
>Unfortunately, in my application 75 seconds is somewhat too long 
>to wait.

in vxworks 5.0+, there is an undocumented call -- connectWithTimeout() which
takes the same args as connect() plus extra last arg of type 'struct timeval *'
which you may be able to use -- you can specify the delay of your own.

or you could also just try non-blocking connect() -- set socket FIONBIO
temporarily, call connect(), which should return EINPROGRESS immediately
if connect attempt is to block -- when this happens you should select()
for 'write'.  the socket will be marked writeable once's it's connected.
to verify the connection after select() returns with 'write' selected, you
can do a getpeername().  this is actually what connectWithTimeout() does.
[ i do hope this is still in vxworks, it was a few years back when i put this
into the system ]

hwajin

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

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

From gdfwc3!kuwait!billb@texsun.central.sun.com  Thu Jan  7 12:23:32 1993
From: billb%kuwait@sun.com (Bill Baumann)
Date: Thu Jan  7 12:23:41 PST 1993
Subject: Forwarding of MAC broadcasts
VxWorks is causing problems by forwarding broadcast messages.

Here's the deal : I have a development system that is broadcasting over
FDDI to a specific IP address.  The IP address is a Unix box, and the
FDDI MAC address is a broadcast.  I'm using the AP Labs driver.

On my analyzer I see the broadcast message being retransmitted by the VxWorks
based cage.  The messages are UDP/IP, so the Unix machine sees both the
broadcast, and the retransmitted message.

It appears to me that VxWorks is doing IP forwarding of broadcast messages.
This is a definate no no.

Does anyone have any experience with this?

Does anyone know how to turn this behavior off?

Thanks BillB.

From gdfwc3!kuwait!billb@texsun.central.sun.com  Thu Jan  7 14:57:49 1993
From: billb%kuwait@sun.com (Bill Baumann)
Date: Thu Jan  7 14:58:01 PST 1993
Cool.  I don't think I've played in a pool yet.

Do it.

later, billb.

From thoff@netxwest.com  Thu Jan  7 15:42:48 1993
From: thoff@netxwest.com (Todd Hoff)
Date: Thu Jan  7 15:43:05 PST 1993
Subject: Problem with broadcasts
I'm having problems sending broadcasts over our network and
would like some help. 

The code that works on just a Sun network doesn't work under VxWorks,
and neither does the VxWorks demo code-- just to show I'm not totally
stupid :-)

The test involves 2 machines X and Y. Some vitals are specified below.
When I send directly from X to Y then Y receives the message, no problem.
When I send to a broadcast address of 144.10.5.255 the message doesn't
arrive. The reciever is setup to recieve for any address. I set the
socket option for BROADCAST to on.

Any ideas?
Any good debugging tips?

Thanx for any help.

There is a Sun router on the network with an IP address of 144.10.2.6.

The interface definition for machine X is:
ln (unit number 0):
     Flags: (0x63) UP BROADCAST ARP RUNNING
     Internet address: 144.10.5.33
     Broadcast address: 144.10.5.255
     Netmask 0xffff0000 Subnetmask 0xffffff00
     Ethernet address is 00:c0:21:01:02:21
     Metric is 0
     Maximum Transfer Unit size is 1500
     3633 packets received; 868 packets sent
     0 input errors; 0 output errors
     0 collisions

Machine Y is the same accept the IP address is 144.10.5.63.

Our route table is:
ROUTE NET TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
0.0.0.0          144.10.5.2       3      2       746           ln0
144.10.0.0       144.10.5.33      1      2       137           ln0
------------------------------------------------------------------------

ROUTE HOST TABLE
destination      gateway          flags  Refcnt  Use           Interface
------------------------------------------------------------------------
127.0.0.1        127.0.0.1        5      0       0             lo0

From gdfwc3!kuwait!billb@texsun.central.sun.com  Thu Jan  7 16:06:17 1993
From: billb%kuwait@sun.com (Bill Baumann)
Date: Thu Jan  7 16:06:26 PST 1993
Subject: Forwarding of ... & stupidness
Forget that last message.  My mailer got out of control.

Please respond to the MAC broadcast question to baumann@gdwest.gd.com

thanks BillB.

From vxworks@mars.psf.ge.com  Thu Jan  7 21:42:02 1993
From: vxworks@mars.psf.ge.com (vx_works)
Date: Thu Jan  7 21:42:13 PST 1993
Subject: MVME14x Diagnostics coexisting with VADSWorks
We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the
VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard
power-on-diagnostics. We have a project requirement to run some level of
board readiness tests without resorting to swapping the Motorola PROMS back
in. I've got a call in to Motorola to see about the availability of their
diagnostic source code, but I'm  wondering how other folks have dealt with
this problem. Has anyone developed downloadable diagnostic or readiness tests
(or adapted Motorola's code) for this situation?

John E. Thier
GE Defense Systems Dept.
Pittsfield MA
vxworks_list@mars.psf.ge.com

From daemon@vxw.ee.lbl.gov  Fri Jan  8 04:00:34 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan  8 04:00:44 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan  8 04:00:23 PST 1993

        Subject: RPC's
        Subject: Re: RPC's
        Subject: Booting from tape
        Subject: text editor for VxWorks ?
        Subject: Re: Forwarding of MAC broadcasts
        Subject: VX Works for MVME104

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

Newsgroups: comp.os.vxworks
Subject: RPC's
Date: Thu, 7 Jan 1993 14:32:48 GMT
From: sapp@falcon.ssc.gov (Kevin Sapp)
Organization: Superconducting Super Collider Laboratory, Dallas
Message-ID: <1993Jan7.143248.12461@sunova.ssc.gov>
Sender: usenet@sunova.ssc.gov (News Admin)

Greetings,

I have been working with VxWorks for a couple of weeks now, so I,m
at the dangerous stage !

I have RPC's working between a Sparc2 and a VxWorks MVME147, but only
at the shell.  When I execute the RPC server directly from the shell
everything works fine.  When I do a taskSpawn 100,0,20000,myRpcTest
the program dies down in the pmap_unset function during an indirect
function call off of (a1), the address that it is trying to call 
causes a bus error.

When doing the rpcgen I used the sun rpcgen to produce the client, server,
and .h files for both the sun and vxworks (is this OK?).

Any halp would be appreciated.

Also, is there a FAQ for this group? Where?
Is there a mail list ? How?

Thankx
Kevin.

- -- 
- ----------------------------------------------------------------------------
Kevin A. Sapp                    "A civilization depends upon the quality
Superconducting Super Collider    of individual it creates"   (Dune)
sapp@sawdust.ssc.gov :>( please NO NeXT mail                   

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

Newsgroups: comp.os.vxworks
Subject: Re: RPC's
Date: Thu, 7 Jan 1993 16:26:15 GMT
From: geoff@wrs.com (Geoff Espin)
Organization: Wind River Systems, Inc.
Message-ID: <geoff.726423975@wrs.com>
References: <1993Jan7.143248.12461@sunova.ssc.gov>
Sender: news@wrs.com (News Manager)

sapp@falcon.ssc.gov (Kevin Sapp) writes:

>I have RPC's working between a Sparc2 and a VxWorks MVME147, but only
>at the shell.  When I execute the RPC server directly from the shell
>everything works fine.  When I do a taskSpawn 100,0,20000,myRpcTest
>the program dies down in the pmap_unset function during an indirect
>function call off of (a1), the address that it is trying to call 
>causes a bus error.

Did you call rpcTaskInit()?

    rpcTaskInit() - initialize a task's access to the RPC package
    This routine must be called by a task before it makes any calls to
    other routines in the RPC package.

WRS' RPC is a port of the standard Sun distribution which
contains numerous static variables making it non-reentrant.
Task variables are used to make the statics task specific,
therefore rpcTaskInit() must be called before making any RPC calls
in a new task context.

Geoff
- -- 
Geoff Espin		geoff@wrs.com	(510)748-4100
Wind			River		Systems
1010 Atlantic Avenue	Alameda		CA 94501

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

Newsgroups: comp.os.vxworks
Subject: Booting from tape
Date: 7 Jan 93 16:30:57 GMT
From: jcreem@Rapnet.Sanders.Lockheed.Com (Jeffrey M. Creem x5700)
Organization: Sanders Associates
Keywords: SCSI, booting, tape
Message-ID: <1993Jan7.163057.19982@Rapnet.Sanders.Lockheed.Com>

Has anyone tried booting vxWorks from a SCSI tape (in our case exabyte
8500) on a mv167? We are currently exploring several boot options and are
trying to come up with the best method.

Jeff Creem

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

Newsgroups: comp.os.vxworks
Subject: text editor for VxWorks ?
Date: 7 Jan 93 18:09:59 GMT
From: jprice@lds.loral.com (Jeffrey Price)
Organization: Loral Data Systems
Keywords: editor vi text edit
Message-ID: <1993Jan7.180959.4005@lds.loral.com>
Reply-To: jprice@lds.loral.com
Sender: news@lds.loral.com

Rumor has it that there are some text editors out there in the ether
somewhere that run under VxWorks.  I have even heard that a copy the
beloved "vi" editor exists for VxWorks. 

Can anyone confirm or deny these rumors, and if they are true 
where might one get one of these ?

Thanks,

Jeff Price
813-371-0811  x6823
email : jprice@mail.lds.loral.com

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

Newsgroups: comp.os.vxworks
Subject: Re: Forwarding of MAC broadcasts
Date: Thu, 7 Jan 1993 21:56:12 GMT
From: healy@nosc.mil (Mike Healy)
Organization: Naval Ocean Systems Center, San Diego
Message-ID: <1993Jan7.215612.8985@nosc.mil>
References: <9301071938.AA09078@kuwait.whizkids>

In article <9301071938.AA09078@kuwait.whizkids> billb%kuwait@sun.com (Bill Baumann) writes:
>VxWorks is causing problems by forwarding broadcast messages.
>
>Here's the deal : I have a development system that is broadcasting over
>FDDI to a specific IP address.  The IP address is a Unix box, and the
>FDDI MAC address is a broadcast.  I'm using the AP Labs driver.
>
>On my analyzer I see the broadcast message being retransmitted by the VxWorks
>based cage.  The messages are UDP/IP, so the Unix machine sees both the
>broadcast, and the retransmitted message.
>
>It appears to me that VxWorks is doing IP forwarding of broadcast messages.
>This is a definate no no.
>
>Does anyone have any experience with this?
>
>Does anyone know how to turn this behavior off?
>
>Thanks BillB.
>

I ran into something similar just this morning. We are using UDP/IP
broadcast datagrams for one of our protocols. We have a multiprocessor
system in which each ethernet port is handling a different simulation
protocol (DIS, SIMNET, ...). I found that in the board with the non-
UDP/IP protocol, where my input hook would return any UDP/IP 
broadcast datagrams to the vxWorks's protocol stack, the other board 
was receiving the broadcast datagram twice. I thought the board was 
forwarding the datagram onto the backplane network and that's why the 
other board was getting the datagram twice - the original datagram 
from the ethernet, and then the same datagram forwarded over the 
backplane network. However, this post seems to indicate a more 
pathological situation.

My fix was to trap these bad boys in my ethernet hook input and toss 
them, but obviously this is not general purpose and somewhat of a 
kludge. 

This sounds like a job for . . . WRS!! :-)

Mike Healy

healy@nosc.mil

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

Newsgroups: comp.os.vxworks
Subject: VX Works for MVME104
Date: Fri, 8 Jan 1993 03:33:21 GMT
From: raob@mullian.ee.mu.oz.au (r. oxbrow)
Organization: Electrical and Electronic - University of Melbourne 
Message-ID: <9300814.7765@mulga.cs.mu.OZ.AU>
Sender: news@cs.mu.OZ.AU

	Does anybody run VX works on a Motorola MVME-104 board ?

	thanks,

		richard/..
richard oxbrow			   |internet    raob@mullian.ee.mu.OZ.AU
dept. ee eng,  uni of melbourne    |uunet       ..!uunet!munnari!mullian!raob
parkville, victoria         3052   |fax         +[613] 344 6678   	   
australia               	   |phone       +[613] 344 6782

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

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

From gordon@tpocc.gsfc.nasa.gov  Fri Jan  8 04:51:24 1993
From: gordon@tpocc.gsfc.nasa.gov (Gordon Miller)
Date: Fri Jan  8 04:51:34 PST 1993
Subject: Re:  RPC's

sapp@falcon.ssc.gov (Kevin Sapp) writes:

>I have RPC's working between a Sparc2 and a VxWorks MVME147, but only
>at the shell.  When I execute the RPC server directly from the shell
>everything works fine.  When I do a taskSpawn 100,0,20000,myRpcTest
>the program dies down in the pmap_unset function during an indirect
>function call off of (a1), the address that it is trying to call 
>causes a bus error.

I am surprised this works from the shell.  A quick look at the 
manual shows that your arguement list could be the problem.  The
call taskSpawn has a usage as follows:

    int taskSpawn (name, priority, options, stackSize, entryPt,
        arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9,arg10)
where
    char    *name;     /* name of the new task       */
    int     priority;  /* priority of the new task   */
    int     options;   /* task option word           */
    int     stackSize; /* size of stack, be generous */
    FUNCPTR entryPt;   /* entry point of new task    */
    int     arg1;      /* task arguement one         */
    int     arg2;      /* task arguement two         */
    int     arg3;      /* task arguement three       */
    int     arg4;      /* task arguement four        */
    int     arg5;      /* task arguement five        */
    int     arg6;      /* task arguement six         */
    int     arg7;      /* task arguement seven       */
    int     arg8;      /* task arguement eight       */
    int     arg9;      /* task arguement nine        */
    int     arg10;     /* task arguement ten         */

If taskSpawn line you used really is as stated in your post, then
you forgot the name for the new task, shifting the entire arguement 
list off by one.  The results of this are unknown to me.

If you do not need to worry about the priority, options, stack size 
and name (for referencing the task from the shell), you could use 
call "sp".  This will spawn a task with the default parameters.
Its usage is as follows:
    
    int sp (func, arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9)

where

     FUNCPTR func;       /* entry point of new task    */
     int arg1,arg2,arg3; /* passed to spawned task     */
     int arg4,arg5,arg6; /* passed to spawned task     */
     int arg7,arg8,arg9; /* passwd to spawned task     */

Jason's comments about RPC needed to be initialized (and built 
into your vxWorks kernel) are still valid.  Hope this helps.

Gordon Miller                  Integral Systems, Inc.
gordon@tpocc.gsfc.nasa.gov     1100 West Street
                               CSC/LR
(301) 497-2416                 Laurel, MD 20707

From fjr@rayssd.ssd.ray.com  Fri Jan  8 06:39:32 1993
From: Roeber <fjr@ssd.ray.com>
Date: Fri Jan  8 06:39:42 PST 1993
Subject: Re:  text editor for VxWorks ?
Jeff Price writes:

>  Rumor has it that there are some text editors out there in the ether
>  somewhere that run under VxWorks.  I have even heard that a copy the
>  beloved "vi" editor exists for VxWorks. 
>  
>  Can anyone confirm or deny these rumors, and if they are true 
>  where might one get one of these ?

The VxWorks archive has a copy of stevie in it (a vi clone).  Sorry but I
haven't used it under VxWorks but it is probably what you want.   Fred

----------

Subject: Monthly VxWorks archive posting

Submitted-by thor@thor.atd.ucar.edu  Tue Dec 31 22:59:28 1992
Submitted-by: thor@thor.atd.ucar.edu (Richard Neitzel)

This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:

-rw-r--r--  1 thor        41196 Oct 16 09:43 stevie01
-rw-r--r--  1 thor        35279 Oct 16 09:43 stevie02
-rw-r--r--  1 thor        35278 Oct 16 09:43 stevie03
-rw-r--r--  1 thor        35012 Oct 16 09:43 stevie04
-rw-r--r--  1 thor        34502 Oct 16 09:43 stevie05
-rw-r--r--  1 thor        37476 Oct 16 09:43 stevie06
-rw-r--r--  1 thor        30073 Oct 16 09:43 stevie07
-rw-r--r--  1 thor        31562 Oct 16 09:43 stevie08
-rw-r--r--  1 thor        37360 Oct 16 09:43 stevie09
-rw-r--r--  1 thor        20662 Oct 16 09:43 stevie10
-rw-r--r--  1 thor        25717 Oct 16 09:43 stevie11
-rw-r--r--  1 thor        28075 Oct 16 09:43 stevie12
-rw-r--r--  1 thor        31852 Oct 16 09:43 stevie13

From baumann@proton.llumc.edu  Fri Jan  8 10:01:41 1993
From: baumann@proton.llumc.edu (Michael Baumann)
Date: Fri Jan  8 10:01:56 PST 1993
Subject: Re:  RPC's

>Submitted-by: gordon@tpocc.gsfc.nasa.gov (Gordon Miller)
> 
>
>sapp@falcon.ssc.gov (Kevin Sapp) writes:
>
>>I have RPC's working between a Sparc2 and a VxWorks MVME147, but only
>>at the shell.  When I execute the RPC server directly from the shell
>>everything works fine.  When I do a taskSpawn 100,0,20000,myRpcTest
>>the program dies down in the pmap_unset function during an indirect
>>function call off of (a1), the address that it is trying to call 
>>causes a bus error.
>
>I am surprised this works from the shell.  

I'm not. Odds are he uses NFS for some functions, this allows:
1) RPC to be loaded
2) rpcTaskInit() is run for the shell. So his server gets the shells task vars.

When you spawn a process, that process MUST run rpcTaskInit(), or you don't
get the needed task variables added to the task context. This should be
done long before you even consider opening a dialoge (so to speak) with the
portmapper.

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

From woody@sparta.com  Fri Jan  8 15:25:36 1993
From: woody@sparta.com (Robert "Woody" Woodburn)
Date: Fri Jan  8 15:25:45 PST 1993
Subject: peregrine 4211 driver for v3d running 5.0.2
Hi,

We're in the processing of working with Interphase to port the 
4211 FDDI driver to the i960.  As a first step, we wanted to get
the driver running on one of our more familiar 68k platforms, just
as a reference.  But the driver doesn't seem to work out of the 
box.  We have version 1.2.

It appears that the setup_bufs routine is trashing something before
it returns.  Has anybody got the driver running on a v3d?  I thought
I'd check before I start digging too far...

Thanks

wood y
(woody@sparta.com)

From daemon@vxw.ee.lbl.gov  Sat Jan  9 04:00:50 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan  9 04:01:00 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan  9 04:00:40 PST 1993

        Subject: mv167/vmechip2 dma library
        Subject: Re: Forwarding of MAC broadcasts
        Subject: Re: Problem with broadcasts

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

Newsgroups: comp.os.vxworks
Subject: mv167/vmechip2 dma library
Date: Fri, 8 Jan 1993 17:15:13 GMT
From: geger@phantom.den.mmc.com (George Eger (303) 971-6974)
Organization: Martin Marietta Astronautics Group
Keywords: mv167 vmechip2 dma
Message-ID: <1993Jan8.171513.11601@den.mmc.com>
Sender: news@den.mmc.com (News)

Has anyone out there got a basic library to run the vmechip2's dma controller
on a mv167?  I am looking for something like:

	dmaInit();
	dmaGet(to, from, length);
	dmaPut(to, from, length);

and an optional routine to set non-blocking, completion notification,
bus priority levels and modes, and abort:

	dmaIoctl(...);

If not, we are going to build one and will post it.

Thanks,

GWE

||==========================================================================
||George Eger / geger@den.mmc.com ||   Voice - (303) - 971 - 6974         ||
||Fault Tolerant Avionics         ||   Fax   - (303) - 977 - 1145         ||
||Launch Systems                  ||   MS T320                            ||
||Martin Marietta Astro Group     ||   P.O. Box 179, Denver CO 80201      ||
||==========================================================================
||We are at a cusp - between the past when humans were more reliable than ||
||computers and the future when computers are more reliable than humans.  ||
||==========================================================================
||All opinions (however truthful or misinformed) are my own.              ||
||==========================================================================

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

Newsgroups: comp.os.vxworks
Subject: Re: Forwarding of MAC broadcasts
Date: Sat, 9 Jan 1993 09:38:18 GMT
From: hjb@netcom.com (H. J. Bae)
Organization: Peaceful Star, Inc.
Message-ID: <1993Jan9.093818.3283@netcom.com>
References: <9301071938.AA09078@kuwait.whizkids>

In article <9301071938.AA09078@kuwait.whizkids> billb%kuwait@sun.com (Bill Baumann) writes:
>It appears to me that VxWorks is doing IP forwarding of broadcast messages.
>This is a definate no no.

since nobody has answered this one so far -- as far as i know vxworks does
not forward broadcast ip packets.  grab a copy of ip_input.c from 4.3
bsd tahoe release, which is essentially used unchanged in vxworks 5.0 --
and read it.  the ip_forward() is *not* called for the broadcast packets.

possible  source of error:  either interface is not configured correctly
with proper broadcast address which matches the net/subnet mask, or a
problem with the driver itself -- not likely.

i'd like to find out more about various configurations, details, etc.

hwajin

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

Newsgroups: comp.os.vxworks
Subject: Re: Problem with broadcasts
Date: Sat, 9 Jan 1993 09:40:29 GMT
From: hjb@netcom.com (H. J. Bae)
Organization: Peaceful Star, Inc.
Message-ID: <1993Jan9.094029.3491@netcom.com>
References: <9301072246.AA11015@cinnabar.netx.com>

In article <9301072246.AA11015@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes:
>The interface definition for machine X is:
>ln (unit number 0):
>     Flags: (0x63) UP BROADCAST ARP RUNNING
>     Internet address: 144.10.5.33
>     Broadcast address: 144.10.5.255
>     Netmask 0xffff0000 Subnetmask 0xffffff00
					^^^^^^^^^^^

>
>Our route table is:
>ROUTE NET TABLE
>destination      gateway          flags  Refcnt  Use           Interface
>------------------------------------------------------------------------
>0.0.0.0          144.10.5.2       3      2       746           ln0
>144.10.0.0       144.10.5.33      1      2       137           ln0
>------------------------------------------------------------------------
>

trying adding a net route entry for 144.10.5.0 subnet?

hwajin

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

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

From daemon@vxw.ee.lbl.gov  Sun Jan 10 04:03:27 1993
From: daemon@vxw.ee.lbl.gov
Date: Sun Jan 10 04:03:36 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 10 04:03:18 PST 1993

        Subject: Re: Forwarding of MAC broadcasts

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

Newsgroups: comp.os.vxworks
Subject: Re: Forwarding of MAC broadcasts
Date: Sun, 10 Jan 1993 03:17:14 GMT
From: rypma@waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <C0MBsq.EBL@waterloo.hp.com>
References: <9301071938.AA09078@kuwait.whizkids>
Sender: news@waterloo.hp.com (NetNews)

Bill Baumann (billb%kuwait@sun.com) wrote:
: VxWorks is causing problems by forwarding broadcast messages.
: 
: Here's the deal : I have a development system that is broadcasting over
: FDDI to a specific IP address.  The IP address is a Unix box, and the
: FDDI MAC address is a broadcast.  I'm using the AP Labs driver.

I just read Hwa Jin's response to this and I think I have a glimmering of
an explaination.

Note that the _MAC_ address is a broadcast and the _IP_ address is not.
Now, one of the (many) failings of BSD 4.3 network code is the fact that
the "broadcastness" of the incoming frame is lost once you get into IP
protocol code. If the IP address is not broadcast, whether legitimately so
or as a result of a misunderstood subnet broadcast (due to incorrect or no
subnet mask), IP will forward if so configured. Of course, it REALLY should
NOT be forwarded because the MAC address was broadcast - information that
BSD 4.3 Tahoe quietly throws away.

BSD Networking Release 2 code nicely fixes this (I'm not sure whether Reno
code does or not, but it may).

We had the same problem in VxWorks 5.0.3 network code causing problems when
multiple subnets were in use on the same wire - we would forward another
subnet's broadcasts. I fixed this in our VxWorks networking code by just not
forwarding frames which would be retranmitted on the same interface on which
they came in. Not an ideal solution, but it looked after the immediate problem
(besides, we don't claim to be an ideal IP router and we're not a
workstation :-).

Regards,

Ted Rypma
HP Panacom Division

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

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

From thoff@netxwest.com  Sun Jan 10 07:25:13 1993
From: thoff@netxwest.com (Todd Hoff)
Date: Sun Jan 10 07:25:29 PST 1993
Subject: More on broadcast problem
With the help of the Sniffer we pinned down why IP broadcasts 
are not being recieved. It appears when using a subnetmask that
differs from netmask then broadcast IP addresses are not translated 
to the broadcast ethernet address.

With:
1. IP Address       = 144.10.5.33
2. Mask             = 0xffff0000
3. Subnetmask       = 0xffffff00
4. Broadcast Address= 144.10.5.255

The ethernet address of the packet goes to our router, not the
expected broadcast ethernet address.

With:
1. IP Address       = 144.10.5.33
2. Mask             = 0xffff0000
3. Subnetmask       = 0xffff0000
4. Broadcast Address= 144.10.255.255

The broadcast works fine, the ethernet address is all 1s as expected.
The suggestion here is that code resolving IP addresses isn't looking
at the subnet mask. Is seems the broadcast IP address is not recognized
as such and is forwarded to the router where the router
of course will not forward the broadcast.

BTW, various manipulations of the route tables had no effect.

I suppose this is a bug.

From daemon@vxw.ee.lbl.gov  Mon Jan 11 04:00:50 1993
From: daemon@vxw.ee.lbl.gov
Date: Mon Jan 11 04:01:00 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 11 04:00:40 PST 1993

        Subject: Re: Forwarding of MAC broadcasts
        Subject: Re: More on broadcast problem

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

Newsgroups: comp.os.vxworks
Subject: Re: Forwarding of MAC broadcasts
Date: Sun, 10 Jan 1993 14:04:15 GMT
From: hjb@netcom.com (H. J. Bae)
Organization: Peaceful Star, Inc.
Message-ID: <1993Jan10.140415.1003@netcom.com>
References: <9301071938.AA09078@kuwait.whizkids> <C0MBsq.EBL@waterloo.hp.com>

In article <C0MBsq.EBL@waterloo.hp.com> rypma@waterloo.hp.com (Ted Rypma) writes:
>I just read Hwa Jin's response to this and I think I have a glimmering of
>an explaination.
>
>Note that the _MAC_ address is a broadcast and the _IP_ address is not.
>Now, one of the (many) failings of BSD 4.3 network code is the fact that
>the "broadcastness" of the incoming frame is lost once you get into IP
>protocol code. If the IP address is not broadcast, whether legitimately so
>or as a result of a misunderstood subnet broadcast (due to incorrect or no
>subnet mask), IP will forward if so configured. Of course, it REALLY should
>NOT be forwarded because the MAC address was broadcast - information that
>BSD 4.3 Tahoe quietly throws away.
>
>BSD Networking Release 2 code nicely fixes this (I'm not sure whether Reno
>code does or not, but it may).

as always, ted is quite correct about this.  [ah... so that's what
that datalink bcast flags/stuff was all about in net2 code, silly me]
of course, if things are done "correctly" (correct subnet masks,
correct ip broadcast addr derived from subnet mask, etc.) the problem 
should not occur.  thanks.

hwajin

- -- 
Peaceful Star Project	hjb@netcom.com
2899 Ford Street	Available for peaceful, responsible work only.
Oakland, CA 94601	(510) 536-7607

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

Newsgroups: comp.os.vxworks
Subject: Re: More on broadcast problem
Date: Sun, 10 Jan 1993 18:40:53 GMT
From: hjb@netcom.com (H. J. Bae)
Organization: Peaceful Star Project
Message-ID: <1993Jan10.184053.9292@netcom.com>
References: <9301081857.AA11564@cinnabar.netx.com>

In article <9301081857.AA11564@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes:
>The suggestion here is that code resolving IP addresses isn't looking
>at the subnet mask. Is seems the broadcast IP address is not recognized
>as such and is forwarded to the router where the router
>of course will not forward the broadcast.

here's in_broadcastaddr() from the tahoe code:

/*
 * Return 1 if the address might be a local broadcast address.
 */
in_broadcast(in)
	struct in_addr in;
{
        register struct in_ifaddr *ia;
        u_long t;

        /*
         * Look through the list of addresses for a match
         * with a broadcast address.
         */
        for (ia = in_ifaddr; ia; ia = ia->ia_next)
            if (ia->ia_ifp->if_flags & IFF_BROADCAST) {
                if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == in.s_addr)
                     return (1);
                /*
                 * Check for old-style (host 0) broadcast.
                 */
                if ((t = ntohl(in.s_addr)) == ia->ia_subnet || t == ia->ia_net)
                    return (1);
        }
        if (in.s_addr == INADDR_BROADCAST || in.s_addr == INADDR_ANY)
                return (1);
        return (0);
}

the only reason this could fail would be some incorrect configuration
some where (at some participating node).  if you're suspecting vxworks
for not recognizing subnet bcast ip address as such, you can call
in_broadcast from the shell or write a small piece of code to find out.
using the shell's built-in debugger (assembly) you could single step
to track down the exact behavior, if you'd like.  but, as the code says,
if netif bcast ip address is incorrectly set on some node, this code
will return 0.

if you have a traditional network (the one that has one network/subnet
per physical segment of ethernet) and your target machine is not
multi-homed, it is also legal to use all 1's ip address to indicate
"broadcast to the immediately attached networks only".  trying
"255.255.255.255", for example, should work and you can avoid
the headaches.

the issue regarding the route entry:  ip_output() has to be able to
resolve the route entry for the given destination address -- to
fetch the netif pointer used throughout (including arpresolve process
which uses in_broadcast before actually sending out any arp req's).
i'd still maintain that you need to keep correct route tables for
the subnets.  given that, and given that the correct netif (which
will be in the route entry returned by rtalloc) has correct broadcast
address proper for the subnet, things should work.  all participating
machines should be checked for this. [as i'm not still sure of your
exact configuration]

if someone has any insight, i'm very interested to hear...  [guess
i'm just very very curious....  :-) ]  thanks

hwajin

- -- 
Peaceful Star Project	hjb@netcom.com
2899 Ford Street	Available for peaceful, responsible work only.
Oakland, CA 94601	(510) 536-7607

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

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

From phil@naic.edu  Mon Jan 11 06:08:18 1993
From: phil@naic.edu (Phil Perillat Rm 407 X286)
Date: Mon Jan 11 06:08:27 PST 1993
Subject: dma routines for motorola vmechip2
Georoge Eger writes....

Has anyone out there got a basic library to run the vmechip2's dma controller
on a mv167?  I am looking for something like:

	dmaInit();
	dmaGet(to, from, length);
	dmaPut(to, from, length);

and an optional routine to set non-blocking, completion notification,
bus priority levels and modes, and abort:

	dmaIoctl(...);

If not, we are going to build one and will post it.

........

Be careful doing dma with the mv167 board. The vmechip2 has two bugs that
might bite (i still remember the weeks i spent scratching these bites!!)

1. dma xfers in d16, fifomode don't work.
   We have an a/d board that looks like a fifo in A16 space. I was accessing
   it with dma in D16 (i had used up all of the mappings...). Turns out that
   the chip needs the vmebus address to increment so it can route the
   D16 data onto the 32bit local bus. this will not be a problem for
   most people since they probably won't use this mode...

2. If you are doing dma with the vmechip2, and an interrupt comes in for
   the same board, things get trashed. When the interrupt arrives,
   the vmechip2 does not wait for the dma controller to give up the vme bus
   before it drives the interrupt acknowledge information onto the vme bus.
   The interrupt level for the acknowledge gets or'ed onto address bits
   a03-a01 while the dma xfer is still active. This will cause the dma 
   address for the dma to be corrupted.
   Motorola's fix for this is to disable vme interrupts for the vmechip2 that
   is doing dma. 

On the plus side, i was impressed with the dma performance i saw. The 
vmechip2 would run the a/d card at it's stated maximum rate. The setup
times for the various vmebus handshakes were what the vme standard says
(and nothing more!).

I struggled with these problems for awhile ... turns out motorola had already
found them (just ask them for their tech notes on the vmechip2 bugs).
They claim to have a silicon fix that should come out  in  early '93 (last
 i heard..).

by the way, i've got a set of routines to setup and do the dma. I kinda let 
them slide once i ran into these problems so they need a little documentation
and probably a little more testing. If you really want them  i guess i 
could put them in some kind of humanly readable form....

phil perillat
arecibo observatory
phil@naic.edu

From daemon@vxw.ee.lbl.gov  Tue Jan 12 04:00:48 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 12 04:00:58 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 12 04:00:37 PST 1993

        Subject: performance of fprintf() for floating point

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

Newsgroups: comp.os.vxworks
Subject: performance of fprintf() for floating point
Date: Mon, 11 Jan 1993 21:12:42 GMT
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Message-ID: <1993Jan11.211242.16776@ncar.ucar.edu>
Sender: news@ncar.ucar.edu (USENET Maintenance)

I am having a performance problem with fprintf().  I have an application that
samples antenna position at 15 Hz, and stores the binary positions in a
dynamically allocated buffer.  When I'm done sampling, I convert from binary to
floating point (angles in degrees), and write the values in ASCII,
using the following loop:

        for (ULONG i= 0; i < CSampleCount_; ++i)
        {
            fprintf(Cfout_, "%8.2f %8.2f\n",
                p->az * BIN_TO_DEG, p->el * BIN_TO_DEG);
            ++p;
        }

On a MVME133 (68020 @ 20Mhz), running under VxWorks 5.02b, release 1, I can only
write 3-4 lines/second, even if I'm writing to "/null".  The MVME133 has a
co-processor, and I can't figure out what could possibly be taking so long . .

I suppose I could convert from binary to ASCII floating point on my networked Sun
SPARC instead, but this solution isn't as "clean".
- -- 
	Joe VanAndel  		Internet:vanandel@ncar.ucar.edu
	National Center for Atmospheric Research

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

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

From fjr@rayssd.ssd.ray.com  Tue Jan 12 07:29:49 1993
From: Roeber <fjr@ssd.ray.com>
Date: Tue Jan 12 07:29:59 PST 1993
Subject: Re:  performance of fprintf() for floating point
Joe Van Andel writes:

>  On a MVME133 (68020 @ 20Mhz), running under VxWorks 5.02b, release 1, I
>  can only write 3-4 lines/second, even if I'm writing to "/null".  The
>  MVME133 has a co-processor, and I can't figure out what could possibly
>  be taking so long . .

Below is an old message on the subject:

---------- Begin Forwarded Message ----------

    I did some grinding and got the cvtb (2) routine to go much faster.

               
    The Results:
 
        Hardware:
            mvme133xt, 25MHz, 68020
 
        Test:
            timexN sprintf, y, "%7.2lf", x
             
        Old cvtb (2) without floating point CP: 33 ms
        Old cvtb (2) with floating point CP:    16 ms
 
        New cvtb (2) without floating point CP: 9 ms
        New cvtb (2) with floating point CP:    2 ms
 
 
    That is about as good as I'm going to get it without spending much more
    time.  But is this fast enough for you?  Your whole conversion will still
    take 10-15 ms.  (15 times faster)  That's well above your motor latency.
 
    So tell me what you want...
 
        I can give you a new floatLib.o for your library.
        Or if you want to try to grind this code some more I could even
        send you source to floatLib.c.

    The moral of the story is floating point conversions to ascii are very
    expensive operations.  Not too much I can do about that.
 
 
        John Fogelin
 
        Wind River Systems
 
---------- Begin Forwarded Message ----------

At a later point Alan Biocca posted a routine for fast printing of floating
point numbers on 680X0 processors.  I am not sure but the routine might
be in the VxWorks archive.    Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|

From jcn@mpl.ucsd.edu  Tue Jan 12 08:28:01 1993
From: jcn@mpl.ucsd.edu (Chris Nickles)
Date: Tue Jan 12 08:28:14 PST 1993
Subject: Re:  performance of fprintf() for floating point

Another approach, if you don't mind a little nitty-gritty, would be
to scale the data as an integer in small units, e. g. tenths or
hundredths of a degree, and then stuff a dot into the output string.

	Chris Nickles
	UCSD Marine Physical Lab

From daemon@vxw.ee.lbl.gov  Wed Jan 13 04:00:50 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 13 04:01:02 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 13 04:00:40 PST 1993

        Subject: sgi CC v3.1 & VxGDB incompatible
        Subject: vxWorks Sockets and Pipes
        Subject: Re: vxWorks Sockets and Pipes
        Subject: Re: sgi CC v3.1 & VxGDB incompatible
        Subject: Re: performance of fprintf() for floating point

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

Newsgroups: comp.os.vxworks,comp.sys.sgi
Subject: sgi CC v3.1 & VxGDB incompatible
Date: 12 Jan 93 10:16:38 -0400
From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer)
Organization: NRL SPACE SYSTEMS DIVISION
Message-ID: <1993Jan12.101638.901@nrlvx1.nrl.navy.mil>

Hi folks,

	I am using an SGI indigo r3000 as a vxworks host
(Iris 4D1-4.1) with cc (v3.10)  and VxGDB to debug software (v1.1).  
The following problems occur when I load a file into the debugger:

if the source code has a "struct" in it :
	unknown symbol type 1a 
if the source code has a "union" in it:
	unknown symbol type 1b

The vxworks tech support mentions that these messages come from the GNU
gdb kernel which they use, and mentioned that these problems do not occur
with atleast version 2.0 of the cc compiler.

has anyone had this problem and solved it? is all I need an older version
of the C compiler?
- -- 
Doug Dyer   *    STI   *    dyer@nrlvax.nrl.navy.mil    | "(2B) | !(2B) -> ?"
DISCLAIMER:  These are my opinions, and not necessarily |  LOWLY SHOPKEEPER,  
those of STI, NRL,  and most likely you too.            | WHERE IS YOUR PEZZ!
- --------------------------------------------------------+---------------------

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

Newsgroups: comp.os.vxworks
Subject: vxWorks Sockets and Pipes
Date: Tue, 12 Jan 1993 20:19:21 GMT
From: dog@xdev.sunspot.noao.edu (Fritz Stauffer)
Organization: Computer, Hardware and Observatory Support
Message-ID: <1993Jan12.201921.4490@nmsu.edu>
Sender: usenet@nmsu.edu

I am porting pdtar to vxWorks.  It works on local disk
systems just fine.  Now, I am writing the remote transfer
stuff.  I spawn a task which creates a pipe to
replace the tar file descriptor.  The spawned task
runs rcmd to 'dd' on a unix host for the remote I/O.
There are two problems.  

1) writing to a vxWorks pipe returns an ERROR if the pipe is full.
Is there a way to block I/O when the pipe is full, or do I need to use
message queues?  

2) writing large files on the vxWorks target to the socket to output 
on the unix host uses all of the memory up and crashes.  This is 
because the socket write buffers data in memory.  This is okay for 
small tar files, but fails on large tar files.  Is there a way to 
wait for the socket buffers to flush, or to get a socket status as 
to how much buffer is left, or any other feedback?

Thanks for any ideas.

Fritz Stauffer, Sac Peak Observatory

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

Newsgroups: comp.os.vxworks
Subject: Re: vxWorks Sockets and Pipes
Date: 12 Jan 93 23:27:53 GMT
From: hwajin@pogo.iphasew.com (Hwa-Jin Bae)
Organization: Interphase West, Santa Clara, CA
Message-ID: <HWAJIN.93Jan12152753@pogo.iphasew.com>
References: <1993Jan12.201921.4490@nmsu.edu>
Sender: hwajin@iphasew.com (Hwa-Jin Bae)

>>>>> On 12 Jan 93 20:19:21 GMT, dog@xdev.sunspot.noao.edu (Fritz Stauffer) said:

Fritz> 1) writing to a vxWorks pipe returns an ERROR if the pipe is full.
Fritz> Is there a way to block I/O when the pipe is full, or do I need to use
Fritz> message queues?  

pipe in 5.0 uses message queues, and write() should block if called from
non-interrupt level code.  in earlier versions, pipe used ring buffers
and write() polled until ring space became available if called from
non-interrupt level code. if you prefer, you can just use ring buffers
(ringLib) yourself, and have finer control over what gets done.

Fritz> 2) writing large files on the vxWorks target to the socket to output 
Fritz> on the unix host uses all of the memory up and crashes.  This is 
Fritz> because the socket write buffers data in memory.  This is okay for 
Fritz> small tar files, but fails on large tar files.  Is there a way to 
Fritz> wait for the socket buffers to flush, or to get a socket status as 
Fritz> to how much buffer is left, or any other feedback?

socket level buffers are adjustable with setsockopt() -- SO_SNDBUF,
SO_RCVBUF.  by default TCP uses 4K on each side and UDP uses 2K on
send side and 4K in recv side.  you can retrieve the current limit by
using getsockopt().  when these high water marks are reached socket
code blocks until more space become available. inetstatShow() displays
output similar to UNIX command 'netstat -a', from which you should be
able to tell various socket level queue length at the time.

hwajin
- --
hjb@netcom.com (home)
hwajin@iphasew.com (work)
- -- 
hjb@netcom.com (home)
hwajin@iphasew.com (work)

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

Newsgroups: comp.os.vxworks,comp.sys.sgi
Subject: Re: sgi CC v3.1 & VxGDB incompatible
Date: 13 Jan 93 00:05:56 GMT
From: davea@quasar.mti.sgi.com (David B.Anderson)
Organization: Silicon Graphics, Inc.  Mountain View, CA
Message-ID: <uq4di0g@sgi.sgi.com>
Sender: davea@quasar.mti.sgi.com

In article <1993Jan12.101638.901@nrlvx1.nrl.navy.mil> dyer@nrlvx1.nrl.navy.mil (Doug Dyer) writes:
>Hi folks,
>
>	I am using an SGI indigo r3000 as a vxworks host
>(Iris 4D1-4.1) with cc (v3.10)  and VxGDB to debug software (v1.1).  
>The following problems occur when I load a file into the debugger:
>
>if the source code has a "struct" in it :
>	unknown symbol type 1a 
>if the source code has a "union" in it:
>	unknown symbol type 1b

Let me make a guess: those numbers are hex and are the st* value from
the symbol table.  0x1a === 26

The sgi-generated symbol tables have 3 new values as compared with
those from pre-merger-MIPS & DEC:

From /usr/include/symconst.h:
#ifdef __sgi
#define stStruct        26      /* begin Struct kind of stBlock */
#define stUnion         27      /* begin Union kind of stBlock */
#define stEnum          28      /* begin Enum  kind of stBlock */
#endif

These are to be treated just like an stBlock except that they are
specific and specify the *type* of the block.

Anywhere in GDB it tests for stBlock, simply look for any of
	stBlock stStruct stUnion stEnum
(though of course those new ones only apply to data, not code blocks,
you need not worry about that since the new ones never appear on
code blocks).

You may find that this information is of use to gdb.

Hope this helps.  This answer *is* just a guess....
[ David B. Anderson             (415)390-4263             davea@sgi.com ]

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

Newsgroups: comp.os.vxworks
Subject: Re: performance of fprintf() for floating point
Date: Wed, 13 Jan 1993 09:23:33 GMT
From: muts@pmcs.estec.esa.nl (Peter Mutsaers)
Organization: European Space Agency
Message-ID: <MUTS.93Jan13092422@PMCS.estec.esa.nl>
References: <1993Jan11.211242.16776@ncar.ucar.edu>
Sender: news@wm.estec.esa.nl

>>On Mon, 11 Jan 1993 21:12:42 GMT, vanandel@rsf.atd.ucar.edu (Joe Van Andel) said:

  Joe> I am having a performance problem with fprintf().  I have an
  Joe> application that

We have exactly the same problem on a different CPU board. I thought I
might have done something stupid while reconfiguring the kernel and
recompiling but it seems it is a common problem (?). Please post a
useful response to the net. Thanks,
- --
_________________________________________________________________________
Peter Mutsaers.         |================================================ 
muts@pmcs.estec.esa.nl  |        Quod licet bovi, non licet Jovi

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

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

From harvey@cse.lbl.gov  Wed Jan 13 10:23:44 1993
From: harvey@cse.lbl.gov (Everett Harvey)
Date: Wed Jan 13 10:23:53 PST 1993
Subject: exploder services
The VxWorks Mail Exploder				11/17/92
-------------------------
This is a user group mailing list for VxWorks related topics.
Submit articles to vxwexplo@lbl.gov for distribution to the memebers.
Send subscription requests and withdrawals to vxwexplo-request@lbl.gov .
Some installations maintain their own sub-list which means we can send just
one message to your site, which is then internally exploded.

There is both an immediate list which gets about 2-5 posts per day and 
a daily digest list which accumulates 24-hours of messages at 4 AM Pacific Time.

The VxWorks Exploder and the comp.os.vxworks newsgroup are
cross-connected such that information posted to either shows up on both.

We also maintain Message Archives which go back a year or so grouped by the
month. These can be accessed via anonymous ftp at vxw-ftp.lbl.gov in the directory "pub". Use your logon name as a password. For example:

		%ftp vxw-ftp.lbl.gov
		% Name: anonymous
		% Password: yourname
		ftp> cd pub
		ftp> dir
		ftp> get archive9108
		
###

From vxworks@mars.psf.ge.com  Wed Jan 13 13:49:41 1993
From: vxworks@mars.psf.ge.com (vx_works)
Date: Wed Jan 13 13:49:52 PST 1993
Subject: REPOST: MVME14x Diagnostics coexisting with VADSWorks
I unfortunately experienced trouble receiving the exploder since I first
posted this, so if anyone out there replied via the exploder, please bear
with me and try again:

We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the
VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard
power-on-diagnostics. We have a project requirement to run some level of
board readiness tests without resorting to swapping the Motorola PROMS back
in. I've got a call in to Motorola to see about the availability of their
diagnostic source code, but I'm  wondering how other folks have dealt with
this problem. Has anyone developed downloadable diagnostic or readiness tests
(or adapted Motorola's code) for this situation?
  
  
John E. Thier
GE Defense Systems Dept.
Pittsfield MA
vxworks_list@mars.psf.ge.com

From talarian!brianq@uunet.uu.net  Wed Jan 13 15:25:43 1993
From: talarian!brianq@uunet.uu.net (Brian Quigley)
Date: Wed Jan 13 15:25:57 PST 1993
Subject: Re: REPOST: MVME14x Diagnostics coexisting with VADSWorks
> We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the
> VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard
> power-on-diagnostics. We have a project requirement to run some level of
> board readiness tests without resorting to swapping the Motorola PROMS back
> in. I've got a call in to Motorola to see about the availability of their
> diagnostic source code, but I'm  wondering how other folks have dealt with
> this problem. Has anyone developed downloadable diagnostic or readiness tests
> (or adapted Motorola's code) for this situation?
>
> John E. Thier
> vxworks_list@mars.psf.ge.com

Sorry if this got through to you already.  I know it doesn't directly
answer you question but hopefully it will help.

---

I faced a similar problem when using a Force CPU30.  The solution 
recommended to us be Force was to use a different boot setting for
our board. This setting told the board to load VMEPROM (Force's 
diagnostic ROM software) which executed the self-start diagnostics
and then jumped to a predefined location in memory to begin executing
a user-defined program.  This user-defined programs was simply a 
jump to the starting address of VxWorks (defined as ROM_BASE_ADRS if
I remember correctly).

The good part was we didn't have to write any selftest software and
we could (by changing the boot setting) run the VMEPROM by itself.

However, we had to modify the kernel (very minor) which means we
had to blast new EPROMs.  Also, the size of our EPROM's needed to
essentially double to hold both VMEPROM and VxWorks.

I don't have access to a 147 manual but a 167 installtion manual alludes
to a similar capability via something called ROMboot.  

I hope this helps.  Let me know if you have questions.

---

Brian Quigley         |  brianq@talarian.com
Talarian Corporation  |  (415)965-8050

From ceco!kevinr@uunet.uu.net  Wed Jan 13 19:08:35 1993
From: ceco!kevinr@uunet.uu.net (Kevin R. Rumbaugh)
Date: Wed Jan 13 19:10:31 PST 1993
Subject: Re: REPOST: MVME14x Diagnostics coexisting with VADSWorks
>We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the
>VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard
>power-on-diagnostics. We have a project requirement to run some level of
>board readiness tests without resorting to swapping the Motorola PROMS back
>in. I've got a call in to Motorola to see about the availability of their
>diagnostic source code, but I'm  wondering how other folks have dealt with
>this problem. Has anyone developed downloadable diagnostic or readiness tests
>(or adapted Motorola's code) for this situation?
>  
>  
>John E. Thier
>GE Defense Systems Dept.
>Pittsfield MA
>vxworks_list@mars.psf.ge.com
>
>

  Can't speak for VADSWorks, but we have had in the past both the Motorla
  EPROMs and the VxWorks EPROMS on the board at the same time.  You 
  have to change the start address for the bootrom code in the config/mv147
  directory, and when the board boots the Motorla code gets control
  and you have it jump to the VxWorks code.  If you think it might
  help, send me mail and I'll look at more specifics for you.
--

                     Kevin Rumbaugh  'The Marauder'
		      --- Commonwealth Edison ---
E-MAIL    : kevinr@ceco.com  OR   uunet!ceco!kevinr
AT&T      : (312) 294-8894        FAX	: (312) 294-4233
USMAIL    : Information Systems; Room 1139; 125 S. Clark; Chicago IL 60603

From daemon@vxw.ee.lbl.gov  Thu Jan 14 04:00:46 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 14 04:00:58 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 14 04:00:36 PST 1993

        Subject: Re: performance of fprintf() for floating point
        Subject: VADSWorks & sockets
        Subject: VME Bus Errors

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

Newsgroups: comp.os.vxworks
Subject: Re: performance of fprintf() for floating point
Date: Wed, 13 Jan 1993 13:12:30 GMT
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Organization: National Center for Atmospheric Research
Message-ID: <1993Jan13.131230.16404@ncar.ucar.edu>
References: <1993Jan11.211242.16776@ncar.ucar.edu> <MUTS.93Jan13092422@PMCS.estec.esa.nl>
Sender: news@ncar.ucar.edu (USENET Maintenance)

The solution seems to be to use "ftoa()", which someone was kind enough to pass
on:
/* 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;
}

- -- 
	Joe VanAndel  		Internet:vanandel@ncar.ucar.edu
	National Center for Atmospheric Research

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

Newsgroups: comp.os.vxworks
Subject: VADSWorks & sockets
Date: 13 Jan 93 22:03:32 GMT
From: yvesb@melair.UUCP (Yves Boudeault)
Organization: Lockheed Canada Inc., Ottawa, Canada
Message-ID: <1553@melair.UUCP>

Hi,
   
   I am working on a multiprocessor using VADSWorks and a number of
   MVME-167.  I know just enough about VxWorks and VADSWorks to be 
   dangerous, so be forewarned:

   It is my understanding that VADSWorks sets up a roud-robin scheduling.
   When I send to my socket, the data gets copied into the socket send buffer
   but the data does not appear to be sent to the receiver until a 
   context switch occurs.  This does not look like a very interesting
   behaviour.  Does anyone know if this is, in fact, how VADS works ?

   Yves Boudreault (yvesb@minas.lockheed.on.ca)

- -- 
     Yves Boudreault           If I express opinions, they have to be mine.
 yvesb@melair.lockheed.on.ca

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

Newsgroups: comp.os.vxworks
Subject: VME Bus Errors
Date: Thu, 14 Jan 1993 06:26:26 GMT
From: binkley@xavier.dfrf.nasa.gov (Rob Binkley)
Organization: NASA Dryden FRF, Edwards, CA
Keywords: Bus error  Interrupts
Message-ID: <1993Jan14.062626.16722@news.dfrf.nasa.gov>
Reply-To: binkley@xavier.dfrf.nasa.gov
Sender: news@news.dfrf.nasa.gov (Usenet news)

I am having a (very basic) problem with vxWorks.
I am trying to intercept VME bus errors and recover
gracefully in my program.  I am looking for some
possible failures of IO boards in the VME crate.

I have looked at vxMemProbe() ...won't do.  I have to
look for dynamic (run time) board failures.

The basic premise I am trying to implement:

Use  intConnect  to install my bus error handler.
That handler simply does a  longjmp  to a previous
setjmp.  If a bus error ever gets called, it works,
but appears to hang the vxWorks OS on exit.

The code is attached to the end of this letter.

Hardware: Force CPU-40/01
	  16 Meg RAM

Software: vxWorks 5.0.2b-68040 Release-1

Thanks for any help...I'm sure I'm missing something
very simple...

An execution fragment:
================================================
Trying 130.134.XXX.XXX ...
Connected to sabretooth.dfrf.nasa.gov.
Escape character is '^]'.
 
- -> cd "/home/xavier/binkley/VxWorks/CIU/Chris"
value = 0 = 0x0
- -> ld < ppp.o
value = 0 = 0x0
- -> init
OK: Bus error handler installed.
 
IDIS board # 0 found and initalized
IDIS board # 1 NOT INSTALLED!  Setjmp ststus: 8
value = 0 = 0x0
- ->

================================================
the system is dead...must be rebooted...

the compile line:
================================================
cc68k -g -c -DCPU=MC68040 -Wall -I/usr/vw/h -I/usr/vw/sun4.68k/lib/gcc-include -I/usr/vw/config/frc40 -I/usr/vw/h/drv ppp.c
================================================

The code:
================================================
#include	<vxWorks.h>
#include	<stdioLib.h>
#include	<ioLib.h>
#include	<types.h>
#include        <setjmp.h>

#include        <intLib.h>
#include        <68k/iv.h>      /* vxWorks 68k-family interrupt vector header */
#include        <frc40.h>       /* vxWorks Force CPU-40 header */
#include        <drv/fga002.h>  /* vxWorks FGA-002 gate array header */

jmp_buf	busErrorEnv;

STATUS init()
{
  void	busErrorIRQ();
  int	status;
  short *p;
  int	i;

  if(intConnect ((void *)IV_BUS_ERROR, busErrorIRQ, (int)IV_BUS_ERROR)== ERROR) {
    printf("ERROR: Unable to install busErrorIRQ() interupt handler.\n");
    printf("       Exiting ciuRT() in function: busErrorHandlerInstall().\n\n");
    exit(-1);
  }
  else printf("OK: Bus error handler installed.\n\n");

  p = (short *) 0xfcff0608;

  for (i=0; i < 2; i++, p+=8) {
    if ((status = setjmp(busErrorEnv)) == 0) {
      *p = 0x00e0;
      printf("IDIS board # %d found and initalized\n",i);
    }
    else {
      printf("IDIS board # %d NOT INSTALLED!  Setjmp ststus: %d\n",i,status);
    }
  }
  return(0);

}

void busErrorIRQ(int callingIntVector)
{
  longjmp(busErrorEnv, callingIntVector);
}

- -- 
- -----------------------------------------------------------------------------
| Robert L. Binkley, EIT    | INTERNET: binkley@xavier.dfrf.nasa.gov        |
| NASA Dryden FRF           |  ADDRESS: 130.134.144.2                       |
| PO Box 273  MS: B4840A    |                                               |
| Edwards, CA  93523-5000   |                                               |
| fone: 805-258-3776        |                                               |
|  fax: 805-258-3567        |                                               |
|---------------------------------------------------------------------------|
|  barf  [ba:rf]  2.  "He suggested using FORTRAN, and everybody barfed."   |
|                                                                           |
|    - From The Shogakukan DICTIONARY OF NEW ENGLISH (Second edition)       |
- -----------------------------------------------------------------------------

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

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

From fjr@rayssd.ssd.ray.com  Thu Jan 14 08:28:59 1993
From: Roeber <fjr@ssd.ray.com>
Date: Thu Jan 14 08:29:08 PST 1993
Subject: Re:  VADSWorks & sockets
Yves Boudeault writes:

>  Organization: Lockheed Canada Inc., Ottawa, Canada
>  Message-ID: <1553@melair.UUCP>
>  
>  Hi,
>     
>     I am working on a multiprocessor using VADSWorks and a number of
>     MVME-167.  I know just enough about VxWorks and VADSWorks to be 
>     dangerous, so be forewarned:
>  
>     It is my understanding that VADSWorks sets up a roud-robin scheduling.
>     When I send to my socket, the data gets copied into the socket send buffer
>     but the data does not appear to be sent to the receiver until a 
>     context switch occurs.  This does not look like a very interesting
>     behaviour.  Does anyone know if this is, in fact, how VADS works ?

First, the fact that you are using VADSWorks vs VxWorks makes a bit of a
difference here.  I assume you are using Ada tasking.  This means that
there is Ada tasking running on top of the standard VxWorks scheduler
(actually, one scheduler handles this).  The thing is that there are some
configurable parameters that affect how the Ada scheduling works.  You can
select time sliced (round robin) tasking as an option.  Realize, though, that
both VADSWorks and VxWorks basically use preemptive scheduling.  Thus, if
your two tasks have different priorities, the higher priority task will run
when it has something to do; preempting any lower priority task that is
running.  Thus, if you send a message from a low priority task to a high
priority one through a socket, the high priority one will run  immediately.
If the receiving task is the same or lower priority, then it won't run until
a context switch occurs.  I expect that you haven't adjusted the task
priorities (using the Ada pragma priority).  One last thing to note, 
VADSWorks priorities are consistent with the Ada LRM which specifies that
higher values are higher priorities.  This is opposite the normal VxWorks
model which has lower numbers as higher priorities.  Thus, depending on how
you are setting your priorities, you could maybe be getting a different
result than you expect.
  There are other potential issues if you are talking about using sockets
across the backplane that depend on how you have the backplane driver
configured.  The driver supports polled or interrupt driven operation.  It
should be set to interrupt driven operation for MVME167s though so I don't
really think that what you are seeing is the result of any backplane driver
issues.   Good luck.   Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|

From fjr@rayssd.ssd.ray.com  Thu Jan 14 08:29:58 1993
From: Roeber <fjr@ssd.ray.com>
Date: Thu Jan 14 08:30:09 PST 1993
Subject: Re:  VME Bus Errors
Rob Binkley writes:

>  I am having a (very basic) problem with vxWorks.
>  I am trying to intercept VME bus errors and recover
>  gracefully in my program.  I am looking for some
>  possible failures of IO boards in the VME crate.
>  
>  I have looked at vxMemProbe() ...won't do.  I have to
>  look for dynamic (run time) board failures.
>  
>  The basic premise I am trying to implement:
>  
>  Use  intConnect  to install my bus error handler.
>  That handler simply does a  longjmp  to a previous
>  setjmp.  If a bus error ever gets called, it works,
>  but appears to hang the vxWorks OS on exit.

The problem is with the longjmp.  When you receive a bus error you are
running in interrupt context.  The "task" which originally did the setjmp
is running in a very different context; different stack, different priority
level...  I have written my own bus error handlers before and it is basically
like any other interrupt handler for a device driver.  You can perform
functions at interrupt level but if you need to do something at task level,
you should use some mechanism like a binary semaphore to "signal" the task
that the event occured.  You can't longjmp.  The other thing I would suggest
is that you get the original interrupt vector for the bus error and call
that handler too after doing any functions in your handler.  For bus errors
there are things like automatic cycle retries done by the original VxWorks
handler that you don't want to disrupt.   Good luck.    Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|

From kimraj@cps070.lds.loral.com  Thu Jan 14 13:03:25 1993
From: kimraj@cps070.lds.loral.com (Ron Kimraj)
Date: Thu Jan 14 13:03:35 PST 1993
Subject: Dangling Socket Descriptor

How does a TCP/IP server knows to stop listening on
a client, if the client aborted without explicitly
removing the socket descriptor by closing it via close()?

(The SO_KEEPALIVE Option is set on both the Server and
Client tasks).

Thank you.

From @amdahl.uts.amdahl.com,@juts.ccc.amdahl.com:bxs20@da.amdahl.com  Thu Jan 14 13:41:30 1993
From: bxs20@da.amdahl.com (Benny Schnaider)
Date: Thu Jan 14 13:41:40 PST 1993
Subject: MVME167 VMEbus transfer rate

I am trying to compare the performance of the MVME167/33Mhz
with MVME135/16.7Mhz. One of the surprising result is a slower
VMEbus access for the MVME167. I am getting 10%-20% slower
transfer rate from/to MVME167 to/from the VMEbus relative to
the MVME135. (I am accessing the same board in both cases).

Are there any configuration registers on the MVME167 that can
affect the transfer rate on the VMEbus. In other words, what
am I doing wrong ?

Thanks,
Benny.

From daemon@vxw.ee.lbl.gov  Fri Jan 15 04:00:33 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 15 04:00:44 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 15 04:00:21 PST 1993

        Subject: Re: VME Bus Errors
        Subject: Re: Dangling Socket Descriptor
        Subject: Memory management debug aids...

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

Newsgroups: comp.os.vxworks
Subject: Re: VME Bus Errors
Date: 14 Jan 93 20:09:40 GMT
From: georg@sgl.ists.ca (Georg Feil)
Organization: Institute for Space and Terrestrial Science
Keywords: Bus error  Interrupts
Message-ID: <georg.727042180@sgl.ists.ca>
References: <1993Jan14.062626.16722@news.dfrf.nasa.gov>
Sender: news@ists.ists.ca (News Subsystem)

binkley@xavier.dfrf.nasa.gov (Rob Binkley) writes:
>I am having a (very basic) problem with vxWorks.
>I am trying to intercept VME bus errors and recover
>gracefully in my program.

Your problem may have to do with the DF bit of the special status word.
Unless it is explicitly cleared, the bus cycle is retried and will just
fail again and again in an endless loop.
Here is an example routine which shows how you might return from the
bus-error handler to avoid hanging. This is very similar to how vxMemProbe()
works. The example is written for 68020 (VxWorks 4.0.2), so I hope it's the
same on 68040.

Georg.

- -----------------------------------------------------------------------
int buserr;

void buserr_isr(int dumparm)
/*
 * Just count the occurrence of bus errors.
 *
 * This is not a conventional VxWorks isr: no registers are saved before entry. 
 * We first increment a bus error indicator 'buserr'. Then we clear the
 * DF bit (bit 8) of the internal special status word saved by the bus error
 * exception. This should appear at sp+0x0e, counting 0x0a for its offset
 * into the exception stack frame and 0x04 for the link a6 instruction 
 * that starts all C functions. The DF bit controls whether the data access
 * is retried following the return from exception. We do not want to retry
 * the access, otherwise everything would hang permanently.
 *
 * Many machine and compiler-dependent assumptions are being made here.
 * In particular we assume that the code generated for this subroutine does 
 * not modify any registers and that the stack format is as described.
 * We also manufacture our own exit sequence, using "unlk a6" and "rte".
 * This is assumed to remain correct.
 *
 * Any code added to this routine should ensure it first saves any registers it
 * uses.
 */
{
   buserr++;
   asm("andw #0xfeff,sp@(0x0e)");
   asm("unlk a6 ; rte");
}

void board_scan(void)
/* Scan for presence of hardware */
{
   FUNCPTR old_isr;
   static int dummy;     /* static to prevent optimizer from removing */

   old_isr=intVecGet(IV_BUS_ERROR);
   /* Make direct connection of buserr_isr to bus error exception vector. */
   intVecSet(IV_BUS_ERROR,(FUNCPTR)buserr_isr);

   buserr=0;

   /* test access to DRD board */
   dummy=M_B(DRDBASE+1);     
   if (buserr==0)  {
      printf("DRD board present.\n");
   }
   else  {
      printf("*** DRD board not present. Will not access.\n");
   }

   intVecSet(IV_BUS_ERROR,old_isr);
}
- -- 
Georg Feil                                 Internet: georg@sgl.ists.ca
Space Geodynamics Laboratory
ISTS, 2700 Steeles Ave West                   Phone: (416) 665-5458
Toronto, Ontario  CANADA                        Fax: (416) 660-1422

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

Newsgroups: comp.os.vxworks
Subject: Re: Dangling Socket Descriptor
Date: Fri, 15 Jan 1993 00:19:57 GMT
From: rypma@waterloo.hp.com (Ted Rypma)
Organization: HP Panacom Div Waterloo ON Canada
Message-ID: <C0vCx9.8yA@waterloo.hp.com>
References: <9301142103.AA14190@cps070.lds.loral.com>
Sender: news@waterloo.hp.com (NetNews)

Ron Kimraj (kimraj@cps070.lds.loral.com) wrote:
: 
: How does a TCP/IP server knows to stop listening on
: a client, if the client aborted without explicitly
: removing the socket descriptor by closing it via close()?
: 
: (The SO_KEEPALIVE Option is set on both the Server and
: Client tasks).

Keepalives won't do a darned thing.. just prove to each side that the
connection is still alive at the TCP protocol level. You need an
application-level handshake (which is the right way to implement this
kind of thing anyway). Keepalives ONLY speed recovery if one side
crashes and then comes back up - the keepalive frame is answered with
a TCP reset frame.  Otherwise you get to have your coffee grow cold
while you wait.

Your particular scenario won't even time out then because VxWorks "owns"
the socket descriptor (they're all global, you know) and the connection
remains very much alive.

Ted Rypma
HP Panacom Division

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

Newsgroups: comp.os.vxworks
Subject: Memory management debug aids...
Date: 15 Jan 93 00:59:23 GMT
From: sjk@strl.labs.tek.com (Steven King)
Organization: Software Technology Research Lab, Tektronix, Inc.
Message-ID: <5073@crl.LABS.TEK.COM>
Followup-To: comp.os.vxworks
Reply-To: sjk@strl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

I'm looking for a tool that can help track down a memory overwrite under
VxWorks.  (Aren't we all?)  This one is especially tough, since it happens
in a reuseable C++ library that is rather complex and would be hard to
"instrument" with printf(), memShow() or memPartShow().

A tool like Purify would be optimal, since I would like a tool to find the
offending line of code and how it's offensive.  Since Purify under VxWorks
is not do-able, I was hoping that a fellow VxWorks user might have a ready-made
solution to share.  Something that monitors or verifies malloc'ed segments of
memory is what I need.

Has anyone used Stethoscope in this manner?  Is it possible?

If not, I'll just whip up a little monitor to watch the memory partition
and report modifications from time-to-time.

Thanks!

Steven (sjk@strl.labs.tek.com)

"Sometimes if you have a cappuccino and then try again it will work OK."
(Dr. Brian Reid)  "Sometimes one cappuccino isn't enough." (Marcus Ranum)
"A double vanilla latte always works."  (Me)

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

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

From visicom!VisiCom.COM!trest@nosc.mil  Fri Jan 15 08:59:36 1993
From: Mike Trest <trest@visicom.com>
Date: Fri Jan 15 08:59:49 PST 1993
Subject: Re: MVME167 VMEbus transfer rate
 Benny Schnaider writes:
 
> I am trying to compare the performance of the MVME167/33Mhz
> with MVME135/16.7Mhz. One of the surprising result is a slower
> VMEbus access for the MVME167. I am getting 10%-20% slower
> transfer rate from/to MVME167 to/from the VMEbus relative to
> the MVME135. (I am accessing the same board in both cases).

I have seen this happen with 68040 boards in general.  I have
not observed the bus activity of the MVME167 to confirm.

The problem may be related to cache-line-filling.  If, for
example, you are reading one-byte-cycles followed by one-byte-writes
and the addresses of those bytes are somewhat spread-out,
and you have cache enabled covering the VME address space
the MMU inside the 68040 is actually reading 4 words to fill 
a cache-line rather than one byte.

To know for sure, we need to know a little more about the addresses
of the bus transfer activity the size of the read/write.  A
VME bus analizer like the NISSO or VMETRO can tell you if this
is the real problem.

..mike..

 
====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From interf!atlas!io!vhopson@uunet.uu.net  Fri Jan 15 12:50:27 1993
From: interf!atlas!io!vhopson@uunet.uu.net (Vince Hopson)
Date: Fri Jan 15 12:50:37 PST 1993
Subject: Exabyte 8500 SCSI drives

Currently, I need to purchase an intelligent VME based SCSI card that is
compatible with vxWorks (i.e. has drivers), and also compatible with the
Exabyte tape drives (5GByte tapes in 8mm format).  I would appreciate any
clues, anecdotes in implementation, or other help that anyone can offer
on either or both topics.  Please send your responses to:

	vhopson@interf.com

Thanks in advance for all replies!!

		...vince

Vincent M. Hopson	vhopson@interf.com
Interferometrics Inc.
8150 Leesburg Pike
Vienna, VA		voice: (202) 653-0945

From fjr@rayssd.ssd.ray.com  Fri Jan 15 13:39:44 1993
From: Roeber <fjr@ssd.ray.com>
Date: Fri Jan 15 13:39:53 PST 1993
Subject: Re:   Memory management debug aids...
Steven King from  Tektronix writes:

>  I'm looking for a tool that can help track down a memory overwrite under
>  VxWorks.  (Aren't we all?)  This one is especially tough, since it happens
>  in a reuseable C++ library that is rather complex and would be hard to
>  "instrument" with printf(), memShow() or memPartShow().
>  
>  A tool like Purify would be optimal, since I would like a tool to find the
>  offending line of code and how it's offensive.  Since Purify under VxWorks
>  is not do-able, I was hoping that a fellow VxWorks user might have a ready-made
>  solution to share.  Something that monitors or verifies malloc'ed segments of
>  memory is what I need.

Steve,  I am a little surprised, the "best" solution that we have found to
this type of problem is to use a HW emulator like you guys build to track
such problems.  Of course the darned things are real expensive and a little
hard to connect up to boards but they are the optimum solution.
  
>  Has anyone used Stethoscope in this manner?  Is it possible?

Stethoscope can track the location too periodically.  I assume Stan
Schnieder who wrote the tool will respond.  Of course it is pretty hard
to get from the periodic point where the value is corrupted to the exact
code that did the corruption.

>  
>  If not, I'll just whip up a little monitor to watch the memory partition
>  and report modifications from time-to-time.

Good luck.   Fred

    _______________________________________________________
   |  Fred J Roeber,  Raytheon Submarine Signal Division   |
   |  1847 West Main Road,  Mail Stop 188                  |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4205)   |
   |                                                       |
   |                   fjr@ssd.ray.com                     |
   |_______________________________________________________|

From brian@wrs.com  Fri Jan 15 15:04:03 1993
From: Brian Lazara <brian@wrs.com>
Date: Fri Jan 15 15:04:13 PST 1993
Subject: Re:  VADSWorks & sockets

Yves Boudeault and Fred Roeber write:

>Yves Boudeault writes:
>
>>  Organization: Lockheed Canada Inc., Ottawa, Canada
>>  Message-ID: <1553@melair.UUCP>
>>  
>>  Hi,
>>     
>>     I am working on a multiprocessor using VADSWorks and a number of
>>     MVME-167.  I know just enough about VxWorks and VADSWorks to be 
>>     dangerous, so be forewarned:
>>  
>>     It is my understanding that VADSWorks sets up a roud-robin scheduling.
>>     When I send to my socket, the data gets copied into the socket send buffer
>>     but the data does not appear to be sent to the receiver until a 
>>     context switch occurs.  This does not look like a very interesting
>>     behaviour.  Does anyone know if this is, in fact, how VADS works ?
>
>First, the fact that you are using VADSWorks vs VxWorks makes a bit of a
>difference here.  I assume you are using Ada tasking.  This means that
>there is Ada tasking running on top of the standard VxWorks scheduler
>(actually, one scheduler handles this).  The thing is that there are some
>configurable parameters that affect how the Ada scheduling works.  You can
>select time sliced (round robin) tasking as an option.  Realize, though, that
>both VADSWorks and VxWorks basically use preemptive scheduling.  Thus, if
>your two tasks have different priorities, the higher priority task will run
>when it has something to do; preempting any lower priority task that is
>running.  Thus, if you send a message from a low priority task to a high
>priority one through a socket, the high priority one will run  immediately.
>If the receiving task is the same or lower priority, then it won't run until
>a context switch occurs.  I expect that you haven't adjusted the task
>priorities (using the Ada pragma priority).  One last thing to note, 
>VADSWorks priorities are consistent with the Ada LRM which specifies that
>higher values are higher priorities.  This is opposite the normal VxWorks
>model which has lower numbers as higher priorities.  Thus, depending on how
>you are setting your priorities, you could maybe be getting a different
>result than you expect.
>  There are other potential issues if you are talking about using sockets
>across the backplane that depend on how you have the backplane driver
>configured.  The driver supports polled or interrupt driven operation.  It
>should be set to interrupt driven operation for MVME167s though so I don't
>really think that what you are seeing is the result of any backplane driver
>issues.   Good luck.   Fred

It should be noted that the default is preemptive scheduling. To start
time slicing, kernelTimeSlice needs to be called. This will still be
preemptive for differrent priority tasks, but ready tasks of equal priority
will be put on a round-robin scheduling. Check out the Programmers Guide
for more detail on this.

-Brian

From daemon@vxw.ee.lbl.gov  Sat Jan 16 04:00:48 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 16 04:00:58 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 16 04:00:33 PST 1993

        Subject: Mysterious task crashes
        Subject: Re: Memory management debug aids...

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

Newsgroups: comp.os.vxworks
Subject: Mysterious task crashes
Date: 15 Jan 93 18:47:13 GMT
From: bard@cutter.ssd.loral.com (J H Woodyatt)
Organization: Abiogenesis 4 Less
Message-ID: <1993Jan15.184713.28368@wdl.loral.com>
Reply-To: bard@cutter.ssd.loral.com
Sender: news@wdl.loral.com

I had this problem under VxWorks 4.0.2, and I hoped it would go away
with the switch to VxWorks 5.0.2b, but it still seems to be plaguing
me, so I'm soliciting advice from the net.  Hopefully, somebody
somewhere has seen something like this before and can offer suggested
explanations for the behavior I'm observing other than the ones I've
already thought up.

At seemingly random intervals, and usually shortly after powerup, I
get an illegal instruction trap.  The task that dies varies, sometimes
it's tNetTask, sometimes it's tPortmapd -- I've even seen tRootTask
die in this fashion.

Under VxWorks 4.0.2, it was really funky, because the `idle' task was
usually the one to give up the ghost, and with that one it was fairly
easy to check that the `idle' function hadn't been clobbered in
memory.

The consistent part is that the program counter always comes up at
address 0000006.  Here's a sample message:

Illegal Instruction
Program Counter: 0x00000006
Status Register: 0x2300
Task: 0xb2b37c "tNetTask"

We're using Tadpole TP-32V SBC's.  We use them in a twenty-slot card
cage with a bunch of other cards used to control a tape drive, four HP
system power supplies, a chart recorder and do other assorted
weirdness.  My superstitions tell me to aim at power supply problems.

I need a clue to know where to start troubleshooting this one.  Can
anyone offer a helpful suggestion?

- -- 
+---------------------------+  I wasn't expecting it.  When Danny Elfman
| J H Woodyatt              |  sang the words, `goo goo ga choo,' Sunday
| bard@cutter.ssd.loral.com |  night, I cracked.  Some horrors are too
+---------------------------+  large to shade out.

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

Newsgroups: comp.os.vxworks
Subject: Re: Memory management debug aids...
Date: Fri, 15 Jan 93 21:11:39 GMT
From: pardo@alta.Stanford.EDU (Gerardo Pardo-Castellote)
Organization: stanford
Message-ID: <1993Jan15.211139.12325@leland.Stanford.EDU>
References:  <5073@crl.LABS.TEK.COM>
Sender: pardo@alta (Gerardo Pardo-Castellote)

In article <5073@crl.LABS.TEK.COM>, sjk@strl.labs.tek.com (Steven King) writes:
|> I'm looking for a tool that can help track down a memory overwrite under
|> VxWorks.  (Aren't we all?)  This one is especially tough, since it happens
|> in a reuseable C++ library that is rather complex and would be hard to
|> "instrument" with printf(), memShow() or memPartShow().
|> 
|> A tool like Purify would be optimal, since I would like a tool to find the
|> offending line of code and how it's offensive.  Since Purify under VxWorks
|> is not do-able, I was hoping that a fellow VxWorks user might have a ready-made
|> solution to share.  Something that monitors or verifies malloc'ed segments of
|> memory is what I need.
|> 
|> Has anyone used Stethoscope in this manner?  Is it possible?
|> If not, I'll just whip up a little monitor to watch the memory partition
|> and report modifications from time-to-time.
|> 
I don't think you can use Stethoscope for that purpose. However Stethoscope comes
with a tool called "heapCheck" that does something very close to what you want. It 
replaces malloc() and free() by its own calls and does a consistency check on the 
whole heap every time malloc() or free() are called. Upon hitting the error it will 
print a stack trace of the offending task. In addition it also keeps a count on the 
number of times either function was called and lets you set e break point at any 
count. If your problem is repeateble this lets you break on the last call before the 
error ocurred and step through to watch the error happen. I have used it several 
times and it is very effective provided (as I said) that the problem is repeateble.

I don't know more about it. You will have to contact RTI (info@rti.com) for more 
details.

|> Thanks!
|> 
|> Steven (sjk@strl.labs.tek.com)

Gerardo.

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

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

From @amdahl.uts.amdahl.com,@juts.ccc.amdahl.com:bxs20@da.amdahl.com  Sun Jan 17 09:35:23 1993
From: bxs20@da.amdahl.com (Benny Schnaider)
Date: Sun Jan 17 09:35:33 PST 1993
Subject: MVME167 VMEbus transfer rate

> Benny Schnaider writes:
> 
>> I am trying to compare the performance of the MVME167/33Mhz
>> with MVME135/16.7Mhz. One of the surprising result is a slower
>> VMEbus access for the MVME167. I am getting 10%-20% slower
>> transfer rate from/to MVME167 to/from the VMEbus relative to
>> the MVME135. (I am accessing the same board in both cases).
>
>I have seen this happen with 68040 boards in general.  I have
>not observed the bus activity of the MVME167 to confirm.
>
>The problem may be related to cache-line-filling.  If, for
>example, you are reading one-byte-cycles followed by one-byte-writes
>and the addresses of those bytes are somewhat spread-out,
>and you have cache enabled covering the VME address space
>the MMU inside the 68040 is actually reading 4 words to fill 
>a cache-line rather than one byte.
>
>To know for sure, we need to know a little more about the addresses
>of the bus transfer activity the size of the read/write.  A
>VME bus analizer like the NISSO or VMETRO can tell you if this
>is the real problem.
>
>..mike..

Mike

I am mainly words transfer (16Bits). Data cache is Enabled, Write-Trough
mode. Enclosed is the code I was using.
I am almost sure that I tried disabling the data cache and the results
were not much different. I do not have the board to verify it.

Thanks,
Benny

#define usign16 unsigned short

VXTcopyShort(src_adrs, dst_adrs, count) /*
******************************************/
register usign16 *src_adrs;  /* source address */
register usign16 *dst_adrs;  /* Destination address */
register int      count;     /* Number of WORDS to transfer */
{
  register int i;
  for (i = 0; i < count; i++) {
    *dst_adrs++ = *src_adrs++;
  }
} /* VXTcopyShort */

From daemon@vxw.ee.lbl.gov  Mon Jan 18 04:00:37 1993
From: daemon@vxw.ee.lbl.gov
Date: Mon Jan 18 04:00:46 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Mon Jan 18 04:00:27 PST 1993

        Subject: X Client Development

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

Newsgroups: comp.os.vxworks
Subject: X Client Development
Date: 17 Jan 1993 23:25:10 GMT
From: ah442@cleveland.Freenet.Edu (Erik C. Orange)
Organization: Case Western Reserve University, Cleveland, Ohio (USA)
Message-ID: <1jcpsmINNdpq@usenet.INS.CWRU.Edu>

I'm curious as to how X client tasks are developed under VxWorks.
Do most developers accomplish this by writing their own X/toolkit
code?

We were hoping to ease this task by using a GUI developer, but some
of these tools produce UIL code along with C code, and I haven't
seen a reference to a UIL compiler that might come with windX.
(I was hoping .UID files are portable in answer to this, but a
port attempt from SGI to DEC kinda failed).

I guess I'm just looking for some trends in X client development.

Any insight would be helpful!

Erik
- -- 
- ----------
Erik C. Orange                            FRD Industrial Automation
Computer Engineering                      Avery-Dennison Corporation
ah442@cleveland.Freenet.Edu               Concord, OH

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

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

From hebo@mbari.org  Mon Jan 18 08:47:12 1993
From: Bob Herlien <hebo@mbari.org>
Date: Mon Jan 18 08:47:20 PST 1993
Subject: Re: X Client Development
> 
> I'm curious as to how X client tasks are developed under VxWorks.
> Do most developers accomplish this by writing their own X/toolkit
> code?
> 
> We were hoping to ease this task by using a GUI developer, but some
> of these tools produce UIL code along with C code, and I haven't
> seen a reference to a UIL compiler that might come with windX.
> (I was hoping .UID files are portable in answer to this, but a
> port attempt from SGI to DEC kinda failed).
> 

The GUI builder I'm familiar with (Builder Xcessory, but I've also used 
UIM/X and I think it works the same way) use UIL as a "save" file format
and, of course, you can use this UIL to generate .UID.  However, they also
have an option to generate pure (K&R or ANSII) C code.  In that mode, UIL
is just a load/store format for the tool; your application never sees it.

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

From daemon@vxw.ee.lbl.gov  Tue Jan 19 04:00:38 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 19 04:00:50 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 19 04:00:30 PST 1993

        Subject: Re: Mysterious task crashes
        Subject: NFS Server Availability?

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

Newsgroups: comp.os.vxworks
Subject: Re: Mysterious task crashes
Date: Mon, 18 Jan 1993 16:36:43 GMT
From: markm@ee.ubc.ca (mark milligan)
Organization: University of BC, Electrical Engineering
Message-ID: <1993Jan18.163643.619@ee.ubc.ca>
References:  <1993Jan15.184713.28368@wdl.loral.com>
Sender: news@ee.ubc.ca (Usenet News)

In article <1993Jan15.184713.28368@wdl.loral.com>, bard@cutter.ssd.loral.com (J H Woodyatt) writes:
> 
> I had this problem under VxWorks 4.0.2, and I hoped it would go away
> with the switch to VxWorks 5.0.2b, but it still seems to be plaguing
> me, so I'm soliciting advice from the net.  Hopefully, somebody
> somewhere has seen something like this before and can offer suggested
> explanations for the behavior I'm observing other than the ones I've
> already thought up.
> 
> At seemingly random intervals, and usually shortly after powerup, I
> get an illegal instruction trap.  The task that dies varies, sometimes
> it's tNetTask, sometimes it's tPortmapd -- I've even seen tRootTask
> die in this fashion.
> 
> Under VxWorks 4.0.2, it was really funky, because the `idle' task was
> usually the one to give up the ghost, and with that one it was fairly
> easy to check that the `idle' function hadn't been clobbered in
> memory.
> 
> The consistent part is that the program counter always comes up at
> address 0000006.  Here's a sample message:
> 
> Illegal Instruction
> Program Counter: 0x00000006
> Status Register: 0x2300
> Task: 0xb2b37c "tNetTask"
> 
> We're using Tadpole TP-32V SBC's.  We use them in a twenty-slot card
> cage with a bunch of other cards used to control a tape drive, four HP
> system power supplies, a chart recorder and do other assorted
> weirdness.  My superstitions tell me to aim at power supply problems.
> 
> I need a clue to know where to start troubleshooting this one.  Can
> anyone offer a helpful suggestion?
> 
> 
> -- 
> +---------------------------+  I wasn't expecting it.  When Danny Elfman
> | J H Woodyatt              |  sang the words, `goo goo ga choo,' Sunday
> | bard@cutter.ssd.loral.com |  night, I cracked.  Some horrors are too
> +---------------------------+  large to shade out.

Sounds like you have the clasic "uninitalized pointer" problem that is clobering
your memory.

Go through all your code and check that all pointers are initalized before use!
It looks like the pointer is writing an instruction to jump to location 0x0006
where the illegal instruction is generated. ( I beleive this is the vector table?)

Hope this helps, any body else agree ?

===============================================================================
Mark R. Milligan                EMAIL: markm@ee.ubc.ca 			      |
University of British Columbia						      |
Department of Electrical Engineering					      |
2356 Main Mall								      |
Vancouver, British Columbia	==============================================+
V6T 1Z4				|" Don`t tell me whats happening!...          |
CANADA				|     Just tell me whats going on?    "       |
Phone: (604)822-4242		| infamous quote attributed to ...            |
Fax  : (604)822-9209		| boB (spelled  backwards with a B) J.D. Butt |
===============================================================================
DISCLAIMER:    ( supplied by the law firm of Shyster and Shyster ) 

All opinions, views and comments expressed above are the personal opinions, 
views and comments of Mark R. Milligan and not of his employer.

I Did'nt do it. Nobody saw me do it. You can't prove I did it. - Bart Simpson
				
===============================================================================
 

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

Newsgroups: comp.os.vxworks
Subject: NFS Server Availability?
Date: 18 Jan 93 20:50:59 GMT
From: feather@lds.loral.com (Bob Feather)
Organization: Loral Data Systems
Message-ID: <1993Jan18.205059.21774@lds.loral.com>
Reply-To: feather@lds.loral.com
Sender: news@lds.loral.com

I would like to access a vxworks target booted from its own local disk from 
another vxworks target in the same vme container using the backplane net.
Is there an NFS Server for vxworks anywhere???  Other ideas would be helpful.

Has anybody tried something like this?? Help!!

netDrv's copying of the entire file on an open or close is not acceptable for
our application.

Thanks 

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

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

From xung@fibertek.com  Tue Jan 19 07:08:53 1993
From: xung@fibertek.com ( Xung Dang )
Date: Tue Jan 19 07:09:05 PST 1993
Subject: Buffered VLDS SCSI driver

I am looking for a SCSI driver for a high speed data recorder (Model: Buffered VLDS from Metrum Information Storage). The host is the MVME-167 running under VxWorks 5.0.2b. The SCSI driver must be able to run in the SYNC transfer mode. Any help in this matter is highly appreciated. Please send your response to:
     
        xung@fibertek.com

Thanks,
Xung Dang
Fibertek, Inc.
510 Herndon Parkway
Herndon, VA 22070
Phone: (703) 471-7671
Fax  : (703) 471-5806

From @aaec1.aaec.com:mitchell@sparky.aaec.com  Tue Jan 19 08:00:27 1993
From: Andy Mitchell <mitchell@sparky.aaec.com>
Date: Tue Jan 19 08:00:37 PST 1993
Subject: Re: Mysterious task crashes
I have a few comments to add on this subject.  The illegal instruction at
address 0x06 may be due to a jump to address 0x2 if the values there
happen to be legal instructions.  Since this problem happens in different
tasks, I would think that someone is trashing your memory.  It is not a
problem with your interrupt vector table, since that would cause an
"exception at interrupt level" message and reboot the SBC.  I would be 
very suspicious of any other bus masters getting to the Tadpoles DRAM by 
accessing it as a VME slave.  Many device drivers use command structures
that are malloc'd from local memory, then converted to a VME address with
sysLocalToBusAdrs(), which often requires slight modifications to work with
different targets (i.e. DRAM size or address jumpers different than what 
the routine expects).  If this mapping is done incorrectly, your devices
could be writing results 4 Meg away from where you want.

We had a horrible time with another vendor's SBC in a twenty-one slot card
cage with 16 cards (two of which were 2-slot board sets).  After many 
months of software thrashing (we were blaming our drivers for trashing DRAM)
we found a correlation between errors like this and VME access of the 
multi-ported on-board DRAM.  After more months of fault isolation by us and
the vendor, they found that the DRAM cycle that follows a VME slave cycle 
could occur to the wrong address.  Apparently Motorola does not specify the
time required for the address bus of their 68030 chip to turn back on after
getting the local bus back from another bus master (in this case, the VME
interface).  The board vendor did not allow enough time for the address to
propagate to the DRAM before asserting the DRAM address strobes, so a write
cycle could corrupt memory.  In our case the errors were usually co-processor
violations, because the 68030 timing is different if the 68882 is involved.

The fault only seemed to occur in our backplane because the loading of all of
the cards on the bus slowed down the VME cycles, which is neither the vendor
or we could duplicate the problem in a "test" cage with only a few CPUs.  I
don't know if Tadpole has similar problems, but if there are any design
shortcomings in a SBC board, VME Slave access of the on-board memory seems
to bring them out!  The vendors can't test against all slaves and are quick
to blame the slave VME timing when problems occur.  The big backplane also
causes trouble.  I've heard of other developers who had trouble with ringing
of the VME strobe lines causing trouble with discrete high speed PAL VME
interfaces as well.

Another problem we had before was with the SBC overheating.  A 50 MHz 68030 
board usually needs good air flow to prevent overheating.  On our boards,
the first thing to go was the parity check circuit, causing a few parity
errors - followed by a lock-up or reboot.  I think these were caused by a
failed DRAM cycles.  I would think your SBC would also have similar
serious problems, but you never know!

good luck! (you'll need it!)

Andrew Mitchell
mitchell@aaec.com

These are my own personal opinions, of course!

From daemon@vxw.ee.lbl.gov  Wed Jan 20 04:00:35 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 20 04:00:45 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 20 04:00:26 PST 1993

        Subject: Database for VxWorks ?

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

Newsgroups: comp.os.vxworks
Subject: Database for VxWorks ?
Date: 19 Jan 93 16:06:03 GMT
From: jprice@lds.loral.com (Jeffrey Price)
Organization: Loral Data Systems
Keywords: database isam relational file management
Message-ID: <1993Jan19.160603.246@lds.loral.com>
Reply-To: jprice@lds.loral.com
Sender: news@lds.loral.com

Does anyone know of a lightweight database system that runs under VxWorks ?
A simple quasi-relational model system, or ISAM would be best. I do not 
need (nor expect) a full-blown rdb such as Oracle or Ingres.

Thanks for the help !

Jeff Price
(813)-371-0811  x6823   
jprice@mail.lds.loral.com  

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

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

From stan@rti.com  Wed Jan 20 10:44:59 1993
From: stan@rti.com (Stan Schneider)
Date: Wed Jan 20 10:45:09 PST 1993
Subject: Re: Memory management debug aids...

Hi Steven,

Sorry I'm so late responding.  I've been out of town.

We do indeed have a memory integrity verifier called "heapCheck".  It's
designed to help find bugs that corrupt the system memory pool.  I think it
will help find your problem.  It's also a good thing to try when something bad
happens "for no reason".

HeapCheck is part of a library called "rtilib".  Rtilib also contains some
other useful utilities, like a crude-but-effective reentrant shell, some
simplified network interfaces, etc.

Our current plans are to include rtilib with StethoScope version 4.0.2.  We
expect to upgrade our customer base to this level along with VxWorks 5.1.
However, we can ship current customers (like you) "beta" copies on request.

I've appended the main manual page to this message.

        -- Stan

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

Some context:

>> Date: 15 Jan 93 00:59:23 GMT
>> From: sjk@strl.labs.tek.com (Steven King)
>> 
>> I'm looking for a tool that can help track down a memory overwrite under
>> VxWorks.  (Aren't we all?)  This one is especially tough, since it happens
>> in a reuseable C++ library that is rather complex and would be hard to
>> "instrument" with printf(), memShow() or memPartShow().
>> 
>> Has anyone used Stethoscope in this manner?  Is it possible?
>> 
---------------------------------

>> Submitted-by fjr@rayssd.ssd.ray.com  Fri Jan 15 13:39:44 1993
>> >  Has anyone used Stethoscope in this manner?  Is it possible?
>> 
>> Stethoscope can track the location too periodically.  I assume Stan
>> Schnieder who wrote the tool will respond.  Of course it is pretty hard
>> to get from the periodic point where the value is corrupted to the exact
>> code that did the corruption.
----------------------------------

>> Date: Fri, 15 Jan 93 21:11:39 GMT
>> From: pardo@alta.Stanford.EDU (Gerardo Pardo-Castellote)
>>
>> I don't think you can use Stethoscope for that purpose. However
>> Stethoscope comes with a tool called "heapCheck" that does something
>> very close to what you want. 
----------------------------------

{stan@rti:45} man heap
Reformatting page.  Wait... done

heap(2)                LibUtils Reference                 heap(2)

NAME
     heap - Heap integrity test for VxWorks.

SYNOPSIS
     heapWalk - dump the status of the heap
     heapCheck - check the status of the heap
     heapCheckInit - enable automatic heap checking

     int heapWalk(int minSize, int maxPrint, MEM_BLOCK *block)
     int heapCheck(int verbosity, MEM_BLOCK *block)
     int heapCheckInit(void)

DESCRIPTION
     HeapCheck is a memory-management system integrity test  rou-
     tine  for VxWorks.  It is designed to help find memory prob-
     lems that corrupt the system memory pool.  Examples of prob-
     lems  these routines will expose include writing off the end
     of an array, using an orphan pointer (i.e. one whose  memory
     has been `free'ed), or messing up the allocated memory space
     in general.

     There are two ways to use heapCheck: as a spot check or as a
     background  monitor.   See the documentation for "heapCheck"
     and "heapCheckInit" for details.

     The VxWorks heap  is  normally  structured  in  two  pieces,
     referred to below as the "upper" and the "lower" heaps.  The
     reason for this is that the highest 10K of  memory  is  used
     during the booting process; that region is added to the sys-
     tem memory pool after booting is complete.

NOTE
     Except  for  verbosity  options,  all  messages  are  logged
     through logMsg instead of printf.  This a) allows tasks that
     don't set VX_STDIO to use heapCheck, and b)  prevents  stack
     overflows.  It does, however, mean that a VxWorks shell ses-
     sion should be active when heapCheck is being used.

RTI Version 3.1      Last change: 9 Jan 1993                    1

From bebek@Csa2.LBL.Gov  Wed Jan 20 14:50:42 1993
From: bebek@Csa2.LBL.Gov
Date: Wed Jan 20 14:50:51 PST 1993
Subject: POSIX

Many months back, someone said they had a POSIX "wrapper" for vxworks.
Where can I get this?  I appreicate that this will be nothing more
than a set of mapping functions.

Chris Bebek
Physics Research Division
Superconducting Supercollider
M/S 2000
2550 Beckleymeade Ave
Dallas, TX 75237
bebek@sscvx1.ssc.gov (134.3.1.101)

From daemon@vxw.ee.lbl.gov  Thu Jan 21 04:00:36 1993
From: daemon@vxw.ee.lbl.gov
Date: Thu Jan 21 04:00:48 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Thu Jan 21 04:00:26 PST 1993

        Subject: ppp or cslip implementation for VxWorks
        Subject: Re: Mysterious task crashes

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

Newsgroups: comp.os.vxworks
Subject: ppp or cslip implementation for VxWorks
Date: Wed, 20 Jan 93 22:49:24 GMT
From: lazarus@leland.Stanford.EDU (Howard Wang)
Organization: DSG, Stanford University, CA 94305, USA
Keywords: ppp, cslip, VxWorks
Message-ID: <1993Jan20.224924.25888@leland.Stanford.EDU>
Sender: news@leland.Stanford.EDU (Mr News)

Hi,
   Does anyone know of a PPP or cslip implementation for VxWorks?
I know that slip is released as a driver with VxWorks, but I need
to run ip stuff over a slow (5000 bps) link.  So I'd like to try
ppp (or cslip, ppp prefered).

   I may try to tackle this myself if nobody has before.

   Any help would be appreciated!  Thanks!

Howard H. Wang
lazarus@sun-valley.stanford.edu
415-723-3608

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

Newsgroups: comp.os.vxworks
Subject: Re: Mysterious task crashes
Date: Thu, 21 Jan 1993 06:28:47 GMT
From: hjb@netcom.com (H. J. Bae)
Organization: Peaceful Star Project
Message-ID: <1993Jan21.062847.27457@netcom.com>
References: <1993Jan15.184713.28368@wdl.loral.com> <1993Jan18.163643.619@ee.ubc.ca>

markm@ee.ubc.ca (mark milligan) writes:

>It looks like the pointer is writing an instruction to jump to location 0x0006
>where the illegal instruction is generated. ( I beleive this is the vector table?)

m68k's look for SSP and PC values (in that sequence) starting at addr 0
upon powerup.  0x6 is pointing to least significant half of whatever was
left there (possibly the kernel boot routine address).

if i were you, i'd use a logic analyser to trigger at that address to
track the problem down.  if you don't have one of those, you could 
possibly hack up something -- like putting in a jsr instruction at 
the location to call your routine which can print out stack trace...
or something like that (i know, pretty sick) <grin>

hwajin

- -- 
Hwa-Jin Bae				hjb@netcom.com
Peaceful Star Project
2899 Ford Street, Oakland CA 94601	Available for Civilian contract work.
(510) 536-7607				

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

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

From peter@fibertek.com  Thu Jan 21 06:21:29 1993
From: peter@fibertek.com (Peter H. Stern)
Date: Thu Jan 21 06:21:41 PST 1993
Subject: Synergy SV420 board
Hello. I am considering using a Synergy SV420 dual-68040 board with VxWorks
running on both processors.  I was wondering if anyone out there has ever
used VxWorks with one of these boards and how well it worked out. I am
curious about how useful 2 processors are in an I/O intensive application.

Please post or contact peter@fibertek.com, (703) 471-7671.  Thanks.

From jagski@slug.ssc.gov  Thu Jan 21 07:51:23 1993
From: jagski@slug.ssc.gov (Michael Jagieski)
Date: Thu Jan 21 07:51:39 PST 1993
Subject: VxWorks scsiLib Questions (MVME147, MVME167)
----------
X-Sun-Data-Type: text
X-Sun-Data-Description: text
X-Sun-Data-Name: text
X-Sun-Content-Lines: 0

----------
X-Sun-Data-Type: default
X-Sun-Data-Description: default
X-Sun-Data-Name: help.vx
X-Sun-Content-Lines: 32

Hello,

I am trying to use the VxWorks scsiLib on a MVME147 and a MVME167.
The device I'm trying to communicate with is a SCSI CAMAC crate
controller. I have been successful in using the scsiIoctl routine
to read and write a fixed amount of data.

HOWEVER when the data that I am reading is variable, I get an error
status (= 0x1f) on the MVME147 and the task hangs on the MVME167
waiting for a semaphore release. Somehow I think you are suppose to
use the addLengthByte variable in the SCSI_TRANSACTION structure.

Other problems is that auto-configuring works great for both boards
but when one hard codes the call to scsiPhysDevCreate() the hook
up appears normal but as soon as I try to access the device the
task hangs like above on the MVME167. (This works fine on the MVME147).

Also, the status I get back from this device is only suppose to be
0 or 2 yet I get 0, 2, or 4 from the MVME167 and 0, 0x82, 0x84 and
0x1f from the MVME147.

I have noticed with time measurements that the MVME147 SCSI controller
is 10 times slower than the MVME167. Issuing a simple command to this
device takes 150 microseconds on the MVME167 but 1.50 milliseconds on
the MVME147. Is this because a layer of SCSI firmware exists on the 
MVME147 ?

Finally can one issue SCSI Messages in VxWorks besides SCSI Commands ?

I would appreciate any help, thanks!
jagski@slug.ssc.gov

From thoff@netxwest.com  Thu Jan 21 16:54:39 1993
From: thoff@netxwest.com (Todd Hoff)
Date: Thu Jan 21 16:54:54 PST 1993
Subject: ping command available?
Does anyone have a ping program, similar to Sun's, available under vxWorks?

Thanx for any help.

From chuckm@verdix.com  Fri Jan 22 06:50:25 1993
From: Chuck Meade <chuckm@verdix.com>
Date: Fri Jan 22 06:50:38 PST 1993
Subject: Re: ping command available? 

> Does anyone have a ping program, similar to Sun's, available under vxWorks?

I put together a VXworks based ping() routine a while ago.  Supply the host to
ping as the first parameter and the number of packets to send as the second.

********** defs.h ************************

#include "vxWorks.h"
#include "errno.h"
#include "socket.h"
#include "in_systm.h"
#include "in.h"
#include "ip.h"
#include "ip_icmp.h"
#include "netdb.h" 
#include "wdLib.h"
#include "usrLib.h"
#include "sigLib.h"
#include "taskLib.h"

*********** c-support.c **********************

#include "defs.h"

#define OK                 0
#define Bad_Host           1
#define Bad_Protocol       2
#define Cant_Create_Socket 3

#define From_Our_Request     0
#define Not_From_Our_Request 1

struct sockaddr_in  dest;
int                 sockfd;
char                *hostname ;
struct protoent     *proto ;
u_char              recvpack[4096] ;
int                 num_received = 0 ;

char configure_socket(the_hostname)
   char *the_hostname ;
{
   dest.sin_family = AF_INET ;
   dest.sin_addr.s_addr = hostGetByName(the_hostname) ;
   if (dest.sin_addr.s_addr == ERROR) 
   {
      printf("bad host!\n") ;
      return(Bad_Host) ;
   }
   strcpy(hostname,the_hostname) ;

   sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) ;
   if (sockfd < 0)
   {
      printf("can't create socket\n") ;
      return (Cant_Create_Socket) ;
   }
   else
   {
      return (OK) ;
   }
}

int in_cksm(msg_ptr)
   register u_short  *msg_ptr ;
{
   register long    sum ;
   register u_short answer ;
   int              index ;

   sum = 0 ;

   for (index = 0 ; index < 4 ; index++)
   {
      sum = sum + *msg_ptr ;
      msg_ptr++ ;
   }

   sum = (sum >> 16) + (sum & 0xffff) ;
   sum = sum + (sum >> 16) ;
   answer = ~sum ;
   return (answer) ;
}

int message_number = 1 ;

void construct(msg)
   struct icmp  *msg ;
{
   u_char *byte_ptr ;

   byte_ptr = (u_char *) msg ;

   msg->icmp_type = ICMP_ECHO ;
   msg->icmp_code = 0 ;
   msg->icmp_cksum = 0 ;
   msg->icmp_id = 0x1234 ;
   msg->icmp_seq = message_number++ ;
   msg->icmp_data[0] = 0 ;
   msg->icmp_cksum = in_cksm(msg) ;
}

void xmt_msg(msg)
   struct icmp *msg ;
{
   int i ;
   int packsize ;

   packsize = 8 ;

   i = sendto(sockfd, (caddr_t) msg, packsize, 0, (struct sockaddr *) &dest, sizeof(dest)) ;

   if (i < 0)
   {
      printf("sendto error\n") ;
   }
   else if (i != packsize)
   {
      printf("wrote %s %d bytes, return = %d\n", hostname, packsize, i) ;
   }
}

void receive_pings()
{
   int                 n ;
   int                 fromlen ;
   struct sockaddr_in  from ;
   int                 iphdrlen ;
   struct ip           *ip ;
   struct icmp         *icp ;
   int                 index ;
   extern int          original_num_packets ;

   num_received = 0 ;

   while (1)  /* loop until we break out */
   {
      fromlen = sizeof(from) ;

      n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0, (struct sockaddr *) &from, &fromlen) ;

      if (n < 0)
      {
         if (errno != EINTR)
         {
            printf("recvfrom error\n") ;
         }
         else
         {
            printf("recvfrom interrupted (this is OK)\n") ;
            ;
         }
      }
      else
      {
         ip = (struct ip *) recvpack ;
         iphdrlen = ip->ip_hl << 2 ;
         icp = (struct icmp *) (recvpack + iphdrlen) ;

         if ((icp->icmp_type == ICMP_ECHOREPLY) && (icp->icmp_id == 0x1234))
         {
            num_received++ ;

            if (num_received == original_num_packets)
            {
               exit() ;
            }
         }
      }
   }
}

************** echo-transmitter.c *************************

#include "defs.h"

void sig_alarm() ;
void clean_up() ;
void watchdog_routine() ;

static WDOG_ID wid ;
int  the_tid ;
struct icmp  the_message ;

void transmit_echo_message()
{
   construct(&the_message) ;
   xmt_msg(&the_message) ;
   return ;
} 

void dummy_alarm_handler()
{
   ;
}

SIGVEC handler_info = {dummy_alarm_handler,0,0} ;
SIGVEC save_handler_info ;

void start_pinging()
{
   extern int get_num_packets() ;
   extern void set_num_packets() ;

   sigInit() ;
   sigvec(SIGALRM, &handler_info, &save_handler_info) ;

   the_tid = taskIdSelf() ;
   wid = wdCreate() ;  /* watchdog */
   wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;;

   while (1)
   {
      if (get_num_packets() > 0)
      {
         set_num_packets(get_num_packets() - 1) ;
         transmit_echo_message() ;
      }
      else
      {
         break ;
      }

      pause() ;
   }

   pause() ;
   wdDelete(wid) ;
   clean_up() ;
   exit() ;
}

void watchdog_routine()
{
   kill(the_tid,SIGALRM) ;
   wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;
}

void clean_up()
{
   extern int original_num_packets ;
   extern int num_received ;
   extern char *hostname ;

   if (num_received == original_num_packets)
   {
      printf("host %s is alive\n", hostname) ;
   }
   else
   {
      printf("response trouble with host %s:  sent %d packet%c, received %d packet%c\n",
             hostname, original_num_packets, ((original_num_packets != 1) ? 's' : ' '),
             num_received, ((num_received != 1) ? 's' : ' ') ) ;
   }

   return ;
}

*********** ping-stats.c *******************************

#include "defs.h"

static int num_packets ;

void set_num_packets(to)
   int to ;
{
   num_packets = to ;
}

int get_num_packets()
{
   return (num_packets) ;
}

*********** ping.c ****************************************

#include "defs.h"

int original_num_packets ;

int ping(arg1, arg2)
   char *arg1 ;
   int arg2 ;
{
   extern int configure_socket() ;
   extern void start_pinging() ;
   extern void receive_pings() ;
   int num_packs ;
   int status ;

   /* get user's parameters */

   if (arg1 != NULL) 
   {
      if (arg2 > 1) 
      {
         num_packs = arg2 ;
      }
      else
      {
         num_packs = 1 ;
      }
   }
   else
   {
      printf("Must enter a host name to Ping\n") ;
      return ;
   }

   set_num_packets(num_packs) ;
   original_num_packets = num_packs ;

   /* configure for network communications */

   status = configure_socket(arg1) ;
   
   if (status == OK)
   {
      sp(start_pinging,0,0,0,0,0,0,0,0,0) ;
      sp(receive_pings,0,0,0,0,0,0,0,0,0) ;
   }
   else
   {
      printf("error while trying to configure socket\n") ;
   }
}

************************************************************

Hope this is what you were looking for.

Chuck Meade
Verdix Product Support

From chuckm@verdix.com  Fri Jan 22 06:56:03 1993
From: Chuck Meade <chuckm@verdix.com>
Date: Fri Jan 22 06:56:20 PST 1993
Subject: Re: ping command available? 

> Does anyone have a ping program, similar to Sun's, available under vxWorks?

I put together a VXworks based ping() routine a while ago.  Supply the host to
ping as the first parameter and the number of packets to send as the second.

********** defs.h ************************

#include "vxWorks.h"
#include "errno.h"
#include "socket.h"
#include "in_systm.h"
#include "in.h"
#include "ip.h"
#include "ip_icmp.h"
#include "netdb.h" 
#include "wdLib.h"
#include "usrLib.h"
#include "sigLib.h"
#include "taskLib.h"

*********** c-support.c **********************

#include "defs.h"

#define OK                 0
#define Bad_Host           1
#define Bad_Protocol       2
#define Cant_Create_Socket 3

#define From_Our_Request     0
#define Not_From_Our_Request 1

struct sockaddr_in  dest;
int                 sockfd;
char                *hostname ;
struct protoent     *proto ;
u_char              recvpack[4096] ;
int                 num_received = 0 ;

char configure_socket(the_hostname)
   char *the_hostname ;
{
   dest.sin_family = AF_INET ;
   dest.sin_addr.s_addr = hostGetByName(the_hostname) ;
   if (dest.sin_addr.s_addr == ERROR) 
   {
      printf("bad host!\n") ;
      return(Bad_Host) ;
   }
   strcpy(hostname,the_hostname) ;

   sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) ;
   if (sockfd < 0)
   {
      printf("can't create socket\n") ;
      return (Cant_Create_Socket) ;
   }
   else
   {
      return (OK) ;
   }
}

int in_cksm(msg_ptr)
   register u_short  *msg_ptr ;
{
   register long    sum ;
   register u_short answer ;
   int              index ;

   sum = 0 ;

   for (index = 0 ; index < 4 ; index++)
   {
      sum = sum + *msg_ptr ;
      msg_ptr++ ;
   }

   sum = (sum >> 16) + (sum & 0xffff) ;
   sum = sum + (sum >> 16) ;
   answer = ~sum ;
   return (answer) ;
}

int message_number = 1 ;

void construct(msg)
   struct icmp  *msg ;
{
   u_char *byte_ptr ;

   byte_ptr = (u_char *) msg ;

   msg->icmp_type = ICMP_ECHO ;
   msg->icmp_code = 0 ;
   msg->icmp_cksum = 0 ;
   msg->icmp_id = 0x1234 ;
   msg->icmp_seq = message_number++ ;
   msg->icmp_data[0] = 0 ;
   msg->icmp_cksum = in_cksm(msg) ;
}

void xmt_msg(msg)
   struct icmp *msg ;
{
   int i ;
   int packsize ;

   packsize = 8 ;

   i = sendto(sockfd, (caddr_t) msg, packsize, 0, (struct sockaddr *) &dest, sizeof(dest)) ;

   if (i < 0)
   {
      printf("sendto error\n") ;
   }
   else if (i != packsize)
   {
      printf("wrote %s %d bytes, return = %d\n", hostname, packsize, i) ;
   }
}

void receive_pings()
{
   int                 n ;
   int                 fromlen ;
   struct sockaddr_in  from ;
   int                 iphdrlen ;
   struct ip           *ip ;
   struct icmp         *icp ;
   int                 index ;
   extern int          original_num_packets ;

   num_received = 0 ;

   while (1)  /* loop until we break out */
   {
      fromlen = sizeof(from) ;

      n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0, (struct sockaddr *) &from, &fromlen) ;

      if (n < 0)
      {
         if (errno != EINTR)
         {
            printf("recvfrom error\n") ;
         }
         else
         {
            printf("recvfrom interrupted (this is OK)\n") ;
            ;
         }
      }
      else
      {
         ip = (struct ip *) recvpack ;
         iphdrlen = ip->ip_hl << 2 ;
         icp = (struct icmp *) (recvpack + iphdrlen) ;

         if ((icp->icmp_type == ICMP_ECHOREPLY) && (icp->icmp_id == 0x1234))
         {
            num_received++ ;

            if (num_received == original_num_packets)
            {
               exit() ;
            }
         }
      }
   }
}

************** echo-transmitter.c *************************

#include "defs.h"

void sig_alarm() ;
void clean_up() ;
void watchdog_routine() ;

static WDOG_ID wid ;
int  the_tid ;
struct icmp  the_message ;

void transmit_echo_message()
{
   construct(&the_message) ;
   xmt_msg(&the_message) ;
   return ;
} 

void dummy_alarm_handler()
{
   ;
}

SIGVEC handler_info = {dummy_alarm_handler,0,0} ;
SIGVEC save_handler_info ;

void start_pinging()
{
   extern int get_num_packets() ;
   extern void set_num_packets() ;

   sigInit() ;
   sigvec(SIGALRM, &handler_info, &save_handler_info) ;

   the_tid = taskIdSelf() ;
   wid = wdCreate() ;  /* watchdog */
   wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;;

   while (1)
   {
      if (get_num_packets() > 0)
      {
         set_num_packets(get_num_packets() - 1) ;
         transmit_echo_message() ;
      }
      else
      {
         break ;
      }

      pause() ;
   }

   pause() ;
   wdDelete(wid) ;
   clean_up() ;
   exit() ;
}

void watchdog_routine()
{
   kill(the_tid,SIGALRM) ;
   wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;
}

void clean_up()
{
   extern int original_num_packets ;
   extern int num_received ;
   extern char *hostname ;

   if (num_received == original_num_packets)
   {
      printf("host %s is alive\n", hostname) ;
   }
   else
   {
      printf("response trouble with host %s:  sent %d packet%c, received %d packet%c\n",
             hostname, original_num_packets, ((original_num_packets != 1) ? 's' : ' '),
             num_received, ((num_received != 1) ? 's' : ' ') ) ;
   }

   return ;
}

*********** ping-stats.c *******************************

#include "defs.h"

static int num_packets ;

void set_num_packets(to)
   int to ;
{
   num_packets = to ;
}

int get_num_packets()
{
   return (num_packets) ;
}

*********** ping.c ****************************************

#include "defs.h"

int original_num_packets ;

int ping(arg1, arg2)
   char *arg1 ;
   int arg2 ;
{
   extern int configure_socket() ;
   extern void start_pinging() ;
   extern void receive_pings() ;
   int num_packs ;
   int status ;

   /* get user's parameters */

   if (arg1 != NULL) 
   {
      if (arg2 > 1) 
      {
         num_packs = arg2 ;
      }
      else
      {
         num_packs = 1 ;
      }
   }
   else
   {
      printf("Must enter a host name to Ping\n") ;
      return ;
   }

   set_num_packets(num_packs) ;
   original_num_packets = num_packs ;

   /* configure for network communications */

   status = configure_socket(arg1) ;
   
   if (status == OK)
   {
      sp(start_pinging,0,0,0,0,0,0,0,0,0) ;
      sp(receive_pings,0,0,0,0,0,0,0,0,0) ;
   }
   else
   {
      printf("error while trying to configure socket\n") ;
   }
}

************************************************************

Hope this is what you were looking for.

Chuck Meade
Verdix Product Support

From chuckm@verdix.com  Fri Jan 22 07:06:08 1993
From: Chuck Meade <chuckm@verdix.com>
Date: Fri Jan 22 07:06:25 PST 1993
Subject: Re: ping command available? 

> Does anyone have a ping program, similar to Sun's, available under vxWorks?

I put together a VXworks based ping() routine a while ago.  Supply the host to
ping as the first parameter and the number of packets to send as the second.

********** defs.h ************************

#include "vxWorks.h"
#include "errno.h"
#include "socket.h"
#include "in_systm.h"
#include "in.h"
#include "ip.h"
#include "ip_icmp.h"
#include "netdb.h" 
#include "wdLib.h"
#include "usrLib.h"
#include "sigLib.h"
#include "taskLib.h"

*********** c-support.c **********************

#include "defs.h"

#define OK                 0
#define Bad_Host           1
#define Bad_Protocol       2
#define Cant_Create_Socket 3

#define From_Our_Request     0
#define Not_From_Our_Request 1

struct sockaddr_in  dest;
int                 sockfd;
char                *hostname ;
struct protoent     *proto ;
u_char              recvpack[4096] ;
int                 num_received = 0 ;

char configure_socket(the_hostname)
   char *the_hostname ;
{
   dest.sin_family = AF_INET ;
   dest.sin_addr.s_addr = hostGetByName(the_hostname) ;
   if (dest.sin_addr.s_addr == ERROR) 
   {
      printf("bad host!\n") ;
      return(Bad_Host) ;
   }
   strcpy(hostname,the_hostname) ;

   sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) ;
   if (sockfd < 0)
   {
      printf("can't create socket\n") ;
      return (Cant_Create_Socket) ;
   }
   else
   {
      return (OK) ;
   }
}

int in_cksm(msg_ptr)
   register u_short  *msg_ptr ;
{
   register long    sum ;
   register u_short answer ;
   int              index ;

   sum = 0 ;

   for (index = 0 ; index < 4 ; index++)
   {
      sum = sum + *msg_ptr ;
      msg_ptr++ ;
   }

   sum = (sum >> 16) + (sum & 0xffff) ;
   sum = sum + (sum >> 16) ;
   answer = ~sum ;
   return (answer) ;
}

int message_number = 1 ;

void construct(msg)
   struct icmp  *msg ;
{
   u_char *byte_ptr ;

   byte_ptr = (u_char *) msg ;

   msg->icmp_type = ICMP_ECHO ;
   msg->icmp_code = 0 ;
   msg->icmp_cksum = 0 ;
   msg->icmp_id = 0x1234 ;
   msg->icmp_seq = message_number++ ;
   msg->icmp_data[0] = 0 ;
   msg->icmp_cksum = in_cksm(msg) ;
}

void xmt_msg(msg)
   struct icmp *msg ;
{
   int i ;
   int packsize ;

   packsize = 8 ;

   i = sendto(sockfd, (caddr_t) msg, packsize, 0, (struct sockaddr *) &dest, sizeof(dest)) ;

   if (i < 0)
   {
      printf("sendto error\n") ;
   }
   else if (i != packsize)
   {
      printf("wrote %s %d bytes, return = %d\n", hostname, packsize, i) ;
   }
}

void receive_pings()
{
   int                 n ;
   int                 fromlen ;
   struct sockaddr_in  from ;
   int                 iphdrlen ;
   struct ip           *ip ;
   struct icmp         *icp ;
   int                 index ;
   extern int          original_num_packets ;

   num_received = 0 ;

   while (1)  /* loop until we break out */
   {
      fromlen = sizeof(from) ;

      n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0, (struct sockaddr *) &from, &fromlen) ;

      if (n < 0)
      {
         if (errno != EINTR)
         {
            printf("recvfrom error\n") ;
         }
         else
         {
            printf("recvfrom interrupted (this is OK)\n") ;
            ;
         }
      }
      else
      {
         ip = (struct ip *) recvpack ;
         iphdrlen = ip->ip_hl << 2 ;
         icp = (struct icmp *) (recvpack + iphdrlen) ;

         if ((icp->icmp_type == ICMP_ECHOREPLY) && (icp->icmp_id == 0x1234))
         {
            num_received++ ;

            if (num_received == original_num_packets)
            {
               exit() ;
            }
         }
      }
   }
}

************** echo-transmitter.c *************************

#include "defs.h"

void sig_alarm() ;
void clean_up() ;
void watchdog_routine() ;

static WDOG_ID wid ;
int  the_tid ;
struct icmp  the_message ;

void transmit_echo_message()
{
   construct(&the_message) ;
   xmt_msg(&the_message) ;
   return ;
} 

void dummy_alarm_handler()
{
   ;
}

SIGVEC handler_info = {dummy_alarm_handler,0,0} ;
SIGVEC save_handler_info ;

void start_pinging()
{
   extern int get_num_packets() ;
   extern void set_num_packets() ;

   sigInit() ;
   sigvec(SIGALRM, &handler_info, &save_handler_info) ;

   the_tid = taskIdSelf() ;
   wid = wdCreate() ;  /* watchdog */
   wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;;

   while (1)
   {
      if (get_num_packets() > 0)
      {
         set_num_packets(get_num_packets() - 1) ;
         transmit_echo_message() ;
      }
      else
      {
         break ;
      }

      pause() ;
   }

   pause() ;
   wdDelete(wid) ;
   clean_up() ;
   exit() ;
}

void watchdog_routine()
{
   kill(the_tid,SIGALRM) ;
   wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;
}

void clean_up()
{
   extern int original_num_packets ;
   extern int num_received ;
   extern char *hostname ;

   if (num_received == original_num_packets)
   {
      printf("host %s is alive\n", hostname) ;
   }
   else
   {
      printf("response trouble with host %s:  sent %d packet%c, received %d packet%c\n",
             hostname, original_num_packets, ((original_num_packets != 1) ? 's' : ' '),
             num_received, ((num_received != 1) ? 's' : ' ') ) ;
   }

   return ;
}

*********** ping-stats.c *******************************

#include "defs.h"

static int num_packets ;

void set_num_packets(to)
   int to ;
{
   num_packets = to ;
}

int get_num_packets()
{
   return (num_packets) ;
}

*********** ping.c ****************************************

#include "defs.h"

int original_num_packets ;

int ping(arg1, arg2)
   char *arg1 ;
   int arg2 ;
{
   extern int configure_socket() ;
   extern void start_pinging() ;
   extern void receive_pings() ;
   int num_packs ;
   int status ;

   /* get user's parameters */

   if (arg1 != NULL) 
   {
      if (arg2 > 1) 
      {
         num_packs = arg2 ;
      }
      else
      {
         num_packs = 1 ;
      }
   }
   else
   {
      printf("Must enter a host name to Ping\n") ;
      return ;
   }

   set_num_packets(num_packs) ;
   original_num_packets = num_packs ;

   /* configure for network communications */

   status = configure_socket(arg1) ;
   
   if (status == OK)
   {
      sp(start_pinging,0,0,0,0,0,0,0,0,0) ;
      sp(receive_pings,0,0,0,0,0,0,0,0,0) ;
   }
   else
   {
      printf("error while trying to configure socket\n") ;
   }
}

************************************************************

Hope this is what you were looking for.

Chuck Meade
Verdix Product Support

From rcm@rayssd.ssd.ray.com  Fri Jan 22 09:50:18 1993
From: Mandler <rcm@ssd.ray.com>
Date: Fri Jan 22 09:50:37 PST 1993
Subject: Re:  ping command available?
To thoff and other interested parties,
Here is a "quick and dirty" version of the ping program that we ported to
VxWorks.
    ______________________________________________________________
   |  Roland C Mandler,  Raytheon Submarine Signal Division       |
   |  1847 West Main Road,  Mail Stop 188                         |
   |  Portsmouth, RI  02871-1087  (401) 847-8000 (X4228)          |
   |                                                              |
   |      {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!rcm             |
   |______________________________________________________________|

 /* Includes, defines and global variables used between functions.
 */
#include "vxWorks.h"
#include "mbuf.h"
#include "ctype.h"
#include "socket.h"
#include "if.h"
#include "ioLib.h"
#include "ioctl.h"
#include "iosLib.h"
#include "stdioLib.h"
#include "selectLib.h"
#include "sockLib.h"
#include "in_systm.h"
#include "in.h"
#include "ip.h"
#include "ip_icmp.h"
#include "taskLib.h"
#include "hostLib.h" 
#include "wdLib.h"
#include "errno.h"

extern int	errno;

/* defines */
/*
 * Beware that the outgoing packet starts with the ICMP header and
 * does not include the IP header (the kernel prepends that for us).
 * But, the received packet includes the IP header.
 */
#define	DEF_DATALEN	  56	/* default data area after ICMP header */
#ifndef	INADDR_NONE
#define	INADDR_NONE	0xffffffff	/* should be in <in.h> */
#endif
#ifndef	MAXHOSTNAMELEN
#define MAXHOSTNAMELEN	  64	/* should be defined in <param.h> */
#endif
#define MAXMSG             1    /* number of messages pipe will hold */
#define MAXPIPE            1    /* number of bytes in pipe message */
#define	MAXPACKET	4096	/* max packet size */
#define	MAXWAIT		  10	/* max time to wait for response, sec. */
				/* used only for final receive */
#define	NROUTES		9	/* number of record route slots */
#define PF_ICMP         1       /* ICMP protocol */
#define QUIET		2	/* quiet flag */
#define	RROUTE		8	/* record route flag */
#define	SIZE_ICMP_HDR	   8	/* 8-byte ICMP header */
#define	SIZE_TIME_DATA	   8	/* then the BSD timeval struct (ICMP "data") */

/* variables */
int		datalen;	/* size of data after the ICMP header */
				   /* may be 0 */
				   /* if >= SIZE_TIME_DATA, timing is done */
char		*destdotaddr;
char		*hostname;
short		ident;		/* masked process ID, to identify returns */
int		mytask;         /* full process ID */
int		npackets;	/* max # of packets to send; 0 if no limit */
int		nreceived;	/* # of packets we got back */
int		ntransmitted;	/* sequence # for outbound packets = #sent */
int             pingflags;
int		packsize;	/* size of ICMP packets to send */
				   /* this includes the 8-byte ICMP header */
char            pipecode;
int             pipefd; /* pipe file descriptor */
int             pipestat;
u_char		recvpack[MAXPACKET];	/* the received packet */
char rspace[3+4*NROUTES+1];	/* record route space */
long            sbytes;
u_char		sendpack[MAXPACKET];	/* the packet we send */
int		sockfd;	/* socket file descriptor */
int             time_start;
int             time_ret;
int		timing;		/* true if time-stamp in each packet */
int		tmin;		/* min round-trip time */
int		tmax;		/* max round-trip time */
long		tsum;		/* sum of all round-trip times, for average */
			/* above 3 times are in milliseconds */
int		verbose;	/* enables additional error messages */

/* structures */
struct fd_set   fdset; /*file descriptor bit mapping for select */
struct fd_set  *fdst;
struct sockaddr_in	dest;	/* who to ping */
WDOG_ID wdtmr;

/* routines */
char		*inet_ntoa();	/* BSD library routine */
VOID             ping_task();
VOID             finish();	/* our function to finish up and exit */
VOID             stp();
VOID             timeout_hndl();
VOID             parseOptions();

/*
 * Copyright (c) 1987 Regents of the University of California.
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms are permitted
 * provided that the above copyright notice and this paragraph are
 * duplicated in all such forms and that any documentation,
 * advertising materials, and other materials related to such
 * distribution and use acknowledge that the software was developed
 * by the University of California, Berkeley.  The name of the
 * University may not be used to endorse or promote products derived
 * from this software without specific prior written permission.
 * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR
 * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
 * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE.
 */

#ifndef lint
char copyright[] =
"@(#) Copyright (c) 1987 Regents of the University of California.\n\
 All rights reserved.\n";
#endif /* not lint */

#ifndef lint
static char sccsid[] = "@(#)ping.c	4.10 (Berkeley) 10/10/88";
#endif /* not lint */

/*
 *			P I N G . C
 *
 * Using the InterNet Control Message Protocol (ICMP) "ECHO" facility,
 * measure round-trip-delays and packet loss across network paths.
 *
 * Author -
 *	Mike Muuss
 *	U. S. Army Ballistic Research Laboratory
 *	December, 1983
 * Modified at Uc Berkeley
 *
 * This version was modified to run under vxWorks by:
 *      Roland Mandler
 *      Raytheon Submarine Signal Division
 *      June, 1991
 *
 * Status -
 *	Public Domain.  Distribution Unlimited.
 *
 * Bugs -
 *	More statistics could always be gathered.
 *	This program has to run SUID to ROOT to access the ICMP socket.
 */

char usage[] =
"\nUsage: \
ping [-dnqrvRs] host [datasize [count]] \n\
\n\
    STANDARD OPTIONS: \n\
      -s = continuous    -d = debug    -q = quiet    -v = verbose \n\
      -R = record route  -r = route to interface \n\
\n\
";
char	hnamebuf[MAXHOSTNAMELEN];
char	*pname;

ping(strng)
char strng[];
{
        /* spawn off ping task - makes it easier to kill */
        taskSpawn(NULL, 1, VX_STDIO | VX_DEALLOC_STACK,20000,&ping_task,
                    strng,0,0,0,0,0,0,0,0,0);
}

VOID ping_task(strng)
char strng[];
{
	int sockoptions,on;
        int host;
        int pargc;
	int i, i1, i2, i3, i4;
	unsigned char ttl, loop;
	struct in_addr ifaddr;
        char *argvpar[11];
        char **pargv = argvpar;

        /* parse input string into argc, argv format */
        parseOptions(&pargc,pargv,strng);

	on = 1;
	pname = pargv[0];
	pargc--;
	pargv++;

        fdst = (struct fd_set *)&fdset;
	sockoptions = 0;
        pingflags = 0;
        ntransmitted = 0;
        nreceived = 0;
        verbose = 0;
        timing = 0;
        tmin = 0;
        tmax = 0;
        npackets = 1; /* default is send one ping */
        tmin = 0;
        tmax = 0;
        tsum = 0;
        wdtmr = wdCreate();
	while (pargc > 0 && *pargv[0] == '-') {
		while (*++pargv[0]) switch (*pargv[0]) {
			case 'd': /* debug on */
				sockoptions |= SO_DEBUG;
				break;
			case 'r': /* route to intfc */
				sockoptions |= SO_DONTROUTE;
				break;
			case 'v': /* verbose input error printout */
				verbose++;
				break;
                        case 's': /* continuous pinging at 1 Hz */
                                npackets = 0; /* 1 Hz continuous pinging */
                                printf("\n\nTYPE 'stp' TO ABORT \n\n");
                                break;
			case 'q': /* disables ping send/recv messages */
				pingflags |= QUIET;
				break;
			case 'R': /* record route */
				pingflags |= RROUTE;
				break;
			default:
				goto print_usage;
		}
		pargc--, pargv++;
	}
        if (pargc < 1) {
print_usage:	printf(usage);
		return;
	}

	/*
	 * Assume the host is specified by numbers (Internet dotted-decimal)
	 * and call inet_addr() to convert it.  If that doesn't work, then
	 * assume its a name and call hostGetByName() to look it up.
	 */

	bzero((char *) &dest, sizeof(dest));
	dest.sin_family = AF_INET;

	if ( (dest.sin_addr.s_addr = htons(inet_addr(pargv[0]))) != INADDR_NONE) {
		strcpy(hnamebuf, pargv[0]);
		hostname = hnamebuf;
		destdotaddr = NULL;
	} else {
		if ( (host = htons(hostGetByName(pargv[0]))) == NULL) {
			printf("host name error: %s ", pargv[0]);
		}
		dest.sin_family = AF_INET;
		dest.sin_addr.s_addr = host;
                strcpy(hnamebuf,pargv[0]);
		hostname = hnamebuf;
		destdotaddr = inet_ntoa(dest.sin_addr.s_addr);
				/* convert to dotted-decimal notation */
	}

	/*
	 * If the user specifies a size, that is the size of the data area
	 * following the ICMP header that is transmitted. 	 */

	if (pargc >= 2)
                sscanf(pargv[1],"%d",&datalen);
	else
		datalen = DEF_DATALEN;

	packsize = datalen + SIZE_ICMP_HDR;
	if (packsize > MAXPACKET)
		printf("packet size too large");
	if (datalen >= SIZE_TIME_DATA)
		timing = 1; 

	/*
	 * The user can specify the maximum number of packets to receive.
	 */

	if (pargc > 2) {
                sscanf(pargv[2],"%d",&npackets);
                printf("\n\nTYPE 'stp' TO ABORT \n\n");
        }

	/*
	 * Fetch our process ID.  We use that as the "ident" field
	 * in the ICMP header, to identify this process' packets.
	 * This allows multiple copies of ping to be running on a host
	 * at the same time.  This identifier is needed to separate
	 * the received ICMP packets (since all readers of an ICMP
	 * socket get all the received packets).
	 */

        mytask = taskIdSelf();
	ident = mytask & 0x7fff;

	/*
	 * Create the socket.
	 */

	if ( (sockfd = socket(AF_INET, SOCK_RAW, PF_ICMP)) < 0) 
		printf("can't create raw socket");
	if (sockoptions & SO_DEBUG)
		if (setsockopt(sockfd, SOL_SOCKET, SO_DEBUG, &on,
								sizeof(on)) < 0)
			printf("setsockopt SO_DEBUG error");
	if (sockoptions & SO_DONTROUTE)
		if (setsockopt(sockfd, SOL_SOCKET, SO_DONTROUTE, &on,
								sizeof(on)) < 0)
			printf("setsockopt SO_DONTROUTE error");
	/* Record Route option */
	if( pingflags & RROUTE ) {
#ifdef IP_OPTIONS
		rspace[IPOPT_OPTVAL] = IPOPT_RR;
		rspace[IPOPT_OLEN] = sizeof(rspace)-1;
		rspace[IPOPT_OFFSET] = IPOPT_MINOFF;
		if( setsockopt(sockfd, IPPROTO_IP, IP_OPTIONS, rspace, sizeof(rspace)) < 0 ) {
			printf( "Record route" );
			return;
		}
#else
		printf( "ping: record route not available on this machine.\n" );
		return;
#endif IP_OPTIONS
	}

        /* create a communication pipe */
        pipeDevCreate("ping_pipe",MAXMSG,MAXPIPE); 

        if ((pipefd = open("ping_pipe", O_RDWR, (int) NULL)) == ERROR)
        {
	    printf("error: can't open pipe.\n");
            return;
        }

        /* set up bit map to select on pipe or socket i/o */
        FD_SET(sockfd, fdst);
        FD_SET(pipefd, fdst);

	do_ping();	/* start the output going */
        return;
}

/* This routine is the watchdog timer handler. It writes a timeout indication
 * to the pipe, which is in turn handled within 'do_ping' */

VOID timeout_hndl()
{
    write(pipefd, "t", 1);
}

/* This routine controls ping origination and reception */

do_ping()
{
	int	finflag;
	register int		n;
	int			fromlen;
	struct sockaddr_in	from;
        int                     cont;

        for ( ; ; ) {

       	    send_ping();		/* first send a packet */

	    if (npackets != 0) 
		/*
		 * We've sent the specified number of packets.
		 * But, we can't just terminate, as there is at least one
		 * packet still to be received (the one we sent at the
		 * beginning of this function).
		 * Just wait 10 seconds.
		 */
                 wdStart (wdtmr, MAXWAIT * sysClkRateGet(), timeout_hndl);

            /* wait for either socket or pipe data availability */

            if ( select (32,&fdset,NULL,NULL,NULL) > 0 ) {
                if (FD_ISSET(pipefd,fdst)) {
                    pipestat = read (pipefd,&pipecode, MAXPIPE);
                    finish();
                    break; /* escape the loop and exit the program */
                }  /* pipe data pending */

                if (FD_ISSET(sockfd,fdst)) {

		    fromlen = sizeof(from);
		    if ( (n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0,
				(struct sockaddr *) &from, &fromlen)) < 0) {
			    if (errno == EINTR)
				continue;	/* normal */
			    printf("recvfrom error");
                            break;
                    }
                    /* cancel 10 second timeout */
                    wdCancel(wdtmr);

                    /* check the receive packet */
		    pr_pack(recvpack, n, &from);

		    /*
		     * If we're only supposed to receive a certain number of
		     * packets, and we've reached the limit, stop.
		     */

		    if (npackets && (nreceived >= npackets)) {
			finish();
                        break;
                    }
                    /* wait 1 second before pinging again */
                    taskDelay(sysClkRateGet()); 

                } /* socket data pending */
            } /* select data available */
	} /* loop */
        return;
}
/*
 * Compose and transmit an ICMP ECHO REQUEST packet.  The IP header
 * will be prepended by the kernel.  The ID field is our process ID,
 * and the sequence number is an ascending integer.  The first 8 bytes
 * of the data portion are used to hold a BSD "timeval" struct in host
 * byte-order, to compute the round-trip time of each packet.
 */

send_ping()
{
	register int		i;
	register struct icmp	*icp;		/* ICMP header */
	register u_char		*uptr;		/* start of user data */

	/*
	 * Fill in the ICMP header.
	 */

	icp = (struct icmp *) sendpack;	/* pointer to ICMP header */
	icp->icmp_type  = ICMP_ECHO;
	icp->icmp_code  = 0;
	icp->icmp_cksum = 0;	     /* init to 0, then call in_cksum() below */
	icp->icmp_id    = ident;     /* our pid, to identify on return */
	icp->icmp_seq   = ntransmitted++;	/* sequence number */

	/*
	 * And fill in the remainder of the packet with the user data.
	 * We just set each byte of udata[i] to i (although this is
	 * not verified when the echoed packet is received back).
	 */

	uptr = &sendpack[SIZE_ICMP_HDR + SIZE_TIME_DATA];
	for (i = SIZE_TIME_DATA; i < datalen; i++)
		*uptr++ = i;

	/*
	 * Compute and store the ICMP checksum (now that we've filled
	 * in the entire ICMP packet).  The checksum includes the ICMP
	 * header, the time stamp, and our user data.
	 */

	icp->icmp_cksum = icmp_cksum(icp, packsize);

	/*
	 * Add the time stamp of when we sent it.
	 */

	if (timing)
                time_start = tickGet();

	/*
	 * Now send the datagram.
	 */

	i = sendto(sockfd, sendpack, packsize, 0,
			(struct sockaddr *) &dest, sizeof(dest));

       /* tell the user it went out */
        if ((pingflags & QUIET) == 0)
        {
	    printf("PING %s", hostname);
	    if (destdotaddr)
		printf(" (%s)", destdotaddr);
	    printf(": %d data bytes\n", datalen);
	    setlinebuf(stdout);		/* one line at a time */
        }

	if (i < 0 || i != packsize)  {
		if (i < 0)
			printf("sendto error");
		else
			printf("wrote %s %d bytes, return=%d",
						hostname, packsize, i);
	}
}
/*
 *			I C M P _ C K S U M
 *
 * Checksum routine for Internet Protocol family headers (C Version)
 *
 */
icmp_cksum(addr, len)
u_short *addr;
int len;
{
	register int nleft = len;
	register u_short *w = addr;
	register int sum = 0;
	u_short answer = 0;

	/*
	 *  Our algorithm is simple, using a 32 bit accumulator (sum),
	 *  we add sequential 16 bit words to it, and at the end, fold
	 *  back all the carry bits from the top 16 bits into the lower
	 *  16 bits.
	 */
	while( nleft > 1 )  {
		sum += *w++;
		nleft -= 2;
	}

	/* mop up an odd byte, if necessary */
	if( nleft == 1 ) {
		*(u_char *)(&answer) = *(u_char *)w ;
		sum += answer;
	}

	/*
	 * add back carry outs from top 16 bits to low 16 bits
	 */
	sum = (sum >> 16) + (sum & 0xffff);	/* add hi 16 to low 16 */
	sum += (sum >> 16);			/* add carry */
	answer = ~sum;				/* truncate to 16 bits */
	return (answer);
}

/*
 * Print out the packet, if it came from us.  This logic is necessary
 * because ALL readers of the ICMP socket get a copy of ALL ICMP packets
 * which arrive ('tis only fair).  This permits multiple copies of this
 * program to be run without having intermingled output (or statistics!).
 */

pr_pack(buf, cc, from)
char			*buf;	/* ptr to start of IP header */
int			cc;	/* total size of received packet */
struct sockaddr_in	*from;	/* address of sender */
{
	int			i, iphdrlen, triptime;
	struct ip		*ip;		/* ptr to IP header */
	register struct icmp	*icp;		/* ptr to ICMP header */
	long			*lp;
	struct timeval		tv;
	char			*pr_type();

	from->sin_addr.s_addr = ntohl(from->sin_addr.s_addr);

	if (timing)
                time_ret = tickGet();

	/*
	 * We have to look at the IP header, to get its length.
	 * We also verify that what follows the IP header contains at
	 * least an ICMP header (8 bytes minimum).
	 */

	ip = (struct ip *) buf;
	iphdrlen = ip->ip_hl << 2;	/* convert # 16-bit words to #bytes */
	if (cc < iphdrlen + ICMP_MINLEN) {
		if (verbose)
			printf("packet too short (%d bytes) from %s\n", cc,
				inet_ntoa(ntohl(from->sin_addr.s_addr)));
		return;
	}
	cc -= iphdrlen;

	icp = (struct icmp *)(buf + iphdrlen);
	if (icp->icmp_type != ICMP_ECHOREPLY) {
		/*
		 * The received ICMP packet is not an echo reply.
		 * If the verbose flag was set, we print the first 48 bytes
		 * of the received packet as 12 longs.
		 */

		if (verbose) {
			lp = (long *) buf;	/* to print 12 longs */
			printf("%d bytes from %s: ", cc,
				inet_ntoa(ntohl(from->sin_addr.s_addr)));
			printf("icmp_type=%d (%s)\n",
				icp->icmp_type, pr_type(icp->icmp_type));
			for (i = 0; i < 12; i++)
			    printf("x%2.2x: x%8.8x\n", i*sizeof(long), *lp++);
			printf("icmp_code=%d\n", icp->icmp_code);
		}
		return;
	}

	/*
	 * See if we sent the packet, and if not, just ignore it.
	 */

	if (icp->icmp_id != ident)
		return;

        if ((pingflags & QUIET) == 0)
        {
	    printf("%d bytes from %s: ", cc,
				     inet_ntoa(ntohl(from->sin_addr.s_addr)));
	    printf("ping # = %d. \n ", icp->icmp_seq);
        }
	if (timing) {
		/* Calculate the round-trip time, and update the min/avg/max */		
                triptime =(time_ret - time_start) * (1000 /sysClkRateGet());
		tsum += triptime;
		if (triptime < tmin)
			tmin = triptime;
		if (triptime > tmax)
			tmax = triptime;
	} 

	nreceived++;	/* only count echo reply packets that we sent */
}

/*
 * Convert an ICMP "type" field to a printable string.
 * This is called for ICMP packets that are received that are not
 * ICMP_ECHOREPLY packets.
 */

char *
pr_type(t)
register int t;
{
	static char	*ttab[] = {
		"Echo Reply",
		"ICMP 1",
		"ICMP 2",
		"Dest Unreachable",
		"Source Quence",
		"Redirect",
		"ICMP 6",
		"ICMP 7",
		"Echo",
		"ICMP 9",
		"ICMP 10",
		"Time Exceeded",
		"Parameter Problem",
		"Timestamp",
		"Timestamp Reply",
		"Info Request",
		"Info Reply"
	};

	if (t < 0 || t > 16)
		return("OUT-OF-RANGE");

	return(ttab[t]);
}

/*
 *	parseOptions.c
 * 	Generate Unix style (argc, argv) parameters from an incoming
 *	VxWorks command string.  Chops up the original string with
 *	nulls to make short strings and fills the argv array with pointers
 *	to the new strings.
 *
 *	maximum of 10 parameters should be defined. (argv[11] in caller).
 *	parameters should be seperated by blanks or tabs.
 */
VOID
parseOptions(argc, argv, inpStr)
	int	*argc;			/* argument count */
	char	*argv[];		/* argument pointers */
	char	*inpStr;		/* original input line */
{
	char	*cch;			/* current character */

	cch = inpStr;
	*argc = 1;			/* always at least 1 */
	
	while (*cch != '\0')
	{
		while (((*cch == ' ') || (*cch == '	')) && (*cch != '\0'))
			cch++;

              
                if (*cch != '\0')
                {
		    argv[*argc] = cch;
		    *argc += 1;

		    while ((*cch != ' ') && (*cch != '	') && 
                           (*cch != '\0'))
			    cch++;
                    if (*cch != '\0')
		        *cch++ = '\0';
                }
	}
}

/*
 * Print out statistics, and stop.
 */

VOID finish()
{
	printf("\n----%s PING Statistics----\n", hostname );
	printf("%d packets transmitted, ", ntransmitted );
	printf("%d packets received, ", nreceived );
	if (ntransmitted)
		printf("%d%% packet loss",
			(int) (((ntransmitted-nreceived)*100) / ntransmitted) );
	printf("\n");
	if (nreceived && timing)
		printf("round-trip (ms)  min/avg/max = %d/%d/%d\n",
				tmin, tsum / nreceived, tmax );
        wdCancel(wdtmr);
        close(pipefd);
        close(sockfd);
        printf("PING done. Hit <return>.\n");
        taskDelete(mytask);
}
/* termination of continuous pinging */

VOID stp()
{
    finish();
}

From daemon@vxw.ee.lbl.gov  Sat Jan 23 04:00:46 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 23 04:00:55 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 23 04:00:35 PST 1993

        Subject: Re: ping command available?
        Subject: 000 Wind River Ski Trip 000
        Subject: X ported to vxworks?

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

Newsgroups: comp.os.vxworks
Subject: Re: ping command available?
Date: Fri, 22 Jan 1993 16:23:27 GMT
From: hjb@netcom.com (H. J. Bae)
Organization: Peaceful Star Project
Message-ID: <1993Jan22.162327.23310@netcom.com>
References: <9301202154.AA10021@cinnabar.netx.com>

In article <9301202154.AA10021@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes:
>Does anyone have a ping program, similar to Sun's, available under vxWorks?

not that i know of.  it's easy to write one though.  or you can port
the guts of code from  unix ping that opens a raw socket to write icmp
echo packets.  or, you can just allocate an mbuf, fill in the ip and
icmp stuff into it and pass it to icmp_send() routine directly (less
lines of code, no sockets)

hwajin

- -- 
Hwa-Jin Bae
Peaceful Star Project
2899 Ford St., Oakland CA 94601	
hjb@netcom.com  (510) 536-7607

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

Newsgroups: comp.os.vxworks
Subject: 000 Wind River Ski Trip 000
Date: 22 Jan 93 21:08:39 GMT
From: pat@wrs.com (Patrick Boylan)
Organization: Wind River Systems
Keywords: ski ski ski ski ski
Message-ID: <pat.727736919@wrs.com>
Reply-To: pat@wrs.com
Sender: news@wrs.com (News Manager)

Some Wind River folk are planning a weekend ski trip to South Tahoe 
(leaving Alameda March 12).

The plan is to charter a bus for the weekend.  Accomodations are at 
fairly large condos (sleep 10).  Cost depends on the number of people.
For 30 - 40 people, the cost should be roughly as follows :

Bus + accomodations: ~ $120
Heavenly valley 2 days: $78

It is NOT limited to just Wind River Systems so if anyone is interested in 
coming along, drop a note.

Space is limited.

Reply to pat@wrs.com or nigel@wrs.com.

See ya there,
Patrick

- -- 
 Patrick Boylan, - Wind River Systems, Alameda, CA - pat@wrs.com

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

Newsgroups: comp.os.vxworks
Subject: X ported to vxworks?
Date: 23 Jan 93 00:28:30 GMT
From: johnch@test22.sun.com (Sam the Skank from Geezer)
Organization: Impossible Missions Force
Message-ID: <JOHNCH.93Jan22162830@test22.sun.com>

Has anyone ported X to vxworks, or tried?  If so, how did it go?

- -- John C

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

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

From daemon@vxw.ee.lbl.gov  Sun Jan 24 04:00:43 1993
From: daemon@vxw.ee.lbl.gov
Date: Sun Jan 24 04:00:52 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sun Jan 24 04:00:33 PST 1993

        Subject: Distributed communications packages

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

Newsgroups: comp.os.vxworks
Subject: Distributed communications packages
Date: Sat, 23 Jan 1993 20:28:16 GMT
From: mkb@cs.cmu.edu (Mike Blackwell)
Organization: Field Robotics Center, CMU
Message-ID: <C1Bq76.EBK.2@cs.cmu.edu>
Reply-To: mkb@cs.cmu.edu
Sender: news@cs.cmu.edu (Usenet News System)

I'm looking for *commercially supported* packages that allow
communications between distributed processes running a mixture of
VxWorks boxes and Sun workstations. Right now we're using CMU's
TCA/TCX, but our client (NASA) is worried about long term support. I
have a description of Sparta's ARTSE executive, which sounds like it
would do the trick. Can anyone comment on their experiences with it?
Are there any other packages out there?

		thanks!   Mike Blackwell	mkb@cs.cmu.edu

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

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

From tweadon@sadira.gb.nrao.edu  Mon Jan 25 07:20:35 1993
From: tweadon@sadira.gb.nrao.edu (TIM WEADON)
Date: Mon Jan 25 07:20:48 PST 1993
Subject: MC68230 PI/T Software driver
I'm looking for a software driver for the MC68230 chip. Actually for
the Motorola MV340B card. Does anyone out there have something I could
use or at least start from?

Thanks in advance.
Tim Weadon
P.O. Box 2
Green Bank, WV. 24944
(304) 456-2120

From visicom!VisiCom.COM!trest@nosc.mil  Mon Jan 25 09:06:09 1993
From: Mike Trest <trest@visicom.com>
Date: Mon Jan 25 09:06:18 PST 1993
Subject: Re: comp.os.vxworks newsdigest
> Jeff Price
> 
> Does anyone know of a lightweight database system that runs under VxWorks ?
> A simple quasi-relational model system, or ISAM would be best. I do not 
> need (nor expect) a full-blown rdb such as Oracle or Ingres.

Jeff,

I would acquire C-ISAM for the PC which is available in source format.
Several years ago I ported the code to several UNIX platforms and 
modified for custom DBMS use.  It should port easily to vxWorks.

..mike..

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From visicom!VisiCom.COM!trest@nosc.mil  Mon Jan 25 10:00:06 1993
From: Mike Trest <trest@visicom.com>
Date: Mon Jan 25 10:00:16 PST 1993
Subject: Re: comp.os.vxworks newsdigest
> 
> Has anyone ported X to vxworks, or tried?  If so, how did it go?
> 
> - -- John C

John,

VisiCom Laboratories did this about 2 years ago. X and MOTIF
standard distributions are available for X11R4 and X11R5 (soon).
Since we had done several previous port of X the move to
vxWorks was relatively easy.  The main problems were in the
"environmental assumptions about UNIX" which implicit in
the prototype code from MIT and OSF. 

Now, the product uses client code which is written for any
level of X  (Xlib,Xtoolkit,Athena,MOTIF) and will handle
code generated by most of the GUI builders.

It is in use by several hardware OEMs for use in their custom
products.   It is available now for 68K, SPARC targets.

It has a full X server implementation as well as support for
several different hardware display adapters.

If you need additional information please EMAIL Mr. Gene Kennon
at:  gene_kennon@visicom.com

====================================================
Mike Trest                      trest@visicom.com
Senior Engineer                 Voice: 619 457 2111
Technology Group                Fax:   619 457 0888
VisiCom Laboratories            San Diego, CA 
====================================================

From thoff@netxwest.com  Mon Jan 25 15:05:59 1993
From: thoff@netxwest.com (Todd Hoff)
Date: Mon Jan 25 15:06:07 PST 1993
Subject: Re: comp.os.vxworks newsdigest
Thanx. I received several pings, but yours sounds the shortest.

From daemon@vxw.ee.lbl.gov  Tue Jan 26 04:00:56 1993
From: daemon@vxw.ee.lbl.gov
Date: Tue Jan 26 04:01:05 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Tue Jan 26 04:00:46 PST 1993

        Subject: Looking for VME-based encoder board that works under VxWorks

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

Newsgroups: comp.os.vxworks
Subject: Looking for VME-based encoder board that works under VxWorks
Date: 25 Jan 93 15:58:42 GMT
From: miller@isrc.sandia.gov (Dave Miller)
Organization: Sandia National Labs, Org. 1600, Albq., NM
Message-ID: <1993Jan25.155842.27584@isrc.sandia.gov>

I am interested in interfacing a CNC machine to a VME bus in order to
implement joint position feedback from the CNC controller.  4 of the 5
axes on my CNC have encoders with relatively easy access to their signals.
I am looking for a VME encoder board which can be programmed to receive
these signals and convert them into X, Y, Z, A, and B values.  Has anyone
had any experience using this type of interface or recommendations for a
vendor which supplies a suitable interface board ?

Thanks

Dave Miller
miller@isrc.sandia.gov

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

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

From stan@rti.com  Tue Jan 26 15:52:11 1993
From: stan@rti.com (Stan Schneider)
Date: Tue Jan 26 15:52:23 PST 1993
Subject: Re: comp.os.vxworks newsdigest
>> Date: 25 Jan 93 15:58:42 GMT
>> From: miller@isrc.sandia.gov (Dave Miller)
>> 
>> I am interested in interfacing a CNC machine to a VME bus in order to
>> implement joint position feedback from the CNC controller.  4 of the 5
>> axes on my CNC have encoders with relatively easy access to their signals.
>> I am looking for a VME encoder board which can be programmed to receive
>> these signals and convert them into X, Y, Z, A, and B values.  Has anyone
>> had any experience using this type of interface or recommendations for a
>> vendor which supplies a suitable interface board ?
>> 

We've used some boards by Whedco in Ann Arbor with good results.  We have
VxWorks drivers for the Whedco 3570 board available.  Drop me a line if you're
interested.

        -- Stan

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

From interf!atlas!athena!buchanan@uunet.uu.net  Tue Jan 26 17:11:25 1993
From: interf!atlas!athena!buchanan@uunet.uu.net (Keith Buchanan)
Date: Tue Jan 26 17:11:45 PST 1993
Subject: Distributed communications packages
We use ARTSE at the Naval Observatory in the Optical Interferometer Project.
We have a distributed control system with Themis 680x0 CPUs, Heurikon 680x0
CPUs and SUN 3 & 4 workstations.  ARTSE has performed well for us not only
for network communications but for process control, startup etc.  Mike Anderson
et al at Sparta have been most helpful with any questions we have posed.
I would recommend the product and the company supporting it to my own brother.
Anyone requiring a more in depth commentary, please contact me via e-mail at
buchanan@interf.com.  If there is considerable traffic, I will post it to
the exploder.

Keith Buchanan
Interferometrics, Inc.
8150 Leesburg Pike
Vieena, VA  22182-2799 

From daemon@vxw.ee.lbl.gov  Wed Jan 27 04:00:52 1993
From: daemon@vxw.ee.lbl.gov
Date: Wed Jan 27 04:01:01 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Wed Jan 27 04:00:43 PST 1993

        Subject: Newer GCC?

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

Newsgroups: comp.os.vxworks
Subject: Newer GCC?
Date: Tue, 26 Jan 1993 21:11:08 GMT
From: dwilliam@pizza.ess.harris.com (Dave Williams)
Organization: Harris Corporation - ISD
Keywords: vxWorks 5.0.3
Message-ID: <C1HC6L.19t@jabba.ess.harris.com>
Sender: usenet@jabba.ess.harris.com (Usenet News Feed Account)

   Here's a question for WRS - what version of the GCC compiler are you
planning on releasing with the newest release of VxWorks?  I noticed a 
few days back that the latest and greatest is up to 2.3.3.  Any plans?

   (We really want to use some of the neat C++ - comments (//) that
the new GCC includes)

- --
Dave Williams                                   | "What time is it?" "9:00AM"
 dwilliam@jabba.ess.harris.com                  | "What day?"        "Monday"
  "Huh?  What?  Could you repeat the question?" | "Go away.  Try me Tuesday"
    <mumble mumble> opinions <mumble mumble> mine <mumble mumble mumble>

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

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

From talarian!brianq@uunet.uu.net  Wed Jan 27 11:43:14 1993
From: talarian!brianq@uunet.uu.net (Brian Quigley)
Date: Wed Jan 27 11:43:23 PST 1993
Subject: Executing shell scripts
I've got a need to execute a shell script from within a program I'm
working on.  I figured I'd copy the startup shell script code since it
does what I want.  Unfortunately, the code that I took from usrConfig.c
does not behave the same when I put it my code.  The script does not execute.  

I've tried killing any existing shell before I start the new one. This
doesn't seem to help.  Various messing with ioTaskSetStd, 
shellOrigStdSet, and ioGlobalStdSet produce undesirable results.

Any hints would be appreciated.

Thanks.

(P.S. Hints for a Unix like "system()" call would also be appreciated.)

---
Brian Quigley         |  brianq@talarian.com
Talarian Corporation  |  (415)965-8050

From fwr8bv@fin.af.mil  Wed Jan 27 16:40:34 1993
From: Chatterjee S <fwr8bv@fin.af.mil>
Date: Wed Jan 27 16:40:43 PST 1993
Subject: Motorola MVME-332 Driver
Does anyone have a vxWorks (5.0) driver for the Mototola MVME-332 (which
is an "Intelligent Communications Controller" for serial comm.)?  We are
using it (4 of the 8 ports available) to interface to 4 Gulton digital
strip-chart recorders.

Thanks,
Shash.

+-----------------------------------------------------------------------------+
+ Shash Chatterjee                               EMAIL:  fwr8bv@fin.af.mil    +
+ EC Software                                   PHONE:  (817) 763-1495        +
+ General Dynamics, Ft. Worth Div.             FAX:    (817) 777-2115         +
+ P.O. Box 748, MZ1719                                                        +
+ Ft. Worth, TX 76101                                                         +
+-----------------------------------------------------------------------------+

From zander@luke.atdiv.lanl.gov  Thu Jan 28 11:22:42 1993
From: zander@luke.atdiv.lanl.gov (Mark Zander)
Date: Thu Jan 28 11:29:26 PST 1993
Subject: Re: Executing shell scripts
Sorry it took so long, but I wanted to clear this before sending it.

Brian Quigley writes:

> I've got a need to execute a shell script from within a program I'm
> working on.  I figured I'd copy the startup shell script code since it
> does what I want.  Unfortunately, the code that I took from usrConfig.c
> does not behave the same when I put it my code.  The script does not execute.  
> 
> I've tried killing any existing shell before I start the new one. This
> doesn't seem to help.  Various messing with ioTaskSetStd, 
> shellOrigStdSet, and ioGlobalStdSet produce undesirable results.
> 
> Any hints would be appreciated.
> 
> Thanks.
> 
> (P.S. Hints for a Unix like "system()" call would also be appreciated.)

I've had a similar need to execute shell scripts from a unix shell.
The following code worked for that purpose.  I hope it can help you
as well.  Good luck!

/*	r s h d . c
*
*************************************************************************
*
*				L O S   A L A M O S
*			Los Alamos National Laboratory
*			 Los Alamos, New Mexico 87545
*
*	File Name:			rshd.c
*	Environment:		VxWorks V4.0
*	Developement:		Sun C, Sun OS 4.0, Sun 3/60
*	Make Description:
*
*
*	Modification History
*	------------ -------
*
*	Date		Programmer		Comments
*	----		----------		--------
*
*	1-Jun-90	Mark Zander		Borrowed from telnetLib
*
*************************************************************************
*/

/*
*       Source Code Control System Identifier
*/
static char SccsId[ ] = "@(#)rshd.c	1.1    11/20/91";
/*
*************************************************************************
*++
*	Name
*	----
*
*>>	rshd	- remote shell daemon for vxWorks
*
*	Purpose
*	-------
*
*
*	Subroutine List
*	---------- ----
*
*	rshInit		- initialize remote shell daemon
*	rshd		- remote shell daemon
*
*	Include Files
*	------- -----
*
*
*
*	See Also
*	--- ----
*
*
*--
*************************************************************************
*/
#include	"vxWorks.h"
#include	"types.h"
#include	"socket.h"
#include	"in.h"
#include	"ioLib.h"
#include	"taskLib.h"

/* login       513/tcp */
/* shell       514/tcp     cmd     # no passwords used */

#define		RSH_SERVICE			514				/* shell port number */

#define		STDIN_BUF_SIZE		512

static int	rshTaskOptions		= VX_SUPERVISOR_MODE | VX_UNBREAKABLE;
static int	rshTaskStackSize	= 1500;
static int	rshTaskPriority		= 2;

int			rshdId;								/* task id of rshd task */

static char	*rshShellName		= "shell";

static char	*ptyRshName			= "/pty/rsh.";
static char	*ptyRshNameM		= "/pty/rsh.M";	/* master side */
static char	*ptyRshNameS		= "/pty/rsh.S";	/* slave side */

VOID rshd( );

/*
*************************************************************************
*+
*	Name
*	----
*
*>	rshInit		- initialize remote shell daemon
*
*	Purpose
*	-------
*
*	Remote shell initialize.
*
*	Calling Sequence
*	------- --------
*
*	rshInit( );
*
*-
*************************************************************************
*/
VOID rshInit( )

{
	static BOOL done = FALSE;	/* FALSE = not done */

	if ( done ) {
		printErr( "rshInit: already initialized.\n" );
		return;
	}

	if ( ptyDrv( ) == ERROR ||
			ptyDevCreate( ptyRshName, 1024, 1024 ) == ERROR ) {
		printErr ("rshInit: unable to create pty device.\n");
		return;
	}

	rshdId = taskSpawn( "rshd", rshTaskPriority,
						rshTaskOptions, rshTaskStackSize,
						rshd, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 );  

	if ( rshdId == ERROR ) {
		printErr( "rshInit: unable to spawn rshd.\n" );
	} else {
		done = TRUE;
	}
}

/*
*************************************************************************
*+
*	Name
*	----
*
*>	rshd		- remote shell daemon
*
*	Purpose
*	-------
*
*	Remote shell daemon.  Similar to telnetd.  Executes a shell command sent
*	via the shell socket from another machine.  Does not redirect input or
*	output of the given command and for this reason requires a special version
*	of the unix rshell command.  Started from routine "rshInit".
*
*	Calling Sequence
*	------- --------
*
*	rshd( );
*-
*************************************************************************
*/
VOID rshd( )

{
	int					optval;
	struct sockaddr_in	myAddress;
	struct sockaddr_in	clientAddress;
	int					clientAddrLen;
	int					client;
	int					masterFd;
	int					slaveFd;
	int					sd;
    char				buf[ STDIN_BUF_SIZE ];
	int					n;
	int					shellInFd;
/*
*	Open a socket and wait for a client
*/
	sd = socket( AF_INET, SOCK_STREAM, 0 );
   
	bzero( (char *) &myAddress, sizeof( myAddress ) );
	myAddress.sin_family = AF_INET;
	myAddress.sin_port   = RSH_SERVICE;

	if ( bind( sd, (struct sockaddr *) &myAddress, sizeof( myAddress ) )
			== ERROR ) {
		printErr( "rshd: bind failed.\n" );
		return;
	}

	listen( sd, 5 );

	FOREVER {
/*
*	Wait for shell to exist
*/
		while ( taskNameToId( rshShellName ) == ERROR ) {
			taskDelay( sysClkRateGet( ) );
		}
		errnoSet( OK );		/* clear errno for pretty i() display */
/*
*	Now accept connection
*/
		clientAddrLen = sizeof( clientAddress );
		client = accept( sd, (struct sockaddr *) &clientAddress, &clientAddrLen );

		if ( client == ERROR ) {
			printErr( "rshd: accept failed - status = 0x%x\n", errnoGet( ) );
			continue;
		}
/*
*	create the pseudo terminal:
*		the master side is connected to the socket to the remote machine
*/

		if ( ( masterFd = open( ptyRshNameM, WRITE ) ) == ERROR ) {
			char *msg = "\r\nSorry, trouble with pty.\r\n";

			printErr( "rshd: error opening %s\n", ptyRshNameM );
			write( client, msg, strlen( msg ) );
			close( client );
			continue;
		}

		if ( ( slaveFd = open( ptyRshNameS, READ ) ) == ERROR ) {
			char *msg = "\r\nSorry, trouble with pty.\r\n";

			printErr( "rshd: error opening %s\n", ptyRshNameS );
			write( client, msg, strlen( msg ) );
			close( client );
			close( masterFd );
			continue;
		}
/*
*	Set up slave
*/
		ioctl( slaveFd, FIOOPTIONS, OPT_RAW );
		ioctl( slaveFd, FIOFLUSH );
/*
*	Save original standard in of shell
*/
		shellInFd  = ioGlobalStdGet( STD_IN );
/*
*	Redirect standard in of shell
*/
		shellOrigStdSet( STD_IN, slaveFd );
/*
*	Restart shell so it'll accept this command
*/
		taskRestart( taskNameToId( rshShellName ) );
/*
*	Get command form remote host and send it to shell
*/
		if ( ( n = read( client, buf, sizeof( buf ) ) ) > 0 ) {
			buf[n] = 0;
			write( masterFd, buf, n );
		}
/*
*	Set shell back to orginal standard in
*/
		shellOrigStdSet( STD_IN, shellInFd );
/*
*	Close connections to shell and remote host
*/
		close( masterFd );
		close( slaveFd );
		close( client );
	}
}

/*	v s h . c
*
*************************************************************************
*
*				L O S   A L A M O S
*			Los Alamos National Laboratory
*			 Los Alamos, New Mexico 87545
*
*	File Name:			vsh.c
*	Environment:		VxWorks V4.0
*	Developement:		Sun C, Sun OS 4.0, Sun 3/60
*	Make Description:
*
*
*	Modification History
*	------------ -------
*
*	Date		Programmer		Comments
*	----		----------		--------
*
*	4-Jun-90	Mark Zander		Original
*	21-Nov-91	me				change name from rsh to vsh to avoid name
*								clashes
*
*************************************************************************
*/

/*
*************************************************************************
*+
*	Name
*	----
*
*>	vsh		- execute remote shell command on a vxWorks system
*
*	Purpose
*	-------
*
*	Executes a remote shell command for a vxWorks system.  Sends one command
*	over the shell socket.  Is similar to the unix rsh command but does not
*	redirect stdin and stdout.
*
*	Command
*	-------
*
*	% vsh hostname cmd
*
*	or
*
*	% vsh
*	Host name? hostname
*	Command? cmd
*
*	Arguments
*	---------
*
*	hostname	name of host listed in yp directory
*	cmd			remote command to be executed
*
*	Example
*	-------
*
*
*	Special Comments
*	------- --------
*
*
*	See Also
*	--- ----
*
*
*-
*************************************************************************
*/
#include <string.h>

#define		RSH_SERVICE			514				/* shell port number */
/*
*	Source Code Control System Identifier
*/
static char SccsId[ ] = "@(#)vsh.c	1.3    11/21/91";

void main(argc, argv)
/*
*	Arguments
*/
	int			argc;				/* command line argument count */
	char		**argv;				/* command line arguments */
{
/*
*	Variables
*/
	int			argin;				/* argument index */
	char		hostname[100];		/* host name */
	char		cmd[300];			/* remote command */
	int			sock;				/* socket */
	int			i;					/* iteration counter */

	argin = 1;
	getarg("Host name? ", argc, argv, &argin, hostname);
	getarg("Command? ", argc, argv, &argin, cmd);
	for (i = argin; i < argc; i++) {
		strcat(cmd, " ");
		strcat(cmd, argv[i]);
	}
	strcat(cmd, "\n");
	sock = socClient(hostname, RSH_SERVICE);
	write(sock, cmd, strlen(cmd));
	close(sock);
}

From daemon@vxw.ee.lbl.gov  Fri Jan 29 04:00:57 1993
From: daemon@vxw.ee.lbl.gov
Date: Fri Jan 29 04:01:07 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Fri Jan 29 04:00:48 PST 1993

        Subject: VIC068 DMA
        Subject: Re: ppp or cslip implementation for VxWorks
        Subject: OR VME products

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

Newsgroups: comp.os.vxworks
Subject: VIC068 DMA
Date: Fri, 22 Jan 93 15:50:19 GMT
From: singer@ll.mit.edu (Matthew R. Singer)
Organization: MIT Lincoln Laboratory
Message-ID: <1993Jan22.155019.26724@ll.mit.edu>
Reply-To: singer@ll.mit.edu (Matthew R. Singer)
Sender: singer@ll.mit.edu (Matthew R. Singer)

- --
Can anyone provide me a short code fragment showing how to do a 
DMA transfer using the vic068 chip?

Thanks

- ----------------------------------------------------------------------------
Matthew R. Singer                                    MIT Lincoln Laboratory
(617) 981-3771                                       244 Wood Street
singer@ll.mit.edu                                    Lexington, MA 02173
- -----------------------------------------------------------------------------

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

Newsgroups: comp.os.vxworks
Subject: Re: ppp or cslip implementation for VxWorks
Date: 26 Jan 93 18:32:39 GMT
From: ajm@wilson.fibercom.com (AJ Madison)
Keywords: ppp, cslip, VxWorks
Message-ID: <45309@fibercom.COM>
References: <1993Jan20.224924.25888@leland.Stanford.EDU>
Sender: news@fibercom.COM

In article <1993Jan20.224924.25888@leland.Stanford.EDU>, lazarus@leland.Stanford.EDU (Howard Wang) writes:
> Hi,
>    Does anyone know of a PPP or cslip implementation for VxWorks?
> I know that slip is released as a driver with VxWorks, but I need
> to run ip stuff over a slow (5000 bps) link.  So I'd like to try
> ppp (or cslip, ppp prefered).
> 
>    I may try to tackle this myself if nobody has before.
> 
>    Any help would be appreciated!  Thanks!
> 

I'm not particularly fond of Me Too postings.  However, on the off
chance that any responses to Howard's request were all over e-mail, I
also am interested in a vxworks PPP.  

Also, to open things up a bit, has anyone ported one of the PD versions
of PPP to a VxWorks environment?  I have copies of the original ppp,
ppp-1.1, and dp-2.2, so if the comments are terse portation notes, I'd
be more than willing to take a look anyway.

I'm definitely doing a PPP, but depending upon how things work out, it
may not necessarily be VxWorks.
- -- 
A.J. Madison                       PHONE: (703) 342-6700 X383
FiberCom, Inc.                       FAX: (703) 342-5961
P.O. Box 11966                  INTERNET: ajm@fibercom.com
Roanoke, VA  24022-1966             UUCP: ...!uunet!fibercom!ajm

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

Newsgroups: comp.robotics,comp.os.vxworks,sci.electronics
Subject: OR VME products
Date: Thu, 28 Jan 1993 19:18:58 GMT
From: nivek@cs.cmu.edu (Kevin Dowling)
Organization: Robotics Institute, Carnegie Mellon
Message-ID: <C1KwBM.Bw0.2@cs.cmu.edu>
References: <1k6si7INNkcc@life.ai.mit.edu>
Reply-To: nivek@cs.cmu.edu
Sender: news@cs.cmu.edu (Usenet News System)

We are looking at some low power 3U VME products
('030, A/D, D/A, Enet, '332) from OR which is represented by
Dynatem in the US. We've had good experiences with other Dynatem products
(low power 6U cards) but would like to hear from others
who've had experience with the OR boards, especially those who've
used VxWorks with them.

The power specs (computational and watts)  are very good and the environmental
specs are excellent as well but it'd be nice to hear from others.

						Thanks.
							nivek

- ---

aka: Kevin Dowling			Carnegie Mellon University
tel: (412) 268-8830			The Robotics Institute
adr: nivek@ri.cmu.edu			Pittsburgh, PA 15213

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

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

From mea@sparta.com  Fri Jan 29 11:43:25 1993
From: mea@sparta.com (Mike Anderson)
Date: Fri Jan 29 11:43:52 PST 1993
Subject: West coast User's Group Meeting w/ BUSCON?
Greetings!

  I just wanted to know if there was going to be a west coast User's Group
meeting in conjunction with BUSCON?  If so, where and when?  Do you need
presentations?  Demos? If the responsible parties could post something to
the net, I'd be most interested in find out the sitch.

Later,

==============================================================================
    AAAA  D D    D D    EEEEE   M   M  TM  // AAAA RRRR  TTTTTT SSSSS EEEEE R
   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, Information Systems Office  FAX:   (703) 734-3323
SPARTA, Inc.                          EMAIL: mea@sparta.com
Suite 900                     
7926 Jones Branch Drive        "It is useless for sheep to pass resolutions 
McLean, VA  22102               in favor of vegetarianism while wolves remain
                                of a different opinion."

                                   William R. Inge, D.D.
==============================================================================

From baumann@proton.llumc.edu  Fri Jan 29 11:45:05 1993
From: baumann@proton.llumc.edu (Michael Baumann)
Date: Fri Jan 29 11:45:23 PST 1993
Subject: G++ Cross compiler
We are now in the mode of developing code on a MVME167 and would like to
continue to use G++. We are currently using a g++ built on gcc/g++ 1.40
I would like to use one based on gcc 2.3.3. This would cross-compile from
a SS2 to the 167.  

Has anyone gone to the pains of building such, and if so please talk to me.

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

From zander@luke.atdiv.lanl.gov  Fri Jan 29 13:42:51 1993
From: zander@luke.atdiv.lanl.gov (Mark Zander)
Date: Fri Jan 29 13:42:58 PST 1993
Subject: Re: G++ Cross compiler
> Michael Baumann writes:

> We are now in the mode of developing code on a MVME167 and would like to
> continue to use G++. We are currently using a g++ built on gcc/g++ 1.40
> I would like to use one based on gcc 2.3.3. This would cross-compile from
> a SS2 to the 167.  
> 
> Has anyone gone to the pains of building such, and if so please talk to me.

I'm currently developing code in C++ and running it on the sun.  The
target environment is vxworks however so we are interested in C++
on a 167 as well.

From daemon@vxw.ee.lbl.gov  Sat Jan 30 04:00:27 1993
From: daemon@vxw.ee.lbl.gov
Date: Sat Jan 30 04:00:38 PST 1993
Subject: comp.os.vxworks newsdigest
Comp.Os.Vxworks Daily Digest    Sat Jan 30 04:00:18 PST 1993

        Subject: X.25 or HDLC driver wanted
        Subject: scsi driver needed
        Subject: Re: West coast User's Group Meeting w/ BUSCON?
        Subject: Need the FAQ for comp.os.vxworks

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

Newsgroups: comp.os.vxworks
Subject: X.25 or HDLC driver wanted
Date: Fri, 29 Jan 1993 15:43:09 GMT
From: an7499@anon.penet.fi
Organization: Anonymous contact service
Message-ID: <1993Jan29.160404.29731@fuug.fi>
Sender: anon@fuug.fi (The Anon Administrator)

Does anyone have the source code for an X.25 or HDLC driver
under vxworks? The particular target is unimportant, since
I would have to customize it anyway for what I'm doing. My
main interest is getting the logic that performs the HDLC
LAPB protocol.
- -------------------------------------------------------------------------
To find out more about the anon service, send mail to help@anon.penet.fi.
Due to the double-blind system, any replies to this message will be anonymized,
and an anonymous id will be allocated automatically. You have been warned.

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

Newsgroups: comp.sys.m68k,comp.sys.m88k,comp.realtime,comp.os.vxworks
Subject: scsi driver needed
Date: Fri, 29 Jan 1993 20:09:50 GMT
From: wybo@adi.com (Dave Wybo)
Organization: Applied Dynamics
Message-ID: <1993Jan29.200950.22529@adi.com>
Sender: news@adi.com

I am looking for some SCSI code to handle the NCR 53C710 or 53C720 SCSI chip.
If anyone has information regarding the availabliity of a driver for this chip,
I would really appreciate hearing from you.  Thanks in advance.
- -- 
- --
Dave Wybo  ADI, 3800 Stone School Rd. Ann Arbor, MI 48108
(313) 973-1300  Reachable at: wybo@adi.com
- --

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

Newsgroups: comp.os.vxworks
Subject: Re: West coast User's Group Meeting w/ BUSCON?
Date: 29 Jan 93 23:25:31 GMT
From: sjk@strl.labs.tek.com (Steven King)
Organization: Software Technology Research Lab, Tektronix, Inc.
Message-ID: <5115@crl.LABS.TEK.COM>
References: <9301291835.AA01185@borg>
Followup-To: comp.os.vxworks
Reply-To: sjk@strl.labs.tek.com (Steven King)
Sender: news@crl.LABS.TEK.COM

In article <9301291835.AA01185@borg>, mea@sparta.com (Mike Anderson) writes:
|> Greetings!
|> 
|>   I just wanted to know if there was going to be a west coast User's Group
|> meeting in conjunction with BUSCON?  If so, where and when?  Do you need
|> presentations?  Demos? If the responsible parties could post something to
|> the net, I'd be most interested in find out the sitch.

As chairperson of the 1993 West Coast UG, my official answer is "I don't know!"
I am in contact with the appropriate folks at Wind River, and we should be
announcing times and dates within the month.  (The 1992 UG meeting was held 
on April 10th, and I anticipate a similar timeframe for 1993.)

I would appreciate the following input from the VxWorks community:

o Did you like the format of the 1992 meeting?  What would you like
  to see more of?  Less of?  Different?

o Would workshops covering specific topics be of interest?  Subjects such 
  as "Using VxWorks 5.1 MMU capabilities", "Using C++ with VxWorks" or
  "Development with MicroWorks" are possibilities.

o Would people like to see demos of 3rd party products?  Stethoscope,
  ARTSE and others come to mind.  Would this be a trade-show format or
  tutorial format?

o Would people like more talks on specific applications?  "How I solved
  this problem..." stories?

o Would a 1 1/2 day or 2 day meeting be acceptable?  Do you prefer the
  one day format?  Would a one day meeting with 1/2 day of optional 
  workshops be workable?

o I would like to find a new chairperson for 1994.  If you have the
  slightest interest, please give me a call to discuss the task.  It's not
  much work, since people at Wind River make most of the arrangements.  You
  simply show up and get sweaty palms talking in front of a large audience
  (JUST KIDDING - REALLY).  Think about it.

For those who can't remember the 1992 meeting (?) or did not attend, the 
agenda was roughly as follows:

7:30 - 8:30	Breakfast
8:30 - 8:35	Welcome
8:35 - 9:00	Wind River Systems Update	- Jerry Fiddler
9:00 - 9:30	VxWorks Update			- Tony Barbagallo
9:30 - 10:30	WRS Technology 			- David Wilner
10:30 - 10:45	BREAK
10:45 - 11:00	WRS Customer Services 		- Francis St. Amant
11:00 - 11:45	POSIX Presentation 		- David Wilner
11:45 - 1:00	Lunch
1:00 - 3:15	Applications Presentation
		- Mike Trest, Visicom
		- Stan Schnieder, RTI
		- Steve Allen, Busware
		- Andrew Pearce, MBARI
		- Brett Goodrich, National Solar Observatory
		- Curt Kuhn, SPARTA
		- Todd Brackett, Interferometrics
3:15 - 3:30	Break
3:30 - 4:15	Birds of a Feather
		- C++, Scott Herzinger
		- BSP Porting Kit, Nigel Standing
		- POSIX/Kernel/5.1, David Wilner
		- Stethoscope, Todd Brackett
4:15 - 4:30	Futures Discussion, Closing Remarks

At this point I want your input into the format and content.  This is our
meeting, so I anticipate change and growth over time.  While I can't make
specific promises at this point, I would like to tailor the meeting to
your needs and the availability of Wind River personnel as much as possible.

I look forward to your response!

Steven

- -------------------------------------------------------------------------
e-mail: sjk@strl.labs.tek.com      |  Steven King
phone: 503-627-2736                |  Software Technology Research Lab
voice mail: 503-727-6651           |  Tektronix, Inc.
fax: 503-627-5502                  |  P.O. Box 500   MS 50-662
			           |  Beaverton, OR  97077
- -------------------------------------------------------------------------
"Sometimes if you have a cappuccino and then try again it will work OK."
(Dr. Brian Reid)  "Sometimes one cappuccino isn't enough." (Marcus Ranum)
"A double vanilla latte always works."  (Me)

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

Newsgroups: comp.os.vxworks
Subject: Need the FAQ for comp.os.vxworks
Date: 29 Jan 93 16:42:45 GMT
From: krishna@csgrad.cs.vt.edu (Krishna Ganugapati)
Organization: VPI&SU Computer Science Department, Blacksburg, VA
Message-ID: <4092@creatures.cs.vt.edu>
Sender: usenet@creatures.cs.vt.edu

Greetings,

Is there an FAQ for this newsgroup and could somebody
tell me how I could get it ?

Thanks very much

Krishna Ganugapati
(krishna@csgrad.cs.vt.edu)

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

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

From thor@thor.atd.ucar.edu  Sun Jan 31 03:17:41 1993
From: thor@thor.atd.ucar.edu (Richard Neitzel)
Date: Sun Jan 31 03:17:53 PST 1993
Subject: Monthly VxWorks archive posting
This is the monthly posting showing the current holdings in the VxWorks
Software Archive. To get more detailed infomation send email to:

vxworks_archive@ncar.ucar.edu

The message body must read:

send index
send index from vx
send index from unix
------------------------------------------------
VxWorks sources:

total 2091
-rw-r--r--  1 thor        22132 Jun 18  1990 ansi.p1
-rw-r--r--  1 thor        22717 Jun 18  1990 ansi.p2
-rw-r--r--  1 thor        24174 Jun 18  1990 ansi.p3
-rw-r--r--  1 thor         8108 Jun 18  1990 ansi.patch1
-rw-r--r--  1 thor        37126 Jun 12  1992 ansilib01
-rw-r--r--  1 thor        18913 Jun 12  1992 ansilib02
-rw-r--r--  1 thor         2671 Jan  2  1990 benchmarks
-rw-r--r--  1 thor         7168 Jul 13  1989 bitcnt
-rw-r--r--  1 thor        11437 Feb 15  1991 c++builtin.shar
-rw-r--r--  1 thor        22330 Apr  4  1990 c++headers.p1
-rw-r--r--  1 thor        22775 Apr  4  1990 c++headers.p2
-rw-r--r--  1 thor        29052 Dec  6  1989 camaclib1
-rw-r--r--  1 thor        25095 Dec  6  1989 camaclib2
-rw-r--r--  1 thor        31005 Dec  6  1989 camaclib3
-rw-r--r--  1 thor        37770 Dec 21  1989 cbench.shar
-rw-r--r--  1 thor         7371 Jun 15  1990 cntsem_class.shar
-rw-r--r--  1 thor         5853 May 31  1989 crc.shar
-rw-r--r--  1 thor         8917 Oct  9  1990 deadman.shar
-rw-r--r--  1 thor        41669 Dec  6  1991 dhrystones01
-rw-r--r--  1 thor        25681 Aug 29  1989 dt1451
-rw-r--r--  1 thor         5944 Apr 26  1989 fcompress.shar
-rw-r--r--  1 thor        11561 Nov  1  1991 flags_class.shar
-rw-r--r--  1 thor        44762 Jul 18  1990 force.p1
-rw-r--r--  1 thor        40154 Jul 18  1990 force.p2
-rw-r--r--  1 thor        80491 May  8  1989 force.shar
-rw-r--r--  1 thor         6106 Oct 10  1989 getdate
-rw-r--r--  1 thor         9774 Nov  2  1990 hkv30extintutil.shar
-rw-r--r--  1 thor        10049 Dec  2 08:45 index
-rw-r--r--  1 thor         2694 Oct  9  1990 ivecalloc.shar
-rw-r--r--  1 thor        35245 Oct  9  1990 joblib2.p1
-rw-r--r--  1 thor        18110 Oct  9  1990 joblib2.p2
-rw-r--r--  1 thor         9079 Apr  2  1990 lclflag.shar
drwxr-xr-x  2 thor          512 Oct 31  1990 libX11
lrwxrwxrwx  1 root            6 Aug 14  1991 libx11 -> libX11
-rw-r--r--  1 thor        25077 Oct  9  1990 loadmeter.shar
-rw-r--r--  1 thor        10399 May  4  1989 math.shar
-rw-r--r--  1 thor        11950 May 30  1989 math2
-rw-r--r--  1 ftp         26655 Nov 15  1990 monitor.shar
-rw-r--r--  1 thor        18733 Jun 14  1990 msgque_class.shar
-rw-r--r--  1 thor        41667 Feb  5  1992 ntpvx01
-rw-r--r--  1 thor        38524 Feb  5  1992 ntpvx02
-rw-r--r--  1 thor        41997 Feb  5  1992 ntpvx03
-rw-r--r--  1 thor        39218 Feb  5  1992 ntpvx04
-rw-r--r--  1 thor        39625 Feb  5  1992 ntpvx05
-rw-r--r--  1 thor        28741 Feb  5  1992 ntpvx06
-rw-r--r--  1 thor        32516 Feb  5  1992 ntpvx07
-rw-r--r--  1 thor        37119 Feb  5  1992 ntpvx08
-rw-r--r--  1 thor        41643 Feb  5  1992 ntpvx09
-rw-r--r--  1 thor        19593 Oct 27 07:47 ping01
-rw-r--r--  1 thor        20494 Oct 31  1991 pipe.shar
-rw-r--r--  1 thor        15418 May 30  1989 poolLib
lrwxrwxrwx  1 root            7 Aug 14  1991 poollib -> poolLib
-rw-r--r--  1 thor        13204 Oct 31  1991 ring.shar
-rw-r--r--  1 thor         6614 May 31  1989 semCnt
lrwxrwxrwx  1 root            6 Aug 14  1991 semcnt -> semCnt
-rw-r--r--  1 thor         2308 Jan  2  1990 ss1.bnch
-rw-r--r--  1 thor        41196 Oct 16 09:43 stevie01
-rw-r--r--  1 thor        35279 Oct 16 09:43 stevie02
-rw-r--r--  1 thor        35278 Oct 16 09:43 stevie03
-rw-r--r--  1 thor        35012 Oct 16 09:43 stevie04
-rw-r--r--  1 thor        34502 Oct 16 09:43 stevie05
-rw-r--r--  1 thor        37476 Oct 16 09:43 stevie06
-rw-r--r--  1 thor        30073 Oct 16 09:43 stevie07
-rw-r--r--  1 thor        31562 Oct 16 09:43 stevie08
-rw-r--r--  1 thor        37360 Oct 16 09:43 stevie09
-rw-r--r--  1 thor        20662 Oct 16 09:43 stevie10
-rw-r--r--  1 thor        25717 Oct 16 09:43 stevie11
-rw-r--r--  1 thor        28075 Oct 16 09:43 stevie12
-rw-r--r--  1 thor        31852 Oct 16 09:43 stevie13
-rw-r--r--  1 thor        16225 Oct 10  1989 string.shar
-rw-r--r--  1 thor         8424 Apr  1  1992 syslog.shar
-rw-r--r--  1 thor        15096 Oct  2  1991 task_class.shar
-rw-r--r--  1 thor        16171 Oct  9  1990 taskmon.shar
-rw-r--r--  1 thor        10523 May 31  1989 tod.shar
-rw-r--r--  1 thor        19912 Aug 27 13:52 tp41.shar
-rw-r--r--  1 thor        25790 Nov  8  1990 ty335.shar
-rw-r--r--  1 thor         5608 Dec  2 08:43 veclist01
-rw-r--r--  1 thor        25814 Apr 26  1989 vtape.shar
-rw-r--r--  1 thor        43671 Nov 22  1991 vwcurses01
-rw-r--r--  1 thor        40180 Nov 22  1991 vwcurses02
-rw-r--r--  1 thor        38308 Nov 22  1991 vwcurses03
-rw-r--r--  1 thor        31181 Nov 22  1991 vwcurses04
-rw-r--r--  1 thor        31798 Nov 22  1991 vwcurses05
-rw-r--r--  1 thor        31459 Nov 22  1991 vwcurses06
-rw-r--r--  1 thor        24279 Nov 22  1991 vwcurses07
-rw-r--r--  1 thor         4636 Feb  4  1992 vx_cplusplus
-rw-r--r--  1 thor        29720 Aug 28  1991 vxrsh.p1
-rw-r--r--  1 thor        26002 Aug 28  1991 vxrsh.p2
-rw-r--r--  1 thor        13713 Aug 28  1991 vxrsh.p3
-rw-r--r--  1 thor         4702 Jan 16  1992 wdog_class
-rw-r--r--  1 thor         5070 Dec  2 08:45 xxx
Unix sources:

total 82
-rw-r--r--  1 thor         1192 Mar 13  1990 index
drwxr-xr-x  2 thor          512 Mar 17  1992 patch
-r--r--r--  1 thor        11744 Apr 11  1989 shar.shar
-rw-r--r--  1 thor        19698 Nov 15  1989 vxtool
-rw-r--r--  1 thor        21934 Jan 31  1990 vxview
-rw-r--r--  1 thor        14151 Feb  9  1990 vxview.patch
-r--r--r--  1 thor         9869 Feb  1  1989 xc.shar
drwxr-xr-x  2 thor          512 Feb 11  1990 xdbx

From mitchell@aaec1.aaec.com  Sun Jan 31 11:23:10 1993
From: mitchell@aaec1.aaec.com
Date: Sun Jan 31 11:23:19 PST 1993
Subject: Re: Backplane Net to SPARC/UNIX

Several weeks ago I posted a question about using the backplane driver to
link a vxWorks VME board to a SPARC via a s-bus to VME adapter made by
BIT-3.  Here's a good summary posted by Alan Biocca, followed by what else
I found.

>From: biocca@csg.lbl.gov (Alan K Biocca)
>Backplane drivers for workstations have been an ongoing problem.  I have
>observed folks who have had significant difficulty with them.
>
>The backplane driver is being supplanted by the shared memory driver, and
>will likely eventually be phased out.  Each new release of workstation OS
>is likely to disrupt the backplane driver.
>
>I'd recommend choosing an architecture that didn't require the backplane net
>on a workstation - WRS has had difficulty supporting that interface in a 
>timely manner.  Use the network to boot from, and then share the data over
>the backplane bus with your own shared memory code.  Thus you will not have to
>deal with backplane net problems on the sun, and you can keep the application
>specific problems within your own control.
>
>Alan K Biocca
>

WRS says its Unix driver has only been tested with CPU's with integral VME
interfaces (assume its a sparc-engine-1e or -2e).  They said it could be
possible to license the source code and port it to an s-bus to VME adapter,
but noted that it seemed like a great undertaking.

A few years ago we tried to get a sun-3e (now discontinued 6U '020 CPU) to
use bp net, but I don't  think it ever worked (those who tried it are long
gone).  

BIT3 says they have heard of someone using their VME-VME link with the UNIX
VME boards, but not s-bus to VME.

Our problem will be solved by using ethernet.  We thought this would be a
problem since another part of the system was using ray ethernet packets for
command and control.  We originally did not want these to get onto a the
"regular" ethernet, but now we think it will be OK.  One of the other
contractors involved with this project is trying to track down a safe
ether-packet type.  Both the UNIX and vxWorks ignore unkown packet types
quite well.  Out backup to this solution is to boot from EEPROM and use
SLIP for networking.  The vxWorks and UNIX applications will talk over the
BIT-3 via our own ring buffer routines, along what Alan suggested.