Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk1.iso/answers/vxworks-faq

Text File | 1993-12-20 | 55KB | 1,528 lines

Newsgroups: comp.os.vxworks,comp.answers,news.answers
Path: senator-bedfellow.mit.edu!bloom-beacon.mit.edu!usc!elroy.jpl.nasa.gov!decwrl!netcomsv!netcom.com!hjb
From: [e-mail] (squeedy)
Subject: comp.os.vxworks Frequently Asked Questions (FAQ)
Message-ID: <[e-mail]>
Followup-To: comp.os.vxworks
Summary: This posting contains a list of Frequently Asked
         Questions (and their answers) about VxWorks REALTIME
     Operating System.  It should be read by anyone who wishes to
     post to the comp.os.vxworks newsgroup.
Keywords: vxworks,realtime,faq,kernel,tcp-ip,networking,vme,embedded
Sender: [e-mail] (squeedy)
Reply-To: [e-mail]
Organization: PEACEFUL STAR, Oakland, CA
Date: Mon, 20 Dec 1993 09:58:19 GMT
Approved: [e-mail]
Lines: 1508
Xref: senator-bedfellow.mit.edu comp.os.vxworks:2759 comp.answers:3095 news.answers:16016

Archive-name: vxworks-faq
Maintained-by: [e-mail]
Last-modified: 1993/12/20
Version: 1.1

This is the list of frequently asked questions (and their answers) for
the newsgroup comp.os.vxworks.

Where possible, pointers to existing information are included here, rather
than rehashing that information again.

If you haven't already done so, now is as good a time as any to read the
guide to Net etiquette which is posted to news.annouce.newusers regularly.
You should be familiar with acronyms like FAQ, FTP and IMHO, as well as know
about smileys, followups and when to reply by email to postings.

The FAQ is currently posted to comp.os.vxworks, news.answers and
comp.answers on the 15th of every month.  You can retrieve the latest copy
of this FAQ via anonymous FTP from rtfm.mit.edu in the directory
/pub/usenet-by-group/comp.os.vxworks.  Remember to use ASCII mode
when transferring.

This FAQ was compiled by [e-mail] using comments by readers of
comp.os.vxworks as well as his own limited knowledge of VxWorks.  Credits
appear at the end.  Comments and indications of doubt are enclosed in []s in
the text.  Each section begins with dashes ("-") on a line of their own,
then the section number.  This should make searching for a specific section
easy.

This FAQ is also available via anonymous ftp in:

    netcom.com:pub/hjb/vxfaq.Z

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

        TABLE OF CONTENTS

    1. What is VxWorks?
    2. Brief History of VxWorks
    3. What are some of the major features of VxWorks?
    4. What are the Latest versions of VxWorks?
    5. Where is the archive site for user-contributed code?
    6. What application notes are available from Wind River?
    7. How can I join the VxWorks user's group?
    8. Is comp.os.vxworks also available via a mailing list?
    9. Can I use gcc or g++ with VxWorks?
    10. Other C/C++ Compiler tools for VxWorks?
    11. Which cross-debuggers can I use with VxWorks?
    12. What are differences between UNIX and VxWorks?
    13. What are the performance/benchmark numbers for WIND kernel?
    14. What are the performance/benchmark numbers for VxWorks TCP/IP?
    15. What is the VxSim VxWorks Simulator?
    16. Can I use one boot EPROM for multiple boards on the same net?
    17. What's the deal with 68881 FPU code in interrupt handlers?
    18. Why does ls() not work on netDrv devices?
    19. Why can't I do ".." at top level directories or NFS mount points?
    20. Why do I have trouble using relative symbolic links with NFS?
    21. X for VxWorks
    22. IEEE-488 (GPIB) driver for VxWorks
    23. How does one disable NFS client caching?
    24. Why doing a lot of slipInit()/slipDelete() cause routing
        table corruption?
    25. How does one get better network I/O performance?
    26. How does one troubleshoot a backplane driver malfunction?
    27. How do I add select support to my driver?
    28. bind() gets EADDRINUSE, how do I fix it?
    29. Common errors in interrupt handlers with floating point
        co-proc hardware
    30. Finding entry point of a given module using its name
    31. The problem with irint() in earlier (5.0.2 ?) releases
    32. What are +T, +I thingies in the "i" output?
    33. Gotchas w.r.t watchdogs
    34. Is it possible to delete a memory partition in VxWorks?
    35. rename() does not work in netDrv and nfsDrv filesystems, why?
    36. Free NFS Server for VxWorks
    37. Free SNMP for VxWorks
    38. What third party products are available for VxWorks?
    39. What kind of products have been developed using VxWorks?
    40. A complete list of CPU hardware supported by VxWorks
    41. A complete list of peripheral devices supported by VxWorks
    42. What's with these unbundled "accessories"?
    43. How come my 5.0.2 BSP isn't available in 5.1, damn it?
    44. How much is VxWorks?
    45. What is MicroWorks?
    46. Other Unbundled Products for VxWorks?
    47. How can I find out more about VxWorks?
    48. What other net.resources are available on real-time systems?
[new]    49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?
[new]    50. Free lex and yacc for use with VxWorks
[new]    51. timer_gettime() bug
[new]    52. bogus INCLUDE_TCP_DEBUG
[new]    53. free ppp for VxWorks
    9999. Contributions to comp.os.vxworks FAQs.

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

1. What is VxWorks?

VxWorks, from Wind River Systems, is a networked real-time operating
system designed to be used in a distributed environment.  It runs on a
wide variety of hardware, including MC680x0, MC683xx, Intel i960, Intel
i386, R3000, SPARC, Fujitsu SPARClite, and TRON Gmicro, based systems.
It requires a host workstation for program development; supported host
platforms include Sun3, Sun4, HP9000, IBM RS-6000, DEC, SGI, and MIPS.

It does not run development systems software such as compiler, linker
and editor on the target machine.  The development environment is based
on cross-development or remote-development method.  You will need a
UNIX machine of some sort (e.g. SUN's) to run the compilers and
debuggers.  The compiled application code can be downloaded to the
target and runs as part of the VxWorks image.  During the development
phase or thereafter, individual object code (.o files) can be
downloaded dynamically to running target system.  Finished applications
can be ROM'ed or whatever.

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

2. Brief History of VxWorks

Based on what I have heard from David Wilner and others, WRS was
started by Jerry Fiddler and David Wilner in Jerry's garage as a
contract/consultant shop for realtime, embedded systems and other fun
things.  Francis Coppola was one of the earlier customers.

They wrote a bunch of neat programs for their work and found that they
liked them a great deal themselves, and added more excellent features
to the system, eventually adding some things unheard of in
embedded/realtime market in those days such TCP/IP networking. And
continued to pioneer in this area by adding NFS, etc.

VxWorks was the name given the collection of software which ran on
top of various realtime kernels including VRTX and pSOS as well an
earlier slower version of WIND kernel.  [ editorial:
VxWorks no longer runs on other kernels; it now runs exclusively on
its own WIND kernel since the 5.0 release, for which the WIND was
rewritten by John Fogelin. ]

They got more people interested in the system and became successful.
And moved from a little building in Emeryville to a larger one. And
eventually to the present site in Alameda.  And hired a  lot of people.

WRS sold many many more copies of this system and continues to grow
like a real successful company.

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

3. What are some of the major features of VxWorks?

In Version 5.1:

 - wind kernel unlimited tasks
 - 256 priorities
 - binary, counting mutex semaphores
 - message q's
 - POSIX pipes
 - sockets
 - shared memory
 - profiling utilities
 - ethernet support (i596, LANCE, NIC, SONIC)
 - SLIP (no PPP yet)
 - backplane driver for network
 - rlogin (server & client)
 - telnet (server only)
 - rpc (no rpcgen)
 - nfs (client)
 - ftp (server & client)
 - tftp (client & server)
 - rsh
 - bootp
 - proxyarp
 - C-interpreter shell (incomplete but useful)
 - symbolic debugging
 - disassembly
 - performmance monitoring tools
 - exception handling
 - signal handling (not quite unix compatible)
 - dynamic object image loader
 - system symbol table
 - system info utilities
 - libraries of 600+ utility routines
 - remote source level debugger(VxGDB)
 - SCSI support
 - DOS & RT11 & Raw filesystems.
 - "full ANSI"
 - "POSIX I/O"

It is a good idea to get a copy of VxWorks manuals before purchasing
the system.  WRS can provide you with such documentation.  As far as I
know there is no "VxBook" in the bookstores.

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

4. What are the Latest versions of VxWorks?

As as of June 1993,

     5.0.3.: TRON will be discontinued.
     5.0.3 : i386
     5.0.5 : r3000
     5.1   : 680x0, 683xx, i960, SPARC
     i386 and r3000 will be upgraded to 5.1.

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

5. Where is the archive site for user-contributed code?

The VxWorks archive system is available for FTP as thor.atd.ucar.edu.
It is also accessible via email server at [e-mail].
Questions should be directed to its maintainer, Richard Neitzel
<[e-mail]>.

To get more detailed infomation send email to:

[e-mail]

The message body must read:

send index
send index from vx
send index from unix

A summary of the archives is periodically posted to comp.os.vxworks.

Some of the usual titles available:

ansi, ansilib, benchmarks, bitcnt, c++builtin, c++headers, camaclib, cbench
cntsem_class, crc, deadman, dhrystones, dirlib, dt1451, fcompress
flags_class, force, gcc+68040, getdate, hkv30extintutil, ivecalloc, joblib2
lclflag, libX11, loadmeter, math, monitor, msgque_class, ntpvx, ping, pipe
poolLib, ring, semCnt, ss1, stevie, string, syslog, task_class, taskmon, tod
tp41, ty335, veclist, vtape, vwcurses, vx_cplusplus, vxrsh, wdog_class, shar
vxtool, vxview, xc

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

6. What application notes are available from Wind River?

  List of Wind Technical Notes

 Motorola MV147 Slave Base Control       9-1
 System hang during lkup( ) output       10-1
 Reserving Memory                        11-1
 Serial IO Vanishing                     13-1
 NFS: problems with writing files        14-1
 Which interrupts does VxWorks use?      15-1
 Debugging ftp problems                  18-1
 Interrupt handlers, floating point      19-1
 Booting From a Memory Board             22-1
 Changing Network Interfaces             23-1
 Writing Non-buffered Sockets            24-1
 RPC and VxWorks                         25-1
 Using SCSI devices with VxWorks 5.x     26-1
 The Select Facility in VxWorks          28-1
        Using on-board Serial Ports  29-1
        Problems with ls()   30-1
 SCSI     31-1
 Trouble Shooting Booting Problems       32-1

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

7. How can I join the VxWorks user's group?

For User Group info contact WRS or Eric Rabinowitz of Panoramic Systems at:

 [e-mail]   or  [e-mail]
 phone: [phone]

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

8. Is comp.os.vxworks also available via a mailing list?

Lawrence Berkeley Labs maintains an automated mailing list which is
bi-directionally gatewayed to comp.os.vxworks

It is called the 'VxWorks Exploder'.

Mail to [e-mail] is automatically mailed to a number
of sites, including Wind River.

Send subscription request to [e-mail].

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

9. Can I use gcc or g++ with VxWorks?

WRS's gcc GNU Toolkit distribution can be reshipped in its entirety.
WRS charges are for media and support, so obviously copies thereof
don't matter to them.

Lots of customers use g++ as provided by the "net" --
see the VxWorks Archive information below.

You can get a generic freely distributable GCC/G++ and compile your
code for VxWorks.  Or you can just get a copy from someone who has a
working GCC cross-development setup from WRS.

WRS worked with Cygnus to polish up their release of GCC but a generic
GCC distribution works just fine as well.

For MC68K targets:
 You can also use native SunOS 4.X cc running on Sun-3's.
 You can also use various other free m68k C compilers
 such as lcc, sozobon, etc. provided that you're willing
 to hack on them.

Richard Neitzel ([e-mail]) writes,

Thanks to some feedback I've corrected the archive instructions on how to
build gcc, libgcc and libg++ for VxWorks. To make my life simpler the
patches referenced are no longer included in the vx_cplusplus file. Instead
there are now seperate patch files for the effected parts:

libg++-2.5-src.patch: Patches libg++/src.
libgcc2-2.5.0.patch: Patch libgccc2.c for gcc-2.5.0.
libgcc2-2.5.2.patch: Patch libgcc2.c for gcc-2.5.2.
libio-2.5.patch: Patch the stream library.

See VxWorks Archive information in this FAQ for details on how to
get these files.

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

10. Other C/C++ Compiler tools for VxWorks?

WRS re-sells (re-engineered?) CenterLine cfront product and WindC++
Gateway for CenterLine ObjectCenter. They come with browsers, etc.
Not free.

Wind C++ Gateway for ObjectCenter sold by WRS:

$995 / user 1-4 copies
$875 / user 5-9 copies

Note that this is the cost over and above ObjectCenter.

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

11. Which cross-debuggers can I use with VxWorks?

GDB & other more expensive tools from WRS, MicroTec Research, etc.

WRS sells a lightly modified version of xxgdb which has a lousy GUI
interface.  In 5.1 xvxgdb may have been slightly improved -- but the
ObjectCenter C++ with VxWorks solution provides better GUI interface.

With a little bit of hacking, regular GDB works just fine.  Personally,
I find GUI to a debugger gets in the way of real work.  I use GNU Emacs
GDB interface which works well and can be easily customized.

There might be some old VxWorks customers that also use VxWorks-aware
dbxtool on Sun machines.  This used to be maintained and sold by SUN
Consulting.

If you're only interested in debugging your "application" on VxWorks,
the vxgdb approach (using RPC) works just fine.

If you are rather more interested in the guts of the system as well as
your application you might want to spend some time building
cross-debugging tools from generic GDB distribution into VxWorks.

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

12. What are differences between UNIX and VxWorks?

They're both a hack.  UNIX has a larger installed base. :-)

Seriously though, similarities end there, IMHO.  VxWorks does have a lot of
UNIX "compatible" routines in the user libraries.  So porting a UNIX
application is not that hard.  But there are enough differences to make such
a port take longer than normally expected.

For one thing, UNIX definitely is not realtime, whatever that means.
[ editorial: To me personally, what realtime means is this -- when there
is a spinning process or task running like crazy doing some stuff
busily, I still want my system to respond immediately when I type a
character on my console keyboard.  VxWorks, and other real realtime
OS'es, do this.  UNIX and MS-DOG don't. ]

VxWorks in its original form does not have any memory protection support.
It runs in one mode.  No protected vs. user mode switching is done.  Running
in supervisor mode on most processors, and not using traps for system calls,
VxWorks can achieve minimal overhead on a given piece of hardware than
UNIX.  Programming on VxWorks can be more tricky than UNIX for the same
reason.

UNIX provides resource reclamation; by default, VxWorks does not.
[ editorial: using deleteHooks or whatever, you could implement
this on your own.]  Instead programmers write what they need as
needed.  As a result, the context switch time in VxWorks is on the
order of a few micro-seconds (since there is a lot smaller context to
save and restore). VxWorks does not have full "process";
it only has tasks, or "threads", or light weight processes as some people
like to call them.

Like any other multi-threaded environments (or SMP environments), care
should be taken when writing multi-tasking code.  Each routine should be
written carefully to be re-entrant (if it is going to be called from
multiple contexts), semaphores are used a lot for this. And static variables
are frowned upon.  Sometimes, when porting a UNIX application, you may need
to add "task variables" for this reason (as done for rpcLib in VxWorks).

VxWorks: minimal interrupt latency (e.g. spl's are quasi-implemented as
semaphores).  UNIX: ridiculous interrupt latency (e.g. spl's are implemented
as interrupt lock and unlock calls!).

VxWorks: priority preemption, optional round-robin time-slicing.
Traditional UNIX: prioritized round-robin time-slicing.
Since VxWorks is just a glorified "program" it can be
changed and customized pretty easily.  Task scheduling can
be customized as desired, for example.  Most people prefer priority based
preemption in the realtime world.  UNIX prefers "fair-share time-slicing".

VxWorks networking code, however, is very UNIX compatible [editorial:
it is essentially "ported" version of BSD UNIX TCP/IP code -- tahoe
release ].  It is relatively easy to port socket based code to
VxWorks.  [ editorial: except the not-so-compatible hostLib routines, etc.]

VxWorks most definitely is not a "realtime UNIX", or a varient of UNIX as
often misunderstood by some people.  The confusion perhaps is due to the
fact that UNIX hosts are used most widely to develop applications for
VxWorks (and VxWorks itself).  [ editorial: Realtime UNIX sounds kind of like
Military Intelligence to me. (can you say, oxymoron?) ;-) ]

There are a lot more differences!  In short, UNIX is a nice system to run
emacs on.  VxWorks is much better at playing pin-ball game machines.

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

13. What are the performance/benchmark numbers for WIND kernel?

A WRS VxWorks 5.1 Benchmark Report hot off the press:

Benchmark numbers based on: mv167-25Mhz, 5.1

                                Cache    Cache
Key Measurements                        Enabled    Disabled

Raw Context Switch Time                 4 us    14 us
Cyclic Test Time                        172 us  638 us
Suspend/Switch/Resume/Switch                23 us   86 us

Kernel Timings

Task Related
taskSpawn                           124 us  370 us
taskInit                            58 us   181 us
taskActivate                        12 us   33 us
taskDelete                          101 us  303 us
Task Create / Delete                    249 us  684 us
taskLock
        CASE 1: no lock                 3 us    4 us
        CASE 2: lock exists                 2 us    5 us
taskUnlock
        CASE 1: no lock                 2 us    12 us
        CASE 2: lock exists                 5 us    6 us
taskSuspend
        CASE 1: ready task                  11 us   30 us
        CASE 2: pended task                 9 us    19 us
        CASE 3: suspended task              8 us    19 us
        CASE 4: delayed task                9 us    19 us
taskResume
        CASE 1: ready task                  6 us    19 us
        CASE 2: pended task                 10 us   19 us
        CASE 3: suspended task              13 us   30 us
        CASE 4: delayed task                9 us    18 us

Semaphore Related
semBCreate                          66 us   152 us
semCCreate                          46 us   150 us
semMCreate                          45 us   139 us
semDelete
        Binary                      49 us   157 us
        Counting                        49 us   163 us
        Mutual Exclusion                    48 us   157 us
semGive
        CASE 1: tasks in queue
        Binary                      18 us   44 us
        Counting                        20 us   46 us
        Mutual Exclusion                    25 us   59 us
        CASE 2: no tasks in queue
        Binary                      4 us    8 us
        Counting                        5 us    11 us
        Mutual Exclusion                    6 us    15 us

semTake
CASE 1: semaphore available
        Binary                      4 us    9 us
        Counting                        5 us    11 us
        Mutual Exclusion                    5 us    13 us
        CASE 2: semaphore unavailable
        Binary                      10 us   25 us
        Counting                        11 us   27 us
        Mutual Exclusion                    4 us    12 us
Semaphore Give / Take
        Binary                      7 us    15 us
        Counting                        9 us    21 us
        Mutual Exclusion                    10 us   26 us
semFlush
        Binary                      11 us   20 us
        Counting                        11 us   20 us
        Mutual Exclusion                    10 us   16 us

Miscellaneous Operating System Timings

Message Queue Related
msgQCreate                          93 us   280 us
msgQDelete                          71 us   229 us
msgQSend
        CASE 1: task pending                39 us   102 us
        CASE 2: no tasks pending                23 us   64 us
        CASE 3: queue full                  14 us   45 us
msgQReceive
        CASE 1: message available               20 us   62 us
        CASE 2: message unavailable             15 us   41 us

Memory Related
malloc                          28 us   81 us
free                                32 us   104 us

Watchdog Related
wdCreate                            42 us   106 us
wdDelete
        CASE 1: timer started               48 us   160 us
        CASE 2: timer not started               44 us   150 us
wdStart
        CASE 1: timer in queue              20 us   70 us
        CASE 2: no timer in queue               18 us   55 us
wdCancel                            11 us   34 us

Floating-Point
robot application                       18 sec  51 sec

[ editorial:
If you're anal enough to count pico-seconds in comparing realtime
kernels, you  might want to actually get each of the evaluation copies
from various vendors and test them yourself.  But remember benchmarks
are misleading and almost always biased and inaccurate.  Given similar
benchmark numbers, give or take a few microseconds, etc., your dollars
are better spent in getting something you'll enjoy using. ]

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

14. What are the performance/benchmark numbers for VxWorks TCP/IP?

According to WRS, using VxWorks 5.1 on mv167-25mhz (i82596 ethernet)

                 w/ cache      w/o cache enabled
 TCP/IP Throughput (KB/sec)      859 KB/sec      682 KB/sec

No numbers available on latency.

Using a reasonably fast processor 25Mhz MC68040 and a reasonably well
made ethernet chip like SONIC or LANCE put together on a reasonable board
design will achieve TCP throughput close to full bandwidth of ethernet.

[ editorial:
This, of course, is rather slow in comparison with other fast
implementations, since a 16Mhz MC68020 with onboard LANCE
or a PeeCee with an ethernet board can easily do the same.
I know at least one implementation based on el-cheapo i486-50mhz/EISA/SONIC
that does: 1170KB/sec.  ]

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

15. What is the VxSim VxWorks Simulator?

Propaganda from WRS:

 It really is VxWorks running under UNIX!  So sure it
 is not realtime, although all tasks and resources interact
 in the same way -- great for prototyping "high-level" code.
 Using the simulator saves wear and tear on h/w.  It (only)
 allows sytem level debugging with native GDB.

 Portably written object code compiled for VxSim (for SunOS SPARC)
 will usually load without recompilation on a SPARC target.  And,
 BTW under 5.1 switching from one architecture to anthoer really is
 pretty painless.

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

16. Can I use one boot EPROM for multiple boards on the same net?

WRS provides EPROMs with a default bogus bootline, virtually all
boards come with non-valiatile RAM which is set as soon as the user
fills in his parameters (which include CPU #).  Therefore 1 EPROM may
be duplicated and used in all boards at a site.  If the board does not
contain nvram then ROMs have to be specially blown, unless a custom
scheme for reading some switches or something is coded to index into a
bootline table.  In 5.1 BOOTP is supported -- no more repeated EPROM
burning is necessary.

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

17. What's the deal with 68881 FPU code in interrupt handlers?

In general, FP context is optimally saved only when the scheduler
notices that the new task coming in also uses the fpu (VX_FP_TASK).
ISRs don't.  If no tasks are using the FPU then ISRs may go ahead,
unless different levels of ISRs could interrupt each other and again
cause a protocol violation.

And Stan Schneider says,

You have to set the "VX_FP_TASK" option flag when you spawn your task.  You
also need to make sure you don't use the FPU in any interrupt service
routines.  Even if your code uses no floating point, some (brain-dead)
compilers save some FPU registers at the start of all routines if there's any
floating point in the file.  That's not usually a problem if you're using the
gcc compiler (at least with the "-O" flag on).  A sure way to check is via the
dissassembler.

And Leonid Rosenboim says,

This problem is quite common, and really simple to fix, all you have to
do is make sure that all tasks that do a float operation ever, will
be spawned with the VX_FP task option set. This is the best and only
solution. Also, if you run floating operations in ISRs care must be taken,
to call fppSave() and fppRestore(). Also if you are using 5.1 on a 68040,
there is a bug in the compiler that you must work around.

And Kent Long says,

This was indeed a real problem in the context switch code in 5.0.x which
was corrected in 5.1.

In both OS versions, there is an optimization that causes the FP context
to be swapped only when the incoming task has been spawned with the
floating point (VX_FP) flag set.  In 5.0.x, the copying-in of the FP context
was done via an fppSave() call.  This created problems if a new FP
task was created after a previous FP task had been pre-empted by a non-FP
task in the middle of an instruction.  The new task ended up with a
mid-instruction context (which causes the protocol violation), and the
old swapped-out FP task ultimately ended up with its context set to IDLE
(which is equally incorrect).

In 5.1, the FP context initialization was changed so that when a task
is created, a pre-defined IDLE frame is copied into that tasks's context.
Since there is no assumption about current FP state (as with fppSave),
task creation is now decoupled from the regular switch logic.


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

18. Why does ls() not work on netDrv devices?

Because the way directory information retrieval IOCTL calls are not acompatible
between different types of "filesystems" in VxWorks.  Another reason why
some think VxWorks filesytem does not exist; they're just a collection of
ioDevice drivers, and there is not a real consistent "design" to it.

The lsOld() should work on "filesystems" that does not support ls().

Chuck Mead proposes the following special routine in case lsOld() does not
work for you:


#include "vxWorks.h"
#include "bootLib.h"

#define RSHD 514

STATUS lsHost(path)
   char  *path ;
{
   char *lsString;
   int dataSock ;
   int n ;
   char nextChar ;

   extern BOOT_PARAMS sysBootParams ;
   extern char *sysBootHost ;

   if (path == (char *) NULL)
   {
      lsString = (char *) malloc(4) ;
      strcpy(lsString, "ls") ;
   }
   else
   {
      lsString = (char *) malloc(strlen(path) + 5) ;
      sprintf(lsString, "%s%s", "ls ", path) ;
   }

   dataSock = rcmd (sysBootHost, RSHD, sysBootParams.usr,
        sysBootParams.usr, lsString, (int *) NULL) ;

   if (dataSock == ERROR)
   {
      printf("Error opening socket") ;
      return (ERROR) ;
   }

   n = fioRead(dataSock, &nextChar, 1) ;
   while (n == 1)
   {
      printf("%c",nextChar) ;
      n = fioRead(dataSock, &nextChar, 1) ;
   }

   close(dataSock) ;
}

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

19.  Why can't I do ".." at top level directories or NFS mount points?

Because, again, VxWorks does not really have a "filesystem" as most people
understand it.  The top level directories are just implemented as device
driver "node", which is used to identify the ioDev associated with the
specific VxWorks "filesystem".  Since there is no underlying filesystem
layer, the story ends there.  When you're at the top of the directory
hierarchy within a given ioDev/filesytem, you simply cannot do "..".

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

20. Why do I have trouble using relative symbolic links with NFS?

See [Q: Why can't I do ".." at top level directories or NFS mount points?]
above.  This is just another problem caused by the fact that a real filesystem
does not exist for VxWorks.  NFS client implementation actually does implement
the symbolic links correctly, using lookup and readlink.  The problem is
due to the fact that, for some relative links that use ".." or whatever, that
crosses over filesystems, VxWorks cannot have underlying subsystem that will
handle file pathname to device mapping.

Using absolute symbolic links work just fine (i.e. full path name from top).

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

21. X for VxWorks

WRS has a product called windX which supports Motif. There is also
libX11 contribution in the VxWorks Archive. This package is perhaps
fairly old and out of date. Essentially, to port X stuff to VxWorks
you'll need to do make sure code is re-entrant everywhere.  There is a
"multi-thread" safe version of Xlib available somewhere on the net, one
might try porting that.  There are also vendors that have built X servers
using VxWorks.  Jupiter Systems, in Alameda, makes high-end X server
machines based on VxWorks.  Other X terminal vendors (HP?) also use VxWorks.

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

22. IEEE-488 (GPIB) driver for VxWorks

 - National Instruments has lots of GPIB stuff
 - THEMIS computers has TSVME-409 whic hincludes a GPIB interface.
 - APLABS probably has some GPIB stuff too.

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

23. How does one disable NFS client caching?

VxWorks caches read and write requests in NFS client code.
To completely disable read and write cache, set nfsCacheSize to 0.
To just flush the write cache as needed, use nfsCacheFlush() or
FIOSYNC ioctl().

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

24. Why doing a lot of slipInit()/slipDelete() cause routing table corruption?

This is due to a bug in slipDelete() and/or if_dettach().  slipDelete()
calls if_dettach() to clean up after itself (SLIP network interface driver).
Not only is if_dettach() misspelled, it also doesn't do a complete job.
One deficiency is that it does not delete routes that are pointing to the
interface being deleted.  This is remedied via another function that deletes
all routes for a give netif device driver.  [ ifRouteDelete() ??? ]
slipDelete() does call this routine to delete routes.  Another problem is
that if_dettach() does not delete a pointer to the netif device driver
structure in the global in_ifaddr linked list.  The in_ifaddr list is
used by the network kernel code to find IP addresses of available network
interfaces, among other things.  This lack of proper cleanup turns out to
be a rather hard-to-find memory corruption problem in network code, and
usually manifests itself as routing table corruptions.

To fix this add the following routine, and call it right after calling
slipDelete:

void in_ifaddr_remove(ifp)
        struct ifnet *ifp;  /* ifp = ifunit("sl0") before slipDelete() called */
{
        struct in_ifaddr *ia, *prev_ia;

        if (!ifp)
                return;

        prev_ia = 0;

        for (ia = in_ifaddr; ia; ia = ia->ia_next) {
                if (ia->ia_ifp == ifp) {
                        if (prev_ia)
                                prev_ia->ia_next = ia->ia_next;
                        else
                                in_ifaddr = ia->ia_next;
                        return;
                }
                prev_ia = ia;
        }
}


This, along with the route cleanup, should be incorporated into if_detach().

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

25. How does one get better network I/O performance?

Most of the overhead is due to socket to network core interface overhead.
The copy that happens between the socket layer and network core code
can be avoided by using the routines in uipc_socket.c (as in BSD tahoe
release code available on various archive sites) and using mbufs directly.

You can also try using raw etherLib routines.  However, etherLib also
does copying between user application and network driver.

If you must use the socket interface (sockLib), make sure you tune the
socket level buffers sizes to optimal values using setsockopt() calls
SO_SNDBUF and SO_RCVBUF.  You might also just try changing the globals
that control the following default parameters to larger numbers (all
the way upto 48K):

 tcp_sendspace (default 4K)
 tcp_recvspace (default 4K)
 udp_sendspace (default 2K)
 udp_recvspace (default 4K)

To get around extra latency in some cases, you might turn on TCP_NODELAY
option on TCP sockets.

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

26. How does one troubleshoot a backplane driver malfunction?

There are a few rules of thumb:

 1) try the simplest case first -- use polling instead of
    bus or mailbox interrupts and software test-and-set
    instead of hardware test-and-set.  See if this
    works first.  And then try hardware test-and-set
    and then the desired mailbox or bus interrupt.

 2) use bpShow() to see what's up.  Also look for magic code
    0x1234 in share mem area being used for messages,
    and verify heartbeat is being incremented.
    At the "anchor" you should see the magic code (4 bytes)
    followed by a long word which should be incrementing (the
    heartbeat) every second.

 3) verify all memory mapping and make sure there's no
    address conflicts on the bus

 4) make sure bus controller is functioning properly.
    Some combinations of boards might not work well
    especially if your system controller board
    arbitrates the bus in one way and other boards
    expect to be arbitrated in a different way.
    Sometimes you might need to use a separate
    system controller.  Of course, also make sure
    you only have one bus master.  And that your VME
    bus strappings (BREQ, IACK daisychains) are right.

 5) call Wind River's VxWorks tech-support...

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

27. How do I add select support to my driver?

#include "selectLib.h"
...

xxx_init(...)
{
     ...
     selWakeupListInit(&xxxdev->selwakeupList);
     ...
}

xxx_ioctl(...)
{
     ...
     switch(request_type) {
     ...
     case FIOSELECT:
          selNodeAdd(&xxxdev->selwakeupList,
               (SEL_WAKEUP_NODE *)request_arg);
          if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELREAD)
               && readable_condition_is_met)
               selWakeup((SEL_WAKEUP_NODE*)request_arg);
          if ((selWakeupType((SEL_WAKEUP_NODE*)request_arg) == SELWRITE)
               && writable_condition_is_met)
               selWakeup((SEL_WAKEUP_NODE*)request_arg);
          break;
     ...
     case FIOUNSELECT:
          selNodeDelete(&xxxdev->selWakeupList,
               (SEL_WAKEUP_NODE*)request_arg);
          break;
     ...
     }
}

And, add calls to selWakeup() as appropriate in your interrupt handlers
and read/write routines as selective conditions are toggled or satisfied.

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

28. bind() gets EADDRINUSE, how do I fix it?

Fix: do setsockopt() SO_REUSEADDR

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

29. Common errors in interrupt handlers with floating point co-proc hardware

Don't forget to use:
 fppSave()
 fppRestore()

Interrupt handler encapsulation code doesn't always save fpp registers for you.

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

30. Finding entry point of a given module using its name

Example from a poster in vxworks newsgroup (who?):


 FUNCPTR  start;  /* found entry point goes here */
 UINT8    symType;
 int      tid;

 if(symFindByName(sysSymTbl,"_nlos_start",(char**)&start,&symType)==OK){
    /* taskSpawn(name,priority,options,stacksize,entryAddress,arg1,..) */

    tid = taskSpawn("nlos",TASK_PRI_NLOS,SPAWN_OPTS,STACK_SIZE_NLOS,start,
    arg1,arg2,.....);
 }

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

31. The problem with irint() in earlier (5.0.2 ?) releases

The problem:

 /* Include Files */
 #include "vxWorks.h"
 #include "math.h"

 long irint_count = 0;

 sinTest()
 {
      int sinTable;

      while(1)
      {
           sinTable = irint(sin(4./1024.*(2.*3.14))*10.);
           irint_count++;
      }
 }


 % cc68k -I/vxworks/vw/h -c sinTest.c

 -> ld < sinTest.o

 /* 0x08 Option = VX_FP_TASK within taskLib.h */
 -> taskSpawn ("sinTest", 100, 0x08, 4000, sinTest)
 /* OR without the Floating Point Option */
 -> sp sinTest

 -> irint_count

 Bus Error
 Program Counter: 0xb0ac0124
 Status Register: 0x3004
 Access Address : 0xb0ac0120
 Special Status : 0x01e6
 Task: 0xfcb82c "sinTest"



The answer:

Submitted-by wrs!yuba![e-mail]  Fri Sep 27 18:55:25 1991
Submitted-by: wrs!yuba![e-mail] (Kent Long)

 > In the function irint, there is a bug that sets the floating point
 > Exception enable byte register to random values.  Here is the
 > disasembled code:
 >
 >                         _irint:
 > 00e034  4e56 0000                LINK  .W    A6,#0
 > 00e038  f227 6b80                FMOVE .X    F7,-(A7)
 > 00e03c  f22e 5780 0008           FMOVE .D    ($8,A6),F7
 > 00e042  f22e 6380 0008           FMOVE .L    F7,($8,A6)
 > 00e048  202e 0008                MOVE  .L    ($8,A6),D0
 >
 > 00e04c  f201 9000                FMOVE .L    D1,#<FPCR>

<insert audible groan here>

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

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

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

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

For VxWorks 5.0.1 and 5.0.2:

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

This bug does NOT affect VxWorks 5.1.  The disassembled code for Vx5.1,
(HK68K/V3D) is:
                        _mathHardIrint:
2042e58  4e56 0000                LINK  .W    A6,#0
2042e5c  f227 6800                FMOVE .X    F0,-(A7)
2042e60  f22e 5400 0008           FMOVE .D    (0x8,A6),F0
2042e66  f22e 6000 0008           FMOVE .L    F0,(0x8,A6)
2042e6c  202e 0008                MOVE  .L    (0x8,A6),D0
2042e70  f21f 4800                FMOVE .X    (A7)+,F0
2042e74  4e5e                     UNLK        A6
2042e76  4e75                     RTS

Kent Long further clarifies,

This was indeed a real problem in the context switch code in 5.0.x which
was corrected in 5.1.

In both OS versions, there is an optimization that causes the FP context
to be swapped only when the incoming task has been spawned with the
floating point (VX_FP) flag set.  In 5.0.x, the copying-in of the FP context
was done via an fppSave() call.  This created problems if a new FP
task was created after a previous FP task had been pre-empted by a non-FP
task in the middle of an instruction.  The new task ended up with a
mid-instruction context (which causes the protocol violation), and the
old swapped-out FP task ultimately ended up with its context set to IDLE
(which is equally incorrect).

In 5.1, the FP context initialization was changed so that when a task
is created, a pre-defined IDLE frame is copied into that tasks's context.
Since there is no assumption about current FP state (as with fppSave),
task creation is now decoupled from the regular switch logic.

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

32. What are +T, +I thingies in the "i" output?

The following is an excellent description of all these symbols by many people
on the net, including "Fred J. Roeber" and others:

Description                                 Status symbol
=====================================       ===============
<blah> and task's priority inherited         <blah> + I
Delayed and suspended                        DELAY+S
Pended and suspended                         PEND+S
Pended and Delayed                           PEND+T
Pended, delayed and suspended                PEND+S+T

The DELAY state indicates that the task has done some sort of delayed
call while PEND means the task has done something that caused it to
block like trying to semTake a semaphore someone else was holding.
PEND+T means that the task is both delaying and pending; it has done a
semTake with a timeout. +I means that the task has (temporarily)
inherited a higher priority through the use of a mutex semaphore.

The priority inheritance protocol also accounts for the ownership of
more than one mutual exclusion semaphore at a given time.  A task in
such a situation will execute at the priority of the highest priority
task blocked on any of the owned resources.  The task will return to
its normal, or standard, priority only after relinquishing all of the
mutual exclusion semaphores with the inversion safety option enabled.

If you use nested mutex semaphores with priority inheritance turned on then
when a task inherits a high priority due to some inner semaphore it owns,
it doesn't lose that priority until it relinquishes all the semaphores it
holds.  This doesn't quite follow the rules for priority inheritance (to
the extent that there really are any rules) in that normally, a task's
inherited priority should decrease as it releases each nested semaphore to
whatever the priority ceiling is for the semaphores it still holds.  Getting
this incremental priority reduction to work right in practice, though,
is extremely difficult (some of the SUN papers on the Solaris real time
scheduling indicate that this was one of the hardest things for SUN to
get right in their OS upgrades).  Given that VxWorks is a real time embedded
OS, I, for one, don't care if WRS uses the current implementation even
though it isn't "pure" because the result is a more reliable implementation
that runs more deterministically.  Anyway, my guess is that you will find
that you have some nested semaphore code where you are doing something
after releasing one of the nested semaphores that shouldn't be done at a
high priority.

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

33. Gotchas w.r.t watchdogs

watchdog handlers run at interrupt level.  You should not use
routines that can block in interrupt level code.  Frequent mistakes:
using printf() in watchdog routines -- use logMsg() instead.

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

34. Is it possible to delete a memory partition in VxWorks?

No.  memPartDestroy() is not really implemented.  Perhaps it will
be in the future.  Currently it just returns ERROR.

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

35. rename() does not work in netDrv and nfsDrv filesystems, why?

Because rename() is not implemented for netDrv (although it could be),
and nfsDrv does not implement rename() completely either.

Talk to WRS to get these fixed.

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

36. Free NFS Server for VxWorks

A free, incomplete, sample implementation (i.e. hack) of NFS Server
for VxWorks is available in:

 netcom.com:pub/hjb/nfsd/

There is a README file there that describes further details.  The current
snapshot of this implementation is a result of a couple of days of
hacking, doesn't do everything right, and intended for educational and
further hacking purpose.

There is someone else who's porting the MS-DOS PC-based nfs server (SOSS?)
to VxWorks.  Not clear on its availability yet (let me know!)

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

37. Free SNMP for VxWorks

[e-mail] (Lawrence T. Hoff) reports,

We ported the CMU SNMPv2 code to vxWorks 5.1. This latest round of posts has
prompted me to put it in anonymous ftp (ctrldev1.rhic.bnl.gov --
130.199.96.82).

SNMP Research sells VxWorks compatible port of their SNMP implementation
with support.  Their's cost $$$$$, though.

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

38. What third party products are available for VxWorks?

I tried to include the third party products, list of consultants,
services, goodies, etc. available for VxWorks from various sources but...
there are too many to list here.  Instead,

the file:

 netcom.com:pub/hjb/vxworkers.Z

is updated in realtime to contain a list of individuals and companies
that offer help, services (paid or unpaid), and goods for VxWorks.

To get a copy (if you don't have ftp access) or to be listed in this file,
please contact or send info in ASCII to:

 [e-mail].

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

39. What kind of products have been developed using VxWorks?

 - flight simulators
 - radio and optical telescopes
 - automative ABS & realtime suspension
 - naviation systems
 - deep sea instrumentation
 - PBXs
 - traffic lights
 - modems
 - sonar systems

 [ editorial: And, regrettably, in: ]

 - military stuff

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

40. A complete list of CPU hardware supported by VxWorks

Complete list of WRS supported BSP's are available in:

 netcom.com:pub/hjb/vxbsp.Z

VxWorks runs on a lot of different hardware.  Majority of hardware
supported is based on VME bus.  Porting VxWorks to a new VME board
based on MC68K takes only a few days, give or take a week, depending
on your karmic condition at the time.  A lot of the ports are
initially done by the customers and later "approved" by WRS, for
which they charge, in order to keep them on "supported" list.

Porting to a new "architecture" (new processor) takes longer.
This varies more widely -- from a few months to a few years.

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

41. A complete list of peripheral devices supported by VxWorks

Complete list of WRS supported BSP's are available in:

 netcom.com:pub/hjb/vxbsp.Z

VxWorks supports a wide variety of devices.  A lot of device drivers
are written both by customers and WRS staff.  There are device drivers
for almost popular available ethernet chips (except perhaps SEEQ and
Fujitzu, etc.), various serial chips (MC68681 DUART, Zilog 8350 Sync/Async
COMM chip, etc.), little I/O thingies in micro-controllers (MC68302
serial I/O, etc.), SCSI, etc.

Customers of VxWorks, hackers and other hardware vendors (especially
VME) usually have a VxWorks driver for their board.  There are drivers
for FDDI boards, GPIB boards, A/D D/A boards, Graphics controllers,
frame grabbers, stepper motors, pin-ball machines, and etch-a-sketch
toy games.

A list of available device driver for VxWorks can be found in:

 netcom.com:pub/hjb/vxdrivers.Z

Some evil VxWorkers have drivers for military/weapons systems.

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

42. What's with these unbundled "accessories"?

Propaganda from WRS:

 The new product/feature doesn't need to wait for the
 next OS release.  Only the users who want/need it pay for it
 lengthens price list which keeps individual items lower
 but still enhances WRS revenue growth.

 Please Note:
 WRS still always adds features to the core product, and
 has never taken items out of core product to make them
 unbundled.  Unlike UNIX vendors and others.

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

43. How come my 5.0.2 BSP isn't available in 5.1, damn it?

Propaganda from WRS:

 WRS tries to give customers 1 year warning when any product
 may be discontinued.  Unfortunately, all the bugs in
 the notification system are still to be worked out.
 Complain vehemently to your sales rep. if he didn't
 keep you informed.  WRS BSP obsoletion policy is primarily
 based on BSP volume and h/w avalability.

The 5.1 Guide and Release Notes provide a step by step recipe to
upgrade from 5.0.2 -- minimal changes,  start by ANISifying.  The BSP
Port Kit 1.1 provides extensive  info for the masochist.

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

44. How much is VxWorks?

 In general: Not free, in fact, quite the opposite.

 - Development License $23.5K (per project?)
 - Source $120K.
 - Target Licenses from $1000 for single quantity to $10 for 100,000+.

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

45. What is MicroWorks?

VxWorks is also available as a kernel-only product (MicroWorks 1.0) for
 the following processors:

 i960, 680x0, 683xx

MicroWorks is -- half the product at a half the price.

It has no network, native debug, shell, or profiling.  Comes with
VxMon a very portable ROM monitor to talk with an enhanced vxGDB 2.0
also included -- this is the debug agent which allows true system
level debugging in ISR or wherever.  In future, VxWorks may also be
able to work with VxMon.

Development License $12,500.

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

46. Other Unbundled Products for VxWorks?

Other unbundled "accessory" products are: VxMP ($4K) which is an
extended shared memory capabilities for the kernel allowing semaphores
and other objects to be manipulated over the backplane transparently
(really!).

VxVMI ($3K) is a library of virtual memory interface routines allowing
text & kernel data protection.  complementary products: BSP Port Kit
1.1 ($2K), VxSim 1.0 ($5K), WindX ($3.5K), WindC++ ($2.5K), WindC++
Gateway for ObjectCenter ($?K's), and Realtime Innovations StethoScope (3K).

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

47. How can I find out more about VxWorks?

 Read: comp.os.vxworks
 Email: [e-mail]
 Call: 1-800-KIK-WIND

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

48. What other net.resources are available on real-time systems?

There is at least one other newsgroup devoted exclusively to a particular
vendor's real-time operating system:

comp.os.os9  Discussions about the OS/9 operating system.

Here are some other related newsgroups:

comp.arch        Computer architecture.
comp.arch.bus.vmebus    Hardware and software for VMEbus Systems.
comp.os.misc        General OS-oriented discussion not carried elsewhere.
comp.realtime        Issues related to real-time computing.
comp.os.os9        Issues related to OS9 and OS9000 realtime OS.

There are too many other newsgroups devoted to computer operating systems
to list here.  The interested reader is advised to check the "newsgroups"
file on a local news service machine.

The automatic server for users of pSOS RTOS is now in place.

PSOSUSER - A list intended for the discussion of topics relating to
           pSOSystem and other products of Integrated Systems Inc.,
           Software Components Group.

Send articles to [e-mail] and administrative requests to
[e-mail].

If you aren't already subscribed and would like to, please send a mail
message to [e-mail] containing the following in the body of
the message

SUBSCRIBE PSOSUSER <substitute your full name here>

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

49. How do i use FIONBIO in 5.0.2 when there is no fcntl()?

Use ioctl() instead.

...
{
    ...
    int on = 1;    /* turn it on */
    ...
    ioctl(fd, FIONBIO, &on);
    ...
}

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

50. Free lex and yacc for use with VxWorks

John Winas ([e-mail]) writes,

I just (moments ago) uploaded the two packages to thor.ncar.ucar.edu where
the vxWorks archive is.  When ever the maintainer moves it into the release
area they will be available to everyone.  I named the file lexyacc.tar.Z
and it contains all of the sources and make files for you to build them.
It all seems to work perfectly on my sun sparc running 4.1.3.  The
only thing you have to configure is the full path name to where you wish
to keep flex so that it can find its skeleton file when you use it to
lexify your .l files.  Byacc has no skeleton files and simply needs to
be in your path.

I am interested in any bugs found in because we are using them here.  Feel
free to email me at [e-mail].

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

51. timer_gettime() bug

From: [e-mail] (Kent Long)

In article <[e-mail]> [e-mail] (Bob Klawuhn) writes:
>I am currently trying to user the timerLib to obtain
>the amount of time that a timer has left before it
>expires. I am trying to use the timer_gettime function.
>The value that it seems to return is always the time
>that the start timer was given, not what is left on the
>timer.


This is indeed a bug in the 5.1 and 5.1.1 VxWorks versions.
It is now being tracked as WRS SPR #2673.

As a workaround, the following could be done following the
timer_gettime() call, to convert the erroneous results into
the desired remainder value:


     #include "private/timerLibP.h"
     struct timespec timeNow;

     (void) clock_gettime (CLOCK_REALTIME, &timeNow);
     TV_SUB (timerid->exp.it_value, timeNow);

...which leaves the remainder in it_value.

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

52. bogus INCLUDE_TCP_DEBUG

From: [e-mail] (Emily Hipp)

>Bus Error
>Program Counter: 0x0001c738
>Status Register: 0x3000
>Access Address : 0xbfbfbfd3
>Special Status : 0x0505
>Task: 0x3dcc54 "tExcTask"
>TCP tracing not enabled (use INCLUDE_TCP_DEBUG).

This is misleading information.  INCLUDE_TCP_DEBUG is not supported
as a configAll.h include option.

[ editorial:
  INCLUDE_TCP_DEBUG never got integrated into VxWorks config files.
  To get around this bug, until WRS fixes it, either unset SO_DEBUG
  socket option using getsockopt()/setsockopt(), or call tcpTraceInit() (sp?)
  which will drag in tcp_debug.o and set the tcp_trace() routine to
  be called when debug option is set on TCP sockets.
]

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

53. free ppp for VxWorks

Is available via anonymous ftp

    netcom.com:pub/peacefulstar/dab/vpppd-1.0.tar.gz

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

9999: Contributions to comp.os.vxworks FAQs.

The following net.folks, among others, have contributed to this posting:

 Name            email address
 ------------        ----------------------------
 Mark Linimon         [e-mail]
 Geoff Espin        [e-mail]
 Rev. Bob Crispen    [e-mail]
 Stan Schneider        [e-mail]
 Fred J Roeber        [e-mail]
 Marc Friedman        [e-mail]
 Joe Van Andel        [e-mail]
 Bob Marino        [e-mail]
 Richard Kowalsky    [e-mail]
 Kent Long        [e-mail]
 James Moore        [e-mail]
 Chuck Meade        [e-mail]
 Patrick T. Pinkowski    [e-mail]
 D'Anne Thompson    [e-mail]
 Leonid Rosenboim    [e-mail]
 David Lim        [e-mail]
 Richard Neitzel    [e-mail]
 John Winas        [e-mail]

I welcome flames, insults, accusations, reactions, additions, and
corrections to this posting via email:

 [e-mail]

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

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

Hwa-Jin Bae  ([e-mail])              510-466-9166 (msg/page)
PEACEFUL STAR Consultants -- "Hackers R Us"    510-536-7607 (office)
2899 Ford St, OAKLAND, CA 94601-2125        510-536-5889 (fax)