Bug 2512496
| Summary: | vc4: WARNING in __vc4_hvs_stop_channel when kwin_wayland performs atomic modesetting on Raspberry Pi 4 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Jaroslav Groman <jgroman> | ||||||
| Component: | kernel | Assignee: | Justin M. Forbes <jforbes> | ||||||
| Status: | NEW --- | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 45 | CC: | acaringi, adscvr, airlied, hans, hpa, jforbes, kernel-maint, linville, masami256, mchehab, nickolasjcarr, pbrobinson, ptalbert, steved, suraj.ghimire7 | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | aarch64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | --- | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | Type: | --- | |||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Attachments: |
|
||||||||
|
Description
Jaroslav Groman
2026-08-07 13:01:04 UTC
Created attachment 2153914 [details]
KDE boot log with added kernel option swiotlb=131072 to avoid another issue
> When KDE Plasma Wayland (kwin_wayland) starts on a Raspberry Pi 4, the vc4 > DRM driver produces a kernel WARNING at drivers/gpu/drm/vc4/vc4_hvs.c:744 in This is a warn once so it's not fatal. Does KDE continue to run as expected or does kwin crash (or something)? > __vc4_hvs_stop_channel(). The HVS hardware fails to acknowledge a channel > stop request within the expected timeout during an atomic modesetting commit. This stop channel is for shutting down/disconnecting an interface, it feels strange that kwin would be doing this on startup. > GNOME (mutter) on the same hardware with the same kernel does not trigger > this warning. On wayland the compositor drives the HW more directly, we've seen a few bugs on KDE vs GNOME where the desktops do things slightly differently so I'm not particularly surprised. > HDMI device connected is a generic HDMI frame grabber at 1920x1080 > resolution. How well does that respond to generic screen off style events generally? I think I might have a generic one of those somewhere I'll see if I can find it. > Not sure, will investigate Maybe even just a F-44 GA image would be a useful test point. > 3. kwin_wayland starts and performs initial display configuration via DRM > atomic modesetting What do you mean by that? (In reply to Peter Robinson from comment #2) > > When KDE Plasma Wayland (kwin_wayland) starts on a Raspberry Pi 4, the vc4 > > DRM driver produces a kernel WARNING at drivers/gpu/drm/vc4/vc4_hvs.c:744 in > > This is a warn once so it's not fatal. > > Does KDE continue to run as expected or does kwin crash (or something)? Yes, that is correct, it is just a momentary glitch (blank screen) during desktop load. After that GUI seems to behave correctly. > > > __vc4_hvs_stop_channel(). The HVS hardware fails to acknowledge a channel > > stop request within the expected timeout during an atomic modesetting commit. > > This stop channel is for shutting down/disconnecting an interface, it feels > strange that kwin would be doing this on startup. I have no idea about that. Maybe this is related to display enumeration? > > > GNOME (mutter) on the same hardware with the same kernel does not trigger > > this warning. > > On wayland the compositor drives the HW more directly, we've seen a few bugs > on KDE vs GNOME where the desktops do things slightly differently so I'm not > particularly surprised. > > > HDMI device connected is a generic HDMI frame grabber at 1920x1080 > > resolution. > > How well does that respond to generic screen off style events generally? I > think I might have a generic one of those somewhere I'll see if I can find > it. My device is marked as PremiumCord KU2GRAB4, USB reports: 345f:2130 MACROSILICON USB3.0 UHD I'll test with standard HDMI display as well. > > > Not sure, will investigate > > Maybe even just a F-44 GA image would be a useful test point. Tested with current Fedora-KDE-Desktop-Disk-44-1.7.aarch64.raw.xz (kernel 6.19.10-300.fc44, mesa 26.0.3) RPI4 was barely usable, very slow and unresposive/hanging. This is strange as I tested pre-release KDE images and did not notice any such behaviour. I retrieved boot log from the SD card and the vc4 HVS warning is there as well, along with swioltb buffer exhaustion. Attaching the boot log. > > > 3. kwin_wayland starts and performs initial display configuration via DRM > > atomic modesetting > > What do you mean by that? It is just that desktop starts, background is displayed, then video temporarily blanks out and after that displays again. The "DRM atomic modesetting" part was suggested by Claude. Not sure how correct / relevant is that. Created attachment 2153935 [details]
Fedora-KDE-Desktop-Disk-44-1.7.aarch64.raw.xz boot log
> > > 3. kwin_wayland starts and performs initial display configuration via DRM
> > > atomic modesetting
> >
> > What do you mean by that?
>
> It is just that desktop starts, background is displayed, then video
> temporarily blanks out and after that displays again.
> The "DRM atomic modesetting" part was suggested by Claude. Not sure how
> correct / relevant is that.
AFAICT it seems Kwin randomly just goes and probes all outputs it can find, then KWin's DRM backend explicitly disables any CRTC that aren't cleanly assigned to a working output as part of normal output (re)configuration. This it seems it why it turns things off and something in the vc4 isn't in the right state so we get the warn once output.
I'm going to report it upstream but it doesn't appear critical.
|