I have this old laptop that I've ran FreeBSD on since the 10.x-RELEASE days, and although slow, it generally works for my needs. It's powered by an AMD E-300 APU w/ embedded Radeon HD 6310 GPU (PALM). On a late ~2019 ZFS BE with xorg-server-1.18, running 12.1-RELEASE, everything, including hardware-accelerated compositing, still works.
However, after the xorg-server-1.20 update, hardware-accelerated compositing no longer works. It looks like glamor fails to initialize (eglInitialize() fails), so compiz falls back to software rendering, which is unusable. I tried a variety of things, including building xorg-server and mesa from ports, but nothing works, so all I am left with is trying to get newer KMS drivers to work.
However, trying drm-fbsd12.0-kmod, when /boot/modules/radeomkms.ko is loaded during boot (via /etc/rc.conf), the screen will get "frosty", is about how I can describe it. It literally looks like it ices over, with this white haze that quickly spreads out from the edges of the LCD inwards to the center. The console text inverts to a medium'ish gray color, like attempting to read a sign in heavy, dense fog, and the machine is completely locked up. The only way to recover is to hard-power the machine off by holding the power button down for ~5 seconds.
I have gone as far as building branch drm-v5.0-fbsd12.1 from the kms-drm github repo. Same effect as above. drm-legacy-kmod is the only KMS drivers that will work. I am primarily using the modesetting driver, but have also tried the radeon driver from x11-drivers/xf86-video-ati to no avail. I have also updated the base system to 12.2-BETA1, and that hasn't helped any either.
Open to any ideas for testing. I'll likely end up just retiring the machine and moving the drive to something newer, but figured to at least open a bug in case it turns out to be a silly quick fix.
# sysctl hw.model
hw.model: AMD E-300 APU with Radeon(tm) HD Graphics
Created attachment 217988 [details]
Created attachment 217989 [details]
pciconf -lvbce output
Created attachment 217990 [details]
devinfo -vr output
Created attachment 217991 [details]
pkg info output (note, contains several ports built as packages)
Created attachment 217992 [details]
Customized kernel config for 12.2-BETA1
Created attachment 217993 [details]
'cat /dev/klog' output when running kldload /boot/modules/radeonkms.ko
Created attachment 217994 [details]
JPEG of the LCD screen "iced up" ~3 seconds after radeonkms.ko is loaded
(In reply to Joshua Kinard from comment #0)
> at least open a bug in case it turns out to be a silly quick fix.
Thank you for doing this. AMD/ATI Radeon cards support got considerably broken for pre-GCN GPUs (TeraScale, Evergreen/NI) with recent updates to FreeBSD graphics stack, and we need more reports like this in order to assess the damage and help us fix this fallout faster.
The drm-v5.0-fbsd12.1 branch is broken and should not be used. If you need a more recent version of drm-kmod than is available in drm-fbsd12.0-kmod, I suggest updating to FreeBSD Current. drm-current-kmod is at version 5.4.
When using the amd drivers (either amdgpu or radeonkms) you might need to set hw.syscons.disable=1 in loader.conf to disable the console before the driver is loaded, when using UEFI boot.
(In reply to Niclas Zeising from comment #10)
Laptop is from ~2011, so it doesn't have UEFI, just BIOS. And it's a dual-core system that's rather slow, so I really plan to stick to binary packaging where possible. Last I checked, I don't think -CURRENT is doable by basic binary updates through freebsd-update(8). buildworld/installworld would be an all-day affair on this machine.
And even if drm-v5.0-fbsd12.1 is broken, the issue I am encountering still happens, so whatever the cause is, is probably independent of the branch's current brokenness. I'd be content at this point to get a more recent radeonkms.ko to initialize and drop me off at a shell prompt at the laptop's native resolution (like current drm-legacy-kmod will do). That would then move the ball back to figuring out why eglInitialize() fails against current xorg-server.
Are there any debugging switches to radeomkms? I have some familiarity with poking around Linux's kernel, but haven't dived deep into FreeBSD's as much, so not as familiar w/ debugging things. It looks like 'cat /dev/klog' can get me some kind of usable raw output when loading the driver, up until the screen does the icing-up effect.
And given I'm on 12.2-BETA1, which branch of kms-drm would be best to test/debug with?
(In reply to Joshua Kinard from comment #11)
For FreeBSD 12, the best branch to track is drm-v4.16-fbsd12.0. It is the same as is in in the drm-fbsd12.0-kmod package, and should be pulled in automatically by drm-kmod. You might want to compile the module locally though, to match the sources of the system you are running. I'm assuming now that what's in /usr/src matches the running kernel.
(In reply to Niclas Zeising from comment #12)
Yup, /usr/src matches the running kernel. I run most things off of prebuilt binaries for BSD, but like to compile my own kernels. I have already tried building drm-v4.16-fbsd12.0/drm-fbsd12.0-kmod from source. I actually first noticed this issue earlier this year, and have periodically attempted re-rolling drm-fbsd12.0-kmod from source, to no avail. 12.2-BETA1's release gave me an idea to try again, hoping for a fix.
Some added observations. I worked out by renaming the four firmware files this APU needs that the "icing-up" effect does not happen if radeon_SUMO_rlc_bin.ko cannot be loaded. I am also noticing that when the effect does happen, it happens before the I2C bus is able to probe for the display. So it hints to me that the problem(s) are in either the SUMO_rlc code or it's something to do with how the I2C logic is or isn't working right to probe the display. I'm leaning more towards I2C. The icing-up effect doesn't seem emblematic of code doing something funny, but more of hardware being told to do something the wrong way, like bad voltage being applied somewhere or such.
Are you using /boot/loader.conf or /etc/rc.conf to load the drm-kmod driver?
(In reply to unitrunker from comment #15)
Under normal circumstances, /etc/rc.conf. However, my testing today has been by loading the modules manually via kldload. The first four prerequisite modules (drm.ko, debugfs.ko, linuxkpi_gplv2.ko, and ttm.ko) load fine. It's when loading radeonkms.ko that the issue happens.
(In reply to Joshua Kinard from comment #14)
It could be worth trying to use a kms-firmware commit that correspond to the 4.16 kernel (from https://github.com/FreeBSDDesktop/kms-firmware/).
I had concern a while ago that syncing the firmware with upstream should be done more carefully for amd/radeon since they are not versioned like the intel one.
Maybe the driver doesn't know how to handle the latest firmware (that wouldn't be surprising).
Joshua, can you grab the panic/backtrace? https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html Thank you.
(In reply to Emmanuel Vadot from comment #17)
I tested for this using the working drm-legacy-kmod, and that version of the package appears to work fine with the latest firmware package (gpu-firmware-kmod-g20200914, built from ports). I made sure that loading /boot/modules/radeonkms.ko was loading firmware files only from /boot/modules by renaming the three firmware files it needs and got a corrupted display (not the icing-up effect or lockup), and was then able to unload radeonkms.ko before rebooting.
So if the older kms-drm works with the latest GPU firmware package, it should be expected that the newer kms-drm should also work that far. I think this rules out the firmware package as the cause and still points to the I2C probing not working right on this particular laptop model.
Are there any debug switches for FreeBSD's I2C/IIC driver(s) that can be easily enabled and will print stuff out to the kernel log?
(In reply to pr from comment #18)
I don't think the machine gets as far as a panic. It's a hard hang-up somewhere after radeonkms.ko loads the firmware files but before the I2C display probing output happens.
Well, you should find out. I have been experiencing panics with BIOS machines that have not been solved yet. If you have a similar problem a backtrace would help. Or if you can confirm the machine does not panics, this also helps, so we know it's not the same problem.
(In reply to pr from comment #21)
Given the display issue I cited, I can't be certain that, if there is a panic, that it's even being printed to the screen. If the display hardware is being told to do the wrong thing, it won't be able to emit any further output. That said, the last several instances where I have forced the issue, I had 'cat /dev/klog' running in a second SSH session (after shutting syslogd down), and I got no further output from there as well. This machine also does not have any form of serial console output. So my best judgement is that it does not panic, but instead enters some kind of hardware fault state beyond the operating system's ability to detect or report on.
Well, this smells like kernel panic to me.
In this case you can obtain a crash dump and send the output. It's a 5 minutes thing, details here https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug.html
(In reply to pr from comment #23)
It is not a kernel panic. I verified that dumpdev was configured to use swap space and then triggered the problem. After rebooting, savecore did not write anything out to /var/crash/.