[tulip] DC21143 rev 65 - hopeless case?

[Karl Hammar]

I have a Kingston KNE100TX. Seems to be rev 65 (the kernel reports it
as 21142, on the chip it says 21143):

  $ cat /proc/pci
  ...
  Bus  0, device  11, function  0:
    Ethernet controller: DEC DC21142 (rev 65).
      Medium devsel.  Fast back-to-back capable.  IRQ 5.  Master Capable.  Latency=64.  Min Gnt=20.Max Lat=40.
      I/O at 0xc400 [0xc401].
      Non-prefetchable 32 bit memory at 0xeffff800 [0xeffff800].
  ...

And using stock 2.2.18 tulip driver:
  Mar  6 09:56:37 opal kernel: tulip.c:v0.91g-ppc 7/16/99 becker@cesdis.gsfc.nasa.gov
  Mar  6 09:56:37 opal kernel: eth0: Digital DS21143 Tulip rev 65 at 0xc400, 00:C0:F0:4D:90:96, IRQ 5.
  Mar  6 09:56:37 opal kernel: eth0:  EEPROM default media type Autosense.
  Mar  6 09:56:37 opal kernel: eth0:  Index #0 - Media MII (#11) described by a 21142 MII PHY (3) block.
  Mar  6 09:56:37 opal kernel: eth0:  MII transceiver #1 config 3000 status 7829 advertising 01e1.

>From what I see you don't have receive buffers and there is some
problem with irq. Check that you don't have an irq-conflict.

Regards,
/Karl

-----------------------------------------------------------------------
Karl Hammar                    Aspö Data           karl@kalle.csb.ki.se
Lilla Aspö 2340             +46  173 140 57                    Networks
S-742 94 Östhammar         +46  10 270 26 67                  Computers
Sweden                                                       Consulting
-----------------------------------------------------------------------


From: John Sutton <john@scl.co.uk>
Subject: [tulip] DC21143 rev 65 - hopeless case?
Date: Tue, 6 Mar 2001 11:13:57 +0000

> Hi
> 
> Is this Intel chip with tulip driver utterly beyond hope?  I've got quite a few
> in service so it's a pain to have to replace them all, especially since I know
> that they are perfectly usable under Windoze ;-(
> 
> I've just returned a failed Kingston KNE100TX to my supplier, hoping that the
> replacement would NOT be a rev 65...  but it is.  So either my supplier is
> holding some very old stock OR Kingston are still shipping these chips?
> 
> Am I the only one with this problem?  (See posting below from 21st Dec for
> details).
> 
> TIA
> John Sutton
> 
> ****************************
> 
> Hi there
> 
> I'm trying to get to the bottom of a persistent problem I have been having with
> Kingston KNE100TX cards.  I've tried upgrading to driver v0.92 but (see
> previous post - "[tulip] Multiple detection?") have temporarily abandoned that
> and reverted to v0.91g.
> 
> I've been using these cards for over a year now in a server/diskless-client
> configuration and everything works fine *most of the time*.  But occasionally,
> and usually when I'm doing a big file transer, it all locks up.  In particular,
> what usually happens is that the server card locks up and although restarting
> the network layer on the server usually helps, it's never quite right again
> until I do a full reboot.
> 
> Anyways, in an effort to get a handle on this, I've downloaded and built the
> diagnostics.  And here's the output of tulip-diag after a lockup has occured:
> 
> tulip-diag.c:v2.04 9/26/2000 Donald Becker (becker@scyld.com)
> http://www.scyld.com/diag/index.html
> Index #1: Found a Digital DS21143 Tulip adapter at 0xf400.
> Port selection is MII, full-duplex.
> Transmit started, Receive started, full-duplex.
> The Rx process state is 'Suspended -- no Rx buffers'.
> The Tx process state is 'Idle'.
> The transmit threshold is 1024.
> Interrupt sources are pending!  CSR5 is f06988c7.
> Tx done indication.
> Tx complete indication.
> Tx out of buffers indication.
> Rx Done indication.
> Receiver out of buffers indication.
> Timer expired indication.
> The NWay status register is 000000c6.
> Internal autonegotiation state is 'Autonegotiation disabled'.
> Use '-a' or '-aa' to show device registers,
> '-e' to show EEPROM contents, -ee for parsed contents,
> or '-m' or '-mm' to show MII management registers.
> 
> Any ideas?
> 
> I've never been sure whether the root cause of this problem is actually NFS, or
> the card driver.  But I'm beginning to suspect the card driver because I also
> get a lockup when using a Win95 machine as client and doing transfers over SMB.
> And Win95 to Win95 I've never had a lockup of any sort (amazing but true ;-).
> 
> Also, to try to get a handle on the problem, I've have been trying to change the
> speed/duplex/etc of the cards by passing kernel parameters e.g.
> ether=0,0,10,eth0 at the LILO prompt (for the server) and in /etc/bootptab (for
> the clients).  But nothing I do makes the slightest bit of difference ;-(  What
> am I doing wrong?
> 
> TIA
> 
> ***************************************************
> John Sutton
> SCL Computer Services
> URL http://www.scl.co.uk/
> Tel. +44 (0) 1239 621021
> ***************************************************
> 
> _______________________________________________
> tulip mailing list
> tulip@scyld.com
> http://www.scyld.com/mailman/listinfo/tulip