[3224] in Release_7.7_team
Re: A theory...
daemon@ATHENA.MIT.EDU (Bogdan Costescu)
Tue Apr 2 11:31:10 2002
Date: Tue, 2 Apr 2002 18:30:53 +0200 (CEST)
From: Bogdan Costescu <bogdan.costescu@iwr.uni-heidelberg.de>
To: Bill Cattey <wdc@MIT.EDU>
cc: release-team@MIT.EDU
In-Reply-To: <1017453288.2360.49.camel@tokata.mit.edu>
Message-ID: <Pine.LNX.4.44.0204021749090.19717-100000@kenzo.iwr.uni-heidelberg.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Hi,
Sorry for the late reply, I've been away for Easter...
On 29 Mar 2002, Bill Cattey wrote:
> So I have empirical evidence that my 3c905c's could get into a state
> where they thought they were not on the network, even across a power
> cycle of the machine.
Did you by any chance exchanged switch ports during these tests or the
cards were always connected to the same switch ?
In the thread that I pointed to you in an earlier message, I described my
problems encountered after the change (to not reset the transceiver when
the driver is initialized) was done to the driver. Because I played a lot
with setting/resetting media options (through module options and
mii-diag), at some point I couldn't get the link to come up at all.
"mii-diag -r" didn't help, "mii-diag -R" didn't help, turning off the
computer didn't help (to clear whatever bits might have gone wrong). The
cable was obviously good as it worked fine several minutes before, so the
only thing left was the switch. I took a laptop with (I think) an Intel
network card and connected it to the port and it worked, then I connected
again my computer and it worked (including autonegotiation) without any
additional operation (like fiddling with mii-diag), so the only thing that
I was able to think of was that the switch port got into some strange
state which was somehow reset when I connected the other network card to
it. BTW, that was a Cisco 4000 series switch.
> Issuing mii-diag -R fixed the condition.
That makes me wonder if instead of providing a module option to restart
autonegotiation (equivalent of "mii-diag -r") we should provide one for
resetting the transceiver ("mii-diag -R").
I didn't see anything out of ordinary in the dumps that you sent me in
your previous message... except for a place where the advertisment was for
only "Flow control" instead of "Flow control 100baseTx-FD 100baseTx...".
In this case is somehow normal that no negotiation could take place as
there is no common set of capabilities.
> Could we have a bug in the chip such that the power-on reset logic is
> not making the link-detect status come from the right place when we
> toggle back from force MII?
As we have no specific documentation about this "strain" of chips, it's
impossible to say if there is a bug, a feature or something else... The
chips already behave different from others w.r.t. activating the
transceiver based on EEPROM settings, so only 3Com knows what else is
different in the rest of the chip...
> Could the reason why mii-diag -R corrected the problem was that it
> cleared and set linkBeatEnable sending us through another route in the
> chip config system to get that link beat status from the right place?
>
> Sounds crazy, but that's my guess based on the information I have.
Well, it seems like your guess is as good as any other on this issue. 8-)
--
Bogdan Costescu
IWR - Interdisziplinaeres Zentrum fuer Wissenschaftliches Rechnen
Universitaet Heidelberg, INF 368, D-69120 Heidelberg, GERMANY
Telephone: +49 6221 54 8869, Telefax: +49 6221 54 8868
E-mail: Bogdan.Costescu@IWR.Uni-Heidelberg.De
