Experimental Physics and
Industrial Control System

[email protected] (John R. Winans) · Sun, 9 Mar 1997 10:40:50 -0600

> I'm setting up a MVME177 to run vxWorks here at Argonne.  I got the
> BSP from WindRivers and installed it.  When I boot from
> a Sun OS 4.1.3 host it works, when I boot from a Sun Solaris 2.5.1
> host the vxWorks image loads (using ftp) and the vxWorks.sym
> file download fails with a 0x1a9.
> 
> The code that does the download for the MVME177 is the same as the
> MVME167 - it invokes ftpXfer().  The 177 ftpXfer() fails and
> the 167 ftpXfer() works fine.  I think there is a problem in ftpXfer()
> when it attempts to reconnect to a port on the Solaris host to
> transfer vxWorks.sym and the port is still busy from the vxWorks file
> download.
> 
> Has anyone experienced a similar problem?  If so, how did you
> resolve it?

Can I assume you are still using 5.1????????

The reconnecting to an identical port number has been a problem since day-1.
Reconnects come in two flavors.  the rebooting of an IOC too soon since
the last reboot, and the blasted kernel deciding to recycle a port number
too soon for no good reason.

The issue with SunOS -vs- Solaris has to do with how long the OS leaves a
TCP socket in TIME_WAIT.  Solaris defaults it to something like 5 minuites.
I don't know abouT SunOS, but the BSD docs and code I read tend to free
up the ports after 1 RTT or some such thing.

The baloney where vxSometimesWorks tries to use the same port from the
server two times in a row is simply broken.  As I recall, the boot roms
are hard-coded to use port N when ftping the kernel image, then it branches
to it to load the rest of the files.  You might have noticed that the 
kernel is built from the same files (with the same hard-coded port numbers
in them) as is the boot ROM images.  Thus  we end up seeing the same port 
used two times in a row.

I recall killing a week on this in the past and that once the second
download fails, the rest go OK.  Unfortunately, I never found any use 
for that knowledge.

The last time I saw this specific problem was with a new BSP for one
of the variants of the 162 or the 167.  WRS sent me a new .o file for one
of the components... I can see it sitting in the mv162 build on phoebus.
Look at /usr/local/vw/vxV52p1/patches/ftPXfer_MC68040/README

WRS is probably still shipping bogus code and doing themselves a GREAT 
disservice by not including a note card that reads something like this:

	WARNING: This product will not operate as advertised!  Please read
	the unenclosed release notes.  Then proceed to replace everything 
	in this package with your newly compiled replacement built from
	random patches hiding on our web site.  Good luck finding a supplier 
	of your no-longer mass-produced eproms and/or figuring out how to 
	download and burn your flash memories on Solaris without any flow 
	control on your serial ports.

--John Winans

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System