Re: [Fwd: Kernel 2.4 problem with 3C905B NIC]

On Wed, 2003-07-09 at 19:45, Bogdan Costescu wrote:
> On 9 Jul 2003, Edward Tandi wrote:
> 
> > I saved the configuration, re-booted into Linux, reconfigured the 3x59x
> > without any options and hey presto, it works just fine! I can do another
> > dump for you if you like.
> 
> Yes, please, the output from "vortex-diag -ee". I'm curious to see what 
> has changed; I might have missed something...

OK. Here goes:

# vortex-diag -ee
vortex-diag.c:v2.14 12/28/2002 Donald Becker ([email protected])
 http://www.scyld.com/diag/index.html
Index #1: Found a 3c905B Cyclone 100baseTx adapter at 0xd800.
 Station address 00:50:04:0b:1d:ec.
  Receive mode is 0x07: Normal unicast and all multicast.
EEPROM format 64x16, configuration table at offset 0:
    00: 0050 040b 1dec 9055 c594 0036 4a54 6d50
  0x08: 2971 0001 0050 040b 1dec 0020 0000 0022
  0x10: 32a2 0000 0000 0180 0000 0004 0000 10b7
  0x18: 9055 000a 0000 0000 0000 0000 0000 0000
  0x20: 00a7 0000 0000 0000 0000 0000 0000 0000
  0x28: 0000 0000 0000 0000 0000 0000 0000 0000
      ...

 The word-wide EEPROM checksum is 0x51e8.
Saved EEPROM settings of a 3Com Vortex/Boomerang:
 3Com Node Address 00:50:04:0B:1D:EC (used as a unique ID only).
 OEM Station address 00:50:04:0B:1D:EC (used as the ethernet address).
  Device ID 9055,  Manufacturer ID 6d50.
  Manufacture date (MM/DD/YYYY) 12/20/1998, division 6, product TJ.
  No BIOS ROM is present.
 Transceiver selection: Autonegotiate.
   Options: negotiated duplex, link beat required.
 PCI Subsystem IDs: Vendor 10b7 Device 9055.
 100baseTx 10baseT.
  Vortex format checksum is incorrect (cf vs. 10b7).
  Cyclone format checksum is correct (0xa7 vs. 0xa7).
  Hurricane format checksum is correct (0xa7 vs. 0xa7).
      ...

> > there is no mention that the parameters stored in the eeprom _must_ be
> > set a certain way.
> 
> They must not! But there are some cards (and I haven't seen enough data to 
> even start some statistics) that return bogus values when reading from MII 
> registers if the default EEPROM media is not set to auto. This is not 
> documented in any way and I (and probably Don too) have no idea about what 
> is causing this and what can be done to fix it. It's only in these cases 
> that the default EEPROM media setting counts.
> 
> > The Windows driver works without poking.
> 
> Oh, if I'd have access to the source of their Windows drivers and some 
> internal documentation I'd probably be able to explain this and maybe 
> other strange behaviours. As I don't, I can't.
> 
> > The official but unsupported open source 3c90x drivers from 3com work
> > without poking.
> 
> To my knowledge you're the first one that have tried this driver which 
> fixed the problem. It's a good starting point...

Blimey.

> > So why should I have to go and poke?
> 
> Because 3Com did not document this behaviour and what to do to fix it.

I presume we can analyse their open source driver.

> > I would argue that the driver should be clever enough to handle this
> > situation.
> 
> Sure. If we'd only knew how...

Hopefully, we are one step closer now.

Ed-T.


_______________________________________________
vortex mailing list
[email protected]
http://www.scyld.com/mailman/listinfo/vortex