Open carver7 opened 4 years ago
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.
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.
The apt firmware has been updated today. Can you test if it resolves your issues?
-what exactly should I try?
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.
Raspivid makes empty files since last apt-get upgrade. What happened? RPI4 feb
This should be fixed in the latest release. When did you last do an apt full-upgrade?
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. :)
sudo apt update
sudo apt full-upgrade.
sudo apt update sudo apt full-upgrade.
Thank you!
Can one of the engineers explain what compromise means in f4b58692fef0b9c16bd4564edb980fff73a758b3? Is there now a limit on how high or low it can go or is it just some internal safety for stock clocks?
The limit is in the maximum frequency of PLLA, which is now capped at 3GHz (the value used before the recent overclock changes).
Well, but what does that mean practically?No change to what can be set in config.txt?
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.
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?
Raspivid works allready. Thanks.
carver7 notifications@github.com ezt írta (időpont: 2020. febr. 22., Szo 3:31):
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 https://github.com/profi200 do you have an update on Raspivid?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1333?email_source=notifications&email_token=AD4UT6XV5NXVI4HXXNNUL7DRECFBDA5CNFSM4KSXX6Q2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMUUS4I#issuecomment-589908337, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4UT6S2RGBN6SGNKJUK7WTRECFBDANCNFSM4KSXX6QQ .
@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.
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.
My raspivid works now. Thanks! Regards Zoltan
James Hughes notifications@github.com ezt írta (időpont: 2020. febr. 24., H, 16:36):
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.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/raspberrypi/firmware/issues/1333?email_source=notifications&email_token=AD4UT6S4OFZM4MUP6RVLDOLREPSQPA5CNFSM4KSXX6Q2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEMYJZAA#issuecomment-590388352, or unsubscribe https://github.com/notifications/unsubscribe-auth/AD4UT6QW6LENWFM4PGPBMS3REPSQPANCNFSM4KSXX6QQ .
Hi! Here is the failure again. The same. Raspivid makes empty files. Size is 29byte. No preview.
I did nothing before.
Regards, Zoltan
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
Other details On reboot the red led goes on, green off, hangs forever - no activity current sits at about 100ma
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
What happens if you set the output file to be H264 rather than MJPEG?
@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).
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?
I'm using Raspbian 64bit OS - does that mean raspivid will not work?
Correct. https://github.com/raspberrypi/userland/pull/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.
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?
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.
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
Problem 7 led act raspberry pi4 with sudo reboot
RPi4 shutdown -r not restarting up
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=196778&p=1609435#p1609681
From https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=196778&p=1609435#p1609681 :
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