Raspberry Pi 3 B+ lockups

[ejolson]

So then the logical next question is, what do we do if we want full usability on our defective Pi? Return it to vendor as defective, paying shipping costs both ways, and hope the new one doesn't have the same issues? Mali it to Pi HQ and they will mail back a known good one? Suffer in silence and be glad that it was only USD$35+tax+shipping?

I bought a new automobile. After driving it for a week I noticed a ripple in the front windshield that caused the view to be distorted. I went to the dealer and checked other cars of the same make and model. The distortion caused by the windshields of the other cars seemed much less. After a month passed, I had more important things to worry about--a broken rearview mirror caused by brushing up against a pole in a parkade. It was a difficult lesson, but I was not sad about the ripple in the window after that.

Maybe I finally learned the lesson how to be happy. When my Pi 3B didn't work reliably at 1200 MHz, I was more amused than sad. I've since been running it crash free at 900 MHz as a DHCP and DNS server. I've also had to under clock CPUs and RAM in many different Intel x86 systems. Stress testing computers is difficult and eventually led to a patent. The important thing is that once things are stable, it finally becomes possible to start doing real work.

[mushu999]

So then the logical next question is, what do we do if we want full usability on our defective Pi? Return it to vendor as defective, paying shipping costs both ways, and hope the new one doesn't have the same issues? Mali it to Pi HQ and they will mail back a known good one? Suffer in silence and be glad that it was only USD$35+tax+shipping?

I bought a new automobile. After driving it for a week I noticed a ripple in the front windshield that caused the view to be distorted. I went to the dealer and checked other cars of the same make and model. The distortion caused by the windshields of the other cars seemed much less. After a month passed, I had more important things to worry about--a broken rearview mirror caused by brushing up against a pole in a parkade. It was a difficult lesson, but I was not sad about the ripple in the window after that.

Maybe I finally learned the lesson how to be happy. When my Pi 3B didn't work reliably at 1200 MHz, I was more amused than sad. I've since been running it crash free at 900 MHz as a DHCP and DNS server. I've also had to under clock CPUs and RAM in many different Intel x86 systems. Stress testing computers is difficult and eventually led to a patent. The important thing is that once things are stable, it finally becomes possible to start doing real work.

While I appreciate that you want to be subtle about your attack on the thoughts stated in my comment, with respect, my statement is absolutely a valid one. Your example is not even close to being the same. You need to change it to this: you were waiting to buy the latest new truck model to haul heavy equipment to and from work, and after you bought it you discovered that only 7 cylinders were firing instead of the 8 you thought you had. So the dealer issued a patch for your engine that adjusted the fuel ratio and timing and allowed it to chug along on those 7 cylinders without dying. Now you didn't get what you thought you were buying, but be happy because, hey, at least it works.

[jamesh]

So then the logical next question is, what do we do if we want full usability on our defective Pi? Return it to vendor as defective, paying shipping costs both ways, and hope the new one doesn't have the same issues? Mali it to Pi HQ and they will mail back a known good one? Suffer in silence and be glad that it was only USD$35+tax+shipping?

/sad

My personal opinion is that if the SW fix doesn't fix the issue, i.e. you are still unable to run stably at 1400Mhz, then I believe you would be entitled to a refund or replacement from the original vendor since the board cannot reach it's claimed clock speed.

[mushu999]

My personal opinion is that if the SW fix doesn't fix the issue, i.e. you are still unable to run stably at 1400Mhz, then I believe you would be entitled to a refund or replacement from the original vendor since the board cannot reach it's claimed clock speed.

Most vendors will need proof that there is a known problem, as stated by the RPi Foundation or similar, so that it can be cited as the cause for a return and/or swap with a newer model.

[baallrog]

I sent a message to the vendor who supplied me the RPI3B+.
He is ok to exchange the RPI.
I bought the RPI the 13th march.

I told him the RPI was defective and sent a link to this forum thread.

I hope I will receive a new one without any problem.

[leon22]

For information only: I exchanged my RPi 3B+ with a new one and voila no more issues!

So I hope the Engineers will find the root cause of the problems!


Greets

[bensimmo]

If these new default sdram/stuff settings are being kept, do you plan on putting the original release settings as an 'overclock' option in raspi-config/desktop config?

There has been some skim reading, so I may have missed something.


(Though I doubt anyone has actually noticed a difference).

[jamesh]

I'm not an expect, but AIUI schmoo isn't the same as overclocking. It's getting the right set pf parameters to make the SD RAM work. Even so, I suspect that the performance difference when changing SDRAM frequency (which is technically an overclock, but not a headline one, since we do not specify a baseline figure for SDRAM frequency) is minor.

[bensimmo]

I'm not an expect, but AIUI schmoo isn't the same as overclocking. It's getting the right set pf parameters to make the SD RAM work. Even so, I suspect that the performance difference when changing SDRAM frequency (which is technically an overclock, but not a headline one, since we do not specify a baseline figure for SDRAM frequency) is minor.

But it must give a fraction more I did notice there was no documented sdram speed.
I class schmoo setting the same as tweaking ras, cas, trp etc on sdram, just a part of overclocking to get it stable or push it a bit faster.

It must be said, I've never bothered with the Pi as the default you allow work fine for me for what I do. (1GHz for Pi1 and Pi2)
Just thinking of the others that may suddenly notice. Not that they will
I did say there was a bit of skim resding

[jahboater]

I'm not an expect, but AIUI schmoo isn't the same as overclocking. It's getting the right set pf parameters to make the SD RAM work. Even so, I suspect that the performance difference when changing SDRAM frequency (which is technically an overclock, but not a headline one, since we do not specify a baseline figure for SDRAM frequency) is minor.

The only thing I would ask is that the user be able to alter the schmoo setting please.
That is, override it if the firmware has set some conservative value to cope with dodgy hardware.
With the sdram freq set to 450Mhz schmoo is off:

Code: Select all

pause_burst_frames=1
program_serial_random=1
sdram_freq=450

I manually set the sdram freq to 500Mhz and get:

Code: Select all

pause_burst_frames=1
program_serial_random=1
sdram_freq=500
sdram_schmoo=0x2000020

Presumably the firmware has detected the higher clock rate and relaxed the timings.
I know my particular Pi is stable at this speed, so I try adding "sdram_schmoo=0x00" to config.txt
and it is ignored - 0x2000020 is still in effect.

So, please could the user be allowed to override any schmoo setting the firmware has added?

I see that if I add a schmoo setting when the sdram clock is 450Mhz it is respected.

[dom]

Presumably the firmware has detected the higher clock rate and relaxed the timings.
I know my particular Pi is stable at this speed, so I try adding "sdram_schmoo=0x00" to config.txt
and it is ignored - 0x2000020 is still in effect.

So, please could the user be allowed to override any schmoo setting the firmware has added?

I see that if I add a schmoo setting when the sdram clock is 450Mhz it is respected.

Any non-zero sdram_schmoo setting will apply. If it is zero and sdram_freq > 450 then you get a different recommended default.
If you really don't want the recommended default then:

Code: Select all

sdram_schmoo=0x8000000

Should behave the same as sdram_schmoo=0 as the top bit of this register has no effect (but stops the register looking like it is default).

But you may need to explain why you don't want the default of 0x2000020 - that has been set automatically for months.
If you believe your settings were stable at sdram_freq=500 then it was almost certainly also with a schoo of 0x2000020.

[jahboater]

But you may need to explain why you don't want the default of 0x2000020 - that has been set automatically for months.
If you believe your settings were stable at sdram_freq=500 then it was almost certainly also with a schoo of 0x2000020.

You are correct of course. 0x2000020 is needed at 500MHz.

All I am hoping for is that if any conservative setting is used to support these faulty boards, please could it be adjusted by users who have tested their memory.

Thanks for the tip!

[wybielacz]

Hi,

the same issue here. My Pi 3 b+ freezes always overnight. At the morning it is always dead and when i touch it then it is hot. I have the latest firmware with "sdram_freq=450".

This is issue is really driving me crazy and i am disappointed, with my old Rpi 3 B i had an up time of over 300 days and with this new Pi i can't even hit 24 hours. WTF?

I thought this might be a power supply error, so i upgraded my power supply to the official Raspberry Pi one but nothing changed so i basically wasted my money!

As a note, before i did the firmware update which changes the sdram_freq to 450 (i suppose based on this thread it was 500 before), the 3 B+ would run sometimes longer then 24 hours without a freeze, right now it is impossible that the pi runs longer then 24 hours, so the latest firmware update just made it worse for me.

Could some summarize this issue to me? What is the exact issue here? CPU or RAM overheating? Is this a software or hardware problem? Or is it even a design flaw of the new Pi?

[dom]

Could some summarize this issue to me? What is the exact issue here? CPU or RAM overheating? Is this a software or hardware problem? Or is it even a design flaw of the new Pi?

This thread is mostly about Pi's that are either unreliable at 500MHz sdram or unreliable at 1400MHz arm frequency.
The issue is complicated by the fact that other software errors (e.g. kernel hangs) may look very similar.

If you are having problems with latest firmware then your issue isn't sdram related. Can you add arm_freq=1200 to config.txt and reboot?
That should help narrow down if the problem is related to the arm frequency.

[wybielacz]

This thread is mostly about Pi's that are either unreliable at 500MHz sdram or unreliable at 1400MHz arm frequency.
The issue is complicated by the fact that other software errors (e.g. kernel hangs) may look very similar.

If you are having problems with latest firmware then your issue isn't sdram related. Can you add arm_freq=1200 to config.txt and reboot?
That should help narrow down if the problem is related to the arm frequency.

I am struggling with this issue since i updated to the new Pi 3 B+ in March and was trying to find a solution to the problem, did change power supply, sd card, reinstalled raspbian many times without any solution. Just today i found this topic...

Fresh install raspbian scratch, nothing installed, just firmware update. Pi always hangs over night, at the morning the cpu heatsink is pretty hot and pi dead. I need to do a hard reboot.

Like i said with 500MHz sdram my Pi was more stable and did survive over night sometimes, after it has been changed to 450 the Pi never survives over night. Not even 24 hours uptime, this is a joke.
I will try today with arm_freq=1200 and see if that works, but anyway this is not an acceptable solution even if that works. You advertise that the Pi 3 B+ runs on 1400MHz so i expect it to run at that speed if not then you basically lie to your customers...

[bensimmo]

At the point it is faulty so you return and replace etc.

What they are trying to do is work out what the faults are and why.

They can change the SDRAM for stability if needed. That is not a specified setup and so can change without notice.

[wybielacz]

This thread is mostly about Pi's that are either unreliable at 500MHz sdram or unreliable at 1400MHz arm frequency.
The issue is complicated by the fact that other software errors (e.g. kernel hangs) may look very similar.

If you are having problems with latest firmware then your issue isn't sdram related. Can you add arm_freq=1200 to config.txt and reboot?
That should help narrow down if the problem is related to the arm frequency.

Unfortunately arm_freq=1200 didn't help, the Pi did loockup overnight again...

[jamesh]

This thread is mostly about Pi's that are either unreliable at 500MHz sdram or unreliable at 1400MHz arm frequency.
The issue is complicated by the fact that other software errors (e.g. kernel hangs) may look very similar.

If you are having problems with latest firmware then your issue isn't sdram related. Can you add arm_freq=1200 to config.txt and reboot?
That should help narrow down if the problem is related to the arm frequency.

Unfortunately arm_freq=1200 didn't help, the Pi did loockup overnight again...

It looks like yours is simply defective (ie probably a SoC that is too far out of spec to work correctly at the required settings). I''d return it for a replacement.

[Nachteule]

This thread is mostly about Pi's that are either unreliable at 500MHz sdram or unreliable at 1400MHz arm frequency.
The issue is complicated by the fact that other software errors (e.g. kernel hangs) may look very similar.

If you are having problems with latest firmware then your issue isn't sdram related. Can you add arm_freq=1200 to config.txt and reboot?
That should help narrow down if the problem is related to the arm frequency.

Unfortunately arm_freq=1200 didn't help, the Pi did loockup overnight again...

It looks like yours is simply defective (ie probably a SoC that is too far out of spec to work correctly at the required settings). I''d return it for a replacement.

Do you really believe that ???

The faulty rate of produced Pi3B+ is extremely high (mine two did not run stable with 500MHz == 100% fault), and it seems that quality control is a foreign word for the manufacturer

[jahboater]

All Pi's are tested to work in the factory, but I guess they cannot run "overnight" tests on every one of 19 million boards.

[wybielacz]

It looks like yours is simply defective (ie probably a SoC that is too far out of spec to work correctly at the required settings). I''d return it for a replacement.

I literally wasted my money on this stuff, i cannot return it for a replacement anymore so the only thing i can do with it, is throw it into trash! And my perfectly working RPi 3B is already sold.....
My home automation and media center should run on this Pi, but because of this issue none of them is usable right now!
I am really disappointed from the RPi 3B+, i never had any issues with my previous RPi's but with this new one my trust is lost...


Seriously, i think that they have some serious quality problems, or they rushed the Pi3B+ so much that they missed a design flaw. Right now they trying to cover this up with a "software fix", but in fact this seems to be a hardware issue...

[gawkmeister]

A few days ago, I reported a problem with ethernet freezes with samba on my Pi 3B+ . Since then I tried switching to the WiFi interface, and while that did not suffer the freeze ups that I experienced on the ethernet interface, I may have run into the problems being discussed in this thread, as the Pi locked up completely after 4 or 5 hours.

Is there any sort of consolidated troubleshooting guide for the 3B+ ? Digging through the forums for random suggestions to try is not a good use of time.

I have a Pi 2 and 2 Pi 3s that have worked flawlessly for me over the past few years. The only thing slightly unusual about my setup is that I have Raspian running from an external USB disk, with only /boot on the SD card. (I had to do this manually, as the current version of NOOBS seems to be using 32 bit arithmetic and refused to run fdisk on a disk of negative size.) Otherwise, this is an out-of-the-box installation from the mid-April NOOBS.

I'm inclined to think this is a faulty board. Time to write it off as a bad buy ?

[wybielacz]

So i did run the cpuburn-a53 test on my raspberry pi 3B+ and the Pi did not crash after 20 minutes. But what i noticed is that the Pi throttles down to around 600-700mHz cpu after a few minutes and temps are around 86 degree. Is this normal with this test? My Pi has no additional cooling.
At least i can say that on my side it is not a thermal problem as it seems, but why does it throttle so much?

[jahboater]

So i did run the cpuburn-a53 test on my raspberry pi 3B+ and the Pi did not crash after 20 minutes. But what i noticed is that the Pi throttles down to around 600-700mHz cpu after a few minutes and temps are around 86 degree. Is this normal with this test? My Pi has no additional cooling.
At least i can say that on my side it is not a thermal problem as it seems, but why does it throttle so much?

No, my Pi3B+ stays above the milli-hertz range

Mine is not in a case, is mounted on edge, and has simple passive cooling.
After a few minutes it throttles back to 1.2Ghz (at 70C) then eventually when it reaches 80C, down another 100Mhz or so.
I have never seen it drop below1GHz ever, even after a hour. Impressive.
(except when idle of course).

[wybielacz]

No, my Pi3B+ stays above the milli-hertz range

Mine is not in a case, is mounted on edge, and has simple passive cooling.
After a few minutes it throttles back to 1.2Ghz (at 70C) then eventually when it reaches 80C, down another 100Mhz or so.
I have never seen it drop below1GHz ever, even after a hour. Impressive.
(except when idle of course).

You sure this is the cpuburn-a53 and not the normal stress test with the stress package? I am getting around the same values with the stress test from the stress package.