On 1/18/06, Christopher Friesen <[EMAIL PROTECTED]> wrote: > > We're seeing an issue with an e1000 device. After some time (4-8 hrs > typically) it jams itself up and refuses to receive any more packets. > > We're running 2.6.10, but with the e1000 driver from 2.6.14.
just so you've got all the latest bug fixes can you try the driver from http://prdownloads.sf.net/e1000/e1000-6.3.9.tar.gz I haven't heard any reports of a jammed receiver. see below > Outgoing packets seem to be fine, incoming packets just increment the > error count. > > ethtool device specific stats show the following counters > > rx_fifo_errors: 1714150 > rx_no_buffer_count: 299 > rx_missed_errors: 1714150 > > The fifo and missed errors seem to actually be counting the same thing, > the "Missed Packets Count" error register. yeah thats a problem we've already addresssed. > From the chip docs: > On the jammed device, dumping the registers gives the following, > indicating that the head and tail pointers are equal: > > Receive buffer size: 2048 > 0x02808: RDLEN (Receive desc length) 0x00001000 > 0x02810: RDH (Receive desc head) 0x00000060 > 0x02818: RDT (Receive desc tail) 0x00000060 > 0x02820: RDTR (Receive delay timer) 0x00000000 > > So, somehow we're getting into a state where we can't receive packets, > and we're never getting out of that state. Are you sure that you're able to transmit and you aren't just handing it to the hardware and it never gets out? tcpdump on a remote machine would verify. RDH==RDT should never happen during runtime because the hardware will lock thinking it has an empty ring. what hardware do you have (lspci -vvv) what is the machine? do you have a test that reproduces this? Thanks for the report, get back to us with the follow up data. Jesse PS for very e1000 specific questions like this you're welcome to include [EMAIL PROTECTED] too. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
