Re: DEC LANBRIDGE problems?


Tait Cyrus (pprg.unm.edu!cyrus@hc.dspo.gov)
22 Oct 88 22:52:34 GMT


In article <8810191208.AA16623@msr.epm.ornl.gov> dunigan@MSR.EPM.ORNL.GOV (Tom Dunigan 576-2522) writes:
>Newer models of DEC's LANBRIDGE 100 apparently will "learn" the
>broadcast address if there is a sick engine on the Ether that
>emits packets with a source addresss of all 1's (broadcast).

I posted this to comp.dcom.lans, but since the topic came up, I
will post here as well.

There has been A LOT of talk lately concerning DEC LANBridges learning
ff-ff-ff-ff-ff-ff (the broadcast address). Well, as I posted a few
days ago, I thought that I saw a relation between seeing these packets
and an IBM PC/RT booting.

Well, after some tests, we have hard evidence showing that an IBM PC/RT
running "IBM Academic Operating System 4.3" sometimes produces giant
packets or packets containing garbage upon boot up. Unfortunately,
the data contained in these packets is mostly 1's which puts some DEC
LANBridges into a bad state.

Below are the results of our tests. We have not fully tested AIX to
see if it also has the same problems, though preliminary tests indicate
that AIX does NOT have these problems.

Ways which do NOT cause it to generate bogus packets:
        - reboot while running (i.e. using reboot/shutdown/halt/etc)
        - software reset (i.e. CNTRL-ALT-Pause) while running

Ways which DO cause it to generate bogus packets:
        - halt & wait for "halting (via wait)" message -> power off ->
                power on -> normal reboot
        - halt & wait for "halting (via wait)" message -> software reset
                via CNTRL-ALT-Pause @ wait for boot prompt ":" ->
                power off -> power on -> normal reboot
        - simulated power hit (power off while running)

The two places in the boot process that we have seen these bogus packets
produced are:
1) when the ethernet device is probed when the kernel is
   looking for devices (marked with ---> below).

        4.3 BSD UNIX (GENERIC) #1: Fri Sep 23 10:32:48 PDT 1988
            ibmacis@clam:/usr/sys/GENERIC

        5799-WZQ (C) Copyright IBM Corporation 1986,1987
        All Rights Reserved
        Licensed Materials - Property of IBM

        Using 238 buffers containing 716K bytes
        Memory summary: total 12288K (0xc00000), available 10196K (0x9f5000)
        AFPA marked down pending microcode load and initialization.
        68881 enabled.
        autoconf
        hdc0: card level 0x4b microcode level 0x46 configuration bits 0xc7
        hdc0 adapter f00001f0 IRQ 12 CPU level 4
        hd0 at hdc0 slave 0
        hd0: hd70e; interleave factor is 1 to 1
        hd1 at hdc0 slave 1
        hd1: hd70e; interleave factor is 1 to 1
        hd2 at hdc0 slave 2
        hd2: hd70e; interleave factor is 1 to 1
        fdc0 adapter f00003f2 IRQ 6 CPU level 4
        fd0: 1.2M drive
        fd0 at fdc0 slave 0
        stc0 adapter f00001e8 IRQ 12
        st0 at stc0 slave 0
---> un0 adapter f4080000 IRQ 3 CPU level 3
---> un0: ethernet address 0:dd:0:f8:23:0
        lp0 adapter f00003bc IRQ 7
        psp0 adapter f0008000 IRQ 2 CPU level 3
        root on hd0
        configure end

2) and when the ifconfig is done in /etc/rc.local
        ifconfig ${network} inet ${hostname} ${net_flags}

We will be notifying IBM of these problems, but in the
mean time we thought everyone should be apprised of this
problem.

---
    @__________@    W. Tait Cyrus   (505) 277-0806
   /|	      /|    University of New Mexico
  / |	     / |    Dept of ECE	- Parallel Processing Research Group
 @__|_______@  |    Albuquerque, New Mexico 87131
 |  |	    |  |
 |  |  hc   |  |    e-mail:
 |  @.......|..@       cyrus@pprg.unm.edu
 | /	    | /
 @/_________@/



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:43:56 GMT