Conference turris::digital_unix

9106.0. "DMS-Problem" by NETRIX::"[email protected]" (Wolfgang Haeckl) Tue Mar 11 1997 11:22

Hello All !!


We have little Problems at Customer-Site with DMS.
On the Beginning some Environment-Data:


DMS-Server:
AServer 4100 4/400, DU 4.0a, FW Rev. v3.0
Networkig over FDDI-Interface 

DMS-Client:
Decstation 3600, DU 4.0a  FW Rev. v6.8
Networkig over FDDI-Interface (PMAF-FA FW-Rev v3.1)

Problem:
When Booting the Client-System over FDDI-Interface some Error-Messages -->

initial Bootstrap is ok (ie. Server found, loading vmunix..)but at second 
bootp-Request -->

Broadcasting BOOTP Request
Retrying bootp: next attempt in 5 seconds
..... Retrying bootp: next attempt in 7 seconds
....... boot_devopen_bp: Unable to access network
boot_devopen: failure to open boot device
Alphaboot: available memory from 0xd96000 to 0x7ffe000
Digital UNIX V4.0a (Rev. 464): Mon Aug 19 23:30:25 EDT 1996
physical memory = 128.00 megabytes
available memory = 114.42 megabytes
using 484 buffers containing 3.78 megabytes of memory
DDR: WARNING: Unable to obtain Device Information Database
     Unable to open file /etc/ddr.db
DDR: WARNING: Basic Defaults will be used

System comes up but with the Error-Messages above.

When booting over Ethernet-Interface all works very clean !!

Are these Messages normal or what's to do against them??

So much for this Client-System.

Got harder Problems with other Clients

DMS-Client:
Alphastation 500,  DU 4.0a  FW Rev. v6.3
Networking over FDDI-Interface (DEFPA FW-Rev v2.46)

Problem:
When Booting the Client-System over FDDI-Interface the first time
the same Problem as above occurs 
(...Broadcasting BOOTP Request
	Retrying bootp: next attempt in 5 seconds
	..... Retrying bootp: next attempt in 7 seconds
	....... boot_devopen_bp: Unable to access network
	boot_devopen: failure to open boot device
	Alphaboot: available memory from 0xd96000 to 0x7ffe000
	Digital UNIX V4.0a ......)
but somewhere (when Client tries to mount root-FS) the System panics an 
syncs disks, that's it!

All works fine when Client is booted over Ethernet !!

Same Problems with 7 more Alphastations500.

What could this cause ?? All the FW-Revs i think are at the newest Level.

For any Help thank you very much in advance !!! 
Nice Greetings from Bavaria

Wolfgang Haeckl
[Posted by WWW Notes gateway]

Sorry Guys sent a wrong Mail-Adress with my Questions
the right one is [email protected]

Bye
[Posted by WWW Notes gateway]

    BOOTP support over FDDI was added to AlphaServer 4100/4000 in the V4.8
    console release. Only MOP boots over FDDI were supported prior to the
    V4.8 release. The V3.0-10 console's readme file and release notes both
    state that BOOTP boots over FDDI are not supported, as do previous SRM
    console versions' release notes.
    
    The V4.8-5 console was released on the V3.9 Alpha FW CD (just started
    shipping). FW's also available on the Web:
    
        ftp://ftp.digital.com/pub/Digital/Alpha/firmware/v3.9/as4x00
    
    Note: V4.8-6 is the latest console and was required to work around an
    SRAM sensitivity issue on the 466 MHz CPU. It didn't make it onto the
    V3.9 CD. V4.8-6 is now being FISed in MFG and is available on the Web
    in the ...firmware/interim/as4x00 subdirectory.

On the DEC 3000 client it's possible that the console callbacks are still
broken for turbochannel option cards.  Can you verify that you have the
latest firmware for both the DEFTA and the DEC 3000 console?


	-- Farrell

[Posted by WWW Notes gateway]

    We have done some more testing om .1 and it seem some kind to work. The
    problem is: If the DMS-Client (Decstation 3600 with PMAF-FA adapter) is
    directly connected to a GIGAswitch/FDDI 4 port line card, then the
    client do NOT boot. In order to trace whats going on, we installed a
    DA30 analyzer between the GIGAswitch and the client. The setup then
    looks like 
    		M-port of GIGAswitch---> B-Port of Analyzer
    		A-Port of Analyzer  ---> S-Port of Client
    
    In thos configuration (which is unwanted, yet legal) we will really
    build up an FDDI Ring. This works fine and we have no Problems to boot.
    
    In the earlier case M-port of GIGAswitch---> S-Port of Client, we run
    probably Digitals FDX and the client does not boot.
    
    Does this sound any reasonable ? I guess we should support the FDX Mode
    during boot.
    
    Thanks	Peter
    
    PS: I have a about 18000 packets trace on when it works. I don't know
    whether this is usefull or not. Tracing FDX Mode is somehow more
    tricky.