| From | Sent On | Attachments |
|---|---|---|
| Jaye Mathisen | Jun 27, 1996 1:39 pm | |
| Kurt Olsen | Jun 27, 1996 2:55 pm | |
| Jaye Mathisen | Jun 27, 1996 3:09 pm | |
| mtay...@cybernet.com | Jun 28, 1996 8:37 am |
| Subject: | Re: de0: Transmission timeout? | |
|---|---|---|
| From: | mtay...@cybernet.com (mtay...@cybernet.com) | |
| Date: | Jun 28, 1996 8:37:15 am | |
| List: | org.freebsd.freebsd-hackers | |
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 mtay...@cybernet.com





