Bugzilla – Bug 1186896
AMD Ryzen 7 4700H Renoir: brightness + ext screen don't work
Last modified: 2021-07-08 08:47:26 UTC
** Platform Info ** Distribution: Leap 15.2 Kernel: 5.3.18-lp152.75-default CPU: Rhyzen 7 4700U Graphics: # lspci -nnk | grep -A3 VGA 05:00.0 VGA compatible controller [0300]: Advanced Micro Devices, Inc. [AMD/ATI] Renoir [1002:1636] (rev c2) Subsystem: CLEVO/KAPOK Computer Device [1558:a500] Symptom: Changing the brightness of the laptop screen doesn't work. Turning the scroll wheel over de battery icon in the system tray does't do anything. No change in brightness. But I do get the mmediate and unexplainable popup of the external monitor widget (see attachment). Peculiarly, the settings are correctly registered. Before: rietgors:/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.0/backlight/acpi_video0 # cat actual_brightness max_brightness 21 49 After: rietgors:/sys/devices/pci0000:00/0000:00:08.1/0000:05:00.0/backlight/acpi_video0 # cat actual_brightness max_brightness 36 49 Exactly the same happens when I directly echo values in the "brightness" device from the command line. No change in brightness and immediate popup of the external monitor widget. Some information you might find useful: xlgears: Accellaratioin seems to work normally. xlgears gives me > 3200 fps. xgamma: value changes are properly registered: koos@rietgors:~> xgamma -rgamma 0.2 -ggamma 0.4 -bgamma 0.6 -> Red 1.000, Green 1.000, Blue 1.000 <- Red 0.200, Green 0.400, Blue 0.600 However no change in color whatsoever. xbacklight: Doesn't work. koos@rietgors:~> xbacklight -get No outputs have backlight property Next to the default Leap 15.2 kernel, I've tried the following kernels: - kernel-default-5.13.rc3/rc4 from KOTD - kernel-default-5.12.9 from the Kernel Stable repo However those kernels don't work at all. They hang hard during the boot process. If I select the Fail Safe option from the boot menu, they both hang at the following location in the boot screen (typed over from photo, see attachment): [drm] amdgpu kernel modesetting enabled. Virtual CRAT table created for CPU amdgpu: Topology: Add CPU node fb0: switching to amdgpudrmfb from EFI VGA
Created attachment 849951 [details] Boot log alternative kernels
Created attachment 849952 [details] External screen widget
Additional remark: I can't use an external screen on the HDMI port.
Another remark: I've also tried the latest Leap 15.3 Live CD version, which is just out. That didn't work either. Same symptoms as my current 15.2.
The support of the recent AMDGPU stuff on Leap 15.2 kernel is fairly bad, and it's unlikely that the fix will be taken for Leap 15.2 unless it's a trivial fix. So, let's concentrate on Leap 15.3. Does Leap 15.3 kernel (with the update of kernel-firmware-amdgpu package) give the same hang up at boot? Or it's only about the brightness? The brightness issue could be worked around by passing amdgpu.backlight=0 option (or 1) on the recent kernels. For the Leap 15.3, you may try the kernel in OBS Kernel:SLE15-SP3, too, http://download.opensuse.org/repositories/Kernel:/SLE15-SP3/standard/
Can I use the Kernel:SLE15-SP3 kernel on Leap 15.2, if only to check this bug?
Yes, the kernel itself should be usable on Leap 15.2 system, too. (No Secure Boot, though). And, you'd need to upgrade the kernel-firmware-amdgpu as well.
I've installed the SLE15-SP3 kernel as you've suggested. I've installed the amdgpu firmware from https://software.opensuse.org/package/kernel-firmware-amdgpu (I took the 15.2 build from Sauerland, as that was available. Hope that was the right choice). That did not help. Hard hang during the boot process at the same location: > switching to amdgpudrmfb from EFI VGA If there's anything I can do to help debug this, please let me know. If upgrading right now to Leap 15.3 is the next step, that's also ok (although if available I'd prefer alternative research options first. It's my production laptop. And I'm not eager to upgrading to a release which is just out).
OK, then it's likely some breakage in the recent upstream kernel. At first, make sure that the boot succeeds with nomodeset option for those new ones. If it works, the boot hang must be from amdgpu graphics. You can find old kernel packages in my OBS repos, e.g. OBS home:tiwai:kernel:5.4 contains the last 5.4.x TW kernel (equivalently), home:tiwai:kernel:5.5 for 5.5.x, etc. It'd be helpful if you can narrow down which kernel starts showing the hang at boot by testing those kernels.
I think I've found your OBS repos for 5.4.14 and 5.5.13. Both kernels boot fine with the nomodeset option. The 5.4.14 boots fine without the nomodeset option. The 5.5.13 does not boot without the nomodeset option. Hope this helps!
With the information from comment 10, would it be useful to progress this bug via the amdgpu module? Is there anything else I could try? My apologies for the impatience. My brand new laptop is hardly usable as I can only use it properly at night in low light conditions.
Did you already try amdgpu.backlight=0 boot option as mentioned in bug 1180749?
Thank you so much for getting back to me on this. Yes, all my trials were using "amdgpu.backlight=0" In fact I added it to the GRUB_CMDLINE_LINUX_DEFAULT variable in /etc/default/grub to ensure I didn't skip it. /proc/cmdline confirms it's being used.
Hm, I'm confused. Now you're using which OS and which setup? Is it about Leap 15.3 kernel + user-land, or still Leap 15.2, or about TW? And is the main problem you're talking about is the brightness, and that's with amdgpu (i.e. without nomodeset), right?
> Hm, I'm confused. Now you're using which OS and which setup? Leap 15.2 > Is it about Leap 15.3 kernel + user-land, or still Leap 15.2, or about TW? Still Leap 15.2. (I don't know what user-land means) > And is the main problem you're talking about is the brightness, and that's with amdgpu (i.e. without nomodeset), right? Correct. Just to remove the confusion about 15.2 vs 15.3, I've just wiped my Leap 15.2 to install Leap 15.3. That should get me aligned with your baseline. And my current 15.2 setup it not very usable anyway. Unfortunately, the ISO boot image hangs when starting udev (see attachment: leap15.3_hangs_at_udev.jpg) After reading up on the boot params, I was able to boot from the Leap 15.3 stick using "acpi=off". I've tried many boot params, and this one was the only one I could boot with. The installation went ok. This comment is just written with the new Leap 15.3 Good news: Brightness and external screen work. So that's very nice. Bad news: without ACPI I have a single core, no Fn keys and no touchpad and probably more goodies. So it's still bad I suppose. But it does lead to the question if we should maintain this bug as is. Please provide direction. I'm now planning to wipe 15.3 again, repartition my drive and go for a multiboot config, so that I have a workable environment, but also an environment I can use to work on this bug. PS: I came across another webshop which also sells my laptop: https://laptopmetlinux.nl/product/clevo-nl51ru Surprisingly, they support 9 Linux configurations with this laptop, but openSUSE is not on the list. This could potentially be related to the udev issue. I'd be happy to work on this in any way you suggest. Please bare in mind I need some time to get me a workable multiboot system. So I might be unavailable for the next couple of weeks. I'm definitely going to try the list with the 9 distributions.
Created attachment 850399 [details] Leap 15.3 boot iso hangs at udev initialization
OK thanks, it's now clarified. So the problem on Leap 15.3 is the boot problem. And IIRC, the same problem persists on the latest 5.12 kernel from OBS Kernel:stable:Backport repo? Did you try 5.13-rc kernel in OBS Kernel:HEAD:Backport, too? And, if you boot with nomodeset, does it still hang? (i.e. whether it's a problem of AMDGPU or else.)
I have tried 5.13.rc7 from Kernel:HEAD:Backport and 5.12.12 from Kernel:stable:Backport. They both yield the same outcome: | Options | boot | brightness | Comments | | ---------------------------- | ---- | ---------- | ----------------------------------------------------- | | - | No | No | Hangs at "fb0: switching to amdgpudrmfb from EFI VGA" | | acpi=off | Yes | Yes | No ACPI functionality | | nomodeset | Yes | No | Hangs at "fb0: switching to amdgpudrmfb from EFI VGA" | | amdgpu.backlight=0 | No | No | | | nomodeset amdgpu.backlight=0 | Yes | No | |
Apologies for the formatting. I think Markdown is supported by Bugzilla, but apparently only the core syntax. And I can't edit or delete my comment.
Strange, are the really case 2 (nomodeset) and case 4 (nomodeset amdgpu.backlight=0) the different results? With nomodeset, any amdgpu option must make no sense. In anyway, please report the issue to upstream if it happens with TW kernel. The upstream report should go to gitlab.freedesktop.org Issues.
Double checked and confirmed for both 5.12.12 and 5.13.rc7: nomodeset: boots ok, no brightness amdgpu.backlight=0: does not boot, hangs at "fb0: switching to amdgpudrmfb from EFI VGA" nomodeset amdgpu.backlight=0: boots ok, no brightness I'll report this at gitlab.freedesktop.org as per your suggestion. I'll report back the reference when done. Thanks so much for your patience.
Can you please precise which project to use? There are a lot of kernel projects on gitlab.
My laptop CPU is also Ryzen 7 4700U (HP ZHAN66 Pro A 14 G3), but brightness + ext screen work with default settings. I am using Tumbleweed 20210623.
(In reply to Fusion Future from comment #23) > My laptop CPU is also Ryzen 7 4700U (HP ZHAN66 Pro A 14 G3), but brightness > + ext screen work with default settings. I am using Tumbleweed 20210623. I just downloaded and tried TW-20210623. Unfortunately I have the same outcome.
(In reply to Takashi Iwai from comment #20) > In anyway, please report the issue to upstream if it happens with TW kernel. > The upstream report should go to gitlab.freedesktop.org Issues. I've opened AMD issue 1637: https://gitlab.freedesktop.org/drm/amd/-/issues/1637 It was discovered this is actually an iommu problem. After adding `iommu=off` to the boot params I was able to successfully boot the laptop. I now have brightness + external screen. I'm now running on standard Leap 15.3 with the default kernel (5.3.18) :-) To avoid problems for future users, it may be useful to see if this iommu issue is something which can be queried/determined at boot time of the installer. Because the fix (`ommu=off`) is very simple, but I could never have figured this out without expert help. Running into runtime issues is one thing, but not even be able to start the installer is very unsettling. I was at the verge of returning the laptop to the webshop for a refund.
OK, it's good to hear. Judging from the description from Alex, this rather sounds like a bug in BIOS / UEFI. Maybe the kernel could have some workaround (e.g. Intel had quite a few workarounds about IOMMU handling), but waiting for the BIOS fix might be another hope.
As you already found a workaround for the BIOS problem (iommu=off boot option), and assuming that the problem is very device-specific, let's close for now. If a similar problem arises often, we have to consider a wider coverage in the kernel side.