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

Since Raspbian Buster kernel in update 2020-02-05, many RPi4 users cannot reboot reliably & other stability issues #1333

Open
carver7 opened this issue Feb 11, 2020 · 29 comments
Labels
Close within 30 days This issue will be closed within 30 days unless further interactions are posted. If you wish this is

Comments

@carver7
Copy link

carver7 commented Feb 11, 2020

Please investigate the growing number of reports written by mostly RPi4 users that relate to a number of consistently reported issues.
Particularly, since Raspbian Buster kernel in updated in release 2020-02-05, variations of reboot commands lead to shutdowns instead.
Instability of RPi4s has been increasing with each incremental update released and this has accelerated since general release 2020-02-05

There are also problems being reported with the simple use of 'sudo' or being logged in as root user for using raspi-config

It appears there are several problems with the 2020-02-05 Raspbian Buster images (and the updates issued just prior to these images).

Until the Raspberry Pi folks sort it all out, the solution is to simply run:
sudo rpi-update 993f475

@carver7 carver7 changed the title Since Raspbian Buster kernel in update 2020-02-05, many RPi4 users cannot reboot reliably Since Raspbian Buster kernel in update 2020-02-05, many RPi4 users cannot reboot reliably & other stability issues Feb 11, 2020
@6by9
Copy link

6by9 commented Feb 11, 2020

The rpi-update was to check if the following one was the issue for raspivid specifically, not a general solution.
Yes, an updated image is being worked on as a priority.

@kosmosgit
Copy link

could be due to gpu_freq => 500, since only 500 MHz are allowed, with the entry hdmi_enable_4kp60 = 1 the frequency is increased to 550 MHz. In the past, 750 MHz was possible, which was also possible without problems with proper cooling.

@popcornmix
Copy link
Contributor

The apt firmware has been updated today. Can you test if it resolves your issues?

@kosmosgit
Copy link

-what exactly should I try?

@kosmosgit
Copy link

great work, runs again with arm_freq = 2147/2294 and also starts with the parameter gpu_freq = 750 MHz.

I will observe the stability over the next few days and give a feedback again.

@akloz
Copy link

akloz commented Feb 13, 2020

Raspivid makes empty files since last apt-get upgrade. What happened?
RPI4 feb

@JamesH65
Copy link
Contributor

This should be fixed in the latest release. When did you last do an apt full-upgrade?

@akloz
Copy link

akloz commented Feb 13, 2020

This should be fixed in the latest release. When did you last do an apt full-upgrade?

In the beginning of February.
with
sudo apt-get upgrade
Shall I use full-upgrade ?

I'll make it this evening. :)

@JamesH65
Copy link
Contributor

sudo apt update
sudo apt full-upgrade. 

@akloz
Copy link

akloz commented Feb 13, 2020

sudo apt update
sudo apt full-upgrade. 

Thank you!

@profi200
Copy link

Can one of the engineers explain what compromise means in f4b5869? Is there now a limit on how high or low it can go or is it just some internal safety for stock clocks?

@pelwell
Copy link
Contributor

pelwell commented Feb 14, 2020

The limit is in the maximum frequency of PLLA, which is now capped at 3GHz (the value used before the recent overclock changes).

@profi200
Copy link

Well, but what does that mean practically?No change to what can be set in config.txt?

@JamesH65
Copy link
Contributor

Raspivid makes empty files since last apt-get upgrade. What happened?
RPI4 feb

Just tried this and raspivid seem to work fine after an apt update/apt full-upgrade - can you make sure you are running the latest stuff please.

@carver7
Copy link
Author

carver7 commented Feb 22, 2020

I've fresh-installed Raspbian Desktop on 2 RPi4's using the Sep 2019 general installer image (not the Feb 2020 installer image) and updated to the present moment (using only the documentation's recommended method of sudo apt update && sudo apt full-upgrade).

I copied the rootfs to a separately powered USB-HDD drive, which is plugged into one of the USB 2.0 ports (haven't tried the USB 3.0 ports) from which I'm booting, with No over_voltage=X added to /boot/config.txt
I did add rootdelay=5 to the /root/cmdline.txt as a precaution (this did not fix the rebooting issues I was experiencing before though), but that's it.

This was done running headless over ssh locally.

I no longer experience any of the issues that I originally inquired about, and the logs displayed by dmesg look normal too.

I haven't tried Raspivid, so I don't know if that is considered resolved or not. But with respect to the issues I raised, these appear to be resolved (at least from my limited n=2 sample size view), so I'm good with the Raspberry Pi team closing this issue whenever it deems it best to do so.

@profi200 do you have an update on Raspivid?

@akloz
Copy link

akloz commented Feb 22, 2020 via email

@profi200
Copy link

@carver7
Sorry, i don't have a camera so can't test that. I was mainly interested in the implications of the compromise for the real archivable overclocking capabilities. Since this issue is closely related i thought i should mention it here instead as a comment under the commit where it gets lost quickly.

@JamesH65
Copy link
Contributor

My thoughts are that this issue has now been fixed, so this issue will be closed within 30 days unless further interactions are posted. If you wish this issue to remain open, please add a comment. A closed issue may be reopened if requested.

@JamesH65 JamesH65 added the Close within 30 days This issue will be closed within 30 days unless further interactions are posted. If you wish this is label Feb 24, 2020
@akloz
Copy link

akloz commented Feb 24, 2020 via email

@akloz
Copy link

akloz commented Mar 6, 2020

Hi!
Here is the failure again.
The same.
Raspivid makes empty files. Size is 29byte.
No preview.

I did nothing before.

Regards,
Zoltan

@magore
Copy link

magore commented Mar 18, 2020

I am having the reboot problem if I have a USB 3.0 hub attached
Linux rpi4-nas2 4.19.97-v7l+ #1294 SMP Thu Jan 30 13:21:14 GMT 2020 armv7l
I was broken in February - fixed - and is now broken again. Same hardware attached as before
My powered USB 3.0 hub has its power to the USB cable disconnected no no back flow is possible
rpi-eeprom-update
BCM2711 detected
BOOTLOADER: up-to-date
CURRENT: Wed Mar 4 14:24:08 UTC 2020 (1583331848)
LATEST: Wed Mar 4 14:24:08 UTC 2020 (1583331848)
FW DIR: /lib/firmware/raspberrypi/bootloader/beta
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 045e:0745 Microsoft Corp. Nano Transceiver v1.0 for Bluetooth
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

A recent update broke reboot with attached USB 3.0 hub - disconnect the hub it works.
FYI - No devices attached to the hub
What caused it to break ? I recently did this:
sudo apt update
sudo apt full-upgrade

Power observations
On reboot the power draw goes down to about 100ma which is very low - normally I see about 600ma

@magore
Copy link

magore commented Mar 22, 2020

Other details
On reboot the red led goes on, green off, hangs forever - no activity current sits at about 100ma

@mitchind
Copy link

I'm seeing previously reported issue with raspivid - but not sure what information you need.
I've updated to latest stable firmware and rpi-eeprom.

RPi4 with 4GB

Using powered USB-3.0 4-port hub (NXT Tech from Staples)
attached to it are a bootable Verbatim USB 256GB 3.0 drive and Coral Edge TPU USB Accelerator
USB 2.0 ports are connected to basic keyboard and mouse
HDMI monitor

If I run command $raspivid -cd MJPEG -w 1920 -h 1080 -fps 30 -o output.mjpg
it creates 29 byte file with many repeated output messages
"mmal: mmal_port_event_send: event lost on port 1,0 (buffer header callback not defined)"

I cannot output to ffmpeg using stdout "-o -" either - same messages and nothing gets sent

Didn't think I'd need the emergency update with latest stable

$ vcgencmd version
Jun 1 2020 13:24:51
Copyright (c) 2012 Broadcom
version 6379679d1ec6a8c746d7e77e015f5b56b939976f (clean) (release) (start_x)

$uname -a
Linux picam 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64 GNU/Linux

$ sudo rpi-eeprom-update
BCM2711 detected
Dedicated VL805 EEPROM detected
BOOTLOADER: up-to-date
CURRENT: Mon 15 Jun 2020 01:36:19 PM UTC (1592228179)
LATEST: Mon 15 Jun 2020 01:36:19 PM UTC (1592228179)
FW DIR: /lib/firmware/raspberrypi/bootloader/stable
VL805: up-to-date
CURRENT: 000137ad
LATEST: 000137ad

@JamesH65
Copy link
Contributor

What happens if you set the output file to be H264 rather than MJPEG?

@6by9
Copy link

6by9 commented Jun 30, 2020

@mitchind

Linux picam 5.4.42-v8+

Please confirm you are using the standard 32bit Raspberry Pi OS. MMAL is not currently supported on the 64bit OS
(It should be working with 64bit kernel and 32bit OS).

@mitchind
Copy link

I'm using Raspbian 64bit OS - does that mean raspivid will not work?

Or can I avoid raspivid and try streaming directly from ffmpeg using H264?

@6by9
Copy link

6by9 commented Jun 30, 2020

I'm using Raspbian 64bit OS - does that mean raspivid will not work?

Correct.
raspberrypi/userland#586 did merge 64bit MMAL support, but there were issues and it was reverted until the cause could be determined. There hasn't been the resource available to do that as yet.

@mitchind
Copy link

Okay thanks.
If it's a 64bit OS issue - I guess I should be watching the OS github issues or forum https://www.raspberrypi.org/forums/viewtopic.php?f=63&t=275372

I'll look at V4L2 in meantime - or are you saying I would need a USB webcam? Pi Camera is out of question for now?

@HunterAP23
Copy link

I see this is marked to be closed soon, but I figured I'd give it a bump with some info I have on these issues.
I've been trying to utilize the HQ Camera module with my Raspberry Pi 4 as a webcam device for my Windows PC. I've been using different projects, but right now the one that's most easily configurable for the 4B is called pi-webcam and has listed the issues faced relating to this one on it's own repo.

The main gist is that attempting to use the HQ camera module in 1080p mode to make the Pi 4B appear as a UVC webcam causes issues described in this issue, such as not being able t shut down the device properly. The other issues also include either not getting any output from the camera module at all, or getting output for a brief period of time (1 to 5 minutes) before the camera output crashes despite the app that is used reporting that everything is fine.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Close within 30 days This issue will be closed within 30 days unless further interactions are posted. If you wish this is
Projects
None yet
Development

No branches or pull requests