|
Archive-name: vxworks-faq/part1
Maintained-by: hjb@netcom.com Last-modified: May 16, 1994 Version: 1.6 See reader questions & answers on this topic! - Help others by sharing your knowledge 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. This FAQ was compiled by hjb@netcom.com 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: ftp://rtfm.mit.edu/pub/usenet/news.answers/ ftp.uu.net:/usenet/news.answers/vxworks-faq.Z ftp://cs.toronto.edu/pub/usenet/comp.answers/ ftp://ftp.netcom.com/pub/hjb/ ------------------------------------------------------------------------- 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 traditional 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? 49. How do i use FIONBIO in 5.0.2 when there is no fcntl()? 50. Free lex and yacc for use with VxWorks 51. timer_gettime() bug 52. bogus INCLUDE_TCP_DEBUG 53. free ppp for VxWorks 54. how to disable cache on mc68040 or mc68030 using TT regs? 55. work-arounds for ms-dos filesystem bug when lseek() past eof 56. TCL for VxWorks 57. adding default route 58. adjusting network driver MTU size 59. tcpdump like utility for vxworks 60. VxWorks performance on i960 -- unofficial benchmark 61. VxWorks SCSI Performance -- unofficial benchmark 62. VME bus arbitration gotchas 63. 5.1.X new MMU supporting code gotchas, as explained in the Manual 64. "Cannot Boot. Error 0x1a9" while downloading/booting 65. problem with qsort in some versions of VxWorks 66. fmod fiasco 67. MVME167 copyback cache and various problems 68. unloading objects [new] 69. HDLC driver software [new] 70. SO_KEEPALIVE 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 vxworks_archive@ncar.ucar.edu. Questions should be directed to its maintainer, Richard Neitzel <thor@thor.ucar.edu>. 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 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: elr@netcom.com or ericr@wrs.com phone: 408-289-7757 ------------------------------ 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 vxwexplo@lbl.gov is automatically mailed to a number of sites, including Wind River. Send subscription request to vxwexplo-request@lbl.gov. ------------------------------ 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 (thor@thor.atd.ucar.edu) 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 traditional UNIX and VxWorks? They're both hacks. 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. VxWorks 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 MP 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). Traditional UNIX: high interrupt latency (e.g. spl's are implemented as interrupt lock and unlock calls). VxWorks: priority interrupt-driven preemption, optional round-robin time-slicing. Traditional UNIX: prioritized round-robin preemptive 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. 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). 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. Having said all this, I should also note that there are Realtime capable UNIX systems out there. Most of these systems do not come close to the capabilities and performance of VxWorks in realtime processing. An exception to this might be QNX, which is a very well designed Realtime POSIX operating system. ---------------------------- 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 care 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: If you write an ISR that uses float instructions, it is not enougth just to call fppSave()/fppRestore(), since the compiler for 68040 inserts FP instructions BEFORE your first line of C code, hence you need to write a dummy ISR that: dummyIsr() { fppSave( .. ); yourRealISR(); fppRestore( ... ); } 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, and the anchor area is properly set up. If the anchor and ring buffer area is on a CPU, make sure the sysLib.c:sysHwInit() does the right thing to allow access to on-board memory by other CPU's in the chassis. Be careful, as some VxWorks BSP's turn off on-board memory access by other CPU's if the CPU is not processor 0. This should be changed if your anchor CPU is not processor 0 (first CPU in VME chassis/backplane) -- this is a boot time configuration parameter [ based on the assumption that bpInit() will be done by the processor 0 ]. 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!kent@uunet.uu.net Fri Sep 27 18:55:25 1991 Submitted-by: wrs!yuba!kent@uunet.uu.net (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: ftp://ftp.netcom.com/pub/hjb/ 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 hoff@bnlux1.bnl.gov (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: ftp://ftp.netcom.com/pub/hjb/ 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: hjb@netcom.com. ------------------------------ 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 control systems - Modems - Sonar systems - Comm/weather satellite test equipment - X terminals - PostScript laser printers - Video Editing, Audio Visual systems - robotics - NFS protocol accelerator product - mass storage tape robot systems --------------------------------- 40. A complete list of CPU hardware supported by VxWorks Complete list of WRS supported BSP's are available in: ftp://ftp.netcom.com/pub/hjb/ 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: ftp://ftp.netcom.com/pub/hjb/ 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: ftp://ftp.netcom.com/pub/hjb/ ---------------------------------- 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: inquiries@wrs.com 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 psosuser@isi.com and administrative requests to listserver@isi.com. If you aren't already subscribed and would like to, please send a mail message to listserv@isi.com 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 (winas@phebos.aps.anl.gov) 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. This file is now available in: epics.aps.anl.gov:/pub/lexyacc.tar.Z I am interested in any bugs found in because we are using them here. Feel free to email me at winans@phebos.aps.anl.gov. ------------------------------ 51. timer_gettime() bug [ From: kent@wrs.com (Kent Long) ] In article <9311230139.AA21147@focal.com> bobk@focal.com (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: hipp@wrs.com (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 ftp.netcom.com:pub/peacefulstar/dab/vpppd-1.0.tar.gz ------------------------------ 54. how to disable cache on mc68040 or mc68030 using TT regs? [ From: Steve Morris <morriss@smtplink.indigo.co.il> ] /**************************/ /* for 68030 (e.g. mv147) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_tt () { register int *pVal; int ttVal; pVal = &ttVal; ttVal = TT0_VALUE; asm ("pmove %0,tt0" : : "g" (*pVal)); ttVal = TT1_VALUE; asm ("pmove %0,tt1" : : "g" (*pVal)); } /**************************/ /* for 68040 (e.g. mv167) */ /**************************/ /* 2 large areas, R/W, cache disabled */ #define TT0_VALUE 0x403f8507 /* from $40000000 -> $77ffffff */ #define TT1_VALUE 0x03018507 /* from $02000000 -> $03ffffff */ test_dtt () { asm ("movec %0,dtt0" : : "r" (DTT0_VALUE)); asm ("movec %0,dtt1" : : "r" (DTT1_VALUE)); } ------------------------------ 55. work-arounds for MS-DOS filesystem bug when lseek() past eof [From: georg@sgl.ists.ca (Georg Feil)] [editorial: This is a workaround for the bug in VxWorks ms-dos implementation which produces incorrect error return on write() after lseek() beyond eof. N.B.: VxWorks versions upto 5.1.1 have buggy IO system layer that does not support "correct" write() to normal files. When writing to a file via write() expect to check the return value even if it is not ERROR. Unlike most other systems (e.g. UNIX) VxWorks write() upto version 5.1.1 will return number of bytes actually written even when write() was not completely successful on devices that are not marked non-blocking and/or are subject to flow control. ] There's been enough heated debate on this so I'm sending out my brute force workaround. Thanks to Kent Long who managed to let slip enough information on the bug to identify the prerequisite: lseek() past the end of file. My workaround simply extends a file by writing 0's on the end whenever there is a seek past the end. (This may result in a file being extended when it shouldn't have been, i.e. no write follows the seek, but what the hell.) Use file_seek() below instead of lseek() to seek. Note that file_seek() is not meant to be plug-replaceable with lseek(), that feature is not required in our system. 'zero8k' is a character array of 8192 zero bytes. int file_seek(int fd, int offset) /* * Sets the byte offset for the next write or read from a file. * Simple interface to lseek() function. This returns ERR_NONE iff the actual * actual seek offset returned by lseek() exactly matches the desired offset. * 'fd' is the file descriptor to seek on. * 'offset' is the absolute file position to seek to in bytes, where 0 is * the beginning of file. * Return value is error code (not a VxWorks error code, another type). */ { STATUS st; struct stat filestat; /* file status info obtained from fstat() */ int aoff; /* actual seek offset returned by lseek() */ long int fillsz; /* (***) for SPR #2739 kludge */ long int fillamt; /* (***) for SPR #2739 kludge */ if (FileDebug && Verbose>=2) { wprintw(interact,"file_seek(): seeking to offset %d on fd %d\n", offset,fd); } /* (***) workaround for VxWorks 5.1.1 bug SPR #2739 (write() returns with transfer count too low but errno not set after seeking past current end of file). Note that this may extend the file prematurely, i.e. even if no write() calls follow the seek. */ /* get current file size */ st=fstat(fd, &filestat); if (st==VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error performing fstat() on fd %d: %s\n", fd, vw_errmsg(0)); } return(ERR_VXIO); } /* manually extend file using zero writes if seek offset past end of file (note: tried ioctl() with FIOTRUNC, but this only works to shorten files! */ if (offset>filestat.st_size) { /* seek to the end of the file first */ errno=0; aoff=lseek(fd, filestat.st_size, SEEK_SET); if (aoff != filestat.st_size) { /* returned value should always match 'filestat.st_size' */ if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking to EOF on fd %d (%d, should be %d) (%s)\n", fd, aoff, filestat.st_size, vw_errmsg(0)); } return(ERR_VXIO); } /* fill file with zeroes to bring length up to 'offset' */ fillsz=offset-filestat.st_size; while (fillsz>0) { if (fillsz>8192) fillamt=8192; else fillamt=fillsz; errno=0; aoff=write(fd, zero8k, fillamt); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error writing zeros to %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } if (aoff != fillamt) { if (Verbose>0) { wprintw(interact,"file_seek(): Bad xfer count writing zeros to fd %d at pos %d (%d, should be %d): %s\n", fd, ioctl(fd,FIOWHERE,0), aoff, fillamt, vw_errmsg(0)); } return(ERR_VXIO); } fillsz -= fillamt; } /* flush the output to disk immediately */ st=ioctl(fd, FIOFLUSH, 0); if (st!=VX_OK) { if (Verbose>0) { wprintw(interact,"file_seek(): Error flushing zeros written to fd %d at pos %d: %s\n", fd, ioctl(fd,FIOWHERE,0), vw_errmsg(0)); } return(ERR_VXIO); } } /* (***) end of workaround for VxWorks 5.1.1 bug SPR #2739 */ errno=0; aoff=lseek(fd, offset, SEEK_SET); if (aoff == VX_ERROR) { if (Verbose>0) { wprintw(interact,"file_seek(): Error seeking to offset %d on fd %d: %s\n", offset, fd, vw_errmsg(0)); } return(ERR_VXIO); } /* returned value should always match 'offset' */ if (aoff != offset) { if (Verbose>0) { wprintw(interact,"file_seek(): Incorrect actual file position after seeking on fd %d (%d, should be %d) (%s)\n", fd, aoff, offset, vw_errmsg(0)); } return(ERR_VXIO); } return(ERR_NONE); } ------------------------------ 56. TCL for VxWorks [ From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) ] Tool Command Language, version 7.0 (TCL7.0) for VxWorks 5.1 is on thor.atd.ucar.edu:~ftp/pub/vx/tclvx7.0.v4.tar.gz If you've ever been frustrated that the VxWorks shell is not re-entrant, and has no control flow (e.g. if then else, switch, case ), then you will find TCL very useful since it is a very complete language, that allows you to add your own application specific commands to the interpreter. I find it invaluable for system testing, since I register TCL commands for all major functionality of my real-time application. This allows me to test most pieces of my data acquisition system from a command line, and build nice flexible scripts to test and operate my system. As a matter of fact, I can even invoke specific methods of C++ classes via TCL. Also, you can control your real-time system from a Unix workstation by sending TCL commands from either a TCL or Tk/TCL application (via tclTCP). I find that sending TCL commands (which are just strings) is much easier and more flexible than writing a Remote Procedure Call (RPC) for each piece of functionality that I need to remotely invoke. ------------------------------ 57. adding default route A default route is a route table entry with destination field set to 0. To do the equivalent of "route add default gateway metric" in VxWorks, do: routeAdd("0",addr_of_gateway); ------------------------------ 58. adjusting network driver MTU size VxWorks network driver are compatible (mostly) with tahoe BSD drivers. To change MTU you should modify "if_mtu" field of "struct ifnet" you pass to ether_attach() or if_attach(). ------------------------------ 59. tcpdump like utility for vxworks Take a look at a hacked up packet trace program in: ftp://ftp.netcom.com/pub/hjb/ [editorial: if you have something better, let me know] ------------------------------ 60. VxWorks performance on i960 -- unofficial benchmark [ From: djanssen@mswe.dnet.ms.philips.nl (Ton Janssen, 62203 (TSSW)) ] We did some measurements on a Heurikon HK80/V960E. Equiped with I960CA on 33MHz. Here they are: Test-item Conditions Time in us ========================================================================== - semGive/semTake pair (binary semaphore) 11,2 - taskSpawn (+/- 8 processes active) 790,0 - taskIdVerify 0,72 - taskSuspend/taskResume pair (+/- 8 processes active) 32,6 - lstAdd/lstDelete pair (10 nodes in list) 3,9 - msgQNumMsgs 1,2 - msgQReceive (NOWAIT, no message available) 16,8 - rngBufPut/rnBufGet pair (0x20 bytes) 24,5 - msgQSend/msgQReceive pair (NOWAIT, no arguments) 65,7 - bcopy (Quad aligned data) 0,515/Quad - mutliply two floats (depends on the value!) 1,6 - multiply two doubles ( '' '' ) 2,6 - Raw context switch (8 processes active) 34,0 ------------------------------ 61. VxWorks SCSI Performance -- unofficial benchmark [ From: mea@mclean.sparta.com (Mike Anderson) ] System : Heurikon HK68G/V4D (33 MHz 68040, 16 MB RAM, NCR53C710 SCSI w/ Hk SCSI DMA routines in Asynchronous SCSI mode) VxWorks : 5.1.1 (Yes, using Heurikon VxWorks 5.1 BSP) Disk : Seagate ST11200N (1 GB SCSI) File System: VxWorks RAW partition mounted as "/sd1/" Clock Rate : 60 Hz Approach: My application has the data coming in in 16Kbyte chunks. So, I devised a piece of test code that would allow me to specify how many 16K chunks I sent to the disk in each write and how many total bytes to write. The actual number of bytes written is generally a little larger (typically one more block size) due to the quick and dirty way I wrote the code, but the calculations are based on the actual number of bytes written to the disk. The technique I used was to write a block to the disk starting at the end of the last write and then seek back to relative zero and write the current pointer (just as I would in real life to know how many bytes had been streamed total). Also, you may notice the disk seek time coming into effect in the 200MByte files. Here are the results: Buffer Size Total Requested Bytes/sec total secs 16K 1024000 (1 MB) 1,032,192 1.000 secs 10240000 (10 MBs) 1,036,087 9.883 secs 102400000 (100 MBs) 1,049,538 97.566 secs 204800000 (200 MBs) 1,043,123 196.333 secs 32K 1024000 1,613,193 0.650 secs 10240000 1,627,997 6.300 secs 102400000 1,627,980 62.900 secs 204800000 1,610,485 127.166 secs 48K 1024000 1,935,360 0.533 secs 10240000 1,994,712 5.150 secs 102400000 1,992,209 51.416 secs 204800000 1,970,335 103.950 secs 64K 1024000 2,169,467 0.483 secs 10240000 2,244,905 4.583 secs 102400000 2,246,332 45.600 secs 204800000 2,216,450 92.400 secs 96K 1024000 2,495,409 0.433 secs 10240000 2,580,480 4.000 secs 102400000 2,571,534 39.833 secs 204800000 2,533,374 80.866 secs 128K 1024000 2,621,440 0.400 secs 10240000 2,761,250 3.750 secs 102400000 2,771,147 36.983 secs 204800000 2,726,693 75.133 secs 256K 1024000 2,859,752 0.366 secs 10240000 3,130,077 3.350 secs 102400000 3,139,304 32.650 secs 204800000 3,083,428 66.483 secs 512K 1024000 3,145,728 0.333 secs 10240000 3,346,519 3.133 secs 102400000 3,361,846 30.566 secs 204800000 3,298,416 62.150 secs 1024K 1024000 3,311,292 0.316 secs 10240000 3,475,942 3.016 secs 102400000 3,487,345 29.466 secs 204800000 3,416,806 60.150 secs ------------------------------ 62. VME bus arbitration gotchas [ From: mea@mclean.sparta.com (Mike Anderson) ] > Sender: Rob Steele, e-mail: steele@telerobotics.jpl.nasa.gov > > > I have the following VME hardware configuration: > > VME MOTES chassis: > 1 Motorola system controller card, > 6 Huerikon 68020 CPU boards (HKV2A), > 1 Micro Memory shared memory cards, > 1 Bit-3 memory interface card, > 2 XYCOM parallel boards, and > 1 Excelan ethernet cards. > > VadsWorks 2.0.1 (equivalent to vxWorks 5.0). > > I am unable to consistently boot the chassis. I will get bus errors and file > not present errors during the boot process on different boards. On rare > occasions it will boot. To get it to boot I halt the boot process on the last > 4 boards in the chassis and let the first two boot. After that I boot the > last 4 one at a time. > This sounds like the bus arbitration bug biting. If the Heurikon boards are all at the same bus grant level (they typically come from the factory set for BG3) then you will experience "random" failures that manifest themselves as bus errors when a board is requesting access to the bus and the bus is so busy that the bus watchdog timer (1.6ms on the HKV2F I think) expires. This is proper behaviour. The watchdog timer is designed to alert the task that it was unsuccessful in accessing a VME address in the alotted time and to signal that failure with a bus error. Now, there are several ways to fix this problem. One which I heard about was to modify the boot ROMs to insert a variable length delay so the first CPU booted immediately, the second booted 30 secs later the third 60 secs later, etc. This approach was clearly a software hack trying to get around a hardware problem that was obviously not understood. This approach *may* get the boards to boot, but with heavy bus traffic during execution, they will continue to exhibit bus errors. You see, because the VMEbus is a daisy chain, the first CPU in the chain has an inherently higher priority than all others that follow it. The 2nd board gets the next highest priority, etc. This means that a graph of bus access at a given BG level looks something like this: % 60 | | A 50 | * | C 40 | | C 30 | | * E 20 | | * S 10 | | * S 0 |------------------*---*-- 1 2 3 4 5 6 # CPUs @ BG level I.e., it is roughly an exponential decay such that, given that the level of bus activity is moderately high, the first 1-3 CPUs will hog 85-95% of the bus cycles and CPUs 4 and beyond will exhibit bus errors. If the bus activity level is very high such as during a boot up via the backplane, you may not be able to get past CPU 2 before bus errors manifest themselves. Now, as I said, there are other ways to circumvent this problem. Boards equipped with the VIC68 VMEbus interface, for instance, can have their bus timeouts changed to the point of an infinite wait (i.e., the bus watchdog is disabled). This is still just a kludge that masks the real problem of a poorly thought-out arbitration scheme. With this approach, *real* bus errors resulting from errant pointers and/or failed boards are never reported and the system just seems to hang. The REAL solution to this problem is to adjust the arbitration levels of the CPUs. In the VMEbus, there are 4 levels of arbitration (0-3) where level 3 is the highest priority. By default, virtually all manufacturers ship their boards configured for BG3. Therein lies the problem. What the real-time designer needs to do is to realize this and make adjustments. Within the 4 BG levels, there are two modes of operation: 1) priority and 2) round robin. Priority mode means that requests at level 3 will be honored before requests at level 2. Level 2 before level 1 and so on. This means that with priority mode arbitration, put your highest priority boards at level 3 and distribute the other boards at the other levels according to their relative priorities. On the other hand, round robin arbitration mode means that all 4 BG levels are treated equally and each level gets a fair slice of the pie so to speak. Use this mode when you have lots of boards, but no one has an inherently higher priority than any other. With this approach, we've been able to get as many as 16 CPUs running in the same backplane (4 at each level) without experiencing bus error problems due to arbitration. Remember, just because the boards are at different BG levels doesn't circumvent the implied priorities of the CPUs at the *same* level based on the bus daisy chain. Typically, these modes are configurable on the system controller either through a jumper, PAL or software bit twiddling. However, there are boards that are hardwired for arbitration level 3 and they can't be changed. The Force SPARC 1E board is one of them. This means that you'll have to use these boards sparingly in VxWorks chassis (i.e., probably no more than 3-4 booting up from the backplane but probably more if you boot each of them up from local Ethernet). I understand that the SPARC 2CE board uses the same VMEbus interface as the 1E which simply means that the bus errors will happen twice as fast. Hopefully, the 3E board will get a real bus interface on it if it ever comes out. ------------------------------ 63. 5.1.X new MMU supporting code gotchas, as explained in the Manual Carl Lacy points out: 1) Programmer's Guide, Chapter 8.3, page 319 How to setup the the MMU for VMEbus address spaces 2) 5.1 Known Problems, Apr '93, page 5 "Several BSPs turn on basic MMU support ... even if this option is not specified in configAll.h" ------------------------------ 64. "Cannot Boot. Error 0x1a9" while downloading/booting This is usually due to the built-in 'feature' inside UNIX inetd program. The inetd tries to protect itself against clients that tries to connect too often too quick as a security measure, and disallows more than a certain number of connections per given period. When this happens, you will usually see some error messages about "looping..." in syslog (if your syslog is configured correctly) on your UNIX server (where inetd is running). You can either try "kill -HUP inetd_process_id" to get out of this looping mode by sending HUP signal to inetd, or try and install the patched version of inetd that has larger default limit for looping detection (some OS vendors will supply this to you), or just get a copy of BSD UNIX distribution of inetd source code and compile it with larger default values for looping and use it instead. ------------------------------ 65. problem with qsort in some versions of VxWorks Some version of VxWorks are shipped with incorrect qsort(), to remedy this problem, get a copy of qsort() from BSD UNIX distribution and compile it. ------------------------------ 66. fmod fiasco From: jbrandt@sadira.gb.nrao.edu (JOE BRANDT) remainder = fmod(value, divisor) - floating point modulus routine. The fmod math subroutine for MC68040 (mv167) based systems has been a topic of discussion on the exploder for many months now. The first discussions centered around the routine's accuracy (or even correctness). Recently I found that the execution time for the fmod subroutine is highly dependent upon the ratio of the values passed as arguments. At a ratio of about 50,000 I was seeing execution times of 30ms! The VxWorks exploder FAQ now includes a proposed replacement routine for 68040 systems, however, I have examined this routine and found it to be grossly in error in cases where the divisor is less than 1.0. Fortunately, I have found public domain source, authored by Sun Micro, for an alternative algorithm. This algorithm claims an exact result. It can be found at: ftp: plan9.att.com in /netlib/fdlibm/e_fmod.c.Z (I believe ftp.uu.net has copies also). This appears to be a ieee 754 compliant routine. (I'm not sure what that means, but it sounds good). Execution times for this routine are in the range of 7.6 to 100 usec's. From: vince@rti.com (Vince Chen) > Submitted-by jbrandt@sadira.gb.nrao.edu Thu Mar 24 12:41:16 1994 > Submitted-by: jbrandt@sadira.gb.nrao.edu (JOE BRANDT) > > While I currently am not questioning the accuracy of the fmod() function, > the performance of it on the mv167 card (68040) is certainly an issue. > > Here's some benchmarks from my 5.1/mv167 system: > > -> timexN(fmod, 49999.9, 1.0) > timex: 25 reps, time per rep = 30661 +/- 666 (2%) microsecs > > -> timexN(fmod, 2.0, 1.0) > timex: 50000 reps, time per rep = 9 +/- 0 (0%) microsecs > > -> timexN(fmod, 499.9, 1.0) > timex: 2525 reps, time per rep = 305 +/- 6 (1%) microsecs > > Note the dependency on value. Unfortunately I am doing an fmod on the > modified julian date (which is currently in the 50,000 range). which > took an amazing 30ms/call ! > > Wow, can some elaborate on the algorithm being used here. seems like it's > a straight while loop! I believe it is a while loop. A while loop is faster in some situations, but obviously no in yours! Until WindRiver resolves the problem w/ the Motorola Floating Point Exception library, you may want to roll your own on this one. The code below on our 167/25MHz VxWorks 5.1 consistently results in 30 usecs. double myfmod1( double arg1, double arg2 ) { return (arg1 - ((int) (arg1 / arg2)) * arg2); } ------------------------------ 67. MVME167 copyback cache and various problems From: georg@sgl.ists.ca (Georg Feil) Well, I think we now know everything there is to know about the memPartFree() problem we were having. The original subject here was "memPartFree error with copyback caching enabled (167)". Other past subjects that possibly related to the same problem include "Large disk writes w/cache cause MVME167 to freeze". Apparently the root cause is a snooping problem related to TAS on the VME bus, and is Motorola's fault. The solution to the problem is the "MV167 VME TAS patch" from Wind River. It consists of a number of configuration changes (config.h, usrConfig.c etc.) and is reproduced below. Strangely, it has not been assigned an SPR number because, according to Wind River, the new version of the 167 BSP has fixed the problem so no SPR is necessary(?). This situation may have changed since the memos I received were written. Our related TSR number was 16443, which may help others to track things down. I had already come up with my own patch that worked in a completely different (and very specific) way, and the WRS patch seemed not to apply to our problem. However I tested the patch anyway and sure enough it fixes our problem. As a bonus, SCSI performance seems to have improved slightly. ------------------------------ 68. unloading objects From: stan@rti.com (Stan Schneider) Under VxWorks 5.1.x, you can use 'unld "file.o"' (or use the module id, see "moduleShow"). Under 5.0.x, you can't unload the object & reclaim the space, but you could remove the symbols from the symbol table with symRemove. That would prevent unnecessary maiming. ------------------------------ 69. HDLC driver software I have drivers/libraries and application software for the Siemens 82532 multiprotocal chip (SYNC/ASYNC serial communication HDLC/SDLC protocol). Maybe there is some compatibility. This is running well in our inhouse designed VME module running vxWorks for the mc68332. Graham Waters waters@reg.triumf.ca TRIUMF Control Systems Engineer. Meson Research Facility, 4004 Wesbrook Mall, Vancouver, B.C. Canada. V6T 2A3 ------------------------------ 70. SO_KEEPALIVE There are two types of keep alive packets. I don't know how smart snoop program is, but most analyzers i've seen do not flag a keepalive packet seperately. KEEPALIVE is not really a part of original TCP spec anyway, so this is understandable. it was an add-on hack by BSD implementation. KEEPALIVE packet was implemented in two different ways. The 4.2 BSD implemented it wrong, and expected a zero length packet. It send out a packet with sequence number set to snd_una -1 (send unack'ed - 1) and ack set to rcv_next - 1. This forces a response from a well behaved TCP peer either in the form of a ACK or RST depending on the peer's status. The 4.3 BSD implemented it better, and send a packet with the sequence number set to snd_una -1 and ack set to rcv_next. the same behavior was expected from a TCP peer. The keep alive will start after connection has been idle for 75 seconds, and keepalive probe will continue for ~2 hours. This is in adherence to the spirit of TCP -- you're not supposed to randomly drop connections. the keepalive is, in a way, a necessary evil, that provides realistically slow garbage collection of zombie connections. It was not meant to be used to detect the other side dying away in realtime. It can be a headache, for example, over a very high latency link, when you're doing a telnet, if keepalive randomly or too quickly decided to terminate the connection because it timed out too quick. You might think 2 hours is excessive, but in the old days, this was a real problem -- like when you are telneting to a host in spain over various low quality, high latency, noisy links... type a character and wait for 10 mintues... that was common. The only application controllable, expectedly behaving way to detect the other side going away is to use a seperate connection, or a seperate connection-less channel.... for out of band status info delivery. a kind of i'm alive or are you there... many TCP and UDP based standard protocols do a form of this... FTP, RSH, etc. SO_RCVTIMEO and SO_SNDTIMEO are not used in reality. they are set and recorded but never reference for any useful work. Adjusting keepalive packet intervals is only possible using global variables. This will affect all TCP sessions on the machine that has keepalive mode set. You can play games with the following variables: tcp_keepidle, tcp_keepintvl, tcp_maxidle. Please get a copy of BSD UNIX TCP/IP code from FTP sites and look into tcp_timer.c and other TCP files before you go and change things though. The keepalive is actually also used in connection setup phase (as a hack). Changing these values carelessly will result in wierd TCP behavior on all TCP sockets. ------------------------------ 9999: Contributions to comp.os.vxworks FAQs. The following net.folks, among others, have contributed to this posting: [ If you have contributed, but are not listed here please me know. ] Name email address ------------ ---------------------------- Mike Anderson mea@mclean.sparta.com Mark Linimon linimon@nominil.lonestar.org Geoff Espin geoff@wrs.com Rev. Bob Crispen crispen@foxy.boeing.com Stan Schneider stan@rti.com Fred J Roeber fjr@ssd.ray.com Marc Friedman maf@verdix.com Joe Van Andel vanandel@ncar.ucar.edu Emily Hipp hipp@wrs.com Bob Marino ram@mr.picker.com Richard Kowalsky cmdorat@tc.fluke.com Kent Long kent@wrs.com James Moore james@wrs.com Chuck Meade chuckm@verdix.com Patrick T. Pinkowski ppinkow@jupiter.ksc.nasa.gov D'Anne Thompson dat@noao.edu Leonid Rosenboim leonid@rst.hellnet.org David Lim lim@robotics.jpl.nasa.gov Richard Neitzel thor@thor.atd.ucar.edu John Winas winas@phebos.aps.anl.gov Lawrence T. Hoff hoff@bnlux1.bnl.gov Georg Feil georg@sgl.ists.ca Steve Morris morriss@smtplink.indigo.co.il Don Brooks dab@netcom.com Ton Janssen djanssen@mswe.dnet.ms.philips.nl Brian Brunner brunner%mother@icarus.ssd.loral.com Carl Lacy lacy@draper.com Joe Brandt jbrandt@sadira.gb.nrao.edu Vince Chen vince@rti.com Graham Waters waters@reg.triumf.ca I welcome reactions, additions, and corrections to this posting via email: Hwa-Jin Bae PEACEFUL STAR hjb@netcom.com ------------------------------ =============================================================================== -- hwajin PEACEFUL STAR User Contributions:
[ Usenet FAQs | Web FAQs | Documents | RFC Index ]
Send corrections/additions to the FAQ Maintainer: hjb@netcom.com
Last Update March 27 2014 @ 02:12 PM
|
comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]
Search the FAQ Archives
N - O - P - Q - R - S - T - U - V - W - X - Y - Z
comp.os.vxworks Frequently Asked Questions (FAQ) [LONG]
[ Usenet FAQs | Web FAQs | Documents | RFC Index | Property taxes ]
Comment about this article, ask questions, or add new information about this topic: