* tulip driver: errors instead TX packets?
@ 2004-01-10 14:48 Piotr Kaczuba
2004-01-10 17:27 ` Jeff Garzik
0 siblings, 1 reply; 9+ messages in thread
From: Piotr Kaczuba @ 2004-01-10 14:48 UTC (permalink / raw)
To: linux-kernel
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 (becker@scyld.com)
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
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: tulip driver: errors instead TX packets? 2004-01-10 14:48 tulip driver: errors instead TX packets? Piotr Kaczuba @ 2004-01-10 17:27 ` Jeff Garzik 2004-01-10 20:28 ` Piotr Kaczuba 0 siblings, 1 reply; 9+ messages in thread From: Jeff Garzik @ 2004-01-10 17:27 UTC (permalink / raw) To: Piotr Kaczuba; +Cc: linux-kernel Piotr Kaczuba wrote: > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: tulip driver: errors instead TX packets? 2004-01-10 17:27 ` Jeff Garzik @ 2004-01-10 20:28 ` Piotr Kaczuba 2004-01-11 3:20 ` Adam Kropelin 0 siblings, 1 reply; 9+ messages in thread From: Piotr Kaczuba @ 2004-01-10 20:28 UTC (permalink / raw) To: Jeff Garzik; +Cc: linux-kernel Jeff Garzik wrote: > Piotr Kaczuba wrote: > >> 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: tulip driver: errors instead TX packets? 2004-01-10 20:28 ` Piotr Kaczuba @ 2004-01-11 3:20 ` Adam Kropelin 2004-01-11 12:16 ` Piotr Kaczuba 0 siblings, 1 reply; 9+ messages in thread From: Adam Kropelin @ 2004-01-11 3:20 UTC (permalink / raw) To: Piotr Kaczuba; +Cc: Jeff Garzik, linux-kernel On Sat, Jan 10, 2004 at 09:28:45PM +0100, Piotr Kaczuba wrote: > Jeff Garzik wrote: > > Piotr Kaczuba wrote: > > > >> 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. > /* 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. > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: tulip driver: errors instead TX packets? 2004-01-11 3:20 ` Adam Kropelin @ 2004-01-11 12:16 ` Piotr Kaczuba 2004-01-11 17:27 ` Adam Kropelin 0 siblings, 1 reply; 9+ messages in thread From: Piotr Kaczuba @ 2004-01-11 12:16 UTC (permalink / raw) To: Adam Kropelin; +Cc: Jeff Garzik, linux-kernel Adam Kropelin wrote: > On Sat, Jan 10, 2004 at 09:28:45PM +0100, Piotr Kaczuba wrote: > >>Jeff Garzik wrote: >> >>>Piotr Kaczuba wrote: >>> >>> >>>>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. > > >> /* 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. > > >> 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. 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: tulip driver: errors instead TX packets? 2004-01-11 12:16 ` Piotr Kaczuba @ 2004-01-11 17:27 ` Adam Kropelin 2004-01-12 22:10 ` Piotr Kaczuba 0 siblings, 1 reply; 9+ messages in thread From: Adam Kropelin @ 2004-01-11 17:27 UTC (permalink / raw) To: Piotr Kaczuba; +Cc: Jeff Garzik, linux-kernel On Sun, Jan 11, 2004 at 01:16:03PM +0100, Piotr Kaczuba wrote: > > 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> > 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 --- linux-2.6.1/drivers/net/tulip/tulip_core.c.orig Sun Jan 11 12:06:34 2004 +++ linux-2.6.1/drivers/net/tulip/tulip_core.c Sun Jan 11 12:09:13 2004 @@ -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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: tulip driver: errors instead TX packets? 2004-01-11 17:27 ` Adam Kropelin @ 2004-01-12 22:10 ` Piotr Kaczuba 2004-01-13 5:09 ` Adam Kropelin 0 siblings, 1 reply; 9+ messages in thread From: Piotr Kaczuba @ 2004-01-12 22:10 UTC (permalink / raw) To: Adam Kropelin; +Cc: Jeff Garzik, linux-kernel Adam Kropelin wrote: > On Sun, Jan 11, 2004 at 01:16:03PM +0100, Piotr Kaczuba wrote: > >>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> > >>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 > > > --- linux-2.6.1/drivers/net/tulip/tulip_core.c.orig Sun Jan 11 12:06:34 2004 > +++ linux-2.6.1/drivers/net/tulip/tulip_core.c Sun Jan 11 12:09:13 2004 > @@ -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. > 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. > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: tulip driver: errors instead TX packets? 2004-01-12 22:10 ` Piotr Kaczuba @ 2004-01-13 5:09 ` Adam Kropelin 2004-01-14 20:47 ` Piotr Kaczuba 0 siblings, 1 reply; 9+ messages in thread From: Adam Kropelin @ 2004-01-13 5:09 UTC (permalink / raw) To: Piotr Kaczuba; +Cc: Jeff Garzik, linux-kernel On Mon, Jan 12, 2004 at 11:10:04PM +0100, Piotr Kaczuba wrote: > Adam Kropelin wrote: > > On Sun, Jan 11, 2004 at 01:16:03PM +0100, Piotr Kaczuba wrote: > > > >>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> > > > >>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? <snip patch that disables SQE test> > 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> > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: tulip driver: errors instead TX packets? 2004-01-13 5:09 ` Adam Kropelin @ 2004-01-14 20:47 ` Piotr Kaczuba 0 siblings, 0 replies; 9+ messages in thread From: Piotr Kaczuba @ 2004-01-14 20:47 UTC (permalink / raw) To: Adam Kropelin; +Cc: Jeff Garzik, linux-kernel Dnia 2004-01-13 06:09:55, Adam Kropelin napisał(a): > 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2004-01-14 20:47 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2004-01-10 14:48 tulip driver: errors instead TX packets? Piotr Kaczuba 2004-01-10 17:27 ` Jeff Garzik 2004-01-10 20:28 ` Piotr Kaczuba 2004-01-11 3:20 ` Adam Kropelin 2004-01-11 12:16 ` Piotr Kaczuba 2004-01-11 17:27 ` Adam Kropelin 2004-01-12 22:10 ` Piotr Kaczuba 2004-01-13 5:09 ` Adam Kropelin 2004-01-14 20:47 ` Piotr Kaczuba
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).