Subject: qe0 overrun
To: None <port-vax@NetBSD.ORG>
From: None <rick@snowhite.cis.uoguelph.ca>
List: port-vax
Date: 05/16/1996 10:40:04
I haven't looked at if_qe.c in a looonnnggg time, but I suspect this may
explain it:

- The DEQNA has a wonderful attribute, in that it will "just stop working"
  under certain heavy load conditions. (DEC had a whole bunch of engineering
  revs of this board, but I don't think the problem was ever really fixed:-)
  As such, if the driver hasn't seen an interrupt from the board for a while,
  it must assume the worst and reset the hardward to get it working again.
  (If it is just an inactive network, the reset is unnecessary, but harmless.)
  In the old days, the driver did this silently (ie. without generating a
  message). I suspect that "qe0 overrun" is being generated when this happens.
  (A ring overrun was one of the ways the hardware would get confused and
   "die". In this case, I believe that the firmware actually just kept
   accessing the next ring buffer descriptor, loopin around, but I'm not
   sure.)

Take this with a grain of salt, since it has been a long time, rick