Raspberry Pi loses ethernet

I always recommend checking through the RasPi Troubleshooting Wiki, especially the parts about start-up and power problems.  The best way to check power problems is to measure the voltage between TP1 and TP2.  If it's less than 4.75V, that could be a problem and the power section of the Wiki tells you what to look for next, e.g., an iffy polyfuse F3.  Micro USB power cables sometimes have very thin conductors and you can get enough of a drop to cause problems, even if your 5V 2.1A supply is working perfectly.

The newer RasPis with the mounting holes do not support hot swap of USB devices.  You should be able to unplug one without grief, but plugging in a USB device may cause a 5V glitch large enough to reboot.

Thanks for that re the power supply and the USB hot swap issue (I can live with that since I don't have any USB devices connected just a 1GB LAN).  I still don't think the problem is the power supply since having tried several (ie 4 some up to 2A, and one was supplied with the RasPi so really should be up to the job)) I get the same LAN drop out problem.  The latest is that when not in a case it runs for longer, 5-10mins but will always drop out eventually (this might suggest something but not convinced).  I still intend to try my current SD card built on the problem PI in my old (ie early running ok for ~1yr) RasPi to see what happens then.

I have four raspberry pi's that I run "headless":

vitalstatistix:~> uptime
09:46:31 up 48 days, 19:56, 12 users,  load average: 0.50, 0.39, 0.31

raspberrypi:~> uptime
10:46:41 up 46 days, 15:39,  5 users,  load average: 0.00, 0.01, 0.05
dogmatix:~> uptime
10:46:53 up 45 days, 17:25,  1 user,  load average: 0.08, 0.04, 0.05
raspberrypi:~> uptime
09:46:29 up 38 days, 21:08,  5 users,  load average: 0.16, 0.05, 0.06

two are "experimenting" machines that haven't gotten their hostname changed from "raspberrypi".  (Hmm. And two are running in a different timezone....)

So I'm thinking it has something to do with /your/ setup.

On the other hand, I'm running all of them "diskless": The filesystem is NOT on the SD card, but on a server connected through the LAN.... So I'm getting very little SD card IO...

/IF/ the powersupply is "bad", the LAN chip is the first that shows signs of not-working. I've put the raspberry pi on a bench supply and turned the voltage down. At 4.3V the 3.3V powerline starts dropping. At 4.0V the 3.3V line has dropped down to 3.0V and that's when the lan chip stops working. As a matter of fact, the CPU SHOULD continue to work down to about 3V. on the 5V line. But e.g. there is a 1.8V that is used to communicate between the RAM and the CPU that might drop too far to keep things running. I haven't checked this.

So if you're seeing lan-chip-crashes, that is still a hint that there might be a problem with your powersupply.

What most people don't realize is how bad the cheap USB cables are. So even if you have a perfect 4A powersupply, the cable might cause a voltage droop. On the other hand, if you've measured TP1/TP2 to be 4.99V that doesn't seem to be the problem either. So... sorry I don't have a clear answer for you. :-(

Agreed with many above posters. This sounds like a power problem. I recommend you measure the voltage under full load with a network file transfer running. This will show if the voltage drops under load and stays high while idle. Because this does sound like what the problem is.

I've now run the old RasPi with the SD built on the failing new RasPi; result - no problems with the network even under heavy load.  This seems to rule out a problem with the build of the SD card.  The next step will be to run the old RasPi with the new SD build but the power supply provided with the new RasPi (I'll also try the other RasPi/power supply combination).  I would say that of course the problem with the new RasPi could be a power supply problem.  However that means the 3 power supplies I've tried, all from different manufacturers, all rated at 5V but one at 1000mA, one at 1200mA, one at 2.1A all have the same problem of voltage drop under load.  Of course possible but it seems to me to be unlikely, I'm not ruling it out but unlikely.

I have exactly the same problem. Tried two different Pi's and both lose the ip address after 20-30 hours of operation. I am trying to run headless so once the ip address is gone, I cannot access using ssh. I am using 3.10.25+ #622 from the NOOBS/Raspian release. raspberry Model B. SONY 16GB Class 10 SD. Powered by a 2.1Ax5V Anker power supply.

An Arduino UNO is connected to one USB and an RS232->USB cable to the other USB. Disconnecting these peripherals does not seem to help.

syslog does not show anything is up.

The first symptom is that all the LAN lights disappear. Then resetting the board via GPIO does not help. The board needs to be powered down and powered up again risking corruption of the SD card.

I am about to give up on the headless approach and move to an Arduino with an Ethernet shield, but it will be difficult to fit my program into 32KB.

Any help appreciated.

SJ

Hi,

My raspberry pi's have uptimes in the order of "months" because on that timeframe I move them and they get powered down.

/IF/ your powersupply is insufficient, the first component to be troubled by that will be the SMC ethernet chip. Can you doublecheck that your powersupply is good? Is it capable of providing 1A? Have you used a sufficiently thick (electrically) cable? Have you tried "backfeeding" the 'pi? Take a powered hub and connect it to the pi's  USB connector...

My old pi has been running now for several days without ethernet drop out running the build I made on the failing new pi. The old pi is running the old power suply, I've not tried it yet on the new pi power supply. As I said in a previous post the new pi had this problem even when I tried it on 3 different power supplies, rated up to 2.1A, so my view is the ps is not the problem. BTW the new pi had this ethernet drop out originally after running for several tens of hours,it now shows the problem after minutes. The usb 'back power' work around sounds a serious 'fudge'! If it works it suggests the unit is not fit for purpose, some not all. It sounds like a manufacturing component failure. I'm quite prepared to send mine back if that will help solve the problem for others, having one that works is all I need really.

To get power from the powersupply to the raspberry pi, you need a cable. Some horrendously bad cables are around. So, buy a cable from Farnell and/or take the cable from your HTC phone. Those are good. You can buy the USB prodder from my company to measure the resistance of your cables with a multimeter if you want.

Most people advise to measure the voltage between TP1 and TP2 on the raspberry pi. The reading should be about 5V. But the problem is that worst case the powersupply+cable cannot provide the current required for short bursts. So if the reading is say 4.9V, it might be that there is 5V for 90% of the time and 4V for 10% of the time. The actual relationship will be more like 99.9 versus 0.1%. And chips will crash if they have too little power for only a very short time. So get that better cable!

The power supply is fine. It can drive 2.1A, and I am running the same power supply in the same setup at a different location and things are fine.

The differences between the two locations are:

a) cable. I reused the cable that came with my Spark Core for the one that is not working correctly.

b) router. cant believe that would be the issue

c) temperature. the working Pi ambient is at 70F, the one that keeps halting ambient is 80+F. CPU temp, however, is at 55C well below the 85C Max.

Here is a snippet from the pi halting. Without warning there is a shutdown at 04:26.44.

Feb 23 04:25:01 rpiblr2 /USR/SBIN/CRON[7388]: (CRON) info (No MTA installed, discarding output)

Feb 23 04:26:44 rpiblr2 shutdown[7400]: shutting down for system halt

Feb 23 04:26:44 rpiblr2 init: Switching to runlevel: 0

Feb 23 04:26:45 rpiblr2 ifplugd(eth0)[1586]: Exiting.

Feb 23 04:26:47 rpiblr2 ifplugd(lo)[1552]: Exiting.

Feb 23 04:26:47 rpiblr2 ntpd[2006]: ntpd exiting on signal 15

Feb 23 04:26:59 rpiblr2 kernel: imklog 5.8.11, log source = /proc/kmsg started.

Feb 23 04:26:59 rpiblr2 rsyslogd: [origin software="rsyslogd" swVersion="5.8.11" x-pid="1825" x-info="http://www.rsyslog.com"] start

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] Booting Linux on physical CPU 0x0

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] Initializing cgroup subsys cpu

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] Initializing cgroup subsys cpuacct

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] Linux version 3.10.25+ (dc4@dc4-arm-01) (gcc version 4.7.2 20120731 (prerelease) (crosstool-NG linaro-1.13.1+bzr2458 - Linaro GCC 2012.08) ) #622 PREEMPT Fri Jan 3 18:41:00 GMT 2014

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] CPU: ARMv6-compatible processor [410fb767] revision 7 (ARMv7), cr=00c5387d

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT nonaliasing instruction cache

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] Machine: BCM2708

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] cma: CMA: reserved 16 MiB at 1b000000

Would there be a clue in /var/log/debug ?

This is what it says, and seems to be exactly when the Pi goes down:

Feb 20 01:45:25 rpiblr2 kernel: [    1.962874] Module dwc_common_port init

Feb 21 07:09:45 rpiblr2 kernel: [    0.000000] On node 0 totalpages: 114688

Feb 21 07:09:45 rpiblr2 kernel: [    0.000000] free_area_init_node: node 0, pgdat c05cfd6c, node_mem_map c067d000

Feb 21 07:09:45 rpiblr2 kernel: [    0.000000]   Normal zone: 896 pages used for memmap

Feb 21 07:09:45 rpiblr2 kernel: [    0.000000]   Normal zone: 0 pages reserved

Feb 21 07:09:45 rpiblr2 kernel: [    0.000000]   Normal zone: 114688 pages, LIFO batch:31

Feb 21 07:09:45 rpiblr2 kernel: [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

Feb 21 07:09:45 rpiblr2 kernel: [    0.000000] pcpu-alloc: [0] 0

Feb 21 07:09:45 rpiblr2 kernel: [    1.874156] dwc_otg: Microframe scheduler enabled

Feb 21 07:09:45 rpiblr2 kernel: [    1.963169] dwc_otg: FIQ enabled

Feb 21 07:09:45 rpiblr2 kernel: [    1.963189] dwc_otg: NAK holdoff enabled

Feb 21 07:09:45 rpiblr2 kernel: [    1.963200] dwc_otg: FIQ split fix enabled

Feb 21 07:09:45 rpiblr2 kernel: [    1.963220] Module dwc_common_port init

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] On node 0 totalpages: 114688

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] free_area_init_node: node 0, pgdat c05cfd6c, node_mem_map c067d000

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000]   Normal zone: 896 pages used for memmap

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000]   Normal zone: 0 pages reserved

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000]   Normal zone: 114688 pages, LIFO batch:31

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768

Feb 23 04:26:59 rpiblr2 kernel: [    0.000000] pcpu-alloc: [0] 0

Feb 23 04:26:59 rpiblr2 kernel: [    1.873554] dwc_otg: Microframe scheduler enabled

Feb 23 04:26:59 rpiblr2 kernel: [    1.962694] dwc_otg: FIQ enabled

Feb 23 04:26:59 rpiblr2 kernel: [    1.962713] dwc_otg: NAK holdoff enabled

Feb 23 04:26:59 rpiblr2 kernel: [    1.962723] dwc_otg: FIQ split fix enabled

Feb 23 04:26:59 rpiblr2 kernel: [    1.962744] Module dwc_common_port init