--pgp-sign-Multipart_Thu_Jul_19_15:44:51_2007-1
Content-Type: text/plain; charset=US-ASCII

>>>>> "ga" == Graham Allan <allan@physics.umn.edu> writes:
>>>>> "m" == der Mouse <mouse@Rodents.Montreal.QC.CA> writes:

    ga> I recall there being two possible transceiver boards in the
    ga> PWS.

yeah.  I think I read about that on this list or somewhere like it.
There is a relay somewhere.  there's an interface for you to choose
which 10BaseT you want, the one built into the chip or the one on the
MII-phy.  It's an 'instance' verb to ifconfig.  I couldn't get the
built-in port on mine to work consistently either, though, even
knowing about the possibility to type 'instance'.  Anyway it was
supposed to DTRT without your worrying about it, and I guess it
doesn't always.

    ga> I don't think the tulip was such a bad ethernet NIC - we never
    ga> had any real problems with them...

I've the impression it's a very good chip, too.  There are a few 
problems with them that I know about.

It's a very old 100Mbit/s chip, one of the first, and some versions in
Alphas shipped MII-less with very crappy speed/duplex autodetection
that behaves kind of weirdly and maybe does not respect advertising
and decoding the link-beat-modulation duplex signal.  but the newer
genuine chips and also knockoffs are fine, in this respect anyway.

After the Compaq/HP/Intel business where Digital was passed around
like a greasy rag, there are all these taiwanese knockoffs with
horrible bugs documented in the man page.

I think on FreeBSD, fxp does interrupt mitigation and dc doesn't.
Either do device polling, though.

On NetBSD, the 'tlp' driver prints console messages whenever it counts
a receive error.  This causes two problems.  First, some networks have
so many receive errors that printing the console messages causes the
system to _lose time_.  I've typed 'date' and seen the clock run at
half speed because tlp is so busy printing things to the serial port.
The messages don't seem to be rate-limited at all.

Second, it exposes networks with misconfigured duplex settings that
the sysadmin usually doesn't know about.  Since tlp is the first thing
to call his network broken, he thinks tlp is broken, not his network.

You can tell him ``your network is broken.  You probably have a
machine falsely auto-setting itself to full duplex that's plugged into
a hub.  Find it, and the messages will go away.''  He never believes
you.  If he half-believes, he goes around and checks all these stupid
Windows machines that happily claim to be half-duplex in their system
tray, and assumes that they're not lying, but if the windows machines
have Realtek 100Mbit/s chips, they are probably lying and are
full-duplex no matter what you set them to, no matter what they claim
to be.  If the machines are modern MacBooks, they're also liars.  If
they're NetBSD macs with 'bm' cards in them, they may also be lying
(Mac OS X with 'bm' hardware is fine, though).  Linux machines with
tulip cards lie sometimes, too.  The sysadmin believes the lies and
concludes tlp is broken.  But if you get tlp messages about CRC errors
and dribbling bits, your network *is* broken.  Get some expensive
managed switches and watch your FCS error counters if you still don't
believe me.

I think I will finally give up on hubs, now that I can get cheap
switches on ebay that will do QoS and port SPAN-ing.  so maybe this
problem is outdated now.

     m> Tomorrow I hope to get a PCI ethernet dug out and put in
     m> it...if I can find one that doesn't give SRM fits.  (I tried a
     m> fiber card I had handy, but I got PCI-related machine checks
     m> before even starting to boot.

yeah I got that when I stuck an Adaptec quad-tulip card into a DS10.
I found no way to boot the machine with the card installed.  The same
cards work fine in a PWS433.

--pgp-sign-Multipart_Thu_Jul_19_15:44:51_2007-1
Content-Type: application/pgp-signature
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (NetBSD)

iQCVAwUARp+/M4nCBbTaW/4dAQI5jQQAlcVnvZrIudHWnULm+vmkCyp+zazZI55m
ekKAKDn153cyDV3wsN+903N2q8Mm7FifFzSG3YQVyOSLasx+jbh/ETYnQL38qYUF
e9+2DlR8VN1D7VbX2YWIUbmhKIFE87hUSukHFXWITL1npafhpknp3RCBBS8pmh5L
LT6ItaJxdRE=
=3jrI
-----END PGP SIGNATURE-----

--pgp-sign-Multipart_Thu_Jul_19_15:44:51_2007-1--