Ah. Maybe that's why netbooting of my MicroVAX II didn't work.
Paul
~~~~
--
---------------------------------------------------------------------
Paul Duncan Tel: +44 1703 596385
Information Systems Group,
NERC Research Vessel Services,
Room 451/11,
Southampton Oceanography Centre,
Empress Dock,
Southampton,
SO14 3ZH. E-mail: p...@soc.soton.ac.uk
---------------------------------------------------------------------
"Aaron J. Grier" <agr...@poofygoof.com> wrote:
> except when hooked to DEC hosts! :)
Oh! Should that be turned on when using the Qbus and Unibus ethernet
cards (DEQNA, DELQA, DEUNA, DELUA)?
Is the lack of heartbeat what causes the messages:
Feb 28 17:24:57 vax /netbsd: qe0: ring overrun, resync'd by skipping 6
I thought it was interesting that the skipping number consistently
cycles from 1 through 14.
> Oh! Should that be turned on when using the Qbus and Unibus ethernet
> cards (DEQNA, DELQA, DEUNA, DELUA)?
Yes. SQE should only be turned off when a transceiver is hooked to a
repeater or a multiplexer (like a DELNI). For hosts it should be left
_ON_.
> Is the lack of heartbeat what causes the messages:
>
> Feb 28 17:24:57 vax /netbsd: qe0: ring overrun, resync'd by skipping 6
>
> I thought it was interesting that the skipping number consistently
> cycles from 1 through 14.
I have no idea. I've never seen this on my uVAX-II... (but then again,
I have SQE enabled. ;P )
--
Aaron J. Grier | "Not your ordinary poofy goof." | agr...@poofygoof.com
"Time Correct function allows automatically correcting slight variation
of your key touching manner." -- Roland MSQ-700 manual
The qe0: overrun ... resync messages are due, in part to some bogus code in
the qe0 driver. Buck's fix was to comment out the *message* the error still
occurs. In the -current kernel Ragge has re-written most if not all of the
driver and this message no longer appears (although another message
"transmit jam, resetting, sometimes does occur". I don't know if the change
is in 1.4.2 but the driver in current doesn't have this problem.
The -YM version of the DELQA is also known as the DELQA-Turbo. It can
handle back to back ethernet packets and has better on board buffering. It
is also the "best" Q-bus ethernet interface DEC ever made (I don't know if
the DESQA uses the Toshiba part or the Lance part)
DEQNA's are pretty poor performers but are not taxed by most PDP-11's
(except perhaps the 11/8x or 11/9x variants. They are unique in that they
can allegedly change their MAC address by replacing an on board PROM. (Not
that you'd want to, but you can do it.)
--Chuck
> So I tried flipping it. This had no obvious effect on the VAX; NetBSD
> continued to work just fine, but it also continued to write those darn
> "qe0: ring overrun, resync'd by skipping" messages to the console.
>
> There was a message in the archives a few years ago about this problem,
> but no resolution. Do other people using DELQAs not experience this?
I've always had that problem. The only thing that makes it go away is
commenting out the line in the source code and compiling a custom kernel :).
-J. Buck Caldwell
What, then, is 'the line', please? I had that problem when attempting to
netboot NetBSD, so if there's a fix available, I'd like it for future
reference.
Dan
--
dan...@ox.compsoc.net
'Common sense is a set of prejudices built up over a lifetime'
--I reserve the right to be completely wrong about any comments or
opinions expressed--
> DEQNA's [...] They are unique in that they
> can allegedly change their MAC address by replacing an on board PROM.
Should be possible on the DELQA as well. Both the turbo and non-turbo
ones that I've seen have a socketed PROM for the address. I think both
the DEQNA and DELQA use an 82S23 PROM (32 bytes) for this, though I
haven't tried swapping them.
I was using a transceiver that had previously been successfully used on
other hosts. I hadn't changed the configuration. There is an SQE switch,
but the labelling makes it completely unclear as to which position is _ON_.
So I tried flipping it. This had no obvious effect on the VAX; NetBSD
continued to work just fine, but it also continued to write those darn
"qe0: ring overrun, resync'd by skipping" messages to the console.
There was a message in the archives a few years ago about this problem,
but no resolution. Do other people using DELQAs not experience this?
I tried several DELQAs, and got the same behavior with all of them.
[snip]
> What *is* this SQE, heartbeat, whatever it's properly called? In
> particular, what does it have to do with connecting to a real host vs
> connecting to the station port of a multiport device?
SQE is "Signal Quality Error", originally CPT or "Collision Presence
Test" in the original DIX spec.
Basically, it's meant for ethernet cards talking to a transceiver. When
the card sends a packet out, the transceiver "acknowledges" the
reception (and transmission on the wire) by sending a short collision
signal back to the host (_only_ the host - it doesn't go out on the
wire). This way the host can tell that the transceiver is
attached and functioning (powered, etc...).
The problem is this: if you put a tranceiver on a hub (or repeater,
etc...), this short SQE collision signal is taken by the hub as an
_actualy_ collision. Since the hub can't really tell an SQE from a
collision, this "false" collision propigates over the network, and
generally dampens the performance (and people's moods :-).
Also, most software doesn't deal correctly with the SQE, and treats it as
a real collision.
A quick, but more in depth explaination is at:
http://www.stratacom.com/warp/public/86/12.html
-Jon
--------------------------------------------------------------------
"Can you count my penny?" | NetBSD on i386, Alpha, VAX, NeXT, SPARC,
"One!" | Mac68k, and hopefully more...
regards,
Nigel Johnson VE3ID
Ding this was SOP for DEC field service and recommended unless it was known
the address could vary. For mop boot, you need the physical address and if
you have a LAVC setup then you like having the address remain the same.
Hence the socketed prom.
Allison
> Yes. SQE should only be turned off when a transceiver is hooked to a
> repeater or a multiplexer (like a DELNI). For hosts it should be
> left _ON_.
What *is* this SQE, heartbeat, whatever it's properly called? In
particular, what does it have to do with connecting to a real host vs
connecting to the station port of a multiport device?
der Mouse
mo...@rodents.montreal.qc.ca
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
> DEQNA's are pretty poor performers but are not taxed by most PDP-11's
> (except perhaps the 11/8x or 11/9x variants. They are unique in that they
> can allegedly change their MAC address by replacing an on board PROM. (Not
> that you'd want to, but you can do it.)
All DEC Ethernet controllers (atleast those usable on VAXen and PDP-11s)
can change the MAC address by software.
I would guess that the initial MAC address is decided by some ROM on all
of them, which obviously can be changed.
Johnny
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@update.uu.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol