Created attachment 45356 [details] dmesg See summary and backtrace. I assume 63ec0119d3720034dfd626c9785aefa5a6f972ca is the offender.
Michel? I don't have hardware to test this...
Looks like one of the pointers in radeon_legacy_backlight_get_brightness() is NULL, but I'm not sure which one that could be. Johannes, can you add some debugging output to see which one it is?
Created attachment 45373 [details] dmesg (In reply to comment #2) > Looks like one of the pointers in radeon_legacy_backlight_get_brightness() is > NULL, but I'm not sure which one that could be. Johannes, can you add some > debugging output to see which one it is? boot parameter: drm.debug=255 nomodeset 3 then a 'rmmod radeon' and finally a 'modprobe radeon'
Thanks, but I mean modifying radeon_legacy_backlight_get_brightness() to print the value of each pointer before dereferencing it. If you don't know how to do that, I can try whipping up a test patch.
Created attachment 45386 [details] [review] Debugging patch This patch (only compile tested) should print the pointer values before referencing them, and bail if one of them is NULL. This should also avoid the immediate crash, but it might still crash elsewhere later on.
Created attachment 45392 [details] dmesg dmesg output with applied Debugging patch
After a second and third try (after reboots) I got: [drm] pdata=00000072 I assume it is the value I receive each time now.
So bl_get_data() returns NULL in radeon_legacy_backlight_get_brightness(). I'm stumped as to how that could happen... Any ideas, Matthew?
That's bizarre. I can't see any obvious way this could happen.
It does not crash when building against recent kernels.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.