Messages in this thread |  | | | Date | Sat, 10 Jan 2004 22:20:38 -0500 | | From | Adam Kropelin <> | | Subject | Re: tulip driver: errors instead TX packets? |
| |
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
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |