KMS: 4096x2160p60 causes hang/unresponsive pi unless overclocked #5034
Labels
KMS Issue
Issues related to KMS/DRM drivers
Comments
|
I think it will require core_freq=600 because overclocking is required for this to work. Although, maybe you'll be able to remove core_freq_min |
|
@alanbork can you post edid? e.g. Pretty sure 4096x2160p60 works on my monitor. I suspect timing differences (e.g. more blanking) may result in a higher core clock requirement. |
|
/root #cat /boot/.firmware_revision /root #base64 /sys/devices/platform/gpu/drm/card1/card1-HDMI-A-1/edid and though you didn't ask for it: |
|
Has this mode ever worked for you, with either fkms or kms (without the core_freq overclock)? |
|
this mode ***@***.***) always works with overclocking, since firmwares
released at least a year ago. It's never worked without it - it's always an
instant fail under kms. I vaguely think it used to work under fkms with a
much older firmware without overclocking but honestly it's been a while
since I ran fkms at 4k and when I just tested it recently fkms also
required overclocking. BTW FKMS has some serious regressions these days,
even low demanding modes sometimes don't work (480i) for instance.
…On Mon, May 16, 2022 at 10:51 AM popcornmix ***@***.***> wrote:
Has this mode ever worked for you, with either fkms or kms (without the
core_freq overclock)?
Without the core_freq overclock, does modetest always fail when switching
to ***@***.***, or is that mode sometimes work for a while?
Does force_turbo=1 work as an alternative to core_freq=600? (i.e. always
forcing 550MHz).
—
Reply to this email directly, view it on GitHub
<#5034 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANPGZ5PAZ4X7N5XBVXCKARLVKKDJDANCNFSM5V72S6XA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
|
force_turbo=1 results in a fail for kms at ***@***.***
edit: stupid github thinks that's an email address
4096 wide at 60hz
…On Mon, May 16, 2022 at 11:00 AM AR ***@***.***> wrote:
this mode ***@***.***) always works with overclocking, since firmwares
released at least a year ago. It's never worked without it - it's always an
instant fail under kms. I vaguely think it used to work under fkms with a
much older firmware without overclocking but honestly it's been a while
since I ran fkms at 4k and when I just tested it recently fkms also
required overclocking. BTW FKMS has some serious regressions these days,
even low demanding modes sometimes don't work (480i) for instance.
On Mon, May 16, 2022 at 10:51 AM popcornmix ***@***.***>
wrote:
> Has this mode ever worked for you, with either fkms or kms (without the
> core_freq overclock)?
> Without the core_freq overclock, does modetest always fail when switching
> to ***@***.***, or is that mode sometimes work for a while?
> Does force_turbo=1 work as an alternative to core_freq=600? (i.e. always
> forcing 550MHz).
>
> —
> Reply to this email directly, view it on GitHub
> <#5034 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ANPGZ5PAZ4X7N5XBVXCKARLVKKDJDANCNFSM5V72S6XA>
> .
> You are receiving this because you were mentioned.Message ID:
> ***@***.***>
>
|
|
To be more clear:
full config.txt that fails:
#following lines set up kms and required overclocking
dtoverlay=vc4-kms-v3d
#core_freq=600
#core_freq_min=600
force_turbo=1
if I swap which overclocking lines are commented out it works fine.
…On Mon, May 16, 2022 at 11:16 AM AR ***@***.***> wrote:
force_turbo=1 results in a fail for kms at ***@***.***
On Mon, May 16, 2022 at 11:00 AM AR ***@***.***> wrote:
> this mode ***@***.***) always works with overclocking, since
> firmwares released at least a year ago. It's never worked without it - it's
> always an instant fail under kms. I vaguely think it used to work under
> fkms with a much older firmware without overclocking but honestly it's been
> a while since I ran fkms at 4k and when I just tested it recently fkms also
> required overclocking. BTW FKMS has some serious regressions these days,
> even low demanding modes sometimes don't work (480i) for instance.
>
>
> On Mon, May 16, 2022 at 10:51 AM popcornmix ***@***.***>
> wrote:
>
>> Has this mode ever worked for you, with either fkms or kms (without the
>> core_freq overclock)?
>> Without the core_freq overclock, does modetest always fail when
>> switching to ***@***.***, or is that mode sometimes work for a while?
>> Does force_turbo=1 work as an alternative to core_freq=600? (i.e. always
>> forcing 550MHz).
>>
>> —
>> Reply to this email directly, view it on GitHub
>> <#5034 (comment)>,
>> or unsubscribe
>> <https://github.com/notifications/unsubscribe-auth/ANPGZ5PAZ4X7N5XBVXCKARLVKKDJDANCNFSM5V72S6XA>
>> .
>> You are receiving this because you were mentioned.Message ID:
>> ***@***.***>
>>
>
|
Just to confirm it results in a I'm running with your edid. It doesn't produce a picture on my dell monitor for 4096x2160@60, but does for other modes. which produces the flip timeout when run with: but for me, adding either
You didn't list hdmi_enable_4kp60=1. I assume you do have that? |
|
Yes, this message: yes, hdmi_enable_4kp60=1 |
|
I'll leave my script running overnight. But I don't seem to be getting the same behaviour as you (which I feel I should when using your edid). I'm on RPiOS bullseye, with boot to console enabled. I have your edid
I note you posted modetest with: Was this straight from boot. I boot up with: After |
|
Does |
popcornmix
added a commit
to popcornmix/linux
that referenced
this issue
May 17, 2022
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
to popcornmix/linux
that referenced
this issue
May 17, 2022
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Would this info still be useful in light of the draft commit that came after? I'm happy to do the testing if it's still useful. |
|
Yes, both these tests are still useful. It's not clear whether 4096x2160@50 suffers from the same issue as there are fewer pixels per second to handle. Although it does use same pixel clocks rate, with larger horizontal blanking, so it may not be easier. I suspect you need |
|
Just in case I grabbed the latest rpi-update: /root #cat /boot/.firmware_revision holding these lines of config.txt constant for all tests: max_framebuffers=1 then setting these: dtoverlay=vc4-kms-v3d these modes work fine: then turning all overclocking off: 4096x2160p50 works fine by fail I mean TV detects no signal + dmesg says [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] ERROR [CRTC:94:crtc-3] flip_done timed out then with these lines: 4096x2160p50 fine You also asked about vcgencmd measure_clock core not sure which configuration you wanted that run under, but here's the output with just core_freq=600 frequency(1)=533329088 a bit different from yours... testing with : 4096x2160p50 is fine Did I miss any combo's? |
popcornmix
added a commit
to popcornmix/linux
that referenced
this issue
May 26, 2022
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
pelwell
pushed a commit
that referenced
this issue
May 26, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
pelwell
pushed a commit
that referenced
this issue
May 26, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
pelwell
pushed a commit
that referenced
this issue
May 26, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
|
@alanbork does latest rpi-update kernel behave okay? |
|
Still not back to be able to test but will be able to by Friday.
…On Mon, May 30, 2022, 10:10 AM popcornmix ***@***.***> wrote:
@alanbork <https://github.com/alanbork> does latest rpi-update kernel
behave okay?
i.e. only allow ***@***.*** when it will work?
—
Reply to this email directly, view it on GitHub
<#5034 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ANPGZ5MWI3XHSGIY54E7Q6DVMTZAJANCNFSM5V72S6XA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
popcornmix
added a commit
that referenced
this issue
Jun 1, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
pelwell
pushed a commit
that referenced
this issue
Jun 3, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Jun 6, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Jun 6, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Jun 6, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
Yes, after updating via rpi-update today. When 4096x2160p appears as an available mode it now works. And it only appears when config.txt includes both overclocking commands: core_freq=600 NOTE: in my testing previously I didn't need both, just the 2nd one (see above but quoting here) I'm rather unclear on what the implications of both are vs just one, and if there's a reason to include both or not (there wasn't on my particular board, at the least). BUT bettter to have it not hang on 100% of boards than fail on 1% since the failure is hard to recover from. |
herrnst
pushed a commit
to herrnst/linux-raspberrypi
that referenced
this issue
Oct 12, 2022
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 17, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 17, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
herrnst
pushed a commit
to herrnst/linux-raspberrypi
that referenced
this issue
Oct 17, 2022
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
mj22226
pushed a commit
to mj22226/linux
that referenced
this issue
Oct 18, 2022
These are no reliable without overclocking. See: raspberrypi/linux#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 19, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 20, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 21, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 24, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 25, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 26, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 31, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Oct 31, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Nov 6, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Nov 7, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Nov 12, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Nov 18, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
herrnst
pushed a commit
to herrnst/linux-raspberrypi
that referenced
this issue
Nov 26, 2022
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Nov 29, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
herrnst
pushed a commit
to herrnst/linux-raspberrypi
that referenced
this issue
Dec 3, 2022
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Dec 6, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Dec 8, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Dec 14, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Dec 19, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Dec 21, 2022
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
herrnst
pushed a commit
to herrnst/linux-raspberrypi
that referenced
this issue
Jan 2, 2023
These are no reliable without overclocking. See: raspberrypi#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Jan 3, 2023
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Jan 5, 2023
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
popcornmix
added a commit
that referenced
this issue
Jan 12, 2023
These are no reliable without overclocking. See: #5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com>
lsahn-gh
pushed a commit
to lsahn-org/ubuntu-raspi
that referenced
this issue
Jan 13, 2023
BugLink: https://bugs.launchpad.net/bugs/1982090 These are no reliable without overclocking. See: raspberrypi/linux#5034 Signed-off-by: Dom Cobley <popcornmix@gmail.com> (cherry picked from commit 2ade4a966fccc7f95436c3e1d7b8d0cf55eb384f rpi-5.19.y) Signed-off-by: Juerg Haefliger <juerg.haefliger@canonical.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
as of 1c56b3a58974f725e1ac63214eeaf914c5908302, I still get hangs/blank screens if I try to use 4096x2160p60 unless I overclock the cpu via config.txt (core_freq=600 core_freq_min=600)
dmesg reports:
vc4-drm gpu: [drm] ERROR Timed out waiting for commit
[ 273.107442] [drm:drm_atomic_helper_wait_for_flip_done [drm_kms_helper]] ERROR [CRTC:94:crtc-3] flip_done timed out
If I understand correctly this should be fixed by #4940.
Steps to reproduce the behaviour
reproducible using kms and modetest at the console (no x). Have not tried X but I see no reason to think it will do better.
Device (s)
Raspberry Pi 4 Mod. B
System
System updated using rpi-update to 1c56b3a58974f725e1ac63214eeaf914c5908302
Logs
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: