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

I have it working properly now, thanks for the help.
Please see comments below...

On Wed, 2003-07-09 at 14:26, Bogdan Costescu wrote:
> On 4 Jul 2003, Edward Tandi wrote:
> 
> > I am currently having problems with the 3c59x driver and I was told that
> > someone at this address (Bogdan?) could help.
> 
> I was away for about 10 days, sorry for the late reply...
> 
> > 3c90x.c driver
> > Transceiver type in use:  Autonegotiate.
> > MAC settings: half-duplex.
> > Your link partner is generating 100baseTx link beat  (no
> > autonegotiation).
> > Link partner capability is 0080: 100baseTx.
> >    Negotiation did not complete.
> 
> This is expected when using a hub.
> 
> > eth0: MII #0 status 0787, link partner capability 0787, info1 8020,
> 
> This looks very strange...
> 
> >  MII PHY #0 transceiver registers:
> >    0787 0787 0787 0787 0787 0787 0787 0787
> 
> ... and this is the reason. All media related operations would probably
> fail to work because of this. We've seen situations where te MII registers
> would look bogus when the default media in EEPROM was set to something
> else than auto/NWAY while the driver was trying to autonegotiate, so 
> normally I would suggest trying to set up the default media in EEPROM to 
> auto/NWAY, but I checked the EEPROM dumps that you've sent and they seem 
> fine... I might not hurt though to use vortex-diag and/or the DOS tool 
> provided by 3Com to check/set this.

Now that I know it could be a possible eeprom setting, I downloaded the
utility from 3com and grudgingly booted into Win98 to run it. I hit the
auto-configure button and hey presto, it altered one setting to
auto-negotiate (there are two such settings by the way).

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.

> This might also be an issue related to power management, but I don't know 
> how that can be checked.
> In summary, I have no idea about what can be done here, obviously if the 
> driver gets wrong data from the hardware it will behave badly...
> 
> > History indicates that card appears to work on Windows machines but have
> > serious performance problems under Linux in certain circumstances.
> 
> History indicates that people can't be bothered to look up a documentation 
> page or this list's archives to look for answers when the card/driver 
> doesn't behave propely.

Maybe. But I did search quite hard. None of the google searches I did
indicated that it could be solved by poking around in the eeprom. After
realising that it could be the eeprom settings, I could quite easily
pull out some success stories.

Although the vortex documentation in the kernel documentation references
3com's utility, there is no mention that the parameters stored in the
eeprom _must_ be set a certain way. Maybe a doc update is in order?

Let me put one more perspective on this. The Windows driver works
without poking. The official but unsupported open source 3c90x drivers
from 3com work without poking. So why should I have to go and poke? I
would argue that the driver should be clever enough to handle this
situation. Chew on that one, if you will.

Thanks again for the quick response. I would be even happier if this
incident would lead to a driver improvement. Let me know if you need
anything from me.

Ed-T.


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