ifplugd: Link beat lost.

AlucardZero · 08-23-2007, 07:11 AM

Hi,

After a big hardware switcheroo, I've started getting the following message on my Debian Etch (2.6.18) router:

Code:

/var/log/syslog:Aug 23 07:14:47 kenobi ifplugd(eth1)[28285]: Link beat lost.
/var/log/syslog:Aug 23 07:14:49 kenobi ifplugd(eth1)[28285]: Link beat detected.

The hardware switched was the motherboard and processor (dual PIIIs now, from one), but not the hard drive, NICs, nor ethernet cables nor switch (which were working flawlessly all summer).

The problem is that my Internet hiccups when the link beat is lost; I lose all my persistent connections, and it's happening every 3-6 hours. Why is it losing the link beat?

Here's the relevant info I can think of:

Code:

02:09.0 Ethernet controller: National Semiconductor Corporation DP83815 (MacPhyter) Ethernet Controller
02:0a.0 Ethernet controller: ADMtek NC100 Network Everywhere Fast Ethernet 10/100 (rev 11)

which (I believe) are using the loaded natsemi and tulip modules.

Code:

eth0      Link encap:Ethernet  HWaddr 00:09:5B:09:FB:70
          inet addr:71.88.98.x  Bcast:255.255.255.255  Mask:255.255.240.0
          inet6 addr: fe80::209:5bff:fe09:fb70/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:10993194 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2483003 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:2983174148 (2.7 GiB)  TX bytes:677221560 (645.8 MiB)
          Interrupt:177 Base address:0x2000

eth1      Link encap:Ethernet  HWaddr 00:02:2A:B4:3D:C7
          inet addr:192.168.0.1  Bcast:192.168.0.255  Mask:255.255.255.0
          inet6 addr: fe80::202:2aff:feb4:3dc7/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:2186237 errors:1 dropped:0 overruns:0 frame:1
          TX packets:2564794 errors:10 dropped:0 overruns:0 carrier:10
          collisions:0 txqueuelen:1000
          RX bytes:664356873 (633.5 MiB)  TX bytes:2367451748 (2.2 GiB)
          Interrupt:169 Base address:0xe800

Code:

alucard@kenobi:~$ cat /proc/interrupts
           CPU0       CPU1
  0:   60118106        104    IO-APIC-edge  timer
  3:   13173487          1    IO-APIC-edge  serial
  6:          1          1    IO-APIC-edge  floppy
  7:          0          0    IO-APIC-edge  parport0
  8:          0          1    IO-APIC-edge  rtc
  9:          1          0   IO-APIC-level  acpi
 14:     242794          0    IO-APIC-edge  ide0
 15:         64          0    IO-APIC-edge  ide1
169:    6519895          1   IO-APIC-level  uhci_hcd:usb1, eth1
177:     731962   12629725   IO-APIC-level  eth0
185:          0          0   IO-APIC-level  Intel 82801AA-ICH
NMI:          0          0
LOC:   60123010   60123009
ERR:          0
MIS:          0

Some Googling hasn't turned up much.. when this happens, the NICs are not under heavy load.

It looks like eth1 shares an interrupt with usb, but there are no USB devices plugged into this machine.

When I get home tonight I'll take it down (sigh) and try playing with some BIOS options (USB emulation and interrupts), and any other ideas presented here.

Thanks for your time.

AlucardZero · 08-28-2007, 01:30 PM

Small update. I disabled USB emulation and the internal NIC, which (so far) has gotton rid of the (not mentioned here) APIC error, but after a couple days up eth1 lost its link beat again, this morning.

I have on my plate to try disabling USB entirely in the BIOS (if I can), and trying a different NIC. Maybe I'll try a different PCI slot for the hell of it. Anyone got any better ideas?

AlucardZero · 08-30-2007, 08:15 PM

Turning off USB didn't do it. I guess it's not interrupt-related.

I did a little googling about the 'carrier' errors, and there seems to be some previous mention of them and the 'tulip' cards. To note, my current computer is a Dell Precision WorkStation 220, and my old was a S1854 Trinity 400. As a reminder, this problem popped up only on the Dell.

I took out the NIC and replaced it with:

Code:

02:0a.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30)

Hopefully the problem won't come back in a few days.

The nature of this problem makes troubleshooting a PITA. It takes a few days to show up, it's intermittent afterwards, and troubleshooting requires BIOS or hardware changes.