[tulip] DC21143 rev 65 - hopeless case?
John Sutton
john@scl.co.uk
Tue, 6 Mar 2001 16:31:46 +0000
On Tue, 06 Mar 2001, you wrote:
> 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.
Thanks for that Karl but I can't believe it's true! The system works fine
most of the time, and there's nothing going on (such as intermittent use of a
printer, mouse, etc) which could lead to an "intermittent" interrupt conflict.
But Donald's come back with something which I'm definitely going to pursue!
Regards
John
> 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
--
***************************************************
John Sutton
SCL Computer Services
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 711 888
***************************************************