From daemon@vxw.ee.lbl.gov Fri Jan 1 04:00:33 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 1 04:00:41 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 1 04:00:24 PST 1993 Subject: No one minding the store ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: No one minding the store Date: Thu, 31 Dec 1992 21:10:05 GMT From: thor@thor.atd.ucar.edu (Richard Neitzel) Organization: National Center for Atmospheric Research Message-ID: <1992Dec31.211005.19714@ncar.ucar.edu> Sender: news@ncar.ucar.edu (USENET Maintenance) I will gone on a field project in the Solomon Islands until about the 4-5 of Feb. During this time there will be no human in charge of the archive, so complaints, requests, etc. will have to wait. See ya! - -- Richard Neitzel thor@thor.atd.ucar.edu Torren med sitt skjegg National Center For Atmospheric Research lokkar borni under sole-vegg Box 3000 Boulder, CO 80307-3000 Gjo'i med sitt shinn 303-497-2057 jagar borni inn. --------------------------- End of New-News digest ********************** From root@sr.hp.com Sat Jan 2 23:26:57 1993 From: Postmaster Date: Sat Jan 2 23:27:06 PST 1993 Subject: Mail delayed on sr.hp.com (queue id: AA22003) After 3 days and 18 hours, your message to: vxworks_users@vxw.ee.lbl.gov has not yet been fully delivered for the following reason: Deferred: No route to host Delivery is still pending for the following address(es): pam@hpsrmjs Your message was received Wednesday, 30 December 1992 04:51:20 PST by sr.hp.com. sr.hp.com will continue to attempt to deliver your message for an additional 11 days and 5 hours. If it has not been delivered by the end of that time it will be returned to you. No further action is required by you. Your message began as follows: -------------------- To: vxworks_users@vxw.ee.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: comp.os.vxworks newsdigest Message-Id: <9212301203.AA10941@vxw.ee.lbl.gov> Submitted-by daemon@vxw.ee.lbl.gov Wed Dec 30 04:03:22 1992 Submitted-by: daemon@vxw.ee.lbl.gov Comp.Os.Vxworks Daily Digest Wed Dec 30 04:03:12 PST 1992 From root@sr.hp.com Sat Jan 2 23:33:57 1993 From: Postmaster Date: Sat Jan 2 23:34:06 PST 1993 Subject: Mail delayed on sr.hp.com (queue id: AA27531) After 3 days and 9 hours, your message to: vxworks_users@vxw.ee.lbl.gov has not yet been fully delivered for the following reason: Deferred: No route to host Delivery is still pending for the following address(es): pam@hpsrmjs Your message was received Wednesday, 30 December 1992 13:53:24 PST by sr.hp.com. sr.hp.com will continue to attempt to deliver your message for an additional 11 days and 14 hours. If it has not been delivered by the end of that time it will be returned to you. No further action is required by you. Your message began as follows: -------------------- To: vxworks_users@vxw.ee.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Where are recent archives? Message-Id: <9212302105.AA11211@vxw.ee.lbl.gov> Submitted-by psm%helios.nosc.mil@nosc.mil Wed Dec 30 13:04:46 1992 Submitted-by: psm%helios.nosc.mil@nosc.mil (Scot McIntosh) The vxworks archives on thor.ucar.edu seem to have stopped in 1991. Is there another archive where more recent material is kept? From root@sr.hp.com Sat Jan 2 23:44:26 1993 From: Postmaster Date: Sat Jan 2 23:44:34 PST 1993 Subject: Mail delayed on sr.hp.com (queue id: AA05561) After 1 day and 23 hours, your message to: vxworks_users@vxw.ee.lbl.gov has not yet been fully delivered for the following reason: Deferred: No route to host Delivery is still pending for the following address(es): pam@hpsrmjs Your message was received Friday, 1 January 1993 00:04:59 PST by sr.hp.com. sr.hp.com will continue to attempt to deliver your message for an additional 13 days. If it has not been delivered by the end of that time it will be returned to you. No further action is required by you. Your message began as follows: -------------------- To: vxworks_users@vxw.ee.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Mail delayed on sr.hp.com (queue id: AA27531) Message-Id: <9301010732.AA11973@vxw.ee.lbl.gov> Submitted-by root@sr.hp.com Thu Dec 31 23:32:38 1992 Submitted-by: Postmaster After 1 day and 9 hours, your message to: From root@sr.hp.com Sat Jan 2 23:44:51 1993 From: Postmaster Date: Sat Jan 2 23:45:01 PST 1993 Subject: Mail delayed on sr.hp.com (queue id: AA05530) After 1 day and 23 hours, your message to: vxworks_users@vxw.ee.lbl.gov has not yet been fully delivered for the following reason: Deferred: No route to host Delivery is still pending for the following address(es): pam@hpsrmjs Your message was received Thursday, 31 December 1992 23:58:24 PST by sr.hp.com. sr.hp.com will continue to attempt to deliver your message for an additional 13 days. If it has not been delivered by the end of that time it will be returned to you. No further action is required by you. Your message began as follows: -------------------- To: vxworks_users@vxw.ee.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: Mail delayed on sr.hp.com (queue id: AA22003) Message-Id: <9301010726.AA11891@vxw.ee.lbl.gov> Submitted-by root@sr.hp.com Thu Dec 31 23:25:45 1992 Submitted-by: Postmaster After 1 day and 18 hours, your message to: From root@sr.hp.com Sat Jan 2 23:48:42 1993 From: Postmaster Date: Sat Jan 2 23:48:53 PST 1993 Subject: Mail delayed on sr.hp.com (queue id: AA19282) After 1 day and 19 hours, your message to: vxworks_users@vxw.ee.lbl.gov has not yet been fully delivered for the following reason: Deferred: No route to host Delivery is still pending for the following address(es): pam@hpsrmjs Your message was received Friday, 1 January 1993 04:36:50 PST by sr.hp.com. sr.hp.com will continue to attempt to deliver your message for an additional 13 days and 4 hours. If it has not been delivered by the end of that time it will be returned to you. No further action is required by you. Your message began as follows: -------------------- To: vxworks_users@vxw.ee.lbl.gov From: vxwexplo@lbl.gov (the vxWorks Users Group Exploder) Subject: comp.os.vxworks newsdigest Message-Id: <9301011200.AA12258@vxw.ee.lbl.gov> Submitted-by daemon@vxw.ee.lbl.gov Fri Jan 1 04:00:33 1993 Submitted-by: daemon@vxw.ee.lbl.gov Comp.Os.Vxworks Daily Digest Fri Jan 1 04:00:24 PST 1993 From daemon@vxw.ee.lbl.gov Wed Jan 6 04:00:44 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 6 04:00:55 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 6 04:00:35 PST 1993 Subject: VME based controllers and drivers for other buses? Subject: Looking for contact info for IBM/PC based realtime o/s vendors Subject: database for VxWorks Subject: Re: VME based controllers and drivers for other buses? ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus Subject: VME based controllers and drivers for other buses? Date: Tue, 5 Jan 1993 15:57:50 GMT From: mcgehee@noao.edu (Peregrine McGehee) Organization: National Optical Astronomy Observatories, Tucson AZ Message-ID: <1993Jan5.155750.14107@noao.edu> References: <9301030745.AA01864@hpmwtd.sr.hp.com> Sender: news@noao.edu Aloha, For part of control system for the Gemini 8 meter telescopes project, we are looking for VMEbus-based controllers for other buses. The purpose of using non-VME systems for some of our subsystems is to avoid placing a full VME crate in locations that are both remote and only performing simple, relatively low bandwidth tasks. My current list is: For BitBus: IST/DATEM DMC804 (the old XYCOM XVME-402) PEP Modular Computers Inc PB-BIT For GESPAC FILBUS: ?? For Profilbus (German standard fieldbus DIN 19245): ?? For CAN: ?? I understand that some of the buses can be controlled via various serial I/O cards but it would be alot more helpful to have a VMEbus module that understood the bus controller logic at the firmware level. Also, any known VxWorks drivers for the above could be useful as well. I have access to drivers for serial controllers and for the XVME-402. Thanks for your help, Peregrine - -- Peregrine M. McGehee Instrument Control Software Engineer Gemini 8-m Telescopes Project Internet: mcgehee@noao.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Looking for contact info for IBM/PC based realtime o/s vendors Date: Wed, 6 Jan 1993 00:00:29 GMT From: gday@ignatz.inde.bc.ca (Gordon Day) Organization: INDE Electronics, Inc. Message-ID: Sender: news@inde.bc.ca The Subject: line says it all. I am currently looking for any information I can get on available realtime o/s' based on the 80386 ISA bus IBM/PC platform. Any contact addresses or recommendations (for or against) would be _greatly_ appreciated. This is a new area for me (being primarily a Unix programmer) so I have no idea where to start looking. Some products I already have in mind (but no contact addresses) are: VXworks -- I know this is available for 68000-based systems, but IBM/PCs? iRMX -- available for IBM/PC QNX -- available for IBM/PC Others? Ta, Gordon. P.S.: I _will_ summarise if there is interest. _______________________________________________________________________________ gordon day, inde electronics, +1-403-430-1446. --------------------------- Newsgroups: comp.os.vxworks Subject: database for VxWorks Date: 6 Jan 93 01:29:17 GMT From: tzou@almaden.ibm.com (Shin-Yuan Tzou) Organization: IBM Almaden Research Center Keywords: vxworks, database, vendor software Message-ID: <2131@coyote.UUCP> Reply-To: tzou@almaden.ibm.com (Shin-Yuan Tzou) Sender: news@ibmarc.UUCP Are there vendors that provide database software for VxWorks? Thanks, Shin-Yuan Tzou tzou@almaden.ibm.com --------------------------- Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus Subject: Re: VME based controllers and drivers for other buses? Date: 6 Jan 93 11:12:51 GMT From: kai@ade.no (Kai Atle Myrvang) Organization: AD Elektronikk AS, Norway Message-ID: References: <1993Jan5.155750.14107@noao.edu> mcgehee@noao.edu (Peregrine McGehee) writes: > > My current list is: > > For BitBus: > IST/DATEM DMC804 (the old XYCOM XVME-402) > PEP Modular Computers Inc PB-BIT > > For GESPAC FILBUS: > ?? > > For Profilbus (German standard fieldbus DIN 19245): > ?? What about PEP Modular Computer's VIUC and VIUC30. They use the 68302 for the Profibus. Check with them regarding the software issue. I know it's there for OS-9. > Also, any known VxWorks drivers for the above could be useful as well. I have > access to drivers for serial controllers and for the XVME-402. There is a VxWorks driver for PEP's PB-BIT, according to their pricelist. kai@ade.no (Kai Atle Myrvang) AD Elektronikk AS, Norway | Keywords: VMEbus Phone: Int+479 869 970 | OS-9 Fax: Int+479 869 920 | VRTX --------------------------- End of New-News digest ********************** From calypso@palantir.gsfc.nasa.gov Wed Jan 6 06:34:03 1993 From: Dave Kim Date: Wed Jan 6 06:34:12 PST 1993 Subject: Gnu assember manual Hello everyone, I am looking for a good manual for gnu assembler manual, preferably one that is better than the one offered by WRS. I am an new comer to 68xxx assembly programming and having to port an assembly program written under PDOS operating system to VxWorks. If anyone out there have a good gnu as manual with examples and can share, I would appreciate it. In the mean time, can anyone help me convert following PDOS assembly code to gnu as: LEA 0(A4,D1.W),A1 Please send any response to calypso@palantir.gsfc.nasa.gov Thank you in advance. David Kim ps: I have already got gnu as distribution ftp files from MIT and found manuals are not part of the distribution. From visicom!VisiCom.COM!trest@nosc.mil Wed Jan 6 08:11:48 1993 From: Mike Trest Date: Wed Jan 6 08:12:05 PST 1993 Subject: Re: database for VxWorks >Shin-Yuan Tzou: >Are there vendors that provide database software for VxWorks? The real-time environment is not the ideal model for a DBMS. What we do is use client/server or RPC capabilities of VxWorks to talk to DBMS services elsewhere in a network. I have probably put as much SCSI disk & DAT tape on VxWorks as anyone, however, I would not attempt anything more than a symplistic DBMS where it is supported exclusively by VxWorks. Therefore, I suggest a marriage between a SUN/OS or UNIX DBMS embedded in the same cage with VxWorks real time boards. We have designed this solution into our customer systems which need access to DBMS by hard real-time applications. The real design critical issues are: 1. What is the allowable latency between the real-time need for data and DBMS data availability? 2. What is the frequency of DBMS read vice update? 3. Do you need multiple requesting real-time processes? 4. Do the requestors operate under a common "user" access profile? 5. Where will data integrity locks be handled? The conclusion offered of a marriage between VxWorks and a good DBMS still requires many *APPLICATION* design decisions. Good luck! And please keep me/us posted on your progress. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From daemon@vxw.ee.lbl.gov Thu Jan 7 04:00:54 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 7 04:01:04 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 7 04:00:43 PST 1993 Subject: Help! (75 seconds to connect() after reboot) Subject: Re: VME based controllers and drivers for other buses? Subject: Re: Help! (75 seconds to connect() after reboot) ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip Subject: Help! (75 seconds to connect() after reboot) Date: 6 Jan 93 19:14:11 GMT From: burch@seas.smu.edu (Chris Burchett) Organization: SMU - School of Engineering & Applied Science - Dallas Message-ID: <1993Jan6.191411.4535@seas.smu.edu> Sender: news@seas.smu.edu (USENET News System) Help! I've found a situation in which I'm unsure of the best solution. The problem has to do with a 75 second timeout in the connect() system call. This occurs after one of two previously connected machines is rebooted and an attempt is subsequently made to reestablish communication. I am using TCP/IP via Berkeley sockets to communicate between a Sun workstation and an embedded system running VxWorks. After communi- cation is established, the embedded system is rebooted. Once the reboot is finished an attempt is made to reestablish the connection, at which point, the connect() system call on the embedded system is unable to reconnect and times out after 75 seconds. I believe this may happen because the embedded system is using the same port number that was used for a connection before the reboot occured (while the remote machine still maintains an established connection on that port). It appears that (after a reboot) if the embedded system attempts to connect() using a port number which was not previously connected, the connection is immediately established; this is the desired behavior. However, if the embedded system uses a port which was previously connected, the connect() system call times out after 75 seconds. Unfortunately, in my application 75 seconds is somewhat too long to wait. I have a potential work around, but it seems to be sort of a kludge and I felt certain that this problem must be a known one with known solutions. (I'm relatively new to NEWS and if this is a topic which has already been discussed in depth or I have improperly used this service in any way, I appologize.) But if someone with insight into this problem would enlighten me on the issues involved, or documentation to be studied, or potential solutions, I would greatly appreciate the help. Chris Burchett email: burch@seas.smu.edu voice: (214) 205-8065 --------------------------- Newsgroups: comp.os.vxworks,comp.arch.bus.vmebus Subject: Re: VME based controllers and drivers for other buses? Date: 6 Jan 93 12:37:03 GMT From: meindert@inducom.nl (Meindert Kuipers) Organization: Inducom Systems BV, Oss, Netherlands Message-ID: <3450@inducom.nl> References: <1993Jan5.155750.14107@noao.edu> Followup-To: comp.os.vxworks From article <1993Jan5.155750.14107@noao.edu>, by mcgehee@noao.edu (Peregrine McGehee): > Aloha, > > For part of control system for the Gemini 8 meter telescopes project, we are > looking for VMEbus-based controllers for other buses. The purpose of using > non-VME systems for some of our subsystems is to avoid placing a full VME > crate in locations that are both remote and only performing simple, relatively > low bandwidth tasks. > For BitBus: > For GESPAC FILBUS: > For Profilbus (German standard fieldbus DIN 19245): > For CAN: M304 Bitbus controller with 8044 M360 CAN controller M314 Intelligent serial controller with MC68302, should work with FILbus or Profibus, also an alternative for Bitbus The above boards come with driver software in source code. All boards are M-modules. Four can be plugged on a 6U VMEbus baseboard. There are currently six manufacturers for M-modules. - -- Meindert Kuipers PO Box 627, NL 5340 AP OSS /\ /~~~\ meindert@inducom.nl Phone: (31)4120-51055 /--\ | | AcQuisition Techonoly BV Fax: (31)4120-51050 / \ \__\/ ****** Manufacturers of M-modules and VMEbus boards C \ --------------------------- Newsgroups: comp.os.vxworks,comp.unix.bsd,comp.protocols.tcp-ip Subject: Re: Help! (75 seconds to connect() after reboot) Date: 6 Jan 93 23:44:22 GMT From: hwajin@iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <1993Jan6.191411.4535@seas.smu.edu> In article <1993Jan6.191411.4535@seas.smu.edu> burch@seas.smu.edu (Chris Burchett) writes: >Unfortunately, in my application 75 seconds is somewhat too long >to wait. in vxworks 5.0+, there is an undocumented call -- connectWithTimeout() which takes the same args as connect() plus extra last arg of type 'struct timeval *' which you may be able to use -- you can specify the delay of your own. or you could also just try non-blocking connect() -- set socket FIONBIO temporarily, call connect(), which should return EINPROGRESS immediately if connect attempt is to block -- when this happens you should select() for 'write'. the socket will be marked writeable once's it's connected. to verify the connection after select() returns with 'write' selected, you can do a getpeername(). this is actually what connectWithTimeout() does. [ i do hope this is still in vxworks, it was a few years back when i put this into the system ] hwajin --------------------------- End of New-News digest ********************** From gdfwc3!kuwait!billb@texsun.central.sun.com Thu Jan 7 12:23:32 1993 From: billb%kuwait@sun.com (Bill Baumann) Date: Thu Jan 7 12:23:41 PST 1993 Subject: Forwarding of MAC broadcasts VxWorks is causing problems by forwarding broadcast messages. Here's the deal : I have a development system that is broadcasting over FDDI to a specific IP address. The IP address is a Unix box, and the FDDI MAC address is a broadcast. I'm using the AP Labs driver. On my analyzer I see the broadcast message being retransmitted by the VxWorks based cage. The messages are UDP/IP, so the Unix machine sees both the broadcast, and the retransmitted message. It appears to me that VxWorks is doing IP forwarding of broadcast messages. This is a definate no no. Does anyone have any experience with this? Does anyone know how to turn this behavior off? Thanks BillB. From gdfwc3!kuwait!billb@texsun.central.sun.com Thu Jan 7 14:57:49 1993 From: billb%kuwait@sun.com (Bill Baumann) Date: Thu Jan 7 14:58:01 PST 1993 Cool. I don't think I've played in a pool yet. Do it. later, billb. From thoff@netxwest.com Thu Jan 7 15:42:48 1993 From: thoff@netxwest.com (Todd Hoff) Date: Thu Jan 7 15:43:05 PST 1993 Subject: Problem with broadcasts I'm having problems sending broadcasts over our network and would like some help. The code that works on just a Sun network doesn't work under VxWorks, and neither does the VxWorks demo code-- just to show I'm not totally stupid :-) The test involves 2 machines X and Y. Some vitals are specified below. When I send directly from X to Y then Y receives the message, no problem. When I send to a broadcast address of 144.10.5.255 the message doesn't arrive. The reciever is setup to recieve for any address. I set the socket option for BROADCAST to on. Any ideas? Any good debugging tips? Thanx for any help. There is a Sun router on the network with an IP address of 144.10.2.6. The interface definition for machine X is: ln (unit number 0): Flags: (0x63) UP BROADCAST ARP RUNNING Internet address: 144.10.5.33 Broadcast address: 144.10.5.255 Netmask 0xffff0000 Subnetmask 0xffffff00 Ethernet address is 00:c0:21:01:02:21 Metric is 0 Maximum Transfer Unit size is 1500 3633 packets received; 868 packets sent 0 input errors; 0 output errors 0 collisions Machine Y is the same accept the IP address is 144.10.5.63. Our route table is: ROUTE NET TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 0.0.0.0 144.10.5.2 3 2 746 ln0 144.10.0.0 144.10.5.33 1 2 137 ln0 ------------------------------------------------------------------------ ROUTE HOST TABLE destination gateway flags Refcnt Use Interface ------------------------------------------------------------------------ 127.0.0.1 127.0.0.1 5 0 0 lo0 From gdfwc3!kuwait!billb@texsun.central.sun.com Thu Jan 7 16:06:17 1993 From: billb%kuwait@sun.com (Bill Baumann) Date: Thu Jan 7 16:06:26 PST 1993 Subject: Forwarding of ... & stupidness Forget that last message. My mailer got out of control. Please respond to the MAC broadcast question to baumann@gdwest.gd.com thanks BillB. From vxworks@mars.psf.ge.com Thu Jan 7 21:42:02 1993 From: vxworks@mars.psf.ge.com (vx_works) Date: Thu Jan 7 21:42:13 PST 1993 Subject: MVME14x Diagnostics coexisting with VADSWorks We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard power-on-diagnostics. We have a project requirement to run some level of board readiness tests without resorting to swapping the Motorola PROMS back in. I've got a call in to Motorola to see about the availability of their diagnostic source code, but I'm wondering how other folks have dealt with this problem. Has anyone developed downloadable diagnostic or readiness tests (or adapted Motorola's code) for this situation? John E. Thier GE Defense Systems Dept. Pittsfield MA vxworks_list@mars.psf.ge.com From daemon@vxw.ee.lbl.gov Fri Jan 8 04:00:34 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 8 04:00:44 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 8 04:00:23 PST 1993 Subject: RPC's Subject: Re: RPC's Subject: Booting from tape Subject: text editor for VxWorks ? Subject: Re: Forwarding of MAC broadcasts Subject: VX Works for MVME104 ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: RPC's Date: Thu, 7 Jan 1993 14:32:48 GMT From: sapp@falcon.ssc.gov (Kevin Sapp) Organization: Superconducting Super Collider Laboratory, Dallas Message-ID: <1993Jan7.143248.12461@sunova.ssc.gov> Sender: usenet@sunova.ssc.gov (News Admin) Greetings, I have been working with VxWorks for a couple of weeks now, so I,m at the dangerous stage ! I have RPC's working between a Sparc2 and a VxWorks MVME147, but only at the shell. When I execute the RPC server directly from the shell everything works fine. When I do a taskSpawn 100,0,20000,myRpcTest the program dies down in the pmap_unset function during an indirect function call off of (a1), the address that it is trying to call causes a bus error. When doing the rpcgen I used the sun rpcgen to produce the client, server, and .h files for both the sun and vxworks (is this OK?). Any halp would be appreciated. Also, is there a FAQ for this group? Where? Is there a mail list ? How? Thankx Kevin. - -- - ---------------------------------------------------------------------------- Kevin A. Sapp "A civilization depends upon the quality Superconducting Super Collider of individual it creates" (Dune) sapp@sawdust.ssc.gov :>( please NO NeXT mail --------------------------- Newsgroups: comp.os.vxworks Subject: Re: RPC's Date: Thu, 7 Jan 1993 16:26:15 GMT From: geoff@wrs.com (Geoff Espin) Organization: Wind River Systems, Inc. Message-ID: References: <1993Jan7.143248.12461@sunova.ssc.gov> Sender: news@wrs.com (News Manager) sapp@falcon.ssc.gov (Kevin Sapp) writes: >I have RPC's working between a Sparc2 and a VxWorks MVME147, but only >at the shell. When I execute the RPC server directly from the shell >everything works fine. When I do a taskSpawn 100,0,20000,myRpcTest >the program dies down in the pmap_unset function during an indirect >function call off of (a1), the address that it is trying to call >causes a bus error. Did you call rpcTaskInit()? rpcTaskInit() - initialize a task's access to the RPC package This routine must be called by a task before it makes any calls to other routines in the RPC package. WRS' RPC is a port of the standard Sun distribution which contains numerous static variables making it non-reentrant. Task variables are used to make the statics task specific, therefore rpcTaskInit() must be called before making any RPC calls in a new task context. Geoff - -- Geoff Espin geoff@wrs.com (510)748-4100 Wind River Systems 1010 Atlantic Avenue Alameda CA 94501 --------------------------- Newsgroups: comp.os.vxworks Subject: Booting from tape Date: 7 Jan 93 16:30:57 GMT From: jcreem@Rapnet.Sanders.Lockheed.Com (Jeffrey M. Creem x5700) Organization: Sanders Associates Keywords: SCSI, booting, tape Message-ID: <1993Jan7.163057.19982@Rapnet.Sanders.Lockheed.Com> Has anyone tried booting vxWorks from a SCSI tape (in our case exabyte 8500) on a mv167? We are currently exploring several boot options and are trying to come up with the best method. Jeff Creem --------------------------- Newsgroups: comp.os.vxworks Subject: text editor for VxWorks ? Date: 7 Jan 93 18:09:59 GMT From: jprice@lds.loral.com (Jeffrey Price) Organization: Loral Data Systems Keywords: editor vi text edit Message-ID: <1993Jan7.180959.4005@lds.loral.com> Reply-To: jprice@lds.loral.com Sender: news@lds.loral.com Rumor has it that there are some text editors out there in the ether somewhere that run under VxWorks. I have even heard that a copy the beloved "vi" editor exists for VxWorks. Can anyone confirm or deny these rumors, and if they are true where might one get one of these ? Thanks, Jeff Price 813-371-0811 x6823 email : jprice@mail.lds.loral.com --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Forwarding of MAC broadcasts Date: Thu, 7 Jan 1993 21:56:12 GMT From: healy@nosc.mil (Mike Healy) Organization: Naval Ocean Systems Center, San Diego Message-ID: <1993Jan7.215612.8985@nosc.mil> References: <9301071938.AA09078@kuwait.whizkids> In article <9301071938.AA09078@kuwait.whizkids> billb%kuwait@sun.com (Bill Baumann) writes: >VxWorks is causing problems by forwarding broadcast messages. > >Here's the deal : I have a development system that is broadcasting over >FDDI to a specific IP address. The IP address is a Unix box, and the >FDDI MAC address is a broadcast. I'm using the AP Labs driver. > >On my analyzer I see the broadcast message being retransmitted by the VxWorks >based cage. The messages are UDP/IP, so the Unix machine sees both the >broadcast, and the retransmitted message. > >It appears to me that VxWorks is doing IP forwarding of broadcast messages. >This is a definate no no. > >Does anyone have any experience with this? > >Does anyone know how to turn this behavior off? > >Thanks BillB. > I ran into something similar just this morning. We are using UDP/IP broadcast datagrams for one of our protocols. We have a multiprocessor system in which each ethernet port is handling a different simulation protocol (DIS, SIMNET, ...). I found that in the board with the non- UDP/IP protocol, where my input hook would return any UDP/IP broadcast datagrams to the vxWorks's protocol stack, the other board was receiving the broadcast datagram twice. I thought the board was forwarding the datagram onto the backplane network and that's why the other board was getting the datagram twice - the original datagram from the ethernet, and then the same datagram forwarded over the backplane network. However, this post seems to indicate a more pathological situation. My fix was to trap these bad boys in my ethernet hook input and toss them, but obviously this is not general purpose and somewhat of a kludge. This sounds like a job for . . . WRS!! :-) Mike Healy healy@nosc.mil --------------------------- Newsgroups: comp.os.vxworks Subject: VX Works for MVME104 Date: Fri, 8 Jan 1993 03:33:21 GMT From: raob@mullian.ee.mu.oz.au (r. oxbrow) Organization: Electrical and Electronic - University of Melbourne Message-ID: <9300814.7765@mulga.cs.mu.OZ.AU> Sender: news@cs.mu.OZ.AU Does anybody run VX works on a Motorola MVME-104 board ? thanks, richard/.. richard oxbrow |internet raob@mullian.ee.mu.OZ.AU dept. ee eng, uni of melbourne |uunet ..!uunet!munnari!mullian!raob parkville, victoria 3052 |fax +[613] 344 6678 australia |phone +[613] 344 6782 --------------------------- End of New-News digest ********************** From gordon@tpocc.gsfc.nasa.gov Fri Jan 8 04:51:24 1993 From: gordon@tpocc.gsfc.nasa.gov (Gordon Miller) Date: Fri Jan 8 04:51:34 PST 1993 Subject: Re: RPC's sapp@falcon.ssc.gov (Kevin Sapp) writes: >I have RPC's working between a Sparc2 and a VxWorks MVME147, but only >at the shell. When I execute the RPC server directly from the shell >everything works fine. When I do a taskSpawn 100,0,20000,myRpcTest >the program dies down in the pmap_unset function during an indirect >function call off of (a1), the address that it is trying to call >causes a bus error. I am surprised this works from the shell. A quick look at the manual shows that your arguement list could be the problem. The call taskSpawn has a usage as follows: int taskSpawn (name, priority, options, stackSize, entryPt, arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9,arg10) where char *name; /* name of the new task */ int priority; /* priority of the new task */ int options; /* task option word */ int stackSize; /* size of stack, be generous */ FUNCPTR entryPt; /* entry point of new task */ int arg1; /* task arguement one */ int arg2; /* task arguement two */ int arg3; /* task arguement three */ int arg4; /* task arguement four */ int arg5; /* task arguement five */ int arg6; /* task arguement six */ int arg7; /* task arguement seven */ int arg8; /* task arguement eight */ int arg9; /* task arguement nine */ int arg10; /* task arguement ten */ If taskSpawn line you used really is as stated in your post, then you forgot the name for the new task, shifting the entire arguement list off by one. The results of this are unknown to me. If you do not need to worry about the priority, options, stack size and name (for referencing the task from the shell), you could use call "sp". This will spawn a task with the default parameters. Its usage is as follows: int sp (func, arg1,arg2,arg3,arg4,arg5,arg6,arg7,arg8,arg9) where FUNCPTR func; /* entry point of new task */ int arg1,arg2,arg3; /* passed to spawned task */ int arg4,arg5,arg6; /* passed to spawned task */ int arg7,arg8,arg9; /* passwd to spawned task */ Jason's comments about RPC needed to be initialized (and built into your vxWorks kernel) are still valid. Hope this helps. Gordon Miller Integral Systems, Inc. gordon@tpocc.gsfc.nasa.gov 1100 West Street CSC/LR (301) 497-2416 Laurel, MD 20707 From fjr@rayssd.ssd.ray.com Fri Jan 8 06:39:32 1993 From: Roeber Date: Fri Jan 8 06:39:42 PST 1993 Subject: Re: text editor for VxWorks ? Jeff Price writes: > Rumor has it that there are some text editors out there in the ether > somewhere that run under VxWorks. I have even heard that a copy the > beloved "vi" editor exists for VxWorks. > > Can anyone confirm or deny these rumors, and if they are true > where might one get one of these ? The VxWorks archive has a copy of stevie in it (a vi clone). Sorry but I haven't used it under VxWorks but it is probably what you want. Fred ---------- Subject: Monthly VxWorks archive posting Submitted-by thor@thor.atd.ucar.edu Tue Dec 31 22:59:28 1992 Submitted-by: thor@thor.atd.ucar.edu (Richard Neitzel) This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: -rw-r--r-- 1 thor 41196 Oct 16 09:43 stevie01 -rw-r--r-- 1 thor 35279 Oct 16 09:43 stevie02 -rw-r--r-- 1 thor 35278 Oct 16 09:43 stevie03 -rw-r--r-- 1 thor 35012 Oct 16 09:43 stevie04 -rw-r--r-- 1 thor 34502 Oct 16 09:43 stevie05 -rw-r--r-- 1 thor 37476 Oct 16 09:43 stevie06 -rw-r--r-- 1 thor 30073 Oct 16 09:43 stevie07 -rw-r--r-- 1 thor 31562 Oct 16 09:43 stevie08 -rw-r--r-- 1 thor 37360 Oct 16 09:43 stevie09 -rw-r--r-- 1 thor 20662 Oct 16 09:43 stevie10 -rw-r--r-- 1 thor 25717 Oct 16 09:43 stevie11 -rw-r--r-- 1 thor 28075 Oct 16 09:43 stevie12 -rw-r--r-- 1 thor 31852 Oct 16 09:43 stevie13 From baumann@proton.llumc.edu Fri Jan 8 10:01:41 1993 From: baumann@proton.llumc.edu (Michael Baumann) Date: Fri Jan 8 10:01:56 PST 1993 Subject: Re: RPC's >Submitted-by: gordon@tpocc.gsfc.nasa.gov (Gordon Miller) > > >sapp@falcon.ssc.gov (Kevin Sapp) writes: > >>I have RPC's working between a Sparc2 and a VxWorks MVME147, but only >>at the shell. When I execute the RPC server directly from the shell >>everything works fine. When I do a taskSpawn 100,0,20000,myRpcTest >>the program dies down in the pmap_unset function during an indirect >>function call off of (a1), the address that it is trying to call >>causes a bus error. > >I am surprised this works from the shell. I'm not. Odds are he uses NFS for some functions, this allows: 1) RPC to be loaded 2) rpcTaskInit() is run for the shell. So his server gets the shells task vars. When you spawn a process, that process MUST run rpcTaskInit(), or you don't get the needed task variables added to the task context. This should be done long before you even consider opening a dialoge (so to speak) with the portmapper. Michael Baumann Radiation Research Lab |Internet: baumann@proton.llumc.edu Loma Linda Universtiy Medical Center | UUCP: ...ucrmath!proton!baumann Loma Linda, California. (714)824-4077| From woody@sparta.com Fri Jan 8 15:25:36 1993 From: woody@sparta.com (Robert "Woody" Woodburn) Date: Fri Jan 8 15:25:45 PST 1993 Subject: peregrine 4211 driver for v3d running 5.0.2 Hi, We're in the processing of working with Interphase to port the 4211 FDDI driver to the i960. As a first step, we wanted to get the driver running on one of our more familiar 68k platforms, just as a reference. But the driver doesn't seem to work out of the box. We have version 1.2. It appears that the setup_bufs routine is trashing something before it returns. Has anybody got the driver running on a v3d? I thought I'd check before I start digging too far... Thanks wood y (woody@sparta.com) From daemon@vxw.ee.lbl.gov Sat Jan 9 04:00:50 1993 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 9 04:01:00 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 9 04:00:40 PST 1993 Subject: mv167/vmechip2 dma library Subject: Re: Forwarding of MAC broadcasts Subject: Re: Problem with broadcasts ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: mv167/vmechip2 dma library Date: Fri, 8 Jan 1993 17:15:13 GMT From: geger@phantom.den.mmc.com (George Eger (303) 971-6974) Organization: Martin Marietta Astronautics Group Keywords: mv167 vmechip2 dma Message-ID: <1993Jan8.171513.11601@den.mmc.com> Sender: news@den.mmc.com (News) Has anyone out there got a basic library to run the vmechip2's dma controller on a mv167? I am looking for something like: dmaInit(); dmaGet(to, from, length); dmaPut(to, from, length); and an optional routine to set non-blocking, completion notification, bus priority levels and modes, and abort: dmaIoctl(...); If not, we are going to build one and will post it. Thanks, GWE ||========================================================================== ||George Eger / geger@den.mmc.com || Voice - (303) - 971 - 6974 || ||Fault Tolerant Avionics || Fax - (303) - 977 - 1145 || ||Launch Systems || MS T320 || ||Martin Marietta Astro Group || P.O. Box 179, Denver CO 80201 || ||========================================================================== ||We are at a cusp - between the past when humans were more reliable than || ||computers and the future when computers are more reliable than humans. || ||========================================================================== ||All opinions (however truthful or misinformed) are my own. || ||========================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Forwarding of MAC broadcasts Date: Sat, 9 Jan 1993 09:38:18 GMT From: hjb@netcom.com (H. J. Bae) Organization: Peaceful Star, Inc. Message-ID: <1993Jan9.093818.3283@netcom.com> References: <9301071938.AA09078@kuwait.whizkids> In article <9301071938.AA09078@kuwait.whizkids> billb%kuwait@sun.com (Bill Baumann) writes: >It appears to me that VxWorks is doing IP forwarding of broadcast messages. >This is a definate no no. since nobody has answered this one so far -- as far as i know vxworks does not forward broadcast ip packets. grab a copy of ip_input.c from 4.3 bsd tahoe release, which is essentially used unchanged in vxworks 5.0 -- and read it. the ip_forward() is *not* called for the broadcast packets. possible source of error: either interface is not configured correctly with proper broadcast address which matches the net/subnet mask, or a problem with the driver itself -- not likely. i'd like to find out more about various configurations, details, etc. hwajin --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Problem with broadcasts Date: Sat, 9 Jan 1993 09:40:29 GMT From: hjb@netcom.com (H. J. Bae) Organization: Peaceful Star, Inc. Message-ID: <1993Jan9.094029.3491@netcom.com> References: <9301072246.AA11015@cinnabar.netx.com> In article <9301072246.AA11015@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes: >The interface definition for machine X is: >ln (unit number 0): > Flags: (0x63) UP BROADCAST ARP RUNNING > Internet address: 144.10.5.33 > Broadcast address: 144.10.5.255 > Netmask 0xffff0000 Subnetmask 0xffffff00 ^^^^^^^^^^^ > >Our route table is: >ROUTE NET TABLE >destination gateway flags Refcnt Use Interface >------------------------------------------------------------------------ >0.0.0.0 144.10.5.2 3 2 746 ln0 >144.10.0.0 144.10.5.33 1 2 137 ln0 >------------------------------------------------------------------------ > trying adding a net route entry for 144.10.5.0 subnet? hwajin --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Jan 10 04:03:27 1993 From: daemon@vxw.ee.lbl.gov Date: Sun Jan 10 04:03:36 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jan 10 04:03:18 PST 1993 Subject: Re: Forwarding of MAC broadcasts ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Forwarding of MAC broadcasts Date: Sun, 10 Jan 1993 03:17:14 GMT From: rypma@waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: References: <9301071938.AA09078@kuwait.whizkids> Sender: news@waterloo.hp.com (NetNews) Bill Baumann (billb%kuwait@sun.com) wrote: : VxWorks is causing problems by forwarding broadcast messages. : : Here's the deal : I have a development system that is broadcasting over : FDDI to a specific IP address. The IP address is a Unix box, and the : FDDI MAC address is a broadcast. I'm using the AP Labs driver. I just read Hwa Jin's response to this and I think I have a glimmering of an explaination. Note that the _MAC_ address is a broadcast and the _IP_ address is not. Now, one of the (many) failings of BSD 4.3 network code is the fact that the "broadcastness" of the incoming frame is lost once you get into IP protocol code. If the IP address is not broadcast, whether legitimately so or as a result of a misunderstood subnet broadcast (due to incorrect or no subnet mask), IP will forward if so configured. Of course, it REALLY should NOT be forwarded because the MAC address was broadcast - information that BSD 4.3 Tahoe quietly throws away. BSD Networking Release 2 code nicely fixes this (I'm not sure whether Reno code does or not, but it may). We had the same problem in VxWorks 5.0.3 network code causing problems when multiple subnets were in use on the same wire - we would forward another subnet's broadcasts. I fixed this in our VxWorks networking code by just not forwarding frames which would be retranmitted on the same interface on which they came in. Not an ideal solution, but it looked after the immediate problem (besides, we don't claim to be an ideal IP router and we're not a workstation :-). Regards, Ted Rypma HP Panacom Division --------------------------- End of New-News digest ********************** From thoff@netxwest.com Sun Jan 10 07:25:13 1993 From: thoff@netxwest.com (Todd Hoff) Date: Sun Jan 10 07:25:29 PST 1993 Subject: More on broadcast problem With the help of the Sniffer we pinned down why IP broadcasts are not being recieved. It appears when using a subnetmask that differs from netmask then broadcast IP addresses are not translated to the broadcast ethernet address. With: 1. IP Address = 144.10.5.33 2. Mask = 0xffff0000 3. Subnetmask = 0xffffff00 4. Broadcast Address= 144.10.5.255 The ethernet address of the packet goes to our router, not the expected broadcast ethernet address. With: 1. IP Address = 144.10.5.33 2. Mask = 0xffff0000 3. Subnetmask = 0xffff0000 4. Broadcast Address= 144.10.255.255 The broadcast works fine, the ethernet address is all 1s as expected. The suggestion here is that code resolving IP addresses isn't looking at the subnet mask. Is seems the broadcast IP address is not recognized as such and is forwarded to the router where the router of course will not forward the broadcast. BTW, various manipulations of the route tables had no effect. I suppose this is a bug. From daemon@vxw.ee.lbl.gov Mon Jan 11 04:00:50 1993 From: daemon@vxw.ee.lbl.gov Date: Mon Jan 11 04:01:00 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Jan 11 04:00:40 PST 1993 Subject: Re: Forwarding of MAC broadcasts Subject: Re: More on broadcast problem ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Forwarding of MAC broadcasts Date: Sun, 10 Jan 1993 14:04:15 GMT From: hjb@netcom.com (H. J. Bae) Organization: Peaceful Star, Inc. Message-ID: <1993Jan10.140415.1003@netcom.com> References: <9301071938.AA09078@kuwait.whizkids> In article rypma@waterloo.hp.com (Ted Rypma) writes: >I just read Hwa Jin's response to this and I think I have a glimmering of >an explaination. > >Note that the _MAC_ address is a broadcast and the _IP_ address is not. >Now, one of the (many) failings of BSD 4.3 network code is the fact that >the "broadcastness" of the incoming frame is lost once you get into IP >protocol code. If the IP address is not broadcast, whether legitimately so >or as a result of a misunderstood subnet broadcast (due to incorrect or no >subnet mask), IP will forward if so configured. Of course, it REALLY should >NOT be forwarded because the MAC address was broadcast - information that >BSD 4.3 Tahoe quietly throws away. > >BSD Networking Release 2 code nicely fixes this (I'm not sure whether Reno >code does or not, but it may). as always, ted is quite correct about this. [ah... so that's what that datalink bcast flags/stuff was all about in net2 code, silly me] of course, if things are done "correctly" (correct subnet masks, correct ip broadcast addr derived from subnet mask, etc.) the problem should not occur. thanks. hwajin - -- Peaceful Star Project hjb@netcom.com 2899 Ford Street Available for peaceful, responsible work only. Oakland, CA 94601 (510) 536-7607 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: More on broadcast problem Date: Sun, 10 Jan 1993 18:40:53 GMT From: hjb@netcom.com (H. J. Bae) Organization: Peaceful Star Project Message-ID: <1993Jan10.184053.9292@netcom.com> References: <9301081857.AA11564@cinnabar.netx.com> In article <9301081857.AA11564@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes: >The suggestion here is that code resolving IP addresses isn't looking >at the subnet mask. Is seems the broadcast IP address is not recognized >as such and is forwarded to the router where the router >of course will not forward the broadcast. here's in_broadcastaddr() from the tahoe code: /* * Return 1 if the address might be a local broadcast address. */ in_broadcast(in) struct in_addr in; { register struct in_ifaddr *ia; u_long t; /* * Look through the list of addresses for a match * with a broadcast address. */ for (ia = in_ifaddr; ia; ia = ia->ia_next) if (ia->ia_ifp->if_flags & IFF_BROADCAST) { if (satosin(&ia->ia_broadaddr)->sin_addr.s_addr == in.s_addr) return (1); /* * Check for old-style (host 0) broadcast. */ if ((t = ntohl(in.s_addr)) == ia->ia_subnet || t == ia->ia_net) return (1); } if (in.s_addr == INADDR_BROADCAST || in.s_addr == INADDR_ANY) return (1); return (0); } the only reason this could fail would be some incorrect configuration some where (at some participating node). if you're suspecting vxworks for not recognizing subnet bcast ip address as such, you can call in_broadcast from the shell or write a small piece of code to find out. using the shell's built-in debugger (assembly) you could single step to track down the exact behavior, if you'd like. but, as the code says, if netif bcast ip address is incorrectly set on some node, this code will return 0. if you have a traditional network (the one that has one network/subnet per physical segment of ethernet) and your target machine is not multi-homed, it is also legal to use all 1's ip address to indicate "broadcast to the immediately attached networks only". trying "255.255.255.255", for example, should work and you can avoid the headaches. the issue regarding the route entry: ip_output() has to be able to resolve the route entry for the given destination address -- to fetch the netif pointer used throughout (including arpresolve process which uses in_broadcast before actually sending out any arp req's). i'd still maintain that you need to keep correct route tables for the subnets. given that, and given that the correct netif (which will be in the route entry returned by rtalloc) has correct broadcast address proper for the subnet, things should work. all participating machines should be checked for this. [as i'm not still sure of your exact configuration] if someone has any insight, i'm very interested to hear... [guess i'm just very very curious.... :-) ] thanks hwajin - -- Peaceful Star Project hjb@netcom.com 2899 Ford Street Available for peaceful, responsible work only. Oakland, CA 94601 (510) 536-7607 --------------------------- End of New-News digest ********************** From phil@naic.edu Mon Jan 11 06:08:18 1993 From: phil@naic.edu (Phil Perillat Rm 407 X286) Date: Mon Jan 11 06:08:27 PST 1993 Subject: dma routines for motorola vmechip2 Georoge Eger writes.... Has anyone out there got a basic library to run the vmechip2's dma controller on a mv167? I am looking for something like: dmaInit(); dmaGet(to, from, length); dmaPut(to, from, length); and an optional routine to set non-blocking, completion notification, bus priority levels and modes, and abort: dmaIoctl(...); If not, we are going to build one and will post it. ........ Be careful doing dma with the mv167 board. The vmechip2 has two bugs that might bite (i still remember the weeks i spent scratching these bites!!) 1. dma xfers in d16, fifomode don't work. We have an a/d board that looks like a fifo in A16 space. I was accessing it with dma in D16 (i had used up all of the mappings...). Turns out that the chip needs the vmebus address to increment so it can route the D16 data onto the 32bit local bus. this will not be a problem for most people since they probably won't use this mode... 2. If you are doing dma with the vmechip2, and an interrupt comes in for the same board, things get trashed. When the interrupt arrives, the vmechip2 does not wait for the dma controller to give up the vme bus before it drives the interrupt acknowledge information onto the vme bus. The interrupt level for the acknowledge gets or'ed onto address bits a03-a01 while the dma xfer is still active. This will cause the dma address for the dma to be corrupted. Motorola's fix for this is to disable vme interrupts for the vmechip2 that is doing dma. On the plus side, i was impressed with the dma performance i saw. The vmechip2 would run the a/d card at it's stated maximum rate. The setup times for the various vmebus handshakes were what the vme standard says (and nothing more!). I struggled with these problems for awhile ... turns out motorola had already found them (just ask them for their tech notes on the vmechip2 bugs). They claim to have a silicon fix that should come out in early '93 (last i heard..). by the way, i've got a set of routines to setup and do the dma. I kinda let them slide once i ran into these problems so they need a little documentation and probably a little more testing. If you really want them i guess i could put them in some kind of humanly readable form.... phil perillat arecibo observatory phil@naic.edu From daemon@vxw.ee.lbl.gov Tue Jan 12 04:00:48 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 12 04:00:58 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 12 04:00:37 PST 1993 Subject: performance of fprintf() for floating point ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: performance of fprintf() for floating point Date: Mon, 11 Jan 1993 21:12:42 GMT From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) Organization: National Center for Atmospheric Research Message-ID: <1993Jan11.211242.16776@ncar.ucar.edu> Sender: news@ncar.ucar.edu (USENET Maintenance) I am having a performance problem with fprintf(). I have an application that samples antenna position at 15 Hz, and stores the binary positions in a dynamically allocated buffer. When I'm done sampling, I convert from binary to floating point (angles in degrees), and write the values in ASCII, using the following loop: for (ULONG i= 0; i < CSampleCount_; ++i) { fprintf(Cfout_, "%8.2f %8.2f\n", p->az * BIN_TO_DEG, p->el * BIN_TO_DEG); ++p; } On a MVME133 (68020 @ 20Mhz), running under VxWorks 5.02b, release 1, I can only write 3-4 lines/second, even if I'm writing to "/null". The MVME133 has a co-processor, and I can't figure out what could possibly be taking so long . . I suppose I could convert from binary to ASCII floating point on my networked Sun SPARC instead, but this solution isn't as "clean". - -- Joe VanAndel Internet:vanandel@ncar.ucar.edu National Center for Atmospheric Research --------------------------- End of New-News digest ********************** From fjr@rayssd.ssd.ray.com Tue Jan 12 07:29:49 1993 From: Roeber Date: Tue Jan 12 07:29:59 PST 1993 Subject: Re: performance of fprintf() for floating point Joe Van Andel writes: > On a MVME133 (68020 @ 20Mhz), running under VxWorks 5.02b, release 1, I > can only write 3-4 lines/second, even if I'm writing to "/null". The > MVME133 has a co-processor, and I can't figure out what could possibly > be taking so long . . Below is an old message on the subject: ---------- Begin Forwarded Message ---------- I did some grinding and got the cvtb (2) routine to go much faster. The Results: Hardware: mvme133xt, 25MHz, 68020 Test: timexN sprintf, y, "%7.2lf", x Old cvtb (2) without floating point CP: 33 ms Old cvtb (2) with floating point CP: 16 ms New cvtb (2) without floating point CP: 9 ms New cvtb (2) with floating point CP: 2 ms That is about as good as I'm going to get it without spending much more time. But is this fast enough for you? Your whole conversion will still take 10-15 ms. (15 times faster) That's well above your motor latency. So tell me what you want... I can give you a new floatLib.o for your library. Or if you want to try to grind this code some more I could even send you source to floatLib.c. The moral of the story is floating point conversions to ascii are very expensive operations. Not too much I can do about that. John Fogelin Wind River Systems ---------- Begin Forwarded Message ---------- At a later point Alan Biocca posted a routine for fast printing of floating point numbers on 680X0 processors. I am not sure but the routine might be in the VxWorks archive. Fred _______________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | fjr@ssd.ray.com | |_______________________________________________________| From jcn@mpl.ucsd.edu Tue Jan 12 08:28:01 1993 From: jcn@mpl.ucsd.edu (Chris Nickles) Date: Tue Jan 12 08:28:14 PST 1993 Subject: Re: performance of fprintf() for floating point Another approach, if you don't mind a little nitty-gritty, would be to scale the data as an integer in small units, e. g. tenths or hundredths of a degree, and then stuff a dot into the output string. Chris Nickles UCSD Marine Physical Lab From daemon@vxw.ee.lbl.gov Wed Jan 13 04:00:50 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 13 04:01:02 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 13 04:00:40 PST 1993 Subject: sgi CC v3.1 & VxGDB incompatible Subject: vxWorks Sockets and Pipes Subject: Re: vxWorks Sockets and Pipes Subject: Re: sgi CC v3.1 & VxGDB incompatible Subject: Re: performance of fprintf() for floating point ------------------------------------------------------- Newsgroups: comp.os.vxworks,comp.sys.sgi Subject: sgi CC v3.1 & VxGDB incompatible Date: 12 Jan 93 10:16:38 -0400 From: dyer@nrlvx1.nrl.navy.mil (Doug Dyer) Organization: NRL SPACE SYSTEMS DIVISION Message-ID: <1993Jan12.101638.901@nrlvx1.nrl.navy.mil> Hi folks, I am using an SGI indigo r3000 as a vxworks host (Iris 4D1-4.1) with cc (v3.10) and VxGDB to debug software (v1.1). The following problems occur when I load a file into the debugger: if the source code has a "struct" in it : unknown symbol type 1a if the source code has a "union" in it: unknown symbol type 1b The vxworks tech support mentions that these messages come from the GNU gdb kernel which they use, and mentioned that these problems do not occur with atleast version 2.0 of the cc compiler. has anyone had this problem and solved it? is all I need an older version of the C compiler? - -- Doug Dyer * STI * dyer@nrlvax.nrl.navy.mil | "(2B) | !(2B) -> ?" DISCLAIMER: These are my opinions, and not necessarily | LOWLY SHOPKEEPER, those of STI, NRL, and most likely you too. | WHERE IS YOUR PEZZ! - --------------------------------------------------------+--------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: vxWorks Sockets and Pipes Date: Tue, 12 Jan 1993 20:19:21 GMT From: dog@xdev.sunspot.noao.edu (Fritz Stauffer) Organization: Computer, Hardware and Observatory Support Message-ID: <1993Jan12.201921.4490@nmsu.edu> Sender: usenet@nmsu.edu I am porting pdtar to vxWorks. It works on local disk systems just fine. Now, I am writing the remote transfer stuff. I spawn a task which creates a pipe to replace the tar file descriptor. The spawned task runs rcmd to 'dd' on a unix host for the remote I/O. There are two problems. 1) writing to a vxWorks pipe returns an ERROR if the pipe is full. Is there a way to block I/O when the pipe is full, or do I need to use message queues? 2) writing large files on the vxWorks target to the socket to output on the unix host uses all of the memory up and crashes. This is because the socket write buffers data in memory. This is okay for small tar files, but fails on large tar files. Is there a way to wait for the socket buffers to flush, or to get a socket status as to how much buffer is left, or any other feedback? Thanks for any ideas. Fritz Stauffer, Sac Peak Observatory --------------------------- Newsgroups: comp.os.vxworks Subject: Re: vxWorks Sockets and Pipes Date: 12 Jan 93 23:27:53 GMT From: hwajin@pogo.iphasew.com (Hwa-Jin Bae) Organization: Interphase West, Santa Clara, CA Message-ID: References: <1993Jan12.201921.4490@nmsu.edu> Sender: hwajin@iphasew.com (Hwa-Jin Bae) >>>>> On 12 Jan 93 20:19:21 GMT, dog@xdev.sunspot.noao.edu (Fritz Stauffer) said: Fritz> 1) writing to a vxWorks pipe returns an ERROR if the pipe is full. Fritz> Is there a way to block I/O when the pipe is full, or do I need to use Fritz> message queues? pipe in 5.0 uses message queues, and write() should block if called from non-interrupt level code. in earlier versions, pipe used ring buffers and write() polled until ring space became available if called from non-interrupt level code. if you prefer, you can just use ring buffers (ringLib) yourself, and have finer control over what gets done. Fritz> 2) writing large files on the vxWorks target to the socket to output Fritz> on the unix host uses all of the memory up and crashes. This is Fritz> because the socket write buffers data in memory. This is okay for Fritz> small tar files, but fails on large tar files. Is there a way to Fritz> wait for the socket buffers to flush, or to get a socket status as Fritz> to how much buffer is left, or any other feedback? socket level buffers are adjustable with setsockopt() -- SO_SNDBUF, SO_RCVBUF. by default TCP uses 4K on each side and UDP uses 2K on send side and 4K in recv side. you can retrieve the current limit by using getsockopt(). when these high water marks are reached socket code blocks until more space become available. inetstatShow() displays output similar to UNIX command 'netstat -a', from which you should be able to tell various socket level queue length at the time. hwajin - -- hjb@netcom.com (home) hwajin@iphasew.com (work) - -- hjb@netcom.com (home) hwajin@iphasew.com (work) --------------------------- Newsgroups: comp.os.vxworks,comp.sys.sgi Subject: Re: sgi CC v3.1 & VxGDB incompatible Date: 13 Jan 93 00:05:56 GMT From: davea@quasar.mti.sgi.com (David B.Anderson) Organization: Silicon Graphics, Inc. Mountain View, CA Message-ID: Sender: davea@quasar.mti.sgi.com In article <1993Jan12.101638.901@nrlvx1.nrl.navy.mil> dyer@nrlvx1.nrl.navy.mil (Doug Dyer) writes: >Hi folks, > > I am using an SGI indigo r3000 as a vxworks host >(Iris 4D1-4.1) with cc (v3.10) and VxGDB to debug software (v1.1). >The following problems occur when I load a file into the debugger: > >if the source code has a "struct" in it : > unknown symbol type 1a >if the source code has a "union" in it: > unknown symbol type 1b Let me make a guess: those numbers are hex and are the st* value from the symbol table. 0x1a === 26 The sgi-generated symbol tables have 3 new values as compared with those from pre-merger-MIPS & DEC: From /usr/include/symconst.h: #ifdef __sgi #define stStruct 26 /* begin Struct kind of stBlock */ #define stUnion 27 /* begin Union kind of stBlock */ #define stEnum 28 /* begin Enum kind of stBlock */ #endif These are to be treated just like an stBlock except that they are specific and specify the *type* of the block. Anywhere in GDB it tests for stBlock, simply look for any of stBlock stStruct stUnion stEnum (though of course those new ones only apply to data, not code blocks, you need not worry about that since the new ones never appear on code blocks). You may find that this information is of use to gdb. Hope this helps. This answer *is* just a guess.... [ David B. Anderson (415)390-4263 davea@sgi.com ] --------------------------- Newsgroups: comp.os.vxworks Subject: Re: performance of fprintf() for floating point Date: Wed, 13 Jan 1993 09:23:33 GMT From: muts@pmcs.estec.esa.nl (Peter Mutsaers) Organization: European Space Agency Message-ID: References: <1993Jan11.211242.16776@ncar.ucar.edu> Sender: news@wm.estec.esa.nl >>On Mon, 11 Jan 1993 21:12:42 GMT, vanandel@rsf.atd.ucar.edu (Joe Van Andel) said: Joe> I am having a performance problem with fprintf(). I have an Joe> application that We have exactly the same problem on a different CPU board. I thought I might have done something stupid while reconfiguring the kernel and recompiling but it seems it is a common problem (?). Please post a useful response to the net. Thanks, - -- _________________________________________________________________________ Peter Mutsaers. |================================================ muts@pmcs.estec.esa.nl | Quod licet bovi, non licet Jovi --------------------------- End of New-News digest ********************** From harvey@cse.lbl.gov Wed Jan 13 10:23:44 1993 From: harvey@cse.lbl.gov (Everett Harvey) Date: Wed Jan 13 10:23:53 PST 1993 Subject: exploder services The VxWorks Mail Exploder 11/17/92 ------------------------- This is a user group mailing list for VxWorks related topics. Submit articles to vxwexplo@lbl.gov for distribution to the memebers. Send subscription requests and withdrawals to vxwexplo-request@lbl.gov . Some installations maintain their own sub-list which means we can send just one message to your site, which is then internally exploded. There is both an immediate list which gets about 2-5 posts per day and a daily digest list which accumulates 24-hours of messages at 4 AM Pacific Time. The VxWorks Exploder and the comp.os.vxworks newsgroup are cross-connected such that information posted to either shows up on both. We also maintain Message Archives which go back a year or so grouped by the month. These can be accessed via anonymous ftp at vxw-ftp.lbl.gov in the directory "pub". Use your logon name as a password. For example: %ftp vxw-ftp.lbl.gov % Name: anonymous % Password: yourname ftp> cd pub ftp> dir ftp> get archive9108 ### From vxworks@mars.psf.ge.com Wed Jan 13 13:49:41 1993 From: vxworks@mars.psf.ge.com (vx_works) Date: Wed Jan 13 13:49:52 PST 1993 Subject: REPOST: MVME14x Diagnostics coexisting with VADSWorks I unfortunately experienced trouble receiving the exploder since I first posted this, so if anyone out there replied via the exploder, please bear with me and try again: We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard power-on-diagnostics. We have a project requirement to run some level of board readiness tests without resorting to swapping the Motorola PROMS back in. I've got a call in to Motorola to see about the availability of their diagnostic source code, but I'm wondering how other folks have dealt with this problem. Has anyone developed downloadable diagnostic or readiness tests (or adapted Motorola's code) for this situation? John E. Thier GE Defense Systems Dept. Pittsfield MA vxworks_list@mars.psf.ge.com From talarian!brianq@uunet.uu.net Wed Jan 13 15:25:43 1993 From: talarian!brianq@uunet.uu.net (Brian Quigley) Date: Wed Jan 13 15:25:57 PST 1993 Subject: Re: REPOST: MVME14x Diagnostics coexisting with VADSWorks > We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the > VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard > power-on-diagnostics. We have a project requirement to run some level of > board readiness tests without resorting to swapping the Motorola PROMS back > in. I've got a call in to Motorola to see about the availability of their > diagnostic source code, but I'm wondering how other folks have dealt with > this problem. Has anyone developed downloadable diagnostic or readiness tests > (or adapted Motorola's code) for this situation? > > John E. Thier > vxworks_list@mars.psf.ge.com Sorry if this got through to you already. I know it doesn't directly answer you question but hopefully it will help. --- I faced a similar problem when using a Force CPU30. The solution recommended to us be Force was to use a different boot setting for our board. This setting told the board to load VMEPROM (Force's diagnostic ROM software) which executed the self-start diagnostics and then jumped to a predefined location in memory to begin executing a user-defined program. This user-defined programs was simply a jump to the starting address of VxWorks (defined as ROM_BASE_ADRS if I remember correctly). The good part was we didn't have to write any selftest software and we could (by changing the boot setting) run the VMEPROM by itself. However, we had to modify the kernel (very minor) which means we had to blast new EPROMs. Also, the size of our EPROM's needed to essentially double to hold both VMEPROM and VxWorks. I don't have access to a 147 manual but a 167 installtion manual alludes to a similar capability via something called ROMboot. I hope this helps. Let me know if you have questions. --- Brian Quigley | brianq@talarian.com Talarian Corporation | (415)965-8050 From ceco!kevinr@uunet.uu.net Wed Jan 13 19:08:35 1993 From: ceco!kevinr@uunet.uu.net (Kevin R. Rumbaugh) Date: Wed Jan 13 19:10:31 PST 1993 Subject: Re: REPOST: MVME14x Diagnostics coexisting with VADSWorks >We're running VADSWorks 2.0 on Motorola MVME143 and MVME147 boards. Since the >VADSWorks PROMS replace the stock Motorola PROMS, you lose the onboard >power-on-diagnostics. We have a project requirement to run some level of >board readiness tests without resorting to swapping the Motorola PROMS back >in. I've got a call in to Motorola to see about the availability of their >diagnostic source code, but I'm wondering how other folks have dealt with >this problem. Has anyone developed downloadable diagnostic or readiness tests >(or adapted Motorola's code) for this situation? > > >John E. Thier >GE Defense Systems Dept. >Pittsfield MA >vxworks_list@mars.psf.ge.com > > Can't speak for VADSWorks, but we have had in the past both the Motorla EPROMs and the VxWorks EPROMS on the board at the same time. You have to change the start address for the bootrom code in the config/mv147 directory, and when the board boots the Motorla code gets control and you have it jump to the VxWorks code. If you think it might help, send me mail and I'll look at more specifics for you. -- Kevin Rumbaugh 'The Marauder' --- Commonwealth Edison --- E-MAIL : kevinr@ceco.com OR uunet!ceco!kevinr AT&T : (312) 294-8894 FAX : (312) 294-4233 USMAIL : Information Systems; Room 1139; 125 S. Clark; Chicago IL 60603 From daemon@vxw.ee.lbl.gov Thu Jan 14 04:00:46 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 14 04:00:58 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 14 04:00:36 PST 1993 Subject: Re: performance of fprintf() for floating point Subject: VADSWorks & sockets Subject: VME Bus Errors ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: performance of fprintf() for floating point Date: Wed, 13 Jan 1993 13:12:30 GMT From: vanandel@rsf.atd.ucar.edu (Joe Van Andel) Organization: National Center for Atmospheric Research Message-ID: <1993Jan13.131230.16404@ncar.ucar.edu> References: <1993Jan11.211242.16776@ncar.ucar.edu> Sender: news@ncar.ucar.edu (USENET Maintenance) The solution seems to be to use "ftoa()", which someone was kind enough to pass on: /* here is a fast floating point to ascii converter we developed for the ** BEVALAC control system for storing control system state. ** ** This work done by Loren Shalz, Alan Biocca, and Maurice McEvoy. ** ** ** ftoa converts float to decimal ascii using the MC68881/2 Floating_Point ** Coprocessor. It utilizes a single line of assembly language to access ** the FPU's floating point to packed BCD. The remainder of the code is ** written in C. The WRS 5.0.1 release gnu cross tools were used (based ** on gcc 1.37). Your mileage may vary -- TEST THESE ROUTINES THOROUGHLY. ** ** ftoa must be compiled with the gnu compiler because cc's assembler ** does not recoginze the k factor(precision) in the inline fmovep command. ** cc68k -c -o ftoa.vx ftoa.c ** ** If any code before the fmovep is changed be sure to get the assembler ** output and verify that value has been put into fp0, that a3 still ** has the address of packed_bcd and that d4 still has precision. ** Adjust fmovep appropriately if any changes are observed. ** ** See the MC68881 Floating-Point Coprocessor Users Manual for the ** packed decimal real format produced by the fmovep. The following ** defines aid in cracking that format to produce the decimal ascii. */ #define MANTISSA_SIGN ( ( unsigned char ) ( 1 << 7 ) ) #define EXPONENT_SIGN ( ( unsigned char ) ( 1 << 6 ) ) #define NAN_BITS ( ( unsigned char ) ( 3 << 4 ) ) #define ASCII_ZERO ( ( unsigned char ) 0x30 ) #define RIGHT_NIBBLE ( ( unsigned char ) 0xf ) #define NIBBLE_SIZE ( ( unsigned char ) 0x4 ) #define PACKED_BCD_SIZE 12 int ftoa( value, precision, width, string ) float value; /* value to be converted to decimal ascii */ int precision; /* 1 <= precision(no. significant digits) <= 17 */ int width; /* minimum size of returned string. String is left */ /* adjusted with blank fill if necessary */ char *string; /* pointer to string to receive converted value */ /* format returned is [-]d.dddddddddddddddde[-]ddd */ /* so string should be sized to hold at least the /* larger of width or precision + 7 characters */ /* plus a terminating null. Trailing zeros in the */ /* mantissa and zero exponents are dropped */ /* ftoa returns the length of string */ { unsigned char packed_bcd[PACKED_BCD_SIZE]; register float v = value; register int p = precision; register int w = width; register char *s = string; register unsigned char *c = &packed_bcd[0]; int i; int trailing_zeros; int trailing_blanks; int right_adjuster; unsigned char next_digit; asm( " fmovep fp0,a3@{d4}" ); /* convert to packed bcd. */ if ( precision < 1 ) precision = 1; if ( precision > 17 ) precision = 17; if ( ( c[0] & NAN_BITS ) != 0 ) { strcpy( s, "NAN" ); return; } /* unpack mantissa--always return at least 1 digit and '.' */ if ( ( c[0] & MANTISSA_SIGN ) != 0 ) *s++ = '-'; /* mantissa sign */ *s++ = ( c[3] & RIGHT_NIBBLE ) + ASCII_ZERO; /* most sign. digit */ *s++ = '.'; /* decimal point */ trailing_zeros = 0; --precision; /* 1st digit unpacked above */ right_adjuster = NIBBLE_SIZE; c = &packed_bcd[4]; for ( i = 0; i < precision ; ++i ) /* unpack rest of digits */ { next_digit = ( c[i/2] >> right_adjuster ) & RIGHT_NIBBLE; if ( next_digit == '\0' ) ++trailing_zeros; else trailing_zeros = 0; *s++ = next_digit + ASCII_ZERO; if ( right_adjuster == 0 ) right_adjuster = NIBBLE_SIZE; else right_adjuster = 0; } s = s - trailing_zeros; /* unpack exponent--drop it if it is zero. */ c = &packed_bcd[0]; if ( ( ( next_digit = ( c[0] & RIGHT_NIBBLE ) ) + c[1] ) != 0 ) { *s++ = 'e'; /* nonzero exponent */ if ( ( c[0] & EXPONENT_SIGN ) != 0 ) *s++ = '-'; if ( next_digit != 0 ) { *s++ = next_digit + ASCII_ZERO; /* 3 digit exponent */ *s++ = ( c[1] >> NIBBLE_SIZE ) + ASCII_ZERO; } else if ( ( next_digit = ( c[1] >> NIBBLE_SIZE ) ) != 0 ) *s++ = next_digit + ASCII_ZERO; /* 2 digit exponent */ *s++ = ( c[1] & RIGHT_NIBBLE ) + ASCII_ZERO; /* 1 digit exponent */ } if ( ( trailing_blanks = width - ( s - string ) ) > 0 ) /* blank pad */ for ( i = 0; i < trailing_blanks; ++i ) *s++ = ' '; *s = '\0'; return s - string; } - -- Joe VanAndel Internet:vanandel@ncar.ucar.edu National Center for Atmospheric Research --------------------------- Newsgroups: comp.os.vxworks Subject: VADSWorks & sockets Date: 13 Jan 93 22:03:32 GMT From: yvesb@melair.UUCP (Yves Boudeault) Organization: Lockheed Canada Inc., Ottawa, Canada Message-ID: <1553@melair.UUCP> Hi, I am working on a multiprocessor using VADSWorks and a number of MVME-167. I know just enough about VxWorks and VADSWorks to be dangerous, so be forewarned: It is my understanding that VADSWorks sets up a roud-robin scheduling. When I send to my socket, the data gets copied into the socket send buffer but the data does not appear to be sent to the receiver until a context switch occurs. This does not look like a very interesting behaviour. Does anyone know if this is, in fact, how VADS works ? Yves Boudreault (yvesb@minas.lockheed.on.ca) - -- Yves Boudreault If I express opinions, they have to be mine. yvesb@melair.lockheed.on.ca --------------------------- Newsgroups: comp.os.vxworks Subject: VME Bus Errors Date: Thu, 14 Jan 1993 06:26:26 GMT From: binkley@xavier.dfrf.nasa.gov (Rob Binkley) Organization: NASA Dryden FRF, Edwards, CA Keywords: Bus error Interrupts Message-ID: <1993Jan14.062626.16722@news.dfrf.nasa.gov> Reply-To: binkley@xavier.dfrf.nasa.gov Sender: news@news.dfrf.nasa.gov (Usenet news) I am having a (very basic) problem with vxWorks. I am trying to intercept VME bus errors and recover gracefully in my program. I am looking for some possible failures of IO boards in the VME crate. I have looked at vxMemProbe() ...won't do. I have to look for dynamic (run time) board failures. The basic premise I am trying to implement: Use intConnect to install my bus error handler. That handler simply does a longjmp to a previous setjmp. If a bus error ever gets called, it works, but appears to hang the vxWorks OS on exit. The code is attached to the end of this letter. Hardware: Force CPU-40/01 16 Meg RAM Software: vxWorks 5.0.2b-68040 Release-1 Thanks for any help...I'm sure I'm missing something very simple... An execution fragment: ================================================ Trying 130.134.XXX.XXX ... Connected to sabretooth.dfrf.nasa.gov. Escape character is '^]'. - -> cd "/home/xavier/binkley/VxWorks/CIU/Chris" value = 0 = 0x0 - -> ld < ppp.o value = 0 = 0x0 - -> init OK: Bus error handler installed. IDIS board # 0 found and initalized IDIS board # 1 NOT INSTALLED! Setjmp ststus: 8 value = 0 = 0x0 - -> ================================================ the system is dead...must be rebooted... the compile line: ================================================ cc68k -g -c -DCPU=MC68040 -Wall -I/usr/vw/h -I/usr/vw/sun4.68k/lib/gcc-include -I/usr/vw/config/frc40 -I/usr/vw/h/drv ppp.c ================================================ The code: ================================================ #include #include #include #include #include #include #include <68k/iv.h> /* vxWorks 68k-family interrupt vector header */ #include /* vxWorks Force CPU-40 header */ #include /* vxWorks FGA-002 gate array header */ jmp_buf busErrorEnv; STATUS init() { void busErrorIRQ(); int status; short *p; int i; if(intConnect ((void *)IV_BUS_ERROR, busErrorIRQ, (int)IV_BUS_ERROR)== ERROR) { printf("ERROR: Unable to install busErrorIRQ() interupt handler.\n"); printf(" Exiting ciuRT() in function: busErrorHandlerInstall().\n\n"); exit(-1); } else printf("OK: Bus error handler installed.\n\n"); p = (short *) 0xfcff0608; for (i=0; i < 2; i++, p+=8) { if ((status = setjmp(busErrorEnv)) == 0) { *p = 0x00e0; printf("IDIS board # %d found and initalized\n",i); } else { printf("IDIS board # %d NOT INSTALLED! Setjmp ststus: %d\n",i,status); } } return(0); } void busErrorIRQ(int callingIntVector) { longjmp(busErrorEnv, callingIntVector); } - -- - ----------------------------------------------------------------------------- | Robert L. Binkley, EIT | INTERNET: binkley@xavier.dfrf.nasa.gov | | NASA Dryden FRF | ADDRESS: 130.134.144.2 | | PO Box 273 MS: B4840A | | | Edwards, CA 93523-5000 | | | fone: 805-258-3776 | | | fax: 805-258-3567 | | |---------------------------------------------------------------------------| | barf [ba:rf] 2. "He suggested using FORTRAN, and everybody barfed." | | | | - From The Shogakukan DICTIONARY OF NEW ENGLISH (Second edition) | - ----------------------------------------------------------------------------- --------------------------- End of New-News digest ********************** From fjr@rayssd.ssd.ray.com Thu Jan 14 08:28:59 1993 From: Roeber Date: Thu Jan 14 08:29:08 PST 1993 Subject: Re: VADSWorks & sockets Yves Boudeault writes: > Organization: Lockheed Canada Inc., Ottawa, Canada > Message-ID: <1553@melair.UUCP> > > Hi, > > I am working on a multiprocessor using VADSWorks and a number of > MVME-167. I know just enough about VxWorks and VADSWorks to be > dangerous, so be forewarned: > > It is my understanding that VADSWorks sets up a roud-robin scheduling. > When I send to my socket, the data gets copied into the socket send buffer > but the data does not appear to be sent to the receiver until a > context switch occurs. This does not look like a very interesting > behaviour. Does anyone know if this is, in fact, how VADS works ? First, the fact that you are using VADSWorks vs VxWorks makes a bit of a difference here. I assume you are using Ada tasking. This means that there is Ada tasking running on top of the standard VxWorks scheduler (actually, one scheduler handles this). The thing is that there are some configurable parameters that affect how the Ada scheduling works. You can select time sliced (round robin) tasking as an option. Realize, though, that both VADSWorks and VxWorks basically use preemptive scheduling. Thus, if your two tasks have different priorities, the higher priority task will run when it has something to do; preempting any lower priority task that is running. Thus, if you send a message from a low priority task to a high priority one through a socket, the high priority one will run immediately. If the receiving task is the same or lower priority, then it won't run until a context switch occurs. I expect that you haven't adjusted the task priorities (using the Ada pragma priority). One last thing to note, VADSWorks priorities are consistent with the Ada LRM which specifies that higher values are higher priorities. This is opposite the normal VxWorks model which has lower numbers as higher priorities. Thus, depending on how you are setting your priorities, you could maybe be getting a different result than you expect. There are other potential issues if you are talking about using sockets across the backplane that depend on how you have the backplane driver configured. The driver supports polled or interrupt driven operation. It should be set to interrupt driven operation for MVME167s though so I don't really think that what you are seeing is the result of any backplane driver issues. Good luck. Fred _______________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | fjr@ssd.ray.com | |_______________________________________________________| From fjr@rayssd.ssd.ray.com Thu Jan 14 08:29:58 1993 From: Roeber Date: Thu Jan 14 08:30:09 PST 1993 Subject: Re: VME Bus Errors Rob Binkley writes: > I am having a (very basic) problem with vxWorks. > I am trying to intercept VME bus errors and recover > gracefully in my program. I am looking for some > possible failures of IO boards in the VME crate. > > I have looked at vxMemProbe() ...won't do. I have to > look for dynamic (run time) board failures. > > The basic premise I am trying to implement: > > Use intConnect to install my bus error handler. > That handler simply does a longjmp to a previous > setjmp. If a bus error ever gets called, it works, > but appears to hang the vxWorks OS on exit. The problem is with the longjmp. When you receive a bus error you are running in interrupt context. The "task" which originally did the setjmp is running in a very different context; different stack, different priority level... I have written my own bus error handlers before and it is basically like any other interrupt handler for a device driver. You can perform functions at interrupt level but if you need to do something at task level, you should use some mechanism like a binary semaphore to "signal" the task that the event occured. You can't longjmp. The other thing I would suggest is that you get the original interrupt vector for the bus error and call that handler too after doing any functions in your handler. For bus errors there are things like automatic cycle retries done by the original VxWorks handler that you don't want to disrupt. Good luck. Fred _______________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | fjr@ssd.ray.com | |_______________________________________________________| From kimraj@cps070.lds.loral.com Thu Jan 14 13:03:25 1993 From: kimraj@cps070.lds.loral.com (Ron Kimraj) Date: Thu Jan 14 13:03:35 PST 1993 Subject: Dangling Socket Descriptor How does a TCP/IP server knows to stop listening on a client, if the client aborted without explicitly removing the socket descriptor by closing it via close()? (The SO_KEEPALIVE Option is set on both the Server and Client tasks). Thank you. From @amdahl.uts.amdahl.com,@juts.ccc.amdahl.com:bxs20@da.amdahl.com Thu Jan 14 13:41:30 1993 From: bxs20@da.amdahl.com (Benny Schnaider) Date: Thu Jan 14 13:41:40 PST 1993 Subject: MVME167 VMEbus transfer rate I am trying to compare the performance of the MVME167/33Mhz with MVME135/16.7Mhz. One of the surprising result is a slower VMEbus access for the MVME167. I am getting 10%-20% slower transfer rate from/to MVME167 to/from the VMEbus relative to the MVME135. (I am accessing the same board in both cases). Are there any configuration registers on the MVME167 that can affect the transfer rate on the VMEbus. In other words, what am I doing wrong ? Thanks, Benny. From daemon@vxw.ee.lbl.gov Fri Jan 15 04:00:33 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 15 04:00:44 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 15 04:00:21 PST 1993 Subject: Re: VME Bus Errors Subject: Re: Dangling Socket Descriptor Subject: Memory management debug aids... ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: VME Bus Errors Date: 14 Jan 93 20:09:40 GMT From: georg@sgl.ists.ca (Georg Feil) Organization: Institute for Space and Terrestrial Science Keywords: Bus error Interrupts Message-ID: References: <1993Jan14.062626.16722@news.dfrf.nasa.gov> Sender: news@ists.ists.ca (News Subsystem) binkley@xavier.dfrf.nasa.gov (Rob Binkley) writes: >I am having a (very basic) problem with vxWorks. >I am trying to intercept VME bus errors and recover >gracefully in my program. Your problem may have to do with the DF bit of the special status word. Unless it is explicitly cleared, the bus cycle is retried and will just fail again and again in an endless loop. Here is an example routine which shows how you might return from the bus-error handler to avoid hanging. This is very similar to how vxMemProbe() works. The example is written for 68020 (VxWorks 4.0.2), so I hope it's the same on 68040. Georg. - ----------------------------------------------------------------------- int buserr; void buserr_isr(int dumparm) /* * Just count the occurrence of bus errors. * * This is not a conventional VxWorks isr: no registers are saved before entry. * We first increment a bus error indicator 'buserr'. Then we clear the * DF bit (bit 8) of the internal special status word saved by the bus error * exception. This should appear at sp+0x0e, counting 0x0a for its offset * into the exception stack frame and 0x04 for the link a6 instruction * that starts all C functions. The DF bit controls whether the data access * is retried following the return from exception. We do not want to retry * the access, otherwise everything would hang permanently. * * Many machine and compiler-dependent assumptions are being made here. * In particular we assume that the code generated for this subroutine does * not modify any registers and that the stack format is as described. * We also manufacture our own exit sequence, using "unlk a6" and "rte". * This is assumed to remain correct. * * Any code added to this routine should ensure it first saves any registers it * uses. */ { buserr++; asm("andw #0xfeff,sp@(0x0e)"); asm("unlk a6 ; rte"); } void board_scan(void) /* Scan for presence of hardware */ { FUNCPTR old_isr; static int dummy; /* static to prevent optimizer from removing */ old_isr=intVecGet(IV_BUS_ERROR); /* Make direct connection of buserr_isr to bus error exception vector. */ intVecSet(IV_BUS_ERROR,(FUNCPTR)buserr_isr); buserr=0; /* test access to DRD board */ dummy=M_B(DRDBASE+1); if (buserr==0) { printf("DRD board present.\n"); } else { printf("*** DRD board not present. Will not access.\n"); } intVecSet(IV_BUS_ERROR,old_isr); } - -- Georg Feil Internet: georg@sgl.ists.ca Space Geodynamics Laboratory ISTS, 2700 Steeles Ave West Phone: (416) 665-5458 Toronto, Ontario CANADA Fax: (416) 660-1422 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Dangling Socket Descriptor Date: Fri, 15 Jan 1993 00:19:57 GMT From: rypma@waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: References: <9301142103.AA14190@cps070.lds.loral.com> Sender: news@waterloo.hp.com (NetNews) Ron Kimraj (kimraj@cps070.lds.loral.com) wrote: : : How does a TCP/IP server knows to stop listening on : a client, if the client aborted without explicitly : removing the socket descriptor by closing it via close()? : : (The SO_KEEPALIVE Option is set on both the Server and : Client tasks). Keepalives won't do a darned thing.. just prove to each side that the connection is still alive at the TCP protocol level. You need an application-level handshake (which is the right way to implement this kind of thing anyway). Keepalives ONLY speed recovery if one side crashes and then comes back up - the keepalive frame is answered with a TCP reset frame. Otherwise you get to have your coffee grow cold while you wait. Your particular scenario won't even time out then because VxWorks "owns" the socket descriptor (they're all global, you know) and the connection remains very much alive. Ted Rypma HP Panacom Division --------------------------- Newsgroups: comp.os.vxworks Subject: Memory management debug aids... Date: 15 Jan 93 00:59:23 GMT From: sjk@strl.labs.tek.com (Steven King) Organization: Software Technology Research Lab, Tektronix, Inc. Message-ID: <5073@crl.LABS.TEK.COM> Followup-To: comp.os.vxworks Reply-To: sjk@strl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM I'm looking for a tool that can help track down a memory overwrite under VxWorks. (Aren't we all?) This one is especially tough, since it happens in a reuseable C++ library that is rather complex and would be hard to "instrument" with printf(), memShow() or memPartShow(). A tool like Purify would be optimal, since I would like a tool to find the offending line of code and how it's offensive. Since Purify under VxWorks is not do-able, I was hoping that a fellow VxWorks user might have a ready-made solution to share. Something that monitors or verifies malloc'ed segments of memory is what I need. Has anyone used Stethoscope in this manner? Is it possible? If not, I'll just whip up a little monitor to watch the memory partition and report modifications from time-to-time. Thanks! Steven (sjk@strl.labs.tek.com) "Sometimes if you have a cappuccino and then try again it will work OK." (Dr. Brian Reid) "Sometimes one cappuccino isn't enough." (Marcus Ranum) "A double vanilla latte always works." (Me) --------------------------- End of New-News digest ********************** From visicom!VisiCom.COM!trest@nosc.mil Fri Jan 15 08:59:36 1993 From: Mike Trest Date: Fri Jan 15 08:59:49 PST 1993 Subject: Re: MVME167 VMEbus transfer rate Benny Schnaider writes: > I am trying to compare the performance of the MVME167/33Mhz > with MVME135/16.7Mhz. One of the surprising result is a slower > VMEbus access for the MVME167. I am getting 10%-20% slower > transfer rate from/to MVME167 to/from the VMEbus relative to > the MVME135. (I am accessing the same board in both cases). I have seen this happen with 68040 boards in general. I have not observed the bus activity of the MVME167 to confirm. The problem may be related to cache-line-filling. If, for example, you are reading one-byte-cycles followed by one-byte-writes and the addresses of those bytes are somewhat spread-out, and you have cache enabled covering the VME address space the MMU inside the 68040 is actually reading 4 words to fill a cache-line rather than one byte. To know for sure, we need to know a little more about the addresses of the bus transfer activity the size of the read/write. A VME bus analizer like the NISSO or VMETRO can tell you if this is the real problem. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From interf!atlas!io!vhopson@uunet.uu.net Fri Jan 15 12:50:27 1993 From: interf!atlas!io!vhopson@uunet.uu.net (Vince Hopson) Date: Fri Jan 15 12:50:37 PST 1993 Subject: Exabyte 8500 SCSI drives Currently, I need to purchase an intelligent VME based SCSI card that is compatible with vxWorks (i.e. has drivers), and also compatible with the Exabyte tape drives (5GByte tapes in 8mm format). I would appreciate any clues, anecdotes in implementation, or other help that anyone can offer on either or both topics. Please send your responses to: vhopson@interf.com Thanks in advance for all replies!! ...vince Vincent M. Hopson vhopson@interf.com Interferometrics Inc. 8150 Leesburg Pike Vienna, VA voice: (202) 653-0945 From fjr@rayssd.ssd.ray.com Fri Jan 15 13:39:44 1993 From: Roeber Date: Fri Jan 15 13:39:53 PST 1993 Subject: Re: Memory management debug aids... Steven King from Tektronix writes: > I'm looking for a tool that can help track down a memory overwrite under > VxWorks. (Aren't we all?) This one is especially tough, since it happens > in a reuseable C++ library that is rather complex and would be hard to > "instrument" with printf(), memShow() or memPartShow(). > > A tool like Purify would be optimal, since I would like a tool to find the > offending line of code and how it's offensive. Since Purify under VxWorks > is not do-able, I was hoping that a fellow VxWorks user might have a ready-made > solution to share. Something that monitors or verifies malloc'ed segments of > memory is what I need. Steve, I am a little surprised, the "best" solution that we have found to this type of problem is to use a HW emulator like you guys build to track such problems. Of course the darned things are real expensive and a little hard to connect up to boards but they are the optimum solution. > Has anyone used Stethoscope in this manner? Is it possible? Stethoscope can track the location too periodically. I assume Stan Schnieder who wrote the tool will respond. Of course it is pretty hard to get from the periodic point where the value is corrupted to the exact code that did the corruption. > > If not, I'll just whip up a little monitor to watch the memory partition > and report modifications from time-to-time. Good luck. Fred _______________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | fjr@ssd.ray.com | |_______________________________________________________| From brian@wrs.com Fri Jan 15 15:04:03 1993 From: Brian Lazara Date: Fri Jan 15 15:04:13 PST 1993 Subject: Re: VADSWorks & sockets Yves Boudeault and Fred Roeber write: >Yves Boudeault writes: > >> Organization: Lockheed Canada Inc., Ottawa, Canada >> Message-ID: <1553@melair.UUCP> >> >> Hi, >> >> I am working on a multiprocessor using VADSWorks and a number of >> MVME-167. I know just enough about VxWorks and VADSWorks to be >> dangerous, so be forewarned: >> >> It is my understanding that VADSWorks sets up a roud-robin scheduling. >> When I send to my socket, the data gets copied into the socket send buffer >> but the data does not appear to be sent to the receiver until a >> context switch occurs. This does not look like a very interesting >> behaviour. Does anyone know if this is, in fact, how VADS works ? > >First, the fact that you are using VADSWorks vs VxWorks makes a bit of a >difference here. I assume you are using Ada tasking. This means that >there is Ada tasking running on top of the standard VxWorks scheduler >(actually, one scheduler handles this). The thing is that there are some >configurable parameters that affect how the Ada scheduling works. You can >select time sliced (round robin) tasking as an option. Realize, though, that >both VADSWorks and VxWorks basically use preemptive scheduling. Thus, if >your two tasks have different priorities, the higher priority task will run >when it has something to do; preempting any lower priority task that is >running. Thus, if you send a message from a low priority task to a high >priority one through a socket, the high priority one will run immediately. >If the receiving task is the same or lower priority, then it won't run until >a context switch occurs. I expect that you haven't adjusted the task >priorities (using the Ada pragma priority). One last thing to note, >VADSWorks priorities are consistent with the Ada LRM which specifies that >higher values are higher priorities. This is opposite the normal VxWorks >model which has lower numbers as higher priorities. Thus, depending on how >you are setting your priorities, you could maybe be getting a different >result than you expect. > There are other potential issues if you are talking about using sockets >across the backplane that depend on how you have the backplane driver >configured. The driver supports polled or interrupt driven operation. It >should be set to interrupt driven operation for MVME167s though so I don't >really think that what you are seeing is the result of any backplane driver >issues. Good luck. Fred It should be noted that the default is preemptive scheduling. To start time slicing, kernelTimeSlice needs to be called. This will still be preemptive for differrent priority tasks, but ready tasks of equal priority will be put on a round-robin scheduling. Check out the Programmers Guide for more detail on this. -Brian From daemon@vxw.ee.lbl.gov Sat Jan 16 04:00:48 1993 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 16 04:00:58 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 16 04:00:33 PST 1993 Subject: Mysterious task crashes Subject: Re: Memory management debug aids... ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Mysterious task crashes Date: 15 Jan 93 18:47:13 GMT From: bard@cutter.ssd.loral.com (J H Woodyatt) Organization: Abiogenesis 4 Less Message-ID: <1993Jan15.184713.28368@wdl.loral.com> Reply-To: bard@cutter.ssd.loral.com Sender: news@wdl.loral.com I had this problem under VxWorks 4.0.2, and I hoped it would go away with the switch to VxWorks 5.0.2b, but it still seems to be plaguing me, so I'm soliciting advice from the net. Hopefully, somebody somewhere has seen something like this before and can offer suggested explanations for the behavior I'm observing other than the ones I've already thought up. At seemingly random intervals, and usually shortly after powerup, I get an illegal instruction trap. The task that dies varies, sometimes it's tNetTask, sometimes it's tPortmapd -- I've even seen tRootTask die in this fashion. Under VxWorks 4.0.2, it was really funky, because the `idle' task was usually the one to give up the ghost, and with that one it was fairly easy to check that the `idle' function hadn't been clobbered in memory. The consistent part is that the program counter always comes up at address 0000006. Here's a sample message: Illegal Instruction Program Counter: 0x00000006 Status Register: 0x2300 Task: 0xb2b37c "tNetTask" We're using Tadpole TP-32V SBC's. We use them in a twenty-slot card cage with a bunch of other cards used to control a tape drive, four HP system power supplies, a chart recorder and do other assorted weirdness. My superstitions tell me to aim at power supply problems. I need a clue to know where to start troubleshooting this one. Can anyone offer a helpful suggestion? - -- +---------------------------+ I wasn't expecting it. When Danny Elfman | J H Woodyatt | sang the words, `goo goo ga choo,' Sunday | bard@cutter.ssd.loral.com | night, I cracked. Some horrors are too +---------------------------+ large to shade out. --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Memory management debug aids... Date: Fri, 15 Jan 93 21:11:39 GMT From: pardo@alta.Stanford.EDU (Gerardo Pardo-Castellote) Organization: stanford Message-ID: <1993Jan15.211139.12325@leland.Stanford.EDU> References: <5073@crl.LABS.TEK.COM> Sender: pardo@alta (Gerardo Pardo-Castellote) In article <5073@crl.LABS.TEK.COM>, sjk@strl.labs.tek.com (Steven King) writes: |> I'm looking for a tool that can help track down a memory overwrite under |> VxWorks. (Aren't we all?) This one is especially tough, since it happens |> in a reuseable C++ library that is rather complex and would be hard to |> "instrument" with printf(), memShow() or memPartShow(). |> |> A tool like Purify would be optimal, since I would like a tool to find the |> offending line of code and how it's offensive. Since Purify under VxWorks |> is not do-able, I was hoping that a fellow VxWorks user might have a ready-made |> solution to share. Something that monitors or verifies malloc'ed segments of |> memory is what I need. |> |> Has anyone used Stethoscope in this manner? Is it possible? |> If not, I'll just whip up a little monitor to watch the memory partition |> and report modifications from time-to-time. |> I don't think you can use Stethoscope for that purpose. However Stethoscope comes with a tool called "heapCheck" that does something very close to what you want. It replaces malloc() and free() by its own calls and does a consistency check on the whole heap every time malloc() or free() are called. Upon hitting the error it will print a stack trace of the offending task. In addition it also keeps a count on the number of times either function was called and lets you set e break point at any count. If your problem is repeateble this lets you break on the last call before the error ocurred and step through to watch the error happen. I have used it several times and it is very effective provided (as I said) that the problem is repeateble. I don't know more about it. You will have to contact RTI (info@rti.com) for more details. |> Thanks! |> |> Steven (sjk@strl.labs.tek.com) Gerardo. --------------------------- End of New-News digest ********************** From @amdahl.uts.amdahl.com,@juts.ccc.amdahl.com:bxs20@da.amdahl.com Sun Jan 17 09:35:23 1993 From: bxs20@da.amdahl.com (Benny Schnaider) Date: Sun Jan 17 09:35:33 PST 1993 Subject: MVME167 VMEbus transfer rate > Benny Schnaider writes: > >> I am trying to compare the performance of the MVME167/33Mhz >> with MVME135/16.7Mhz. One of the surprising result is a slower >> VMEbus access for the MVME167. I am getting 10%-20% slower >> transfer rate from/to MVME167 to/from the VMEbus relative to >> the MVME135. (I am accessing the same board in both cases). > >I have seen this happen with 68040 boards in general. I have >not observed the bus activity of the MVME167 to confirm. > >The problem may be related to cache-line-filling. If, for >example, you are reading one-byte-cycles followed by one-byte-writes >and the addresses of those bytes are somewhat spread-out, >and you have cache enabled covering the VME address space >the MMU inside the 68040 is actually reading 4 words to fill >a cache-line rather than one byte. > >To know for sure, we need to know a little more about the addresses >of the bus transfer activity the size of the read/write. A >VME bus analizer like the NISSO or VMETRO can tell you if this >is the real problem. > >..mike.. Mike I am mainly words transfer (16Bits). Data cache is Enabled, Write-Trough mode. Enclosed is the code I was using. I am almost sure that I tried disabling the data cache and the results were not much different. I do not have the board to verify it. Thanks, Benny #define usign16 unsigned short VXTcopyShort(src_adrs, dst_adrs, count) /* ******************************************/ register usign16 *src_adrs; /* source address */ register usign16 *dst_adrs; /* Destination address */ register int count; /* Number of WORDS to transfer */ { register int i; for (i = 0; i < count; i++) { *dst_adrs++ = *src_adrs++; } } /* VXTcopyShort */ From daemon@vxw.ee.lbl.gov Mon Jan 18 04:00:37 1993 From: daemon@vxw.ee.lbl.gov Date: Mon Jan 18 04:00:46 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Jan 18 04:00:27 PST 1993 Subject: X Client Development ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: X Client Development Date: 17 Jan 1993 23:25:10 GMT From: ah442@cleveland.Freenet.Edu (Erik C. Orange) Organization: Case Western Reserve University, Cleveland, Ohio (USA) Message-ID: <1jcpsmINNdpq@usenet.INS.CWRU.Edu> I'm curious as to how X client tasks are developed under VxWorks. Do most developers accomplish this by writing their own X/toolkit code? We were hoping to ease this task by using a GUI developer, but some of these tools produce UIL code along with C code, and I haven't seen a reference to a UIL compiler that might come with windX. (I was hoping .UID files are portable in answer to this, but a port attempt from SGI to DEC kinda failed). I guess I'm just looking for some trends in X client development. Any insight would be helpful! Erik - -- - ---------- Erik C. Orange FRD Industrial Automation Computer Engineering Avery-Dennison Corporation ah442@cleveland.Freenet.Edu Concord, OH --------------------------- End of New-News digest ********************** From hebo@mbari.org Mon Jan 18 08:47:12 1993 From: Bob Herlien Date: Mon Jan 18 08:47:20 PST 1993 Subject: Re: X Client Development > > I'm curious as to how X client tasks are developed under VxWorks. > Do most developers accomplish this by writing their own X/toolkit > code? > > We were hoping to ease this task by using a GUI developer, but some > of these tools produce UIL code along with C code, and I haven't > seen a reference to a UIL compiler that might come with windX. > (I was hoping .UID files are portable in answer to this, but a > port attempt from SGI to DEC kinda failed). > The GUI builder I'm familiar with (Builder Xcessory, but I've also used UIM/X and I think it works the same way) use UIL as a "save" file format and, of course, you can use this UIL to generate .UID. However, they also have an option to generate pure (K&R or ANSII) C code. In that mode, UIL is just a load/store format for the tool; your application never sees it. -------------------------------------------------------------- Bob Herlien MBARI (Monterey Bay Aquarium Research Institute) hebo@mbari.org From daemon@vxw.ee.lbl.gov Tue Jan 19 04:00:38 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 19 04:00:50 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 19 04:00:30 PST 1993 Subject: Re: Mysterious task crashes Subject: NFS Server Availability? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Mysterious task crashes Date: Mon, 18 Jan 1993 16:36:43 GMT From: markm@ee.ubc.ca (mark milligan) Organization: University of BC, Electrical Engineering Message-ID: <1993Jan18.163643.619@ee.ubc.ca> References: <1993Jan15.184713.28368@wdl.loral.com> Sender: news@ee.ubc.ca (Usenet News) In article <1993Jan15.184713.28368@wdl.loral.com>, bard@cutter.ssd.loral.com (J H Woodyatt) writes: > > I had this problem under VxWorks 4.0.2, and I hoped it would go away > with the switch to VxWorks 5.0.2b, but it still seems to be plaguing > me, so I'm soliciting advice from the net. Hopefully, somebody > somewhere has seen something like this before and can offer suggested > explanations for the behavior I'm observing other than the ones I've > already thought up. > > At seemingly random intervals, and usually shortly after powerup, I > get an illegal instruction trap. The task that dies varies, sometimes > it's tNetTask, sometimes it's tPortmapd -- I've even seen tRootTask > die in this fashion. > > Under VxWorks 4.0.2, it was really funky, because the `idle' task was > usually the one to give up the ghost, and with that one it was fairly > easy to check that the `idle' function hadn't been clobbered in > memory. > > The consistent part is that the program counter always comes up at > address 0000006. Here's a sample message: > > Illegal Instruction > Program Counter: 0x00000006 > Status Register: 0x2300 > Task: 0xb2b37c "tNetTask" > > We're using Tadpole TP-32V SBC's. We use them in a twenty-slot card > cage with a bunch of other cards used to control a tape drive, four HP > system power supplies, a chart recorder and do other assorted > weirdness. My superstitions tell me to aim at power supply problems. > > I need a clue to know where to start troubleshooting this one. Can > anyone offer a helpful suggestion? > > > -- > +---------------------------+ I wasn't expecting it. When Danny Elfman > | J H Woodyatt | sang the words, `goo goo ga choo,' Sunday > | bard@cutter.ssd.loral.com | night, I cracked. Some horrors are too > +---------------------------+ large to shade out. Sounds like you have the clasic "uninitalized pointer" problem that is clobering your memory. Go through all your code and check that all pointers are initalized before use! It looks like the pointer is writing an instruction to jump to location 0x0006 where the illegal instruction is generated. ( I beleive this is the vector table?) Hope this helps, any body else agree ? =============================================================================== Mark R. Milligan EMAIL: markm@ee.ubc.ca | University of British Columbia | Department of Electrical Engineering | 2356 Main Mall | Vancouver, British Columbia ==============================================+ V6T 1Z4 |" Don`t tell me whats happening!... | CANADA | Just tell me whats going on? " | Phone: (604)822-4242 | infamous quote attributed to ... | Fax : (604)822-9209 | boB (spelled backwards with a B) J.D. Butt | =============================================================================== DISCLAIMER: ( supplied by the law firm of Shyster and Shyster ) All opinions, views and comments expressed above are the personal opinions, views and comments of Mark R. Milligan and not of his employer. I Did'nt do it. Nobody saw me do it. You can't prove I did it. - Bart Simpson =============================================================================== --------------------------- Newsgroups: comp.os.vxworks Subject: NFS Server Availability? Date: 18 Jan 93 20:50:59 GMT From: feather@lds.loral.com (Bob Feather) Organization: Loral Data Systems Message-ID: <1993Jan18.205059.21774@lds.loral.com> Reply-To: feather@lds.loral.com Sender: news@lds.loral.com I would like to access a vxworks target booted from its own local disk from another vxworks target in the same vme container using the backplane net. Is there an NFS Server for vxworks anywhere??? Other ideas would be helpful. Has anybody tried something like this?? Help!! netDrv's copying of the entire file on an open or close is not acceptable for our application. Thanks --------------------------- End of New-News digest ********************** From xung@fibertek.com Tue Jan 19 07:08:53 1993 From: xung@fibertek.com ( Xung Dang ) Date: Tue Jan 19 07:09:05 PST 1993 Subject: Buffered VLDS SCSI driver I am looking for a SCSI driver for a high speed data recorder (Model: Buffered VLDS from Metrum Information Storage). The host is the MVME-167 running under VxWorks 5.0.2b. The SCSI driver must be able to run in the SYNC transfer mode. Any help in this matter is highly appreciated. Please send your response to: xung@fibertek.com Thanks, Xung Dang Fibertek, Inc. 510 Herndon Parkway Herndon, VA 22070 Phone: (703) 471-7671 Fax : (703) 471-5806 From @aaec1.aaec.com:mitchell@sparky.aaec.com Tue Jan 19 08:00:27 1993 From: Andy Mitchell Date: Tue Jan 19 08:00:37 PST 1993 Subject: Re: Mysterious task crashes I have a few comments to add on this subject. The illegal instruction at address 0x06 may be due to a jump to address 0x2 if the values there happen to be legal instructions. Since this problem happens in different tasks, I would think that someone is trashing your memory. It is not a problem with your interrupt vector table, since that would cause an "exception at interrupt level" message and reboot the SBC. I would be very suspicious of any other bus masters getting to the Tadpoles DRAM by accessing it as a VME slave. Many device drivers use command structures that are malloc'd from local memory, then converted to a VME address with sysLocalToBusAdrs(), which often requires slight modifications to work with different targets (i.e. DRAM size or address jumpers different than what the routine expects). If this mapping is done incorrectly, your devices could be writing results 4 Meg away from where you want. We had a horrible time with another vendor's SBC in a twenty-one slot card cage with 16 cards (two of which were 2-slot board sets). After many months of software thrashing (we were blaming our drivers for trashing DRAM) we found a correlation between errors like this and VME access of the multi-ported on-board DRAM. After more months of fault isolation by us and the vendor, they found that the DRAM cycle that follows a VME slave cycle could occur to the wrong address. Apparently Motorola does not specify the time required for the address bus of their 68030 chip to turn back on after getting the local bus back from another bus master (in this case, the VME interface). The board vendor did not allow enough time for the address to propagate to the DRAM before asserting the DRAM address strobes, so a write cycle could corrupt memory. In our case the errors were usually co-processor violations, because the 68030 timing is different if the 68882 is involved. The fault only seemed to occur in our backplane because the loading of all of the cards on the bus slowed down the VME cycles, which is neither the vendor or we could duplicate the problem in a "test" cage with only a few CPUs. I don't know if Tadpole has similar problems, but if there are any design shortcomings in a SBC board, VME Slave access of the on-board memory seems to bring them out! The vendors can't test against all slaves and are quick to blame the slave VME timing when problems occur. The big backplane also causes trouble. I've heard of other developers who had trouble with ringing of the VME strobe lines causing trouble with discrete high speed PAL VME interfaces as well. Another problem we had before was with the SBC overheating. A 50 MHz 68030 board usually needs good air flow to prevent overheating. On our boards, the first thing to go was the parity check circuit, causing a few parity errors - followed by a lock-up or reboot. I think these were caused by a failed DRAM cycles. I would think your SBC would also have similar serious problems, but you never know! good luck! (you'll need it!) Andrew Mitchell mitchell@aaec.com These are my own personal opinions, of course! From daemon@vxw.ee.lbl.gov Wed Jan 20 04:00:35 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 20 04:00:45 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 20 04:00:26 PST 1993 Subject: Database for VxWorks ? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Database for VxWorks ? Date: 19 Jan 93 16:06:03 GMT From: jprice@lds.loral.com (Jeffrey Price) Organization: Loral Data Systems Keywords: database isam relational file management Message-ID: <1993Jan19.160603.246@lds.loral.com> Reply-To: jprice@lds.loral.com Sender: news@lds.loral.com Does anyone know of a lightweight database system that runs under VxWorks ? A simple quasi-relational model system, or ISAM would be best. I do not need (nor expect) a full-blown rdb such as Oracle or Ingres. Thanks for the help ! Jeff Price (813)-371-0811 x6823 jprice@mail.lds.loral.com --------------------------- End of New-News digest ********************** From stan@rti.com Wed Jan 20 10:44:59 1993 From: stan@rti.com (Stan Schneider) Date: Wed Jan 20 10:45:09 PST 1993 Subject: Re: Memory management debug aids... Hi Steven, Sorry I'm so late responding. I've been out of town. We do indeed have a memory integrity verifier called "heapCheck". It's designed to help find bugs that corrupt the system memory pool. I think it will help find your problem. It's also a good thing to try when something bad happens "for no reason". HeapCheck is part of a library called "rtilib". Rtilib also contains some other useful utilities, like a crude-but-effective reentrant shell, some simplified network interfaces, etc. Our current plans are to include rtilib with StethoScope version 4.0.2. We expect to upgrade our customer base to this level along with VxWorks 5.1. However, we can ship current customers (like you) "beta" copies on request. I've appended the main manual page to this message. -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== Some context: >> Date: 15 Jan 93 00:59:23 GMT >> From: sjk@strl.labs.tek.com (Steven King) >> >> I'm looking for a tool that can help track down a memory overwrite under >> VxWorks. (Aren't we all?) This one is especially tough, since it happens >> in a reuseable C++ library that is rather complex and would be hard to >> "instrument" with printf(), memShow() or memPartShow(). >> >> Has anyone used Stethoscope in this manner? Is it possible? >> --------------------------------- >> Submitted-by fjr@rayssd.ssd.ray.com Fri Jan 15 13:39:44 1993 >> > Has anyone used Stethoscope in this manner? Is it possible? >> >> Stethoscope can track the location too periodically. I assume Stan >> Schnieder who wrote the tool will respond. Of course it is pretty hard >> to get from the periodic point where the value is corrupted to the exact >> code that did the corruption. ---------------------------------- >> Date: Fri, 15 Jan 93 21:11:39 GMT >> From: pardo@alta.Stanford.EDU (Gerardo Pardo-Castellote) >> >> I don't think you can use Stethoscope for that purpose. However >> Stethoscope comes with a tool called "heapCheck" that does something >> very close to what you want. ---------------------------------- {stan@rti:45} man heap Reformatting page. Wait... done heap(2) LibUtils Reference heap(2) NAME heap - Heap integrity test for VxWorks. SYNOPSIS heapWalk - dump the status of the heap heapCheck - check the status of the heap heapCheckInit - enable automatic heap checking int heapWalk(int minSize, int maxPrint, MEM_BLOCK *block) int heapCheck(int verbosity, MEM_BLOCK *block) int heapCheckInit(void) DESCRIPTION HeapCheck is a memory-management system integrity test rou- tine for VxWorks. It is designed to help find memory prob- lems that corrupt the system memory pool. Examples of prob- lems these routines will expose include writing off the end of an array, using an orphan pointer (i.e. one whose memory has been `free'ed), or messing up the allocated memory space in general. There are two ways to use heapCheck: as a spot check or as a background monitor. See the documentation for "heapCheck" and "heapCheckInit" for details. The VxWorks heap is normally structured in two pieces, referred to below as the "upper" and the "lower" heaps. The reason for this is that the highest 10K of memory is used during the booting process; that region is added to the sys- tem memory pool after booting is complete. NOTE Except for verbosity options, all messages are logged through logMsg instead of printf. This a) allows tasks that don't set VX_STDIO to use heapCheck, and b) prevents stack overflows. It does, however, mean that a VxWorks shell ses- sion should be active when heapCheck is being used. RTI Version 3.1 Last change: 9 Jan 1993 1 From bebek@Csa2.LBL.Gov Wed Jan 20 14:50:42 1993 From: bebek@Csa2.LBL.Gov Date: Wed Jan 20 14:50:51 PST 1993 Subject: POSIX Many months back, someone said they had a POSIX "wrapper" for vxworks. Where can I get this? I appreicate that this will be nothing more than a set of mapping functions. Chris Bebek Physics Research Division Superconducting Supercollider M/S 2000 2550 Beckleymeade Ave Dallas, TX 75237 bebek@sscvx1.ssc.gov (134.3.1.101) From daemon@vxw.ee.lbl.gov Thu Jan 21 04:00:36 1993 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 21 04:00:48 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 21 04:00:26 PST 1993 Subject: ppp or cslip implementation for VxWorks Subject: Re: Mysterious task crashes ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: ppp or cslip implementation for VxWorks Date: Wed, 20 Jan 93 22:49:24 GMT From: lazarus@leland.Stanford.EDU (Howard Wang) Organization: DSG, Stanford University, CA 94305, USA Keywords: ppp, cslip, VxWorks Message-ID: <1993Jan20.224924.25888@leland.Stanford.EDU> Sender: news@leland.Stanford.EDU (Mr News) Hi, Does anyone know of a PPP or cslip implementation for VxWorks? I know that slip is released as a driver with VxWorks, but I need to run ip stuff over a slow (5000 bps) link. So I'd like to try ppp (or cslip, ppp prefered). I may try to tackle this myself if nobody has before. Any help would be appreciated! Thanks! Howard H. Wang lazarus@sun-valley.stanford.edu 415-723-3608 --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Mysterious task crashes Date: Thu, 21 Jan 1993 06:28:47 GMT From: hjb@netcom.com (H. J. Bae) Organization: Peaceful Star Project Message-ID: <1993Jan21.062847.27457@netcom.com> References: <1993Jan15.184713.28368@wdl.loral.com> <1993Jan18.163643.619@ee.ubc.ca> markm@ee.ubc.ca (mark milligan) writes: >It looks like the pointer is writing an instruction to jump to location 0x0006 >where the illegal instruction is generated. ( I beleive this is the vector table?) m68k's look for SSP and PC values (in that sequence) starting at addr 0 upon powerup. 0x6 is pointing to least significant half of whatever was left there (possibly the kernel boot routine address). if i were you, i'd use a logic analyser to trigger at that address to track the problem down. if you don't have one of those, you could possibly hack up something -- like putting in a jsr instruction at the location to call your routine which can print out stack trace... or something like that (i know, pretty sick) hwajin - -- Hwa-Jin Bae hjb@netcom.com Peaceful Star Project 2899 Ford Street, Oakland CA 94601 Available for Civilian contract work. (510) 536-7607 --------------------------- End of New-News digest ********************** From peter@fibertek.com Thu Jan 21 06:21:29 1993 From: peter@fibertek.com (Peter H. Stern) Date: Thu Jan 21 06:21:41 PST 1993 Subject: Synergy SV420 board Hello. I am considering using a Synergy SV420 dual-68040 board with VxWorks running on both processors. I was wondering if anyone out there has ever used VxWorks with one of these boards and how well it worked out. I am curious about how useful 2 processors are in an I/O intensive application. Please post or contact peter@fibertek.com, (703) 471-7671. Thanks. From jagski@slug.ssc.gov Thu Jan 21 07:51:23 1993 From: jagski@slug.ssc.gov (Michael Jagieski) Date: Thu Jan 21 07:51:39 PST 1993 Subject: VxWorks scsiLib Questions (MVME147, MVME167) ---------- X-Sun-Data-Type: text X-Sun-Data-Description: text X-Sun-Data-Name: text X-Sun-Content-Lines: 0 ---------- X-Sun-Data-Type: default X-Sun-Data-Description: default X-Sun-Data-Name: help.vx X-Sun-Content-Lines: 32 Hello, I am trying to use the VxWorks scsiLib on a MVME147 and a MVME167. The device I'm trying to communicate with is a SCSI CAMAC crate controller. I have been successful in using the scsiIoctl routine to read and write a fixed amount of data. HOWEVER when the data that I am reading is variable, I get an error status (= 0x1f) on the MVME147 and the task hangs on the MVME167 waiting for a semaphore release. Somehow I think you are suppose to use the addLengthByte variable in the SCSI_TRANSACTION structure. Other problems is that auto-configuring works great for both boards but when one hard codes the call to scsiPhysDevCreate() the hook up appears normal but as soon as I try to access the device the task hangs like above on the MVME167. (This works fine on the MVME147). Also, the status I get back from this device is only suppose to be 0 or 2 yet I get 0, 2, or 4 from the MVME167 and 0, 0x82, 0x84 and 0x1f from the MVME147. I have noticed with time measurements that the MVME147 SCSI controller is 10 times slower than the MVME167. Issuing a simple command to this device takes 150 microseconds on the MVME167 but 1.50 milliseconds on the MVME147. Is this because a layer of SCSI firmware exists on the MVME147 ? Finally can one issue SCSI Messages in VxWorks besides SCSI Commands ? I would appreciate any help, thanks! jagski@slug.ssc.gov From thoff@netxwest.com Thu Jan 21 16:54:39 1993 From: thoff@netxwest.com (Todd Hoff) Date: Thu Jan 21 16:54:54 PST 1993 Subject: ping command available? Does anyone have a ping program, similar to Sun's, available under vxWorks? Thanx for any help. From chuckm@verdix.com Fri Jan 22 06:50:25 1993 From: Chuck Meade Date: Fri Jan 22 06:50:38 PST 1993 Subject: Re: ping command available? > Does anyone have a ping program, similar to Sun's, available under vxWorks? I put together a VXworks based ping() routine a while ago. Supply the host to ping as the first parameter and the number of packets to send as the second. ********** defs.h ************************ #include "vxWorks.h" #include "errno.h" #include "socket.h" #include "in_systm.h" #include "in.h" #include "ip.h" #include "ip_icmp.h" #include "netdb.h" #include "wdLib.h" #include "usrLib.h" #include "sigLib.h" #include "taskLib.h" *********** c-support.c ********************** #include "defs.h" #define OK 0 #define Bad_Host 1 #define Bad_Protocol 2 #define Cant_Create_Socket 3 #define From_Our_Request 0 #define Not_From_Our_Request 1 struct sockaddr_in dest; int sockfd; char *hostname ; struct protoent *proto ; u_char recvpack[4096] ; int num_received = 0 ; char configure_socket(the_hostname) char *the_hostname ; { dest.sin_family = AF_INET ; dest.sin_addr.s_addr = hostGetByName(the_hostname) ; if (dest.sin_addr.s_addr == ERROR) { printf("bad host!\n") ; return(Bad_Host) ; } strcpy(hostname,the_hostname) ; sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) ; if (sockfd < 0) { printf("can't create socket\n") ; return (Cant_Create_Socket) ; } else { return (OK) ; } } int in_cksm(msg_ptr) register u_short *msg_ptr ; { register long sum ; register u_short answer ; int index ; sum = 0 ; for (index = 0 ; index < 4 ; index++) { sum = sum + *msg_ptr ; msg_ptr++ ; } sum = (sum >> 16) + (sum & 0xffff) ; sum = sum + (sum >> 16) ; answer = ~sum ; return (answer) ; } int message_number = 1 ; void construct(msg) struct icmp *msg ; { u_char *byte_ptr ; byte_ptr = (u_char *) msg ; msg->icmp_type = ICMP_ECHO ; msg->icmp_code = 0 ; msg->icmp_cksum = 0 ; msg->icmp_id = 0x1234 ; msg->icmp_seq = message_number++ ; msg->icmp_data[0] = 0 ; msg->icmp_cksum = in_cksm(msg) ; } void xmt_msg(msg) struct icmp *msg ; { int i ; int packsize ; packsize = 8 ; i = sendto(sockfd, (caddr_t) msg, packsize, 0, (struct sockaddr *) &dest, sizeof(dest)) ; if (i < 0) { printf("sendto error\n") ; } else if (i != packsize) { printf("wrote %s %d bytes, return = %d\n", hostname, packsize, i) ; } } void receive_pings() { int n ; int fromlen ; struct sockaddr_in from ; int iphdrlen ; struct ip *ip ; struct icmp *icp ; int index ; extern int original_num_packets ; num_received = 0 ; while (1) /* loop until we break out */ { fromlen = sizeof(from) ; n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0, (struct sockaddr *) &from, &fromlen) ; if (n < 0) { if (errno != EINTR) { printf("recvfrom error\n") ; } else { printf("recvfrom interrupted (this is OK)\n") ; ; } } else { ip = (struct ip *) recvpack ; iphdrlen = ip->ip_hl << 2 ; icp = (struct icmp *) (recvpack + iphdrlen) ; if ((icp->icmp_type == ICMP_ECHOREPLY) && (icp->icmp_id == 0x1234)) { num_received++ ; if (num_received == original_num_packets) { exit() ; } } } } } ************** echo-transmitter.c ************************* #include "defs.h" void sig_alarm() ; void clean_up() ; void watchdog_routine() ; static WDOG_ID wid ; int the_tid ; struct icmp the_message ; void transmit_echo_message() { construct(&the_message) ; xmt_msg(&the_message) ; return ; } void dummy_alarm_handler() { ; } SIGVEC handler_info = {dummy_alarm_handler,0,0} ; SIGVEC save_handler_info ; void start_pinging() { extern int get_num_packets() ; extern void set_num_packets() ; sigInit() ; sigvec(SIGALRM, &handler_info, &save_handler_info) ; the_tid = taskIdSelf() ; wid = wdCreate() ; /* watchdog */ wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;; while (1) { if (get_num_packets() > 0) { set_num_packets(get_num_packets() - 1) ; transmit_echo_message() ; } else { break ; } pause() ; } pause() ; wdDelete(wid) ; clean_up() ; exit() ; } void watchdog_routine() { kill(the_tid,SIGALRM) ; wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ; } void clean_up() { extern int original_num_packets ; extern int num_received ; extern char *hostname ; if (num_received == original_num_packets) { printf("host %s is alive\n", hostname) ; } else { printf("response trouble with host %s: sent %d packet%c, received %d packet%c\n", hostname, original_num_packets, ((original_num_packets != 1) ? 's' : ' '), num_received, ((num_received != 1) ? 's' : ' ') ) ; } return ; } *********** ping-stats.c ******************************* #include "defs.h" static int num_packets ; void set_num_packets(to) int to ; { num_packets = to ; } int get_num_packets() { return (num_packets) ; } *********** ping.c **************************************** #include "defs.h" int original_num_packets ; int ping(arg1, arg2) char *arg1 ; int arg2 ; { extern int configure_socket() ; extern void start_pinging() ; extern void receive_pings() ; int num_packs ; int status ; /* get user's parameters */ if (arg1 != NULL) { if (arg2 > 1) { num_packs = arg2 ; } else { num_packs = 1 ; } } else { printf("Must enter a host name to Ping\n") ; return ; } set_num_packets(num_packs) ; original_num_packets = num_packs ; /* configure for network communications */ status = configure_socket(arg1) ; if (status == OK) { sp(start_pinging,0,0,0,0,0,0,0,0,0) ; sp(receive_pings,0,0,0,0,0,0,0,0,0) ; } else { printf("error while trying to configure socket\n") ; } } ************************************************************ Hope this is what you were looking for. Chuck Meade Verdix Product Support From chuckm@verdix.com Fri Jan 22 06:56:03 1993 From: Chuck Meade Date: Fri Jan 22 06:56:20 PST 1993 Subject: Re: ping command available? > Does anyone have a ping program, similar to Sun's, available under vxWorks? I put together a VXworks based ping() routine a while ago. Supply the host to ping as the first parameter and the number of packets to send as the second. ********** defs.h ************************ #include "vxWorks.h" #include "errno.h" #include "socket.h" #include "in_systm.h" #include "in.h" #include "ip.h" #include "ip_icmp.h" #include "netdb.h" #include "wdLib.h" #include "usrLib.h" #include "sigLib.h" #include "taskLib.h" *********** c-support.c ********************** #include "defs.h" #define OK 0 #define Bad_Host 1 #define Bad_Protocol 2 #define Cant_Create_Socket 3 #define From_Our_Request 0 #define Not_From_Our_Request 1 struct sockaddr_in dest; int sockfd; char *hostname ; struct protoent *proto ; u_char recvpack[4096] ; int num_received = 0 ; char configure_socket(the_hostname) char *the_hostname ; { dest.sin_family = AF_INET ; dest.sin_addr.s_addr = hostGetByName(the_hostname) ; if (dest.sin_addr.s_addr == ERROR) { printf("bad host!\n") ; return(Bad_Host) ; } strcpy(hostname,the_hostname) ; sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) ; if (sockfd < 0) { printf("can't create socket\n") ; return (Cant_Create_Socket) ; } else { return (OK) ; } } int in_cksm(msg_ptr) register u_short *msg_ptr ; { register long sum ; register u_short answer ; int index ; sum = 0 ; for (index = 0 ; index < 4 ; index++) { sum = sum + *msg_ptr ; msg_ptr++ ; } sum = (sum >> 16) + (sum & 0xffff) ; sum = sum + (sum >> 16) ; answer = ~sum ; return (answer) ; } int message_number = 1 ; void construct(msg) struct icmp *msg ; { u_char *byte_ptr ; byte_ptr = (u_char *) msg ; msg->icmp_type = ICMP_ECHO ; msg->icmp_code = 0 ; msg->icmp_cksum = 0 ; msg->icmp_id = 0x1234 ; msg->icmp_seq = message_number++ ; msg->icmp_data[0] = 0 ; msg->icmp_cksum = in_cksm(msg) ; } void xmt_msg(msg) struct icmp *msg ; { int i ; int packsize ; packsize = 8 ; i = sendto(sockfd, (caddr_t) msg, packsize, 0, (struct sockaddr *) &dest, sizeof(dest)) ; if (i < 0) { printf("sendto error\n") ; } else if (i != packsize) { printf("wrote %s %d bytes, return = %d\n", hostname, packsize, i) ; } } void receive_pings() { int n ; int fromlen ; struct sockaddr_in from ; int iphdrlen ; struct ip *ip ; struct icmp *icp ; int index ; extern int original_num_packets ; num_received = 0 ; while (1) /* loop until we break out */ { fromlen = sizeof(from) ; n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0, (struct sockaddr *) &from, &fromlen) ; if (n < 0) { if (errno != EINTR) { printf("recvfrom error\n") ; } else { printf("recvfrom interrupted (this is OK)\n") ; ; } } else { ip = (struct ip *) recvpack ; iphdrlen = ip->ip_hl << 2 ; icp = (struct icmp *) (recvpack + iphdrlen) ; if ((icp->icmp_type == ICMP_ECHOREPLY) && (icp->icmp_id == 0x1234)) { num_received++ ; if (num_received == original_num_packets) { exit() ; } } } } } ************** echo-transmitter.c ************************* #include "defs.h" void sig_alarm() ; void clean_up() ; void watchdog_routine() ; static WDOG_ID wid ; int the_tid ; struct icmp the_message ; void transmit_echo_message() { construct(&the_message) ; xmt_msg(&the_message) ; return ; } void dummy_alarm_handler() { ; } SIGVEC handler_info = {dummy_alarm_handler,0,0} ; SIGVEC save_handler_info ; void start_pinging() { extern int get_num_packets() ; extern void set_num_packets() ; sigInit() ; sigvec(SIGALRM, &handler_info, &save_handler_info) ; the_tid = taskIdSelf() ; wid = wdCreate() ; /* watchdog */ wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;; while (1) { if (get_num_packets() > 0) { set_num_packets(get_num_packets() - 1) ; transmit_echo_message() ; } else { break ; } pause() ; } pause() ; wdDelete(wid) ; clean_up() ; exit() ; } void watchdog_routine() { kill(the_tid,SIGALRM) ; wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ; } void clean_up() { extern int original_num_packets ; extern int num_received ; extern char *hostname ; if (num_received == original_num_packets) { printf("host %s is alive\n", hostname) ; } else { printf("response trouble with host %s: sent %d packet%c, received %d packet%c\n", hostname, original_num_packets, ((original_num_packets != 1) ? 's' : ' '), num_received, ((num_received != 1) ? 's' : ' ') ) ; } return ; } *********** ping-stats.c ******************************* #include "defs.h" static int num_packets ; void set_num_packets(to) int to ; { num_packets = to ; } int get_num_packets() { return (num_packets) ; } *********** ping.c **************************************** #include "defs.h" int original_num_packets ; int ping(arg1, arg2) char *arg1 ; int arg2 ; { extern int configure_socket() ; extern void start_pinging() ; extern void receive_pings() ; int num_packs ; int status ; /* get user's parameters */ if (arg1 != NULL) { if (arg2 > 1) { num_packs = arg2 ; } else { num_packs = 1 ; } } else { printf("Must enter a host name to Ping\n") ; return ; } set_num_packets(num_packs) ; original_num_packets = num_packs ; /* configure for network communications */ status = configure_socket(arg1) ; if (status == OK) { sp(start_pinging,0,0,0,0,0,0,0,0,0) ; sp(receive_pings,0,0,0,0,0,0,0,0,0) ; } else { printf("error while trying to configure socket\n") ; } } ************************************************************ Hope this is what you were looking for. Chuck Meade Verdix Product Support From chuckm@verdix.com Fri Jan 22 07:06:08 1993 From: Chuck Meade Date: Fri Jan 22 07:06:25 PST 1993 Subject: Re: ping command available? > Does anyone have a ping program, similar to Sun's, available under vxWorks? I put together a VXworks based ping() routine a while ago. Supply the host to ping as the first parameter and the number of packets to send as the second. ********** defs.h ************************ #include "vxWorks.h" #include "errno.h" #include "socket.h" #include "in_systm.h" #include "in.h" #include "ip.h" #include "ip_icmp.h" #include "netdb.h" #include "wdLib.h" #include "usrLib.h" #include "sigLib.h" #include "taskLib.h" *********** c-support.c ********************** #include "defs.h" #define OK 0 #define Bad_Host 1 #define Bad_Protocol 2 #define Cant_Create_Socket 3 #define From_Our_Request 0 #define Not_From_Our_Request 1 struct sockaddr_in dest; int sockfd; char *hostname ; struct protoent *proto ; u_char recvpack[4096] ; int num_received = 0 ; char configure_socket(the_hostname) char *the_hostname ; { dest.sin_family = AF_INET ; dest.sin_addr.s_addr = hostGetByName(the_hostname) ; if (dest.sin_addr.s_addr == ERROR) { printf("bad host!\n") ; return(Bad_Host) ; } strcpy(hostname,the_hostname) ; sockfd = socket(AF_INET, SOCK_RAW, IPPROTO_ICMP) ; if (sockfd < 0) { printf("can't create socket\n") ; return (Cant_Create_Socket) ; } else { return (OK) ; } } int in_cksm(msg_ptr) register u_short *msg_ptr ; { register long sum ; register u_short answer ; int index ; sum = 0 ; for (index = 0 ; index < 4 ; index++) { sum = sum + *msg_ptr ; msg_ptr++ ; } sum = (sum >> 16) + (sum & 0xffff) ; sum = sum + (sum >> 16) ; answer = ~sum ; return (answer) ; } int message_number = 1 ; void construct(msg) struct icmp *msg ; { u_char *byte_ptr ; byte_ptr = (u_char *) msg ; msg->icmp_type = ICMP_ECHO ; msg->icmp_code = 0 ; msg->icmp_cksum = 0 ; msg->icmp_id = 0x1234 ; msg->icmp_seq = message_number++ ; msg->icmp_data[0] = 0 ; msg->icmp_cksum = in_cksm(msg) ; } void xmt_msg(msg) struct icmp *msg ; { int i ; int packsize ; packsize = 8 ; i = sendto(sockfd, (caddr_t) msg, packsize, 0, (struct sockaddr *) &dest, sizeof(dest)) ; if (i < 0) { printf("sendto error\n") ; } else if (i != packsize) { printf("wrote %s %d bytes, return = %d\n", hostname, packsize, i) ; } } void receive_pings() { int n ; int fromlen ; struct sockaddr_in from ; int iphdrlen ; struct ip *ip ; struct icmp *icp ; int index ; extern int original_num_packets ; num_received = 0 ; while (1) /* loop until we break out */ { fromlen = sizeof(from) ; n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0, (struct sockaddr *) &from, &fromlen) ; if (n < 0) { if (errno != EINTR) { printf("recvfrom error\n") ; } else { printf("recvfrom interrupted (this is OK)\n") ; ; } } else { ip = (struct ip *) recvpack ; iphdrlen = ip->ip_hl << 2 ; icp = (struct icmp *) (recvpack + iphdrlen) ; if ((icp->icmp_type == ICMP_ECHOREPLY) && (icp->icmp_id == 0x1234)) { num_received++ ; if (num_received == original_num_packets) { exit() ; } } } } } ************** echo-transmitter.c ************************* #include "defs.h" void sig_alarm() ; void clean_up() ; void watchdog_routine() ; static WDOG_ID wid ; int the_tid ; struct icmp the_message ; void transmit_echo_message() { construct(&the_message) ; xmt_msg(&the_message) ; return ; } void dummy_alarm_handler() { ; } SIGVEC handler_info = {dummy_alarm_handler,0,0} ; SIGVEC save_handler_info ; void start_pinging() { extern int get_num_packets() ; extern void set_num_packets() ; sigInit() ; sigvec(SIGALRM, &handler_info, &save_handler_info) ; the_tid = taskIdSelf() ; wid = wdCreate() ; /* watchdog */ wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ;; while (1) { if (get_num_packets() > 0) { set_num_packets(get_num_packets() - 1) ; transmit_echo_message() ; } else { break ; } pause() ; } pause() ; wdDelete(wid) ; clean_up() ; exit() ; } void watchdog_routine() { kill(the_tid,SIGALRM) ; wdStart(wid, sysClkRateGet(), watchdog_routine, 0) ; } void clean_up() { extern int original_num_packets ; extern int num_received ; extern char *hostname ; if (num_received == original_num_packets) { printf("host %s is alive\n", hostname) ; } else { printf("response trouble with host %s: sent %d packet%c, received %d packet%c\n", hostname, original_num_packets, ((original_num_packets != 1) ? 's' : ' '), num_received, ((num_received != 1) ? 's' : ' ') ) ; } return ; } *********** ping-stats.c ******************************* #include "defs.h" static int num_packets ; void set_num_packets(to) int to ; { num_packets = to ; } int get_num_packets() { return (num_packets) ; } *********** ping.c **************************************** #include "defs.h" int original_num_packets ; int ping(arg1, arg2) char *arg1 ; int arg2 ; { extern int configure_socket() ; extern void start_pinging() ; extern void receive_pings() ; int num_packs ; int status ; /* get user's parameters */ if (arg1 != NULL) { if (arg2 > 1) { num_packs = arg2 ; } else { num_packs = 1 ; } } else { printf("Must enter a host name to Ping\n") ; return ; } set_num_packets(num_packs) ; original_num_packets = num_packs ; /* configure for network communications */ status = configure_socket(arg1) ; if (status == OK) { sp(start_pinging,0,0,0,0,0,0,0,0,0) ; sp(receive_pings,0,0,0,0,0,0,0,0,0) ; } else { printf("error while trying to configure socket\n") ; } } ************************************************************ Hope this is what you were looking for. Chuck Meade Verdix Product Support From rcm@rayssd.ssd.ray.com Fri Jan 22 09:50:18 1993 From: Mandler Date: Fri Jan 22 09:50:37 PST 1993 Subject: Re: ping command available? To thoff and other interested parties, Here is a "quick and dirty" version of the ping program that we ported to VxWorks. ______________________________________________________________ | Roland C Mandler, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4228) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!rcm | |______________________________________________________________| /* Includes, defines and global variables used between functions. */ #include "vxWorks.h" #include "mbuf.h" #include "ctype.h" #include "socket.h" #include "if.h" #include "ioLib.h" #include "ioctl.h" #include "iosLib.h" #include "stdioLib.h" #include "selectLib.h" #include "sockLib.h" #include "in_systm.h" #include "in.h" #include "ip.h" #include "ip_icmp.h" #include "taskLib.h" #include "hostLib.h" #include "wdLib.h" #include "errno.h" extern int errno; /* defines */ /* * Beware that the outgoing packet starts with the ICMP header and * does not include the IP header (the kernel prepends that for us). * But, the received packet includes the IP header. */ #define DEF_DATALEN 56 /* default data area after ICMP header */ #ifndef INADDR_NONE #define INADDR_NONE 0xffffffff /* should be in */ #endif #ifndef MAXHOSTNAMELEN #define MAXHOSTNAMELEN 64 /* should be defined in */ #endif #define MAXMSG 1 /* number of messages pipe will hold */ #define MAXPIPE 1 /* number of bytes in pipe message */ #define MAXPACKET 4096 /* max packet size */ #define MAXWAIT 10 /* max time to wait for response, sec. */ /* used only for final receive */ #define NROUTES 9 /* number of record route slots */ #define PF_ICMP 1 /* ICMP protocol */ #define QUIET 2 /* quiet flag */ #define RROUTE 8 /* record route flag */ #define SIZE_ICMP_HDR 8 /* 8-byte ICMP header */ #define SIZE_TIME_DATA 8 /* then the BSD timeval struct (ICMP "data") */ /* variables */ int datalen; /* size of data after the ICMP header */ /* may be 0 */ /* if >= SIZE_TIME_DATA, timing is done */ char *destdotaddr; char *hostname; short ident; /* masked process ID, to identify returns */ int mytask; /* full process ID */ int npackets; /* max # of packets to send; 0 if no limit */ int nreceived; /* # of packets we got back */ int ntransmitted; /* sequence # for outbound packets = #sent */ int pingflags; int packsize; /* size of ICMP packets to send */ /* this includes the 8-byte ICMP header */ char pipecode; int pipefd; /* pipe file descriptor */ int pipestat; u_char recvpack[MAXPACKET]; /* the received packet */ char rspace[3+4*NROUTES+1]; /* record route space */ long sbytes; u_char sendpack[MAXPACKET]; /* the packet we send */ int sockfd; /* socket file descriptor */ int time_start; int time_ret; int timing; /* true if time-stamp in each packet */ int tmin; /* min round-trip time */ int tmax; /* max round-trip time */ long tsum; /* sum of all round-trip times, for average */ /* above 3 times are in milliseconds */ int verbose; /* enables additional error messages */ /* structures */ struct fd_set fdset; /*file descriptor bit mapping for select */ struct fd_set *fdst; struct sockaddr_in dest; /* who to ping */ WDOG_ID wdtmr; /* routines */ char *inet_ntoa(); /* BSD library routine */ VOID ping_task(); VOID finish(); /* our function to finish up and exit */ VOID stp(); VOID timeout_hndl(); VOID parseOptions(); /* * Copyright (c) 1987 Regents of the University of California. * All rights reserved. * * Redistribution and use in source and binary forms are permitted * provided that the above copyright notice and this paragraph are * duplicated in all such forms and that any documentation, * advertising materials, and other materials related to such * distribution and use acknowledge that the software was developed * by the University of California, Berkeley. The name of the * University may not be used to endorse or promote products derived * from this software without specific prior written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR * IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED * WARRANTIES OF MERCHANTIBILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ #ifndef lint char copyright[] = "@(#) Copyright (c) 1987 Regents of the University of California.\n\ All rights reserved.\n"; #endif /* not lint */ #ifndef lint static char sccsid[] = "@(#)ping.c 4.10 (Berkeley) 10/10/88"; #endif /* not lint */ /* * P I N G . C * * Using the InterNet Control Message Protocol (ICMP) "ECHO" facility, * measure round-trip-delays and packet loss across network paths. * * Author - * Mike Muuss * U. S. Army Ballistic Research Laboratory * December, 1983 * Modified at Uc Berkeley * * This version was modified to run under vxWorks by: * Roland Mandler * Raytheon Submarine Signal Division * June, 1991 * * Status - * Public Domain. Distribution Unlimited. * * Bugs - * More statistics could always be gathered. * This program has to run SUID to ROOT to access the ICMP socket. */ char usage[] = "\nUsage: \ ping [-dnqrvRs] host [datasize [count]] \n\ \n\ STANDARD OPTIONS: \n\ -s = continuous -d = debug -q = quiet -v = verbose \n\ -R = record route -r = route to interface \n\ \n\ "; char hnamebuf[MAXHOSTNAMELEN]; char *pname; ping(strng) char strng[]; { /* spawn off ping task - makes it easier to kill */ taskSpawn(NULL, 1, VX_STDIO | VX_DEALLOC_STACK,20000,&ping_task, strng,0,0,0,0,0,0,0,0,0); } VOID ping_task(strng) char strng[]; { int sockoptions,on; int host; int pargc; int i, i1, i2, i3, i4; unsigned char ttl, loop; struct in_addr ifaddr; char *argvpar[11]; char **pargv = argvpar; /* parse input string into argc, argv format */ parseOptions(&pargc,pargv,strng); on = 1; pname = pargv[0]; pargc--; pargv++; fdst = (struct fd_set *)&fdset; sockoptions = 0; pingflags = 0; ntransmitted = 0; nreceived = 0; verbose = 0; timing = 0; tmin = 0; tmax = 0; npackets = 1; /* default is send one ping */ tmin = 0; tmax = 0; tsum = 0; wdtmr = wdCreate(); while (pargc > 0 && *pargv[0] == '-') { while (*++pargv[0]) switch (*pargv[0]) { case 'd': /* debug on */ sockoptions |= SO_DEBUG; break; case 'r': /* route to intfc */ sockoptions |= SO_DONTROUTE; break; case 'v': /* verbose input error printout */ verbose++; break; case 's': /* continuous pinging at 1 Hz */ npackets = 0; /* 1 Hz continuous pinging */ printf("\n\nTYPE 'stp' TO ABORT \n\n"); break; case 'q': /* disables ping send/recv messages */ pingflags |= QUIET; break; case 'R': /* record route */ pingflags |= RROUTE; break; default: goto print_usage; } pargc--, pargv++; } if (pargc < 1) { print_usage: printf(usage); return; } /* * Assume the host is specified by numbers (Internet dotted-decimal) * and call inet_addr() to convert it. If that doesn't work, then * assume its a name and call hostGetByName() to look it up. */ bzero((char *) &dest, sizeof(dest)); dest.sin_family = AF_INET; if ( (dest.sin_addr.s_addr = htons(inet_addr(pargv[0]))) != INADDR_NONE) { strcpy(hnamebuf, pargv[0]); hostname = hnamebuf; destdotaddr = NULL; } else { if ( (host = htons(hostGetByName(pargv[0]))) == NULL) { printf("host name error: %s ", pargv[0]); } dest.sin_family = AF_INET; dest.sin_addr.s_addr = host; strcpy(hnamebuf,pargv[0]); hostname = hnamebuf; destdotaddr = inet_ntoa(dest.sin_addr.s_addr); /* convert to dotted-decimal notation */ } /* * If the user specifies a size, that is the size of the data area * following the ICMP header that is transmitted. */ if (pargc >= 2) sscanf(pargv[1],"%d",&datalen); else datalen = DEF_DATALEN; packsize = datalen + SIZE_ICMP_HDR; if (packsize > MAXPACKET) printf("packet size too large"); if (datalen >= SIZE_TIME_DATA) timing = 1; /* * The user can specify the maximum number of packets to receive. */ if (pargc > 2) { sscanf(pargv[2],"%d",&npackets); printf("\n\nTYPE 'stp' TO ABORT \n\n"); } /* * Fetch our process ID. We use that as the "ident" field * in the ICMP header, to identify this process' packets. * This allows multiple copies of ping to be running on a host * at the same time. This identifier is needed to separate * the received ICMP packets (since all readers of an ICMP * socket get all the received packets). */ mytask = taskIdSelf(); ident = mytask & 0x7fff; /* * Create the socket. */ if ( (sockfd = socket(AF_INET, SOCK_RAW, PF_ICMP)) < 0) printf("can't create raw socket"); if (sockoptions & SO_DEBUG) if (setsockopt(sockfd, SOL_SOCKET, SO_DEBUG, &on, sizeof(on)) < 0) printf("setsockopt SO_DEBUG error"); if (sockoptions & SO_DONTROUTE) if (setsockopt(sockfd, SOL_SOCKET, SO_DONTROUTE, &on, sizeof(on)) < 0) printf("setsockopt SO_DONTROUTE error"); /* Record Route option */ if( pingflags & RROUTE ) { #ifdef IP_OPTIONS rspace[IPOPT_OPTVAL] = IPOPT_RR; rspace[IPOPT_OLEN] = sizeof(rspace)-1; rspace[IPOPT_OFFSET] = IPOPT_MINOFF; if( setsockopt(sockfd, IPPROTO_IP, IP_OPTIONS, rspace, sizeof(rspace)) < 0 ) { printf( "Record route" ); return; } #else printf( "ping: record route not available on this machine.\n" ); return; #endif IP_OPTIONS } /* create a communication pipe */ pipeDevCreate("ping_pipe",MAXMSG,MAXPIPE); if ((pipefd = open("ping_pipe", O_RDWR, (int) NULL)) == ERROR) { printf("error: can't open pipe.\n"); return; } /* set up bit map to select on pipe or socket i/o */ FD_SET(sockfd, fdst); FD_SET(pipefd, fdst); do_ping(); /* start the output going */ return; } /* This routine is the watchdog timer handler. It writes a timeout indication * to the pipe, which is in turn handled within 'do_ping' */ VOID timeout_hndl() { write(pipefd, "t", 1); } /* This routine controls ping origination and reception */ do_ping() { int finflag; register int n; int fromlen; struct sockaddr_in from; int cont; for ( ; ; ) { send_ping(); /* first send a packet */ if (npackets != 0) /* * We've sent the specified number of packets. * But, we can't just terminate, as there is at least one * packet still to be received (the one we sent at the * beginning of this function). * Just wait 10 seconds. */ wdStart (wdtmr, MAXWAIT * sysClkRateGet(), timeout_hndl); /* wait for either socket or pipe data availability */ if ( select (32,&fdset,NULL,NULL,NULL) > 0 ) { if (FD_ISSET(pipefd,fdst)) { pipestat = read (pipefd,&pipecode, MAXPIPE); finish(); break; /* escape the loop and exit the program */ } /* pipe data pending */ if (FD_ISSET(sockfd,fdst)) { fromlen = sizeof(from); if ( (n = recvfrom(sockfd, recvpack, sizeof(recvpack), 0, (struct sockaddr *) &from, &fromlen)) < 0) { if (errno == EINTR) continue; /* normal */ printf("recvfrom error"); break; } /* cancel 10 second timeout */ wdCancel(wdtmr); /* check the receive packet */ pr_pack(recvpack, n, &from); /* * If we're only supposed to receive a certain number of * packets, and we've reached the limit, stop. */ if (npackets && (nreceived >= npackets)) { finish(); break; } /* wait 1 second before pinging again */ taskDelay(sysClkRateGet()); } /* socket data pending */ } /* select data available */ } /* loop */ return; } /* * Compose and transmit an ICMP ECHO REQUEST packet. The IP header * will be prepended by the kernel. The ID field is our process ID, * and the sequence number is an ascending integer. The first 8 bytes * of the data portion are used to hold a BSD "timeval" struct in host * byte-order, to compute the round-trip time of each packet. */ send_ping() { register int i; register struct icmp *icp; /* ICMP header */ register u_char *uptr; /* start of user data */ /* * Fill in the ICMP header. */ icp = (struct icmp *) sendpack; /* pointer to ICMP header */ icp->icmp_type = ICMP_ECHO; icp->icmp_code = 0; icp->icmp_cksum = 0; /* init to 0, then call in_cksum() below */ icp->icmp_id = ident; /* our pid, to identify on return */ icp->icmp_seq = ntransmitted++; /* sequence number */ /* * And fill in the remainder of the packet with the user data. * We just set each byte of udata[i] to i (although this is * not verified when the echoed packet is received back). */ uptr = &sendpack[SIZE_ICMP_HDR + SIZE_TIME_DATA]; for (i = SIZE_TIME_DATA; i < datalen; i++) *uptr++ = i; /* * Compute and store the ICMP checksum (now that we've filled * in the entire ICMP packet). The checksum includes the ICMP * header, the time stamp, and our user data. */ icp->icmp_cksum = icmp_cksum(icp, packsize); /* * Add the time stamp of when we sent it. */ if (timing) time_start = tickGet(); /* * Now send the datagram. */ i = sendto(sockfd, sendpack, packsize, 0, (struct sockaddr *) &dest, sizeof(dest)); /* tell the user it went out */ if ((pingflags & QUIET) == 0) { printf("PING %s", hostname); if (destdotaddr) printf(" (%s)", destdotaddr); printf(": %d data bytes\n", datalen); setlinebuf(stdout); /* one line at a time */ } if (i < 0 || i != packsize) { if (i < 0) printf("sendto error"); else printf("wrote %s %d bytes, return=%d", hostname, packsize, i); } } /* * I C M P _ C K S U M * * Checksum routine for Internet Protocol family headers (C Version) * */ icmp_cksum(addr, len) u_short *addr; int len; { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0; /* * Our algorithm is simple, using a 32 bit accumulator (sum), * we add sequential 16 bit words to it, and at the end, fold * back all the carry bits from the top 16 bits into the lower * 16 bits. */ while( nleft > 1 ) { sum += *w++; nleft -= 2; } /* mop up an odd byte, if necessary */ if( nleft == 1 ) { *(u_char *)(&answer) = *(u_char *)w ; sum += answer; } /* * add back carry outs from top 16 bits to low 16 bits */ sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* truncate to 16 bits */ return (answer); } /* * Print out the packet, if it came from us. This logic is necessary * because ALL readers of the ICMP socket get a copy of ALL ICMP packets * which arrive ('tis only fair). This permits multiple copies of this * program to be run without having intermingled output (or statistics!). */ pr_pack(buf, cc, from) char *buf; /* ptr to start of IP header */ int cc; /* total size of received packet */ struct sockaddr_in *from; /* address of sender */ { int i, iphdrlen, triptime; struct ip *ip; /* ptr to IP header */ register struct icmp *icp; /* ptr to ICMP header */ long *lp; struct timeval tv; char *pr_type(); from->sin_addr.s_addr = ntohl(from->sin_addr.s_addr); if (timing) time_ret = tickGet(); /* * We have to look at the IP header, to get its length. * We also verify that what follows the IP header contains at * least an ICMP header (8 bytes minimum). */ ip = (struct ip *) buf; iphdrlen = ip->ip_hl << 2; /* convert # 16-bit words to #bytes */ if (cc < iphdrlen + ICMP_MINLEN) { if (verbose) printf("packet too short (%d bytes) from %s\n", cc, inet_ntoa(ntohl(from->sin_addr.s_addr))); return; } cc -= iphdrlen; icp = (struct icmp *)(buf + iphdrlen); if (icp->icmp_type != ICMP_ECHOREPLY) { /* * The received ICMP packet is not an echo reply. * If the verbose flag was set, we print the first 48 bytes * of the received packet as 12 longs. */ if (verbose) { lp = (long *) buf; /* to print 12 longs */ printf("%d bytes from %s: ", cc, inet_ntoa(ntohl(from->sin_addr.s_addr))); printf("icmp_type=%d (%s)\n", icp->icmp_type, pr_type(icp->icmp_type)); for (i = 0; i < 12; i++) printf("x%2.2x: x%8.8x\n", i*sizeof(long), *lp++); printf("icmp_code=%d\n", icp->icmp_code); } return; } /* * See if we sent the packet, and if not, just ignore it. */ if (icp->icmp_id != ident) return; if ((pingflags & QUIET) == 0) { printf("%d bytes from %s: ", cc, inet_ntoa(ntohl(from->sin_addr.s_addr))); printf("ping # = %d. \n ", icp->icmp_seq); } if (timing) { /* Calculate the round-trip time, and update the min/avg/max */ triptime =(time_ret - time_start) * (1000 /sysClkRateGet()); tsum += triptime; if (triptime < tmin) tmin = triptime; if (triptime > tmax) tmax = triptime; } nreceived++; /* only count echo reply packets that we sent */ } /* * Convert an ICMP "type" field to a printable string. * This is called for ICMP packets that are received that are not * ICMP_ECHOREPLY packets. */ char * pr_type(t) register int t; { static char *ttab[] = { "Echo Reply", "ICMP 1", "ICMP 2", "Dest Unreachable", "Source Quence", "Redirect", "ICMP 6", "ICMP 7", "Echo", "ICMP 9", "ICMP 10", "Time Exceeded", "Parameter Problem", "Timestamp", "Timestamp Reply", "Info Request", "Info Reply" }; if (t < 0 || t > 16) return("OUT-OF-RANGE"); return(ttab[t]); } /* * parseOptions.c * Generate Unix style (argc, argv) parameters from an incoming * VxWorks command string. Chops up the original string with * nulls to make short strings and fills the argv array with pointers * to the new strings. * * maximum of 10 parameters should be defined. (argv[11] in caller). * parameters should be seperated by blanks or tabs. */ VOID parseOptions(argc, argv, inpStr) int *argc; /* argument count */ char *argv[]; /* argument pointers */ char *inpStr; /* original input line */ { char *cch; /* current character */ cch = inpStr; *argc = 1; /* always at least 1 */ while (*cch != '\0') { while (((*cch == ' ') || (*cch == ' ')) && (*cch != '\0')) cch++; if (*cch != '\0') { argv[*argc] = cch; *argc += 1; while ((*cch != ' ') && (*cch != ' ') && (*cch != '\0')) cch++; if (*cch != '\0') *cch++ = '\0'; } } } /* * Print out statistics, and stop. */ VOID finish() { printf("\n----%s PING Statistics----\n", hostname ); printf("%d packets transmitted, ", ntransmitted ); printf("%d packets received, ", nreceived ); if (ntransmitted) printf("%d%% packet loss", (int) (((ntransmitted-nreceived)*100) / ntransmitted) ); printf("\n"); if (nreceived && timing) printf("round-trip (ms) min/avg/max = %d/%d/%d\n", tmin, tsum / nreceived, tmax ); wdCancel(wdtmr); close(pipefd); close(sockfd); printf("PING done. Hit .\n"); taskDelete(mytask); } /* termination of continuous pinging */ VOID stp() { finish(); } From daemon@vxw.ee.lbl.gov Sat Jan 23 04:00:46 1993 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 23 04:00:55 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 23 04:00:35 PST 1993 Subject: Re: ping command available? Subject: 000 Wind River Ski Trip 000 Subject: X ported to vxworks? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: ping command available? Date: Fri, 22 Jan 1993 16:23:27 GMT From: hjb@netcom.com (H. J. Bae) Organization: Peaceful Star Project Message-ID: <1993Jan22.162327.23310@netcom.com> References: <9301202154.AA10021@cinnabar.netx.com> In article <9301202154.AA10021@cinnabar.netx.com> thoff@netxwest.com (Todd Hoff) writes: >Does anyone have a ping program, similar to Sun's, available under vxWorks? not that i know of. it's easy to write one though. or you can port the guts of code from unix ping that opens a raw socket to write icmp echo packets. or, you can just allocate an mbuf, fill in the ip and icmp stuff into it and pass it to icmp_send() routine directly (less lines of code, no sockets) hwajin - -- Hwa-Jin Bae Peaceful Star Project 2899 Ford St., Oakland CA 94601 hjb@netcom.com (510) 536-7607 --------------------------- Newsgroups: comp.os.vxworks Subject: 000 Wind River Ski Trip 000 Date: 22 Jan 93 21:08:39 GMT From: pat@wrs.com (Patrick Boylan) Organization: Wind River Systems Keywords: ski ski ski ski ski Message-ID: Reply-To: pat@wrs.com Sender: news@wrs.com (News Manager) Some Wind River folk are planning a weekend ski trip to South Tahoe (leaving Alameda March 12). The plan is to charter a bus for the weekend. Accomodations are at fairly large condos (sleep 10). Cost depends on the number of people. For 30 - 40 people, the cost should be roughly as follows : Bus + accomodations: ~ $120 Heavenly valley 2 days: $78 It is NOT limited to just Wind River Systems so if anyone is interested in coming along, drop a note. Space is limited. Reply to pat@wrs.com or nigel@wrs.com. See ya there, Patrick - -- Patrick Boylan, - Wind River Systems, Alameda, CA - pat@wrs.com --------------------------- Newsgroups: comp.os.vxworks Subject: X ported to vxworks? Date: 23 Jan 93 00:28:30 GMT From: johnch@test22.sun.com (Sam the Skank from Geezer) Organization: Impossible Missions Force Message-ID: Has anyone ported X to vxworks, or tried? If so, how did it go? - -- John C --------------------------- End of New-News digest ********************** From daemon@vxw.ee.lbl.gov Sun Jan 24 04:00:43 1993 From: daemon@vxw.ee.lbl.gov Date: Sun Jan 24 04:00:52 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sun Jan 24 04:00:33 PST 1993 Subject: Distributed communications packages ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Distributed communications packages Date: Sat, 23 Jan 1993 20:28:16 GMT From: mkb@cs.cmu.edu (Mike Blackwell) Organization: Field Robotics Center, CMU Message-ID: Reply-To: mkb@cs.cmu.edu Sender: news@cs.cmu.edu (Usenet News System) I'm looking for *commercially supported* packages that allow communications between distributed processes running a mixture of VxWorks boxes and Sun workstations. Right now we're using CMU's TCA/TCX, but our client (NASA) is worried about long term support. I have a description of Sparta's ARTSE executive, which sounds like it would do the trick. Can anyone comment on their experiences with it? Are there any other packages out there? thanks! Mike Blackwell mkb@cs.cmu.edu --------------------------- End of New-News digest ********************** From tweadon@sadira.gb.nrao.edu Mon Jan 25 07:20:35 1993 From: tweadon@sadira.gb.nrao.edu (TIM WEADON) Date: Mon Jan 25 07:20:48 PST 1993 Subject: MC68230 PI/T Software driver I'm looking for a software driver for the MC68230 chip. Actually for the Motorola MV340B card. Does anyone out there have something I could use or at least start from? Thanks in advance. Tim Weadon P.O. Box 2 Green Bank, WV. 24944 (304) 456-2120 From visicom!VisiCom.COM!trest@nosc.mil Mon Jan 25 09:06:09 1993 From: Mike Trest Date: Mon Jan 25 09:06:18 PST 1993 Subject: Re: comp.os.vxworks newsdigest > Jeff Price > > Does anyone know of a lightweight database system that runs under VxWorks ? > A simple quasi-relational model system, or ISAM would be best. I do not > need (nor expect) a full-blown rdb such as Oracle or Ingres. Jeff, I would acquire C-ISAM for the PC which is available in source format. Several years ago I ported the code to several UNIX platforms and modified for custom DBMS use. It should port easily to vxWorks. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From visicom!VisiCom.COM!trest@nosc.mil Mon Jan 25 10:00:06 1993 From: Mike Trest Date: Mon Jan 25 10:00:16 PST 1993 Subject: Re: comp.os.vxworks newsdigest > > Has anyone ported X to vxworks, or tried? If so, how did it go? > > - -- John C John, VisiCom Laboratories did this about 2 years ago. X and MOTIF standard distributions are available for X11R4 and X11R5 (soon). Since we had done several previous port of X the move to vxWorks was relatively easy. The main problems were in the "environmental assumptions about UNIX" which implicit in the prototype code from MIT and OSF. Now, the product uses client code which is written for any level of X (Xlib,Xtoolkit,Athena,MOTIF) and will handle code generated by most of the GUI builders. It is in use by several hardware OEMs for use in their custom products. It is available now for 68K, SPARC targets. It has a full X server implementation as well as support for several different hardware display adapters. If you need additional information please EMAIL Mr. Gene Kennon at: gene_kennon@visicom.com ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 457 2111 Technology Group Fax: 619 457 0888 VisiCom Laboratories San Diego, CA ==================================================== From thoff@netxwest.com Mon Jan 25 15:05:59 1993 From: thoff@netxwest.com (Todd Hoff) Date: Mon Jan 25 15:06:07 PST 1993 Subject: Re: comp.os.vxworks newsdigest Thanx. I received several pings, but yours sounds the shortest. From daemon@vxw.ee.lbl.gov Tue Jan 26 04:00:56 1993 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 26 04:01:05 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 26 04:00:46 PST 1993 Subject: Looking for VME-based encoder board that works under VxWorks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Looking for VME-based encoder board that works under VxWorks Date: 25 Jan 93 15:58:42 GMT From: miller@isrc.sandia.gov (Dave Miller) Organization: Sandia National Labs, Org. 1600, Albq., NM Message-ID: <1993Jan25.155842.27584@isrc.sandia.gov> I am interested in interfacing a CNC machine to a VME bus in order to implement joint position feedback from the CNC controller. 4 of the 5 axes on my CNC have encoders with relatively easy access to their signals. I am looking for a VME encoder board which can be programmed to receive these signals and convert them into X, Y, Z, A, and B values. Has anyone had any experience using this type of interface or recommendations for a vendor which supplies a suitable interface board ? Thanks Dave Miller miller@isrc.sandia.gov --------------------------- End of New-News digest ********************** From stan@rti.com Tue Jan 26 15:52:11 1993 From: stan@rti.com (Stan Schneider) Date: Tue Jan 26 15:52:23 PST 1993 Subject: Re: comp.os.vxworks newsdigest >> Date: 25 Jan 93 15:58:42 GMT >> From: miller@isrc.sandia.gov (Dave Miller) >> >> I am interested in interfacing a CNC machine to a VME bus in order to >> implement joint position feedback from the CNC controller. 4 of the 5 >> axes on my CNC have encoders with relatively easy access to their signals. >> I am looking for a VME encoder board which can be programmed to receive >> these signals and convert them into X, Y, Z, A, and B values. Has anyone >> had any experience using this type of interface or recommendations for a >> vendor which supplies a suitable interface board ? >> We've used some boards by Whedco in Ann Arbor with good results. We have VxWorks drivers for the Whedco 3570 board available. Drop me a line if you're interested. -- Stan =============================================================================== = = = = Stan Schneider = email: stan@rti.com = = Real-Time Innovations, Inc. = Phone: (408) 720-8312 = = 954 Aster, Sunnyvale, CA 94086 = Fax: (408) 720-8419 = = = = =============================================================================== From interf!atlas!athena!buchanan@uunet.uu.net Tue Jan 26 17:11:25 1993 From: interf!atlas!athena!buchanan@uunet.uu.net (Keith Buchanan) Date: Tue Jan 26 17:11:45 PST 1993 Subject: Distributed communications packages We use ARTSE at the Naval Observatory in the Optical Interferometer Project. We have a distributed control system with Themis 680x0 CPUs, Heurikon 680x0 CPUs and SUN 3 & 4 workstations. ARTSE has performed well for us not only for network communications but for process control, startup etc. Mike Anderson et al at Sparta have been most helpful with any questions we have posed. I would recommend the product and the company supporting it to my own brother. Anyone requiring a more in depth commentary, please contact me via e-mail at buchanan@interf.com. If there is considerable traffic, I will post it to the exploder. Keith Buchanan Interferometrics, Inc. 8150 Leesburg Pike Vieena, VA 22182-2799 From daemon@vxw.ee.lbl.gov Wed Jan 27 04:00:52 1993 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 27 04:01:01 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 27 04:00:43 PST 1993 Subject: Newer GCC? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Newer GCC? Date: Tue, 26 Jan 1993 21:11:08 GMT From: dwilliam@pizza.ess.harris.com (Dave Williams) Organization: Harris Corporation - ISD Keywords: vxWorks 5.0.3 Message-ID: Sender: usenet@jabba.ess.harris.com (Usenet News Feed Account) Here's a question for WRS - what version of the GCC compiler are you planning on releasing with the newest release of VxWorks? I noticed a few days back that the latest and greatest is up to 2.3.3. Any plans? (We really want to use some of the neat C++ - comments (//) that the new GCC includes) - -- Dave Williams | "What time is it?" "9:00AM" dwilliam@jabba.ess.harris.com | "What day?" "Monday" "Huh? What? Could you repeat the question?" | "Go away. Try me Tuesday" opinions mine --------------------------- End of New-News digest ********************** From talarian!brianq@uunet.uu.net Wed Jan 27 11:43:14 1993 From: talarian!brianq@uunet.uu.net (Brian Quigley) Date: Wed Jan 27 11:43:23 PST 1993 Subject: Executing shell scripts I've got a need to execute a shell script from within a program I'm working on. I figured I'd copy the startup shell script code since it does what I want. Unfortunately, the code that I took from usrConfig.c does not behave the same when I put it my code. The script does not execute. I've tried killing any existing shell before I start the new one. This doesn't seem to help. Various messing with ioTaskSetStd, shellOrigStdSet, and ioGlobalStdSet produce undesirable results. Any hints would be appreciated. Thanks. (P.S. Hints for a Unix like "system()" call would also be appreciated.) --- Brian Quigley | brianq@talarian.com Talarian Corporation | (415)965-8050 From fwr8bv@fin.af.mil Wed Jan 27 16:40:34 1993 From: Chatterjee S Date: Wed Jan 27 16:40:43 PST 1993 Subject: Motorola MVME-332 Driver Does anyone have a vxWorks (5.0) driver for the Mototola MVME-332 (which is an "Intelligent Communications Controller" for serial comm.)? We are using it (4 of the 8 ports available) to interface to 4 Gulton digital strip-chart recorders. Thanks, Shash. +-----------------------------------------------------------------------------+ + Shash Chatterjee EMAIL: fwr8bv@fin.af.mil + + EC Software PHONE: (817) 763-1495 + + General Dynamics, Ft. Worth Div. FAX: (817) 777-2115 + + P.O. Box 748, MZ1719 + + Ft. Worth, TX 76101 + +-----------------------------------------------------------------------------+ From zander@luke.atdiv.lanl.gov Thu Jan 28 11:22:42 1993 From: zander@luke.atdiv.lanl.gov (Mark Zander) Date: Thu Jan 28 11:29:26 PST 1993 Subject: Re: Executing shell scripts Sorry it took so long, but I wanted to clear this before sending it. Brian Quigley writes: > I've got a need to execute a shell script from within a program I'm > working on. I figured I'd copy the startup shell script code since it > does what I want. Unfortunately, the code that I took from usrConfig.c > does not behave the same when I put it my code. The script does not execute. > > I've tried killing any existing shell before I start the new one. This > doesn't seem to help. Various messing with ioTaskSetStd, > shellOrigStdSet, and ioGlobalStdSet produce undesirable results. > > Any hints would be appreciated. > > Thanks. > > (P.S. Hints for a Unix like "system()" call would also be appreciated.) I've had a similar need to execute shell scripts from a unix shell. The following code worked for that purpose. I hope it can help you as well. Good luck! /* r s h d . c * ************************************************************************* * * L O S A L A M O S * Los Alamos National Laboratory * Los Alamos, New Mexico 87545 * * File Name: rshd.c * Environment: VxWorks V4.0 * Developement: Sun C, Sun OS 4.0, Sun 3/60 * Make Description: * * * Modification History * ------------ ------- * * Date Programmer Comments * ---- ---------- -------- * * 1-Jun-90 Mark Zander Borrowed from telnetLib * ************************************************************************* */ /* * Source Code Control System Identifier */ static char SccsId[ ] = "@(#)rshd.c 1.1 11/20/91"; /* ************************************************************************* *++ * Name * ---- * *>> rshd - remote shell daemon for vxWorks * * Purpose * ------- * * * Subroutine List * ---------- ---- * * rshInit - initialize remote shell daemon * rshd - remote shell daemon * * Include Files * ------- ----- * * * * See Also * --- ---- * * *-- ************************************************************************* */ #include "vxWorks.h" #include "types.h" #include "socket.h" #include "in.h" #include "ioLib.h" #include "taskLib.h" /* login 513/tcp */ /* shell 514/tcp cmd # no passwords used */ #define RSH_SERVICE 514 /* shell port number */ #define STDIN_BUF_SIZE 512 static int rshTaskOptions = VX_SUPERVISOR_MODE | VX_UNBREAKABLE; static int rshTaskStackSize = 1500; static int rshTaskPriority = 2; int rshdId; /* task id of rshd task */ static char *rshShellName = "shell"; static char *ptyRshName = "/pty/rsh."; static char *ptyRshNameM = "/pty/rsh.M"; /* master side */ static char *ptyRshNameS = "/pty/rsh.S"; /* slave side */ VOID rshd( ); /* ************************************************************************* *+ * Name * ---- * *> rshInit - initialize remote shell daemon * * Purpose * ------- * * Remote shell initialize. * * Calling Sequence * ------- -------- * * rshInit( ); * *- ************************************************************************* */ VOID rshInit( ) { static BOOL done = FALSE; /* FALSE = not done */ if ( done ) { printErr( "rshInit: already initialized.\n" ); return; } if ( ptyDrv( ) == ERROR || ptyDevCreate( ptyRshName, 1024, 1024 ) == ERROR ) { printErr ("rshInit: unable to create pty device.\n"); return; } rshdId = taskSpawn( "rshd", rshTaskPriority, rshTaskOptions, rshTaskStackSize, rshd, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 ); if ( rshdId == ERROR ) { printErr( "rshInit: unable to spawn rshd.\n" ); } else { done = TRUE; } } /* ************************************************************************* *+ * Name * ---- * *> rshd - remote shell daemon * * Purpose * ------- * * Remote shell daemon. Similar to telnetd. Executes a shell command sent * via the shell socket from another machine. Does not redirect input or * output of the given command and for this reason requires a special version * of the unix rshell command. Started from routine "rshInit". * * Calling Sequence * ------- -------- * * rshd( ); *- ************************************************************************* */ VOID rshd( ) { int optval; struct sockaddr_in myAddress; struct sockaddr_in clientAddress; int clientAddrLen; int client; int masterFd; int slaveFd; int sd; char buf[ STDIN_BUF_SIZE ]; int n; int shellInFd; /* * Open a socket and wait for a client */ sd = socket( AF_INET, SOCK_STREAM, 0 ); bzero( (char *) &myAddress, sizeof( myAddress ) ); myAddress.sin_family = AF_INET; myAddress.sin_port = RSH_SERVICE; if ( bind( sd, (struct sockaddr *) &myAddress, sizeof( myAddress ) ) == ERROR ) { printErr( "rshd: bind failed.\n" ); return; } listen( sd, 5 ); FOREVER { /* * Wait for shell to exist */ while ( taskNameToId( rshShellName ) == ERROR ) { taskDelay( sysClkRateGet( ) ); } errnoSet( OK ); /* clear errno for pretty i() display */ /* * Now accept connection */ clientAddrLen = sizeof( clientAddress ); client = accept( sd, (struct sockaddr *) &clientAddress, &clientAddrLen ); if ( client == ERROR ) { printErr( "rshd: accept failed - status = 0x%x\n", errnoGet( ) ); continue; } /* * create the pseudo terminal: * the master side is connected to the socket to the remote machine */ if ( ( masterFd = open( ptyRshNameM, WRITE ) ) == ERROR ) { char *msg = "\r\nSorry, trouble with pty.\r\n"; printErr( "rshd: error opening %s\n", ptyRshNameM ); write( client, msg, strlen( msg ) ); close( client ); continue; } if ( ( slaveFd = open( ptyRshNameS, READ ) ) == ERROR ) { char *msg = "\r\nSorry, trouble with pty.\r\n"; printErr( "rshd: error opening %s\n", ptyRshNameS ); write( client, msg, strlen( msg ) ); close( client ); close( masterFd ); continue; } /* * Set up slave */ ioctl( slaveFd, FIOOPTIONS, OPT_RAW ); ioctl( slaveFd, FIOFLUSH ); /* * Save original standard in of shell */ shellInFd = ioGlobalStdGet( STD_IN ); /* * Redirect standard in of shell */ shellOrigStdSet( STD_IN, slaveFd ); /* * Restart shell so it'll accept this command */ taskRestart( taskNameToId( rshShellName ) ); /* * Get command form remote host and send it to shell */ if ( ( n = read( client, buf, sizeof( buf ) ) ) > 0 ) { buf[n] = 0; write( masterFd, buf, n ); } /* * Set shell back to orginal standard in */ shellOrigStdSet( STD_IN, shellInFd ); /* * Close connections to shell and remote host */ close( masterFd ); close( slaveFd ); close( client ); } } /* v s h . c * ************************************************************************* * * L O S A L A M O S * Los Alamos National Laboratory * Los Alamos, New Mexico 87545 * * File Name: vsh.c * Environment: VxWorks V4.0 * Developement: Sun C, Sun OS 4.0, Sun 3/60 * Make Description: * * * Modification History * ------------ ------- * * Date Programmer Comments * ---- ---------- -------- * * 4-Jun-90 Mark Zander Original * 21-Nov-91 me change name from rsh to vsh to avoid name * clashes * ************************************************************************* */ /* ************************************************************************* *+ * Name * ---- * *> vsh - execute remote shell command on a vxWorks system * * Purpose * ------- * * Executes a remote shell command for a vxWorks system. Sends one command * over the shell socket. Is similar to the unix rsh command but does not * redirect stdin and stdout. * * Command * ------- * * % vsh hostname cmd * * or * * % vsh * Host name? hostname * Command? cmd * * Arguments * --------- * * hostname name of host listed in yp directory * cmd remote command to be executed * * Example * ------- * * * Special Comments * ------- -------- * * * See Also * --- ---- * * *- ************************************************************************* */ #include #define RSH_SERVICE 514 /* shell port number */ /* * Source Code Control System Identifier */ static char SccsId[ ] = "@(#)vsh.c 1.3 11/21/91"; void main(argc, argv) /* * Arguments */ int argc; /* command line argument count */ char **argv; /* command line arguments */ { /* * Variables */ int argin; /* argument index */ char hostname[100]; /* host name */ char cmd[300]; /* remote command */ int sock; /* socket */ int i; /* iteration counter */ argin = 1; getarg("Host name? ", argc, argv, &argin, hostname); getarg("Command? ", argc, argv, &argin, cmd); for (i = argin; i < argc; i++) { strcat(cmd, " "); strcat(cmd, argv[i]); } strcat(cmd, "\n"); sock = socClient(hostname, RSH_SERVICE); write(sock, cmd, strlen(cmd)); close(sock); } From daemon@vxw.ee.lbl.gov Fri Jan 29 04:00:57 1993 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 29 04:01:07 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 29 04:00:48 PST 1993 Subject: VIC068 DMA Subject: Re: ppp or cslip implementation for VxWorks Subject: OR VME products ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: VIC068 DMA Date: Fri, 22 Jan 93 15:50:19 GMT From: singer@ll.mit.edu (Matthew R. Singer) Organization: MIT Lincoln Laboratory Message-ID: <1993Jan22.155019.26724@ll.mit.edu> Reply-To: singer@ll.mit.edu (Matthew R. Singer) Sender: singer@ll.mit.edu (Matthew R. Singer) - -- Can anyone provide me a short code fragment showing how to do a DMA transfer using the vic068 chip? Thanks - ---------------------------------------------------------------------------- Matthew R. Singer MIT Lincoln Laboratory (617) 981-3771 244 Wood Street singer@ll.mit.edu Lexington, MA 02173 - ----------------------------------------------------------------------------- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: ppp or cslip implementation for VxWorks Date: 26 Jan 93 18:32:39 GMT From: ajm@wilson.fibercom.com (AJ Madison) Keywords: ppp, cslip, VxWorks Message-ID: <45309@fibercom.COM> References: <1993Jan20.224924.25888@leland.Stanford.EDU> Sender: news@fibercom.COM In article <1993Jan20.224924.25888@leland.Stanford.EDU>, lazarus@leland.Stanford.EDU (Howard Wang) writes: > Hi, > Does anyone know of a PPP or cslip implementation for VxWorks? > I know that slip is released as a driver with VxWorks, but I need > to run ip stuff over a slow (5000 bps) link. So I'd like to try > ppp (or cslip, ppp prefered). > > I may try to tackle this myself if nobody has before. > > Any help would be appreciated! Thanks! > I'm not particularly fond of Me Too postings. However, on the off chance that any responses to Howard's request were all over e-mail, I also am interested in a vxworks PPP. Also, to open things up a bit, has anyone ported one of the PD versions of PPP to a VxWorks environment? I have copies of the original ppp, ppp-1.1, and dp-2.2, so if the comments are terse portation notes, I'd be more than willing to take a look anyway. I'm definitely doing a PPP, but depending upon how things work out, it may not necessarily be VxWorks. - -- A.J. Madison PHONE: (703) 342-6700 X383 FiberCom, Inc. FAX: (703) 342-5961 P.O. Box 11966 INTERNET: ajm@fibercom.com Roanoke, VA 24022-1966 UUCP: ...!uunet!fibercom!ajm --------------------------- Newsgroups: comp.robotics,comp.os.vxworks,sci.electronics Subject: OR VME products Date: Thu, 28 Jan 1993 19:18:58 GMT From: nivek@cs.cmu.edu (Kevin Dowling) Organization: Robotics Institute, Carnegie Mellon Message-ID: References: <1k6si7INNkcc@life.ai.mit.edu> Reply-To: nivek@cs.cmu.edu Sender: news@cs.cmu.edu (Usenet News System) We are looking at some low power 3U VME products ('030, A/D, D/A, Enet, '332) from OR which is represented by Dynatem in the US. We've had good experiences with other Dynatem products (low power 6U cards) but would like to hear from others who've had experience with the OR boards, especially those who've used VxWorks with them. The power specs (computational and watts) are very good and the environmental specs are excellent as well but it'd be nice to hear from others. Thanks. nivek - --- aka: Kevin Dowling Carnegie Mellon University tel: (412) 268-8830 The Robotics Institute adr: nivek@ri.cmu.edu Pittsburgh, PA 15213 --------------------------- End of New-News digest ********************** From mea@sparta.com Fri Jan 29 11:43:25 1993 From: mea@sparta.com (Mike Anderson) Date: Fri Jan 29 11:43:52 PST 1993 Subject: West coast User's Group Meeting w/ BUSCON? Greetings! I just wanted to know if there was going to be a west coast User's Group meeting in conjunction with BUSCON? If so, where and when? Do you need presentations? Demos? If the responsible parties could post something to the net, I'd be most interested in find out the sitch. Later, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE R A A D D D D E M M M M // A A R R TT S E AAAAAA D D D D EEEEE M M M // AAAAAA RRRR TT SSS EEEEE A A D D D D E M M // A A R R TT S E A A D D D D EEEEE M M // A A R R TT SSSSS EEEEE Process Distribution/Control and Communications for Distributed Systems Mike Anderson Voice: (703) 448-0210 ext. 235 Director, Information Systems Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "It is useless for sheep to pass resolutions McLean, VA 22102 in favor of vegetarianism while wolves remain of a different opinion." William R. Inge, D.D. ============================================================================== From baumann@proton.llumc.edu Fri Jan 29 11:45:05 1993 From: baumann@proton.llumc.edu (Michael Baumann) Date: Fri Jan 29 11:45:23 PST 1993 Subject: G++ Cross compiler We are now in the mode of developing code on a MVME167 and would like to continue to use G++. We are currently using a g++ built on gcc/g++ 1.40 I would like to use one based on gcc 2.3.3. This would cross-compile from a SS2 to the 167. Has anyone gone to the pains of building such, and if so please talk to me. Thanks, Michael Baumann Radiation Research Lab |Internet: baumann@proton.llumc.edu Loma Linda Universtiy Medical Center | UUCP: ...ucrmath!proton!baumann Loma Linda, California. (714)824-4077| From zander@luke.atdiv.lanl.gov Fri Jan 29 13:42:51 1993 From: zander@luke.atdiv.lanl.gov (Mark Zander) Date: Fri Jan 29 13:42:58 PST 1993 Subject: Re: G++ Cross compiler > Michael Baumann writes: > We are now in the mode of developing code on a MVME167 and would like to > continue to use G++. We are currently using a g++ built on gcc/g++ 1.40 > I would like to use one based on gcc 2.3.3. This would cross-compile from > a SS2 to the 167. > > Has anyone gone to the pains of building such, and if so please talk to me. I'm currently developing code in C++ and running it on the sun. The target environment is vxworks however so we are interested in C++ on a 167 as well. From daemon@vxw.ee.lbl.gov Sat Jan 30 04:00:27 1993 From: daemon@vxw.ee.lbl.gov Date: Sat Jan 30 04:00:38 PST 1993 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Sat Jan 30 04:00:18 PST 1993 Subject: X.25 or HDLC driver wanted Subject: scsi driver needed Subject: Re: West coast User's Group Meeting w/ BUSCON? Subject: Need the FAQ for comp.os.vxworks ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: X.25 or HDLC driver wanted Date: Fri, 29 Jan 1993 15:43:09 GMT From: an7499@anon.penet.fi Organization: Anonymous contact service Message-ID: <1993Jan29.160404.29731@fuug.fi> Sender: anon@fuug.fi (The Anon Administrator) Does anyone have the source code for an X.25 or HDLC driver under vxworks? The particular target is unimportant, since I would have to customize it anyway for what I'm doing. My main interest is getting the logic that performs the HDLC LAPB protocol. - ------------------------------------------------------------------------- To find out more about the anon service, send mail to help@anon.penet.fi. Due to the double-blind system, any replies to this message will be anonymized, and an anonymous id will be allocated automatically. You have been warned. --------------------------- Newsgroups: comp.sys.m68k,comp.sys.m88k,comp.realtime,comp.os.vxworks Subject: scsi driver needed Date: Fri, 29 Jan 1993 20:09:50 GMT From: wybo@adi.com (Dave Wybo) Organization: Applied Dynamics Message-ID: <1993Jan29.200950.22529@adi.com> Sender: news@adi.com I am looking for some SCSI code to handle the NCR 53C710 or 53C720 SCSI chip. If anyone has information regarding the availabliity of a driver for this chip, I would really appreciate hearing from you. Thanks in advance. - -- - -- Dave Wybo ADI, 3800 Stone School Rd. Ann Arbor, MI 48108 (313) 973-1300 Reachable at: wybo@adi.com - -- --------------------------- Newsgroups: comp.os.vxworks Subject: Re: West coast User's Group Meeting w/ BUSCON? Date: 29 Jan 93 23:25:31 GMT From: sjk@strl.labs.tek.com (Steven King) Organization: Software Technology Research Lab, Tektronix, Inc. Message-ID: <5115@crl.LABS.TEK.COM> References: <9301291835.AA01185@borg> Followup-To: comp.os.vxworks Reply-To: sjk@strl.labs.tek.com (Steven King) Sender: news@crl.LABS.TEK.COM In article <9301291835.AA01185@borg>, mea@sparta.com (Mike Anderson) writes: |> Greetings! |> |> I just wanted to know if there was going to be a west coast User's Group |> meeting in conjunction with BUSCON? If so, where and when? Do you need |> presentations? Demos? If the responsible parties could post something to |> the net, I'd be most interested in find out the sitch. As chairperson of the 1993 West Coast UG, my official answer is "I don't know!" I am in contact with the appropriate folks at Wind River, and we should be announcing times and dates within the month. (The 1992 UG meeting was held on April 10th, and I anticipate a similar timeframe for 1993.) I would appreciate the following input from the VxWorks community: o Did you like the format of the 1992 meeting? What would you like to see more of? Less of? Different? o Would workshops covering specific topics be of interest? Subjects such as "Using VxWorks 5.1 MMU capabilities", "Using C++ with VxWorks" or "Development with MicroWorks" are possibilities. o Would people like to see demos of 3rd party products? Stethoscope, ARTSE and others come to mind. Would this be a trade-show format or tutorial format? o Would people like more talks on specific applications? "How I solved this problem..." stories? o Would a 1 1/2 day or 2 day meeting be acceptable? Do you prefer the one day format? Would a one day meeting with 1/2 day of optional workshops be workable? o I would like to find a new chairperson for 1994. If you have the slightest interest, please give me a call to discuss the task. It's not much work, since people at Wind River make most of the arrangements. You simply show up and get sweaty palms talking in front of a large audience (JUST KIDDING - REALLY). Think about it. For those who can't remember the 1992 meeting (?) or did not attend, the agenda was roughly as follows: 7:30 - 8:30 Breakfast 8:30 - 8:35 Welcome 8:35 - 9:00 Wind River Systems Update - Jerry Fiddler 9:00 - 9:30 VxWorks Update - Tony Barbagallo 9:30 - 10:30 WRS Technology - David Wilner 10:30 - 10:45 BREAK 10:45 - 11:00 WRS Customer Services - Francis St. Amant 11:00 - 11:45 POSIX Presentation - David Wilner 11:45 - 1:00 Lunch 1:00 - 3:15 Applications Presentation - Mike Trest, Visicom - Stan Schnieder, RTI - Steve Allen, Busware - Andrew Pearce, MBARI - Brett Goodrich, National Solar Observatory - Curt Kuhn, SPARTA - Todd Brackett, Interferometrics 3:15 - 3:30 Break 3:30 - 4:15 Birds of a Feather - C++, Scott Herzinger - BSP Porting Kit, Nigel Standing - POSIX/Kernel/5.1, David Wilner - Stethoscope, Todd Brackett 4:15 - 4:30 Futures Discussion, Closing Remarks At this point I want your input into the format and content. This is our meeting, so I anticipate change and growth over time. While I can't make specific promises at this point, I would like to tailor the meeting to your needs and the availability of Wind River personnel as much as possible. I look forward to your response! Steven - ------------------------------------------------------------------------- e-mail: sjk@strl.labs.tek.com | Steven King phone: 503-627-2736 | Software Technology Research Lab voice mail: 503-727-6651 | Tektronix, Inc. fax: 503-627-5502 | P.O. Box 500 MS 50-662 | Beaverton, OR 97077 - ------------------------------------------------------------------------- "Sometimes if you have a cappuccino and then try again it will work OK." (Dr. Brian Reid) "Sometimes one cappuccino isn't enough." (Marcus Ranum) "A double vanilla latte always works." (Me) --------------------------- Newsgroups: comp.os.vxworks Subject: Need the FAQ for comp.os.vxworks Date: 29 Jan 93 16:42:45 GMT From: krishna@csgrad.cs.vt.edu (Krishna Ganugapati) Organization: VPI&SU Computer Science Department, Blacksburg, VA Message-ID: <4092@creatures.cs.vt.edu> Sender: usenet@creatures.cs.vt.edu Greetings, Is there an FAQ for this newsgroup and could somebody tell me how I could get it ? Thanks very much Krishna Ganugapati (krishna@csgrad.cs.vt.edu) --------------------------- End of New-News digest ********************** From thor@thor.atd.ucar.edu Sun Jan 31 03:17:41 1993 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Sun Jan 31 03:17:53 PST 1993 Subject: Monthly VxWorks archive posting This is the monthly posting showing the current holdings in the VxWorks Software Archive. To get more detailed infomation send email to: vxworks_archive@ncar.ucar.edu The message body must read: send index send index from vx send index from unix ------------------------------------------------ VxWorks sources: total 2091 -rw-r--r-- 1 thor 22132 Jun 18 1990 ansi.p1 -rw-r--r-- 1 thor 22717 Jun 18 1990 ansi.p2 -rw-r--r-- 1 thor 24174 Jun 18 1990 ansi.p3 -rw-r--r-- 1 thor 8108 Jun 18 1990 ansi.patch1 -rw-r--r-- 1 thor 37126 Jun 12 1992 ansilib01 -rw-r--r-- 1 thor 18913 Jun 12 1992 ansilib02 -rw-r--r-- 1 thor 2671 Jan 2 1990 benchmarks -rw-r--r-- 1 thor 7168 Jul 13 1989 bitcnt -rw-r--r-- 1 thor 11437 Feb 15 1991 c++builtin.shar -rw-r--r-- 1 thor 22330 Apr 4 1990 c++headers.p1 -rw-r--r-- 1 thor 22775 Apr 4 1990 c++headers.p2 -rw-r--r-- 1 thor 29052 Dec 6 1989 camaclib1 -rw-r--r-- 1 thor 25095 Dec 6 1989 camaclib2 -rw-r--r-- 1 thor 31005 Dec 6 1989 camaclib3 -rw-r--r-- 1 thor 37770 Dec 21 1989 cbench.shar -rw-r--r-- 1 thor 7371 Jun 15 1990 cntsem_class.shar -rw-r--r-- 1 thor 5853 May 31 1989 crc.shar -rw-r--r-- 1 thor 8917 Oct 9 1990 deadman.shar -rw-r--r-- 1 thor 41669 Dec 6 1991 dhrystones01 -rw-r--r-- 1 thor 25681 Aug 29 1989 dt1451 -rw-r--r-- 1 thor 5944 Apr 26 1989 fcompress.shar -rw-r--r-- 1 thor 11561 Nov 1 1991 flags_class.shar -rw-r--r-- 1 thor 44762 Jul 18 1990 force.p1 -rw-r--r-- 1 thor 40154 Jul 18 1990 force.p2 -rw-r--r-- 1 thor 80491 May 8 1989 force.shar -rw-r--r-- 1 thor 6106 Oct 10 1989 getdate -rw-r--r-- 1 thor 9774 Nov 2 1990 hkv30extintutil.shar -rw-r--r-- 1 thor 10049 Dec 2 08:45 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 35245 Oct 9 1990 joblib2.p1 -rw-r--r-- 1 thor 18110 Oct 9 1990 joblib2.p2 -rw-r--r-- 1 thor 9079 Apr 2 1990 lclflag.shar drwxr-xr-x 2 thor 512 Oct 31 1990 libX11 lrwxrwxrwx 1 root 6 Aug 14 1991 libx11 -> libX11 -rw-r--r-- 1 thor 25077 Oct 9 1990 loadmeter.shar -rw-r--r-- 1 thor 10399 May 4 1989 math.shar -rw-r--r-- 1 thor 11950 May 30 1989 math2 -rw-r--r-- 1 ftp 26655 Nov 15 1990 monitor.shar -rw-r--r-- 1 thor 18733 Jun 14 1990 msgque_class.shar -rw-r--r-- 1 thor 41667 Feb 5 1992 ntpvx01 -rw-r--r-- 1 thor 38524 Feb 5 1992 ntpvx02 -rw-r--r-- 1 thor 41997 Feb 5 1992 ntpvx03 -rw-r--r-- 1 thor 39218 Feb 5 1992 ntpvx04 -rw-r--r-- 1 thor 39625 Feb 5 1992 ntpvx05 -rw-r--r-- 1 thor 28741 Feb 5 1992 ntpvx06 -rw-r--r-- 1 thor 32516 Feb 5 1992 ntpvx07 -rw-r--r-- 1 thor 37119 Feb 5 1992 ntpvx08 -rw-r--r-- 1 thor 41643 Feb 5 1992 ntpvx09 -rw-r--r-- 1 thor 19593 Oct 27 07:47 ping01 -rw-r--r-- 1 thor 20494 Oct 31 1991 pipe.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 1991 poollib -> poolLib -rw-r--r-- 1 thor 13204 Oct 31 1991 ring.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 1991 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 41196 Oct 16 09:43 stevie01 -rw-r--r-- 1 thor 35279 Oct 16 09:43 stevie02 -rw-r--r-- 1 thor 35278 Oct 16 09:43 stevie03 -rw-r--r-- 1 thor 35012 Oct 16 09:43 stevie04 -rw-r--r-- 1 thor 34502 Oct 16 09:43 stevie05 -rw-r--r-- 1 thor 37476 Oct 16 09:43 stevie06 -rw-r--r-- 1 thor 30073 Oct 16 09:43 stevie07 -rw-r--r-- 1 thor 31562 Oct 16 09:43 stevie08 -rw-r--r-- 1 thor 37360 Oct 16 09:43 stevie09 -rw-r--r-- 1 thor 20662 Oct 16 09:43 stevie10 -rw-r--r-- 1 thor 25717 Oct 16 09:43 stevie11 -rw-r--r-- 1 thor 28075 Oct 16 09:43 stevie12 -rw-r--r-- 1 thor 31852 Oct 16 09:43 stevie13 -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 8424 Apr 1 1992 syslog.shar -rw-r--r-- 1 thor 15096 Oct 2 1991 task_class.shar -rw-r--r-- 1 thor 16171 Oct 9 1990 taskmon.shar -rw-r--r-- 1 thor 10523 May 31 1989 tod.shar -rw-r--r-- 1 thor 19912 Aug 27 13:52 tp41.shar -rw-r--r-- 1 thor 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 5608 Dec 2 08:43 veclist01 -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 43671 Nov 22 1991 vwcurses01 -rw-r--r-- 1 thor 40180 Nov 22 1991 vwcurses02 -rw-r--r-- 1 thor 38308 Nov 22 1991 vwcurses03 -rw-r--r-- 1 thor 31181 Nov 22 1991 vwcurses04 -rw-r--r-- 1 thor 31798 Nov 22 1991 vwcurses05 -rw-r--r-- 1 thor 31459 Nov 22 1991 vwcurses06 -rw-r--r-- 1 thor 24279 Nov 22 1991 vwcurses07 -rw-r--r-- 1 thor 4636 Feb 4 1992 vx_cplusplus -rw-r--r-- 1 thor 29720 Aug 28 1991 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 1991 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 1991 vxrsh.p3 -rw-r--r-- 1 thor 4702 Jan 16 1992 wdog_class -rw-r--r-- 1 thor 5070 Dec 2 08:45 xxx Unix sources: total 82 -rw-r--r-- 1 thor 1192 Mar 13 1990 index drwxr-xr-x 2 thor 512 Mar 17 1992 patch -r--r--r-- 1 thor 11744 Apr 11 1989 shar.shar -rw-r--r-- 1 thor 19698 Nov 15 1989 vxtool -rw-r--r-- 1 thor 21934 Jan 31 1990 vxview -rw-r--r-- 1 thor 14151 Feb 9 1990 vxview.patch -r--r--r-- 1 thor 9869 Feb 1 1989 xc.shar drwxr-xr-x 2 thor 512 Feb 11 1990 xdbx From mitchell@aaec1.aaec.com Sun Jan 31 11:23:10 1993 From: mitchell@aaec1.aaec.com Date: Sun Jan 31 11:23:19 PST 1993 Subject: Re: Backplane Net to SPARC/UNIX Several weeks ago I posted a question about using the backplane driver to link a vxWorks VME board to a SPARC via a s-bus to VME adapter made by BIT-3. Here's a good summary posted by Alan Biocca, followed by what else I found. >From: biocca@csg.lbl.gov (Alan K Biocca) >Backplane drivers for workstations have been an ongoing problem. I have >observed folks who have had significant difficulty with them. > >The backplane driver is being supplanted by the shared memory driver, and >will likely eventually be phased out. Each new release of workstation OS >is likely to disrupt the backplane driver. > >I'd recommend choosing an architecture that didn't require the backplane net >on a workstation - WRS has had difficulty supporting that interface in a >timely manner. Use the network to boot from, and then share the data over >the backplane bus with your own shared memory code. Thus you will not have to >deal with backplane net problems on the sun, and you can keep the application >specific problems within your own control. > >Alan K Biocca > WRS says its Unix driver has only been tested with CPU's with integral VME interfaces (assume its a sparc-engine-1e or -2e). They said it could be possible to license the source code and port it to an s-bus to VME adapter, but noted that it seemed like a great undertaking. A few years ago we tried to get a sun-3e (now discontinued 6U '020 CPU) to use bp net, but I don't think it ever worked (those who tried it are long gone). BIT3 says they have heard of someone using their VME-VME link with the UNIX VME boards, but not s-bus to VME. Our problem will be solved by using ethernet. We thought this would be a problem since another part of the system was using ray ethernet packets for command and control. We originally did not want these to get onto a the "regular" ethernet, but now we think it will be OK. One of the other contractors involved with this project is trying to track down a safe ether-packet type. Both the UNIX and vxWorks ignore unkown packet types quite well. Out backup to this solution is to boot from EEPROM and use SLIP for networking. The vxWorks and UNIX applications will talk over the BIT-3 via our own ring buffer routines, along what Alan suggested.