Conference noted::atm

895.0. "ATMworks 350 -> panic when configuring" by EVTAI1::BROCHARD (Manuel Brochard - French CSC) Tue Apr 08 1997 09:01

    
    Hi,
    
    	I'm a beginner with ATM technology under Digital Unix. 
    	
    	One customer has plugged a AtmWorks 350 (DEC DGLPB ATM) in his
    	AlphaStation 255/233 running Digital Unix v4.0A.
    
    	When the system is power off/on the dia output (after a boot)
    	looks like :
    	
>        pci1000 at pci0 slot 12
>        lta0: Microcode Version: 1.11, Hardware Rev: 0.04
>        lta0 at pci1000 slot 0
>        lta0: DEC DGLPB ATM Interface, hardware addresses:
>            08-00-2B-80-82-28
>            08-00-2B-80-82-29
>            08-00-2B-80-82-2A
>            08-00-2B-80-82-2B
>            08-00-2B-80-82-2D
>            08-00-2B-80-82-2E
>            08-00-2B-80-82-2F
>        ATM Subsystem configured with 1 restart threads
>        ltaregister: registered unit 0 with CMM
    and
>   	ATM Subsystem configured with 1 restart threads
>       ATM UNI 3.x signalling: configured
>       ATM IP interface: configured
    
    	But after a warm restart (shutdown -r now) the board initialization
    fails with :
    
>    	 pci1000 at pci0 slot 12
>        otto: RAM location 6c57 wrote 800 read 0
>        otto: RAM test failed
>        lta0: initialization failed
>        lta0 in pci slot 0 not probed
         and
>    	ATM Subsystem configured with 1 restart threads
>       ATM UNI 3.x signalling: configured
>       ATM IP interface: configured
    
    Is this a known feature of the device, that after a warm restart, the 
    	board selftests fails ?
    
    Is slot 12 of pci1000 allow for AtmWorks 350 board ?
    
    
    Then, after a power off/on, when customer tries to configure the board,  	
    the system panics with : 
    		"panic (cpu 0): lta_softreset failed"
    
    or with the following stack trace :
    
>	0 boot
>	1 panic
>	2 ottoinit
>	3 otto_manage
>    	4 otto_manage_up
>	5 atm_cmm_driver_config
>	6 atm_cmm_mmi_private
>	7 atm_cmm_ioctl
>   	8 spec_ioctl
>       9 vn_ioctl
>	10 ioctlbase
>	11 ioctl
>	12 syscall
>	13 _Xsyscall
    
    	I ask the customer to install digital Unix v4.0B and patches.
    
    	Is it time to swap the board ?
    
    Thanks for advices,
    
    	Manuel.
    

    I have never seen that error during reboot. I would not feel too bad
    asking the customer to have the board replaced. It will not hurt to
    get the system upgraded to V4.0B with patches, but my guess is that you
    are seeing a hardware problem.

    >Per