HDTenEightyP/NetNews huggingface dataset:
From: baumann@proton.llumc.edu (Michael Baumann)
Newsgroups: comp.os.vxworks
Subject: re:  RPC's
Date: Fri, 8 Jan 93 07:54:41 PST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


>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|
Newsgroups: comp.os.vxworks
From: hjb@netcom.com (H. J. Bae)
Subject: Re: Forwarding of MAC broadcasts
Organization: Peaceful Star, Inc.
Date: Sat, 9 Jan 1993 09:38:18 GMT

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
From: thoff@netxwest.com (Todd Hoff)
Newsgroups: comp.os.vxworks
Subject: More on broadcast problem
Date: 8 Jan 93 18:57:24 GMT
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

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.
Newsgroups: comp.os.vxworks
From: geoff@wrs.com (Geoff Espin)
Subject: Re: RPC's
Organization: Wind River Systems, Inc.
Date: Thu, 7 Jan 1993 16:26:15 GMT

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
From: Roeber <fjr@ssd.ray.com>
Newsgroups: comp.os.vxworks
Subject: re:  performance of fprintf() for floating point
Date: Tue, 12 Jan 1993 08:58:24 -0500
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

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                     |
   |_______________________________________________________|


Xref: sparky comp.os.vxworks:1169 comp.arch.bus.vmebus:126
From: meindert@inducom.nl (Meindert Kuipers)
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
Followup-To: comp.os.vxworks
Organization: Inducom Systems BV, Oss, Netherlands

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.arch.bus.vmebus
From: mcgehee@noao.edu (Peregrine McGehee)
Subject: VME based controllers and drivers for other buses?
Organization: National Optical Astronomy Observatories, Tucson AZ
Date: Tue, 5 Jan 1993 15:57:50 GMT

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
From: Mike Trest <trest@visicom.com>
Newsgroups: comp.os.vxworks
Subject: re: database for VxWorks
Date: Wed, 6 Jan 93 7:43:34 PST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


>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: gordon@tpocc.gsfc.nasa.gov (Gordon Miller)
Newsgroups: comp.os.vxworks
Subject: re:  RPC's
Date: Fri, 8 Jan 93 07:51:27 EST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov


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: billb%kuwait@sun.com (Bill Baumann)
Newsgroups: comp.os.vxworks
Subject: Forwarding of MAC broadcasts
Date: Thu, 7 Jan 93 13:38:59 CST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

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: jprice@lds.loral.com (Jeffrey Price)
Newsgroups: comp.os.vxworks
Subject: text editor for VxWorks ?
Keywords: editor vi text edit
Date: 7 Jan 93 18:09:59 GMT
Reply-To: jprice@lds.loral.com
Organization: Loral Data Systems


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
Xref: sparky comp.os.vxworks:1165 comp.arch.bus.vmebus:125
From: kai@ade.no (Kai Atle Myrvang)
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
Organization: AD Elektronikk AS, Norway

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
Newsgroups: comp.os.vxworks
From: vanandel@rsf.atd.ucar.edu (Joe Van Andel)
Subject: performance of fprintf() for floating point
Organization: National Center for Atmospheric Research
Date: Mon, 11 Jan 1993 21:12:42 GMT

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
From: woody@sparta.com (Robert "Woody" Woodburn)
Newsgroups: comp.os.vxworks
Subject: peregrine 4211 driver for v3d running 5.0.2
Date: Fri, 8 Jan 93 18:30:22 EST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

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)

Newsgroups: comp.os.vxworks
From: raob@mullian.ee.mu.oz.au (r. oxbrow)
Subject: VX Works for MVME104
Organization: Electrical and Electronic - University of Melbourne 
Date: Fri, 8 Jan 1993 03:33:21 GMT


	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
From: hwajin@pogo.iphasew.com (Hwa-Jin Bae)
Newsgroups: comp.os.vxworks
Subject: Re: vxWorks Sockets and Pipes
Date: 12 Jan 93 23:27:53 GMT
Organization: Interphase West, Santa Clara, CA

>>>>> 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)
From: vxworks@mars.psf.ge.com (vx_works)
Newsgroups: comp.os.vxworks
Subject: MVME14x Diagnostics coexisting with VADSWorks
Date: Tue, 5 Jan 93 09:32:14 EST
Organization: Lawrence Berkeley Laboratory, Berkeley CA
NNTP-Posting-Host: 128.3.112.16
Originator: daemon@vxw.ee.lbl.gov

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
Newsgroups: comp.os.vxworks