Raspberry Pi 3B+ freezes with a network share mounted and ethernet connected #2598

merdok · 2018-06-27T20:45:53Z

Since the release of the 3B+ i am struggling with the it ALWAYS freezing overnight when i mount my network share and connect the Pi using ethernet to my router.
I had multiple 3B+ in the past months and each of them had the same issue. I always wake up to my Pi being dead and the network chip is burning hot.

The facts are:

The 3B+ is always freezing when i mount my network share and use ethernet.
This are no random crashes, mostly happening overnight with a few exception where it happened during apt-get upgrade.
The network controller chip is burning hot when the Pi freezes.
When i do not mount the network share but still use ethernet then the Pi survives overnight.
When i mount the network share and use WiFi instead of ethernet then the Pi also survives overnight.
A Pi 3B runs fine in all above configurations.

I use fstab to mount the share with the following command:
//ip/USB_Storage/ /home/pi/network_drive cifs vers=3.0,defaults,guest,uid=1000,iocharset=utf8,x-systemd.automount 0 0

I am using Raspbian with all latest updates (dist-upgrade & rpi-update).
Kernel currently at 4.14.50 but it was happening on all previous before.
I am using Plex media server with default configuration.
There is only a LAN cable and power cable connected to my Pi, no other ports are used.
Using official Raspberry Pi power supply.
Router is a Netgear x4s and i use the built in readyshare server to expose the share in my network.
There is no network traffic overnight.
There is no activity on the Pi overnight.

I do not think this is network or router related issue because my 3B runs fine with the same configuration also no other devices making problems.
My 3B without any problem had 100 days+ of uptime, with the same configuration and 3B+ can't get past 24 hours of uptime.

At first i thought it was a defective 3B+ but after multiple times I got a replacement and bought new ones the issue is still here. All 6 RPi 3B+ which i got had the issue. I bought a new power supply and a new sd card, i also reinstalled my Raspbian image from scratch multiple times all without success. Then i slowly did narrow down the issue to the ethernet controller.

The text was updated successfully, but these errors were encountered:

lategoodbye · 2018-06-28T07:46:29Z

You wrote there is a Plex media server, which provides the CIFS share. Which OS / hardware architecture is running on this server?

JamesH65 · 2018-06-28T09:48:41Z

I'd like to leave an anecdote, to try and give some idea of the complexities involved, and why knowledge of the entire system is required. I have a Zylel NAS, and a Humax PVR on my home network. I want to be able to share the data on the PVR to other devices on the network, and it has a option just for that. BUT, there is some incompatibility between the version of server SW on the PVR and that on the NAS, so if I turn sharing on on the PVR, at some point the PVR will lock up solid, and needs to be power cycled. Humax says it's Zylels fault, Zylel say it's Humax's fault. In the meantime, nothing gets fixed.

JamesH65 · 2018-06-28T09:51:18Z

In this particular case, since the majority of people do NOT see the issue, is even more important to determine the environment around the device, because that is surely what is causing the problem to occur. That is NOT to say there isn't an issue on the Pi, just that the particular environment is exposing that issue.

merdok · 2018-06-28T10:49:02Z

@JamesH65
That is exactly what i also think. This is for sure an issue with the 3B+, i did test it on 6 different ones and each of them is breaking, where a 3B runs fine.
The problem is that this issue only occurs in a specific environment. Luckily i nailed down the issue and can reproduce it every time when i setup a fresh raspbian installation.
Also i am not sure if this is a hardware issue or a software issue. There are some factors which strongly speak for a hardware issue with the ethernet chip controller which is used in the 3B+, the question now is if this can be fixed "just by software".

The Plex media server is running on the 3B+. The CIFS share is provided by the router.

JamesH65 · 2018-06-28T14:09:12Z

To clarify.

You have a 3B+ running a Plex server.
This is the device that is exposes the CIFS's share?
Still a bit unclear as to where and what is mounting the CIFS 'share', is it simply a USB drive attached to the Pi that fails?
You don't actually have anything connected to the server when is dies during the night?
You say you can reproduce easily in a fresh Raspbian install, so what are the exact steps to reproduce?

Cannot really speculate where the problem is at the moment.

lategoodbye · 2018-06-28T19:20:26Z

Sorry, for the confusion. Your Netgear router exposes the CIFS share.

Does the issue still occure if you change cifs parameter from vers=3.0 to vers=1.0?
Did you add the cifs mount point as media during Plex setup or isn't this necessary?

merdok · 2018-06-28T20:54:27Z

@lategoodbye
Yes, the Netgear router exposes the CIFS share. As i know the Netgear router is running samba.
The cifs parameter doesn't matter, it crashes anyway.
Yes, i add the cifs mount point as media during Plex setup, but i don't have periodical media scanning in plex enabled so that means plex does not access the mount point until i manually trigger it.

@JamesH65

Yes
No, the netgear router exposes the cifs shares, which i then mount on the Pi
No, see point 2
Nothing connected, nothing running, Pi is just idling
To reproduce:

Fresh install of Raspbian
apt-get upgrade (not necessary)
apt-get dist-upgrade (not necessary)
rpi-update (not necessary)
mount network share
install plex media server
connect Pi using ethernet
That's it, Pi is dead next morning.

lategoodbye · 2018-06-29T08:22:53Z

Could you please provide the output of the following commands from the Pi after ~ 1h uptime:

grep "" /sys/class/net/eth0/statistics/*
sudo apt-get install ethtool
ethtool -S eth0

Did you use the apt files from https://dev2day.de/pms/ for the Plex media server installation?
Does the Pi still dies, if you shutdown the Plex media service via sudo service plexmediaserver stop?

Edit: I tried to reproduce this issue at home with my TP-Link Archer C1200, but my RPi 3B+ is still available after 20 hours. I will try to setup a SAMBA server ...

merdok · 2018-06-29T17:27:08Z

Here are the results of the commands after around ~ 1h uptime:

/sys/class/net/eth0/statistics/collisions:0
/sys/class/net/eth0/statistics/multicast:0
/sys/class/net/eth0/statistics/rx_bytes:36940729
/sys/class/net/eth0/statistics/rx_compressed:0
/sys/class/net/eth0/statistics/rx_crc_errors:0
/sys/class/net/eth0/statistics/rx_dropped:2
/sys/class/net/eth0/statistics/rx_errors:0
/sys/class/net/eth0/statistics/rx_fifo_errors:0
/sys/class/net/eth0/statistics/rx_frame_errors:0
/sys/class/net/eth0/statistics/rx_length_errors:0
/sys/class/net/eth0/statistics/rx_missed_errors:0
/sys/class/net/eth0/statistics/rx_nohandler:0
/sys/class/net/eth0/statistics/rx_over_errors:0
/sys/class/net/eth0/statistics/rx_packets:64232
/sys/class/net/eth0/statistics/tx_aborted_errors:0
/sys/class/net/eth0/statistics/tx_bytes:11367936
/sys/class/net/eth0/statistics/tx_carrier_errors:0
/sys/class/net/eth0/statistics/tx_compressed:0
/sys/class/net/eth0/statistics/tx_dropped:0
/sys/class/net/eth0/statistics/tx_errors:0
/sys/class/net/eth0/statistics/tx_fifo_errors:0
/sys/class/net/eth0/statistics/tx_heartbeat_errors:0
/sys/class/net/eth0/statistics/tx_packets:36898
/sys/class/net/eth0/statistics/tx_window_errors:0

NIC statistics:
     RX FCS Errors: 0
     RX Alignment Errors: 0
     Rx Fragment Errors: 0
     RX Jabber Errors: 0
     RX Undersize Frame Errors: 0
     RX Oversize Frame Errors: 0
     RX Dropped Frames: 0
     RX Unicast Byte Count: 34870818
     RX Broadcast Byte Count: 39681
     RX Multicast Byte Count: 2414252
     RX Unicast Frames: 54587
     RX Broadcast Frames: 333
     RX Multicast Frames: 9669
     RX Pause Frames: 0
     RX 64 Byte Frames: 6720
     RX 65 - 127 Byte Frames: 4667
     RX 128 - 255 Byte Frames: 6002
     RX 256 - 511 Bytes Frames: 29325
     RX 512 - 1023 Byte Frames: 1483
     RX 1024 - 1518 Byte Frames: 16392
     RX Greater 1518 Byte Frames: 0
     EEE RX LPI Transitions: 0
     EEE RX LPI Time: 0
     TX FCS Errors: 0
     TX Excess Deferral Errors: 0
     TX Carrier Errors: 0
     TX Bad Byte Count: 0
     TX Single Collisions: 0
     TX Multiple Collisions: 0
     TX Excessive Collision: 0
     TX Late Collisions: 0
     TX Unicast Byte Count: 10294634
     TX Broadcast Byte Count: 486003
     TX Multicast Byte Count: 1079092
     TX Unicast Frames: 30292
     TX Broadcast Frames: 7031
     TX Multicast Frames: 2833
     TX Pause Frames: 1244
     TX 64 Byte Frames: 16072
     TX 65 - 127 Byte Frames: 11685
     TX 128 - 255 Byte Frames: 4408
     TX 256 - 511 Bytes Frames: 2669
     TX 512 - 1023 Byte Frames: 155
     TX 1024 - 1518 Byte Frames: 5167
     TX Greater 1518 Byte Frames: 0
     EEE TX LPI Transitions: 19657
     EEE TX LPI Time: 4973416129

Yes, i use the apt files from there to install plex media server.
I did not try to shutdown the service. I just want to use the advertised and promised Gigabit-Ethernet, which right now doesn't work stable on any 3B+ which i have.

lategoodbye · 2018-06-30T08:31:03Z

Thanks for providing the outputs. There is one obviously difference to my results: i don't have EEE TX LPI transitions.

Does the Pi still freeze after executing the following command (necessary after every reboot):
sudo ethtool --set-eee eth0 eee off

merdok · 2018-07-01T06:35:00Z

I tried the command and the 3B+ survived the night for the first time after 3 months! That is really good.
But now my question is what does the command do? I suppose it disables a feature, but what feature exactly and what disadvantages will come now?

lategoodbye · 2018-07-01T08:23:15Z

Great. Please keep the setup at least for 1 day, so we are sure that's not an exception.

I'm not the Ethernet expert, but this command disabled a power saving feature. I guess LPI is required on all devices in the network and that's the reason i can't reproduce it.

Wild theory: The combination of CIFS share and Plex server wake up the Pi too often. But it's also possible there is a bug in the LPI handling of the kernel.

I hope the Raspberry Pi guys can take over. Btw if you want this change persistent add dtparam=eee=off to config.txt and reboot.

merdok · 2018-07-01T09:16:56Z

Yes, i will test that a few days now and post here the results. But this is literally the first time a 3B+ survived the night for me :p

This change should be included in the RPi firmware if indeed fixes the issue!

But the Plex server doesn't access the CIFS share, it does it only when i trigger it (as far as i know)...
Watching media from the CIFS share did not freeze the 3B+, it only always happend during night.

Anyway, the Ethernet chip on 3B+ must be a big piece of trash if we need to disable half of the features to make it work properly...

JamesH65 · 2018-07-01T12:15:52Z

Interesting. EEE is energy efficient ethernet. We've had one bug fix already from the supplier of the chip (long cables causing EEE problems), sounds like there needs to be another one. Or we just turn it off, which would be my preference.

OOI, what length cables does your network have?

@pelwell @ghollingworth

pelwell · 2018-07-01T17:01:43Z

EEE gives us a useful power saving, so I'm reluctant to just switch it off for everybody.

I think the Plex media server, by default, runs a media scan in the early hours of the morning. That is likely to be the trigger for the failure.

merdok · 2018-07-01T18:11:09Z

@pelwell maybe it gives useful power saving, but it doesn't work!
Plex media server by default doesn't run any media scan, only when it is triggerd manually. Plex media server is for sure not the issue here since on all other platforms it runs fine, just 3B+ dies... It might be the trigger but the issue lies in the Ethernet chip of the 3B+.
The 3B+ also crashed a few times with the same symptoms when i did a simple apt-get upgrade, just with Plex i can reproduce the issue always.

@JamesH65
2 meters UTP CAT6 cable

Right now i have an uptime of 38 hours, which i never saw before on a 3B+ connected via ethernet. Let's see if it survives the next night...

lategoodbye · 2018-07-01T19:00:04Z

@pelwell PMS opens several ports (incl. DLNA server) so i think there could be a lot of reasons for this issue. I think it should be possible to reproduce it with 2x RPI 3B+ (1 CIFS server + 1 PMS) and a LPI capable network.

Maybe we could increase the value of tx_lpi_timer.

tilosp · 2018-07-01T20:42:18Z

I had a similar problem with my RPI 3B+.
It did not happen every night, it only happened every 2-3 days. And i fixed it by setting up a cron job that rebooted it every night.

The only thing i am running on it is a haproxy instance inside a docker container.

I have disabled the reboot cron job and disabled eee this morning. And it looks like it fixed the problem.

(My cable is about 1 meter long.)

merdok · 2018-07-02T06:13:21Z

Unfortunately the 3B+ was dead again today at the morning with EEE off... What a shame...

I did one change in comparison to the first night where it survived. I have assigned a static IP address to the 3B+ ethernet mac address in the router so it always has the same IP (normally i do this always straight ahead but this time the first night i didn't do it since i thought this will be just a quick test).

So maybe DHCP i also a variable here which triggers the issue?

The next night i will try to remove the static ip address from the 3B+ again and see if it dies.

lategoodbye · 2018-07-02T06:34:07Z

@tilosp As you run into the same issue, do you have a HDMI screen or serial connection connected to the Pi to see what's happend if the issue appeared?

tilosp · 2018-07-02T08:42:13Z

@lategoodbye no i am running it headless

lategoodbye · 2018-07-02T08:45:22Z

Let me rephrase my question: could you please connect a HDMI screen or serial connection to the Pi and make the issue occur?

tilosp · 2018-07-02T08:55:44Z

Yes i can connect a monitor and try to make the issue occur. But i can only try it next weekend because i am currently about 150km away from my pi.

Are there some specific commands I should run if i get the issue to occur?

lategoodbye · 2018-07-02T09:07:46Z

In case you still can run commands, please run the following commands:

dmesg
lsusb
ethtool -S eth0

Otherwise try to make a screenshot of the possible kernel panic.

merdok · 2018-07-03T06:36:39Z

Today at the morning my 3B+ was again dead. I did remove the MAC address of the Pi from my router so it did not have a static IP, also the EEE was on.

I also moved the 3B+ next to my TV so i could connect it to HDMI after it dies as suggested by @lategoodbye, but unfortunately it gave me "no signal" after i plugged in the HDMI on my TV so it was completely dead.

lategoodbye · 2018-07-03T06:44:53Z

What was the state of Pi LEDs?
Did you connected a USB keyboard to wake up the screen?

JamesH65 · 2018-07-03T07:43:01Z

So would it be correct to say that turning off EEE did make quite a difference, but didn't completely fix the issue, just made it less likely to happen? I wonder if we are seeing two issues here.

merdok · 2018-07-03T08:29:02Z

@lategoodbye
The state of the Pi LEDs are completely random, sometimes when it dies the green light is always on sometimes only the red is on.
I did not connect a USB keyboard, i never used the GUI on the Pi so i am not familiar how this works. At least when i pulled the plug and put it back in, then i saw the Pi booting on my TV and it finally stopped at a command line with a prompt to login.

@JamesH65
i will try tonight turning off EEE again and see what happens.

lategoodbye · 2018-07-04T05:46:30Z

Do you use a case for the Raspberry Pi and in case what kind?

merdok · 2018-07-04T06:42:48Z

I use a case but i also already tried numerous times without a case and nothing changed.

So today at the morning the 3B+ was dead again, i did set EEE to off so it seems that it is not the issue.
I did again connect a HDMI cable and this time there was signal and a kernel panic. Here is an image from it : Kernel panic
Hopefully this will be helpful...

pelwell · 2018-07-04T09:27:32Z

It's a shame that the useful bit - what CPU0 was doing - is off the top of the screen. You could try setting framebuffer_height=2160 in config.txt to capture a bit more.

merdok · 2018-07-04T10:02:17Z

@JamesH65
It only happens when the 3B+ is connected over ethernet to the router, using WiFi the 3B+ runs stable, so i assume this has something to do with it.

@pelwell
Will do that tonight and i will post the results tomorrow. Isn't the kernel panic dumped to a file which i can just paste here for you?

pelwell · 2018-07-04T10:03:59Z

It might be - it depends on which context and how hard it crashes. It's going to be in /var/log/syslog if anywhere.

merdok · 2018-07-04T10:08:37Z

Ok i will later check out if i can find the kernel panic there.
Also i assume framebuffer_height=2160 will change the resolution, do i also need to change the width to 3840 or is just setting the height enough?

pelwell · 2018-07-04T10:21:54Z

The height is what matters. I found that it looks the same whether or not I set the width, but you may get different results.

merdok · 2018-07-04T16:18:39Z

I did check /var/log/syslog and this are the last few log lines:

Jul 4 02:00:49 raspberrypi dhcpcd[385]: eth0: no IPv6 Routers available
Jul 4 02:00:54 raspberrypi systemd[1]: home-pi-network_drive.automount: Got automount request for /home/pi/network_drive, triggered by 762 (Plex Media Serv)
Jul 4 02:00:54 raspberrypi systemd[1]: Mounting /home/pi/network_drive...
Jul 4 02:00:54 raspberrypi kernel: [ 27.315862] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-5
Jul 4 02:00:54 raspberrypi systemd[1]: Mounted /home/pi/network_drive.
Jul 4 07:18:58 raspberrypi systemd[1]: Time has been changed

So it seems that after the drive was mounted the 3B+ instantly died. At 7:18 i restarted the Pi.

Also a few seconds before that, there are the following lines in the log:

Jul 4 02:00:38 raspberrypi systemd[1]: home-pi-network_drive.automount: Got automount request for /home/pi/network_drive, triggered by 561 (Plex Media Serv)
Jul 4 02:00:38 raspberrypi systemd[1]: Reached target Network is Online.
Jul 4 02:00:38 raspberrypi systemd[1]: Mounting /home/pi/network_drive...
Jul 4 02:00:39 raspberrypi kernel: [ 11.406960] FS-Cache: Netfs 'cifs' registered for caching
Jul 4 02:00:39 raspberrypi kernel: [ 11.407336] Key type cifs.spnego registered
Jul 4 02:00:39 raspberrypi kernel: [ 11.407351] Key type cifs.idmap registered
Jul 4 02:00:39 raspberrypi kernel: [ 11.418265] CIFS VFS: Error connecting to socket. Aborting operation.
Jul 4 02:00:39 raspberrypi kernel: [ 11.418277] CIFS VFS: cifs_mount failed w/return code = -101
Jul 4 02:00:39 raspberrypi systemd[1]: home-pi-network_drive.mount: Mount process exited, code=exited status=32
Jul 4 02:00:39 raspberrypi systemd[1]: Failed to mount /home/pi/network_drive.
Jul 4 02:00:39 raspberrypi systemd[1]: home-pi-network_drive.mount: Unit entered failed state.

The Pi did try a few times to mount it but with failures...

If you need any more specific info i can check the log...

I have also set framebuffer_height=2160. Tomorrow morning i will report with more details about the kernel panic.

pelwell · 2018-07-04T16:27:30Z

I know you have claimed repeatedly that Plex doesn't run an overnight scan on your system, but I humbly suggest that you may be mistaken. Notice that the automount request is running on behalf of Plex Media Serv.

Even if I'm right it wouldn't excuse the crashes and lockups, but it would help to understand why they are occurring.

merdok · 2018-07-04T16:41:04Z

As you can see here periodical scanning is disabled. From the Plex documentation about the Scan my library automatically option:

This uses capabilities of the operating system to detect when content has changed and then initiate a library scan.

So it still doesn't explain why it only crashes exactly at around 2:00 in the morning. It should crash every time i copy some new media to the drive since then the scanning starts, but this is not the case.

Anyway like you say, it doesn't matter here. Plex might be the trigger but the issue is with the 3B+ which should slowly be resolved after almost 4 months now...

pelwell · 2018-07-04T16:47:58Z

Do you have anything relevant enabled in the "Scheduled Tasks" section? At what time does they run?

merdok · 2018-07-04T17:01:42Z

Actually that was my first time that i checked that section. Those are default values in there, i never touched them Scheduled Tasks
That would explain why it is crashing always around 2:00 in the morning, but i have looked in the syslog again and checked the crash from yesterday:

Jul 3 01:52:01 raspberrypi systemd[1]: home-pi-network_drive.automount: Got automount request for /home/pi/network_drive, triggered by 748 (Plex Media Serv)
Jul 3 01:52:01 raspberrypi systemd[1]: Mounting /home/pi/network_drive...
Jul 3 01:52:01 raspberrypi kernel: [ 28.266871] CIFS VFS: ioctl error in smb2_get_dfs_refer rc=-5
Jul 3 01:52:01 raspberrypi systemd[1]: Mounted /home/pi/network_drive.

It already crashed before 2:00...

merdok · 2018-07-05T06:20:35Z

Here is the Kernel panic from today, there is a little more information. I hope that this can help...

lategoodbye · 2018-07-05T08:00:53Z

The panic looks similiar like #2538

Any idea to trigger the scheduled task on demand?

Btw my RPI 3B+ has now a uptime of 1 day and 10 hours, so your Plex media server seems to have more "load" during scheduled tasks.

pelwell · 2018-07-05T08:39:07Z

That trace is very helpful. With a certain amount of guesswork I would say that lan78xx_bh is processing a corrupted skb chain (the tx queue), probably failing in the call to skb_is_gso in the loop at the top of lan78xx_tx_bh.

I can see the kernel version, but if you know exactly which build it is that would help to remove some of the uncertainty. A serial cable to capture the crash log would be even better, but this is already massive help.

merdok · 2018-07-05T08:56:37Z

@lategoodbye
Unfortunately i have no idea how to trigger that on demand. But that would be definitely better then waiting 24 hours for a crash...

@pelwell
That sounds good :)
How do i find out the exact build?
Unfortunately i am not familiar with the serial console...

pelwell · 2018-07-05T09:10:27Z

@merdok If you get your kernels from rpi-update then the content of /boot/.firmware_revision is sufficient information.

Is the txq_pend queue access in lan78xx_tx_bh safe? The skb list structure (skb_buff_head) includes a lock but the standard skb queue API methods don't call it themselves - it is up to the caller to do so depending on the use case. Some guidelines on the context of calls to the netdev_ops methods and their interactions with bottom halves would be useful.

pelwell · 2018-07-05T10:07:53Z

I think the netdev_ops methods are called in atomic context, interlocked against the bottom half handlers, so the txq_pend access is (at least at a basic level) safe, but something is clearly wrong - either a race condition or a buffer overflow/memory corruption.

merdok · 2018-07-05T16:19:08Z

@pelwell
Here you go, the exact build: 76f2126f958813868e6b07945c948761d8eec91d

lategoodbye · 2018-07-07T12:14:03Z

@merdok At least you can avoid the manual restarts after the crash by adding panic=5 to cmdline.txt

merdok · 2018-07-07T12:57:51Z

I currently switched back to WiFi, since it works rock solid using that :)

@pelwell any progress? Do you need me to do any more tests?

pelwell · 2018-07-08T11:06:05Z

Progress is being made in a parallel issue (#2608) which may turn out to be caused by the same bug. We've worked out that under some circumstances the pending queue can appear to have one more sk_buff on it than is actually the case. This causes a naive list walk to misinterpret the end marker or sentinel (actually the object that represents the list as a whole) as being an sk_buff. Since the sentinel doesn't have an end pointer, attempts to use it end up using some other data as a pointer, hence the crash.

I'm going to put this issue on hold (but leave it open) until we have some more answers in #2608.

JamesH65 · 2018-07-11T14:50:31Z

@merdok Worth checking #2608 which now has a fix, and which will probably fix this issue as well.

merdok · 2018-07-11T16:24:56Z

@JamesH65 cool, thanks for the info. I will check that out and let you know if this is fixed. When will the fix be available through rpi-update ?

popcornmix · 2018-07-11T20:39:52Z

The potential fix is now in rpi-update kernel.

merdok · 2018-07-13T06:23:39Z

@JamesH65 @pelwell
It seems that this fix is working. The 3B+ survived 2 nights using Ethernet with the latest rpi-update kernel.

pelwell · 2018-07-13T06:26:39Z

That's good news. Please close the issue when you feel the matter is resolved.

merdok · 2018-07-13T06:55:40Z

I will try it for a few more days and if everything is fine, i will close the issue!

merdok · 2018-07-15T06:43:51Z

Ok, I guess that this fix is definitely working. My 3B+ survived now 4 night and has an uptime of 4 days. Thanks!

merdok closed this as completed Jul 15, 2018

amovitz mentioned this issue Jul 16, 2018

Raspberry Pi 3B+ transferring large amounts of data with the ethernet interface locks up system #2608

Closed

karsc96 mentioned this issue Apr 13, 2020

Pi3B+ freeze with connections via eth0, no issue with wlan0 raspberrypi/firmware#1368

Open

Raspberry Pi 3B+ freezes with a network share mounted and ethernet connected #2598

Raspberry Pi 3B+ freezes with a network share mounted and ethernet connected #2598

Comments

merdok commented Jun 27, 2018

lategoodbye commented Jun 28, 2018

JamesH65 commented Jun 28, 2018

JamesH65 commented Jun 28, 2018

merdok commented Jun 28, 2018 • edited Loading

JamesH65 commented Jun 28, 2018

lategoodbye commented Jun 28, 2018

merdok commented Jun 28, 2018 • edited Loading

lategoodbye commented Jun 29, 2018 • edited Loading

merdok commented Jun 29, 2018 • edited Loading

lategoodbye commented Jun 30, 2018 • edited Loading

merdok commented Jul 1, 2018 • edited Loading

lategoodbye commented Jul 1, 2018

merdok commented Jul 1, 2018

JamesH65 commented Jul 1, 2018

pelwell commented Jul 1, 2018

merdok commented Jul 1, 2018 • edited Loading

lategoodbye commented Jul 1, 2018

tilosp commented Jul 1, 2018

merdok commented Jul 2, 2018 • edited Loading

lategoodbye commented Jul 2, 2018

tilosp commented Jul 2, 2018

lategoodbye commented Jul 2, 2018

tilosp commented Jul 2, 2018

lategoodbye commented Jul 2, 2018

merdok commented Jul 3, 2018 • edited Loading

lategoodbye commented Jul 3, 2018

JamesH65 commented Jul 3, 2018

merdok commented Jul 3, 2018 • edited Loading

lategoodbye commented Jul 4, 2018

merdok commented Jul 4, 2018

pelwell commented Jul 4, 2018

merdok commented Jul 4, 2018

pelwell commented Jul 4, 2018

merdok commented Jul 4, 2018 • edited Loading

pelwell commented Jul 4, 2018

merdok commented Jul 4, 2018

pelwell commented Jul 4, 2018

merdok commented Jul 4, 2018 • edited Loading

pelwell commented Jul 4, 2018

merdok commented Jul 4, 2018 • edited Loading

merdok commented Jul 5, 2018

lategoodbye commented Jul 5, 2018

pelwell commented Jul 5, 2018

merdok commented Jul 5, 2018

pelwell commented Jul 5, 2018

pelwell commented Jul 5, 2018

merdok commented Jul 5, 2018

lategoodbye commented Jul 7, 2018 • edited Loading

merdok commented Jul 7, 2018 • edited Loading

pelwell commented Jul 8, 2018

JamesH65 commented Jul 11, 2018

merdok commented Jul 11, 2018

popcornmix commented Jul 11, 2018

merdok commented Jul 13, 2018

pelwell commented Jul 13, 2018

merdok commented Jul 13, 2018

merdok commented Jul 15, 2018

merdok commented Jun 28, 2018 •

edited

Loading

merdok commented Jun 28, 2018 •

edited

Loading

lategoodbye commented Jun 29, 2018 •

edited

Loading

merdok commented Jun 29, 2018 •

edited

Loading

lategoodbye commented Jun 30, 2018 •

edited

Loading

merdok commented Jul 1, 2018 •

edited

Loading

merdok commented Jul 1, 2018 •

edited

Loading

merdok commented Jul 2, 2018 •

edited

Loading

merdok commented Jul 3, 2018 •

edited

Loading

merdok commented Jul 3, 2018 •

edited

Loading

merdok commented Jul 4, 2018 •

edited

Loading

merdok commented Jul 4, 2018 •

edited

Loading

merdok commented Jul 4, 2018 •

edited

Loading

lategoodbye commented Jul 7, 2018 •

edited

Loading

merdok commented Jul 7, 2018 •

edited

Loading