Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Raspberry Pi 4: Network non-functional directly after (re)boot #3034

Closed
M-Reimer opened this issue Jun 30, 2019 · 56 comments

Comments

@M-Reimer
Copy link

commented Jun 30, 2019

Describe the bug
If I boot directly to an up-to-date Raspbian, then the network starts up in some kind of "no-functional" state. Means that dhcpcd does not manage to get an IP and trying to manually run dhcpcd on the interface hangs forever.

The problem resets if I unplug and replug the network cable. This triggers fetching a valid IP and properly enables the network interface.

It is also possible to reset from the non-functional state by running
sudo mii-tool -r eth0
This also "unblocks" the network card and makes dhcpcd get a new IP.

To reproduce
Seems like not everyone is able to reproduce this bug. Maybe it's even some kind of "hardware problem".
But on affected Raspberry Pi 4 board, everything you have to do is to reboot. Result will be non-functional network.

Expected behaviour
Network should come up without problems every time.

Actual behaviour
Network hangs until mii-tool -r is called or the network cable is unplugged and replugged.

Logs
I already published some logs here:
https://www.raspberrypi.org/forums/viewtopic.php?f=66&t=244061#p1488426
I can provide more if needed.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2019

Weird, I reboot my Pi4 all the time with no network issues at all, and i have not heard of anyone else with anything similar. Can you try with a different router (or perhaps even reboot your router in case that behaving oddly).

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 1, 2019

I've tried all that already (check forum thread). All the previous raspberry models work without any issues at the same router.

I think it is interesting that the problem can be reset in software. The kernel module should be able to detect this case to "fix" it automatically.

@ummon29

This comment has been minimized.

Copy link

commented Jul 1, 2019

I seem to have similar Problems with my new Pi4.
It's an System with a manualy configured IP. The System is the old system upgraded to buster. Had it running on an Pi3B with buster while I waited for the Pi4B without any Problems. Since I switched to the Pi4B I had Problems with the NIC.
Yeserday the network stopped to work and I rebooted (the System is Headless).
The reboot didn't help. The LEDs of the NIC flashed every few seconds but I couldn't get a Link.
Two further reboots didn't help only after restarting the switch the Link would come up again. (A managed HP-Switch. The Log of the Switch didn't show any problems).
Today I had the problem again. The NIC stoped working for 15 to 20 minutes. Afterwards it started to work again without any change from my side.
Looking in the dmesg output I can see that the problem is happening from tine to time.
I'll try if plugging the RPi4B in another Switch changes the behaviour.

dmesg from tonight:

[40987.338593] bcmgenet fd580000.genet eth0: Link is Down
[40987.338717] br0: port 1(eth0) entered disabled state
[40989.418628] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[40989.418675] br0: port 1(eth0) entered blocking state
[40989.418695] br0: port 1(eth0) entered forwarding state
[40994.619008] bcmgenet fd580000.genet eth0: Link is Down
[40994.619131] br0: port 1(eth0) entered disabled state
[40997.738788] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[40997.738843] br0: port 1(eth0) entered blocking state
[40997.738862] br0: port 1(eth0) entered forwarding state
[41005.018835] bcmgenet fd580000.genet eth0: Link is Down
[41005.018956] br0: port 1(eth0) entered disabled state
[41007.098925] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[41007.098971] br0: port 1(eth0) entered blocking state
[41007.098990] br0: port 1(eth0) entered forwarding state
[41012.298947] bcmgenet fd580000.genet eth0: Link is Down
[41007.098990] br0: port 1(eth0) entered forwarding state
[41012.298947] bcmgenet fd580000.genet eth0: Link is Down
[41012.299070] br0: port 1(eth0) entered disabled state
[41014.379015] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[41014.379060] br0: port 1(eth0) entered blocking state
[41014.379080] br0: port 1(eth0) entered forwarding state
[41024.779133] bcmgenet fd580000.genet eth0: Link is Down
[41024.779254] br0: port 1(eth0) entered disabled state
[41027.899209] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[41027.899256] br0: port 1(eth0) entered blocking state
[41027.899276] br0: port 1(eth0) entered forwarding state
[48321.531109] bcmgenet fd580000.genet eth0: Link is Down
[48321.531231] br0: port 1(eth0) entered disabled state
[48323.611093] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[48323.611139] br0: port 1(eth0) entered blocking state
[48323.611158] br0: port 1(eth0) entered forwarding state
[48321.531231] br0: port 1(eth0) entered disabled state
[48323.611093] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control off
[48323.611139] br0: port 1(eth0) entered blocking state
[48323.611158] br0: port 1(eth0) entered forwarding state

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 1, 2019

@ummon29 Can you try if "mii-tool -r eth0" fixes the issue for you, too?

As the problem only seems to happen for a few Raspberry Pi systems, I think it could be a hardware issue.
I'm planning to buy a second unit just to check if the LAN interface is stable with a second one.

I still don't think that this is an issue that can't be fixed on kernel side ("mii-tool -r eth0" actually fixes the problem for me) but I'm no kernel hacker. With this specific model it can be reproduced 100% of the time. I would just need more info on how to deliver the info a kernel developer needs. I could also ship the unit to someone with the needed knowledge. I would pay for shipping in one direction but would either want my unit back after some time or the money for the RPi board.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2019

@M-Reimer Not sure yet whether we would need this back - we might. We always replace like for like, plus goodies to pay for the postage.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 1, 2019

So I'll wait. My plan was to try to get a refund from the seller in case noone here is interested in this particular unit.
Will buy a second one now to get sure that a new unit doesn't have the same problems (to rule out my network infrastructure). But I'm almost 100% sure it is not my network. I had several RPi 1, 2 and 3 boards running here without ever having problems with the network.
In fact the gigabit network is one of the reasons why I really like the new RPi 4. If we get this stable it can be used for several network services like small NAS systems, router, small in-house server, ...

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2019

We have noted some strange DHCP issues that seem related to the network hardware, different switches show different results. We'll look in to it.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 1, 2019

It doesn't seem to be DHCP issues only. I configured my RPi 4 for static IP and rebooted several times. The journal always says that IP, route and DNS are set properly but it is impossible to reach the RPi.

Then I tried the switch thing. I still have some old 100MBit switch and connected it in place of my 1GBit one. With this switch in place I was able to reboot 5 times and network was always available.

So yes, this changes with changing the switch. But of course I would prefer to run the 1GBit card on a 1GBit switch 😛

So I think if I buy a second one, then this will show exactly the same problem on this switch?

@6by9

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2019

What make and model is your gigabit switch? Is it managed, and if so what speed, duplex and flow control settings have you set?
We're generally running every day with a gigabit switch with no issues, so there's obviously something subtle in there somewhere.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 1, 2019

D-Link DGS-108
https://www.amazon.de/dp/B000BCC0LO/
Simple switch without management.
I never had problems with this switch on any other device. Including Raspberry boards from version 1 to 3. It's the RPi 4 which causes problems for the first time...

I've ordered a second RPi 4 now. Just to see if a new board causes the same problems on this switch.

@ummon29

This comment has been minimized.

Copy link

commented Jul 1, 2019

At the moment everything is running fine. When it's happening again and I have the opportunity I'll try "mii-tool -r eth0". My Switch is a managed HP 1810-8G The connection is running at 1000Mbps FullDuplex. The error counters are at 0 and the only log entry was that the port was down. Disconnecting an reconnecting didn't work even after a reboot of the RPi. Connecting the RPi with another cable to an AVM FritzBox (7490) worked instantly. After I restarted the Switch everything was fine again. I sill have to replace the cable to rule out that the problem is in the cable. My RPi has a manually configured IP.
In my case I'm not 100% sure if the problem is the Raspberry but it started the day after I switched from the RPi3B to the RPi4B without any other changes (I already updated to buster with the RPi3B as soon as it was possible).

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Jul 1, 2019

It's likely that there is a bug in Ethernet/PHY driver. Even hardware and drivers that appear to work well suddenly develop issues when exposed to the vast number of devices and use cases that make up the world of Pi. We had a very busy few weeks after the launch of the 3B+ with network glitches, but they were sorted eventually.

@ummon29

This comment has been minimized.

Copy link

commented Jul 2, 2019

After changing to another cable and switch still the same problem.
I'm now directly connected to the AVM FritzBox 7490.

dmesg:
[ 182.553342] bcmgenet fd580000.genet eth0: Link is Down
[ 182.553465] br0: port 1(eth0) entered disabled state
[ 185.673598] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 185.673644] br0: port 1(eth0) entered blocking state
[ 185.673664] br0: port 1(eth0) entered forwarding state

I had no chance to test "mii-tool -r eth0" yet.
The error isn't happening all the time. I have it once or twice a day at different times. Most of the time the link comes up again after a few seconds. Most of the time I only see the errors afterwards in the dmesg output.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 9, 2019

I've received another RPi 4 board, now.

I just moved the same SD card to the new board and rebootet about 10 times. With static IP and with DHCP. Never had a problem. But I'll do some more tries just to be sure. I'll then also start to use this board for some 24/7 network stuff to see how stable the ethernet card will be.

After this test, I move the SD card back to the old board. First boot activated the network interface without issues but the first "sudo reboot" started in non-functional network, again. Unplugging and replugging the network cable fixed the problem just as before.

So this may have something to do with my hardware. Probably in combination with the specific switch that I use.

Tell me if it is possible to help with fixing this issue somehow.

@P33M

This comment has been minimized.

Copy link
Contributor

commented Jul 9, 2019

Can you try forcing the mac address of the not-working Pi to that of the working Pi? Use the config.txt option force_mac_address=xx:xx:xx:xx:xx:xx

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 10, 2019

I've tried that (and verified that the mac address really changed).
It doesn't change anything.
Network failed right on the first boot with the config.txt change and worked after unplugging/replugging the cable...

@tbaeuerlepi

This comment has been minimized.

Copy link

commented Jul 10, 2019

I have exactly the same issue on my RPi 4 4GB and only unplug and replug the network cable brings the pi back to be able to SSH into it.
Running on a Netgear switch with Fritzbox 7490 as DHCP Server. With or without a static IP does not change anything

@api4user

This comment has been minimized.

Copy link

commented Jul 11, 2019

I have also experienced this issue and I raised the issue on the Raspberry Pi forum.

I now have two Pi 4's each with 4Gb of RAM. With everything the same except the Pi board one works and one does not.

As @M-Reimer discovered the only ways to get an IP address with the not working one seem to be to unplug/plug the network cable or to somehow run ethtool -r eth0 or mii-tool -r eth0.

Let me know if there are any tests or commands you would like me to run.

@api4user

This comment has been minimized.

Copy link

commented Jul 16, 2019

Any further news or should I just throw away this defective Pi 4? I do not feel it is up to the usual Pi standard in manufacture (I own/have owned more than 10 and this is only the second I have had problems with) and would not feel confident using it in a production environment due to the hack required to make it boot. I wish there was some other way of contacting Raspberry Pi rather than having to air my grievances in public.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

@api4user It does sound like a defective device given an alternative device does not show the same issue. Do not throw it away, it should be replaced under warranty. I'll ping some others to see if they have any comment. @pelwell @P33M @jimbojr Would it be worth getting defective device back to us?

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

@api4user Yes, we would like that device back for internal testing please. We will replace it by return + goodies to cover postage costs. Please contact me via email info@raspberrypi.org, using FAO James Hughes at the top, to arrange how to get it to us. Thanks.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 16, 2019

Same for my case or should I return to my seller for a refund?
@JamesH65

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 16, 2019

@M-Reimer Yes please, can you follow instructions in my previous post and contact me via email please. We are trying to get together a database of unusual failures for quality control purposes, so everything is helpful!

@ummon29

This comment has been minimized.

Copy link

commented Jul 20, 2019

I found a bit of time to debug the problem further.
I still had no chance to test mii-tool -r eth0 because for me eth0 doesn't hang at startup all the time. I had it a few times when I was connected to the HP-Switch (HP 1810-8G). I had it once that for several reboots the device didn't come up. Switching from HP-Switch to the FritzBox 7490 fixed it that time. Most of the time everything starts fine and after some time (seconds to hours) eth0 disconnects and reconnects for a few times. afterwards everything is fine again for some time.
When the problem occurs it happens for 1 to 3 times in a short period and afterwards everything if fine for a while. Most of the times the link is only down for 2-3 seconds.
Here is a typical dmesg output of such a case:

[ 159.832782] bcmgenet fd580000.genet eth0: Link is Down
[ 162.952881] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 165.032880] bcmgenet fd580000.genet eth0: Link is Down
[ 167.112949] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
[ 172.312944] bcmgenet fd580000.genet eth0: Link is Down
[ 175.433042] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

I tested with a fresh raspbian buster install to ensure that it's no problem with my old updated system. The problem is the same.
Using dhcp or static IPs doesn't make a difference.
When switching back to my old Pi3B the same SD-Card with the system has no problem.
When switching from eth0 to eth1 (eth1 is an USB to Ethernet Adapter) on the Pi4B the problem is gone.
I connected the the Pi4B to an FortiGate firewall in transparent mode and monitored the traffic to see if I find some packets that trigger the problem. The problem was the same connected to the FortiGate but nothing special happened in the packet dump while the problem occurred.
All devices the PI4 was connected to (FritzBox, HP-Switch and FortiGate) show nothing special in their logs except that the link goes down and comes up again.
All devices use auto negotiation for the speed of the links. The Link comes always up with 1Gbps/Full. I haven't tried to set the NICs to a fixed speed yet.
It should be no problem with the power. I use the original USB-C adapter for the PI.
The temperature is most of the time around 60 degrees Celsius.
I'm just testing with an Cisco SG250-08 as a switch. No problems yet but I'm just a few minutes in the test.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 21, 2019

@M-Reimer Yes please, can you follow instructions in my previous post and contact me via email please.

I guess this "info@" address gets too much mail and so it takes long for the queue to be processed?
Anyway. That's my mail address: manuel.reimer [at] gmx.de

@ummon29

This comment has been minimized.

Copy link

commented Jul 23, 2019

A quick Update.
The three days since my Pi4B is connected to the Cisco SG250-08 i had no connection problems with the NIC. I'm cautiously hopeful to have a combination here that is working without the problem. Before trying the Cisco Switch the longest time between those disconnects were around one day.
I don't know exactly which Switch/Router/Firewall was connected when but if I remember correctly the AVM FritzBox 7490 had the most problems. I often had the first disconnect within minutes after the Pi started and when it started I then I got 2-3 disconnects in a row. But I never got any disconnects that didn't recover within 2-3 seconds.
With the HP 1810-8G I had problems between one and four times a day. This is the only device where I had disconnects that didn't recover within seconds.
The FortiGate (61E) was only tested for a short time by me. I had my first disconnects with this device within 2-4 hours.

@TheGreatestJannet

This comment has been minimized.

Copy link

commented Jul 25, 2019

I am also experiencing the exact same issue on a Pi4B 4GB model. @JamesH65 do you still want it back or should I contact the seller?

Sorry for the ping I have resolved the issue. It seems that a program edited the dhcpcd.conf to add a static ip. The config was:
interface eth0
static ip_address=192.168.3.7
static routers=192.168.3.254
static domain_name_servers=
After commenting it out the pi connects every time after reboot.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

I returned my Pi 4 to you a week ago. You emailed to say you could not replicate the problem and were sending my Pi back. I have still not received it back. I am not happy.

There definitely IS a problem as one of my Pi's works and the other did not.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

@api4user It's only been a week! Please take into account the time to pack stuff up and get it back to you. I wasn't dealing with this one, so will try and find out what is happening. Who emailed you the results? (Difficult to cross reference api4user against an email address/actual identity)

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

@JamesH65 Richard Jones but the return address I was given was to you.

BTW it may only be a week to you but I bought this three weeks ago and have been trying to fix it ever since. This is extremely frustrating especially after also being caught up in the PoE fiasco as well. To be told there wasn't a problem with the board and to be told it will just be sent back to me was the final straw. I sent the board to you immediately when you requested it AT MY EXPENSE. The least you could do would be to send it back in a timely manner when you failed to reproduce the error.

There are more and more people reporting this problem on the forums so it isn't just us here and there is a problem.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 26, 2019

I haven't received anything back to my mail at all.

The bug can only be reproduced in specific situations. In my case changing the switch "fixes" it. But I also wrote which specific switch model triggers the problem in my case. The switch is cheap. I can send you my one if you prefer to have the model which triggers the problem for sure.

I would also send detailed logs captured when the problem occurs. If someone tells me how to do so. Then maybe I don't have to send anything at all and can create some logs on my side.

I would have preferred to help with debugging by sending you my board but if that's what happens (board sent back if you can't reproduce in an environment where the problem isn't triggered at all) then I'll contact my German seller directly. I'll get my replacement for sure if I do so. I know that the problem exists in my environment and if you just send me back my problematic unit doesn't help me.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

@M-Reimer I had your email to info forwarded to me this morning, don;t know why it took so long, but the info address does get a LOT of email so probably just that queue. I think we will want that one back, but will email you with details.

@api4user Richard doesn't work full time, but is in today so will talk to him about it. Should be sent back today, although we are backlogged in sending stuff out at the moment so might be Monday. Apologies for the delay.

I can only apologise about delays here, we are very busy at the moment, throughout Trading. In future we will only ask for devices back from people who are OK with the timescales involved. Had I been aware you needed stuff back within a week we would not have approached you to return the device.

Note, PoE power issues is fixed by updating the bootloader as described here https://www.raspberrypi.org/forums/viewtopic.php?f=117&t=246027

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

@api4user a package was sent out yesterday to a Mr Harper - if that is you (I cannot X-reference the github username to an individual so don't know for sure), it's on its way.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

@JamesH65 The timescale wouldn't be a problem if I was told about. Like @M-Reimer my email reply to Richard was ignored as well so I had no idea what was going on. My review of this Pi isn't going to be very positive.

I will try and ring Eben about this later, I think I have his business card somewhere from the last press junket I attended.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

I've passed on concerns about the process to management.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

It is not just the process.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

@JamesH65 FWIW I have just received the replacement Pi. It cost me £15 to return (third of the price of the Pi) and I have wasted many many hours on this. Was it worth it for the extra goodies you promised? For anyone who is interested the promised goodies consisted of a £5 cable (https://www.raspberrypi.org/products/micro-hdmi-to-standard-hdmi-a-cable). Nothing else. Who knows whether the replacement Pi will be another dud or not?

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 26, 2019

@M-Reimer I had your email to info forwarded to me this morning, don;t know why it took so long, but the info address does get a LOT of email so probably just that queue. I think we will want that one back, but will email you with details.

Please only if you are willing to test in the proper test environment. This includes the switch that I recommended.

In your current environment the result will be the same as with the unit of @api4user and if you just send the board back to me, this just wastes time that could have been saved if I just sent back to my seller directly.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

@M-Reimer I would send it back to your seller. They are not interested in resolving this. I offered my help too in private but had to resort to this. (Sorry for hijacking your thread but don't waste your time sending it back to them.)

@LizUpton

This comment has been minimized.

Copy link

commented Jul 26, 2019

@api4user, what is your name? I just want to chase up what's happened with our shipping department. If you're not happy providing that in a public forum, just your initials and the town where you live will be sufficient.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

Yes, we are interested in fixing this - not sure how you have got the impression we are not. As a SW guy working on the Pi4, it's been nothing BUT report investigations and fixes for the last 5 weeks (and the development for months before that), as always happen when you let a new device loose to a much larger pool of environments.

It appears to be an issue with a small number of switches (since the huge majority of people have not encountered the problem), and I believe we now have replicated the issue with an in house device and switch. So we will be investigating; it's likely some relatively unused code path in the Linux ethernet driver (not written by us btw) triggered by unusual responses from the switch. It seems likely we no longer need any devices back that exhibit the issue.

@LizUpton

This comment has been minimized.

Copy link

commented Jul 26, 2019

OK: I think someone's not operating in good faith here, and I'm damned if I know why; this is very, very odd. I've just followed api4user's link back to the forums where he posts as Yanewby, and because I'm an administrator there I can see from his email address that he is the person we thought he was when we were trying to figure out when his box had been posted, although he has failed to confirm that here. Many things he has said here do not add up.

I have looked at Richard's emails, and can see that he has not only received and read all of api4user's mails: he has also replied to them.

We have the Jiffy bag the unit was posted to us in. The franking label says he spent £3 on postage, not the £15 he's claiming.

I have looked at our shipping logs. The package that was sent to him (which he received today) contained the original Pi 4, the cable he said he needed, as well as a brand new Pi 4 which we included as a courtesy.

I run the press department here. We have not held any press conferences or other "junkets" since February 2016 (we have a more nuanced approach now to working with press), and I keep lists of attendees alongside other press lists. He doesn't appear on any of them.

Finally, Eben doesn't use business cards. He's sitting opposite me now. He says you should feel free to call him right now if you actually have his number, @api4user; and that if you don't, he's calling bullshit.

Like I say, I'm not sure what's going on here; from the forum posts it looks like there was initially some genuine problem, but someone seems to be trying to exploit that.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

@LizUpton You are so wrong. Please have a member of your legal team contact me. I take libel very seriously.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

Yes, we are interested in fixing this - not sure how you have got the impression we are not. As a SW guy working on the Pi4, it's been nothing BUT report investigations and fixes for the last 5 weeks (and the development for months before that), as always happen when you let a new device loose to a much larger pool of environments.

It appears to be an issue with a small number of switches (since the huge majority of people have not encountered the problem), and I believe we now have replicated the issue with an in house device and switch. So we will be investigating; it's likely some relatively unused code path in the Linux ethernet driver (not written by us btw) triggered by unusual responses from the switch. It seems likely we no longer need any devices back that exhibit the issue.

Not that you will be at all interested after @LizUpton's libellous post but the replacement board also has the same issue.

@JamesH65

This comment has been minimized.

Copy link
Contributor

commented Jul 26, 2019

OK, since the 'legal' word has been brought up, there will be no further word of comment from myself on this subject. I'm also closing this issue. Anyone commenting will do so at their own risk.

@JamesH65 JamesH65 closed this Jul 26, 2019
@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

I look forward to discussing this in court with you and @LizUpton who is too scared to contact me herself.

@LizUpton

This comment has been minimized.

Copy link

commented Jul 26, 2019

Very happy to. Please email me: press@raspberrypi.org.

@api4user

This comment has been minimized.

Copy link

commented Jul 26, 2019

What part of contact me do you not understand?

Closing things down because you are upset is not the way to resolve an issue. Neither is libelling someone.

This will not go away by you ignoring it.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 27, 2019

@M-Reimer I had your email to info forwarded to me this morning, don;t know why it took so long, but the info address does get a LOT of email so probably just that queue. I think we will want that one back, but will email you with details.

Would be great if you could answer this mail at some time so I know if you want the board back. Otherwise it goes to my seller for replacement.

Maybe in future a driver update could fix this board, but I would prefer to have one that works right now 😛

It appears to be an issue with a small number of switches (since the huge majority of people have not encountered the problem), and I believe we now have replicated the issue with an in house device and switch. So we will be investigating; it's likely some relatively unused code path in the Linux ethernet driver (not written by us btw) triggered by unusual responses from the switch. It seems likely we no longer need any devices back that exhibit the issue.

That's great news. This is more or less what I expected. Maybe some kind of timing issue. The funny thing is that the card is visible as fully functional on the Pi. With fixed IP it even gets the IP and at least on "MAC layer" it seems to be available to the outside (my router sees it as active). But any attempt of communication fails.

@patrikolausson

This comment has been minimized.

Copy link

commented Jul 28, 2019

I have the same problem as described in the initial comment. Setting a static address makes it respond to ping most of the time after boot, but no other communications work. mii-tool -r eth0 works every time so far, and I have added it to crontab as a workaround. I would really like to see a proper fix to this.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 28, 2019

The problem, described here in detail by many users, never was actually resolved.

So what should I do now? Can I (as the initial reporter) request reopening so the Issue can be closed later as soon as the problem is actually solved?

Or should I create a new Issue describing the same problem...

@pelwell

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2019

Another issue, if you would - a cut-and-paste of just the technical details, please. I'll be deleting any non-constructive posts - we all want to understand and fix the issue.

@M-Reimer

This comment has been minimized.

Copy link
Author

commented Jul 28, 2019

@zafrirron

This comment has been minimized.

Copy link

commented Oct 2, 2019

After 3 long continues days of investigating similar ethernet issues (eth0 down...), I've observed the following:

  1. The issues exists on my two RPI-4.
  2. The issue is not related to any network or device connected to the Pi (can be reproduced easily with no cable attached (eth0 is down)
  3. my tests done on clean Buster install (before and after ALL updates).
  4. I've observed different behaviour related to monitor attached to the HDMI connections
  5. I could bring back eth0 with static IP setting ifconfig eth0 xx.xx.xx.xx
  6. On several occasions performing (5) connected to the network and rebooting Pi with HDMI connected (the one closer to the USB) will block the boot (no screen), different behaviour on the second HDMI port.

The above leads me to suspect in some kind of HW design issue....
hopefully this will help someone in future investigation....

@divinehawk

This comment has been minimized.

Copy link

commented Oct 4, 2019

I am having the same issue with my newly purchased RPI-4.

The device loses link "Link is Down" for a few seconds and then comes back up.

This is a standard desktop TEG-S80G which has been rock solid for every other device I have connected.

@jakekarnes42

This comment has been minimized.

Copy link

commented Oct 6, 2019

I think I'm hitting the same with my new raspberry pi 4 board as well. The pi is connected directly to my router. It starts up and grabs an IP via DHCP. I connect to the board via SSH. It works fine for ~10 minutes then suddenly my SSH connection to the board becomes "choppy" (for lack of a better term). It becomes drastically slower to send characters/commands via SSH and then the SSH connection dies completely. If I wait a few minutes, the pi will become available again, and repeat the problem some time later.

I'm really not able to find the problem. Only (possibly) relevant output in syslog is the following:

[ 4256.278159] bcmgenet fd580000.genet eth0: Link is Down
[ 4259.350246] bcmgenet fd580000.genet eth0: Link is Up - 1Gbps/Full - flow control rx/tx

As others have mentioned, I haven't seen this with any of my previous generation raspberry pis, or any other device attached to my network.

Any help would be appreciated!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.