4k60p display issue (DRM VC4 driver crash / backtrace) #3842
Comments
|
did this ever get fixed? |
|
Hi, [165973.223398] WARNING: CPU: 0 PID: 1075 at drivers/firmware/raspberrypi.c:64 rpi_firmware_transaction+0xec/0x128 I have no c;lue how to fix this. And it happens each time I run a video on Youtube. Very weird |
|
Hi, I have a similar issue, reproduced on both compute module 3 and 3+. It's for a custom DSI panel with 4 lanes, kms vc4: The panel worked with older kernel versions, for example with 4.19.127-v7+ kernel that comes from a Raspbian Lite image from May 2020, but with the kernel 5.4,83-v7+ that comes with the RaspberryOS image from January 2021, it does not work anymore. Looks like the panel device driver is probed, prepared and enabled ok, then the problem appears. The screen stays blank and eventually the panel driver is disabled. This also might be relevant: Probably it's originating from: from |
|
I have more info on this: after changing the driver code for 5.10.y (there are some changes in there that prevented compiling it), it seems to work, so probably along the way the DSI vc4 implementation was broken and in 5.10.y is fixed. |
|
Any discussion of DSI displays on CM3 is going a long way off topic for a thread on 4k60 on Pi4. If you are wishing to use vc4-kms-v3d then I strongly recommend you use the rpi-5.10.y branch. The backtrace from rpi_firmware_transaction is just that the firmware hasn't replied within a timeout period, typically because something else has managed to crash it. The callstack is generally meaningless. I haven't checked 4k60 myself recently, but it was working. There were a large number of tweaks to get the HDMI state machine stable, and AFAIK it is in the most recent releases. |
|
By release do you mean the official image downloadable from the website , or a testing version via rpi-update? I have a copy downloaded in November that's having issues with 4k60, and I'm wondering if I need a new install from scratch, or should try rpi-update. |
|
anybody found a solution to this? I've personally found that 3840x2160-60 works but have yet to get 4096x2160-60 to ever show a picture using the pi4, across several different cables, pi4s, and monitors/tvs. The pi tries to display it, meaning that all the config.txt settings are probably right, but the displays don't like the signal. |
|
I'd need to check the actual register sizes. 4k60 support is nearly resolved for vc4-kms-v3d. Please could you dump the EDID so that I can see what configuration we end up with, even if I can't see the results. Github should take zipped attachments, or base64 encode it. |
|
I think that question is meant for me? I dumped both edid's for a separate bug report I posted (hard crash/lockup on recent firmware for 4096x2160): #4271. Sorry if that's a duplicate; though it's not obviously so: The original poster's backtrace shows he was trying 3840x and failing, so he should definitely try the newest firmware to see if it works for him. |
Yes please. Accessible as (normally) /sys/class/drm/card1-HDMI-A-1/edid or /sys/class/drm/card1-HDMI-A-2/edid |
|
tvservice dumped edids 4k tvs.zip I already have these archives if that will work for you. if it has to be from the /sys path that will take a little longer. |
|
Running those through edid-decode, VIC 102: 4096x2160 60.000 Hz 256:135 67.500 kHz 297.000 MHz 4096x2160 @ 24Hz should work and would be a useful test to confirm the width/height registers are programmed correctly. The TCL EDID appears to say the same. The DRM driver should have filtered out all 4:2:0 modes because it knows they aren't supported by the hardware, so have you been manually selecting them? You can add |
|
what do you mean by manually selecting them? I didn't add something to config.txt if that's what you mean? I used stock modetest from the drm/freedesktop project. |
|
OK, I'll artificially load your EDID and see what the parsing is doing. Something odd is happening if it does allow it, as the driver does NOT set |
|
ok, turns out that the tv has a per-port setting for what edid to send, and I had not enabled hdmi 2.0 on that port. my bad. that's why my previous report and current report do not line up. |
|
edid after enabling hdmi 2, etc on the port the pi is plugged into. |
|
having fixed that we are back to where I was before: root@raspberrypi:~# modetest | grep '#' modetest -s 89:3840x2160-60 WORKS |
|
I'll look at your updated EDID in a mo, but modetest with the old EDID reports modes as 4096x2160 @ 60 is not one of those modes |
yes, that's what I see too, before enabling hdmi 2.0. very sorry about that mistake. but after enabling it and rebooting the pi 4096x2160 @ 60 is back in the list. |
|
after adding the drm flag to cmdline, "modetest -s 89:4096x2160-60" gives: trying to open device 'vc4'...done dmesg says (but only after modetest is locked up for at least a minute): [ 204.633524] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] ERROR [CRTC:87:crtc-0] flip_done timed out |
|
The HDMI2 analyser has decided to work again, so I do have a test system :-) Using your EDID, selecting 4096x2160@50 via modetest works. @60 doesn't by default. to /boot/config.txt and selecting 4096x2160@60 works. So it looks to be an issue of the clock being slightly too low to be able to clock through the extra pixels of 4096 vs 3840. @timg236 @popcornmix Is it worth looking again at the clock config, or do we just document that 4096x2160@60 needs an overclock? |
|
What clock config do you think could help? Does kms behave any differently? (with the 4kp60 patchset) It may just be that the extra pixels from the 4096 width are too much for 550MHz core/hvs clock. |
|
I haven't tested further. I'll try full KMS with the 4k60 patches in a bit, but I suspect they'll be the same. 4096 is 6.7% more than 3840, so plausibly 586MHz. I don't recall what the clocking arrangement is now and therefore what clock frequencies are possible. If we can determine the required conditions, then yes we can filter them out with an appropriate warning message. We already query the firmware with RPI_FIRMWARE_GET_DISPLAY_CFG to get the max pixel clock (ie whether hdmi_enable_4k60=1), so that can gain core_clock_freq checks too. |
Latest firmware sets PLLA to an integer multiple of the max of core,v3d,isp,h264,hevc. So you can specify arbitrary values, i.e. core_clock=586 will get you an accurate core clock (but you may effectively be also overclocking v3d,isp,h264,hevc). If you don't specify over_voltage yourself you will get a default one based on the increase in clocks over default. |
|
Overclocking fixes the lockup - 4096x2160-60 is displayed correctly, with no tearing. It's not a perfect solution, however, as 3840x2160-60, which was working perfectly, now has tearing. well, tearing isn't exactly the right word - it's like a fragment of the most recently flipped buffer is shown 2 frames early. see video: https://www.youtube.com/watch?v=3nhIT1MwPKg. use 25% speed to get to the "good part", and then , and . to step frame by frame. what's happening: after swapbuffer gets called a small triangular segment of the back buffer shows up on screen immediately. because of double buffering, that full frame that the fragment came from will show up as expected after 2 more refresh cycles. the fragment is an odd triangular cutout:
|
|
FKMS has issues with vsync synchronisation. It's not going to be fixed as vc4-kms-v3d is the better solution. 4k60 support there should be merged within a week or two - it is all working now. Altering the core clock has shifted the timing of V3D completing vs display being rendered. |
|
any chance of getting early access to that kms-v3d binary blob? with my lag
testing setup I could do some verification that the timing is
working properly.
…On Fri, Apr 16, 2021 at 10:10 AM 6by9 ***@***.***> wrote:
FKMS has issues with vsync synchronisation. It's not going to be fixed as
vc4-kms-v3d is the better solution. 4k60 support there should be merged
within a week or two - it is all working now.
Altering the core clock has shifted the timing of V3D completing vs
display being rendered.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3842 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANPGZ5MF2FEWWMWCNDVZCSDTJBVOZANCNFSM4RAJL62Q>
.
|
|
Or more technically that's a backport of the upstream commits |
|
I have under x86, but it's a bit beyond my enthusiasm to help out to set it
up for the pi. I was hoping more for a binary file or two I could copy to
/boot or whatever. But if that's too much trouble I understand.
…On Fri, Apr 16, 2021 at 10:28 AM popcornmix ***@***.***> wrote:
Can you build your own kernel? It's described here
<https://www.raspberrypi.org/documentation/linux/kernel/building.md>
You'd want to build with this PR included:
#4284 <#4284>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#3842 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANPGZ5KMKCEMPFRHEUDAGM3TJBXSRANCNFSM4RAJL62Q>
.
|
|
You can wait. I expect it will be merged (and hence appear in rpi-update kernel) in the next week or so. |
|
We got a lot of fixes that might fix the issue reported here, can you test if it's still there with an updated kernel? Thanks! |
I'm running into an issue trying to get 4K60p output from my RPi4 to my Acer Nitro XV273K monitor. I thought this might have been the typical EDID issue that many people have run into trying to get 4K60p to work, but this appears to be more of a corner case that involves a bug in the DRM VC4 driver causing it to get stuck in a loop and eventually crash an/or restart.
The specific symptom in this case is that when I set "hdmi_enable_4kp60=1" in config.txt and reboot, the display will show the initial boot screen with the 4 raspberry pi logos and boot logs, but as soon as the VC4 driver takes over, the display goes blank and stays blank. I did eventually discover that If I wait for 8 or 9 minutes, the display does in fact come back on and show the RPi OS desktop at 4k60p. This behavior is consistent and repeatable.
Hardware list:
OS:
Steps:
Analysis:
I spent most of the day yesterday trying to debug this issue. My initial thought was that this was an EDID parsing / matching issue, but after some investigation I determined that wasn't the case and that the VC4 DRM driver is selecting the appropriate modeline. After enabling the DRM debug logs in the kernel via the "drm.debug=0x14" kernel command line flag, I could see that the DRM driver is getting stuck in a loop with the following error logs popping out 30 seconds or so:
This goes on for several minutes until the VC4 DRM driver apparently crashes or restarts just past the 7 minute mark. The following backtrace is dumped at this point:
Immediately after this backtrace is dumped, the VC4 DRM driver seems to correct itself and successfully brings up the desktop at 4k60p.
I've reached the limit of my ability to debug this issue, so I need some guidance from the RPi experts...
Thanks!
-Robert Hildinger
The text was updated successfully, but these errors were encountered: