3c905C and autonegotiate

[Bogdan Costescu]

Dear Mr. Becker, dear list members,

I have several 3c905C cards which are not initialized properly by the
current driver (0.99L). While the partner is a full-duplex switch
(BayStack 350-24T) set to autonegotiate, it seems that the cards are set
to 100baseTx, but only in half-duplex mode (verified on the switch and
with vortex-diag). I can also force them in 10baseT-FD and HD and
100baseTx-HD, but not in 100baseTx-FD (also reported by both the switch
and vortex-diag). However, using 3Com's driver (without any options), the
card goes to 100baseTx-FD from the beginning and I'm also able to force
it into this mode.
I did the same tests with a 3c905B card and this one works properly
(autonegotiate to 100-FD, force to every mode).

Then I took a look at the 0.99L source code. First of all, I noticed that
in the info table (pci_tbl), 3c905C is only set to IS_CYCLONE, while B-Tx 
is set to IS_CYCLONE | HAS_NWAY. Is there any good reason for dropping the
N-WAY support for the C revision?
Anyway, I set HAS_NWAY for 905C and went further. Now, vortex-diag reports
Autonegotiate for Transceiver type in use (previously was 100baseTx), and
the card is set to 100MBit/s, but still half-duplex.

I tracked the problem to the setting of vp->full_duplex, precisely to :

	if (vp->info1 & 0x8000)
		vp->full_duplex = 1;

I used printk to see what is there:
	-rev. B	= 0x8001
	-rev. C = 0x0001
So that's the difference.

Then I used the 3c90xcfg DOS-based utility and set the card to 100/FD (it
was in Auto/N-WAY); it seems like now I also get for the C rev. 0x8001 in
eeprom[13] (which is read in vp->info1), but I get the forced settings in
config.u.autoselect (0) and config.u.xcvr (4), so no autonegotiation...
Probably I can use vortex-diag to change the eeprom to give me the same
results as the B rev., but is this valid?
Is this change of behaviour between B and C affecting all C cards or I
have some "faulty" cards?

I put it back to Auto/N-WAY (eeprom[13] = 0x0001) and commented the test
for this setting, so that vp->full_duplex is always set to 1 and now I get
autonegotiate and full-duplex. The driver seems to be able to change the
full-duplex status in the timer interrupt (as I said, I set HAS_NWAY),
however no such re-setting is done if HAS_NWAY is not set
(case XCVR_10baseT: case XCVR_100baseTx: case XCVR_100baseFx: branch). So,
the two questions: should vp->full_duplex be set to 1 based on some
other criteria than eeprom[13]? How does the 3Com's driver handle this?

I would suggest setting vp->full_duplex after checking (and reading if
possible) for the MII transceiver, when the MII info should have priority
over eeprom[13].

Best regards,

Bogdan Costescu

Systemadministrator, IWR, Uni Heidelberg
INF 368, D-69120, Heidelberg, Tel: 06221-548869, Fax: 06221-548868
E-mail: Bogdan.Costescu@iwr.uni-heidelberg.de