Bug 231884 - x11-drivers/xf86-video-ati stops working after update to 18.1.0,1
Summary: x11-drivers/xf86-video-ati stops working after update to 18.1.0,1
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Some People
Assignee: freebsd-x11 (Nobody)
Depends on:
Reported: 2018-10-02 20:13 UTC by rsmith
Modified: 2019-01-04 21:05 UTC (History)
12 users (show)

See Also:

xorg log from failing startup (25.29 KB, text/plain)
2019-01-04 18:28 UTC, george
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description rsmith 2018-10-02 20:13:58 UTC
After updating the port from 7.9.0_3,1 to 18.1.0,1, my X11 setup stopped working; the screen turns off and doesn't show anything, although it seems that X11 and i3 are running.

What I saw in dmesg:

   drmn0: error: No GEM object associated to handle 0x00000438, can't create framebuffer

Just to be sure there were no lingering remains from the old driver in memory, I tried rebooting, but that didn't make a difference.

* X.Org X Server 1.18.4
* ATI Radeon HD 3450
* 11.2-STABLE r338042
* GENERIC kernel, amd64
Comment 1 Niclas Zeising freebsd_committer 2018-10-03 11:05:02 UTC
Are you using any drm-kmod ports or the driver from base? Can you try installing drm-stable-kmod from ports and follow the instructions if you aren't using that already.
Can you please also provide your Xorg.log?
Comment 2 Christian Weisgerber freebsd_committer 2018-10-03 15:05:07 UTC
FWIW, I had the same problem on amd64 11.2-STABLE 339010 with my

ATI Radeon HD 5450

Installing drm-kmod and thus drm-stable-kmod and adding kld_list="/boot/modules/radeonkms.ko" fixed it.
Comment 3 rsmith 2018-10-03 20:42:16 UTC
(In reply to Christian Weisgerber from comment #2)

Thanks Christian, your tip fixed the issue.
Comment 4 rsmith 2018-10-03 20:51:05 UTC
On a more general note, I think there could be a *little* more guidance w.r.t. graphics/drm.

Even as a longtime FreeBSD user (since 5.x) it sometimes confuses the heck out of me what you need to get some graphics functionality working!

If xf86-video-ati-18.1 requires drm-kmod, shouldn't it depend on it?

Or if that is not possible because some graphics cards might not need it, at least a pkg-message like "Depending on your hardware, this driver might *require* the drm-kmod port."

I saw the message in UPDATING, but to me "It is recommended" != "your hardware might not work correctly without it".
Comment 5 lumiwa 2018-10-04 22:40:44 UTC
I have the same problem on FreeBSD 11.2-RELEASE (amd64) installed on iMac (efi boot).

vendor='Advanced Micro Devices, Inc. [AMD/ATI]'
device='RV770/M98L [Mobility Radeon HD 4850]

And as I read there are a problems (or were) with Raden graphics card and Efi boot.

Update didn't worj for me and I downgraded the port and it works again..
When I have a time, I do not have now I will try the new driver again.

And as they said before /usr/ports/UPDATING is not so useful in this case.
Comment 6 lumiwa 2018-10-05 10:14:26 UTC
(In reply to Niclas Zeising from comment #1)
Does line  hw.acpi.reset_video=1 in /etc/sysctl.conf help for usind drm-kmod drivers for radeon uefi boot, please because I did read somewhere that is not recommended?
Comment 7 Greg V 2018-10-05 13:24:34 UTC
(In reply to lumiwa from comment #6)
I'm not sure how much this applies to something as old as HD 4850, but with modern Radeon cards, the EFI framebuffer conflict is solved by hw.syscons.disable=1 (which, well, disables the EFI framebuffer, so you have garbage on screen after the bootloader and before the GPU driver loads :D)
Comment 8 Greg V 2018-10-05 13:25:36 UTC
(oh and use /boot/loader.conf not /etc/sysctl.conf, the latter is too late for most graphics-related settings)
Comment 9 lumiwa 2018-10-05 22:49:51 UTC
(In reply to Greg V from comment #8)
I put hw.syscons.disable=1 in /boot/loader.conf and I have also kern.vty="vt"
and didn't work.

If I run sysctl hw.syscons.disable=1 manually I got:
sysctl: unknown oid 'hw.syscond.disable'

or I am doing something wrong.
Comment 10 Graham Perrin 2018-10-06 01:07:50 UTC
(In reply to lumiwa from comment #6)

> … hw.acpi.reset_video=1 … read somewhere that is not recommended?

It seems to be significantly troublesome for me with r339186 on an HP EliteBook 8570p with AMD 'Thames' Radeon HD 7570M.

You might find details on the freebsd-current list in due course. (I need to cover other things first.)
Comment 11 Tatsuki Makino 2018-10-06 06:02:59 UTC
By the way,

> Installing drm-kmod and thus drm-stable-kmod and adding kld_list="/boot/modules/radeonkms.ko" fixed it.

this means that 10.x support is over, right?
Comment 12 Graham Perrin 2018-10-06 06:32:40 UTC
(In reply to Christian Weisgerber from comment #2)

> … Installing drm-kmod and thus drm-stable-kmod …

Maybe off-topic but for the record, re: <https://pastebin.com/8qdpWR1x> it seems to me that: 

- installation of drm-stable-kmod requires _removal_ of drm-kmod
Comment 13 Graham Perrin 2018-10-06 08:05:02 UTC
(In reply to Tatsuki Makino from comment #11)

> … 10.x support is over, right?

If it helps to answer your question: 

drm / drm2 removal in 12


(As this bug 231884 is Closed FIXED I should probably encourage people to continue in lists, or at The FreeBSD Forums …)
Comment 14 Niclas Zeising freebsd_committer 2018-10-06 11:26:05 UTC
There is definitely a regression with xf86-video-ati when using the legacy drm driver from base.  We're currently investigating this and will try to find a way to solve it.  If you are on amd64 you can try to use graphics/drm-kmod (this will install either drm-stable-kmod or drm-next-kmod depending on your FreeBSD version), or install either of drm-stable or drm-next directly.

If you are on 12 you can also try drm-devel-kmod.

With regards to 10.x support, that branch is end of life at October 31, so I suggest you try to update to either 11.2 or the upcoming 12.0.

The legacy drm (drm1 and drm2) modules are still in base, the decision to remove them was reverted.  They are also available as a port, graphics/drm-legacy-kmod, which works on a very recent 12.
Comment 15 rsmith 2018-10-07 20:55:59 UTC
(In reply to Niclas Zeising from comment #14)

I can confirm that drm-stable-kmod *works fine* on

* X.Org X Server 1.18.4
* ATI Radeon HD 3450
* 11.2-STABLE r338042
* GENERIC kernel, amd64
* BIOS boot (this machine's to old for UEFI)
Comment 16 ml 2018-10-08 06:37:56 UTC
Just a "me too", here, in case it helps others.

* "ATI Radeon HD 4200" (ChipID = 0x9710)
* BIOS boot (not UEFI)
* FreeBSD 11.2/amd64
* xorg-server-1.19.6_1,1

Adding drm-kmod (which in turn installed drm-stable-kmod and gpu-firmware-kmod) solved this problem.
Comment 17 Marek Zarychta 2018-10-08 16:11:53 UTC
(In reply to Niclas Zeising from comment #14)

I can also confirm that after installation of drm-kmod and loading radeonkms.ko module from this package both 11.2-STABLE and 12.0-ALPHA8 desktops work fine with the recently updated xf86-video-ati driver.

My graphics card is: 

vgapci0@pci0:1:5:0:	class=0x030000 card=0x3047103c chip=0x97101002 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'RS880 [Radeon HD 4200]'
    class      = display
    subclass   = VGA
Comment 18 Tatsuki Makino 2018-10-08 20:23:20 UTC
My comment #11 also implies "me too". But I am using 10.4-STABLE amd64. The problem is not solved using drm-kmod because drm-kmod has "IGNORE= not supported on 11.1 or older, no kernel support" for (${ARCH} == "amd64" && ${OSVERSION} < 1101510).
There is not a month left, but it was a bit early to make 10.x out of support :)
Comment 19 johan van Zanten 2018-10-09 05:19:19 UTC

Just for the record,this problem began for me when i upgraded from 11.2-RELEASE-p2 to 11.2-RELEASE-p4, and then rebuilt and reinstalled all of the ports i use.

X.Org X Server 1.18.4
Radeon HD 5470

I used the fix described by Christian Weisgerber to get X working again. (Danke schoen!)  For me this meant:

  pkg install graphics/drm-kmod

Change /etc/rc.conf:

old line: kld_list="radeonkms"

new line: kld_list="/boot/modules/radeonkms.ko"
Comment 20 lumiwa 2018-10-09 22:40:07 UTC
(In reply to Niclas Zeising from comment #14)
I am still not succsful.
Posted on https://pastebin.com/GGnP7zPu my glxinfo and some from dmesg| grep radeon.
I am using ati drivers 7 still.

Thank you.
Comment 21 johan van Zanten 2018-10-10 05:55:04 UTC
dejacque:/var/crash # pkg info | grep drm
drm-kmod-g20180930             Metaport of DRM modules for the linuxkpi-based KMS components
drm-stable-kmod-g20180822      DRM modules for the linuxkpi-based KMS components
libdrm-2.4.93,1                Userspace interface to kernel Direct Rendering Module services

I've discovered an unpleasant side effect of the fix -- the kernel panics when i shutdown or reboot.  It's after the "syncing disks" message.

I can upload the vmcore from the crash if that'd be useful. This crash happens with the GENERIC kernel and a custom kernel i normally run (that removes a lot of devices not in my laptop). Below is the core.txt from one of the custom kernel crashes (the traceback is the same with both kernels).  I can upload the kernel crash dump if that would be helpful.

panic: page fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:
<118>Stopping devd.
<118>Waiting for PIDS: 352.
<118>Writing entropy file:.
<118>Writing early boot entropy file:.
<118>Oct  9 22:10:56 dejacque syslogd: exiting on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop... done
Waiting (max 60 seconds) for system process `bufdaemon' to stop... done
Waiting (max 60 seconds) for system process `syncer' to stop... 
Syncing disks, vnodes remaining... 5 5 4 0 0 done
All buffers synced.
Uptime: 1h22m15s
[drm:cypress_dpm_set_power_state] rv770_restrict_performance_levels_before_switch failed
VT: Switching back from "fb" to "vga".
vgapci0: REPOSTing

Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address   = 0x2c0
fault code              = supervisor read data, page not present
instruction pointer     = 0x20:0xffffffff8063f042
stack pointer           = 0x28:0xfffffe01e7ce9770
frame pointer           = 0x28:0xfffffe01e7ce9780
code segment            = base rx0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1 (init)
trap number             = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0xffffffff8064e277 at kdb_backtrace+0x67
#1 0xffffffff80607b97 at vpanic+0x177
#2 0xffffffff80607a13 at panic+0x43
#3 0xffffffff8090447f at trap_fatal+0x35f
#4 0xffffffff809044d9 at trap_pfault+0x49
#5 0xffffffff80903ca7 at trap+0x2c7
#6 0xffffffff808e596c at calltrap+0x8
#7 0xffffffff8184cf50 at backlight_device_unregister+0x150
#8 0xffffffff8166c0e8 at radeon_enc_destroy+0x58
#9 0xffffffff817d0e0b at drm_mode_config_cleanup+0x3b
#10 0xffffffff816fb88b at radeon_modeset_fini+0x11b
#11 0xffffffff81709a8d at radeon_driver_unload_kms+0x3d
#12 0xffffffff817dd229 at drm_dev_unregister+0x39
#13 0xffffffff817dd1c0 at drm_put_dev+0x30
#14 0xffffffff81845249 at linux_pci_shutdown+0x39
#15 0xffffffff80641d0a at bus_generic_shutdown+0x5a
#16 0xffffffff80641d0a at bus_generic_shutdown+0x5a
#17 0xffffffff80641d0a at bus_generic_shutdown+0x5a
Uptime: 1h22m21s
Dumping 496 out of 8034 MB:..4%..13%..23%..33%..42%..52%..62%..71%..81%..91%
Comment 22 Adam Jimerson 2018-10-11 03:18:36 UTC
I'm running into this issue as well

FreeBSD 11.2-RELEASE-p4
GENERIC kernel, amd64
X.Org X Server 1.18.4
vgapci0@pci0:10:0:0:	class=0x030000 card=0x24601462 chip=0x67191002 rev=0x00 hdr=0x00
    vendor     = 'Advanced Micro Devices, Inc. [AMD/ATI]'
    device     = 'Cayman PRO [Radeon HD 6950]'
    class      = display
    subclass   = VGA

I've tried installing the drm-kmod (and thus drm-stable-kmod) ports and adding the following to my /etr/rc.conf


But I'm still getting the same error, for now I rolled back to the previous ati driver.
Comment 23 Adam Jimerson 2018-10-11 11:49:03 UTC
(In reply to Adam Jimerson from comment #22)

Following up on this, I guess I had a typo in the kld_load statement in my rc.conf file as removing what I had and copying and pasting one from here and rebooting fixed it with xf86-video-ati 18.1.0,1
Comment 24 Jason W. Bacon freebsd_committer 2018-10-15 15:57:38 UTC
Hit the same issue on my ThinkPad X120e.  Installing drm-stable-kmod fixed it.

I'd like to see the issue with the base kmods fixed.

I maintain sysutils/desktop-installer, and this prevents users from getting a working desktop.

If fixing the regression is not feasible, an automated way to detect when one of the kmod ports is needed would be a fallback option.  I'm already autodetecting Intel GPUs and setting kld_list in those cases.

Comment 25 Niclas Zeising freebsd_committer 2018-10-15 18:14:14 UTC
(In reply to Jason W. Bacon from comment #24)

It's very hard to fix the regression in a good way.  If we revert the change, we will break support for newer hardware.  This seem to be a problem with the legacy kmod, which only support old hardware, being incompatible with the new xf86-video-ati.  The new drm-stable-kmod modules support mostly the same hardware, as well as more modern hardware, and works with the new xf86-video-ati.

There is already a port, graphics/drm-kmod that selects the appropriate kmod depending on FreeBSD version.

It might be possible to create a legacy version of xf86-video-ati, but that would conflict with the current version, meaning it would be troublesome getting it installed.

Trying to figure out, based on hardware, which xf86-video-ati port to install would, in my opinion, be very fragile, and probably only lead to even more support issues.
Comment 26 Niclas Zeising freebsd_committer 2018-10-15 18:18:17 UTC
(In reply to Tatsuki Makino from comment #18)

FreeBSD 10 is out of support half a month.  It is not worth spending time and effort on fixing this for FreeBSD 10.  I recommend you update to FreeBSD 11.2 or the upcoming FreeBSD 12.
Comment 27 Niclas Zeising freebsd_committer 2018-10-15 18:20:05 UTC
(In reply to johan van Zanten from comment #21)
Any chance you can report this issue here: https://github.com/FreeBSDDesktop/kms-drm/issues
or create a separate issue for this in bugzilla?
Comment 28 Niclas Zeising freebsd_committer 2019-01-03 02:24:18 UTC
Closing this.  A workaround has been provided for affected users.
If you experience problems with ATI graphics cards when using the legacy kernel driver, please try with xf86-video-ati-legacy xorg DDX.
Comment 29 johan van Zanten 2019-01-04 13:28:52 UTC
FWIW, this kernel panic at shutdown i described in comment #21 has stopped after i upgraded to FreeBSD 12.0-RELEASE-p1.

Also upgraded were all of the installed packages, notably the DRM related packages, which are now:
Comment 30 george 2019-01-04 18:26:19 UTC
This bug is still biting me.
11.2-RELEASE-p6 FreeBSD 11.2-RELEASE-p6 #0 r341632
I can't say it was due to an update. because I've been using the motherboard and CPU in question as a non-graphics server for about five years, and now I have recycled them into a desktop system where I do need graphics.  I'll attach my Xorg.log.0.  I got the exact same "can't create framebuffer" message given by the original poster (which led me to this bug).  I installed:


and set kld_list="radeonkms" in my /etc/rc.conf.  Is there anything else I can try?
Comment 31 george 2019-01-04 18:28:45 UTC
Created attachment 200775 [details]
xorg log from failing startup
Comment 32 johan van Zanten 2019-01-04 20:27:16 UTC
(In reply to george from comment #30)

I needed to change my kld_list line in /etc/rc.conf to be:


... maybe that would help?

Comment 33 george 2019-01-04 21:05:48 UTC
That was it!  Thanks for the crucial clue.  It all works now!

I actually saw the instruction about giving the full path name, but my brain (thinking that it was cleverer than the pkg-message) decided that the full path name was clearly unnecessary, and the effort to type all those extra letters in would be wasted effort.

I hate when my brain is wrong.