Wired network unstable while browsing menus


I just upgraded from old raspbmc to new OSMC release from 2015-10-01, however my network (wired) is strange.
While OSMC is booting I have lan connectivity and after the SO boots still, however while I am browsing the menus depending on the menus I am, the lan connectivity is switching ON, OFF, ON, OFF, ON, OFF all the time…

Any idea for what may I do to solve/debug this?

Is your power supply sufficient?

Logs will also help too.

To get a better understanding of the problem you are experiencing we need more information from you. Please see http://osmc.tv/wiki/general/how-to-submit-a-useful-support-request/ for advice on how to help us.


100% guarantee this is a power issue. Either drop your level of overclock (if you have increased it from the default) and/or try a different power adaptor.

Ethernet is one of the first things to fail when the power supply voltage drops too low under load.

I can double that problem; I also recently upgraded on a Pi (not Pi2) to 2015-10-1 and experience a very unstable (i.e., not working) ethernet, visible by the LEDs going off and on in various patterns.

I’ll hope the following details are helping to eventually find the problem.

  1. I unplugged the attached USB drive, to reduce load on the power supply.
  2. I never had any instabilities before with that very same power supply, even with USD drive attached I never experienced any unstable ethernet condition previously.
  3. I did a clean reinstall, without any further addons or whatsoever, to rule out any side-effects.
  4. I also lowered arm_freq to 700 and core_freq to 250, since these are the defaults according to the help but where not set after the clean install (arm_freq was 850, I believe, and core_freq 300 something, can’t remember exactly); no improvement from that.
  5. The problem seems to quite load-sensitive:
    a) when I exit osmc and let the Pi simply idle, the network seems stable, at least the LEDs are telling me this. However, given the fact that osmc will restart itself after a short while I can’t elaborate on that, e.g., by trying to setup network manually and logging in via ssh. I am happy to give that a try; is there a way to boot into “debug mode” without osmc starting automatically?
    b) when I activate the debug logs, the off periods are notably increased, i.e., the network LEDs are on only for a very short frame below a second, while without logging the LEDs/network are on for quite a while.
    c) As the previous user said, pressing any remote action results in immediate shutdown of the network/LEDs.

Now, I’d be happy to help with logs, but I obviously can’t upload them directly via osmc. I tried the option to write them to the SD card, but need a pointer where exactly they are stored to?

Sorry for the lengthy reply, but how this problem appears it’s quite strange to me, and thus I’d like to give as many details as I could.


OK, now I managed to get (very sporadic) access via ssh, thus I can provide logs more easily.

dmesg provides some hints, also including USB connects/disconnects (nothing is plugged into the USB ports), which seem to relate to the actual ethernet hardware? Hopefully anybody has an idea what’s going on? Maybe a kernel side-effect?

[ 177.539348] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 222.538286] ERROR::dwc_otg_hcd_urb_enqueue:505: Not connected

[ 222.604207] usb 1-1: USB disconnect, device number 22
[ 222.604242] usb 1-1.1: USB disconnect, device number 23
[ 222.604559] smsc95xx 1-1.1:1.0 eth0: unregister ‘smsc95xx’ usb-20980000.usb-1.1, smsc95xx USB 2.0 Ethernet
[ 222.604636] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
[ 222.794292] Indeed it is in host mode hprt0 = 00021501
[ 223.064073] usb 1-1: new high-speed USB device number 24 using dwc_otg
[ 223.064272] Indeed it is in host mode hprt0 = 00001101
[ 223.324459] usb 1-1: New USB device found, idVendor=0424, idProduct=9512
[ 223.324505] usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 223.333700] hub 1-1:1.0: USB hub found
[ 223.340317] hub 1-1:1.0: 3 ports detected
[ 223.614010] usb 1-1.1: new high-speed USB device number 25 using dwc_otg
[ 223.714374] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[ 223.714410] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
[ 223.724333] smsc95xx v1.0.4
[ 223.804665] smsc95xx 1-1.1:1.0 eth0: register ‘smsc95xx’ at usb-20980000.usb-1.1, smsc95xx USB 2.0 Ethernet, b8:27:eb:85:13:c2
[ 223.876749] smsc95xx 1-1.1:1.0 eth0: hardware isn’t capable of remote wakeup
[ 223.878883] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 225.296377] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xCDE1
[ 225.299562] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready

No logs needed. Everything you have described points at a power issue.

In all your testing you have failed to do the one thing that really matters - try another power adaptor.

Is your Pi 1 an original model B or a B+ ? If it’s an original model B you may have a faulty polyfuse which will cause a low power issue regardless of how good your power adaptor is. This can be tested with a voltmeter.

Yes, I see that point about the power adaptor, and gave it a try. Out of lack for other options, I use an Apple charger (supposedly providing 1A) and now it’s stable again.

However, I am still wondering why this instability, which I never experienced before with my old 1.2A adapter, coincidences with the latest update from software revision of September to the October one. My wild guess is that my previous power adapter was running barely below its limit, and the new October revision has a somewhat increased average load, i.e., implies more power consumption and thus made my adapter struggle.

Anyway, thanks for the pointer to change the power adaptor.


BTW, I have an Pi 1 B, I believe, at least I can see a green fuse on the PCB. I tried both “plug-in options”, first by connecting the charger directly to an USB port, thus circumventing the fuse, and then also using the regular power-input (Micro? USB) of the Pi. Both is working, so the fuse should be fine.

iPad chargers are not particularly great either. Their problem is the voltage drops too low under load - my iPad chargers drop to to 4.3v under load which is no where near enough to run a stable Pi. (My Pi 2 can’t even boot successfully on my iPad chargers) If the voltage drops below 4.75v at any point, trouble is likely to occur.

The reason why software can affect the power requirements is that the Pi uses dynamic overclocking - the clock speeds you have selected in the overclocking profile only apply when the CPU is busy and switches to “Turbo” mode, when the CPU is fairly idle it drops back to low speeds (700Mhz on the Pi 1 and 600Mhz on the Pi 2) and at those lower speeds much less power is required.

Its up to the “cpu governor” to decide what level of CPU (and/or disk) activity warrants a switch to Turbo mode - the governor is a kernel feature that is configurable in software and has been changed at least once in the course of OSMC updates.

Also different versions of software (Kodi/addons, any extra software installed) may require more or less CPU time - if Kodi is more CPU hungry after an update (maybe due to a bug) then it may cause the CPU to be in Turbo mode a lot more of the time.

A marginal power adaptor may be fine to power the Pi when it is running at the idle clock speeds but insufficient to run the Pi at the full Turbo speed for any length of time. In typical intermittent use the clock speed may flip back and forth between low and turbo several times a second but if the CPU is really pegged it will stay in Turbo permanently and that is when you would probably notice a stability problem.

The original Pi 1 B model was the worst for power sensitivity issues (it was the number one cause of crashes) and some improvements were made on the B+ through completely redesigned power circuitry. The Pi 2 B (IMHO) is a bit more fussy about power than the B+ due to a higher power demand, but not as bad as the original Pi 1 B.

Edit: I see you have an original Pi 1 B - in that case if you have access to a voltmeter you can measure the voltage on the board between TP1 and TP2 - it should stay within 4.75v and 5.25v at all times. If it drops much below 4.75v then you will start to experience problems. The voltage measured here is after the polyfuse.

I am happy to give that a try; is there a way to boot into “debug mode” without osmc starting automatically?

Not sure who you’re replying to there ?

Also your question doesn’t make sense - OSMC is the operating system, so you can’t boot without starting the operating system… also what do you mean by debug mode ? Kodi has a debug mode but it sounds like you want to boot without Kodi starting, so it’s really not clear what you want.

Well, I’ll have to wait and see how the iPhone charger works out. I’m residing in the UAE, and it’s not always easy to get hands on specific electronic items, like a high-quality and high-power adapter.

Regarding the governing of the CPU: I can rule that one out, since I configured the Pi with fixed turbo during my tests, and set the frequency to only 700 MHz, which I also verified via /sys/devices/system

Also, since it was a clean install, I can rule out addons causing the increased power consumption. So, I think it’s either kodi or osmc. But anyway, I’ll know what to look into first when I experience any instabilities next.


Replaced the power adapter and know it is working ok :wink:

Coincidently power adapter went working wrong at the same time I upgraded my Pi

Thanks all