Penny for your thoughts (on DECchip)
B. James Phillippe
Sun Aug 9 03:34:46 1998
On Sat, 8 Aug 1998, Donald Becker wrote:
> [[ Quick note: the 0.89K version puts a 21143w/MII into Rx-all mode.
> Look for 0.89L in a few hours. ]]
Excellent, I'll try it out ASAP, and let you know the results. Looks like
a lot of changes; I'm eager to test the 21143/MII support. 8)
> On Sat, 8 Aug 1998, B. James Phillippe wrote:
> > In my case, I have boards with the (common) QS6611 tranceiver. I spoke to
> > an engineer at Digital/Intel who informed me that with this tranceiver it
> > is not possible to do NWay for 100base-Tx. There is no MII on my board.
> Check out the QS6611 datasheet at
Okay, I'll take a look at this, too. I have a .pdf file from
developer.intel.com that has some information on this tranceiver, also, but
I don't recall seeing anything in there that jumped out at me. BTW, I
found that some of our test boards do seem to have MII tranceivers. It's
wacky, really; they're all supposed to be identical, but both tulip.o and
tulip-diag report MII's on about 1/4 of the NIC's. Is it possible that a
mis-programmed SROM or other board problem would produce a phantom MII?
I can't see anything physically different on them..
> This transceiver includes specific support for the NWay autonegotiation.
> Note that the autonegotiation must take place on the 10baseT link beat, so
> you can't start at 100mbps. Once the driver has decided that
> autonegotiation has failed it should switch to auto-sense mode, looking for
> link beat first at 10mbps, then at 100mbps.
Ah... I see. This makes a lot of sense. This "auto-sense" mode you
describe is where you are stopping transmit/receive, setting CSR6 with
appropriate values (for threshold, etc), then resetting SIA and port
activity bits.. and then CSR5 interrupts on link pass? And then test
10/100 link fail bits in CSR12?
> > What drives me nuts though is that Windows98 seems to be able to detect the
> > media type very quickly without a problem. I wonder if they a.) know
> > something we don't, or b.) are polling the controller very rapidly and
> > looking for activity bits.
> The generic Win98 driver, or a card-specific one?
> Is it do NWay, or link beat sensing?
> It's possible the link beat signal is connected to a general-purpose pin.
It's the generic included driver, which I hate to admit seems to work
semi-reliably. It (and the davies driver) can hiccup if you're swapping 10
and 100 quickly, and then can get "stuck" at 10Mbit on a 100Mbit cable.
Then you have to pop it back in. I don't know if the Windows driver does
NWay, but there is near-zero delay between switching media types.
> > Is this SROM decoding what you mean when you refer to the
> > EEPROM media table? How does this work? I can't seem to find any further
> > information in any of the material I have.
> Digital calls it the "SROM" (Serial ROM). It's always an EEPROM, so I call
> it that.
> Digital has published about a zillion version of the SROM table description.
So using this table description (assuming an accurate one was available)
would allow you to determine the media type of a connection? It seems that
if this were possible, it would be much smarter/easier for there to just be
a word in a CSR that would indicate this information(?) The only part of
the EEPROM I can identify is the MAC address. :( I suppose I can run
tulip-diag -e -e -f when connected to different media types...? Perhaps
this will educate me further..
> Oh, and most versions are only available in MSWord version-de-jour.
> [[ I just deleted a very nasty comment.. ]]
Darn, and deprive me of the free entertainment.
B. James Phillippe <firstname.lastname@example.org>
Linux Software Engineer, WGT Inc.