eth0: link down

This topic contains 3 replies, has 2 voices, and was last updated by  Heiner Moderator 11 months ago.

Viewing 4 posts - 1 through 4 (of 4 total)
  • 8. November 2017 at 5:40 #32340

    Having random eth0 issues. I see in both /var/log/syslog and /var/log/messages lines with „eth0: link down“ following by a flurry of entries like this:

    Nov  6 02:08:48 max2play kernel: [514970.619360] smsc95xx 1-1.1:1.0 eth0: link down
    Nov  6 02:08:50 max2play kernel: [514972.548004] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    Nov  6 02:09:56 max2play kernel: [515039.226938] smsc95xx 1-1.1:1.0 eth0: link down
    Nov  6 02:09:56 max2play rsyslogd-2007: action 'action 17' suspended, next retry is Mon Nov  6 02:11:26 2017 [try http://www.rsyslog.com/e/2007 ]
    Nov  6 02:10:09 max2play kernel: [515052.056353] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Nov  6 02:10:09 max2play kernel: [515052.259763] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Nov  6 02:10:11 max2play kernel: [515053.854585] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    Nov  6 02:12:01 max2play rsyslogd-2007: action 'action 17' suspended, next retry is Mon Nov  6 02:13:31 2017 [try http://www.rsyslog.com/e/2007 ]
    Nov  6 02:12:25 max2play kernel: [515187.758367] smsc95xx 1-1.1:1.0 eth0: link down
    Nov  6 02:12:37 max2play kernel: [515200.046090] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Nov  6 02:12:37 max2play kernel: [515200.229710] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Nov  6 02:12:39 max2play kernel: [515202.009168] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    Nov  6 02:14:01 max2play rsyslogd-2007: action 'action 17' suspended, next retry is Mon Nov  6 02:15:31 2017 [try http://www.rsyslog.com/e/2007 ]
    Nov  6 02:14:37 max2play kernel: [515320.160425] smsc95xx 1-1.1:1.0 eth0: link down
    Nov  6 02:14:39 max2play kernel: [515322.001392] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    Nov  6 02:16:01 max2play rsyslogd-2007: action 'action 17' suspended, next retry is Mon Nov  6 02:17:31 2017 [try http://www.rsyslog.com/e/2007 ]
    Nov  6 02:17:05 max2play kernel: [515467.744078] smsc95xx 1-1.1:1.0 eth0: link down
    Nov  6 02:17:17 max2play kernel: [515480.033012] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    Nov  6 02:17:18 max2play kernel: [515480.756431] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Nov  6 02:17:18 max2play kernel: [515480.949942] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
    Nov  6 02:17:20 max2play kernel: [515482.721341] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
    

    Tonight I’ve had the RPi2 eth0 go completely dead — no traffic through the eth port (port lights off, unplugging cable and reinserting ineffective–only remedy RPi reboot) — in the middle of playing music. I thought the issue was my old SqueezeBox Classic, so I opened up the RPi and installed a HifiBerry Digi+ I bought but never installed, rebooted and began playing music (yay) only to have the same ethernet failure requiring another RPi reboot. When this happens the router web ui shows the RPi2 (listed as max2play) as disabled and not active.

    This RPi2 was purchased from Hifiberry along with a case, etc. on January, 2016, so not that old. I’ve only ever used it as a Logitech Media Server (formerly with picoreplayer and now with Max2Play). Sits on top of my AV Receiver with a 2Tb USB3 drive attached and the ethernet cable plugged in and an optical link to the AV Receiver.

    I’ve set up the RPi2 to assign a fixed IP from the AT&T Uverse router but that’s about all I know to do. I do not have a WiFi dongle to plug into one of the open USB ports. I can’t think what can cause a cabled ethernet connection to bounce like this, or for the ethernet hardware (?) to freeze.

    Any ideas anyone?

    What’s the life expectancy of a RPi2? Should I just pony up the $ and buy a new RPi3 rather than waste time trying to figure this random craziness out?

    8. November 2017 at 16:08 #32355

    Hi gstalnaker,

    Firstly, you could try to deactivate the fixed IP and see whether the problem remains the same or if there is some variation to it.

    Also, you can try removing all periphery to make sure power supply is not an issue (5V 2A min for RPi2).

    10. November 2017 at 20:54 #32412

    Heiner – thanks for the reply.

    1. I set up fixed IP as a trouble-shooting step to by-pass DHCP IP renewal; eth0 going dead occurs with both fixed IP (set either from the Max2Play admin UI or in the dhcp config file in /etc) and without fixed IP.

    2. The 2Tb USB disk is attached to a powered hub with the hub’s connecting cable running to the RPi2, so its operation should not be a draw on the RPi2 power supply. I have not modified any setting related to the RPi2 (cpu overclocking or power output to USB ports).

    How can I check the input power coming into the RPi2? I’m using the AV/DC power brick that I bought when I bought the RPi2 from HifiBerry.

    Other than setting the USB to be persistently mounted, installing LMS/SqueezeLite, and using aptitude from a terminal session to install a few mp3 tag editing apps, this is a stock Max2Play/RPi2 unit. I don’t use the desktop UI and have no keyboard/mouse attached, nor do I use HDMI out to any monitor.

    It failed again last night. Was streaming a local radio station and it went silent. I observed the ethernet port activity lights continue to flash for about five minutes, then they went dark and did not resume activity. I went to bed. This morning the ethernet port activity lights were again active with no action on my part and I could again connect to the LSM with my smartphone app. So, sometime overnight the eth0 issue righted itself. BUT … I could not play an internet stream. All attempts reported that the stream URL could not be found. I could play music from my library on the USB drive.

    Very odd behavior. I’ve been using this thing for many, many weeks. Why should the eth0 link go down like this? When this happens, btw, I have wifi connections to the router and I can check email, etc., so the network itself is there.

    13. November 2017 at 13:41 #32451

    If you do have another device you could check for that ethernet connection, you could try to recreate the issue to rule out the Pi’s ethernet port as the source of error. This is amongst the most likely of sources.

    You could also try running a completely fresh image for a day to rule out any software changes.

    Otherwise, you can also try running the system as is via WiFi to see if this is truly a hardware issue with the ethernet port.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic.

Register here