Received: by oss.sgi.com id ; Thu, 10 Aug 2000 15:56:19 -0700 Received: from ppp0.ocs.com.au ([203.34.97.3]:64517 "HELO mail.ocs.com.au") by oss.sgi.com with SMTP id ; Thu, 10 Aug 2000 15:55:40 -0700 Received: (qmail 10730 invoked from network); 10 Aug 2000 22:54:58 -0000 Received: from ocs3.ocs-net (192.168.255.3) by mail.ocs.com.au with SMTP; 10 Aug 2000 22:54:58 -0000 X-Mailer: exmh version 2.1.1 10/15/1999 From: Keith Owens To: Kanoj Sarcar cc: linux-origin@oss.sgi.com Subject: Re: ethernet In-reply-to: Your message of "Thu, 10 Aug 2000 11:01:00 MST." <200008101801.LAA50412@google.engr.sgi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 11 Aug 2000 08:54:56 +1000 Message-ID: <11989.965948096@ocs3.ocs-net> Sender: owner-linux-origin@oss.sgi.com Precedence: bulk Return-Path: X-Orcpt: rfc822;linux-origin-outgoing On Thu, 10 Aug 2000 11:01:00 -0700 (PDT), Kanoj Sarcar wrote: >Not that it is bothering me greatly right now (at least not more than >the RX overflow messages), but with late kernels, I think I sometimes >have trouble telneting/pinging mips64 machines. Things seem to get fixed >though once I log in to the mips64 machine, and ping the other one from >it, that seems to clean up the line. Recent developement. The symptoms sound like the ARP reply is getting lost. I have seen this on some network cards (especially NetGear FA310TX) where the RX data is much longer than it should be and is split over multiple input buffers which confuses the kernel. When you get this symptom, check arp -an on both machines. I expect that the mips64 box will have the hardware address of the source machine but the other machine will be missing the hardware address of the mips64 box. Doing the traffic in reverse automatically fills in the hardware address of the machine that the arp request came from. This tends to hide the RX overrun problem.