[tulip] samsung SC1200-TX weirdness?
Thu Mar 28 14:10:01 2002
Thanks for your response. Here are some of your points addressed:
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 <email@example.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 (firstname.lastname@example.org)
> > 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
As above, I don't think it is switching to half duplex at all. This was all a
> > 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.
> Donald Becker email@example.com
> Scyld Computing Corporation http://www.scyld.com
> 410 Severn Ave. Suite 210 Second Generation Beowulf Clusters
> Annapolis MD 21403 410-990-9993
Tel. +44 (0) 1239 711 888