[tulip] base i/o address & mii problems

[Donald Becker]

On Wed, 12 Jul 2000, David C Ables wrote:

[[ Sorry about the delayed response -- some of my mail was stuck in a
queue. ]]

> I have a linksys lne100tx card I'm trying to use with debian potato and a
> 2.2.15 kernel. I've already downloaded and installed pci-scan.o and
> tulip.o. they show up in /proc/modules, so I think I have them set up
> correctly. the problem is that although I can "talk" to the card with
> ifconfig eth0 blah, I can't actually communicate through it. pinging on my
> lan produces no blinking on my 10/100 switch. 

The PNIC-II usually doesn't have a problem with v92.

> tulip (via dmesg) reports 
> eth0: Lite-On PNIC-II rev 37 at 0xc381cc00, <mac address>, IRQ 10.

This is a remapped PCI memory address.  The address reported is mostly
useless when using memory mode on new kernels.  You can use PCI I/O mode by
compiling with -DUSE_IO_OPS

BTW, the only nasty thing that we can do with your MAC address is
Wake-On-LAN.  And it's pretty difficult to get a working WOL packet to your
local network.

> ifconfig eth0 reports
> Interrupt:10 Base Address:0xdc00

This is the truncated PCI memory address -- see /proc/pci.

> /proc/pci reports
> IRQ 10, I/O at 0xf400 [0xf401].

This is the PCI I/O address, which isn't remapped on the x86.

> using tulip-diag, I get
> Index #1: Found a Lite-On PNIC II adapter at 0xf400.
...
> The NWay status register is 41e1d0cc.

Looks normal..

> The current PNIC-II MAC/WOL etc.
> No MII transceivers found!

This is normal for the PNIC-II.  I should take out the "!".

> which brings me to my next point: where is my MII transciever? it doesn't
> appear in startup when tulip is loaded as it should. after running
> mii-diag, I get
> Basic registers of MII PHY #32: 1000 7868 0000 0000 07e1 41e1 0000 0000.

Clue: MII address are only 5 bits, 0..31.  The driver is simulating the MII
transceiver registers.

> Basic mode control register 0x1000: Auto-negotiation enabled.
> Basic mode status register 0x7868 ... 7868.
> Link status: not established.

Buglet with constructing the link status.  Line 2979
		data[3] = 0x1848 + ((csr12&0x7000) == 0x5000 ? 0x20 : 0)
				+ (csr12&0x06 ? 0 : 4);
This should be
		data[3] = 0x1848 + ((csr12&0x7000) == 0x5000 ? 0x20 : 0)
				+ ((csr12&0x06) ? 0 : 4);

This has been fixed in post-92 versions.

> Your link partner advertised 41e1: 100baseTx-FD 100baseTx 10baseT-FD
> 10baseT.

I'm guessing that you have a routing or configuration problem, not a driver
problem. 

Donald Becker				becker@scyld.com
Scyld Computing Corporation		http://www.scyld.com
410 Severn Ave. Suite 210		Beowulf Clusters / Linux Installations
Annapolis MD 21403