From smb@afterlife.ncsc.mil Fri Jan 3 23:31:34 1992 From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Date: Fri Jan 3 23:31:41 PST 1992 Subject: multiple initiators with scsiLib(1)? The man page for scsiLib (1) states (version 5.0.2): It implements only the SCSI initiator function, i.e., the concept of a VxWorks target acting as a SCSI target is not currently supported. Furthermore, in the current implementation, a VxWorks target is assumed to be the only initiator on the SCSI bus, although there may be multiple targets (SCSI peripherals) on the bus. I need multiple initiators on a single SCSI bus to allow using a disk as a rather large FIFO written by one processor and read by another. Can anyone (WRS) tell me if there are any plans to extent scsiLib's functionality to allow for multiple initiators? How about VxWorks targets as SCSI targets? Thanks, Steve Burinsky smb@afterlife.ncsc.mil From visicom!VisiCom.COM!trest@nosc.mil Sat Jan 4 08:52:35 1992 From: trest@visicom.com (Mike Trest) Date: Sat Jan 4 08:52:43 PST 1992 Subject: Re: multiple initiators with scsiLib(1)? Steve: >>Can anyone (WRS) tell me if there are any plans to extent scsiLib's >>functionality to allow for multiple initiators? While I do not presume to speak for WRS or Jason, I have used the existing WRS scsiLib since before it was a public product. I have sucessfully used it to perform for several controllers on the same physical SCSI against a common pool of disks. One of VisiCom's customers us using it with a MVME326 controller (a Mil variation of the Interphase Jaguar) with 5 controllers talking to two disks. This works because (1) scsiLib is re-entrant enough and (2) the SCSI bus itself allows this capability. HOWEVER, you have to observe some reasonable rules: A. A Single Controller should be the only one UPDATING a specific area of the disk as delimited in your scsiDevCreate(). This does not preclude multiple processes from updating files on this controller. It does, however, preclude a process on a different controller updating the same disk area. In other words, use disk partitioning as well as controller separation. B. DO NOT EXPECT THAT MULTIPLE INITIATORS KNOW ABOUT EACH OTHER UNLESS YOU TELL THEM. I have one application where multiple VME cages are used against a single disk & tape pool in a mixed RAW and MSDOS modes. A small server is used to distribute a global index to the other VME cages and to request global mutual exclusion. This is a distributed locks methodology without all the overhead of NFS and truly distributed locks. C. DO NOT EXPECT scsiLib or SCSI bus to do things which are not supported by the target device. For example, I have seen attempts to use multiple initiator controllers to issue a second request to the same disk spindle. The programmer wondered why the second request from the other initiator was denied. Well, the disk's target firmware was single request only. All subsequent requests are rejected by the device until the in-process command is completed. Prior to SCSI-2, multiple request devices are expensive DISK SUBSYSTEMS, RAIDs, or SCSI SERVER products with very intelligent controllers. ALAS, SCIS-2 and TAG QUEUE operating devices will extend this to more devices in the near future. devices are not far away. VisiCom is working on an OEM scsi controller driver for VxWorks which is SCSI-2 and supports full TAG QUEUE operation and multiple request driven. The multiple commands are fed immediately to the controller which is responsible for controlling all requests from all processes. Multiple controllers are supported on the same SCSI bus. The above rules and comments still apply. >> How about VxWorks targets as SCSI targets? I am already doing this to. However, it depends on the firmware and SCSI chip used on the controller itself. I do not know of any plans to put this kind of stuff in scsiLib. It is obviously software that we need and use when VxWorks is embedded into products. Perhaps VisiCom will consider a "ADVANCED SCSI CAPABILITIES" library for the general VX market like the X server and Motif product. >>I need multiple initiators on a single SCSI bus to allow using a disk as >>a rather large FIFO written by one processor and read by another. The answer to your problem is twofold. First is appropriate data structuring on the SCSI disk. Second is adequate communication between the producer task and the consumer task. I will assume that you also want this FIFO to sustain the highest possible speed. I will also assume that you are willing to control the inherent latency involved because you cannot write to the disk by the producer while a read is in process by the consumer. And, that you are using a dumb controller which cannot queue requests for either producer or consumer. Therefore, let your producer task use RAW disk organization with a single link list data structure imbedded in you data. Include in that data structure a unique block/serial number. Let your consumer task read the link list data. Share the current producer and consmer block numbers between the two processors via shared memory (or communications). Treat all of the disk as if it were a large ring buffer with a traditional HEAD/TAIL algorithm. Depending on your data rates, and the relative processing overhead of the the consumer task, you seek activity should be minimal since the TAIL should be following the HEAD quite closely. Even if the two processors only loosly coupled and network communications must be used, the exchange of HEAD and TAIL pointers can be done if the SCSI driver is well written and does not spin-loop internally while the disk transfer is in process. UNFORTUNATELY not all drivers are well written and do not lend themselves to overlapped operation. For example using a relatively dumb SCSI chip and then not using DMA happen more times than you want to know about. Driver for stand-alone VME SCSI controllers are generally tuned to take advantage of the co-processor overlap and yeild much higher performance. If, however, your producer and consumer processes are on different processor boards with their own private SCSI chip, they should still be up to the job. Sorry about taking so much of the net traffic time, but I thought you needed to hear some of these things. I hope that I have given you some hope rather than despair. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== From hmp@frc2.frc.ri.cmu.edu Sat Jan 4 13:34:16 1992 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Sat Jan 4 13:34:25 PST 1992 Subject: RESULT: comp.os.vxworks passes 295:17 The voting period for comp.os.vxworks is now officially over, resulting in 295 votes in favor vs. 17 votes opposed to creation of comp.os.vxworks. Since these results meet the criteria for group creation, and barring any serious objections or errors in the vote-taking on my part, comp.os.vxworks should be created after the customary 5 day waiting period (beginning with the appearance of this message in news.announce.newgroups). Thanks to everyone who voted. -Henning Pangels ############################################################################## Votes OPPOSED to creation of comp.os.vxworks were received from: Purnam (P.A.)Sheth Walt Froloff Harald Nordgard-Hansen Richard Kulawiec Memphis_TN "Richard H. Miller" Paul Eggert Quincey Koziol Jeff Beadles "Prashant V. Waknis" Steve Rogers John G Dobnick "Gregory G. Woodbury" Tom Fitzgerald Hans Olov Eriksson "Kenton A. Hoover" "Leonard J. Reder" ############################################################################## Votes IN FAVOR of creation of comp.os.vxworks were received from: James Woodyatt Alan K Biocca Andrew (A.J.)McGregor heyes@dadev.cebaf.gov Andy Kozubal Jeff Hill Jim Nusbaum George Osmolski Pam Otsuka (Pam Woods) Tracy Erkkila "Terry A. Jones" Ken Seymour Gerry Roston Steven king (503)627-2736 DS 50-662 "Paul R. Bade" Bill Randle Jim Newman Phil Kester Bob Lawhead Todd Brackett glb@s1.gov Marc Ullman Bret Goodrich Chris Nickles Dan Merget projoe@zip.eecs.umich.edu rmk@iss-ipc3.ssd.ray.com Marcus Gates "George M. Howard" Kevin Damour Mike Trest Bob Kibrick Richard Neitzel steveu@tv.tv.tek.com Olivier Bernard Stan Schneider fjr@iss-ipc1.ssd.ray.com "J. Russell Noseworthy" Brian Quigley Gordon Miller "Lance A. Page" Kim Gillies X246 Dave Gawley Chris Maio Rob -Not from Bloom County- Binkley June Liesch Cynthia Ward - CRL Support Line ------------ Peter Chu crispen <@ada3.ca.boeing.com:crispen@amber.boeing.com> "Dave St.Clair" Don Berlin pierre@Helios.McRCIM.McGill.EDU David Lim Cory Fasbender chrise@hpsrcje.sr.hp.com Jim Horstkotte Jim Jones Lou Salz moritz@hpsrjam.sr.hp.com pardo@sun-valley.stanford.edu Dennis Morse houchin@wind.wv.tek.com Tom Wilson MICHAEL RICHARDS Mark Baranowski Jon Hull Cheryl Troester Hwa-Jin Bae abekas!mikep Dave Norris "Steve M. Burinsky" 6585 Sandra Harimoto skoft@itk.unit.no ojr@itk.unit.no Eric Knox Steve Harpster John Baldwin Georg Feil Kevin Rumbaugh bob geer Ross McAree "Trygg A. Eliassen" Paul Palumbo Steve Lewis Edwin Wilder Lonnie Cole Darrell Call Bill Brown maf@verdix.com Clark Briggs Robert Belshe Loren Shalz Dan Warburton D'Anne Thompson Steve Morris vanandel@rsf.atd.ucar.EDU Steven S Smith Fei-Yue Wang Rick Voreck Jim Beyer jose@ncar.ucar.edu Rob Marchand Don Wells Paul Gittings rcm@iss-ipc2.ssd.ray.com aspect!mike@uunet.uu.net aspect!kevinc@uunet.uu.net bean@pslnm.NMSU.Edu Bill Cruise rjk@mlb.dmt.csiro.au James Moore Graulle Christophe "Girard R. Ramsay" jvdwerf@mmra1.ms.philips.nl sb@itk.unit.no Mike Anderson Geoff Espin Glenn Tarbox deena-strauss@orl.mmc.com digiac Ebbe Petersen Dragisha Miladinovic Pierre Mathieu Gary Trimble Chris Frank Ed Vielmetti David Berg murphy (Bill Murphy) Gabor Karsai John Cromer Louis Gray Al Maillet Hugh Fader AnnMichele Lobello "Jonathan M. Cameron" Jerry Fiddler tran@sun-valley.stanford.edu Bob Marino Bruce Nelson Russell Sheehan Thomas Ljubi Vic Potter Marty Marra Todd Litwin Roger Gonzalez Richard Saunders Susanna Jacobson Scott Huddleston billh@assip.csasyd.oz.AU Al Conrad kevin d bonifield "William Lupton: WLupton@Keck.Hawaii.Edu" Bob Cohen Alan Stanier favre eric Matthieu Herrb Mike Heley Tom Wetherbee Gary Haas (IBD) Edward Hinton Chris Beasley tmelen@itk.unit.no Carl Lionberger Dean Tucker Wayne D Michael NOELL T E "J. Porter Clark" roos@imasun.lbl.gov (Mark S. Roos) Emmanuel Fleishman "Taso N. Devetzis" Mitch Hendrickson "hlewis@keck.hawaii.edu" "Thomas J. Trebisky" Jeff Fitzgerald barry n nelson Brian Carlton christ@mordor.wr.tek.com "Kenneth Holmstr\\Nm" <@mail.swip.net:hkh@abbaut> Mark Linimon MHAMILTON@cooper.bbn.com "Larry E. Peruski" Bob Herlien ramap@wow.tv.tek.com (Rama Pailoor) Andrew Pearce rgonzale@ccc.CX.NRAO.EDU (Ray Gonzalez) Patrick Boylan mike-i green pfeffer@sun-valley.stanford.edu Rahul Shah Dick Smith djc@oxygen.aps1.anl.gov (Daniel J. Ciarlette) dbocek@doc.jhuapl.edu (Dawn B. Schepleng) aspect!richard@uunet.UU.NET ronb@duke.labs.tek.com Scott Herzinger simon@wrs.com (Simon Leong) Mike Oliver crs@gmrt.ernet.in (CR Subrahmanya) "John Archbold (dubdoob" Stuart Stirling Peter Corke bobf@verdix.com Ted Rypma miked@wrs.com (Mike Deliman) mrk@phebos.aps.anl.gov (Marty Kraimer) frl@phebos.aps.anl.gov (Frank Lenkszus) wpm@phebos.aps.anl.gov (Bill McDowell) Charlie Singer George Plourde Rick Rousseau Neil Demario Norbert Hofmann Doug Balek Patrice Kadionik Dominique Leveque chochon@aar.alcatel-alsthom.fr ( Helene Chochon ) Mike Swears Peter Trenning Al Pariante Charles Harrington winans@phebos.aps.anl.gov (John R. Winans) John Curry Monica Skidmore Kenneth Holmstr\Nm <@mail.swip.net:hkh@abbaut> usenet user <@mail.swip.net:usenet@abbaut> Christer Hansson <@mail.swip.net:cha@abbaut> Mats Molander <@mail.swip.net:mm@abbaut> gunther@luke.ATdiv.Lanl.GOV (Betty Gunther) mcevoy@srv1.bcs.lbl.gov (Maurice McEvoy) gdfwc3!kuwait!tod@texsun.Central.Sun.COM (Tod Chapman) Kim DeVaughn Eric Stromberg scr@UK.ATE.SLB.COM Neil McKay vxwexplo@lbl.gov (the vxWorks Users Group Exploder) andy@sealink1.oe.fau.edu (Mr.Andrew_Shein) David Bruce Michael Bordua Tom Pendleton - Sun South Bay Region SE Hesham (H.)El Bakoury Minoru Nakamura "David N. Wilner" Leonid Rosenboim vxWorks@digitailor.se Po Shan Cheah Randall Atkinson Kragh Hertel "Craig A. Franklin" Steven Smith Jayne Johnson "Harold N. Rosenstock" Maarten (M.A.)Koning Jose Alvistur William Dere Randy Motyka "VADSWorks/VxWorks 2.0.1c-5.0.1" Elias Pavlakos Hali Lindbloom bebek@Csa2.LBL.Gov Jo Schambach ntmtv!daemon@ames.arc.nasa.gov Bud Hensley David Blackman "Alex L. Bangs" klaus@sol.ced.utah.edu Rick Sustek djanssen@mmra1.ms.philips.nl hunt@s6550b.nrl.navy.mil Nigel Standing Kent Long Jeffrey Lee Lee S Wilfinger George den Boer Sypko Andreae Rhonda Gaines Travis Craig VxWorks Realtime System Chuck Broadwell Shobha Erramilli "Brian G. Harper" Ray Lampman KYWONG@SJEVM5.VNET.IBM.COM Chuck Cox kddlab!advanced-software.co.jp!yoriyuki@uunet.UU.NET Mike Ryan Webster Dove Steven Lynch Carl Symborski Ken Saruwatari Sigeo Hasegawa (ONTAKE) "Ben T. Eguchi" Tim Page Joe Orichella ############################################################################## Henning Pangels |hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer|(412) 268-7088 |Carnegie-Mellon University ------------------------------------------------------------------------------ It's later than you think From whorner@vlsi9.gsfc.nasa.gov Mon Jan 6 10:27:54 1992 From: whorner@vlsi9.gsfc.nasa.gov (Ward Horner) Date: Mon Jan 6 10:28:02 PST 1992 Subject: subscription request Please place me on the Exploder mailing list. My address is: whorner@vlsi9.gsfc.nasa.gov My name is: Ward Horner, NASA/GSFC, Code 521.1, Greenbelt, MD 20771 My phone is: (301) 286-5804 Thank you From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Mon Jan 6 21:20:01 1992 From: fjr@iss-ipc1.ssd.ray.com Date: Mon Jan 6 21:20:12 PST 1992 Subject: Re: multiple initiators with scsiLib(1)? Mike Trest writes: > This works because (1) scsiLib is re-entrant enough and (2) > the SCSI bus itself allows this capability. HOWEVER, you have > to observe some reasonable rules: > > A. A Single Controller should be the only one UPDATING > a specific area of the disk as delimited in your > scsiDevCreate(). This does not preclude multiple > processes from updating files on this controller. > It does, however, preclude a process on a different > controller updating the same disk area. In other > words, use disk partitioning as well as controller > separation. > C. DO NOT EXPECT scsiLib or SCSI bus to do things which > are not supported by the target device. For example, > I have seen attempts to use multiple initiator controllers > to issue a second request to the same disk spindle. > The programmer wondered why the second request from > the other initiator was denied. Well, the disk's > target firmware was single request only. All subsequent > requests are rejected by the device until the in-process > command is completed. Prior to SCSI-2, multiple request > devices are expensive DISK SUBSYSTEMS, RAIDs, or SCSI SERVER We are looking to also use multiple hosts on the same SCSI bus. We want to have one processor on one bus reading and writing a SCSI disk while another processor on another bus just reads the same disk. We thought that by using the Auto Sync option of the disk driver that gets the MSDOS FAT table output after every transaction that things would work. We have not, however, taken any precautions for scheduling usage of the disk. Mike, do I understand that you implement some queueing on the host side of the SCSI interfaces to order the attempts to communicate with a shared disk? If you just let multiple controller cards attempt to work with the same disk might the controllers handle the contention? > Sorry about taking so much of the net traffic time, but I thought > you needed to hear some of these things. I hope that I have > given you some hope rather than despair. It was useful seeing the discussion. Thanks. Fred ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From visicom!VisiCom.COM!trest@nosc.mil Tue Jan 7 09:37:24 1992 From: Mike Trest Date: Tue Jan 7 09:37:31 PST 1992 Subject: Re: multiple initiators with scsiLib(1)? Fred: >>... by using the Auto Sync option of the disk driver that gets the MSDOS >>FAT table output after every transaction that things would work. We have >>not, however, taken any precautions for scheduling usage of the disk. This approach assumes that the FAT writing operation is atomic. This cannot be guaranteed. However, FATs are only part of the problem. What about directory entries? What of reading a file on processor B until what appears to be EOF while processor A is in the act of extending the file with new data? >>do I understand that you implement some queueing on the host side of the >>SCSI interfaces to order the attempts to communicate with a shared disk? Yes, for controllers which have multiple queues, a queue per spindle, or significant linked command capabilities. However, the queue is not "... to order ..." but to maximize I/O and processing overlap. >>If you just let multiple controller cards attempt to work with the same >>disk might the controllers handle the contention? The controllers and SCSI selection/arbitration do indeed handle the physical contention. My original suggestion regarding the FIFO application was to provide a coherent handler for a single producer on one processor and a single consumer on another processor which minimized software overhead and maximized throughput. I appreciate the use of the exploder as an open forum of discussion. We need occasional review and outside suggestions. Otherwise we shall suffer the malady of aging programmers: "Hardening of the categories" ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== From mea@sparta.com Tue Jan 7 10:58:59 1992 From: mea@sparta.com (Mike Anderson) Date: Tue Jan 7 10:59:06 PST 1992 Subject: MSDOS file systems > 32MB? Greetings! Has anyone heard of or developed a way to support MSDOS filesystems under VxWorks > 32MB in size? I have a 1GB Wren VII that I would like to support under the MSDOS filesystem and it appears that for now, I have to set up a 32MB MSDOS partition and then access the rest in Raw mode or as a handfull of other 32MB partitions (yuk!). Any pointers would be appreciated. BTW, I have looked at the RT11 and it doesn't fit my requirements either. Thanks, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM 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, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From kent@wrs.com Tue Jan 7 15:16:49 1992 From: kent@wrs.com (Kent Long) Date: Tue Jan 7 15:17:07 PST 1992 Subject: dosFs: big disks & config tips Hi, Folks - Mike Anderson (mea@sparta.com) writes: > > Has anyone heard of or developed a way to support MSDOS filesystems > under VxWorks > 32MB in size? I have a 1GB Wren VII that I would like to > support under the MSDOS filesystem and it appears that for now, I have to > set up a 32MB MSDOS partition and then access the rest in Raw mode or > as a handfull of other 32MB partitions (yuk!). Fortunately, this is not the case! There is no special work which must be done to use large disks with the standard VxWorks dosFs file system. The dosFs library supports the disk format changes introduced in MS-DOS 4.0 which include a 32-bit sector count. (Earlier versions of DOS only had a 16-bit sector count, giving the infamous 32M limit, assuming 512-byte sectors.) So, it can handle up to 4 billion sectors, which is pretty darned big. What may be confusing things is that there is an independent limit, based on the size of FAT table entries. Since each FAT entry is only 16 bits, there can only be 64K clusters defined on a disk. (A cluster is the unit of allocation on a DOS disk, consisting of one or more sectors; each FAT entry describes one cluster.) So, what happens with a large disk such as Mike describes is that the sectors per cluster goes up. This means that there is less granularity when allocating portions of the disk, but it does not impose an overall size limit. By the way, the dosFsMkfs() call will initialize a disk using default values, including calculating the appropriate number of sectors per cluster. The values which are generated can then be used as a starting point for more application-specific config values. There should be no problem using dosFsMkfs() on a large disk. There are two calls in dosFsLib which were not originally documented (but will be made official in a future release) which may be helpful. These are "dosFsConfigShow()" and "dosFsConfigGet()". These calls provide configuration data about an intiialized dosFs disk. The dosFsConfigShow() routine will display the config info on standard output. It's single input parameter is the name of the device, e.g.: status = dosFsConfigShow ("DISK1:"); The dosFsConfigGet() routine is similar, but returns the configuration data in a manner suitable for use in a C program. It takes two parameters, a pointer to the volume descriptor (DOS_VOL_DESC) of the disk, and a pointer to a DOS_VOL_CONFIG structure to be filled with the current config data: DOS_VOL_DESC *pVolDesc; DOS_VOL_CONFIG *pConfig; status = dosFsConfigGet (pVolDesc, pConfig); The DOS_VOL_CONFIG structure pointed to by pConfig must have already been allocated! It is only filled in by dosFsConfigGet(). Anyway, how all this relates back to the issue of initializing a big disk (or any dosFs disk, for that matter) is that you can first get the volume initialized using dosFsMkfs() with the default values it calculates. Then, use either dosFsConfigShow() or dosFsConfigGet() to find out what values were actually used. These configuration values can then be used as a basis for more application-specific values, which should be provided using the regular dosFsDevInit() method of initialization. > BTW, I have looked at the RT11 and it doesn't fit my > requirements either. That's right. The RT-11 format again imposes a 16-bit sector count, thereby limiting disks to 32Meg. Given the other RT-11 restrictions (inability to append to a file, even more restrictive file names, etc.), there is no situation in which I can really recommend using rt11Fs over dosFs. I hope this sheds some light on all of this.... - kent Kent Long Wind River Systems kent@wrs.com From rayssd!iss-ipc1.ssd.ray.com!fjr@uunet.uu.net Wed Jan 8 22:24:07 1992 From: fjr@iss-ipc1.ssd.ray.com Date: Wed Jan 8 22:24:15 PST 1992 Subject: Re: dosFs: big disks & config tips Kent Long (kent@wrs.com) writes: > What may be confusing things is that there is an independent limit, based > on the size of FAT table entries. Since each FAT entry is only 16 bits, > there can only be 64K clusters defined on a disk. (A cluster is the unit > of allocation on a DOS disk, consisting of one or more sectors; each FAT > entry describes one cluster.) > > So, what happens with a large disk such as Mike describes is that > the sectors per cluster goes up. This means that there is less > granularity when allocating portions of the disk, but it does not > impose an overall size limit. While large disks can be handled under MSDOS, the granularity issue seems quite important. My understanding is that a cluster is the smallest unit that can be accessed on an MSDOS disk. With large cluster sizes, disk fragmentation goes up and effective disk usage goes down. Typically, the amount of wasted space in a disk partition will be: total files * .5 * cluster size This isn't necessarily a problem, it just has to be considered. If you are going to have lots of little files you probably don't want to put them into a partition that is set up with a large cluster size; use large partitions for large files and little partitions for little files. The question I have is whether clusters are always read and written using a single disk request? I would want the driver to do a single disk operation to access all the sectors in the cluster. Also, do drivers optimize beyond that? Do they read/write multiple contiguous clusters when possible? This would improve disk IO rates if it was supported. Thanks for any information. ______________________________________________________________ | Fred J Roeber, Raytheon Submarine Signal Division | | 1847 West Main Road, Mail Stop 188 | | Portsmouth, RI 02871-1087 (401) 847-8000 (X4205) | | | | {uiucdcs,uunet}!rayssd!sgfb.ssd.ray.com!fjr | |______________________________________________________________| From visicom!VisiCom.COM!trest@nosc.mil Thu Jan 9 09:22:55 1992 From: Mike Trest Date: Thu Jan 9 09:23:02 PST 1992 Subject: Re: dosFs: big disks & config tips Fred: >> The question I have is whether clusters are always read and written >>using a single disk request? I would want the driver to do a single >>disk operation to access all the sectors in the cluster. Also, do drivers >>optimize beyond that? Do they read/write multiple contiguous clusters >>when possible? Based on my observation of MSDOS to the driver, I cannot confirm that clusters do not ALWAYS read/write as a whole. Perhaps WRS will comment definitively. However, my observation in a >100MB MSDOS partition booting VxWorks, the FS requests enough SCSI blocks to equal the cluster size (ALMOST ALWAYS). The scsiLib() itself imposes no real limit on the number of blocks to read/write. The drivers will usually pass the number of blocks right on to the controller. HOWEVER not all controllers and targets support multiblock operation. These FS/scsiLib() requests and must be broken into individual read/writes to the limit of the controller/target. Sometimes, the culprit is a DMA controller which can move only 64K bytes at a time or which cannot cross some magical 1MB or 16MB memory address boundary. Driver optimize? What a good idea! Unfortunately, the requests to the driver by the FS are serialized as they pass thru the present scsiLib(). Since Disonnect/Reconnect is not supported in scsiLib() and each SCSI TRANSACTION is expected to be atomic by scsiLib(), the driver writer has no other choice when using the convience of scsiLib(). In defense of scsiLib() and Jason, its overhead and the restrictions imposed are trivial in most real world cases. Multiple simultaneous request from many processes PASSING THRU THE SAME scsiLib() on a single processor are properly protected for multi-thread operation. One technique which I advise in a multi-processor and single SCSI controller environment, is to have one processor do all the Read/Write DISK processing but to point the buffers to address spaces on the requesting processor card. This may sound a little slow but the IPC overhead between the processors is orders of magnitude less than the drive seek time and your requesting application must compensate for this anyway. If your SCSI controller is up to the performance you demand of it and your target devices are capable of delivering the goods, then you will see VERY GOOD PERFORMANCE with scsiLib() and the DOS file system if you use contiguous allocation when a file is created. Without resorting to crass salesmanship, I strongly suggest that when your application truly needs operation with multiple requesting initiators you really need a powerful stand-alone SCSI controller rather than the "on the board" SCSI chip. Even then you have to observe reasonable design rules. In the really high performance requirements (i.e. > 10MB/sec average in bursts) with multi-MB data transfers, you really need to balance the total application design and task priorities carefully. If you do, your performance will be outstanding! ..mike.. From interf!atlas!argus!brackett@uunet.uu.net Fri Jan 10 05:10:41 1992 From: interf!atlas!argus!brackett@uunet.uu.net (Todd Brackett) Date: Fri Jan 10 05:10:52 PST 1992 Subject: Windays and User Groups Hi! I just heard from Stan Schneider at RTI that WinDays has been scrubbed due to lack of interest (or maybe response). How many people could scare up the conference "fee" as well as getting the boss to get you travel and time? I was wondering if the "National" user group meeting has been scrubbed as well? For everybody's reference I was anointed (by default) to organize the east coast meeting sometime in the fall. As of right now there is no scheduled time or place. If you have comments, ideas & suggestions please feel free to get them to me. Regards, ------------------------------------------------------- |Todd S. Brackett |Voice:703 790 8500 | |Interferometrics, Inc. |FAX: 703 848 2492 | |8150 Leesburg Pike | | |Vienna, VA 22182 | | |-----------------------------------------------------| |U. S. Naval Observatory |Voice:202 653 0945 | |34th and Massachusetts Ave. NW |FAX: 202 653 0941 | |Building 52 | | |Washington, DC 20392-5100 | | |-----------------------------------------------------| |Internet:brackett@interf.com | |Uunet: uunet!interf!brackett | ------------------------------------------------------- From jjohnson@hns.com Fri Jan 10 05:54:02 1992 From: jjohnson@hns.com (Jayne Johnson) Date: Fri Jan 10 05:54:09 PST 1992 Subject: Re: Windays and User Groups In reference to ideas about the East Coast Users Group Meeting I would like to say that I find that paying for such a conference was a bad idea since we the Users are organizing the event. If we want why don't we organize the meeting to occur in a place that isn't too expensive and hard to get to. Is this year going to be in Boston? If so is anyone attending a college around the Boston area where we could use the campus resources? As far as subjects go I would like to hear alot about C++ and POSIX . Let's have a seminar to teach the fundamentals of C++. Let's have a seminar about the POSIX standards VxWorks is compliant and what it means. Has anyone mentioned the possibility of Users Group dues to pay for the conferences? Well, that's my two cents for now.... From heyes@dadev.cebaf.gov Fri Jan 10 06:52:21 1992 From: heyes@dadev.cebaf.gov Date: Fri Jan 10 06:52:31 PST 1992 Subject: Re: Windays and User Groups can someone in the know verify if Windays has indeed been canceled due to lack of interest?? I am just looking at the invitation which has no deadline for subscription printed on it. I am sure there are many people like myself who could not "rush" a subscription off before the holidays, because their companys travel department does not work that far in advance, but would have done something if there had been a deadline. We all know some psychology is needed, especially in goverment labs, so get the beurocracy moving. Graham Heyes CEBAF From wesw@fog.wv.tek.com Fri Jan 10 09:05:45 1992 From: wesw@fog.wv.tek.com Date: Fri Jan 10 09:05:51 PST 1992 Subject: Streams for VxWorks Available? Some software we are evaluating is written for a System V implementation of streams. Is there a streams interface available for VxWorks (third- party or otherwise)? Wes Whitnah From jim@cave.arc.nasa.gov Fri Jan 10 22:09:14 1992 From: Jim Pantaleo x45347 Date: Fri Jan 10 22:09:22 PST 1992 Subject: serial problems with 5.0.2 on 1E We've run into a problem in our recent installation of 5.0.2b (released version). Long rapid output (like a memory dump) over the serial port to a terminal or host suffers from missing, altered, and/or extra characters. We've tried both our ROM sets on both of our 1E's and the result is exactly the same. A monitor dump like "d 300000,1000" with no user code loaded will demonstrate the problem. We've tried all combinations of parity, data bits, stop bits, and soft and hard flow control without any improvement. The original Sun ROMs and the VxWorks 4.0.2 ROMs work just fine under the same test conditions. It almost looks like something in an interrupt service routine is screwed up. WRS tech support has been unable to reproduce the problem. The only difference in our systems seems to be that WRS uses the Force 1E wit2 MB Roms, while we use older Sun 1Es with 1 MB ROMs. We just got a new 1E from Sun with 2MB ROMs, but we can't get that one to boot VxWorks (using a 5.0.2 2MB ROM) at all. Any ideas would be greatly appreciated! Thanks in advance - Jim Pantaleo Sterling Software jim@cave.arc.nasa.gov From visicom!VisiCom.COM!trest@nosc.mil Sat Jan 11 11:31:38 1992 From: Mike Trest Date: Sat Jan 11 11:31:46 PST 1992 Subject: VX-SERVER PERFORMANCE MEAUREMENT? Someone asked me how the VX-SERVER compares to X running on the SUN? I decided to try a small comparison test to let him decide. I know what I did is not a definitive benchmark. I chose to set a decicated VxWorks display along side a SUN display and let him judge by visual performance. The VX-Server was v5.0.2 on a FORCE CPU-30 (25MHZ, 4MB) with a Vigra MMI-150 1MB video card. The SUN/OS 4.0.3 was a SUN 4/300 32MB with a cgsix video frame buffer. Both machines were booted and were reduced to minimum deamons and limited net inteference. (Not perfect but reasonable). The demonstration was to start xclock and six individual occurances of the Kaleidascope client. Kaleids were all 200x200. The were all fully exposed on both screens. All clients were working against X servers on their respective CPU. No network activity was occuring to or from outside servers. Once everything was running, all the visual ovservers voted that the X server on the FORCE CPU-30 had a slight edge on the SUN 4/300. The programmers in the group thought this was FANTASTIC since the 68030 has 1/3 the MIPS rating of the SPARC, 1/4 the memory size and (someone guessed) 1/10 of the cost. My question of the VxWorks community is: What is a fair comparison? Should we fight through the technical datails to try for a truly equitable comparison environment or is it appropriate to use the human observer? After all, for a man-machine interface like the X-Windows System, how fast is "fast enough"? If you have any thoughts or simple clients which can be made into a reasonably universal benchmark, I would be interested in hearing from you. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> -> The remainder of this item is some of the VxWorks commands to show you -> the actual task environment and socket activity between the clients -> and the server. If you do not care about this stuff, STOP NOW. -> ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> i NAME ENTRY TID PRI STATUS PC SP ERRNO DELAY ---------- ------------ -------- --- ---------- -------- -------- ------- ----- tExcTask _excTask 3fb600 0 PEND bf90 3fb564 0 0 tLogTask _logTask 3fa0b8 0 PEND bf90 3fa018 0 0 tShell _shell 3b5890 1 READY 1b5d8 3b553c 0 0 tRlogind _rlogind 3e2844 2 PEND 335e6 3e264c 0 0 tTelnetd _telnetd 3e09d8 2 PEND 335e6 3e090c 0 0 tNetTask _netTask 3f5dc8 50 PEND 335e6 3f5d70 0 0 t_Xvxvigra1_main 2afba0 75 PEND+T 335e6 2af804 0 26052 t_xclock2 _main 39024c 100 PEND+T 335e6 38ff50 0 2084 t_kaleid3 _main 37054c 100 READY 29b8c 3700bc 0 0 t_kaleid4 _main 364b84 100 PEND 335e6 3647f8 0 0 t_kaleid5 _main 358180 100 READY 2baa4 357db8 0 0 t_kaleid6 _main 34cd34 100 PEND 335e6 34c9a8 0 0 t_kaleid7 _main 341e6c 100 PEND 335e6 341b00 0 0 t_kaleid8 _main 3358dc 100 PEND 335e6 335570 3d0002 0 ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> spy 10 NAME ENTRY TID PRI total % (ticks) delta % (ticks) -------- -------- ----- --- --------------- --------------- tExcTask _excTask 3fb600 0 0% ( 0) 0% ( 0) tLogTask _logTask 3fa0b8 0 0% ( 0) 0% ( 0) tShell _shell 3b5890 1 0% ( 14) 0% ( 0) tRlogind _rlogind 3e2844 2 0% ( 0) 0% ( 0) tTelnetd _telnetd 3e09d8 2 0% ( 0) 0% ( 0) tSpyTask _spyTask 3766dc 5 5% ( 750) 5% ( 34) tNetTask _netTask 3f5dc8 50 9% ( 1326) 9% ( 61) t_Xvxvigra1 _main 2afba0 75 44% ( 5963) 46% ( 287) t_xclock2 _main 39024c 100 0% ( 1) 0% ( 0) t_kaleid3 _main 37054c 100 4% ( 589) 3% ( 24) t_kaleid4 _main 364b84 100 5% ( 727) 4% ( 28) t_kaleid5 _main 358180 100 5% ( 683) 3% ( 20) t_kaleid6 _main 34cd34 100 5% ( 684) 4% ( 25) t_kaleid7 _main 341e6c 100 4% ( 638) 5% ( 33) t_kaleid8 _main 3358dc 100 4% ( 659) 6% ( 39) KERNEL 10% ( 1441) 9% ( 61) INTERRUPT 0% ( 3) 0% ( 0) IDLE 0% ( 0) 0% ( 0) TOTAL 95% ( 13478) 94% ( 612) ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> memShow SUMMARY: status bytes blocks ave block max block ------ --------- -------- ---------- ---------- current free 1968964 18 109386 1856556 alloc 1926184 10164 189 - cumulative alloc 3923044 17732 221 - ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> inetstatShow Active Internet connections (including servers) PCB Proto Recv-Q Send-Q Local Address Foreign Address (state) -------- ----- ------ ------ ------------------ ------------------ ------- 377a0c TCP 76 0 137.247.112..6000 137.247.112..1031 ESTABLISHED 37d60c TCP 0 380 137.247.112..1031 137.247.112..6000 ESTABLISHED 377e0c TCP 0 0 137.247.112..6000 137.247.112..1030 ESTABLISHED 3f770c TCP 0 92 137.247.112..1030 137.247.112..6000 ESTABLISHED 35e50c TCP 0 0 137.247.112..6000 137.247.112..1029 ESTABLISHED 37d50c TCP 0 92 137.247.112..1029 137.247.112..6000 ESTABLISHED 37d58c TCP 92 0 137.247.112..6000 137.247.112..1028 ESTABLISHED 377d0c TCP 0 92 137.247.112..1028 137.247.112..6000 ESTABLISHED 37730c TCP 0 0 137.247.112..6000 137.247.112..1027 ESTABLISHED 3f710c TCP 0 0 137.247.112..1027 137.247.112..6000 ESTABLISHED 3f800c TCP 76 0 137.247.112..6000 137.247.112..1026 ESTABLISHED 3f748c TCP 0 152 137.247.112..1026 137.247.112..6000 ESTABLISHED 3f778c TCP 0 0 137.247.112..6000 137.247.112..1025 ESTABLISHED 3f758c TCP 0 0 137.247.112..1025 137.247.112..6000 ESTABLISHED 3f7b0c TCP 0 0 0.0.0.0.6000 0.0.0.0. LISTEN 3f7c8c TCP 0 0 0.0.0.0.23 0.0.0.0. LISTEN 3f7d8c TCP 0 0 0.0.0.0.513 0.0.0.0. LISTEN ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> tcpstatShow TCP: 2353937 packets sent 2039925 data packets (157874957 bytes) 6 data packets (2300 bytes) retransmitted 289464 ack-only packets (289303 delayed) 0 URG only packet 0 window probe packet 24429 window update packets 114 control packets 2354493 packets received 313163 acks (for 157874462 bytes) 71 duplicate acks 0 ack for unsent data 2041508 packets (159471927 bytes) received in-sequence 7 completely duplicate packets (2301 bytes) 0 packet with some dup. data (0 byte duped) 2 out-of-order packets (0 byte) 0 packet (0 byte) of data after window 0 window probe 0 window update packet 1 packet received after close 0 discarded for bad checksum 0 discarded for bad header offset field 0 discarded because packet too short 43 connection requests 42 connection accepts 85 connections established (including accepts) 104 connections closed (including 0 drop) 0 embryonic connection dropped 312813 segments updated rtt (of 312865 attempts) 6 retransmit timeouts 0 connection dropped by rexmit timeout 0 persist timeout 0 keepalive timeout 0 keepalive probe sent 0 connection dropped by keepalive ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> ipstatShow total 2388939 badsum 0 tooshort 0 toosmall 0 badhlen 0 badlen 0 fragments 0 fragdropped 0 fragtimeout 0 forward 0 cantforward 0 redirectsent 0 ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> -> udpstatShow UDP: 0 incomplete header 0 bad data length field 0 bad checksum ->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->->-> - From johnb@srchtec.searchtech.com Mon Jan 13 06:40:58 1992 From: johnb@srchtec.searchtech.com Date: Mon Jan 13 06:41:05 PST 1992 Subject: Re: Windays and User Groups (Jayne Johnson wrote:) > Is this year going to be in Boston? If so is anyone attending a college around > the Boston area where we could use the campus resources? > > As far as subjects go I would like to hear alot about C++ and POSIX . Let's > have a seminar to teach the fundamentals of C++. Let's have a seminar about > the POSIX standards VxWorks is compliant and what it means. If you decide to make Boston the location, I'm interested. (My wife has family in the area.) If you have trouble finding someone to teach your "starter seminar" in C++, I'd be willing to do it for free, provided that the trip doesn't cost me anything (i.e. somehow an airplane ticket would have to be provided). I could also possibly talk about experiences using C++ and VxWorks to do "shared instantiations" of objects across processor boards... we've been doing that on a couple of chassis' with FORCE CPU-30's, CPU-40's, and MIPS r3000 boards. Since I only get the daily exploder digest, I haven't been following all of this thread. If anyone has saved all/most of it, could you either forward it to me, or bring me up to date about what's happening with the meeting? Regards, John Baldwin johnb@searchtech.com search technology, inc. uupsi!srchtec!johnb 4725 peachtree corners cir., ste 200 johnb@srchtec.uucp norcross, georgia 30092 From root@borsu6.lbl.gov Mon Jan 13 06:59:59 1992 From: root@borsu6.lbl.gov (PK System Administrator) Date: Mon Jan 13 07:00:05 PST 1992 Subject: don't care Don't care From mea@sparta.com Mon Jan 13 07:05:52 1992 From: mea@sparta.com (Mike Anderson) Date: Mon Jan 13 07:06:02 PST 1992 Subject: Re: Windays and User Groups Greetings! For what it's worth, my company had volunteered a meeting place for last year's East Coast User's group meeting and WRS opted for downtown D.C. We are still willing to volunteer our conference facilities for the 1992 meeting provided folks don't mind McLean, VA (about 7 Miles in towards D.C. from Dulles Airport in the Tyson's Corner area) as a site (maybe $10 each to offset refreshment costs). As usual Todd, if you need any assistance organizing this year's meeting, just let me know and I'll pitch in to help. Last Year's East Coast Meeting Stuckee, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM 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, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From prb@aplexus.jhuapl.edu Mon Jan 13 08:09:19 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Mon Jan 13 08:09:25 PST 1992 Subject: Windays, C++, and shared instantiations John Baldwin wrote: > I could also possibly talk about experiences using C++ and VxWorks to > do "shared instantiations" of objects across processor boards... we've been > doing that on a couple of chassis' with FORCE CPU-30's, CPU-40's, and > MIPS r3000 boards. I would be very interested in a seminar on using C++ and VxWorks; especially your implementation of "shared instantiations" of objects across processor boards... Paul Bade prb@aplexus.jhuapl.edu Life is what happens while you're planning something else. From Christina_Goette@wrs.com Mon Jan 13 08:11:37 1992 From: Christina_Goette@wrs.com (Christina Goette) Date: Mon Jan 13 08:11:49 PST 1992 Subject: WINDAYS USA Subject: Time:8:17 AM OFFICE MEMO WINDAYS USA Date:1/13/92 Recently there have been some questions posted to the exploder about the status of the WINDAYS USA conference that was to be held in March in San Jose. WINDAYS USA was designed to be an exciting series of technical and marketing programs held over the course of two days at the Fairmont Hotel. The audience was targeted as much at new prospects as existing customers. Although the program was shaping up nicely, Wind River Systems has decided to postpone the conference due to the current economic pressures affecting many company's travel budgets. There were simply not enough people that could commit to attend. The concept of WINDAYS USA is a good one, and we look forward to holding this event in the near future, although a new date and time have not yet been decided on. The annual West Coast VxWorks Users Group will be held in the early spring. Details for this event are being worked out even as you are reading this message, so stay tuned for more information. Mitch Bishop Director Marketing From biocca@bevsun.bev.lbl.gov Mon Jan 13 10:26:51 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Mon Jan 13 10:26:57 PST 1992 Subject: Re: RESULT: comp.os.vxworks passes 295: 17 I just want to thank Henning for his efforts in getting this newsgroup creation processed. I'm working on the list-newsgroup connection software, though I suspect it won't work for a few weeks yet. Alan K Biocca Exploder Maintainer From mea@sparta.com Mon Jan 13 10:41:21 1992 From: mea@sparta.com (Mike Anderson) Date: Mon Jan 13 10:41:28 PST 1992 Subject: Re: serial problems with 5.0.2 on 1E Greetings! Sounds to me as though you're overrunning the receive buffer on your display device. I've typically seen this sort of behaviour when the handshakes weren't coordinated (one end was using X-ON/X-OFF and the other was expecting RTS/CTS, etc.) or when the ring buffer for output was being overrun by too many tasks writing to it simultaneously. You might try and just up the ring buffer size on your tyCoDevCreate call. However, if it is a handshake problem, this will only serve to mask it. What you need to do is to put a breakout box on the serial line and watch the signals as you generate this problem. If you see the DTR, RTS, CTS, or DSR lines toggle state, then someone on the line is trying to use hardware handshakes and the other one is ignoring it. I suspect that you probably want to set up both sides for software handshakes (X-ON/X-OFF). As much as I prefer hardware handshakes (it's tough to miss a line voltage change :-), software handshakes are typically easier to implement and they are the default on Sun workstations as they come out of the box (hardware handshakes had to be enabled via a kernel mod under most releases of SunOS). Hope this helps, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM 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, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From dit@melchor.jhuapl.edu Mon Jan 13 13:41:38 1992 From: dit@melchor.jhuapl.edu (Daryl I. Tewell) Date: Mon Jan 13 13:41:44 PST 1992 1) Why is the entryPt parameter of taskSpawn() type FUNCPTR instead of type VOIDFUNCPTR ? Discussion: Since tasks never return, or, at least, aren't called with the idea of providing a return value, it makes sense to cast them as pointers to functions returning void. Doing otherwise, I think, is confusing. 2) Why is the type that malloc() returns (VOID*) NOT the same as the type that free() takes (char*) ? Discussion: These two types should be the same. After all, the application programmer is required to pass free() the same value returned by malloc(). Having two different types for the same value is bad style and confusing. From whorner@vlsi7.gsfc.nasa.gov Mon Jan 13 15:05:19 1992 From: whorner@vlsi7.gsfc.nasa.gov (Ward Horner) Date: Mon Jan 13 15:05:25 PST 1992 Subject: Re: Streams for VxWorks Available? From susanna@tomato.lbl.gov Tue Jan 14 12:43:17 1992 From: susanna@tomato.lbl.gov (Susanna Jacobson) Date: Tue Jan 14 12:43:24 PST 1992 Subject: MVME-165 boot problem Has anyone else had problems booting the MVME-165 with the VxWorks boot PROM's? We have an intermittent boot failure that looks like this: At power-on, the 165 board's status lights show it apparently starting as usual. At about the time when the banner page and boot countdown should appear on the console screen, the red FAIL light on the board lights and stays on. Nothing ever appears on the console screen. If we cycle power a few times, the 165 may eventually come up successfully. Once the 165 succeeds on power-up, warm boots (via software or RESET button) always succeed, but if the crate is powered off, we can never tell whether the 165 will fail on the next power-up. We have seen this on all the 165's we have tried (six so far) in two different kinds of VME crate. A 165 alone in a crate will behave this way, as well as with other boards in the crate. If the 165 has the Motorola BUG PROM instead of the VxWorks boot PROM, it comes up successfully every power-up without fail. We have even tried booting two 165's - one with BUG and one with VxWorks -- in the same crate: the VxWorks board failed and the BUG 165 came up successfully. We're pursuing this with Motorola and with WRS, of course. Has anyone else had this experience or, conversely, used 165's with WRS PROM's without problems? ======================================================================== Susanna Jacobson MS 46A-1123 Lawrence Berkeley Laboratory SRJacobson@LBL.Gov 1 Cyclotron Road (510) 486-7801 Berkeley, CA 94720 ======================================================================== From jim@cave.arc.nasa.gov Tue Jan 14 12:54:47 1992 From: Jim Pantaleo x45347 Date: Tue Jan 14 12:54:53 PST 1992 Subject: 5.0.2b boot problems on 1E While we can get around the serial problems we've been having, another problem has come up that's a stopper. We have two Sun 1E boards - one is an older board with 1MB EPROMs and one is a new board with 2MB EPROMs. The problem is that both of these boards will only boot 5.0.2 in one of our four VME chassis. Both boards will boot in any of the chassis with their original Sun EPROMs installed, and one will boot anywhere with 4.0.2 installed (we don't have a 2MB 4.0.2 EPROM to test the other board). Both boards have 4MB of memory. We also have a third 4MB board with 1MB EPROMs - it has failure problems when it heats up, but it boots in all four chassis with Sun or 4.0.2 installed. With 5.0.2 installed, it will boot in the same chassis the other boards boot OK in, plus one additional chassis. But then it fails after 10-15 minutes because of its heat-related problems... Two of the chassis are 20-slot open cardcages used only for development work, while the other two are enclosed chassis with 17- or 20-slot backplanes. We tried the 1Es both alone in the chassis and with several memory boards in case power supplies were load-sensative - but when they booted they booted regardless of the number of boards. I've spoken to WRS tech support, and they indicated they also found the 1Es to be very sensative to chassis configuration. Does anyone else have any ideas what we can do to get 5.0.2 up and running on those other chassis? Since Sun and 4.0.2 EPROMs boot fine, it's hard not to point a finger at 5.0.2... From ntmtv!fleishma@ames.arc.nasa.gov Tue Jan 14 19:36:04 1992 From: ntmtv!fleishma@ames.arc.nasa.gov (Emmanuel Fleishman) Date: Tue Jan 14 19:36:11 PST 1992 Subject: Re:MVME-165 boot problem Susanna Jacobson writes > Submitted-by susanna@tomato.lbl.gov Tue Jan 14 12:43:17 1992 > Submitted-by: susanna@tomato.lbl.gov (Susanna Jacobson) > > Has anyone else had problems booting the MVME-165 with the VxWorks boot > PROM's? We have an intermittent boot failure that looks like this: > > At power-on, the 165 board's status lights show it apparently > starting as usual. At about the time when the banner page and > boot countdown should appear on the console screen, the red > FAIL light on the board lights and stays on. Nothing ever > appears on the console screen. > > If we cycle power a few times, the 165 may eventually come up > successfully. Once the 165 succeeds on power-up, warm boots (via > software or RESET button) always succeed, but if the crate is powered > off, we can never tell whether the 165 will fail on the next power-up. We too experienced intermitent boot failure although we are using proprietary boards. Recently we identified what was our problem: refference to uninitialized variable during kernelInit This problem has been checked and confirmed by WRS (BTW they were very cooperative and responsive) The problem is kindof rear since most boards probably zero their memory on power-up and this seems to be the *right* value for uninitialized variable. However, since this particular variable resides on stack - all depends what has been done prior to entering scope of this variable... :-( If you suspect any of above then the following patch may help: prior to calling kernelInit(...) call kernelInitPatch(...) which will zero certain area to be used by local variables of kernelInit. Here is modified invocation of kernelInit(..): ---------------------------------------------------------------------------- /* initalize kernel and spawn RootTask * * the following patch zeros space where "initTCB" block will be * located in the kernelInit() procedure. * * Note that Patch always returns OK but it is "tested" to * force compiler to pop SP after return from the Patch. */ if (kernelInitPatch(0,0,0,0,0,0) != OK) return; kernelInit(... 6 kernelInit parameters ...); ---------------------------------------------------------------------------- STATUS kernelInitPatch( int dummy0, int dummy1, int dummy2, int dummy3, int dummy4, int dummy5) { WIND_TCB dummyTCB; bzero((char *)&dummyTCB, sizeof dummyTCB); return (OK); } ---------------------------------------------------------------------------- Hope this helps ----------------------------------------------------------- Emanuel Fleishman voice: (415) 940-2346 Northern Telecom, fax: (415) 966-1067 685 E. Middlefield Road UUCP: ames!ntmtv!fleishma Mountain View, CA 94039 ARPA: fleishma@ntmtv.com ------------------------------------------------------------ From hmp@frc2.frc.ri.cmu.edu Wed Jan 15 08:54:31 1992 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Wed Jan 15 08:54:42 PST 1992 Subject: comp.os.vxworks is alive ... but I haven't seen anything but my own first post on it. Perhaps some of you would like to make trial posts to see if things are working; maybe it takes a while to propagate to everyone. From my post, then: What's up with the promised kernel patch that will fix the synchronization bug with message queues? This bug appeared in a most surprising manner almost simultaneously at several sites last November. -Henning Henning Pangels | hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer | (412) 268-7088 | Carnegie-Mellon University ------------------------------------------------------------------------------ Do you really know what time it is? From prb@aplexus.jhuapl.edu Wed Jan 15 10:13:53 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Wed Jan 15 10:14:00 PST 1992 Subject: Re: comp.os.vxworks is alive Henning wrote: >What's up with the promised kernel patch that will fix the synchronization bug with message queues? This bug appeared in a most surprising manner almost simultaneously at several sites last November. I have received and tested the patch for msgQ's. It works! You will have to talk to WRS to get a copy of the patch. Paul Bade JHU/APL (301)-953-6000 x8681 From francis@wrs.com Wed Jan 15 10:28:23 1992 From: francis@wrs.com (Francis St. Amant) Date: Wed Jan 15 10:28:29 PST 1992 Subject: Re:MVME-165 boot problem Emmanuel Fleishman writes: > We too experienced intermitent boot failure although we are using proprietary > boards. Recently we identified what was our problem: > reference to uninitialized variable during kernelInit WRS verified this problem a few days ago and has built a patch quite similar to the one Emmanuel includes. I am just finished the README file and will formally release the patch to WRS Tech Support this morning. To get it, ask for the kernelInit patch. We had originally characterized this as a warm boot problem only, which is why Susanna Jacobson's initial mail didn't prompt me to reply sooner with this solution. Thanks to Emmanuel for pointing out that some boards may not zero memory on cold boot, so there could be junk on the stack upon cold boot also. Since the patch is relatively short, in source (thus is ascii), and is a current discussion item, I'll put the patch on the exploder in a couple of hours. ------------------------------------------------------------------------------ Francis St. Amant | 800-872-4977 / FAX 510-814-2010 Director of Customer Services | 510-814-2165 bbs Wind River Systems | 1010 Atlantic Avenue francis@wrs.com | Alameda, California, 94501 USA ------------------------------------------------------------------------------ From francis@wrs.com Wed Jan 15 10:44:25 1992 From: francis@wrs.com (Francis St. Amant) Date: Wed Jan 15 10:44:31 PST 1992 Subject: Message queue patch Henning Pangels writes: > What's up with the promised kernel patch that will fix the > synchronization bug with message queues? In mid-December, WRS mailed (US mail, i.e. real hardcopy) a description of this problem and notification of a fix to every customer who had ever bought VxWorks. A small number of these have been returned to us as undeliverable. Most often, this is because we have not been updated when the contact-of-record has changed jobs or left a customer's company. Please be sure that when this happens, you notify us so we can change our records. We depend on correct addresses to communicate with you. Contact WRS sales department at 510-748-4100 to notify us. It can also happen that the person designated to receive official communications from WRS may not be an engineer on the project. So if you didn't receiv word of this fix, please check with your management to see if perhaps they did. If you need the patch, please contact WRS tech support at 800-872-4977 and ask for the message queue patch. It can be shipped to you via email or tape, or you can download it from the WRS BBS at 510-814-2165. ------------------------------------------------------------------------------ Francis St. Amant | 800-872-4977 / FAX 510-814-2010 Director of Customer Services | 510-814-2165 bbs Wind River Systems | 1010 Atlantic Avenue francis@wrs.com | Alameda, California, 94501 USA ------------------------------------------------------------------------------ From jimt@wrs.com Wed Jan 15 11:30:22 1992 From: jimt@wrs.com (Jim Talbot) Date: Wed Jan 15 11:30:33 PST 1992 Subject: SPARC 5.0.2b Summary There have been a lot of questions (both internally and from customers) about the differences in VxWorks 68K and VxWorks 5.0.2b for the SPARC. The main areas of interest are between 68K and SPARC, and VxWorks/SPARC changes from 4.0.2 to 5.0.2b. Most of this is fairly well documented in: Guide to VxWorks / SPARC Architecture-Specific Reference for VxWorks / SPARC Board Support Documentation (Sun SPARCengine 1E, Ironics iv-SPRC). I will summarize some of the changes below (by document) and try to highlight the areas that cause the most difficulty for application developers. To our knowledge, there are no serious bugs in 5.0.2b SPARC. Our beta sites were extremely helpful in finding (and fixing) the few bugs reported. Bug fixes, enhancements, and clean up efforts continued throughout the SPARC VxWorks development and release phases. Guide to VxWorks / SPARC ------------------------ Section 1.0 Introductory stuff. Section 2.0 Getting started, installation, and documentation. Section 3.0 Differences between VxWorks for 68K and SPARC Section 3.1 Compile application modules with -DCPU=SPARC. Section 3.2 bALib can be pulled in to get 8-byte versions (faster execution) of bzero(), bfill(), and bcopy(). Section 3.3 bLib provides an unaligned swap routine call uswab(). Section 3.4 dbgLib has some changes and caveats for SPARC. Affected routines are: c(), s(), cret(), so(), psrShow(), and tt(). Section 3.5 Addition of fppEnable() to fppALib. Section 3.6 Addition of fsrShow() to fppLib. Section 3.7 intALib functions intLevelSet() and intLock() differ for the SPARC which has 15 interrupt levels (68K has 7). Section 3.8 malloc() returns a pointer that is 8-byte aligned. Section 3.9 scsiPhysDevCreate() parameter change: selTimeOut replaced by reqSenseLength. Section 3.10 Some SPARC signal definition changes - see sigLib.h Section 3.11 taskRegsSet() and taskRegsGet() in taskArchLib differ from 68K. Section 3.12 The register functions in usrLib differ for SPARC (of course): g0() - g7(), o0() - o7(), l0() - l7(), i0() - i7(), pc(), npc(), psr(), wim(), y(). Section 3.13 The vxTas() routine uses the SPARC LDSTUB instruction - reference vxALib and/or the SPARC Architecture Manual (note the TAS/backplane configuration for the Sun-1E). Section 3.14 vxLib contains an additional function to access alternate space indices (ASI) called vxMemProbeAsi(). Section 3.15 The vector table base address is 0x1000 for all SPARC targets. Section 3.16 This is a lengthy discussion of SPARC interrupts. In brief, there are 15 levels, an interrupt stack is implemented in software, and there is optional vectored interrupt handling. In 4.0.2 vectored interrupts were not supported (the SPARC uses autovectoring) which made porting from 68K targets difficult. In 5.0.2 vectored interrupts are the default for seamless porting for 68K types and applications. In sysLib.c look at sysIntAckTable[]. There are two options based on "addresses" or "functions". Also, the vector size and ASI space are selectable for levels that specify an IACK address. Note that 4.0.2 applications that want to remain autovectored should fill the table entries to NULL (one entry for each interrupt level). A NULL entry suppresses the IACK cycle (or call) for that interrupt level. The call table method allows more powerful and flexible interrupt acknowledgement but has adds overhead. The mapping of the 7 VMEbus interrupt levels to the 15 SPARC levels may vary with each target (see hardware manual). VME interrupts must be acknowledged to clear the signal line. Section 4.0 This is the floating-point section for SPARC. Areas covered include: floating-point contexts, exception definitions and options, exception handlers, deferred exceptions, and floating-point exception simulation. A list of SPARC floating-point instructions follows, as does the VxWorks math library for the SPARC. There is a tutorial on how to incorporate a higher performance math library (SunOS libm.a) for certain SPARC targets. Architecture-Specific Reference for VxWorks / SPARC --------------------------------------------------- This document contains replacement "libraries" for: bALib Buffer manipulation (assembly) fppALib Floating-Point (assembly) fppLib Floating-Point (C) intLib Interrupt subroutines taskArchLib Architecture-specific task management routines trcLib Stack trace support The "drivers" section contains two additions: l64853Lib Sbus DMA Controller ncr5390Lib NCR 5390 Advanced SCSI Controller (ASC) Board Support Documentation (Sun SPARCengine 1E) ------------------------------------------------ The Sun-1E is the most popular of the SPARC VxWorks targets to date. This board can be very difficult to develop applications with if one needs to work at the board level. Higher level applications can benefit greatly from the wealth of SPARC code. VxWorks on the Sun-1E has attempted to buffer the user from the Sun hardware, but it is impossible to do so for everybody. Some key topics are touched upon, but refer to the VxWorks documentation, the 1E documentation, and the BSP code for more detail and code samples. EPROM Sockets - Some boards have 1Mbit (27010) daughter boards (256K total), others support 2Mbit (27020) ROMs (512K bytes). The ROMs are sequential, not interleaved. Code starts in U101 and continues in U102, if necessary. See ROM_SIZE in config.h, and check your hardware manual for the daughter board size. Boot ROMs - The standard VxWorks boot ROMs are compressed. This results in a very long boot sequence (>30s) on the 1E since the execution of the decompression code and the writing of the resultant data are done while caching is still turned off. Sorry, but that's as fast as the hardware can go. If this is too annoying use uncompressed ROMs (make bootrom_uncmp.hex) - 40% more code space but faster booting. Also note the debug option RESET_WINDOW_UNROLLING in romInit.s. Non-Volatile RAM - The VxWorks boot parameters are saved in NVRAM. Previous versions of the 1E BSP saved this information at offset 0, trashing the SunOS boot parameters. In an effort to help those who freely interchange SunOS and VxWorks on 1Es the boot parameters were moved to an unused area of the NVRAM (see NV_BOOT_LINE in config.h). 5.0.2b ROMs will not find your old boot parameters so copy them the new area or re-enter them from the boot prompt. The old ethernet address was created in usrConfig.c (and bootConfig.c) to try to come up with a unique physical address. Now that we know where Sun puts the address in NVRAM it is pulled from there and given to the LANCE. Since many of us are doing development and our code may go astray, this six-byte address can get trashed. I suggest you write it down somewhere so you can restore it by modifying the bytes directly. There are two parts: the three-byte Sun prefix, and the three-byte suffix. See sysHwInit() and the initialization of lnEnetAddr[] in sysLib.c. For those who have already lost the address, try using the last digits of the board's serial number to get a unique pattern for the last three bytes. The virtual addresses and data are as follows: 0xFFD047DA = 0x08 /* Sun Microsystems */ 0xFFD047DB = 0x00 0xFFD047DC = 0x20 0xFFD047DD = 0x?? /* Board-specific */ 0xFFD047DE = 0x?? 0xFFD047DF = 0x?? You can also attempt to write-protect the NVRAM using the Sun-4 MMU. Jumpers - There are only a few jumpers on the board and are seldom set more than once. The bus arbiter function is enabled/disabled by the inclusion/exclusion (respectively) of the J1701 jumper between the VMEbus connectors. Use the "jump" tool, it really works! Devices - The serial ports use a 15-pin connector in the DB-9 footprint. There are two standard serial ports, a keyboard/mouse interface, LANCE chip, SCSI controller, a time-of-day clock, Sbus, P2 bus, VMEbus, and front panel LEDs. Please note the interactions between the MMU, the cache, DMA devices, VME slave accesses, and Sun DVMA space. Memory Maps - There are several memory maps in the manual, including: Control Space, System Space, Device Space, the DRAM Map, and the MMU table. Note that use of the MMU is required, and also provides some of the cache support. Memory Management Unit - The Sun-4 MMU can be fun (just kidding) to program, so VxWorks has set up default mappings. Since this will not cover all applications, changes should be made to sysMmuInit() in sysLib.c. Note the interactions between the MMU, the cache, DMA devices, and VME slave accesses (DVMA). The MMU can only map 64M bytes at any given time. The MMU can make development difficult, but can also serve as a powerful extension when used effectively. Working with the MMU is tricky so use extreme caution, and consider side effects. Key terminology: context, segment, page, PMEG, PTE, type, virtual address, physical address, DMA, and DVMA. See the 1E manual for the gory details. The MMU operation is required, so learn it well if you must program at that level. In an effort to minimize the user's knowledge of the MMU an alternate library (sysMmuLib.c) has been developed. There is an excerpt from a paper describing how one can create architecture-independent MMU and cache libraries for all VxWorks targets. Note that malloc() and other accesses to high DRAM on 16M boards for DMA devices (LANCE, SCSI) may create virtual address that are not mapped (0xFF400000 - 0xFFCFFFFF), already used (0xFFD00000 - 0xFFD1BFFF), or conflict with DVMA space (0xFFFxxxxx). Cache - The Sun-1E contains a 64K byte write-through virtual address cache with several flushing options - see sysCacheSet(). Be wary of cache coherency of DMA and VMEbus slave operations since things are cached by virtual address. The rule of thumb is to flush the data cache and then invalidate the instruction cache. Short cuts can be made for different cache implementations, especially mixed instruction/ data caches in write-through mode like on the Sun-1E. VMEbus - The VMEbus supports a restricted set of master and slave accesses. Other features include 32 mailbox addresses, a bus locker, a jumper for system controller, and a loopback cycle. Note that there is a 512K byte master access window, and a 1M byte slave access window with DVMA (MMU mapping). The default window number is set to the processor number. Note that this affects the backplane driver for on-board buffering. Interrupts - On-board interrupts do not need to be acknowledged. However, VMEbus interrupts must be acknowledged. See sysIntAckTable[] or sysBusIntAck() in sysLib.c. Floating-Point - Floating-point operations are supported with a coprocessor chip that allows the pipelining of operations. Floating-point exceptions are deferred, i.e., they must be pushed through the queue to generate an error. In summary for the 1E, understand the MMU and caches, the interactions of them with DMA devices and slave DVMA. Also note that the early Sun-1E manual had several errors and typos. Board Support Documentation (Ironics iv-SPRC) --------------------------------------------- The Ironics SPARC runs at 25MHz or 33MHz, which must be selected in ivSPRC.h with CPU_CLOCK_xxMHZ. Remake the VxWorks image to run on 33MHz boards (the default is 25MHz). EPROM and NVRAM - The ROMs are interleaved and require two (2) 27210s or 271024s (16-bit) ROMs. The most significant word is in U57; the least significant word is in U60. The board does not have non-volatile RAM to preserve the boot parameters. One can use function keys to aid in boot parameter entry, or burn a new bootline in the boot ROMs. Non- volatile memory may be supported in future releases of the hardware. Jumpers - There are a few jumpers of interest in the iv-SPRC. One must select the EPROM size, the system controller function, and enable/disable the abort and reset switches. Devices - The ivSPRC board has the two serial ports, VIC, VAC, and LED registers. A hexadecimal rotary switch, a reset switch, and an abort switch are available for the application programmer. Support for a daughter board (seti) may be added in future releases. It provides on-board ethernet, SCSI, and non-volatile memory. Ethernet - The current configuration only supports ENP-based networks. The seti daughter board (if/when supported) would allow on-board ethernet. Interrupts - The ivSPRC requires an acknowlegement of all interrupts. This has been made easier with the 5.0.2b release - see sysIntAckTable[] in sysLib.c. MMU and Cache - The default configuration is with the MMU and cache enabled, write-through mode. This can be set to copyback mode to increase performance, but at the added risk of cache coherency problems. The rule of thumb is to flush the data cache and then invalidate the instruction cache. Short cuts can be made for different cache implementations. Memory Maps - The memory map is established by the MMU. The DRAM map for VxWorks differs slightly for the ivSPRC, but the vector table is still at address 0x1000. One can customize the default MMU setup by changing sysMmuInit() in sysLib.c. Problems -------- * Some versions of the Force CPU-1E have been having trouble booting. Wind River Systems and Force Computers are working together to find the source of the problem(s), hardware and/or software. Force is investigating the revisions of ROM daughter board, the gate arrays, and other hardware configurations that seem to be troublesome. All Sun/Force 1Es here at WRS boot fine with the 5.0.2b boot ROMs. * Remember, most network related problems are simply due to configuration on the host and/or target. See the network section of the VxWorks Programmers Guide. Patches ------- Since the release in November there have been a few improvements to the SPARC release. None are critical, but may be helpful to know about. These are in the patches directory of the release tree. In h/sparc/esf.h there should be parentheses around the "n" in the following macros: SF_LOCAL, SF_IN, ESF_GLOBAL, ESF_OUT, ESF_LOCAL, and ESF_IN. This helps avoid unexpected sizing assumptions that the compiler might make. The stack tracing code has been upgraded to allow more stacks to be traced. The SPARC had code that forced and early exit of some traces that involved calling absolute (register-based) addresses, as opposed to PC-relative calls (most calls are relative). This debugging aid has been fixed so that these cases are supported. As a result ^C from the shell now works and tt() is more robust. There is a bug in the initialization code for all of VxWorks 5.X that can affect boot ROMs and VxWorks image booting. Uninitialized variables in kernelInit() that serve as the initial TCB can prevent the root task from finishing its configuration. All of the above are rarely encountered, so getting the patches should not be critical unless you have already been affected. Contact Wind River Systems Technical Support for more information and/or upgrades. Be creative in your debugging efforts. There is always a solution - the information gathering and design efforts are only limited by your imagination and effort! Remember, read those manuals and try different configurations and tests before calling Technical Support. The more homework that you do the better able tech support will be help you to solve your problem. * Both VxGDB and windX are available as separate products for the SPARC. +-------------------------------------------------------------------+ | James W. Talbot Wind River Systems | | Architecture Porting Group Lead 1010 Atlantic Avenue | | and SPARC Project Lead Alameda, California 94501 | | | | (510) 814-2087 TEL: (510) 748-4100, x2087 | | jimt@wrs.com FAX: (510) 814-2010 | +-------------------------------------------------------------------+ From francis@wrs.com Wed Jan 15 12:41:38 1992 From: francis@wrs.com (Francis St. Amant) Date: Wed Jan 15 12:41:45 PST 1992 Subject: kernelInit patch, as promised Here's the official patch from WRS. The text mentions the source file sprFix1272.c, which I have included after the README file. I hope this solves the 165 booting problems. Please call Tech Support if you have continuing problems. ------------------------------------------------------------------------------ Francis St. Amant | 800-872-4977 / FAX 510-814-2010 Director of Customer Services | 510-814-2165 bbs Wind River Systems | 1010 Atlantic Avenue francis@wrs.com | Alameda, California, 94501 USA ------------------------------------------------------------------------------ This is the README file for the kernelInit patch. This patch applies to Wind River Systems' VxWorks versions 5.0.2, 5.0.2b, 5.0.3, and 5.0.4 on the architecture families of 68k, 683xx, SPARC, and TRON. This patch is not necessary for the architectures of 68040, 960, or MIPS. Any questions or problems should be directed to Wind River Systems Technical Support. Presenting Symptoms ------------------- Warm boot using control-X can fail intermittently. If warm boot succeeds, all is well. Hardware reset or cold boot may also experience this problem if your board does not zero memory when reset or powered up. Patch Contents -------------- This patch contains the following files: (1) This README file; (2) The file sprFix1272.c Patch Installation Instructions: -------------------------------- This is a source code patch which will zero an uninitialized stack variable used by the routine kernelInit(). (1) Edit the function usrInit in both the files config/all/usrConfig.c and config/all/bootConfig.c to include a new function call, as shown below. (2) Add the new function sprFix1272, which is the entire contents of the file sprFix1272.c, to config/all/usrConfig.c and config/all/bootConfig.c. (3) In the target directory for each of your targets, execute the commands make make bootrom.hex to generate new vxWorks and bootrom.hex files (4) Make new boot ROMs from the new bootrom.hex file. ------------------------------------------------------------------------------- The following code fragment from the usrInit function shows the code to be added according to step 1, above. Insert the lines specified between the >>>> <<<< marks just before the call to kernelInit, as shown. (Do not insert the >>>> <<<< marks themselves.) ------------------------------------------------------------------------------- VOID usrInit (startType) int startType; { ... /* start the kernel specifying usrRoot as the root task */ >>>> <<<< >>>>sprFix1272 (usrRoot, ROOT_STACK_SIZE, FREE_RAM_ADRS, sysMemTop (), <<<< >>>> ISR_STACK_SIZE, INT_LOCK_LEVEL); <<<< kernelInit (usrRoot, ROOT_STACK_SIZE, FREE_RAM_ADRS, sysMemTop (), ISR_STACK_SIZE, INT_LOCK_LEVEL); } ==============End of README file for the kernelInit patch====================== /******************************************************************************* * * sprFix1272 - fix SPR #1272 * * This routine will zero an unitialized stack variable used by kernelInit(). * It achieves this by mimicking the kernelInit () stack frame and zeroing the * variable in question. * * This patch is necessary for the versions 5.0.2, 5.0.2b, 5.0.3, and 5.0.4 on * the architecture families of 68k, 683xx, SPARC, and TRON. * * This patch is not necessary for the architectures of 68040, 960, or MIPS. * * CAVEAT * This patch must be compiled with the same compiler switches and optimization * level as was shipped with the original Makefile. * * ARGSUSED * NOMANUAL */ sprFix1272 (rtn, size1, base1, base2, size2, level) FUNCPTR rtn; unsigned size1; char * base1; char * base2; unsigned size2; int level; { WIND_TCB tcb; WIND_TCB * pTcb; unsigned lsize; char * lbase1; char * lbase2; bzero ((char *) &tcb, sizeof (WIND_TCB)); } From litwin@robotics.jpl.nasa.gov Wed Jan 15 13:41:53 1992 From: litwin@robotics.jpl.nasa.gov (Todd Litwin) Date: Wed Jan 15 13:42:00 PST 1992 Subject: TCP/IP timeouts I know that this issue has been brought up before, but I want to ask a very specific question that I don't think has been covered. We are using TCP/IP both over ethernet and over a SLIP channel. If one of the channels is disconnected, then my socket times out after somewhere between 5 and 10 minutes. What I want to do is to reduce this to some reasonable minimum, such as 1 minute or 30 seconds. From previous discussions, it seems that the variables to set are probably one of tcp_maxidle tcp_keepidle tcp_maxintvl but that changing these affects many things, and not just timeout. Does anyone know how to manipulate these (or other) variables to adjust when TCP/IP will timeout a socket? And what would the side effects be of doing this? Thanks. Todd Litwin Jet Propulsion Laboratory (818) 354-5028 litwin@robotics.jpl.nasa.gov From biocca@bevsun.bev.lbl.gov Wed Jan 15 15:43:10 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Wed Jan 15 15:43:17 PST 1992 Subject: Connecting list to newsgroup In article <1992Jan15.184722.26046@acsu.buffalo.edu> jones@acsu.buffalo.edu (Terry A. Jones) writes: > Any ideas when the exploder will be connected to the news group? As soon as I get things working. Perhaps a couple of weeks, depending on workload.. Anyone have a robust program that collects news from a specific newsgroup and puts it into a pipe or files or ...?? I picked up one from the new awhile back but it is buggy... Alan K Biocca Exploder Maintainer From dave@exlog.com Thu Jan 16 06:20:56 1992 From: dave@exlog.com (Dave St.Clair) Date: Thu Jan 16 06:21:02 PST 1992 Subject: Unsubscribe me Please unsubscribe me from the exploder since I get USENET (comp.os.vxworks). dave st.clair From prb@aplexus.jhuapl.edu Thu Jan 16 08:11:02 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Thu Jan 16 08:11:09 PST 1992 Subject: Re: kernelInit patch, as promised Francis St. Amant wrote: >I hope this solves the 165 booting problems. >This patch applies to Wind River Systems' VxWorks versions 5.0.2, 5.0.2b, 5.0.3, and 5.0.4 on the architecture families of 68k, 683xx, SPARC, and TRON. This patch is not necessary for the architectures of 68040, 960, or MIPS. I am confused. The 165 board has a 68040. I will soon be using MVME-165 and MVME-167 boards. I assume I need the patch? Paul Bade From biocca@bevsun.bev.lbl.gov Thu Jan 16 08:25:29 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Jan 16 08:25:35 PST 1992 Subject: Re: Unsubscribe me Two comments about unsubscribing from the exploder due to the availability of comp.os.vxworks: 1. Please wait until they are cross-connected (perhaps two weeks). 2. Please don't send these requests through the exploder -- there are separate addresses at the end of each exploder message that give the correct addresses for administrative requests. Thanks, Alan K Biocca Exploder Maintainer From sky!copeland@uunet.uu.net Thu Jan 16 08:46:03 1992 From: sky!copeland@uunet.uu.net (Darrell Copeland ) Date: Thu Jan 16 08:46:10 PST 1992 Subject: Unsubscribe me From francis@wrs.com Thu Jan 16 11:21:48 1992 From: francis@wrs.com (Francis St. Amant) Date: Thu Jan 16 11:21:53 PST 1992 Subject: Re: kernelInit patch and 68040 I wrote: > >I hope this solves the 165 booting problems. > and then later in the patch itself: > >This patch applies to Wind River Systems' VxWorks versions 5.0.2, 5.0.2b, > 5.0.3, and 5.0.4 on the architecture families of 68k, 683xx, SPARC, and TRON. > This patch is not necessary for the architectures of 68040, 960, or MIPS. > And Paul Bade writes: > I am confused. The 165 board has a 68040. I will soon be using > MVME-165 and MVME-167 boards. I assume I need the patch? > I apologize for the momentary confusion. This fix had been suggested by a user as potential help for the 165 booting problem. The main text of that message was a patch for kernelInit. I thus hastened to put up the "official" WRS patch, so WRS could more easily support customers, as they'd all have our version of it. My thanks to Emmanuel Fleishman for graciously providing essentially the same fix. I'm simply trying to standardize this as much as possible for ease of supporting you all. In rushing to focus on the patch/support issue, I overlooked the fact that this had started out as a discussion of mv165 booting, to which this patch doesn't apply. We're dealing directly with LBL on their booting problems. It's possible that the issue is simply LBL having an early beta release. We'll soon find out. So once again, sorry for any confusion generated. The patch and the mv165 booting are separate issues; their lifelines in "information space" momentarily intersected on the exploder, and hopefully they will now cleanly diverge. ------------------------------------------------------------------------------ Francis St. Amant | 800-872-4977 / FAX 510-814-2010 Director of Customer Services | 510-814-2165 bbs Wind River Systems | 1010 Atlantic Avenue francis@wrs.com | Alameda, California, 94501 USA ------------------------------------------------------------------------------ From MCGREGR@bnr.ca Thu Jan 16 13:08:03 1992 From: Andrew (A.J.) McGregor Date: Thu Jan 16 13:08:11 PST 1992 Subject: Re: kernelInit patch, as promised I am suprised that the patch is not required for the 960 as I had similar problems (which I fixed by zeroing the memory). How sure are you of this, or was it rolled into the latest 960 release? Regards, Andrew. Andrew McGregor (MCGREGR@BNR.CA) Phone: (613) 763-7236 Bell-Northern Research P.O. Box 3511, Station C, Ottawa, Ontario, Canada, K1Y 4H7 From hill@luke.atdiv.lanl.gov Fri Jan 17 08:19:11 1992 From: hill@luke.atdiv.lanl.gov (Jeff Hill) Date: Fri Jan 17 08:19:18 PST 1992 Subject: Re: TCP/IP timeouts I solved this problem by periodically sending a noop message over the TCP/IP connection. Please send me a copy of any interesting responses to your message. Jeff From biocca@bevsun.bev.lbl.gov Fri Jan 17 12:38:36 1992 From: randyw@theopolis.orl.mmc.com (Randy Walker) Date: Fri Jan 17 12:38:43 PST 1992 Subject: targeting custom boards Our team recently targeted VxWorks to a SPARC based processing board which was designed in-house. We ran into problems while integrating an Ethernet driver. We needed information about the VxWorks network communication layers of software so that we could interface our software. We experienced great difficulty in getting support from Wind River. It seems that their customer support organization was either not capable or not willing to answer questions of this sort. Finally, Wind River told us that they would not support the targeting of VxWorks to custom hardware through their normal customer service. We were told that we had three options: 1. We could buy their source code. ( no guarantees of support ) 2. We could pay for a Wind River consultant to come to our site and help us. 3. We could pay Wind River to write custom software for us. I am curious about other groups' experiences in targeting VxWorks to custom hardware. Also, do other groups expect to try this in the future? If enough pressure is applied to Wind River, maybe they will be more flexible in the future. Sales can be won and lost over supporting a customer's needs. From sjk@emerald.labs.tek.com Fri Jan 17 16:06:18 1992 From: Steven King (503) 627-2736 Date: Fri Jan 17 16:06:26 PST 1992 Subject: NFS Server for VxWorks Does anyone have a publicly available (or cheap) NFS Server ported to VxWorks? Steven ---------------------------------------------------------------------- e-mail: sjk@crl.labs.tek.com Steven King phone: 503-627-2736 Computer Research Lab, Tektronix, Inc. voice mail: 503-727-6651 P.O. Box 500 MS 50-662 fax: 503-627-5502 Beaverton, OR 97077 ---------------------------------------------------------------------- From visicom!VisiCom.COM!trest@nosc.mil Fri Jan 17 16:10:56 1992 From: Mike Trest Date: Fri Jan 17 16:11:03 PST 1992 Subject: Re: targeting custom boards >>I am curious about other groups' experiences in targeting VxWorks to >>custom hardware. VisiCom Labs has "targeted" VxWorks to several OEM boards including three NON-VME custom boards. We have a team of 40 VxWorks programmers 10 of whom are board level GURU types. Our decision to do custom work is done on a case-by-case basis. Some ports have taken only 4 days (a recent 68040) effort. Others have taken several weeks. We are presently working on custom 68302 and 68340 jobs. We usually do custom work because (1) we need it for ourselves, (2) one of our customers requests it or, (3) an OEM organization needs it done faster than in-house staff can do it. Our two years+ experience with WRS has been quite good. Since we have done 14 such "targeting" jobs, we have had a fruitful exchange at the formal corporate level and at the more personal working level. Perhaps our friendly relationship is because we are contractor to several of WRS's biggest customers and are a reseller of VxWorks ourselves. Understand this. There is no free lunch. We have paid our share of prices for licenses and annual maintenance contracts, and such (we have several full and half licenses present in our shop ... some ours ... some being customized awaiting delivery to the final customer). We have also recprocated whenever asked for technical assistance, joint marketing opportunities, or BETA site testing of new software. Having worked with the people in Customer Support myself, I understand what my money has purchased and what it has not. Alas, like you, I would some times like to have the full sources. We cannot afford it. But we get the job done by asking questions carefully. Having been involved, personally, in UNIX kernel support and device driver writing for 15 years, I have found that the last two years dealing with WRS has been quite pleasant (in comparision to others who shall not be named). ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== From carl@umd5.umd.edu Fri Jan 17 21:32:03 1992 From: Carl Symborski Date: Fri Jan 17 21:32:09 PST 1992 Subject: re: targeting custom hardware On Fri Jan 17, 1992 randyw@theopolis.orl.mmc.com (Randy Walker) writes: > Our team recently targeted VxWorks to a SPARC based processing board > which was designed in-house. We ran into problems.... > . . . > We experienced great difficulty in getting support from Wind River. > . . . > I am curious about other groups' experiences in targeting VxWorks to > custom hardware. Also, do other groups expect to try this in the future? I have personally managed the development of three VxWorks board support packages last fall. All of these were custom hardware designs with custom interfaces, one with a VME interface. Prior to starting we spent some time trying to figure out how to go about doing this. Like you we did not (and still don't) have sources for VxWorks. Also like you, we experienced difficulty getting information on the work required. First off, I should point out that our targets were for the i960 and so we bought our OS (Vx960) and support from Intel. The Intel factory organization *was* supportive of us but the main problem was that there was just no black and white documentation which Intel or WR could hand to us. Since we didn't deal directly with WR on this I can't comment on the WR support organization. So we studied the example BSPs in the config directory. Asked careful questions. Considered the answers. Looked at the code again. Then repeat. At one point I considered contacting one of those contractor companies with WR experience you occasionally see here on the net. But naaa, we were having to much fun! You may actually have to be concerned with three types of software. A low level monitor (in our case NINDY), the board support package proper (including backplane interfaces and the infamous sysLib), and the development of network drivers for any custom hardware on your board (like T1 or whatever). Oh and don't forget, you have to do this and debug virgin hardware at the same time! ;-> Today it is my understanding that WR has a class on how to do the board support package part. Or maby this was from Sparta... don't remember but I'm sure Mike will fill you in. Can't say how good these would be. I also know that WR has developed a document which discusses how to develop a network driver. Not sure if this is officially released, but we got a copy through Intel. This was very helpfull. It also helped to read plain old BSD code to get an understanding of mbufs and what IP generally expects out of a piece of network code. That is, if you are going to write a network driver. Getting a copy of an example VxWorks network driver was also crucial. Note that if you are just porting an existing network driver to your hardware most likely all that is needed are sysLib changes. My suggestion is to look at the hardware boards represented with board support packages in your config directory. Find one which matches your actual hardware the best. Then start your modifications using that package. I can relate to the problems you mention. Seems that the "typical" Vx customer simply buys commercially available single board computers (Hurikon, Cyclone, what ever) and uses the board support software which those vendors supply. It is probably not profitable for WR to have to train the few of us who feel the need to roll our own. No, this is not a justification, its just the way it is. Soooo, keep on calling them with questions. Carl From chinacat!nominil!linimon@cs.utexas.edu Sat Jan 18 08:15:37 1992 From: linimon@nominil.lonestar.org (Mark Linimon) Date: Sat Jan 18 08:15:49 PST 1992 Subject: re: targeting custom hardware Basically there are three levels to porting vxWorks. 1. Porting to a new architecture. You will find that the level of difficulty will vary from medium to hard; however, it is my humble opinion that without the sources, and a close working relationship (or parternship) with Wind River, this is infeasible. 2. Porting to a new variant of the same architecture (68040 vs 68030 or 68302 vs 68000). Although this may seem to be easy, there can be subtle issues involved, especially if one wants to take appropriate advantage of all the features of the new architecture. The above comments apply. 3. Porting to a new peripheral chipset. It's most likely that you only need some sample driver code for these. The gotchas mostly lurk in network drivers, although serial and disk drivers have their fair share. Prior Unix driver experience will save you the steepest part of the learning curve. 4. Porting to a new board using the same architecture. Given that you leave out virtual memory and DMA (a common condition in many of the real-time VMEbus board ports), this will be the easiest of the set, and can be learned without source (although it's certainly helpful and will save head-scratching time). The first one's hard, the second one's medium, and after that they get easy (given that the comments in 3 also apply here). 5. Virtual memory and/or DMA? Multiple masters on the same backplane? New floating point architecture? I would recommend laying in a heavy stock of Maalox and tranquilisers before starting. These are all only my personal opinions, of course, but I can reassure you that I've paid for them with personal experience. -- Mark Linimon / Lonesome Dove Computing Services / Austin, Texas {balkan,chinacat,uunet}!nominil!linimon || " ...so you've got to pay attention, linimon@nominil.lonestar.org || ... a D-10 can be the death of you." From iphasew!hwajin@uunet.uu.net Sun Jan 19 15:37:47 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Sun Jan 19 15:37:54 PST 1992 Subject: VxWorks network drivers WRS should have various technical documents regarding the network drivers. I have written a few while I was there, so I know they should have it somewhere. If you can't get them from WRS, you can learn by reading freely available 4.3 BSD code which is available various places (e.g. uunet.uu.net). For an example of how a CMC ENP-10 ethernet board driver can be written for 4.3 BSD based TCP/IP such as VxWorks', you can read "packages/bsd-sources/sys/tahoe/if/if_enp.c" available on uunet. The latest VxWorks also includes SunOS compatible routines such as ether_attach(), do_protocol(), and copy_to_mbufs(), etc., which are included in the post-Reno 4.3 BSD code on uunet in file "packages/bsd-sources/sys/net/if_ethersubr.c". As most have guessed, VxWorks network driver uses essentially the same interfaces to the upper level protocols via "struct ifnet" based interface. There are, however, a few notable differences between the UNIX and VxWorks network drivers: 1. In VxWorks, network interrupt handlers do minimal amount of work at interrupt level. Pretty much all that happens inside the interrupt handler routine is to queue a call to the routine that does the actual work of handling the interrupt by calling netJobAdd(). netJobAdd() queues a funtion pointer and arguments to a ring buffer queue which is handled by the network task. The network task dequeues the queued job requests and carry out the request by issuing the calls at the task level. This minimizes the interrupt latency. In contrast, UNIX drivers may go as far as scheduling ipintr() and liberally lock out lower level interrupts using spl routines. VxWorks never locks out interrupt levels; spl routines are implemented using semaphores. VxWorks does not use schednetisr(). Task level routines call ipintr() directly; interrupt level routines queue the call using netJobAdd(). 2. The mbuf's are implemented a little differently in VxWorks. The driver writer needs to pay a bit more attention to on-board network devices if he/she wants to use VxWorks mbuf clusters to avoid unnecessary copying of data. If local arbiter allows both CPU and network chip to access the buffer memory without any special restriction, you can use mbuf clusters to initialize the buffer memory for the network device and use cluster specific routines to share the same buffer between the CPU and network chip. You should be able to figure out how to do this by reading "net/mbuf.h" and perhaps one of the drivers that actually does this such as the LANCE driver or the backplane driver. VxWorks mbuf clusters are implemented without any paged VM support, but the code that implements it is available in "mbuf.h" so you should be able make use of this if you want performance out of your drivers. 3. VxWorks lacks SunOS NIT or BSD packet filter style hooks to the drivers, but includes support for "etherLib" style hooks to allow access to the raw network data. Driver writers who want to allow etherHook support should add some code to output and input routines of the driver that checks the existence of etherHook routines for input and output. If they exist a copy of the input or output data should be sent to the hook routines. Documentation for etherLib explains this further. -- Hwa-Jin Bae Interphase West From leonid@amil.co.il Mon Jan 20 07:49:20 1992 From: leonid@amil.co.il (Leonid Rosenboim) Date: Mon Jan 20 07:49:27 PST 1992 Subject: MMU Usage Now that VxWorks runs on a couple of CPUs that have integral MMUs (e.g. 68030) it looks pretty interesting if the MMU can be exploited to acheive some extent of memory protection scheme to improve overall software reliability, and shorten development time. I would like to hear your opinion and ideas on this subject, and even more we would like to hear about people that really implemented any of their ideas. To start the discussion rolling, here are some ideas we here have come up with: 1. Text Write Protection Protect the portions of memory that contain program text from accidental corruption by part of the program - identify portions of memory that contain text and protect them read-only. Alternatively prellocate a portion of memory for text and make sure to load text into that part and write protect it after load finished. 2. Stack Overflow Protection Any scheme that can guarantee a bus error (or other trap) in case a task's stack pointer has exceeded the stack's allocated space, to prevent accidental curruption of unrelated data areas, and help identify tasks which have a wrong stack size. 3. Hardware Breakpoints A feature most ICEs provide - stop task execution (Suspend Task) on attempt to access (Read Wrote or Execute) a particular address or address range. 4. Resource Manager To protect all writable data items on a system from accidental access/writing due to uninitialized pointers or other program error, there should be some kind of central broker to pass through, like the MacOS Resource Manager. This typically adds some overhead to program portions that share data with other tasks. ----- The 4th item is rather far-tetched I understand, but it looks promising in the longer term. We are not planning to implement any of these yet, but would like to know what other WRS users think about. Sure, WRS developers' point of view is most welcome. --------------------------------------------------------------------- | Leonid Rosenboim Internet: leonid@amil.co.il | | System Administrator Fax: +972-3498-078 | | Applied Materials (Israel) LTD. Voice: +972-3499-573 | | +972-3498-201 | --------------------------------------------------------------------- From mea@sparta.com Mon Jan 20 09:07:52 1992 From: mea@sparta.com (Mike Anderson) Date: Mon Jan 20 09:08:01 PST 1992 Subject: Re: NFS Server for VxWorks Greetings! There's a public domain NFS Server implementation called SOS (Steve's Own Server, I believe) that runs on PCs using PC-NFS. Its available from the Simtel20 anonymous FTP archives in the UNIX-C directories. It doesn't target VxWorks directly, but it is source that should come close. Good Luck and please send a working version to the user's group archives, ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM 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, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From PK5685%MAX.U.WASHINGTON.EDU@UWAVM.U.WASHINGTON.EDU Mon Jan 20 09:58:09 1992 From: PK5685@MAX.U.WASHINGTON.EDU Date: Mon Jan 20 09:58:17 PST 1992 Subject: VxWorks users' group I'm interested in joining the VxWorks users' group -- What do I do? Thanks for your help --Jens Quistgaard pk5685@max.u.washington.edu From mea@sparta.com Mon Jan 20 11:29:25 1992 From: mea@sparta.com (Mike Anderson) Date: Mon Jan 20 11:29:32 PST 1992 Subject: Re: MMU Usage Greetings! All of the mentioned targets (with the possible exception of option 4) seem interesting. However, my question with regards to the use of MMUs in real-time systems is "How much does it cost?". This means not only the $$ required to implement, but also the time hit on context switches, memory accesses, etc. required for the MMU to do its thing. If the MMU can do these things in 10s of nanoseconds, then I'm all for it. On the other hand, if it takes 10s of microseconds, then I wonder. My opinion is that a late answer is a wrong answer. I've also seen many e-mail messages from folks who are struggling with the SPARC 1E MMUs. These messages lead me to believe that MMUs could be more trouble than they're worth given the days of lost time trying to figure out how to get a board to even boot let alone run with the MMU. Granted, I'd love to have a mechanism that would protect my code against errant pointers, stack overflows, bad programmers and the like. Who wouldn't if we can get it for free ;-). I'd also be supportive of MMU support in VxWorks if I had a #define that would allow me to turn it off for really time-critical applications. If it were my money, I'd rather see a good interprocessor communications mechanism ala pSOS+M than an MMU implementation. That would help me with the 683XX, 68E030, i960 and few other CPUs as well. So much for my $0.02 ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM 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, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From hmp@frc2.frc.ri.cmu.edu Tue Jan 21 07:01:27 1992 From: hmp@frc2.frc.ri.cmu.edu (Henning M. Pangels) Date: Tue Jan 21 07:01:34 PST 1992 Subject: Fdtos and Fstod under 5.0.2 We've run into a situation here where an application being ported to 5.0.2 wants the OS to supply the symbols Fdtos and Fstod, which are not there under 5.0.2. After some poking around, I've come up with some clues: It seems that before the GNU cross-building tools became the default, i.e. pre-5.0.2, a kernel build on a Sun3 would pull in the native libc.a from the sun. This was specified in the Makefile by the HOST_LIB macro, and the sun3's libc.a contains Fdtos and Fstod. In the new Makefile, you'll find HOST_LIB = $(HOST_LIB_MC68020) but HOST_LIB_MC6802 is not defined anywhere that I can see. My guess is that WRS moved the C support functions into the main library (all.a, perhaps) but forgot the modules Fdtos and Fstod. Can anyone confirm this theory or blast it to pieces with the right explanation? -Henning Henning Pangels | hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer | (412) 268-7088 | Carnegie-Mellon University ------------------------------------------------------------------------------ The Door is a Jar From kent@wrs.com Tue Jan 21 12:15:48 1992 From: kent@wrs.com (Kent Long) Date: Tue Jan 21 12:15:55 PST 1992 Subject: Re: Fdtos and Fstod under 5.0.2 Hi, Folks - Henning M. Pangels writes: > > We've run into a situation here where an application being ported to > 5.0.2 wants the OS to supply the symbols Fdtos and Fstod, which are > not there under 5.0.2. > > It seems that before the GNU cross-building tools became the default, i.e. > pre-5.0.2, a kernel build on a Sun3 would pull in the native libc.a > from the sun. This was specified in the Makefile by the HOST_LIB > macro, and the sun3's libc.a contains Fdtos and Fstod. This is correct. In all VxWorks that used the native Sun tools (including the Sun4-based cross-compiler), floating point functions were obtained by linking with Sun libraries. However, with 5.0.1 (the first Gnu tools version), this was no longer an option. The floating point library calls generated by gcc are completely different than those from the Sun native compiler. So, a completely new floating point library was included with VxWorks. This library should provide a full set of subroutines for gcc- compiled code. > > My guess is that WRS moved the C support functions into the main library > (all.a, perhaps) but forgot the modules Fdtos and Fstod. Well, these names appear to be Sun floating point routines, not gcc style. (Corresponding gcc names might be "truncdfsf2" and "extendsfdf2".) From this, I would assume that the code has not been recompiled under gcc. There are two options: 1. Recompile the code using gcc. This would be my first choice, since it eliminates any reliance on the now-obsolete Sun libraries, and in the long run will make maintenance more straight forward. 2. Link the application modules with /usr/lib/libc.a directly on the Sun host, leaving a relocatable object. That can then be loaded or linked with VxWorks. This second alternative will also work for folks who want to use the Sun3 Fortran compiler, etc. Good luck, - kent Kent Long Wind River Systems kent@wrs.com From steele@telerobotics.jpl.nasa.gov Tue Jan 21 15:11:29 1992 From: steele@telerobotics.jpl.nasa.gov (Rob Steele) Date: Tue Jan 21 15:11:35 PST 1992 Subject: questions from JPl We are using vxWorks on Heurkion 68020 boards in a VME chassis. We have 6 of the boards in the one chassis. Does anyone have an answere to one or more of the following questions: 1. Is it possible to set our system up so we boot and execute downloads via a Bit-3 interface to our Sun4 instead of the Ethernet connection we are currently using. 2. Is there a known fix for the memory leakage problem when download a second image of an executable after the first one crashes. 3. (related to 2) Is there a software mechanism to reinitialize a board. 4. Does anyone have experiencing using an oscilloscope to perform timing estimates of software running on the Heurikon boards. Rob Steele steele@telerobotics.jpl.nasa.gov From visicom!VisiCom.COM!trest@nosc.mil Tue Jan 21 21:27:19 1992 From: Mike Trest Date: Tue Jan 21 21:27:26 PST 1992 Subject: Re: questions from JPl Rob >>2. Is there a known fix for the memory leakage problem when download a >> second image of an executable after the first one crashes. I assume "memory" leakage is loss of memory occupied by first copy of program when second ld < pgm.o is run. We use several techniques: A. Early on we used a unload command in which we chase the symbol table for the primary "txt" and "data" segments related and free them. We had no really easy to chase all variables in the symbol table as well. B. Today we use a wrapper around the loadModuleAt command and load NO symbols, only GLOBAL symbols, or ALL symbols depending on the task. We continue to unload the "txt" and "data" via the original symbol table lookup and free approach. >>3. (related to 2) Is there a software mechanism to reinitialize a board. I do not now use the Heurikon 020 boards you referenced. But I do use software to re-initialize boards from Performance Technologies Inc, FORCE, and MOTOROLA. The technique varies but generally reboot(2) does the trick for a complete reboot of the board via BOOT from ROM. >>4. Does anyone have experiencing using an oscilloscope to perform timing >> estimates of software running on the Heurikon boards. I have done this by inserting an otherwise un-needed movement of the UART handshake line (DTR,RTS or the like) and probing at the external serial interface pin. I have also tied this line to Freq Counter and to detect variations in averaged over longer periods than could be detected by a scope probe and a few samples. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== From @surname.draper.com,@ccfvx3.draper.com:lacy@coyote.draper.com Wed Jan 22 04:50:50 1992 From: Carl Lacy Date: Wed Jan 22 04:50:58 PST 1992 Subject: Sparc 1E Comments Has anyone experience with Force's Sparc 1E processor? We are thinking of getting a few, initially using VxWorks or SunOS/1E, depending on the context. There is some fuzzyness in Force's literature about whether the VxWorks port is planned or real. From visicom!VisiCom.COM!trest@nosc.mil Wed Jan 22 08:11:25 1992 From: Mike Trest Date: Wed Jan 22 08:11:31 PST 1992 Subject: Re: Sparc 1E Comments I have used the Force Sparc processor under VxWorks and recommend them highly to my customers. Earlier, version 5.0.x was not available for it. It is now available. ..mike.. From mea@sparta.com Wed Jan 22 08:21:49 1992 From: mea@sparta.com (Mike Anderson) Date: Wed Jan 22 08:21:58 PST 1992 Subject: Re: Sparc 1E Comments Greetings! I'm not sure of other folks experiences with the SPARC 1E boards, but I've had a very lukewarm response to the SPARC 1E. First, the ones I've used where from Sun not from Force, but I understand that they're essentially the same board. Second, although they seem to run SunOS fine, I've been collecting all of the mail from folks using the 1E for VxWorks, and as a VxWorks platform the 1E apparently leaves much to be desired. A few points that have come up: -- The 1E is locked at bus grant level 3. This means that more than 3-4 boards in a backplane that are heavy users of the bus pose an arbitration problem leading to bus errors, failure of the cards down the daisy chain to boot and a whole host of other bugs. Remember that the 1E was designed to be the only processor on the backplane (i.e., multi-CPU systems were not on Sun's mind when they built the card). However, I am hopeful that Force's SPARC 2E board will be designed to better allow for multi-processing (although this might conflict with Sun's 600MP processor line and Sun might therefore require Force to produce a hobbled card so as not to compete with this new line). -- The bus speeds of the 1E are dismally slow. 32-bit transfers are rated at about 6MB/s. 8-bit transfers are less than 2 MB/s. Since the speed of multi-processor systems is largely limited by the slowest board on the bus, it would seem to me that a 1E represents a significant bottleneck in the system. -- Many users seem to be having lots of trouble with the 1E MMU under VxWorks. I've got a dozen messages from people struggling to deal with the 1E MMUs just to get the boards to boot. Also, I'm not sure whether the on-board SBUS slot is a plus or a minus. My experience with adding Sun's 64MB RAM card through this interface was not pleasant. The lack of a VSB interface also limits the board's ability for high-speed CPU<->CPU transfers. -- Of course, if the goal of the 1E board is simply to run SunOS to boot boards from and to provide disk service, then I would also suggest a different course of action. Running a UNIX CPU with such a slow bus interface in a real-time (i.e., ideally, deterministic) backplane seems to be a contradiction in terms. I would instead suggest a setup similar to AP Labs' VxWorks box where a SPARC 2 motherboard in mounted inside the chassis to provide the user interface and disks but kept off of the VMEBus. Or, you could also buy the OPUS Systems OPUSEngine SPARC motherboard and use that if you didn't want to buy a Sun SPARCStation and gut the box. I have seen several vendors using this approach. -- Finally, there is the cost of the SPARC 1E. My Sun reseller's guide still shows the 1E price at $9,000 each minimum quantity 3. Now there is an OEM discount associated with the board and you might be able to purchase them in quantities less than 3 from Force, but the bottom line is that these boards are still expensive when compared to 68Ks or i960s. Even more so when you consider that you're paying 25-50% more for a 12 MIP 1E than you're paying for a 20 MIP SPARCStation ELC and with the ELC you're getting a monitor keyboard and mouse as well. -- Don't get me wrong. I applaud WRS for porting VxWorks to the SPARC environment. I think that it might be a neat idea, for instance, to be able to run VxWorks as the native O/S on a SPARCStation 2 workstation. Coupled with WindX or Visicom's X-Windows solutions you'd have an incredible single user data acquisition station with a nice interactive display capability. Alternatively, if the SPARC manufacturers (Force, Ironics and Mizar to date) could come up with a good VME implementation targeted at real-time, multi- processing systems at a reasonable price, I'd be happy to incorporate them into both my company's and my customer's designs. In short, one can always hope that the new 2E will be better ;-). ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM 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, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From kibrick@helios.ucsc.edu Wed Jan 22 09:38:45 1992 From: "Bob Kibrick -- kibrick@helios.ucsc.edu" Date: Wed Jan 22 09:38:51 PST 1992 Subject: Re: Sparc 1E Comments The Sparc 1E from Force is interchangeable with that made by Sun. We have been running the identical vxWorks 4.0.2 and 5.0.2b on Sparc 1E's made by both Force and Sun and find no differences. Bob Kibrick UCO/Lick Observatory University of California Santa Cruz, CA 95064 kibrick@helios.ucsc.edu From diarra@borsu6.in2p3.fr Wed Jan 22 09:59:00 1992 From: diarra@borsu6.lbl.gov (Christophe Vinima 399) Date: Wed Jan 22 09:59:12 PST 1992 Hi ! Could you please add me to the VxWorks User's Group... Christophe Diarra. diarra@borsu6.in2p3.fr ========================================================= #### ###### # # ##### #### # # # ## # # # # # # ##### # # # ##### # # # # # # # # # ### # # # # ## # # # # #### ###### # # ##### #### FRANCE Centre d' Etudes Nucleaires de Bordeaux Gradignan ========================================================= "Tout doit etre aussi simple que possible, pas seulement plus simple" A. Einstein ========================================================= Christophe Diarra Voice : +33 56891800 C.E.N.B.G. Fax : +33 56751180 Le Haut Vigneau Email : diarra@borsu6.in2p3.fr 33175 Gradignan cedex FRANCE ========================================================= From rasolofo@borsu6.in2p3.fr Wed Jan 22 10:02:03 1992 From: rasolofo@borsu6.lbl.gov (Heriniaina Rasolofo) Date: Wed Jan 22 10:02:10 PST 1992 Hi folks ! Please add me to the VxWorks User's Group. Thanks. H. Rasolofo. rasolofo@borsu6.in2p3.fr ========================================================= #### ###### # # ##### #### # # # ## # # # # # # ##### # # # ##### # # # # # # # # # ### # # # # ## # # # # #### ###### # # ##### #### FRANCE Centre d' Etudes Nucleaires de Bordeaux Gradignan ========================================================= "Tout doit etre aussi simple que possible, pas seulement plus simple" A. Einstein ========================================================= Heriniaina Rasolofo Voice : +33 56891800 C.E.N.B.G. Fax : +33 56751180 Le Haut Vigneau Email : rasolofo@borsu6.in2p3.fr 33175 Gradignan cedex FRANCE ========================================================= From stan@rti.com Wed Jan 22 11:09:30 1992 From: stan@rti.com (Stan Schneider) Date: Wed Jan 22 11:09:41 PST 1992 Subject: Re: questions from JPl steele@telerobotics.jpl.nasa.gov writes: >> >> 4. Does anyone have experiencing using an oscilloscope to perform timing >> estimates of software running on the Heurikon boards. >> >> Depending on what you mean by "timing estimates", StethoScope's new "Profile" module might be able to help you out. It's out in beta test now; I could send you an advance copy... A snippet from the man pages: DESCRIPTION Profile is a dynamic execution profiler for use with VxWorks and StethoScope. It allows monitoring the execution flow of VxWorks programs on a procedure-by-procedure basis. Profile allows a systems programmer to analyze exactly how a VxWorks program is utilizing the processor. Profile works by sampling the execution state (both program counter and stack). The sampling is done by an interrupt service routine. These ``random'' samples are then analyzed by a low-priority background task to determine which rou- tines were active at the time of the sample. The output of the analysis procedure is used to keep a dynamic record of the system activity. The output consists of a "frequency" for each routine. Frequencies are the fraction of time spent in that routine, and are normally within the range 0.0 (never active) to 1.0 (always active). Both current and cumulative frequencies are reported. The current frequencies of procedures may be installed as signals to StethoScope, letting you watch how your system is using the CPU in real-time. Perhaps more importantly, StethoScope may be used to monitor the profiler progress, detect conditions that would give inaccurate results, and explore the system reaction to events. Together, Profile and StethoScope allow a much more accurate picture of the system's activities than either could provide alone. Profile is designed for minimal impact on the real-time code it analyzes. No special compilation is required. The sam- pling is quick and efficient. The analysis uses the resident VxWorks symbol table to decide which procedure was active. Profile can therefore be used to analyze already running code. ... I'll provide more details to anyone 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 iphasew!hwajin@apple.com Wed Jan 22 13:09:57 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Wed Jan 22 13:10:04 PST 1992 Subject: RE: Fdtos and Fstod under 5.0.2 >>>>> On Wed, 22 Jan 92 04:00:08 PST, Kent Long said: Kent> Well, these names appear to be Sun floating point routines, not Kent> gcc style. (Corresponding gcc names might be "truncdfsf2" and Kent> "extendsfdf2".) From this, I would assume that the code has not Kent> been recompiled under gcc. Perhaps I'm missing something, but don't truncdfsf2 and extendsfdf2 come from gnulib.c ? Since gnulib.c is supposed to be compiled with a native C compiler when building gcc, they will reference native library calls, namely Fdtos and Fstod. I thought the whole point of compiling gnulib.c with native compiler (e.g. Sun's) was to use the routines in the native C library. Since compiling gnulib.c with gcc results in cyclic calls to the callers themselves, I assume that the gcc distributed by WRS doesn't do this. Which leads me to believe that either WRS is providing their own replacement routines for the Sun routines, or require linking with Sun's libc.a, or WRS is providing their own replacement for gnulib routines. I'm curious because it *is* possible for gcc compiled code to reference routines from native libc.a. Anyone care to enlighten me? From srm%matrx@mcnc.org Wed Jan 22 13:14:58 1992 From: srm@matrx.matrix.com (Steve Morris) Date: Wed Jan 22 13:15:07 PST 1992 Subject: scsiLib and the CPU-1E (aka SPARC-1E) Does VxWorks 5.0.2b for the CPU-1E support (on-board) SCSI via scsiLib ? Has anyone used it? Thanks, Steve From hali@interactive.com Wed Jan 22 18:11:06 1992 From: hali@interactive.com (Hali Lindbloom) Date: Wed Jan 22 18:11:13 PST 1992 Subject: .profile file Has anyone else experienced the following problem and/or has any insight into it: When we create a .profile file in the home directory of the user as which our board is logging into the host, the board can no longer boot properly. It reports a bus error after partially loading VxWorks. The only thing in the .profile is the setting and exporting of environment variables. I know that a .cshrc can mess up a board's booting if it causes any standard output, but this seems like something else. Thanks for any help! Hali Lindbloom Interactive Network (415) 903-4052 hali@interactive.com From thor@surt.atd.ucar.edu Thu Jan 23 07:12:53 1992 From: thor@surt.atd.ucar.edu (Richard Neitzel) Date: Thu Jan 23 07:13:00 PST 1992 Subject: Tp41V & VME addresses We've got a Tadpole TP41V under 5.0.2. Unfortunately, we cannot make it access any off board addresses. I know about the 3 paging bits, but they don't seem to have any effect. I have 2 boards, one at 0x20000000 & one at 0x2000000. According to what we understand, they should therefore be addressed by the TP41 as 0xa0000000 and 0xa2000000 respectively. The paging bits should then be 0x1 for the first board & 0x0 for the second. However, cycling through all 8 posssible cases makes no difference. Are there other CIO bits that must be changed before this can work? What are we doing wrong? 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. From visicom!VisiCom.COM!trest@nosc.mil Thu Jan 23 11:11:10 1992 From: Mike Trest Date: Thu Jan 23 11:11:17 PST 1992 Subject: Re: Tp41V & VME addresses Richard: >>We've got a Tadpole TP41V under 5.0.2. Unfortunately, we cannot make >>it access any off board addresses. The TP41-V with our VX-SERVER references the video frame buffer off card with no difficulty. We also have mixed TP41-V and FORCE cpu cards in the same chassis talking. We did re-compile the distribution vxWorks to add envoronmental variables used by the server, otherwise nothing exotic. The video card is in STD address space so all references off the TP41 must be adjusted with sysBusToLocalAdrs(); The server has a line like this buried in the device dependent portion which determines the TP41's address for the frame buffer as: char *fb; ... sysBusToLocalAdrs(VME_AM_STD_USR_DATA,videoVmeAddr,&fb); ... return( fb ); ONE WAY TO KNOW FOR SURE is to do something like the following on each card: whereOnBus(localAddress) char *localAddress; { char *onBusAt; if (sysLocalToBusAdrs( VME_AM_EXT_SUP_DATA, localAddress,&onBusAt) == OK) printf("LocalAddress 0x%x on VME 0x%x\n", localAddress,onBusAt); else printf("ERROR!\n"); } This will tell you the TP41's opinion of his own address on the bus. Card 1 should use card 2's address (and vice-versa). ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== From biocca@bevsun.bev.lbl.gov Thu Jan 23 11:26:00 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Jan 23 11:26:07 PST 1992 Subject: contract consultant needed Jeff Gold at United Source Services is looking for a Diagnostic Software Engineer. The six month contract with a Sunnyvale firm to develop ASIC/VLSI diagnostic software in the Sun workstation/vxWorks environment in C requires working with hardware engineers, writing test specifications, etc. Contact Jeff at 818-991-2277. I have no connection with these firms. Alan K Biocca From brancato@hercules.calspan.com Thu Jan 23 12:32:21 1992 From: brancato@hercules.calspan.com (Tony Brancato) Date: Thu Jan 23 12:32:28 PST 1992 Subject: VME to GPIB interface boards under VxWorks 5.0 Does anyone have experiences with VME-to-GPIB interface boards that they would mind sharing? We are building an RF simulation system and are using an HP8902A measuring receiver and an HP voltmeter to perform diagnostics and calibration. We'd like to write software to control the voltmeter and measuring receiver from the main CPU over the GPIB. The system is built around a Motorola M147 VME CPU board running VxWorks 5.0 (as part of VADS 2.0.1c). We have looked at an interface board from American Eltec, and found that their driver would not arbitrate service requests from the GPIB. Specifically, if a command was sent which caused a service request and the controller attempted to talk to the requesting node before the request was handled, the driver would hang because the requesting node would never respond. Is this normal for these types of boards, or do other drivers detect and handle this condition? We also have the driver for the MZ7500 board from Mizar, but have not had a chance to look at it yet. Any suggestions, impressions, or past experiences about quality of product and support are appreciated. Thanks in advance. -- Tony Brancato Calspan Corporation ATC Buffalo, NY ...!uupsi!calspan!brancato brancato@calspan.com From bobf@verdix.com Thu Jan 23 12:39:49 1992 From: Bob Foery Date: Thu Jan 23 12:39:55 PST 1992 Subject: Re: contract consultant needed > Jeff Gold at United Source Services is looking for a Diagnostic Software > Engineer. The six month contract with a Sunnyvale firm to develop ASIC/VLSI ^^^^^^^^^^^^^^^^^^ > diagnostic software in the Sun workstation/vxWorks environment in C > requires working with hardware engineers, writing test specifications, etc. > Contact Jeff at 818-991-2277. Sounds pretty neat, eh? From kadionik@borsu6.in2p3.fr Thu Jan 23 13:39:57 1992 From: kadionik@borsu6.lbl.gov (Patrice Kadionik) Date: Thu Jan 23 13:40:05 PST 1992 Subject: Love Love is a wondering feeling... From hmp@frc2.frc.ri.cmu.edu Thu Jan 23 14:56:23 1992 From: "Henning M. Pangels" Date: Thu Jan 23 14:56:32 PST 1992 Subject: Re: Love -- On Thu, 23 Jan 92 13:40:19 PST, you wrote: > > >Submitted-by kadionik@borsu6.in2p3.fr Thu Jan 23 13:39:57 1992 >Submitted-by: kadionik@borsu6.lbl.gov (Patrice Kadionik) > >Love is a wondering feeling... Ya, but is there a public domain package available for it? :-) Henning Pangels | hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer | (412) 268-7088 | Carnegie-Mellon University ------------------------------------------------------------------------------ It's later than you think From scr@uk.ate.slb.com Fri Jan 24 00:00:15 1992 From: scr@uk.ate.slb.com Date: Fri Jan 24 00:03:40 PST 1992 Subject: Re: VME to GPIB interface boards under VxWorks 5.0 > > Submitted-by brancato@hercules.calspan.com Thu Jan 23 12:32:21 1992 > Submitted-by: brancato@hercules.calspan.com (Tony Brancato) > > Does anyone have experiences with VME-to-GPIB interface boards that they > would mind sharing? ....... Tony, Have you looked at National Instruments' product range. They have a number of VME / IEEE interface cards. Contact them at :- 6504 Bridge Point Parkway Austin Texas 76730-5039 Tel: (512) 794-0100 Fax: (512) 794-8411 Stephen. -------------------------------------------------------------------- Stephen Rothwell, | email : Schlumberger Technologies, | rothwell%ukfca1@sj.ate.slb.com Ferndown Industrial Estate, | Wimborne, | phone : Dorset, BH21 7PP | +44-202-893535 England. | ------------------------------------------------------------------- From biocca@bevsun.bev.lbl.gov Fri Jan 24 08:00:51 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Fri Jan 24 08:01:03 PST 1992 Subject: comp.os.vxworks articles Comp.os.vxworks lives! Here's the current article set (hand collected, the exploder to news link is working in a test group at lbl, but the news to exploder link isn't up yet...) Alan K Biocca From dog.ee.lbl.gov!pasteur!ames!elroy.jpl.nasa.gov!usc!wupost!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells Fri Jan 24 08:00:14 PST 1992 Article: 3 of comp.os.vxworks Newsgroups: comp.realtime,comp.os.vxworks Path: dog.ee.lbl.gov!pasteur!ames!elroy.jpl.nasa.gov!usc!wupost!darwin.sura.net!uvaarpa!cv3.cv.nrao.edu!cv3.cv.nrao.edu!dwells From: dwells@fits.cx.nrao.edu (Don Wells) Subject: C++ class library for RT? Message-ID: Sender: news@nrao.edu Organization: National Radio Astronomy Observatory, Charlottesville, VA Distribution: comp Date: Wed, 15 Jan 1992 18:02:06 GMT Lines: 10 Xref: dog.ee.lbl.gov comp.realtime:1973 comp.os.vxworks:3 Is there a C++ class library for RT applications under some RT OS? In particular, is there such a thing for VxWorks? -- Donald C. Wells Associate Scientist dwells@nrao.edu National Radio Astronomy Observatory +1-804-296-0277 520 Edgemont Road Fax= +1-804-296-0278 Charlottesville, Virginia 22903-2475 USA 78:31.1W, 38:02.2N From dog.ee.lbl.gov!overload.lbl.gov!agate!stanford.edu!rutgers!ub!acsu.buffalo.edu!usenet Fri Jan 24 08:00:16 PST 1992 Article: 2 of comp.os.vxworks Path: dog.ee.lbl.gov!overload.lbl.gov!agate!stanford.edu!rutgers!ub!acsu.buffalo.edu!usenet From: jones@acsu.buffalo.edu (Terry A. Jones) Newsgroups: comp.os.vxworks Subject: This is a test... Message-ID: <1992Jan15.184722.26046@acsu.buffalo.edu> Date: 15 Jan 92 18:47:22 GMT Sender: usenet@acsu.buffalo.edu Organization: State University of New York at Buffalo/Comp Sci Lines: 7 Nntp-Posting-Host: cursa.cs.buffalo.edu This is a test....like the Subject line says. Any ideas when the exploder will be connected to the news group? Terry Jones From dog.ee.lbl.gov!biocca Fri Jan 24 08:00:17 PST 1992 Article: 4 of comp.os.vxworks Path: dog.ee.lbl.gov!biocca From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Newsgroups: comp.os.vxworks Subject: Connecting list to newsgroup Date: 15 Jan 1992 23:46:52 GMT Organization: Lawrence Berkeley Laboratory, California Lines: 11 Message-ID: <20658@dog.ee.lbl.gov> References: <1992Jan15.184722.26046@acsu.buffalo.edu> NNTP-Posting-Host: 131.243.192.12 In article <1992Jan15.184722.26046@acsu.buffalo.edu> jones@acsu.buffalo.edu (Terry A. Jones) writes: > Any ideas when the exploder will be connected to the news group? As soon as I get things working. Perhaps a couple of weeks, depending on workload.. Anyone have a robust program that collects news from a specific newsgroup and puts it into a pipe or files or ...?? I picked up one from the new awhile back but it is buggy... Alan K Biocca Exploder Maintainer From dog.ee.lbl.gov!network.ucsd.edu!pacbell.com!ames!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmail!randyw Fri Jan 24 08:00:19 PST 1992 Article: 5 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!pacbell.com!ames!elroy.jpl.nasa.gov!usc!zaphod.mps.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmail!randyw From: randyw@iplmail.orl.mmc.com (Randy Walker) Subject: targeting custom boards Message-ID: <1992Jan15.213120.19694@iplmail.orl.mmc.com> Keywords: SPARC, custom Sender: randyw@iplmail (Randy Walker) Organization: Martin Marietta Date: Wed, 15 Jan 1992 21:31:20 GMT Our team recently targeted VxWorks to a SPARC based processing board which was designed in-house. We ran into problems while integrating an Ethernet driver. We needed information about the VxWorks network communication layers of software so that we could interface our software. We experienced great difficulty in getting support from Wind River. It seems that their customer support organization was either not capable or not willing to answer questions of this sort. Finally, Wind River told us that they would not support the targeting of VxWorks to custom hardware through their normal customer service. We were told that we had three options: 1. We could buy their source code. ( no guarantees of support ) 2. We could pay for a Wind River consultant to come to our site and help us. 3. We could pay Wind River to write custom software for us. I am curious about other groups' experiences in targeting VxWorks to custom hardware. Also, do other groups expect to try this in the future? If enough pressure is applied to Wind River, maybe they will be more flexible in the future. Sales can be won and lost over supporting a customer's needs. From dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!uwm.edu!zazen!uwvax!meteor!scrap.ssec.wisc.edu!bt Fri Jan 24 08:00:20 PST 1992 Article: 8 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!hellgate.utah.edu!caen!zaphod.mps.ohio-state.edu!uwm.edu!zazen!uwvax!meteor!scrap.ssec.wisc.edu!bt From: bt@scrap.ssec.wisc.edu (Bill Taylor) Subject: Re: targeting custom boards Message-ID: <1992Jan16.170247.8042@meteor.wisc.edu> Keywords: SPARC, custom Sender: @meteor.wisc.edu Organization: Space Science and Engineering Center, UW Madison References: <1992Jan15.213120.19694@iplmail.orl.mmc.com> Date: Thu, 16 Jan 92 17:02:47 GMT In article <1992Jan15.213120.19694@iplmail.orl.mmc.com>, randyw@iplmail.orl.mmc.com (Randy Walker) writes: |> |> Our team recently targeted VxWorks to a SPARC based processing board |> which was designed in-house. We ran into problems while integrating |> an Ethernet driver. We needed information about the VxWorks network |> communication layers of software so that we could interface our software. |> Unitl almost 2 years ago I worked for Heurikon. As a leading supplier for VxWorks even we had problems like that. When Heurikon's Intel 960 board was new, They had to do most of the VxWorks work even though hardware for this was supplied to WindRiver. Policy developed over time to support their(Heurikon's) customer's inhouse after having each customer buy a development kit with many sources to minimize support issues. |> We experienced great difficulty in getting support from Wind River. |> It seems that their customer support organization was either not capable |> or not willing to answer questions of this sort. |> I think they are stretched(or were) pretty thin like most people in a growing market with a good product. I still think its a good product for software development. |> Finally, Wind River told us that they would not support the targeting of |> VxWorks to custom hardware through their normal customer service. We |> were told that we had three options: |> |> 1. We could buy their source code. ( no guarantees of support ) |> |> 2. We could pay for a Wind River consultant to come to our site and |> help us. |> |> 3. We could pay Wind River to write custom software for us. |> |> This is not a bad response. If you were designing a board for this application you could have found out which ethernet chips set they support, and chosen one. It may not have been "ideal", but it would have been cheaper in time and $. |> |> I am curious about other groups' experiences in targeting VxWorks to |> custom hardware. Also, do other groups expect to try this in the future? |> If enough pressure is applied to Wind River, maybe they will be more |> flexible in the future. Sales can be won and lost over supporting a |> customer's needs. Unfortunately they make BIG $$ on each customer from places like above mentioned firm, and Force, Sun, Mizar, etc...... The number of $$ generated from in house hardware is relatively small. At least you could port the basic product. I once tried to get Word Perfect for Heurikon's Unix Systems. The sales folks there said for less than several million dollars they really couldn't be bothered. Good luck.... Isn't engineering fun? From dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!batcomputer!cornell!rochester!rocksanne!thingy!leisner Fri Jan 24 08:00:21 PST 1992 Article: 13 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!batcomputer!cornell!rochester!rocksanne!thingy!leisner From: leisner@thingy.henr801@xerox.com (Marty Leisner x76704 siena) Subject: Re: targeting custom boards Message-ID: <1992Jan19.222735.15679@spectrum.xerox.com> Keywords: SPARC, custom Sender: news@spectrum.xerox.com Organization: Xerox References: <1992Jan15.213120.19694@iplmail.orl.mmc.com> <1992Jan16.170247.8042@meteor.wisc.edu> Date: Sun, 19 Jan 1992 22:27:35 GMT In article <1992Jan16.170247.8042@meteor.wisc.edu> bt@scrap.ssec.wisc.edu (Bill Taylor) writes: > >Good luck.... Isn't engineering fun? Whoever said software is engineering? marty leisner leisner.henr801c@xerox.com From dog.ee.lbl.gov!nosc!manta!psm Fri Jan 24 08:00:23 PST 1992 Article: 6 of comp.os.vxworks Path: dog.ee.lbl.gov!nosc!manta!psm From: psm@manta.NOSC.MIL (Scot Mcintosh) Newsgroups: comp.os.vxworks Subject: Rumor regarding Ada Keywords: Ada, Verdix Message-ID: <2615@manta.NOSC.MIL> Date: 16 Jan 92 18:15:28 GMT Organization: Naval Ocean Systems Center, San Diego Lines: 11 I've heard a rumor that Verdix will no longer be offering an Ada product that runs with vxWorks. Supposedly, they'll be furnishing their own operating system. I've also heard that Wind River is talking with Telesoft about furnishing Ada. Anyone know the real story? ---- Scot McIntosh Internet: psm@helios.nosc.mil UUCP: {ihnp4,akgua,decvax,decwest,ucbvax}!sdscvax!nosc!psm "It's not a bug, it's a limitation" - Microsoft Tech Assistant From dog.ee.lbl.gov!network.ucsd.edu!ames!elroy.jpl.nasa.gov!usc!rpi!zaphod.mps.ohio-state.edu!wupost!uunet!dove!dove.nist.gov!przemek Fri Jan 24 08:00:24 PST 1992 Article: 7 of comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!ames!elroy.jpl.nasa.gov!usc!rpi!zaphod.mps.ohio-state.edu!wupost!uunet!dove!dove.nist.gov!przemek From: przemek@rrdstrad.nist.gov (Przemek Klosowski) Newsgroups: comp.os.vxworks Subject: VxWorks running VME experimental hardware Message-ID: Date: 16 Jan 92 19:20:06 GMT Sender: news@dove.nist.gov Organization: U. Notre Dame/NIST Lines: 28 Hello! We are currently considering moving from CAMAC crates controlled by VMS Vaxes to VME hardware ran by in-crate controllers under VxWorks, interfaced with Unix hardware (currently Ultrix, but this may change). Our application is experimental data collection, so our VME modules are histogramming memories, scalers, counters etc. I have couple of questions to you: - Does VME look like a good choice for the task (we need the speed, but I have heard that controlling it is tricky) - How well does VxWorks support running the VME stuff? By looking through the manual I did not notice system calls dealing with VME transactions. How does one run a particular hardware device? do we need drivers from each VME module manufacturer? if yes, how easy is it to get a good quality drivers working under VxWorks? We were told that it might be the problem, and that we might have to write the drivers ourselves. How hard is it to write a VxWorks device driver? - How tightly is the VxWorks tied to a particular development platform? is it conceivable to initially develop stuff from workstation A on target B and then process the data collected by the standalone target over the network to various hosts C? Thanks for the info. Please feel free either to post or to e-mail, and I'll summarize in a little while if there is sufficient response. Please also suggest some other appropriate newsgroups where those questions could be also appropriate. -- przemek klosowski (przemek@ndcvx.cc.nd.edu) Physics Department University of Notre Dame IN 46556 From dog.ee.lbl.gov!network.ucsd.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!THD-News!adams Fri Jan 24 08:00:25 PST 1992 Article: 10 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!usc!cs.utexas.edu!qt.cs.utexas.edu!yale.edu!ira.uka.de!THD-News!adams From: adams@pdv2.fmr.maschinenbau.th-darmstadt.de (Adams) Subject: Re: VxWorks running VME experimental hardware Sender: news@infoserver.th-darmstadt.de (The Usenet-News System) Message-ID: In-Reply-To: przemek@rrdstrad.nist.gov's message of 16 Jan 92 19: 20:06 GMT Date: Sat, 18 Jan 1992 02:23:19 GMT References: Nntp-Posting-Host: pdv2.fmr.maschinenbau.th-darmstadt.de Organization: TH-Darmstadt Lines: 50 In article przemek@rrdstrad.nist.gov (Przemek Klosowski) writes: > Hello! > We are currently considering moving from CAMAC crates controlled by VMS Vaxes > to VME hardware ran by in-crate controllers under VxWorks, interfaced with > Unix hardware (currently Ultrix, but this may change). Our application is > experimental data collection, so our VME modules are histogramming memories, > scalers, counters etc. I have couple of questions to you: We run similiar tasks together with control tasks on VME-Bus hardware under pSOS interfaced over shared memory with an Unix host (SysV68). > - Does VME look like a good choice for the task (we need the speed, but > I have heard that controlling it is tricky) Other faculties and we run similiar setups successfully since years. Nuclear Physics run their linear accelarator with VME-Bus harddware under pSOS. It is even comparable easy to build your own VME-Bus hardware, a couple of companies offer interface chips etc. > - How well does VxWorks support running the VME stuff? By looking through > the manual I did not notice system calls dealing with VME transactions. > How does one run a particular hardware device? do we need drivers from > each VME module manufacturer? if yes, how easy is it to get a good quality > drivers working under VxWorks? We were told that it might be the problem, and that we might have to write the drivers ourselves. How hard is it to > write a VxWorks device driver? We do not use VxWorks --- no glue. All peripherals are seen memory mapped on the VME-Bus. No system calls are necessary to initiate transcactions. Transactions (atomic read/writes) should be handled properly by the hardware, lock via BBUSY* - line. In the past, problems occured at this point. Writing device drivers was never fancy stuff, but as the OS provides signals, events and queues, it is not as hard as most will fear. > - How tightly is the VxWorks tied to a particular development > platform? is it conceivable to initially develop stuff from > workstation A on target B and then process the data collected by > the standalone target over the network to various hosts C? GNU-gdb 4.3 allows remote debugging of VxWorks targets. Nuclear Physics run a setup comparable to that you described, but under pSOS. It is a common setup. best regards, adams From dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!ispd-newsserver!psinntp!ptsys1!rcw Fri Jan 24 08:00:27 PST 1992 Article: 9 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!usc!rpi!ispd-newsserver!psinntp!ptsys1!rcw From: rcw@ptsys1.pt.com (Ray Ward) Subject: Looking For General Info On VxWORKS Message-ID: <1992Jan16.203702.477@pt.com> Sender: rcw@pt.com (Ray Ward) Organization: Performance Technologies, Incorporated Date: Thu, 16 Jan 1992 20:37:02 GMT We are close to finishing the port of OS-9 to our line of single board computers. I am gathering information on doing a port of another operating system and am interested in VxWORKS. Would anyone who has any experience, good or bad, with VxWORKS please email me your experience(s). Please send any replies to: rcw@ptsys1.pt.com Thanks to all.... From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!cs.utexas.edu!uunet!fernwood!portal!exloghou!mcdowell Fri Jan 24 08:00:28 PST 1992 Article: 11 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!cs.utexas.edu!uunet!fernwood!portal!exloghou!mcdowell From: mcdowell@exloghou.exlog.com (Steve McDowell) Subject: Async Sockets Message-ID: <1992Jan18.024429.19937@exlog.com> Keywords: sockets, ipc, signals Sender: mcdowell@exlog.com (Steve McDowell) Organization: Exploration Logging, Inc. Date: Sat, 18 Jan 92 02:44:29 GMT Has anyone out there done any work in adding asyncronous socket support for VxWorks? Is the signalling mechanism too terribly unreliable (any more than UN*X)? With this glaring exception, WRS seems to have delivered a pretty complete implementation of BSD sockets....... -- Steve McDowell . . . . o o o o o Opinions are Exlog, Inc. _____ o mine, not my mcdowell@exlog.com _____==== ]OO|_n_n__][. employers.. [_________]_|__|________)< From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!usc!elroy.jpl.nasa.gov!ncar!hsdndev!adm!afterlife!smb Fri Jan 24 08:00:29 PST 1992 Article: 15 of comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!usc!elroy.jpl.nasa.gov!ncar!hsdndev!adm!afterlife!smb From: smb@afterlife.ncsc.mil (Steve M. Burinsky) Newsgroups: comp.os.vxworks Subject: Re: Async Sockets Keywords: sockets, ipc, signals Message-ID: <1992Jan20.165631.18648@afterlife.ncsc.mil> Date: 20 Jan 92 16:56:31 GMT References: <1992Jan18.024429.19937@exlog.com> Organization: The Great Beyond Lines: 8 VxWorks does not support any asynchronous I/O. However, AP Labs in San Diego, who does quite a bit of VxWorks development and integration, offers an asynchronous I/O library for VxWorks. I have not done business with them yet, but they seem to have a good reputation. -- Steve M. Burinsky smb@afterlife.ncsc.mil From dog.ee.lbl.gov!network.ucsd.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!netnews-2.srv.cs.cmu.edu!dac Fri Jan 24 08:00:30 PST 1992 Article: 12 of comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!rutgers!rochester!cantaloupe.srv.cs.cmu.edu!netnews-2.srv.cs.cmu.edu!dac From: dac@frc.ri.cmu.edu (Daniel Christian) Newsgroups: comp.os.vxworks Subject: SunOs+VxWorks on same VME bus? Message-ID: Date: 19 Jan 92 19:09:14 GMT Reply-To: dac@ri.cmu.edu (Dan Christian) Distribution: comp Organization: Field Robotic Center, CMU Lines: 16 Nntp-Posting-Host: locust.frc.ri.cmu.edu Does anyone have experience with running SunOs (on a SparcEngine xx) and real-time processors (68K, Sparc, i960) under VxWorks on the same VME bus? I have seen split bus setups that use still use ethernet to communicate; but I want to avoid TCP bottle necks. I know people were working on this, but I never found out if a workable system has been produced yet. Thanks, -Dan Christian -- ___________________________________________________________________________ Dan Christian Field Robotics Center Carnegie Mellon University (412) 268-6562 dac@ri.cmu.edu From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!news.cs.indiana.edu!lynx!chama.eece.unm.edu!ele Fri Jan 24 08:00:31 PST 1992 Article: 14 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!news.cs.indiana.edu!lynx!chama.eece.unm.edu!ele From: ele@chama.eece.unm.edu (Erik L. Ellis) Subject: Request for advice on error message Message-ID: <=1mg-xn@lynx.unm.edu> Date: Mon, 20 Jan 92 04:45:04 GMT Organization: University of New Mexico, Albuquerque Keywords: error messages Lines: 43 SYSTEM DESCRIPTION: I am running VxWorks on a Force CPU30 board which is controlling a Datacube image processing board (MaxVideo20). I am developing code on a Sun3 and porting the object code to the CPU30. THE PROBLEM: My program will run just fine until I attempt to exit the program. At this point, the system crashes with the message. workQPanic: Kernel work queue overflow. To get things working again, it's not enough to reboot. I actually have to power down the VME bus and restart. HELP REQUEST: As you may have guessed by the question, I am fairly new to VxWorks (and Datacube and Force hardware/software for that matter). I havn't been able to find much in the documentation to guide me. Any suggestions would be appreciated. Here is the end of my code (where the crash occurs). printf("type [Return] to freeze:\n"); getchar(); dqHaltPipe(oAcqPipe); printf("type [Return] to end program:\n"); getchar(); dqDisposeSys(oSystem); } The 1st printf works fine, but we never get to the 2nd one. The obvious guess is that something screws up in trying to halt the Acquisition Pipe. (dqHaltPipe is an ImageFlow/Datacube command, and, you guessed it, Datacube does not officially support VxWorks environments). Any idea what's going on? - Erik L. Ellis Dept. of EECE Univ. of New Mexico Albuquerque, NM From dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!spool.mu.edu!umn.edu!src.honeywell.com!whillock Fri Jan 24 08:00:33 PST 1992 Article: 16 of comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!sdd.hp.com!spool.mu.edu!umn.edu!src.honeywell.com!whillock From: whillock@src.honeywell.com (Rand Whillock) Newsgroups: comp.os.vxworks Subject: Re: Request for advice on error message Keywords: error messages Message-ID: <1992Jan21.163029.26957@src.honeywell.com> Date: 21 Jan 92 16:30:29 GMT Article-I.D.: src.1992Jan21.163029.26957 References: <=1mg-xn@lynx.unm.edu> Sender: news@src.honeywell.com (News interface) Organization: Honeywell Systems & Research Center Lines: 34 Nntp-Posting-Host: dienbienphu.src.honeywell.com In article <=1mg-xn@lynx.unm.edu> ele@chama.eece.unm.edu (Erik L. Ellis) writes: >SYSTEM DESCRIPTION: >I am running VxWorks on a Force CPU30 board which is controlling >a Datacube image processing board (MaxVideo20). I am developing >code on a Sun3 and porting the object code to the CPU30. > >THE PROBLEM: >My program will run just fine until I attempt to exit the program. >At this point, the system crashes with the message. > >workQPanic: Kernel work queue overflow. > ... > >Any idea what's going on? > >- Erik L. Ellis > Dept. of EECE > Univ. of New Mexico > Albuquerque, NM We have had a similar problem with our system running VxWorks on a MVME147 CPU with a Datacube Max20 in the system. We also had to power down to reset the boards. The problem went away when we installed the 5.0.2b bug fix sent out by Wind River. Good Luck, -- Rand Paul Whillock Phone: 612-782-7654 Signal Processing Systems Fax : 612-782-7438 Systems and Control Sciences Net : whillock@src.honeywell.com From dog.ee.lbl.gov!nosc!network.ucsd.edu!sdd.hp.com!wupost!uwm.edu!rutgers!ub!galileo.cc.rochester.edu!rochester!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!netnews.srv.cs.cmu.edu!hmp Fri Jan 24 08:00:35 PST 1992 Article: 17 of comp.os.vxworks Path: dog.ee.lbl.gov!nosc!network.ucsd.edu!sdd.hp.com!wupost!uwm.edu!rutgers!ub!galileo.cc.rochester.edu!rochester!cantaloupe.srv.cs.cmu.edu!crabapple.srv.cs.cmu.edu!netnews.srv.cs.cmu.edu!hmp From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Newsgroups: comp.os.vxworks Subject: Fdtos and Fstod under 5.0.2 Message-ID: Date: 21 Jan 92 15:00:09 GMT Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Lines: 25 Nntp-Posting-Host: deimos.frc.ri.cmu.edu We've run into a situation here where an application being ported to 5.0.2 wants the OS to supply the symbols Fdtos and Fstod, which are not there under 5.0.2. After some poking around, I've come up with some clues: It seems that before the GNU cross-building tools became the default, i.e. pre-5.0.2, a kernel build on a Sun3 would pull in the native libc.a from the sun. This was specified in the Makefile by the HOST_LIB macro, and the sun3's libc.a contains Fdtos and Fstod. In the new Makefile, you'll find HOST_LIB = $(HOST_LIB_MC68020) but HOST_LIB_MC6802 is not defined anywhere that I can see. My guess is that WRS moved the C support functions into the main library (all.a, perhaps) but forgot the modules Fdtos and Fstod. Can anyone confirm this theory or blast it to pieces with the right explanation? -Henning -- Henning Pangels | hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer | (412) 268-7088 | Carnegie-Mellon University ------------------------------------------------------------------------------ The Door is a Jar From dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes Fri Jan 24 08:00:36 PST 1992 Article: 18 of comp.os.vxworks Path: dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes From: heyes@dadev.cebaf.gov (Graham Heyes) Newsgroups: comp.os.vxworks Subject: Age old 800k vs 1400k problem... Message-ID: <1992Jan21.182100.29996@murdoch.acc.Virginia.EDU> Date: 21 Jan 92 18:21:00 GMT Sender: usenet@murdoch.acc.Virginia.EDU Reply-To: heyes@dadev.cebaf.gov (Graham Heyes) Organization: CEBAF (Continuous Electron Beam Accelerator Facility) Lines: 28 Last week I posted about a problem I was having with system 7 tune-up but got no replies. When printing with a tuned system 7.01 on a laserwriter SC my Mac+ locks up completely with the tune-up extension in the system. With tune-up removed I got corrupted output, lines of dots over text. I re-built system 7.01 and found that the printing problem is still there so I guess that my system 7.01 installation kit is corrupt, 7.0 was fine. The problem is that my poor old Mac only has an 800k drive so I can't use real disks. I used Mount Image to mount disk images then dragged the disks onto my hard disk to create folders from which I installed. Some people have written to say that MountImage is still a little shaky so I am blaming the problem on that and going back to 7.0 for now. There are some irritating bugs etc in 7.0 which I have read are fixed in 7.01 but since 7.01 is availible as 1400k disk images only I don't seem able to get 7.01 without going through mountImage and perhaps getting in the same mess again. Is there any way to extract the files from a disk Image without using mountimage or real disks? Does anyone know if System 7 tune-up fixes the disk eject bug where when you eject a floppy the Mac asks for it back again?? thanks, Graham Heyes From dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes Fri Jan 24 08:00:38 PST 1992 Article: 19 of comp.os.vxworks Path: dog.ee.lbl.gov!hellgate.utah.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!caen!uvaarpa!murdoch!dadev!heyes From: heyes@dadev.cebaf.gov (Graham Heyes) Newsgroups: comp.os.vxworks Subject: IGNORE EARLIER POST!! Message-ID: <1992Jan21.182951.204@murdoch.acc.Virginia.EDU> Date: 21 Jan 92 18:29:51 GMT Sender: usenet@murdoch.acc.Virginia.EDU Reply-To: heyes@dadev.cebaf.gov (Graham Heyes) Organization: CEBAF (Continuous Electron Beam Accelerator Facility) Lines: 1 This mxrn news reader is a real pain in the ^##&&^ sometimes. From dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cosmic.physics.utah.edu!corbato Fri Jan 24 08:00:39 PST 1992 Article: 20 of comp.os.vxworks Newsgroups: comp.os.vxworks Path: dog.ee.lbl.gov!hellgate.utah.edu!fcom.cc.utah.edu!cosmic.physics.utah.edu!corbato From: corbato@cosmic.physics.utah.edu (Steve Corbato) Subject: On-campus (U of Utah) test of vxworks group -- please disregard Message-ID: <1992Jan22.224043.25212@fcom.cc.utah.edu> Originator: corbato@cosmic.physics.utah.edu Sender: news@fcom.cc.utah.edu Organization: University of Utah Computer Center Distribution: slc Date: Wed, 22 Jan 92 22:40:43 GMT -- Steve Corbato corbato@cosmic.physics.utah.edu (Internet) Cosmic Ray Physics Group utahco::corbato, 47623::corbato (HEPnet) Physics Dept., Univ. of Utah corbato@utahcca (BITnet) Salt Lake City UT 84112 USA (801) 581-5053 (office), -4801 (Fax) From dog.ee.lbl.gov!network.ucsd.edu!usc!elroy.jpl.nasa.gov!swrinde!mips!samsung!uunet!psinntp!calspan!smc!brancato Fri Jan 24 08:00:40 PST 1992 Article: 21 of comp.os.vxworks Path: dog.ee.lbl.gov!network.ucsd.edu!usc!elroy.jpl.nasa.gov!swrinde!mips!samsung!uunet!psinntp!calspan!smc!brancato From: brancato@calspan.com (Tony Brancato) Newsgroups: comp.os.vxworks Subject: VME to GPIB interface boards under VxWorks Keywords: VME GPIB HPIB interface driver Message-ID: <1992Jan23.171925.10881@calspan.com> Date: 23 Jan 92 17:19:25 GMT Sender: usenet@calspan.com Organization: Calspan Advanced Technology Center, Buffalo, NY Lines: 28 Originator: brancato@smc Nntp-Posting-Host: smc Does anyone have experiences with VME-to-GPIB interface boards that they would mind sharing? We are building an RF simulation system and are using an HP8902A measuring receiver and an HP voltmeter to perform diagnostics and calibration. We'd like to write software to control the voltmeter and measuring receiver from the main CPU over the GPIB. The system is built around a Motorola M147 VME CPU board running VxWorks 5.0 (as part of VADS 2.0.1c). We have looked at an interface board from American Eltec, and found that their driver would not arbitrate service requests from the GPIB. Specifically, if a command was sent which caused a service request and the controller attempted to talk to the requesting node before the request was handled, the driver would hang because the requesting node would never respond. Is this normal for these types of boards, or do other drivers detect and handle this condition? We also have the driver for the MZ7500 board from Mizar, but have not had a chance to look at it yet. Any suggestions, impressions, or past experiences about quality of product and support are appreciated. Please e-mail and I will post a summary. Thanks in advance. -- Tony Brancato Calspan Corporation ATC Buffalo, NY ..!uupsi!calspan!brancato brancato@calspan.com From briggs@thalia.jpl.nasa.gov Fri Jan 24 08:43:05 1992 From: briggs@thalia.jpl.nasa.gov (Clark Briggs) Date: Fri Jan 24 08:43:11 PST 1992 Subject: Re: TP & VME addresses The question >>We've got a Tadpole TP41V under 5.0.2. Unfortunately, we cannot make >>it access any off board addresses. lead to discussions about the local to bus & bus to local maps. While I dont think the following really bears upon the original problem, I wondered about the general state of things other than in the world of Heurikon BSPs where I spend my time. I found that HK only maps the local ram to a VME address if the SBC is Processor 0. This is explicitly checked in the mapping functions. Slot 0 is mapped to support the on-board memory used for backplane message passing. Since the other SBCs use the memory on the slot 0 processor, they dont need to set up the map to expose themselves to slave accesses from the VMEbus. This does not mean all the processors cant go out and be bus masters and access others, just that they wont respond if accessed. So this does not appear to be the original problem. So, is there any standard for placing the other procs in VME space? Are folks using A32 or A24? Mapping small parts, or all of the onboard memory? Do folks use a simple formula that is a function of the processor number (which can be obtained via the BSP)? I have various uses for this that might lead to different address allocation schemes. Sometimes we simply want to set up a few semaphore-like locations for synchronization. Sometimes we need to share (fairly large) data arrays. To date we have placed everything in a large VMEbus RAM board, but I have begun to worry about the bus traffic for the future in some of these uses. In one use, I need multiple HK V4Fs, 2 TASCO 1750s, and a 4MB RAM board in the same address space. Since the 1750s take 2Mb in A24 and thats their only possible configuration, things get tight quickly. There is room enough but I would like to follow some standard scheme. From mea@sparta.com Fri Jan 24 09:48:01 1992 From: mea@sparta.com (Mike Anderson) Date: Fri Jan 24 09:48:08 PST 1992 Subject: Re: TP & VME addresses Greetings! When playing memory mapping games with the Heurikon HK80G/V960E board (i960CA), I use the processor number to map my slave memory segments into A32 space. A32 space is the only area where most manufacturers don't add additional "address modifier" bits so 0x40000000 on one board is the same 0x40000000 on any other board in the system. This makes life much easier because anyone can calculate the extended address segment by a formula such as 0x40000000 + (processor_number * 0x1000000). This formula maps slave RAM into even 16MB segments which may have to be adjusted for particular applications. In general, I try to avoid the A24 space for slave memory when possible because A) there's not much of it; B) vendors have different address ranges for standard space that may vary from card to card (e.g., Heurikon maps standard space at 0x1000000 on the V3E but maps that same address at 0x2000000 on the V30); and C) there's always some card that comes along that needs 128K or so of RAM right in the middle of A24 space that can't be moved ;-). ============================================================================== AAAA D D D D EEEEE M M TM // AAAA RRRR TTTTTT SSSSS EEEEE TM 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, ADDEM(TM) Project Office FAX: (703) 734-3323 SPARTA, Inc. EMAIL: mea@sparta.com Suite 900 7926 Jones Branch Drive "The optimist proclaims that we live in the McLean, VA 22102 best of all possible worlds, and the pessimist fears that this is true." J.B. Cabell ============================================================================== From kevinf@verdix.com Fri Jan 24 11:26:36 1992 From: "D. Kevin Faust" Date: Fri Jan 24 11:26:46 PST 1992 Subject: Re: comp.os.vxworks articles Does VxWorks provide any way to direct output to a null device, in other words, the equivalent of "/dev/null" ??? From nelson@wrs.com Fri Jan 24 15:52:53 1992 From: nelson@wrs.com (Nelson Stubbins) Date: Fri Jan 24 15:53:00 PST 1992 Subject: VxWorks equivalent to "/dev/null" > Does VxWorks provide any way to direct output to a null device, > in other words, the equivalent of "/dev/null" ??? Yes, there is a "/null" device. To see a list of devices, use the devs() routine. You will see the null device listed there. Nelson Stubbins Training Manager Wind River Systems From bdoerr@aplpy.jhuapl.edu Sat Jan 25 13:46:58 1992 From: bdoerr@aplpy.jhuapl.edu (Bryan S. Doerr) Date: Sat Jan 25 13:47:06 PST 1992 Subject: MMU Follow-up Hi: I have used the MMU on our MVME-147S to provide some of the features described in the last MMU query (poster's name forgotten, sorry). It is a simple implementation but a first step into the MMU world. Without getting real specific, I divided the VxWorks image into specified text and data segments at link time. I then mapped the following areas using the MMU translation tables: VxWorks reserved 0- FFFH R/W, cache on VMEbus global ram 1000- 2FFFH R/W, cache off MMU Trans Tables 3000- 4FFFH RO , cache on application text 5000- 7FFFFH RO , cache on VxWorks text 80000- FFFFFH RO , cache on application data 100000- 14FFFFH R/W, cache on VxWorks data 150000- ? R/W, cache on system memory pool ? - 3FFFFFH R/W, cache on VMEbus space 400000-FF7FFFFFH R/W, cache off Also mapped were the EPROM banks and VMEbus Short I/O. I was a little generous with some of the space allocations as a first pass. I plan to change this when the application matures. Also, the hardware cache inhibits VMEbus accesses but just for completness, I did it also. The translation tables are created in usrRoot after everything else has completed initialization. To start the application running, I load it from a script that uses the vxWorks routine 'loadModuleAt()' and specify the the application text and data base addresses. The code consists of one C module. The MMU initializations were done using ASM in-line calls. The translation tables were written in C. I had to do one hack to get this working and that was to change the boot ROMs to load the VxWorks segments correctly. The data address is hardcoded, hence the hack. In addition, I had to change to boot ROMs to run from a different (higher) part of memory because the new mappings caused the system image to clobber the currently running ROM code. Also, I wrote a short routine to turn the MMU off from the shell and another routine to search all addressable space and print a summary of the access and cache mode specifications at the transition points. There are some notable weaknesses with this approach, specifically no task protection, no smart handling of bus errors caused by the various no-no's (access violation, not mapped space vs board not responding etc), and breakpoints can't be set. It does work well for what we needed though which was cache coherency after VMEbus-local RAM access by an alternate master and code protection. I think most of these deficiencies could be overcome with a little more work. One final note, a co-worker took this idea and ported to a MVME-167 board and used the 040 MMU to control things such as serialized I/O reqs. and cache mode. The port wasn't a drop in because the 040 MMU is a good bit different. Regards, Bryan From wdf@uk.ate.slb.com Mon Jan 27 00:08:16 1992 From: wdf@uk.ate.slb.com Date: Mon Jan 27 00:08:33 PST 1992 Subject: NFS read very slow We have a configuration consisting of a Motorola mv147 running VxWorks 5.0.2 connected to a host Sun SparcStation over ethernet, there are no other nodes on the ethernet. We boot the mv147 over the ethernet from an image which is VxWorks linked with our application, this is quite large (about 1.6 Mbytes) and is loaded to start at 0xd0000. Our application is started from the end of usrRoot(). VxWorks is configured to use NFS. When we stop our application at it's start, so that none of our code has been executed and type the following commands to the shell, the read() takes about a minute ! -> nfsMount ("host","/directory","/directory") -> cd "/directory/sub_dir" -> x = open("file",0) -> y = malloc(600000) -> read (x,y,550000) Where "file" is a file of 590000 bytes. If we link the image without our code, but configured in exactly the same way (which gives an image of less than 400Kbytes) the same sequence of commands results in the read() taking about 3 seconds. If we put the mv147 and Sun onto our factory ethernet, which has over 50 nodes and is quite busy, the read() is again faster than a minute, although not as good as 3 seconds. If anyone out there has any idea what may be causing read() to take so long, we will be gratefull to hear from you ! Bill Frewing Principal Engineer Schlumberger Technologies, Ferndown, UK. Email: wdf@ukfca1.uk.ate.slb.com Voice: (+44) 202 893535 Fax: (+44) 202 897097 From bernard@aar.alcatel-alsthom.fr Mon Jan 27 02:24:55 1992 From: bernard@aar.alcatel-alsthom.fr ( Olivier Bernard ) Date: Mon Jan 27 02:25:02 PST 1992 Subject: msgQueue Patch ... Is it possible to get the msgQueue patch ? Thanks -- Olivier From visicom!VisiCom.COM!trest@nosc.mil Mon Jan 27 09:08:47 1992 From: Mike Trest Date: Mon Jan 27 09:08:54 PST 1992 Subject: Re: NFS read very slow >>when we stop our application at it's start, so that none of our >>code has been executed and type the following commands to the >>shell, the read() takes about a minute ! . . . >>If we link the image without our code, but configured in exactly >>the same way (which gives an image of less than 400Kbytes) the >>same sequence of commands results in the read() taking about >>3 seconds. The former uses NFS which goes thru the additional protocol of NFS daemons and competetion for your workstation's processing resources. The full client/server processing is involved at both ends of the connection. The latter uses rcmd() from your workstation. The command is a simple "cat filename" to an open file descriptor "read" on the VxWorks card. The NFS is about 40 or 50 times "heavier" in processing load than the rcmd() which is a strait TDP connection. Secondly, the "cat filename" on your workstation is significantly buffered and will produce many times fewer disk acesses than the NFS. Remember, the virtue of NFS is to provide the FULL FILE HANDLING capabilities in a multiuser, shared, network environment. The rcmd() "cat filename" only provides a sequential output to your sequential input. The choice is up to you the application designer. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== From daemon@vxw.ee.lbl.gov Mon Jan 27 10:16:15 1992 From: daemon@vxw.ee.lbl.gov Date: Mon Jan 27 10:16:22 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Mon Jan 27 10:16:08 PST 1992 Subject: specifying boot parameters Subject: Wind River contact Subject: low power disk? ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: specifying boot parameters Date: 24 Jan 92 20:16:25 GMT From: heyes@dadev.cebaf.gov (Graham Heyes) Organization: CEBAF (Continuous Electron Beam Accelerator Facility) Message-ID: <1992Jan24.201625.6160@murdoch.acc.Virginia.EDU> Reply-To: heyes@dadev.cebaf.gov (Graham Heyes) Some time ago I ported VxWorks to a FERMILAB - FSCC fastbus controller now the time has come to release the system to some real users and we have hit a problem. The board has only 50 bytes of NV ram to store the VxWorks boot-line. Up to now for testing we have been using one board with a cryptic boot line like: fe(0,0)c: e=xxx.xx.x.xx h=xxx.xx.x.x u=vxw s=/vb Where I have replaced digits by xxx in the internet addresses for security of this posting. The boot script /vb has to be in the root directory since there is no space to specify a path. The user name is cut down to three characters but presents a security loophole in our system, we would prefer longer names. These boards are intended to be imbedded processors in a large scale system and 50 bytes is too small to store a boot line with enough versatility to specify unique options for each VxWorks node. The block of internet addresses reserved for VxWorks at our lab has a format like xxx.xx.xx.xx some of the hosts already have addresses like xxx.xxx.xx.xx which looses us 4 bytes compared with the test system, also three characters gives little scope for username allocation and putting a boot script in the root directory is messy. Other users must have had similar problems. Of course we could blow a unique set of EPROMS for each VxWorks target, or perhaps put a case statement in a common startup script which switches on inet address and branches to target specific scripts. The ideal solution would be to re-define the boot line as a parameter block, the fe(0,0) network interface specifier is redundant and could be thrown out, the two network addresses could be stored in long word format instead of dot notation taking only 4 bytes each, with one byte of flags the other 41 bytes can be split between username and boot script path. Has anyone already done this? I would be interested to know of any potential problems, is bootLib only called from usrConfig.c leaving it open for modification/removal??? Any advice gratefully accepted. Graham Heyes - ------------------------------------------------------------------------------- Graham Heyes CEBAF Physics Division MS 12H Internet: heyes@dadev.cebaf.gov 12000 Jefferson Ave DECnet : dadev::heyes, cebaf::heyes Newport News VA 23606 BITNET : heyes@cebaf Tel: (804) 249-7030 --------------------------- Newsgroups: comp.os.vxworks Subject: Wind River contact Date: Mon, 27 Jan 92 16:46:41 GMT From: selic@bqnws23ca (Bran Selic) Organization: Bell-Northern Research Ltd. Message-ID: <1992Jan27.164641.2290@bqnes74.bnr.ca> - -- Does anyone have the name of a contact in the marketing group at Wind River (e-mail or phone)? - -------------------------------------------------------------- * Bran Selic Bell-Northern Research Ltd. * * e-mail: selic@bnr.ca PO Box 3511, Station C * * phone: (613) 763-3954 Ottawa, Ont. CANADA K1y 4H7 * - -------------------------------------------------------------- --------------------------- Newsgroups: comp.realtime,comp.os.vxworks Subject: low power disk? Date: Mon, 27 Jan 1992 17:10:48 GMT From: rg@msel.unh.edu (Roger Gonzalez) Organization: UNH Marine Systems Engineering Lab Message-ID: This is not a realtime specific question, but lacking a comp.sys.embedded: Does anyone have any information on low power scsi disk drives? Now that I've purchased low power cmos 3u vme boards, I need a similarly low-powered disk. Thanks, - -Roger - -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsgar W. Dijkstra Roger Gonzalez - rg@msel.unh.edu Division of Bit Banging and Reluctant Robotics UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) From biocca@bevsun.bev.lbl.gov Mon Jan 27 11:13:44 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Mon Jan 27 11:13:55 PST 1992 Subject: crossconnection to comp.os.vxworks I am currently testing the interconnection between comp.os.vxworks and the exploder. Posting from the exploder to netnews occurs hourly, but of course newsfeeds will determine when your site receives them. Explosion of comp.os.vxworks occurs once daily early in the morning in digest form, just before the exploder daily digest goes out. Alan K Biocca Exploder maintainer From maf@verdix.com Mon Jan 27 13:19:36 1992 From: maf@verdix.com Date: Mon Jan 27 13:19:51 PST 1992 Subject: Re: Rumor regarding Ada > From dog.ee.lbl.gov!nosc!manta!psm Fri Jan 24 08:00:23 PST 1992 > From: psm@manta.NOSC.MIL (Scot Mcintosh) > Newsgroups: comp.os.vxworks > Subject: Rumor regarding Ada > Keywords: Ada, Verdix > Date: 16 Jan 92 18:15:28 GMT > > I've heard a rumor that Verdix will no longer be offering an > Ada product that runs with vxWorks. Verdix and Wind River recently announced a four-year extension to the reselling agreement under which Verdix distributes VxWorks as part of our VADSworks product (see page 6 of Wind River's September, 1991 edition of "Windword" for details). There are no plans to discontinue the VADSworks product. On the contrary, we are continuing to support and enhance existing versions of VADSworks, and we are porting the product to new processors. Marc Friedman Verdix Technical Sales From visicom!VisiCom.COM!trest@nosc.mil Mon Jan 27 14:08:58 1992 From: Mike Trest Date: Mon Jan 27 14:09:09 PST 1992 Subject: RE: specifying boot parameters Graham Heyes writes: >>The board has only 50 bytes of NV ram to store the VxWorks boot-line. >>Up to now for testing we have been using one board with a cryptic boot >>line like: . . . >>Other users must have had similar problems. Of course we could blow a >>unique set of EPROMS for each VxWorks target, or perhaps put a case statement >>in a common startup script which switches on inet address and branches to >>target specific scripts. . . . >>Has anyone already done this? I would be interested to know of any >>potential problems, is bootLib only called from usrConfig.c leaving it open >>for modification/removal??? >>Any advice gratefully accepted. Graham, we faced the same problem with ZERO NV ram on a custom board used in a cluster of 12 cpu boards in the same chassis and a network of 4 to 12 chassis. The prsopect of burning 144 unique ROM sets was very negative. Our solution (which might apply to your posting) was to put a small function in the bootConfig.c file which "Requested Permission To Boot" from a "Boot Monitor Service". The BMS service assigned a network address, board id, user id, ETC .... A (unplanned) side benefit was a much faster boot process for all boards and chassis because it eliminated the instant depletion of Q entries in the boot host's TCP/IP which was caused when every board in every chassis booted at the same time. A designed-in benefit of this was "Dynamic Assignment Of Boot Host Role". We wrote our bootConfig.c function to be independent of the actual boot host's identity. This allowed for booting from any of a group multiple workstations to eliminate single point failures. We are presently extending this capability with VxWorks cards booting themselves from SCSI disks and then providing additional "Boot Service" to the remaining boards and chassis. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== ? From wdf@uk.ate.slb.com Tue Jan 28 01:39:00 1992 From: wdf@uk.ate.slb.com Date: Tue Jan 28 01:41:46 PST 1992 Subject: Re: NFS read very slow I asked for help on a problem where read() using NFS on a mv147 was taking too long, this happened on a lightly loaded ethernet, and seemed to depend on the ammount of object code (text, not data) loaded at the time, even though that object is not executed. We link the object code with vxWorks and boot from that combined image over the network. If the image was about 400K read() takes 3seconds, if it was 1.1M read() takes over a minute (to read 550K). I have had a some replies, as follows. Leonid Rosenboim suggested putting the net task priority to 0 or 1, this didn't have any effect. He also suggested trying etherfind on a different Sun on the network, I haven't tried that yet. We received the message queue patch from Wind River yesterday, and that has fixed the problem, although I don't know why. Actually it has only partially fixed the problem... we are experiencing this on two types of board, the mv147 mentioned in my earlier mailing, and a National Instruments VXIcpu-030. This is a mv147 look-alike which lives on a VXI backplane, the message queue patch did improve matters on that, but not significantly (the read() now takes about 40 seconds). Mike Trest suggested that the two cases (where the read took 3 seconds and over a minute) were different, in that one used NFS and the other didn't. I cannot understand why that should be the case, as the two read()s are done in exactly the same manner from the shell after usrRoot() returns. The sequence of commands was as follows: -> nfsMount ("host","/directory","/directory") -> cd "/directory/sub_dir" -> x = open("file",0) -> y = malloc(600000) -> read (x,y,550000) Bill Frewing Principal Engineer Schlumberger Technologies, Ferndown, UK. Email: wdf@ukfca1.uk.ate.slb.com Voice: (+44) 202 893535 Fax: (+44) 202 897097 From leonid@amil.co.il Tue Jan 28 02:52:09 1992 From: leonid@amil.co.il (Leonid Rosenboim) Date: Tue Jan 28 02:52:17 PST 1992 Subject: Re: NFS read very slow > Submitted-by wdf@uk.ate.slb.com (Bill Frewing) Tue Jan 28 01:39:00 1992 > ... > Mike Trest suggested that the two cases (where the read took 3 seconds > and over a minute) were different, in that one used NFS and the other > didn't. I cannot understand why that should be the case, as the two > read()s are done in exactly the same manner from the shell after > usrRoot() returns. The sequence of commands was as follows: > -> nfsMount ("host","/directory","/directory") > ... Mike was wrong. True that usually VxWorks comes from WRS configured without NFS support, but the above "nfsMount" command clearly shows that the smaller kernel does include the NFS option, otherwise "nfsMount" would have failed. Leonid From daemon@vxw.ee.lbl.gov Tue Jan 28 04:00:33 1992 From: daemon@vxw.ee.lbl.gov Date: Tue Jan 28 04:00:39 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Tue Jan 28 04:00:25 PST 1992 Subject: Re: Rumor regarding Ada ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Rumor regarding Ada Date: Tue, 28 Jan 1992 01:47:53 GMT From: tony@wrs.com (Tony Barbagallo) Organization: Wind River Systems, Inc. Alameda, CA Keywords: Ada, Verdix Message-ID: <1992Jan28.014753.3591@wrs.com> References: <2615@manta.NOSC.MIL> In article <2615@manta.NOSC.MIL> psm@manta.NOSC.MIL (Scot Mcintosh) writes: >I've heard a rumor that Verdix will no longer be offering an >Ada product that runs with vxWorks. Supposedly, they'll be >furnishing their own operating system. I've also heard that >Wind River is talking with Telesoft about furnishing Ada. >Anyone know the real story? > Just to clarify the recent postings regarding the relationship between Verdix and Wind River Systems, I'd like to point out that in September of 1991 the two companies signed a four year extension to this successful agreement which brought VADSworks to the market. Included in the extended agreement are rights for Verdix to sell VADSworks on a worldwide basis. Furthermore, the marketing organization at Wind River is not pursuing relationships with any other Ada vendors at this time. Tony Barbagallo Manager of Product Marketing Wind River Systems, Inc. tony@wrs.com --------------------------- End of New-News digest ********************** From visicom!VisiCom.COM!trest@nosc.mil Tue Jan 28 07:56:39 1992 From: Mike Trest Date: Tue Jan 28 07:56:46 PST 1992 Subject: Re: NFS read very slow Obviously I did not read the posting carefully enough to determine that both reads were NFS reads. Sorry about the confusion. However, the difference in performance between NFS reads and remote command execution of "cat filename" remains true. ..mike.. ==================================================== Mike Trest trest@visicom.com Senior Engineer Voice: 619 592 0353 Technology Group Fax: 619 673 0307 VisiCom Laboratories San Diego, CA ==================================================== From phil%kerSs2@wrsec.wrsec.fr Tue Jan 28 10:52:10 1992 From: phil%kerSs2@wrsec.wrsec.fr (Philippe Le Foll) Date: Tue Jan 28 10:52:18 PST 1992 Subject: Mv165 and VSB hello, Does anybody already used VSB on a Motorola MV165 ? If yes thank for the initialisation sequence used. thank you Philippe From thor@thor.atd.ucar.edu Tue Jan 28 11:06:42 1992 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Tue Jan 28 11:06:50 PST 1992 Subject: Job offer Do not reply to sender!!!!! Contract diagnostics engineer needed immediately in Bay area. 6+ months. S/W diagnostics, Sun, UNIX, VxWorks. Contact: Jeff Gold United Source Services 28310 Roadside Dr. Suite 237 Agoura Hills, CA 91301 818-991-227 (voice) 818-991-3413 (fax) From prb@aplexus.jhuapl.edu Tue Jan 28 12:13:07 1992 From: prb@aplexus.jhuapl.edu (Paul R. Bade) Date: Tue Jan 28 12:13:14 PST 1992 Subject: Re: Mv165 and VSB We also are planning to use the MV165 and its VSB in the near future. We will be using it only as a temporary solution until the MV166 boards become available this summer.This is partially because the MV165 board has such poor VME performance. In addition to its normal poor VME performance, the MV165 does not support VME64. THe MV166 board is essentially a MV167 (software compatible) with the addition of the VSBchip2 interface. Please let me know if you find anything about the MV165 board which may be useful. Thanks, Paul Bade Johns Hopkins University / Applied Physics Lab prb@aplexus.jhuapl.edu PS I wrote some MMU code for the MV167 board, let me know if you are interested. From comtec!jack@ucsd.edu Tue Jan 28 12:15:11 1992 From: comtec!jack@ucsd.edu (Jack McRoberts) Date: Tue Jan 28 12:15:19 PST 1992 Subject: Re: memory board, VSB part. slave I/F We use a board by MicroMemory. It has 64 Megs and is accessible as a slave across both VSB and VME. Addresses are selectable on 1M boundaries, and it responds to both A24 and A32. jack mcroberts ORINCON Corp 9363 Towne Center Drive San Diego, Ca 92121 From biocca@bevsun.bev.lbl.gov Tue Jan 28 13:01:42 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Tue Jan 28 13:01:49 PST 1992 Subject: Re: Job offer REPEATED Hmmm. This is the second time this job offer has been on here. Alan K Biocca From iphasew!hwajin@apple.com Tue Jan 28 13:28:22 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Tue Jan 28 13:28:29 PST 1992 Subject: RE: NFS read very slow Bill Frewing writes... >I asked for help on a problem where read() using NFS on a mv147 was >taking too long, this happened on a lightly loaded ethernet, and >seemed to depend on the ammount of object code (text, not data) >loaded at the time, even though that object is not executed. We link >the object code with vxWorks and boot from that combined image over >the network. If the image was about 400K read() takes 3seconds, if >it was 1.1M read() takes over a minute (to read 550K). When this happens try various network related "Show" routines to see if you see any excessive input errors are happening either at the network interface level or protocol level. You can use -> lkup "Show" to see a list of Show routines and "help" command to see what they do. Of course, the final "read()" command will need to be "sp" (spawned), so that you can run "Show" commands from the shell. And also, try using TCP based read() on the same file -- use either FTP or RSH based netDrv. See if this makes any difference. On some eariler rev's of mv147's (there were a number of rev's) and other '030 based SBC's there were some hardware problems (the LANCE would report CRC and Frame error when in fact the packet received was okay -- caused by power glitch due to insufficient capacitance) that only occurred when a lot of back-to-back packets were received from the network. A lot of packets get dropped at the LANCE driver level when this happens. Thus, my suggestions for further investigation... Good luck. - Hwa-Jin Bae Interphase West From iphasew!hwajin@apple.com Tue Jan 28 13:32:42 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Tue Jan 28 13:32:50 PST 1992 Subject: RE: specifying boot parameters Graham Heyes writes... > The ideal solution would be to re-define the boot line as >a parameter block, the fe(0,0) network interface specifier is redundant and >could be thrown out, the two network addresses could be stored in long word >format instead of dot notation taking only 4 bytes each, with one byte of flags >the other 41 bytes can be split between username and boot script path. If you do throw out the network interface specifier two things will need to be changed: 1. the call to bootStringToParams() in usrConfig.c and bootConfig.c will need to be replaced with your own (or fake the bootString input). The bootStringToParams() is rather strict about the format it accepts. 2. bypass the code that attaches a particular network interface based on either a bunch of "if" blocks (if you're using old version of VxWorks) or a table. Attach your device directly and skip that part. The network addresses can be in hex format but you need to specify '0x' or '0X' prefix. The hex digits still need to be ascii format so you'll waste a byte per digit. Still, this will save you a few bytes. Due to a "bug" in inet_addr() routine in VxWorks, you could actually save a byte if you don't specify '0' in front of 'x' or 'X'. That is "0x12345678" = "x12345678". I think this "bug" is still in there so a couple of additional bytes can be saved. Alternatively you could add a host table entry using hostAdd() for the "host" you're booting from (if it doesn't change). And delete the corresponding hostAdd() used in bootConfig.c and usrConfig.c. No more space wasted for the host IP address. Save a bunch of bytes there. Also if you do away with bootStringToParams() entirely, you make it do what you want. If you want to get rid of the boot line dependency all together, you can write either RARP or BOOTP. > Has anyone already done this? I would be interested to know of any >potential problems, is bootLib only called from usrConfig.c leaving it open >for modification/removal??? Routines in bootLib.c are called from usrConfig.c and bootConfig.c. I don't think they're used anywhere else, but I'm not 100% sure. I'm using an ancient version of VxWorks here -- version 4.0.1. Of course, if you remove bootLib, you won't be able to do things like bootParamsShow() from the shell. Good luck! -- Hwa-Jin Bae Interphase West From thor@thor.atd.ucar.edu Tue Jan 28 13:49:49 1992 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Tue Jan 28 13:49:56 PST 1992 Subject: TP41 booting problems When we boot our TP41V, the following error message appears: Format Error Program Counter: 0x4003be60 Status Register: 0x3010 Task: 0x401d34e4 "tShell" and VxWorks hangs - no startup script processing, ^C & ^X don't work, etc. Actually, what's more confusing is that ^X works for the eprom WRS sent with the board support package, but our own proms cannot even service ^X. Any ideas? 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. From votava@fndaue.fnal.gov Tue Jan 28 13:51:46 1992 From: votava@fndaue.fnal.gov (Margaret Votava) Date: Tue Jan 28 13:51:54 PST 1992 Subject: vxworks for an lr33000 Hi, I know LSI is in the process of doing a vxworks port for the LR33000 MIPS microprocessor. Has anyone else already done the port? Thanks, Margaret Votava Fermilab From bob@wrs.com Tue Jan 28 13:59:15 1992 From: bob@wrs.com (Bob Cohen) Date: Tue Jan 28 13:59:24 PST 1992 Subject: Re: NFS read very slow I think what you're seeing is the lance bug that appeared on earlier versions of the 147 which caused it to drop incoming packets under certain conditions. The symptom we saw here at wind river (and elsewhere - this was a widespread problem) was exactly as you describe. If you run etherfind, you'll see the target transmit the nfs request, the reply comes back immediately, then the nfs retransmission period elapses (5 seconds default), and it retransmits the request. I believe Motorola is aware of the problem, and they can update your board. From kent@wrs.com Tue Jan 28 15:01:12 1992 From: kent@wrs.com (Kent Long) Date: Tue Jan 28 15:01:29 PST 1992 Subject: Re: TP41 booting problems Hi, Folks - thor@thor.atd.ucar.edu (Richard Neitzel) writes: > > When we boot our TP41V, the following error message appears: > > Format Error > Program Counter: 0x4003be60 > Status Register: 0x3010 > Task: 0x401d34e4 "tShell" > > and VxWorks hangs - no startup script processing, ^C & ^X don't work, > etc. Actually, what's more confusing is that ^X works for the eprom > WRS sent with the board support package, but our own proms cannot even > service ^X. Any ideas? Well, I suspect that this TP-41 uses the new mask of the 68040. This can be confirmed by looking for the ID "04D50D" on the cpu chip. This newer mask included some changes in the floating point exception format, which can cause the "format error" which Richard describes. The beta/pre-release version of VxWorks 5.0.2/68040 (i.e. the version in general circulation) does not correctly deal with this new chip mask. The new 5.0.2b/68040 release should be available within a couple weeks, and it does include changes for the D50D mask. As for the reboot problem, it is quite possible that this is also due to the mask revision. There is also an unrelated fix in the 5.0.2b/ 68040 release which corrects a general problem with rebooting. So, please be patient and see if the new version fixes your problems. - kent Kent Long Wind River Systems kent@wrs.com From Enterprise!arete!reder@uu.psi.com Tue Jan 28 18:04:22 1992 From: reder@arete.lbl.gov (Leonard J. Reder) Date: Tue Jan 28 18:04:28 PST 1992 Subject: RE: NFS read very slow > On some eariler rev's of mv147's (there were a number of rev's) and > other '030 based SBC's there were some hardware problems (the LANCE > would report CRC and Frame error when in fact the packet received > was okay -- caused by power glitch due to insufficient capacitance) > that only occurred when a lot of back-to-back packets were received > from the network. A lot of packets get dropped at the LANCE driver > level when this happens. Thus, my suggestions for further investigation... > > Hwa-Jin Bae > Interphase West > At one point we had a problem of unreliable data com with our MV147S board due to a problem with the LANCE hardware on the board. This caused very slow net data rates. Finally it was fixed by sending the board back to Motorola for an upgrade to Rev. E (I think..). Everything with the board and socket level communications seems to function normally now. I originally recall reading about this problem in one of the WindWord news letters from WRS. You may wish to contact WRS for the specifics. Len Reder Arete Associates From daemon@vxw.ee.lbl.gov Wed Jan 29 04:00:36 1992 From: daemon@vxw.ee.lbl.gov Date: Wed Jan 29 04:00:43 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Wed Jan 29 04:00:23 PST 1992 Subject: vxworks development organization Subject: Unimplemented Opcode error Subject: Re: comp.os.vxworks newsdigest reposting Subject: Re: Unimplemented Opcode error ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: vxworks development organization Date: 28 Jan 92 14:16:44 GMT From: rg@msel.unh.edu (Roger Gonzalez) Organization: UNH Marine Systems Engineering Lab Message-ID: I've just gotten VxWorks up and running, and I'm trying to figure out a way to let several people work on coding pieces of the same project, without leaving all the directories wide open. I was considering something like the following: users a, b, and c are all working on project p. the vxworks library/binary tree is in v. Assume that a, b, c, p, and v all are in /etc/passwd, but p and v have disabled passwords. a, b, and c have hooks in their .cshrc's that, if they newgrp to group "p", will change their home directory to ~p, and run ~p/.setup. ~p/.setup will add Now that seems to be ok for the unix side. What about vxworks? Should they do an "iam p" on that side? Any comments would be appreciated. - -Roger - -- "The question of whether a computer can think is no more interesting than the question of whether a submarine can swim" - Edsger W. Dijkstra Roger Gonzalez - rg@msel.unh.edu Division of Bit Banging and Reluctant Robotics UNH Marine Systems Engineering Laboratory, Durham, NH 03824-3525 (603) 862-4600 -4399 (fax) --------------------------- Newsgroups: comp.os.vxworks Subject: Unimplemented Opcode error Date: 28 Jan 92 19:10:23 GMT From: cole@noao.edu (Lonnie Cole) Organization: National Optical Astronomy Observatories, Tucson, AZ, USA Keywords: BOMB Message-ID: <1992Jan28.191023.3382@noao.edu> We are running vxWorks 5.0.2 on a Motorola MV147 board which is running some instrumentation we have. The tasks run along fine most of the time, but if I rlogin into the vxWorks system, sometimes I get something like the following actual example: rlogin sonora-i inst > Unimplemented Opcode 1111 Program Counter: 0x0075f2c8 Status Register: 0x3000 Task: 0x76d8a8 "tRotator" The a dump of the offending code from vxWorks looks like: 75f2aa f22e 5438 ffa0 FCMP .D (0xffa0,A6),F0 75f2b0 f29d 00fa FB .W #0xfaf22e 75f2b4 f22e 4400 ffdc FMOVE .S (0xffdc,A6),F0 75f2ba f22e 5423 fff8 FMUL .D (0xfff8,A6),F0 75f2c0 f200 0003 FDB D0,#0xf22e 75f2c4 f22e 6000 ffd8 FMOVE .L F0,(0xffd8,A6) 75f2ca 0cae 0000 7fff ffd8 CMPI .L #0x07fff,(0xffd8,A6) 75f2d2 6f08 BLE 0x75f2dc 75f2d4 2d7c 0000 7fff ffd8 MOVE .L #0x07fff,(0xffd8,A6) value = 7729884 = 0x75f2dc = _updateRotator + 0x1a0 Has anybody else had any similar problems. This happens fairly frequently and I don't know if my code is doing or not-doing something to cause this behavior. Lonnie cole@noao.edu --------------------------- Newsgroups: comp.os.vxworks Subject: Re: comp.os.vxworks newsdigest reposting Date: 28 Jan 1992 19:36:08 GMT From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Organization: Lawrence Berkeley Laboratory, California Message-ID: <20916@dog.ee.lbl.gov> References: <9201281200.AA26055@vxw.ee.lbl.gov> Sorry about that. A bug in the exploder reposted the newsdigest of the previous postings. Repairs have been made. Alan K Biocca Exploder Maintainer --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Unimplemented Opcode error Date: 28 Jan 92 20:40:10 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: <1992Jan28.191023.3382@noao.edu> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) I've found that often times when things get this bad, the cause is actua From heyes@dadev.cebaf.gov Wed Jan 29 05:50:49 1992 From: heyes@dadev.cebaf.gov Date: Wed Jan 29 05:50:57 PST 1992 Subject: Re: specifying boot parameters Many thanks for the mails. I've had several on the subject, the most elegant is as follows. Start with a short boot string specifying only the host and your own network address. Edit the network initialisation code to attach our interface directly rather thn looking it up so we don't need the fe(0,0) part of the boot string. Next, when the network is up, do an RPC call to a server on the specified host. The server recognises the address of the caller and sends back an extended boot line with any number of arguments of arbitrary length. (Alternatively open a flat file in a known place which contains entries keyed by network address). A second call to bootStringToParams can then be made to update the boot parameters, or since the format of the boot parameter structure is known, a user decode routine can be put into usrConfig.c allowing more user options to be specified. This gets us nicely out of the problem. By the way I keep mentioning usrConfig.c and not bootConfig.c because our board only has limited RAM but a large amount of EPROM. As much of our kernel and symbol table as possible is in EPROM. Only the Data and Bss segments in RAM. We have to do some playing with the linker here since the Data and Bss must be forced into RAM for execution but the Data segment must initially be contained in the EPROMS then copied to RAM during the boot procedure. Also look at the assembler code for the symbol table, you will see that all the name strings of symbols are in the Data segment i.e. RAM. They don't need to be since they never change. Awk or Sed can be used to edit the assembly code to put these definitions in the Text Segment, forcing them into EPROM. You can't force the whole symbol table into EPROM since it is hashed later. Many thanks again for advice on the boot line problem, Graham Heyes ------------------------------------------------------------------------------- Graham Heyes CEBAF Physics Division MS 12H Internet: heyes@dadev.cebaf.gov 12000 Jefferson Ave DECnet : dadev::heyes, cebaf::heyes Newport News VA 23606 BITNET : heyes@cebaf Tel: (804) 249-7030 From heyes@dadev.cebaf.gov Wed Jan 29 06:19:14 1992 From: heyes@dadev.cebaf.gov Date: Wed Jan 29 06:19:21 PST 1992 Subject: Re: specifying boot parameters Many thanks for the mails. I've had several on the subject, the most elegant is as follows. Start with a short boot string specifying only the host and your own network address. Edit the network initialisation code to attach our interface directly rather thn looking it up so we don't need the fe(0,0) part of the boot string. Next, when the network is up, do an RPC call to a server on the specified host. The server recognises the address of the caller and sends back an extended boot line with any number of arguments of arbitrary length. (Alternatively open a flat file in a known place which contains entries keyed by network address). A second call to bootStringToParams can then be made to update the boot parameters, or since the format of the boot parameter structure is known, a user decode routine can be put into usrConfig.c allowing more user options to be specified. This gets us nicely out of the problem. By the way I keep mentioning usrConfig.c and not bootConfig.c because our board only has limited RAM but a large amount of EPROM. As much of our kernel and symbol table as possible is in EPROM. Only the Data and Bss segments in RAM. We have to do some playing with the linker here since the Data and Bss must be forced into RAM for execution but the Data segment must initially be contained in the EPROMS then copied to RAM during the boot procedure. Also look at the assembler code for the symbol table, you will see that all the name strings of symbols are in the Data segment i.e. RAM. They don't need to be since they never change. Awk or Sed can be used to edit the assembly code to put these definitions in the Text Segment, forcing them into EPROM. You can't force the whole symbol table into EPROM since it is hashed later. Many thanks again for advice on the boot line problem, Graham Heyes ------------------------------------------------------------------------------- Graham Heyes CEBAF Physics Division MS 12H Internet: heyes@dadev.cebaf.gov 12000 Jefferson Ave DECnet : dadev::heyes, cebaf::heyes Newport News VA 23606 BITNET : heyes@cebaf Tel: (804) 249-7030 From jritchie@wrs.com Wed Jan 29 09:32:09 1992 From: jritchie@wrs.com (Jim Ritchie) Date: Wed Jan 29 09:32:15 PST 1992 Hello, Has anyone written a VxWorks' driver for the Motorola MVME328 Dual-channel SCSI Adapter VME card that they would be willing to share with another VxWorks' customer? Thanks! ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ + James Ritchie Wind River Systems + + Western Region Field Application Engineer 19925 Stevens Creek Blvd + + jritchie@wrs.com Cupertino, CA 95014 + + (408)973-7857 + ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ From sjk@emerald.labs.tek.com Wed Jan 29 09:33:31 1992 From: Steven King (503) 627-2736 Date: Wed Jan 29 09:33:40 PST 1992 > Hi, > I know LSI is in the process of doing a vxworks port for the LR33000 > MIPS microprocessor. Has anyone else already done the port? > > Thanks, > Margaret Votava > Fermilab LSI has performed a board port of 5.0.4 (beta) for the LSI Pocket Rocket. The 5.0.4 (beta) distribution comes with a BSP for the Lockheed/ Sanders STAR MVP. It is my understanding that 5.0.4 will be officially released in February. I suggest you contact your Wind River salesperson regarding the availability of 5.0.4 (for the MIPS), and any specific BSPs. Steven ---------------------------------------------------------------------- e-mail: sjk@crl.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 ---------------------------------------------------------------------- From stan@rti.com Wed Jan 29 10:51:21 1992 From: stan@rti.com (Stan Schneider) Date: Wed Jan 29 10:51:27 PST 1992 Subject: Re: comp.os.vxworks newsdigest >> From: rg@msel.unh.edu (Roger Gonzalez) >> Organization: UNH Marine Systems Engineering Lab >> Message-ID: >> >> >> I've just gotten VxWorks up and running, and I'm trying to figure out a way >> to let several people work on coding pieces of the same project, without >> leaving all the directories wide open. >> >> ... >> >> Now that seems to be ok for the unix side. What about vxworks? >> Should they do an "iam p" on that side? >> We use a simple shell script that copies the user's login file out to a file that's sourced by the VxWorks startup script. It's simple & it works, but it does assume you're willing to reboot your target. >> --------------------------- >> >> Newsgroups: comp.os.vxworks >> Subject: Re: Unimplemented Opcode error >> Date: 28 Jan 92 20:40:10 GMT >> From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) >> Organization: Field Robotics Center, CMU >> Message-ID: >> References: <1992Jan28.191023.3382@noao.edu> >> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) >> >> >> I've found that often times when things get this bad, the cause is >> actua >> Is anyone else losing messages like this? -- 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 susanna@tomato.lbl.gov Wed Jan 29 14:34:05 1992 From: susanna@tomato.lbl.gov (Susanna Jacobson) Date: Wed Jan 29 14:34:12 PST 1992 Subject: Re: Mv165 and VSB Philippe Le Foll writes: > >Does anybody already used VSB on a Motorola MV165 ? >If yes thank for the initialisation sequence used. > and Paul R. Bade adds: > >We also are planning to use the MV165 and its VSB in the near future. ... >Please let me know if you find anything about the MV165 board >which may be useful. > We use the following shell commands at the beginning of the startup.cmd script: # Enable VSB access on MVME 165 m 0xfffa0000 0xfebe 0xfebe . m 0xfff9002a 0x1c . The first "m" writes to the VSB chip; the second to the Bus Control Register of the Local Resource Controller. The idea is to enable VSB access and set the longest timeout; see the VSBchip manual and the LRC section of the mv165 documentation. ======================================================================== Susanna Jacobson MS 46A-1123 Lawrence Berkeley Laboratory SRJacobson@LBL.Gov 1 Cyclotron Road (510) 486-7801 Berkeley, CA 94720 ======================================================================== From daemon@vxw.ee.lbl.gov Thu Jan 30 04:00:35 1992 From: daemon@vxw.ee.lbl.gov Date: Thu Jan 30 04:00:42 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Thu Jan 30 04:00:26 PST 1992 Subject: boot parameters + vxwexplo problems... Subject: Re: NFS read very slow Subject: Re: specifying boot parameters Subject: Re: Mv165 and VSB ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: boot parameters + vxwexplo problems... Date: 29 Jan 92 15:02:44 GMT From: heyes@dadev.cebaf.gov (Graham Heyes) Organization: CEBAF (Continuous Electron Beam Accelerator Facility) Message-ID: <1992Jan29.150244.25360@murdoch.acc.Virginia.EDU> Followup-To: boot parameters + vxwexplo problems... Reply-To: heyes@dadev.cebaf.gov (Graham Heyes) I would just like to point out that although the vxwexplo E-mail sent me a correct copy of my last posting (29 Jan) the copy which appears here has the first part missing and so doesn't make any sense at all... ... Is there a problem with the vxwexplo to comp.os.vxworks connection?? Here is the complete article - ------------------------------------------------------------------------ - ---------- Many thanks for the mails. I've had several on the subject, the most elegant is as follows. Start with a short boot string specifying only the host and your own network address. Edit the network initialisation code to attach our interface directly rather thn looking it up so we don't need the fe(0,0) part of the boot string. Next, when the network is up, do an RPC call to a server on the specified host. The server recognises the address of the caller and sends back an extended boot line with any number of arguments of arbitrary length. (Alternatively open a flat file in a known place which contains entries keyed by network address). A second call to bootStringToParams can then be made to update the boot parameters, or since the format of the boot parameter structure is known, a user decode routine can be put into usrConfig.c allowing more user options to be specified. This gets us nicely out of the problem. By the way I keep mentioning usrConfig.c and not bootConfig.c because our board only has limited RAM but a large amount of EPROM. As much of our kernel and symbol table as possible is in EPROM. Only the Data and Bss segments in RAM. We have to do some playing with the linker here since the Data and Bss must be forced into RAM for execution but the Data segment must initially be contained in the EPROMS then copied to RAM during the boot procedure. Also look at the assembler code for the symbol table, you will see that all the name strings of symbols are in the Data segment i.e. RAM. They don't need to be since they never change. Awk or Sed can be used to edit the assembly code to put these definitions in the Text Segment, forcing them into EPROM. You can't force the whole symbol table into EPROM since it is hashed later. Many thanks again for advice on the boot line problem, Graham Heyes --------------------------- Newsgroups: comp.os.vxworks Subject: Re: NFS read very slow Date: 29 Jan 92 01:27:09 GMT From: rypma@hppad.waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: <27550002@hppad.waterloo.hp.com> References: <9201270810.AA04153@pickle.UK.ATE.SLB.COM> We load a 2.5 Mb file with NFS and it takes no more than 10 to 20 seconds. Is there some kind of memory limitation when your application is linked in? Ted Rypma HP Panacom Division --------------------------- Newsgroups: comp.os.vxworks Subject: Re: specifying boot parameters Date: 29 Jan 92 01:10:11 GMT From: rypma@hppad.waterloo.hp.com (Ted Rypma) Organization: HP Panacom Div Waterloo ON Canada Message-ID: <27550001@hppad.waterloo.hp.com> References: <1992Jan24.201625.6160@murdoch.acc.Virginia.EDU> The bootp protocol is designed to do this, is supported (I think) by VxWorks and is a standard facility provided on many hosts. Ted Rypma HP Panacom Division --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Mv165 and VSB Date: 30 Jan 92 03:49:17 GMT From: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) Organization: Field Robotics Center, CMU Message-ID: References: <9201292237.AA07232@tomato.lbl.gov> Reply-To: hmp@frc2.frc.ri.cmu.edu (Henning Pangels) This is just a generic comment regarding the method described by Susanna Jacobson which involves modifying hardware registers via "m" commands from a script: I once tried the same thing and it took me a while to realize that the "m" command performs (I believe) 16-bit accesses, while the particular device I was trying to tinker with only responded to byte access. In a similar vein, hardware registers like that may be read-only, write-only or sometimes even have different purposes depending on the direction of transfer; simply reading a whole 16 bit word and rewriting it with those bits of interest set or cleared may have subtle side effects. Admittedly, this was some time ago and I was just starting out with vxWorks, but it just came back to me as one of those early lessons. - -Henning - -- Henning Pangels | hmp@frc2.frc.ri.cmu.edu | Field Robotics Center Research Programmer | (412) 268-7088 | Carnegie-Mellon University - ------------------------------------------------------------------------------ Do you really know what time it is? --------------------------- End of New-News digest ********************** From matthieu@vega.laas.fr Thu Jan 30 08:02:01 1992 From: Matthieu Herrb Date: Thu Jan 30 08:02:10 PST 1992 Subject: Re: Mv165 and VSB Susanna Jacobson writes: > We use the following shell commands at the beginning of the > startup.cmd script: > > # Enable VSB access on MVME 165 > m 0xfffa0000 > 0xfebe > 0xfebe > . > m 0xfff9002a > 0x1c > . > > The first "m" writes to the VSB chip; the second to the Bus Control > Register of the Local Resource Controller. The idea is to enable > VSB access and set the longest timeout; see the VSBchip manual and > the LRC section of the mv165 documentation. Our problem is that we need to initialize the VSB chip with 0xfeae (with the BOUNCE bit at zero) to access our UIC03 I/O card (from MicroSys). When we initialize the VSB chip with this particular value, the backplane interface of the 165 hangs. Has anyone else experienced this problem and/or a solution to it ? Thank you in advance. Matthieu Herrb -- Matthieu Herrb CNRS - LAAS matthieu@laas.fr 7, avenue du Colonel Roche 31077 Toulouse Cedex - France From wdf@uk.ate.slb.com Thu Jan 30 08:10:25 1992 From: wdf@uk.ate.slb.com Date: Thu Jan 30 08:10:39 PST 1992 Subject: Slow NFS read My last mailing on this subject started thus: > I asked for help on a problem where read() using NFS on a mv147 was > taking too long, this happened on a lightly loaded ethernet, and > seemed to depend on the ammount of object code (text, not data) > loaded at the time, even though that object is not executed. We link > the object code with vxWorks and boot from that combined image over > the network. If the image was about 400K read() takes 3seconds, if > it was 1.1M read() takes over a minute (to read 550K). Since then a few contributers have suggested that there may be a problem with the Lance ethernet chip(s) on the SBC we are using (a National Instruments VXIcpu-030). This may be borne out by the following findings: 1. When run on a loaded network (30+ suns) the problem does not occur. 2. When the host is an HP9000 (as opposed to the usual Sun Sparc) again the problem does not occur. 3. Using etherfind on the Sun when the read is taking a long time, shows that every 5th packet is followed by a wait of 5 seconds before the identical packet (with a packet number 1 greater!) is sent again. 4. If the nfsReXmitSec & nfsReXmitUSec globals are altered to hold the time of 0.5 seconds instead of the default 5.0 seconds then the read takes a 10th of the slow read time. From 1 & 2 we conclude that the SBC cannot handle the higher transfer rate possible due to light loading of network and server. 3 & 4 seem to indicate that the SBC is retrying but why it is doing so is a mystery to us! When using the vxWorks ???Show commands none of the reports show any errors. We have tried ipstatShow(), tcpstatShow(), icmpstatShow() & udpstatShow() (in each case we called the function from the vxWorks shell without any parameters). Bill Frewing Principal Engineer Schlumberger Technologies, Ferndown, UK. Email: wdf@ukfca1.uk.ate.slb.com Voice: (+44) 202 893535 Fax: (+44) 202 897097 From biocca@bevsun.bev.lbl.gov Thu Jan 30 15:04:16 1992 From: biocca@bevsun.bev.lbl.gov (Alan K Biocca) Date: Thu Jan 30 15:04:23 PST 1992 Subject: missing article fragment I found the missing article fragment Stan@rti.com mentioned. The bug has (likely) been fixed. In case you haven't noticed, I turned on the cross-coupling of the newsgroup and exploder on monday, and aside from this problem it appears to be working. Please send any requests to vxwexplo-request (rather than the exploder) for changes in your subscriptions. Alan K Biocca Exploder Maintainer From daemon@vxw.ee.lbl.gov Fri Jan 31 04:00:25 1992 From: daemon@vxw.ee.lbl.gov Date: Fri Jan 31 04:00:32 PST 1992 Subject: comp.os.vxworks newsdigest Comp.Os.Vxworks Daily Digest Fri Jan 31 04:00:18 PST 1992 Subject: Re: Unimplemented Opcode error Subject: Re: Mv165 and VSB ------------------------------------------------------- Newsgroups: comp.os.vxworks Subject: Re: Unimplemented Opcode error Date: 30 Jan 92 15:57:55 GMT From: winans@xray.aps.anl.gov (John R. Winans) Organization: Argonne National Laboratory, Chicago Illinois Message-ID: <1992Jan30.155755.6183@mcs.anl.gov> References: <1992Jan28.191023.3382@noao.edu> In article hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: > >I've found that often times when things get this bad, the cause is >actually somewhere else, and usually involves some memory locations >having been trashed. For all you know, your task may be executing data >at that point. Notice in your code dump that during normal >execution flow, the program counter should not be 0x0075f2c8, but >either 0x75f2c4 or 0x75f2ca. >I'd look for stack overflows (checkStack()) or other stack corruption. >Since the rlogin requires CPU cycles (and netTask is usually higher >than application code, by default), your application may not get >enough cycles and, if you are using interrupts, the interrupt stack >might be exceeded. The first thing to try might be to increase your >application task priority above that of the netTask and see if that >makes any difference. I agree with your comments. But let me add an observation: The origionator of this thread mentions that he is using version 5.0.2. We here recently converted from a 4.x release to 5.0.2. We recompiled all our code to find that every now and then we were crashing for no reasonable cause. After some poking around, we noticed that all tasks have stacks that are about 0x800 bytes smaller than they did under 4.x. Some poking around the new manual showed that a task's TCB is now cut out of its stack. So, if you are a byte counter... don't forget about the TCB size too! - -- ! John Winans Advanced Photon Source (Controls) ! ! winans@mcs.anl.gov Argonne National Laboratory, Illinois ! ! ! !"The large print giveth, and the small print taketh away." - Tom Waits ! --------------------------- Newsgroups: comp.os.vxworks Subject: Re: Mv165 and VSB Date: Thu, 30 Jan 1992 19:50:14 GMT From: james@wrs.com (James Moore) Organization: Wind River Systems, Inc. Message-ID: References: <9201292237.AA07232@tomato.lbl.gov> hmp@frc2.frc.ri.cmu.edu (Henning Pangels) writes: >...it took me a >while to realize that the "m" command performs (I believe) 16-bit >accesses, while the particular device I was trying to tinker with only >responded to byte access. True, but don't forget that the source to 'm' is sitting in somedir/vw/config/all/usrLib.c (and bootLib.c), which you've got. Easy to modify if you need something non-standard. - -- James Moore | james@wrs.com Wind River Systems Engineering | --------------------------- End of New-News digest ********************** From abenett@lodestar.gb.nrao.edu Fri Jan 31 06:06:51 1992 From: abenett@lodestar.gb.nrao.edu (ARON BENETT) Date: Fri Jan 31 06:07:00 PST 1992 Subject: Vxworks cross-compiler and GNU g++ Version 1.40.3 Could anyone give me some tips on getting GNU g++ V1.40.3 to work with the Vxworks V5.0.1 GNU Toolkit. We are currently using the VxWorks cross compiler V5.0.1 with gcc 1.37.1. I notice in the makefile there is a section to make cplus but the cplus .o objects are not included on the tape. When I talk with tech support at Wind River, they say that a supported version will not be out until 4th quarter 92. Does anyone know if I just take the objects from g++ 1.40.3 and link them in via the makefile will they work. I also see that there are a set of class libraries and header file on the NETLIB index. Are these needed to get the system up and running. Any information would be greatly appreciated. Thanks. ---------------------------------------------------------------------------- Aron Benett National Radio Astronomy Observatory P.O. Box 2 Green Bank, W.Va. 24944 voice: (304)456-2214 Internet: abenett@lodestar.gb.nrao.edu From iphasew!hwajin@apple.com Fri Jan 31 12:34:52 1992 From: hwajin@iphasew.com (Hwa-Jin Bae) Date: Fri Jan 31 12:34:58 PST 1992 Subject: Re: Slow NFS read >>>>> On Fri, 31 Jan 92 04:05:31 Bill Frewing said: Bill> 3 & 4 seem to indicate that the SBC is retrying but why it is Bill> doing so is a mystery to us! When using the vxWorks ???Show Bill> commands none of the reports show any errors. We have tried Bill> ipstatShow(), tcpstatShow(), icmpstatShow() & udpstatShow() (in Bill> each case we called the function from the vxWorks shell without Bill> any parameters). You should also try ifShow() which reports statistics available for a all network interface drivers. Pay special attention to "ierrors" (input errors) field. As I said before, I have found out by working with board manufacturers that on some boards that have on-board LANCE devices, CRC and/or Frame errors are generated for perfectly good frames received; that is, the LANCE lies about the error condition. When this happens the VxWorks LANCE driver drops the packet and increments input error count. This problem was attributed to the use of too low farad capacitors between the power source and the LANCE VCC/VSS pins. -- Hwa-Jin Bae Interphase West From Christina_Goette@wrs.com Fri Jan 31 13:59:51 1992 From: Christina Goette Date: Fri Jan 31 13:59:58 PST 1992 Subject: West Coast Users Group Meet Subject: Time:1:43 PM OFFICE MEMO West Coast Users Group Meeting Date:1/31/92 The next annual West Coast VxWorks Users Group Meeting is scheduled to be held in Southern California this April. Tentatively, the date has been set for April 10, 1992. We are looking for a VxWorks user to chair the meeting. Chairing a meeting involves setting the agenda, inviting users to present, and running the meeting. Time commitment on the volunteer's part is fairly minimal as Wind River Systems will handle the administrative details such as mailings, registration, and facilities. Watch this space for more information about the meeting. If you are interested in chairing this meeting or have questions, please contact me via e-mail at tina@wrs.com, or at 1-800-545-9463 x2050. Thank you. Christina Goette Wind River Systems From news@fdm.fujitsu.co.jp Fri Jan 31 14:53:17 1992 From: news@fdm.fujitsu.co.jp Date: Fri Jan 31 14:53:25 PST 1992 Subject: Rejected news: No send to JUNET ----- Unsent reason follows ----- User "vxwexplo@lbl.gov" is not authorized. ----- Unsent message follows ----- Path: fdm!fdm-cnews!fgw!sh.wide!wnoc-tyo-news!rena!tdo!tkymail!nddsun1!spsgate!uunet!uunet!elroy.jpl.nasa.gov!ames!agate!dog.ee.lbl.gov!lbl.gov!vxwexplo From: vxwexplo@lbl.gov (vxWorks Exploder) Newsgroups: comp.os.vxworks Subject: RE: NFS read very slow Message-ID: <9201290056.AA25895@arete> Date: 29 Jan 92 00:56:30 GMT Sender: vxwexplo@lbl.gov Organization: Lawrence Berkeley Laboratory, Berkeley CA Lines: 22 NNTP-Posting-Host: 128.3.112.16 Submitted-by: reder@arete.lbl.gov (Leonard J. Reder) Originator: daemon@vxw.ee.lbl.gov > On some eariler rev's of mv147's (there were a number of rev's) and > other '030 based SBC's there were some hardware problems (the LANCE > would report CRC and Frame error when in fact the packet received > was okay -- caused by power glitch due to insufficient capacitance) > that only occurred when a lot of back-to-back packets were received > from the network. A lot of packets get dropped at the LANCE driver > level when this happens. Thus, my suggestions for further investigation... > > Hwa-Jin Bae > Interphase West > At one point we had a problem of unreliable data com with our MV147S board due to a problem with the LANCE hardware on the board. This caused very slow net data rates. Finally it was fixed by sending the board back to Motorola for an upgrade to Rev. E (I think..). Everything with the board and socket level communications seems to function normally now. I originally recall reading about this problem in one of the WindWord news letters from WRS. You may wish to contact WRS for the specifics. Len Reder Arete Associates From jupiter!bob@uunet.uu.net Fri Jan 31 18:46:49 1992 From: bob@jupiter.com (Bob Schulman) Date: Fri Jan 31 18:47:01 PST 1992 Subject: RE: NFS read very slow > On some eariler rev's of mv147's (there were a number of rev's) and > other '030 based SBC's there were some hardware problems (the LANCE > would report CRC and Frame error when in fact the packet received > was okay -- caused by power glitch due to insufficient capacitance) > that only occurred when a lot of back-to-back packets were received > from the network. A lot of packets get dropped at the LANCE driver > level when this happens. Thus, my suggestions for further investigation... Actually, *all* rev's of the 147 have this problem. We had to use a WRS-supplied hack to get our 5.0.2 NFS reads running at (more or less) full speed. The WRS-supplied hack was to change LN_DATA_WIDTH from "NONE" to "4" (in mv147.h). This was verified with the latest rev board. bob From thor@thor.atd.ucar.edu Fri Jan 31 22:56:53 1992 From: thor@thor.atd.ucar.edu (Richard Neitzel) Date: Fri Jan 31 22:57:01 PST 1992 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 1604 -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 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 14:07 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 12:12 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 8807 Jan 16 13:30 index -rw-r--r-- 1 thor 2694 Oct 9 1990 ivecalloc.shar -rw-r--r-- 1 thor 27824 May 30 1989 jobCondLib -rw-r--r-- 1 thor 25014 May 30 1989 jobLib lrwxrwxrwx 1 root 10 Aug 14 07:11 jobcondlib -> jobCondLib lrwxrwxrwx 1 root 6 Aug 14 07:11 joblib -> jobLib -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 07:11 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 55175 Oct 21 09:11 ntpvx01 -rw-r--r-- 1 thor 55174 Oct 21 09:11 ntpvx02 -rw-r--r-- 1 thor 50076 Oct 21 09:11 ntpvx03 -rw-r--r-- 1 thor 39603 Oct 21 09:11 ntpvx04 -rw-r--r-- 1 thor 28719 Oct 21 09:11 ntpvx05 -rw-r--r-- 1 thor 32494 Oct 21 09:11 ntpvx06 -rw-r--r-- 1 thor 37097 Oct 21 09:11 ntpvx07 -rw-r--r-- 1 thor 41621 Oct 21 09:11 ntpvx08 -rw-r--r-- 1 thor 20494 Oct 31 12:06 pipe.shar -rw-r--r-- 1 thor 15418 May 30 1989 poolLib lrwxrwxrwx 1 root 7 Aug 14 07:11 poollib -> poolLib -rw-r--r-- 1 thor 13204 Oct 31 08:19 ring.shar -rw-r--r-- 1 thor 6614 May 31 1989 semCnt lrwxrwxrwx 1 root 6 Aug 14 07:11 semcnt -> semCnt -rw-r--r-- 1 thor 2308 Jan 2 1990 ss1.bnch -rw-r--r-- 1 thor 16225 Oct 10 1989 string.shar -rw-r--r-- 1 thor 15096 Oct 2 08:55 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 25790 Nov 8 1990 ty335.shar -rw-r--r-- 1 thor 25814 Apr 26 1989 vtape.shar -rw-r--r-- 1 thor 43671 Nov 22 14:05 vwcurses01 -rw-r--r-- 1 thor 40180 Nov 22 14:05 vwcurses02 -rw-r--r-- 1 thor 38308 Nov 22 14:05 vwcurses03 -rw-r--r-- 1 thor 31181 Nov 22 14:05 vwcurses04 -rw-r--r-- 1 thor 31798 Nov 22 14:05 vwcurses05 -rw-r--r-- 1 thor 31459 Nov 22 14:05 vwcurses06 -rw-r--r-- 1 thor 24279 Nov 22 14:05 vwcurses07 -rw-r--r-- 1 thor 29720 Aug 28 14:10 vxrsh.p1 -rw-r--r-- 1 thor 26002 Aug 28 14:10 vxrsh.p2 -rw-r--r-- 1 thor 13713 Aug 28 14:10 vxrsh.p3 -rw-r--r-- 1 thor 4702 Jan 16 13:28 wdog_class -rw-r--r-- 1 thor 4168 Jan 16 13:30 xxx Unix sources: total 82 -rw-r--r-- 1 thor 1192 Mar 13 1990 index drwxr-xr-x 2 thor 512 Oct 26 1989 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 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.