RE: DEQNA info

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Wednesday, June 18, 2014 at 10:35 AM, Mouse wrote:
> sys/dev/qbus/if_qe.c says, in part, even in -current according to cvsweb,
> 
>         /*
>          * How is the DEQNA turned in ALLMULTI mode???
>          * Until someone tells me, fall back to PROMISC when more than
>          * 12 ethernet addresses.
>          */
> 
> I have a digital copy of EK-DEQNA-UG-001 from bitsavers which appears to
> answer this question (though the wording of the first sentence is a little
> confusing; I believe there is a "count" missing after the first "byte"), 
> which I
> quote here in case anyone wants to pick it up and do something with it.  (I
> will, but not in any NetBSD version I expect NetBSD to care about.)
> 
> 4.3.3.2 Operating Condition Set-Up - When the byte exceeds 128 (177 octal),
> bits 06:00 of the byte count are used as control parameters, and are
> interpreted as follows.
> 
> Bit           Definition
> 
> 00            All Multicast. When set, enables the DEQNA to recognize
>             any multicast address.
> 
> 01            Promiscuous. When set, enables the DEQNA to recognize any
>             destination address.
> 
> 03:02         LED Value. These two bits cause the three LEDs on the
>             DEQNA to turn off in the following sequence (all the LEDs
>             are turned on at power-up and when boot/diagnostic code
>             is loaded from the BD ROM).
> 
>               00        No effect.
> 
>               01        Turns off the first LED, indicating the DEQNA
>                       self-test is running in the host.
> 
>               10        Turns off the second LED, indicating all
>                       internal loopbacks appear to function
>                       correctly.
> 
>               11        Turns off the third LED, indicating
>                       externalloopback appears to function correctly.
> 
> 06:04         Sanity Timer Time-Out Value.  [...[
> 
> It is not clear to me whether this is "of the byte count value in the 
> descriptor"
> or "of the actual count of bytes according to the descriptor", since the 
> buffer
> descriptor contains the *negated* byte count.  If I had a MicroVAX-II in
> usable shape, I'd experiment with this to find out, but, at the moment, I
> don't - they're still buried from my move.

There was some ambiguity in this domain when I worked out the simh simulation 
of the DEQNA/DELQA/DELQA-T devices.

Here are the comments from what I did there:

  /*
     Under VMS the setup packet that is passed to turn promiscuous 
     off after it has been on doesn't seem to follow the rules documented 
     in both the DEQNA and DELQA manuals.
     These rules seem to say that setup packets less than 128 should only 
     modify the address filter set and probably not the All-Multicast and 
     Promiscuous modes, however, VMS V5-5 and V7.3 seem to send a 127 byte 
     packet to turn this functionality off.  I'm not sure how real hardware 
     behaves in this case, since the only consequence is extra interrupt 
     load.  To realize and retain the benefits of the newly added BPF 
     functionality in sim_ether, I've modified the logic implemented here
     to disable Promiscuous mode when a "small" setup packet is processed.
     I'm deliberately not modifying the All-Multicast mode the same way
     since I don't have an observable case of its behavior.  These two 
     different modes come from very different usage situations:
        1) Promiscuous mode is usually entered for relatively short periods 
           of time due to the needs of a specific application program which
           is doing some sort of management/monitoring function (i.e. tcpdump)
        2) All-Multicast mode is only entered by the OS Kernel Port Driver
           when it happens to have clients (usually network stacks or service 
           programs) which as a group need to listen to more multicast ethernet
           addresses than the 12 (or so) which the hardware supports directly.
     so, I believe that the All-Multicast mode, is first rarely used, and if 
     it ever is used, once set, it will probably be set either forever or for 
     long periods of time, and the additional interrupt processing load to
     deal with the distinctly lower multicast traffic set is clearly lower than
     that of the promiscuous mode.
  */

- Mark