bensimmo wrote: ↑

Mon Jun 18, 2018 8:26 pm

I’m assuming this github thread seems to be the main ethernet debugging thread similar to this?
https://github.com/raspberrypi/linux/issues/2482

Closest one I think.

wybielacz wrote: ↑

Mon Jun 18, 2018 11:31 am

jamesh wrote: ↑

Mon Jun 18, 2018 9:40 am

Sadly, I don’t have time to dig through pages of posts to find one line of information. Can you give specific instructions on what you do to make this go wrong, and any errors that may be display (e.g. syslogs). Since this does NOT appear to be the tcp segmentation offload issue (although symptoms appear the same – welcome to the wonderful world of ethernet bugs), it would be worth adding a very detailed issue in github (if you haven’t already done so) which is the official way of reporting bugs, it also means they do not get lost. Post a link here to the github issue to cross reference.

In the meantime, does forcing it to 100bT make the problem go away (yes, I know you want Gig ethernet, this is for testing purposes to narrow down the issue)

You already have a 3B+ with an sd card with this issue in your office. Anyway we can safely assume that every 3B+ has this issue, just the right steps needs to be performed to make it crash.

Steps to reproduce are as follows:

1. Install a fresh image of Raspbian
2. Update firmware
3. Mount a cifs network drive
4. 3B+ is dead overnight when using Ethernet, there are no errors, LAN chip is burning hot

Sadly, i do not have time anymore to invest in this, i literally setup my multiple RPi’s 3B+ in the past months hundreds of times new to help you debug and narrow down the issue, even that i am not responsible to do that…

All the 3B+ problems seems to me like this is a faulty ethernet hardware which you trying to cover with software fixes. If that is really the case then please at least do an official statement about it. I mean come on, it’s been 3 months…

I have already tested that sequence overnight and seen no issues, so No, your assumption that this is a problem with every 3B+ appears to be wrong. So there is probably an extra stage of usage or perhaps something about your particular network router that needs to be determined. For example, what is you network doing overnight? Is it in use? Is a lot of data being transferred? Do you have flow control turned on on your router? What software is running on the Pi that might have some impact?

As I said, 3 months is NOTHING when compared to the complexity of trying to figure out ethernet issues that some people see and others don’t. I’ve personally spent months working on ethernet or wifi issues on the Pi over the last years and a half. And what is annoying NONE of them were Raspberry Pi’s fault – they are either in the firmware of the device or in the driver. Neither of which we have much control over, apart from reporting them to the firmware writers, or mailing the Linux netdev group, or trying to figure them out ourselves.

Semi-Official statement. All software has bugs. All HW has bugs, Usually we can get round HW problems with software. In this case, we do not yet know where the problem arises. We have determined at least one cause so far, the tcp segmentation offloading, which has fixed networking problems for most people. There appears to still be something going on, so we will continue to investigate.

I would prefer the investigation to be done via github, because more engineers see it there.

Heater wrote:

$ vcgencmd get_throttled
throttled=0x50005

Okay, the bits in this number represent:

0: under-voltage
1: arm frequency capped
2: currently throttled 
16: under-voltage has occurred
17: arm frequency capped has occurred
18: throttling has occurred

under-voltage occurs when voltage drops below 4.63V. The Pi is throttled
arm frequency capped occurs with temp > 80’C
over-temperature occurs with temp > 85’C. The Pi is throttled

Throttling removes turbo mode, which reduces core voltage, and sets arm and gpu frequencies to non-turbo value.
Capping just limits the arm frequency (somewhere between 600MHz and 1200MHz) to try to avoid throttling.
If you are throttled and not under-voltage then you can assume over-temperature. (confirm with vcgencmd measure_temp).

So 0x50005 means you are currently under-voltage and throttled.
If you want to be able to support this use case without throttling you will need a better power supply.

Although be aware running a stress test is not typical behaviour. If you never see a non-zero get_throttled value in normal usage, then you may not need to do anything.