Date: Fri, 28 Jun 1996 11:37:35 -0400 (EDT) From: (Mark J. Taylor) <mtaylor@cybernet.com> To: Jaye Mathisen <mrcpu@cdsnet.net> Cc: Kurt Olsen <kurto@tiny.mcs.usu.edu>, hackers@freebsd.org Subject: Re: de0: Transmission timeout? Message-ID: <XFMail.960628113945.mtaylor@cybernet.com> In-Reply-To: <Pine.NEB.3.92.960627150803.8567m-100000@schizo.cdsnet.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On 19:09:20 Jaye Mathisen wrote: >>Hmmm, I'm a bit skeptical of this explanation, for the following reason. >The same kernel and source tree is on 4 identical boxes (4 P120's), and >the 1 P6, and the P6 only has this problem. Swapping cards and slots >doesn't fix it either, it's only on the P6. > >So I'm thinking a hardware problem of somekind, but I can't imagine what. >3com cards work fine, the adaptec works fine, just the darn network card. > >On Thu, 27 Jun 1996, Kurt Olsen wrote: > >> I've seen this same behavior and a knowledgable friend tells me it's a >> common bug. Claims that it expires the arp entry for the default router, >> so you can't talk to it from anywhere outside the subnet. A work-around >> is to have either a cron job that pings out of your subnet every few minutes, >> or just do what I do and: >> >> % ping -i 300 <somedistanthost> >& /dev/null & >> >> I haven't look into the kernel to see if this is the case though, but the >> ping does the job (as well as logging in from the console, then telneting >> out.) >> >> Kurt >> I too have only experienced this on our one P6-200. We have several P5 machines with the SMC Ethernet (de0), and they do not exhibit this message. Sounds like a loop-counter in the de driver code instead of a sleep(). -Mark Taylor mtaylor@cybernet.com
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.960628113945.mtaylor>