tulip driver: errors instead TX packets?

DISCUSSION Piotr Kaczuba 3 participants 9 messages Jan 10, 2004 – Jan 14, 2004 Network drivers

Share & tools

Piotr Kaczuba

author

2004-01-10 14:48 UTC #0 lore raw

I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip driver on 2.6.1. I wonder if anyone has noticed that ifconfig shows the packets sent in the errors field instead of the TX packets field. At least, this is what I assume because it shows 0 TX packets and 11756 errors.

Here's the ifconfig output for eth0, which is used for PPPoE:

eth0 Link encap:Ethernet HWaddr 00:04:75:B1:E0:77

          inet6 addr: fe80::204:75ff:feb1:e077/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:9130 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:11756 dropped:0 overruns:0 carrier:23473
          collisions:0 txqueuelen:1000
          RX bytes:1723335 (1.6 MiB)  TX bytes:0 (0.0 b)
          Interrupt:10 Base address:0x5000

I had the same behaviour with 2.4 and the tulip driver from scyld.

This is what tulip-diag reports:

tulip-diag.c:v2.18 11/12/2003 Donald Becker ([email protected])
http://www.scyld.com/diag/index.html
Index #1: Found a 3Com 3cSOHO100B-TX (ADMtek Centaur) adapter at 0xd000.
Comet duplex is reported in the MII status registers. Transmit started, Receive started.
The Rx process state is 'Waiting for packets'.
The Tx process state is 'Idle'.
The transmit threshold is 128.
Comet MAC address registers b1750400 ffff77e0
Comet multicast filter 8000000040001000.
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.

Is it okay for the TX process to be in idle state although there definitly is outgoing traffic?

Please CC any replies to me as I'am not subscribed.

Piotr Kaczuba

Jeff Garzik

2004-01-10 17:27 UTC #1 lore raw

Quoted 1 line · Piotr Kaczuba

I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip driver on 2.6.1. I wonder if anyone has noticed that ifconfig shows the packets sent in the errors field instead of the TX packets field. At least, this is what I assume because it shows 0 TX packets and 11756 errors.

This is an old error, but since packets show up, nobody bothers with the incorrect statistics...

Jeff

Piotr Kaczuba

author

2004-01-10 20:28 UTC #2 lore raw

Quoted 5 lines · Jeff Garzik

Quoted 1 line · Piotr Kaczuba
I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip driver on 2.6.1. I wonder if anyone has noticed that ifconfig shows the packets sent in the errors field instead of the TX packets field. At least, this is what I assume because it shows 0 TX packets and 11756 errors.
This is an old error, but since packets show up, nobody bothers with the incorrect statistics...

It seems that the error lies in the following piece of code from drivers/net/tulip/interrupt.c, function tulip_interrupt. I've inserted an additional printk after the "if (status & 0x8000)" and it looks like normal operation of the nic is considered as an major error by the driver because my printk appeared in dmesg output right after bringing the interface up. I assume that the else branch is never executed although I didn't test what happens if an transmit error really happens. I wonder if a fix for this problem consists of just changing the value of the AND mask but I have no idea what the right value would be.

  if (status & 0x8000) {
          /* There was an major error, log it. */

#ifndef final_version
if (tulip_debug > 1)
printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
dev->name, status);

#endif
          tp->stats.tx_errors++;
          if (status & 0x4104) tp->stats.tx_aborted_errors++;
          if (status & 0x0C00) tp->stats.tx_carrier_errors++;
          if (status & 0x0200) tp->stats.tx_window_errors++;
          if (status & 0x0002) tp->stats.tx_fifo_errors++;
          if ((status & 0x0080) && tp->full_duplex == 0)
                  tp->stats.tx_heartbeat_errors++;
  } else {
          tp->stats.tx_bytes +=
                  tp->tx_buffers[entry].skb->len;
          tp->stats.collisions += (status >> 3) & 15;
          tp->stats.tx_packets++;

}

Piotr Kaczuba

Adam Kropelin

2004-01-11 03:12 UTC #3 lore raw

Quoted 23 lines · Piotr Kaczuba

Quoted 10 lines · Jeff Garzik
Quoted 5 lines · Piotr Kaczuba
I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip driver on 2.6.1. I wonder if anyone has noticed that ifconfig shows the packets sent in the errors field instead of the TX packets field. At least, this is what I assume because it shows 0 TX packets and 11756 errors.
This is an old error, but since packets show up, nobody bothers with the incorrect statistics...
It seems that the error lies in the following piece of code from drivers/net/tulip/interrupt.c, function tulip_interrupt. I've inserted an additional printk after the "if (status & 0x8000)" and it looks like normal operation of the nic is considered as an major error by the driver because my printk appeared in dmesg output right after bringing the interface up. I assume that the else branch is never executed although I didn't test what happens if an transmit error really happens. I wonder if a fix for this problem consists of just changing the value of the AND mask but I have no idea what the right value would be.

Quoted 1 line

   if (status & 0x8000) {

According to my PNIC docs (don't have true Tulip docs handy), this bit is the logical OR of all the Tx error bits, so it appears a true tx error has ocurred.

Quoted 6 lines

           /* There was an major error, log it. */
#ifndef final_version
if (tulip_debug > 1)
printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
dev->name, status);
#endif

Enabling this printk and setting tulip_debug appropriately would tell us what tx error you're experiencing.

Quoted 7 lines

           tp->stats.tx_errors++;
           if (status & 0x4104) tp->stats.tx_aborted_errors++;
           if (status & 0x0C00) tp->stats.tx_carrier_errors++;
           if (status & 0x0200) tp->stats.tx_window_errors++;
           if (status & 0x0002) tp->stats.tx_fifo_errors++;
           if ((status & 0x0080) && tp->full_duplex == 0)
                   tp->stats.tx_heartbeat_errors++;

And this code bumps error counters based on the specific error that ocurred. It all seems perfectly sane to me. The actual problem lies elsewhere, I think.

--Adam

Piotr Kaczuba

author

2004-01-11 12:16 UTC #4 lore raw

Quoted 43 lines · Adam Kropelin

Quoted 5 lines · Piotr Kaczuba
Quoted 3 lines · Jeff Garzik
Piotr Kaczuba wrote:
Quoted 8 lines
Quoted 3 lines
Quoted 1 line
I've got a ADMtek Centaur (3cSOHO100B-TX) running with the tulip driver on 2.6.1. I wonder if anyone has noticed that ifconfig shows the packets sent in the errors field instead of the TX packets field. At least, this is what I assume because it shows 0 TX packets and 11756 errors.
This is an old error, but since packets show up, nobody bothers with the incorrect statistics...
It seems that the error lies in the following piece of code from drivers/net/tulip/interrupt.c, function tulip_interrupt. I've inserted an additional printk after the "if (status & 0x8000)" and it looks like normal operation of the nic is considered as an major error by the driver because my printk appeared in dmesg output right after bringing the interface up. I assume that the else branch is never executed although I didn't test what happens if an transmit error really happens. I wonder if a fix for this problem consists of just changing the value of the AND mask but I have no idea what the right value would be.
  if (status & 0x8000) {
According to my PNIC docs (don't have true Tulip docs handy), this bit is the logical OR of all the Tx error bits, so it appears a true tx error has ocurred.
Quoted 6 lines
          /* There was an major error, log it. */
#ifndef final_version
if (tulip_debug > 1)
printk(KERN_DEBUG "%s: Transmit error, Tx status %8.8x.\n",
dev->name, status);
#endif
Enabling this printk and setting tulip_debug appropriately would tell us what tx error you're experiencing.
Quoted 7 lines
          tp->stats.tx_errors++;
          if (status & 0x4104) tp->stats.tx_aborted_errors++;
          if (status & 0x0C00) tp->stats.tx_carrier_errors++;
          if (status & 0x0200) tp->stats.tx_window_errors++;
          if (status & 0x0002) tp->stats.tx_fifo_errors++;
          if ((status & 0x0080) && tp->full_duplex == 0)
                  tp->stats.tx_heartbeat_errors++;

Quoted 3 lines

And this code bumps error counters based on the specific error that ocurred. It all seems perfectly sane to me. The actual problem lies elsewhere, I think.

Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting pppd (eth0 is used by PPPoE). I agree that the code looks okay but somehow every packet sent is considered to be an error although I don't experience any problems in everday network traffic.

Linux Tulip driver version 1.1.13 (May 11, 2002)
eth0: ADMtek Comet rev 49 at 0xe1fc5000, 00:04:75:B1:E0:77, IRQ 10.
eth0: tulip_up(), irq==10.
eth0: Done tulip_up(), CSR0 fff98000, CSR5 fc664010 CSR6 ff972113.
eth0: Added filter for 33:33:00:00:00:01 f99baaba bit 31.
eth0: Added filter for 33:33:ff:b1:e0:77 35362b05 bit 44.
eth0: Added filter for 33:33:00:00:00:01 f99baaba bit 31.
eth0: Added filter for 33:33:ff:b1:e0:77 35362b05 bit 44.
eth0: Added filter for 33:33:00:00:00:01 f99baaba bit 31.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: no IPv6 routers present
eth0: Added filter for 33:33:ff:b1:e0:77 35362b05 bit 44.
eth0: Added filter for 33:33:00:00:00:01 f99baaba bit 31.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 2a0b8c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Comet link status 0000 partner capability 0000.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.
eth0: Transmit error, Tx status 1a078c80.

(output truncated)

Piotr Kaczuba

Adam Kropelin

2004-01-11 17:19 UTC #5 lore raw

Quoted 3 lines · Piotr Kaczuba

Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting pppd (eth0 is used by PPPoE). I agree that the code looks okay but

<snip>

Quoted 1 line

eth0: Transmit error, Tx status 1a078c80.

That would be heartbeat failure, no carrier, and loss of carrier. It's interesting that you seem to be able to get valid packets on the wire because the latter two errors are usually quite fatal. I suspect either the Comet is just buggy and those error bits aren't to be trusted or there is something wrong with the PHY config. I don't have docs on the Comet PHY so there's not much I can do.

On whim, does the patch below change anything for you?

--Adam

drivers/net/tulip/tulip_core.c renamed from drivers/net/tulip/tulip_core.c.orig +1 -1

@@ -438,7 +438,7 @@
 		/* Enable automatic Tx underrun recovery. */
 		outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
 		dev->if_port = tp->mii_cnt ? 11 : 0;
-		tp->csr6 = 0x00040000;
+		tp->csr6 = 0x000C0000;
 	} else if (tp->chip_id == AX88140) {
 		tp->csr6 = tp->mii_cnt ? 0x00040100 : 0x00000100;
 	} else

Piotr Kaczuba

author

2004-01-12 22:10 UTC #6 lore raw

Quoted 26 lines · Adam Kropelin

Quoted 1 line · Piotr Kaczuba
Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting pppd (eth0 is used by PPPoE). I agree that the code looks okay but
<snip>
Quoted 1 line
eth0: Transmit error, Tx status 1a078c80.
That would be heartbeat failure, no carrier, and loss of carrier. It's interesting that you seem to be able to get valid packets on the wire because the latter two errors are usually quite fatal. I suspect either the Comet is just buggy and those error bits aren't to be trusted or there is something wrong with the PHY config. I don't have docs on the Comet PHY so there's not much I can do.
On whim, does the patch below change anything for you?
--Adam

drivers/net/tulip/tulip_core.c line 444

Quoted 8 lines

drivers/net/tulip/tulip_core.c renamed from drivers/net/tulip/tulip_core.c.orig +1 -1

@@ -438,7 +438,7 @@
 		/* Enable automatic Tx underrun recovery. */
 		outl(inl(ioaddr + 0x88) | 1, ioaddr + 0x88);
 		dev->if_port = tp->mii_cnt ? 11 : 0;
-		tp->csr6 = 0x00040000;
+		tp->csr6 = 0x000C0000;
 	} else if (tp->chip_id == AX88140) {
 		tp->csr6 = tp->mii_cnt ? 0x00040100 : 0x00000100;
 	} else

Unfortunately, not. The errors are still there, but the status code has changed. Below is an excerpt from kern.log after applying the patch.

Quoted 29 lines

Jan 12 21:34:57 orbiter kernel: Linux Tulip driver version 1.1.13 (May 11, 2002)
Jan 12 21:34:57 orbiter kernel: eth0: ADMtek Comet rev 49 at 0xe1fea000, 00:04:75:B1:E0:77, IRQ 10.
Jan 12 21:35:09 orbiter kernel: eth0: tulip_up(), irq==10.
Jan 12 21:35:09 orbiter kernel: eth0: Done tulip_up(), CSR0 fff98000, CSR5 fc664010 CSR6 ff9f2113.
Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:ff:b1:e0:77  35362b05 bit 44.
Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:ff:b1:e0:77  35362b05 bit 44.
Jan 12 21:35:09 orbiter kernel: eth0: Added filter for 33:33:00:00:00:01  f99baaba bit 31.
Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:10 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:10 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:12 orbiter kernel: eth0: Comet link status 0000 partner capability 0000.
Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 2a0b8c00.
Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 2a0b8c00.
Jan 12 21:35:12 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 2a0b8c00.
Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:13 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:14 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:15 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:18 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.

Quoted 8 lines

Jan 12 21:35:18 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:18 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:19 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:19 orbiter kernel: eth0: no IPv6 routers present
Jan 12 21:35:20 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:20 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:21 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.
Jan 12 21:35:32 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.

Piotr Kaczuba

Adam Kropelin

2004-01-13 05:01 UTC #7 lore raw

Quoted 11 lines · Piotr Kaczuba

Quoted 10 lines · Adam Kropelin
Quoted 2 lines · Piotr Kaczuba
Here is the output of dmesg after setting TULIP_DEBUG to 4 and starting pppd (eth0 is used by PPPoE). I agree that the code looks okay but
<snip>
Quoted 1 line
eth0: Transmit error, Tx status 1a078c80.

Quoted 8 lines

Quoted 8 lines
That would be heartbeat failure, no carrier, and loss of carrier. It's interesting that you seem to be able to get valid packets on the wire because the latter two errors are usually quite fatal. I suspect either the Comet is just buggy and those error bits aren't to be trusted or there is something wrong with the PHY config. I don't have docs on the Comet PHY so there's not much I can do.
On whim, does the patch below change anything for you?

Quoted 2 lines

Unfortunately, not. The errors are still there, but the status code has changed. Below is an excerpt from kern.log after applying the patch.

<snip>

Quoted 1 line

Jan 12 21:35:09 orbiter kernel: eth0: Transmit error, Tx status 1a078c00.

Yep...we told it to disable the SQE test so the heartbeat error no longer appears. The carrier errors are still present, though. This definitely smells like a configuration problem, but without docs and a card to test with there's not much else I can do. I'll poke thru the code and see if anything else leaps out at me. If anybody out there has Comet docs or a NIC that exhibits this problem they'd be willing to loan I'll take a deeper look.

--Adam

Piotr Kaczuba

author

2004-01-14 20:47 UTC #8 lore raw

Dnia 2004-01-13 06:09:55, Adam Kropelin napisał(a):

Quoted 5 lines

I'll poke thru the
code and see if anything else leaps out at me. If anybody out there has Comet docs or a NIC that exhibits this problem they'd be willing to
loan I'll take a deeper look.

If you come up with any patches, I'd love to test them, so feel free to send me any diffs.

Piotr Kaczuba