Managers:
I'm working with a pair of Alphas running 4.0D - one machine as the host and the other as the dms client, and we're experiencing a conflict of sorts.
The problem shows up when I've got an Alpha running as a host and running our application code. (The application does some communications through sockets with applications that run on the client computers - the full environment has multiple clients, but the problem is reproducible with just the pair)
While the application is running, if I try to boot the client Alpha, it never makes it up all the way. The following is a capture of the console while this is going on:
PU 0 booting
(boot ewa0.0.0.6.0 -flags a)
Trying BOOTP boot.
Broadcasting BOOTP Request...
Received BOOTP Packet File Name is: /clients/dlnetlcf/.vmunix
local inet address: 192.45.xx.xxy
remote inet address: 192.45.xx.xxx
TFTP Read File Name: /clients/dlnetlcf/.vmunix
netmask = 255.255.255.0
Server is on same subnet as client.
...Block FFFFFFF2 is not in any zone
........Block FFFFFFF2 is not in any zone
........Block FFFFFFF2 is not in any zone
.......Block FFFFFFF2 is not in any zone
........Block FFFFFFF2 is not in any zone
........Block FFFFFFF2 is not in any zone
........Block FFFFFFF2 is not in any zone
And it continues, but won't boot until the application running on the host is killed.
Have you seen this before, or do you maybe have an idea what it is?
Is it possible that we're tying up sockets on the host that are needed for the client to do the network boot, and thus the bootp request isn't serviced?
Is it possible that it's something as straightforward as tftp timing out on the bootp, only requiring some adjustment of settings?
Any help would be greatly appreciated.
-Patrick Norris
patrick.norris_at_trw.com
Received on Wed Aug 29 2001 - 20:44:59 NZST