[tulip] samsung SC1200-TX weirdness?
John Sutton
john@scl.co.uk
Thu Apr 4 13:34:01 2002
Donald
Success! Further to my last post (repeated below because it never actually
made it into the list. Something to do with old headers ending up in
replies?), I did the obvious thing - got a new packet driver from
www.crynwr.com. Problem solved!.
Thanks for your efforts. Here FWIW is a brief account of my dealings with
this card, for the benefit of others.
Ethercard Samsung SC1200-TX REV-1A with Digital chip 21140-AF
All results relate to linux kernel 2.2.19 and tulip driver 0.93
Two issues with this card:
1) The full duplex LED on the backplate does not correctly reflect the state of
the connection. Proprietary software (in particular the SC1200.COM packet
driver supplied with the card) is able to drive this LED but the tulip driver
does not. However, the report in the system log when the tulip driver loads
and, equally, the tulip-diag program, correctly report the duplex state of the
connection irrespective of what the LED says.
2) Use of the SC1200.COM packet driver supplied with the card leaves the card in
a wierd state such that the tulip driver cannot then drive it. Solution is to
get the generic DC21X4 packet driver from www.crynwr.com. But note that the
default ConnectionType=Autosense will not work. Rather, you need to force the
media negotiation using ConnectionType=_100BaseTx_FD (or whatever suits your
network environment - I have only tested this particular value).
All in all, an object lesson in how to make a pig's ear out of a silk purse,
courtesy of Samsung ;-( But once you've negotiated the gotchas, the card works
fine.
-------------------------------------------------
Donald
Hi again. As per my first response (below), I have now installed a hard disk
in a system with the SC1200 card in it and running the same config - kernel
2.2.19 and tulip 0.93. However, I'm now stuck...
The client runs fine as expected. Problem now is to expose the card to the DOS
packet driver to try to get it to do its weird thing, and then be able to run
diagnostics on the resulting mess. So my first attempt has been to run the
packet driver in a dosemu session. Unfortunately (and not really very
surprising), the sod won't run:
C:\>pktdrv\sc1200 0x62
Packet Driver for SAMSUNG SC1200-TX Fast Ethernet Adapter Ver 3.03(971216)
FATAL: DC21X4 Does not support this bus type
???? Hmmm. I've fiddled about a bit with the dosemu config thinking that the
problem is probably that dosemu doesn't have direct enough access to the PCI
bus, but no luck so far. And I'm not very hopeful...
Any ideas about how I might proceed gratefully received!
TIA
John
On Thu, 28 Mar 2002, Donald Becker wrote:
> On Wed, 27 Mar 2002, John Sutton wrote:
>
> > I'm running linux kernel 2.2.19 with the latest tulip.c (v0.93 11/7/2001)
> > compiled into the kernel. Attempting to get some samsung SC1200-TX cards going
> > but with mixed results this far ;-(
> ..
> >> kernel: eth0: Digital DS21140A Tulip rev 34 at 0xe400, 00:40:05:A5:86:CC, IRQ10.
> > kernel: eth0: EEPROM default media type Autosense.
> > kernel: eth0: Index #0 - Media MII (#11) described by a 21140 MII PHY (1) block.
> > kernel: eth0: MII transceiver #0 config 0000 status 780d advertising 0001.
> > kernel: tulip.c:v0.93 11/7/2001 Written by Donald Becker <becker@scyld.com>
> > kernel: http://www.scyld.com/network/tulip.html
> > kernel: eth0: Setting full-duplex based on MII #0 link partner capability of 41e1.
>
> This looks fine. A 21140 with a MII transceiver should be handled
> correctly by almost any tulip driver from the past six years.
>
> > but it appears (from the led on the backplate) to be only running at half
> > duplex? tulip-diag -e gives:
>
> The LED setting may not be accurate, even when the card is correctly
> operating. The LED should is normally driven by the MII transceiver,
> but it may be connected to the GPIO (general purpose) pins on the 21140A
> and require special card-specific magic.
You are right. Since I don't have the benefit of an HD/FD led indicator on my
hub, I've now wired a client back-to-back into the server with a crossover
cable and have thus confirmed your opinion - the connection *is* full duplex
even though the led on the card indicates not. Moreover, this fits with another
observation I have made. When booting the client using the DOS packet driver,
I previously asserted that the FD led went off when the linux kernel loaded the
tulip driver. Wrong. It all happens pretty fast but I've now observed that
the FD led goes off at the same instant as the linux kernel *starts* to boot,
i.e. well before it loads the tulip driver. This fits the idea that the
"card-specific magic" in the packet driver is lost as soon as the packet driver
relinquishes control in favour of the linux kernel.
> > tulip-diag.c:v2.10 3/08/2002 Donald Becker (becker@scyld.com)
> > http://www.scyld.com/diag/index.html
> > Index #1: Found a Digital DS21140 Tulip adapter at 0xe400.
> > Port selection is MII, full-duplex.
>
> Looks good.
> Is the card working at this point?
Yes. This trace is from when I've successfully booted the system directly from
a linux kernel on a floppy disk and (notwithstanding the FD/HD issue which I
think we've now put to bed) everything is working fine.
> > CSR12 direction setting bits 0x00.
> > 1 transceiver description blocks:
> > Media MII, block type 1, length 12.
> > MII interface PHY 0 (media type 11).
> > No MII reset sequence. No MII initialization sequence.
> > Media capabilities are 7800, advertising 01e1.
> > Full-duplex map 5000, Threshold map 1800.
> > MII PHY found at address 0, status 0x782d.
>
> This looks pretty generic.
>
> > However, the real show stopper is that I'm running a diskless client
> > config so I need to boot from a kernel which has been pulled over the
> > network. To do this I've built a bootrom image using the netboot
> > package and the DOS packet driver SC1200.COM supplied with the cards.
> > And this works fine - it pulls the kernel using TFTP *and* using full
> > duplex - until the kernel loads the tulip driver, at which point the
> > card switches to half duplex (judging by the led) and then the whole
> > thing locks up with "neighbour table overflow" messages spitting out!
>
> Hmmm, something else is happening here. Just switching to half duplex
> will cause bad performance, but you should still get some packets
> through.
As above, I don't think it is switching to half duplex at all. This was all a
red herring.
>
> > So, in summary:
> > boot the system directly with the linux kernel, OK except only get
> > half duplex (and passing the ether=0,0,0x200,eth0 kernel param makes
> > no difference)
>
> What is the packet and error counts in /proc/net/dev?
I need to do an install onto a hard disk to be able to do any
diagnostics on the failing ether connection - at the moment all my machines bar
the server in the middle are diskless so no ether connection means no system...
I'll get back to you with some proper diagnostics as soon as I've done that.
Thanks again
John
> --
> Donald Becker becker@scyld.com
> Scyld Computing Corporation http://www.scyld.com
> 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
> Annapolis MD 21403 410-990-9993
--
***************************************************
John Sutton
SCL Internet
URL http://www.scl.co.uk/
Tel. +44 (0) 1239 711 888
***************************************************