Bug 249357

# sysctl hw.model
hw.model: AMD E-300 APU with Radeon(tm) HD Graphics

Created attachment 217988 [details]
dmesg output

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

Comment 9 Alexey Dokuchaev 2020-09-16 03:27:17 UTC

(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.

Comment 10 Niclas Zeising 2020-09-16 11:26:14 UTC

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?

Comment 12 Niclas Zeising 2020-09-16 15:32:39 UTC

(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.

Comment 17 Emmanuel Vadot 2020-09-17 06:31:32 UTC

(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/.

Small update, but FreeBSD 13.0 appears to resolve whatever the issue was, mostly.  I think you have to specify 'kld_list="radeonkms"' as the very first line of rc.conf, otherwise I *think* the icing effect may happen again.  Not too sure.  Currently on BETA3 and I am back to a fully-working X11/Mate desktop.  I sometimes get some minor graphical glitches when moving a Compiz-enabled window around, but that's extremely minor at this point.  I will leave it up to any developers on whether they want to keep this bug open.  This laptop will not be going back to 12.x anytime soon.