Bug 245702 - x11-drivers/xf86-video-ati-legacy does not work under 12.1
Summary: x11-drivers/xf86-video-ati-legacy does not work under 12.1
Status: Closed Overcome By Events
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: i386 Any
: --- Affects Only Me
Assignee: freebsd-x11 (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-17 16:25 UTC by Anders Liljeborg
Modified: 2021-11-19 14:45 UTC (History)
4 users (show)

See Also:
bugzilla: maintainer-feedback? (x11)


Attachments
Output from dmesg (16.17 KB, text/plain)
2020-04-17 16:25 UTC, Anders Liljeborg
no flags Details
Xorg.o.log (11.66 KB, text/plain)
2020-04-17 16:28 UTC, Anders Liljeborg
no flags Details
Boot messages, reboot after kernel panic (25.31 KB, text/plain)
2020-04-28 13:17 UTC, Anders Liljeborg
no flags Details
Photo of screen after kernel panic (545.16 KB, image/jpeg)
2020-05-07 12:54 UTC, Anders Liljeborg
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Anders Liljeborg 2020-04-17 16:25:29 UTC
Created attachment 213501 [details]
Output from dmesg

I upgraded from 12.0 to 12.1 and xf86-video-ati-legacy is broken now.
Trying to use xf86-video-ati.

Have ATI X1300 on PCIe x 16 card, GPU name is RV515, generation Radeon R500 PCIe.

Have tried drm-kmod and drm-legacy-kmod, does not work.
Have kld_list="/boot/modules/radeonkms.ko" in /etc/rc.conf and rebooted several times.
Have hw.syscons.disable=1 in /boot/loader.conf

Does not help.

> kldstat -v | grep drm
                117 drmn/fbd
                540 drmn/radeon_atom_hw_i2c
                536 drmn/radeon_iicbb
                538 drm/radeon_hw_i2c
 8    1 0x1f542000    4a000 drm2.ko (/boot/kernel/drm2.ko)
                531 drmn/drm_iic_dp_aux
                532 drmn

> kldstat -v | grep radeon
 7    1 0x1f470000    d2000 radeonkms.ko (/boot/modules/radeonkms.ko)
                535 vgapci/radeonkms
                540 drmn/radeon_atom_hw_i2c
                537 radeon_iicbb/iicbb
                539 radeon_hw_i2c/iicbus
                536 drmn/radeon_iicbb
                538 drm/radeon_hw_i2c
12    1 0x1f59f000     4000 radeon_R520_cp_bin.ko (/boot/modules/radeon_R520_cp_bin.ko)
                541 radeon_R520_cp_bin_fw

> uname -a
FreeBSD dataserv.nanophys.kth.se 12.1-RELEASE-p3 FreeBSD 12.1-RELEASE-p3 GENERIC  i386

Excerpt from /var/log/Xorg.0.log:
[   248.529] (EE) Screen(s) found, but none have a usable configuration.
[   248.529] (EE)
Fatal server error:
[   248.529] (EE) no screens found(EE)
[   248.529] (EE)

I always get this in dmesg:
info: [drm] Initialized drm 1.1.0 20060810
drmn0: =======================================================
drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod \
pkg
drmn0: =======================================================
drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
drmn0: =======================================================
drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod \
pkg
drmn0: =======================================================
drmn0: Deprecated code (to be removed in FreeBSD 13): drm2 drivers
drmn0: <ATI Radeon X1300/X1550> on vgapci0
info: [drm] RADEON_IS_PCIE
info: [drm] initializing kernel modesetting (RV515 0x1002:0x7187 0x18BC:0x1972)\
.

and I HAVE installed drm-legacy-kmod.
Comment 1 Anders Liljeborg 2020-04-17 16:28:07 UTC
Created attachment 213502 [details]
Xorg.o.log
Comment 2 Val Packett 2020-04-22 01:37:19 UTC
Your radeonkms is loaded from /boot/modules, but there's drm2 from /boot/kernel. This is not correct. (This really should fail harder..)

I guess kldxref didn't work out correctly. For good measure, rm /boot/kernel/drm2.ko
Comment 3 Anders Liljeborg 2020-04-23 11:56:28 UTC
(In reply to Greg V from comment #2)

Thank you very much for the info, Greg_V.

I removed /boot/kernel/drm2.ko and rebooted, but kldstat gives still that drm2.ko is in the kernel.

1001:SU:dataserv:anders> kldstat
Id Refs Address        Size Name
 1   60   0x800000  19a6b64 kernel
 2    1 0x1f400000     7000 fdescfs.ko
 3    1 0x1f407000     b000 linprocfs.ko
 4    2 0x1f412000    50000 linux.ko
 5    1 0x1f462000     7000 linsysfs.ko
 6    1 0x1f469000     7000 nullfs.ko
 7    1 0x1f470000    d2000 radeonkms.ko
 8    1 0x1f542000    45000 drm2.ko
 9    4 0x1f587000     7000 iicbus.ko
10    1 0x1f58e000     5000 iic.ko
11    1 0x1f593000     7000 iicbb.ko
12    1 0x1f59a000     4000 radeon_R520_cp_bin.ko
13    1 0x1f59e000     6000 uhid.ko
14    1 0x1f5a4000     7000 wmt.ko
15    1 0x1f5ab000     8000 ums.ko
16    1 0x1f5b3000    2f000 ipfw.ko
17    1 0x1f5e2000     4000 mac_ntpd.ko
1002:SU:dataserv:anders> cd /boot/kernel/
1003:SU:dataserv:kernel> lf drm*
drm.ko*

I cannot unload the drm2.ko:

1005:SU:dataserv:kernel> kldunload drm2.ko
kldunload: can't unload file: Device busy

And I still get the same error when running "startx".

However, the error meesage of "drm2 deprecated code" has dissappeared from dmesg. 

I have tried with and without hw.syscons.disable=1 in /boot/loader.conf
rebooted between each trial.

Same error in /var/log/Xorg.0.log all the time:
[  1768.060] (II) UnloadModule: "radeon"
[  1768.060] (EE) Screen(s) found, but none have a usable configuration.
[  1768.060] (EE)
Fatal server error:
[  1768.060] (EE) no screens found(EE)
[  1768.060] (EE)

Best wishes
Anders
Comment 4 Niclas Zeising freebsd_committer freebsd_triage 2020-04-23 13:03:28 UTC
drm-legacy-kmod comes with a drm2.ko as well.
Comment 5 Niclas Zeising freebsd_committer freebsd_triage 2020-04-23 13:09:04 UTC
Are you using drm-legacy-kmod or drm-fbsd12.0-kmod?  What happens if you try the modesetting driver instead?
Comment 6 Anders Liljeborg 2020-04-24 14:47:48 UTC
(In reply to Niclas Zeising from comment #5)

I have been using drm-legacy-kmod.

Now I installed drm-fbsd12.0-kmod, this uninstalls drm-kmod and drm-legacy-kmod.
Rebooted.

1005 dataserv:~> kldstat
Id Refs Address        Size Name
 1   61   0x800000  19a6b64 kernel
 2    1 0x1f400000     7000 fdescfs.ko
 3    1 0x1f407000     b000 linprocfs.ko
 4    2 0x1f412000    50000 linux.ko
 5    1 0x1f462000     7000 linsysfs.ko
 6    1 0x1f469000     7000 nullfs.ko
 7    1 0x1f470000   177000 radeonkms.ko
 8    2 0x1f5e7000    7f000 drm.ko
 9    5 0x1f666000    18000 linuxkpi.ko
10    4 0x1f67e000    1a000 linuxkpi_gplv2.ko
11    2 0x1f698000     5000 debugfs.ko
12    1 0x1f69d000    16000 ttm.ko
13    1 0x1f6b3000     4000 radeon_R520_cp_bin.ko
14    1 0x1f6b7000     6000 uhid.ko
15    1 0x1f6bd000     7000 wmt.ko
16    1 0x1f6c4000     8000 ums.ko
17    1 0x1f6cc000    2f000 ipfw.ko
18    1 0x1f6fb000     4000 mac_ntpd.ko


startx gives same error:
[ 12580.071] (EE) Screen(s) found, but none have a usable configuration.

"What happens if you try the modesetting driver instead?"
Do you mean 
kld_list="/boot/modules/radeonkms.ko"
in /etc/rc.conf ?
That I am already using.

THEN I had the good idea to do eaxctly what the Handbook says about old xorg.conf files, I removed
/etc/X11/xorg.conf
and
/usr/local/etc/X11/xorg.conf

Then startx gives kernel panic, and reset button have to be used to get my computer started.
Since I am doing all this remotely via ssh, I cannot try this many times. I have to call a person at my work to press the reset button. I do not have the details what the sysconsole said about the panic. I have to be at work to continue experiments. Unless you have a good tip to avoid kernel panic.
Comment 7 Niclas Zeising freebsd_committer freebsd_triage 2020-04-24 20:31:35 UTC
(In reply to Anders Liljeborg from comment #6)

The modesetting driver is in X.  If you don't have xf86-video-ati installed, it should be used automatically.  I don't know if it works with drm-legacy-kmod though.

In order to know what's going on, we need the backtrace from the panic.  Is the dmesg from using drm-legacy-kmod or drm-fbsd12.0-kmod?

Is there any particular reason you're using i386?  Can you try on amd64 and see if it works better?
Comment 8 Alexey Dokuchaev freebsd_committer freebsd_triage 2020-04-25 13:19:34 UTC
(In reply to Niclas Zeising from comment #7)
> The modesetting driver is in X.  If you don't have xf86-video-ati installed,
> it should be used automatically.  I don't know if it works with
> drm-legacy-kmod though.
For me on AMD A8-5550M, modesetting driver does not work with any drm-* ports (including legacy), producing garbage on the screen and constantly spamming the console with "radeon: The kernel rejected CS, see dmesg for more information (-16)" messages.  When I'd have a chance, I'll try that on i386+RV710 if it makes any difference, against both new and previous X.Org server versions.

> Is there any particular reason you're using i386?
Judging by old trusty RV710 of mine which gives me perfect X.Org experience on i386 (probably even better than on amd64), Anders may be happier with i386+RV515 combo as well. :-)
Comment 9 Anders Liljeborg 2020-04-28 13:17:19 UTC
Created attachment 213885 [details]
Boot messages, reboot after kernel panic
Comment 10 Anders Liljeborg 2020-04-28 13:25:54 UTC
(In reply to Niclas Zeising from comment #7)

I have xf86-ati-video installed.
I have drm-fsbd12.0-kmod installed.
It was like this when the kernel panic happened.

1002:SU:dataserv:anders> pkg info | grep xf86-video
xf86-video-ati-19.1.0_2,1      X.Org ati display driver
xf86-video-scfb-0.0.4_7        X.Org syscons display driver
xf86-video-vesa-2.4.0_2        X.Org vesa display driver
1003:SU:dataserv:anders> pkg info | grep drm
drm-fbsd12.0-kmod-4.16.g20200221 DRM modules for the linuxkpi-based KMS components
libdrm-2.4.99,1                Userspace interface to kernel Direct Rendering Module services

I have extracted the boot messages from the reboot right after the kernel panic, they are in the attachment. since the computer have been running for a while (I need it for some mailserver function) I used /var/log/messages.0.bz2 to extract.

i386 or adm64, forgive my ignorance, do you mean to switch the installation altogether?

I do not know how to do this and keep the user filesystem intact.
Comment 11 Anders Liljeborg 2020-05-07 12:54:49 UTC
Created attachment 214232 [details]
Photo of screen after kernel panic

I tried "startx" while at the computer, took photo of screen after kernel panic, see jpg-image.

Before this trial I removed all xorg.conf files and contents of xorg.confd,
according to FreeBSD handbook.

/etc/X11/
/etc/X11/xorg.confd
/usr/local/etc/X11/
/usr/local/etc/X11/xorg.confd
/usr/local/share/X11/
/usr/local/share/X11/xorg.confd
No valid files in these folders.

As normal user:
> startx
Screen goes black, short flash of random patterns at lower quarter of screen, then kernel panic,
takes about two seconds.

Background on how I upgrade FreeBSD, I use freebsd-update, first I check that current version is fully updated.
Then:
> freebsd-update -r 12.1 upgrade
> /usr/sbin/freebsd-update install
Reboot
Again:
> /usr/sbin/freebsd-update install

After that I remove all packages and clear /var/cache/pkg
Then I install all packages I need using pkg install XXXX.
I never try to compile any port, I have had really bad experiences of this in the past.

Any help is really appreciated.
Best wishes
Anders
Comment 12 Niclas Zeising freebsd_committer freebsd_triage 2020-09-17 09:48:33 UTC
xf86-video-ati-legacy has been deprecated and removed, since it broke after the xorg-server 1.20 update.

Is this still relevant?
Comment 13 Rene Ladan freebsd_committer freebsd_triage 2020-09-18 20:16:23 UTC
This port was removed on 2020-09-16 in r548803
Comment 14 Anders Liljeborg 2020-09-24 13:57:45 UTC
Does this mean I have to get a newer graphics card?
Comment 15 Val Packett 2020-09-26 09:25:25 UTC
(In reply to Anders Liljeborg from comment #14)

xf86 modesetting (or better: try Wayland) should still work with radeonkms, technically.

But of course it's better to get a modern GPU like Polaris or Vega, supported by amdgpu.
amdgpu receives lots of attention both upstream and in FreeBSD.
radeon(kms) receives little attention upstream and pretty much ZERO attention here.
There is currently just no one who is both motivated to work on old (pre-GCN) GPU support and skilled enough to debug and fix the issues.
Comment 16 Niclas Zeising freebsd_committer freebsd_triage 2020-09-26 10:00:36 UTC
drm-kmod still provides the radeonkms.ko driver, and should work with xf86-video-ati or modesetting.  However, as Greg points out, the age of the hardware means that upstream is paying less attention to it.  It is also harder to come by this hardware, meaning that we have limited possibilities to test on it.  Most focus is on amdgpu, which supports hardware from the last 10 years or so.

Specifically, in this case, drm-legacy-kmod is being deprecated as well (however, it will live on in base for the lifetime of FreeBSD 11 and most likely 12), and xf85-video-ati-legacy, which was created to use drm-legacy-kmod broke with the xserver 1.20 update, with no one stepping up to try to fix it.  I made a blind attempt to fix it, which made it build, but did not solve run time issues.
Comment 17 Niclas Zeising freebsd_committer freebsd_triage 2020-09-26 10:02:39 UTC
I also like to point out that i386 most likely is given less and less attention upstream, meaning that there might be regressions on i386 which are not present on amd64.  I don't think this is the problem specifically in this case, but might be worth keeping in mind.
Comment 18 Alexey Dokuchaev freebsd_committer freebsd_triage 2020-09-27 04:48:20 UTC
(In reply to Greg V from comment #15)
> xf86 modesetting (or better: try Wayland) should still work with
> radeonkms, technically.
Probably should work in theory, but does not necessarily work in practice, see my comment #8.

> But of course it's better to get a modern GPU like Polaris or Vega,
> supported by amdgpu.
Many of our users cannot (or do not want to for various reasons) replace the video chip in their laptops.  Replacing a gfx card is often an option for PC users only, and even they might refuse to throw away working hardware just because software support sucks.

> There is currently just no one who is both motivated to work on old
> (pre-GCN) GPU support and skilled enough to debug and fix the issues.
I'm motivated, albeit unskilled, to fix support for pre-GCN cards.  Technically this should be doable because they definitely used to work 2-3 years ago.  However, I still can't decide whether I should start with figuring out when the base DRM bits (or drm-legacy-kmod port) got broken, or forget about the legacy bits and work with the new code provided by the latest drm-{current,devel}-kmod ports.

(In reply to Niclas Zeising from comment #16)
> Most focus is on amdgpu, which supports hardware from the last 10
> years or so.
While NI (the last pre-GCN family) was released back in 2010, it had been used for several years in AMD APU-based laptops.  I've purchased mine in 2016 and it was still using it, so amdgpu(4) is not an option for me.
Comment 19 Emmanuel Vadot freebsd_committer freebsd_triage 2020-09-27 08:08:22 UTC
(In reply to Alexey Dokuchaev from comment #18)
> Probably should work in theory, but does not necessarily work in practice, see > my comment #8.

I don't see where this message can come from.

(In reply to Alexey Dokuchaev from comment #18)
> I'm motivated, albeit unskilled, to fix support for pre-GCN cards.
> Technically this should be doable because they definitely used to work 2-3 
> years ago.  However, I still can't decide whether I should start with figuring 
> out when the base DRM bits (or drm-legacy-kmod port) got broken, or forget 
> about the legacy bits and work with the new code provided by the latest 
> drm-{current,devel}-kmod ports.

It's not possible to compare the last code that was in sys/dev/drm2 with even the first drm-kmod.
drm-kmod didn't originated from the sys/dev/drm2 code, it was started to be port from scratch from the Linux code with Linuxkpi.
If radeonkms doesn't work for you on -CURRENT (I insist on -CURRENT as it's the only branch activelly supported right now) please create a new issue at https://github.com/freebsd/drm-kmod/. Note that it works for powerpc64 for some devices and while it doesn't mean that it might work on i386 or with the hardware that you have it means that it's not dead code.
I suggest you first try the image I've made a few weeks ago, see https://lists.freebsd.org/pipermail/freebsd-current/2020-September/077024.html for the links.

(In reply to Alexey Dokuchaev from comment #18)
> While NI (the last pre-GCN family) was released back in 2010, it had been used > for several years in AMD APU-based laptops.  I've purchased mine in 2016 and 
> it was still using it, so amdgpu(4) is not an option for me.

What brand/model is that ?
Comment 20 Alexey Dokuchaev freebsd_committer freebsd_triage 2020-09-27 20:13:05 UTC
(In reply to Emmanuel Vadot from comment #19)
> I suggest you first try the image I've made a few weeks ago
I'm aware of those and already downloaded both images, but didn't have a chance to try them out just yet; will do.

> What brand/model is that?
https://wiki.freebsd.org/Laptops/HP_ProBook_645_G1
Comment 21 Anders Liljeborg 2020-10-01 16:21:00 UTC
Thanks for all the attention to my problem.

I can replace the graphics card, it sits in a normal desktop PC, although a rather old one.
The graphics cards for amdgpu (Polaris, Vega) seems to be very high-end cards intended for gamers. I do not need that, just something that works for normal office use.
Do you have any suggestions?

What I DO NOT want to do is to reinstall an amd64 FreeBsd, I would like to stick to i386 on this hardware.
To reinstall means to wipe the whole system disk (or take a fresh disk), and reinstall/re-configure everything, quite a lot of work for me.

Best wishes
Anders
Comment 22 Val Packett 2020-10-01 16:29:30 UTC
(In reply to Anders Liljeborg from comment #21)

Vega is indeed only relatively high end. Polaris starts with the cheap, low power RX 550. Some older cards are supported too, but the newer ones are going to be more efficient and easier to find possibly.

i386 is very sad, no developers really care about desktop on i386 anymore, so it just "hopefully works". You don't have to wipe everything to switch to amd64. Quite possibly you could even just run i386 userspace with an amd64 kernel!
Comment 23 Niclas Zeising freebsd_committer freebsd_triage 2020-10-02 07:36:33 UTC
amdgpu is used for GPUs made in the last decade or so.  It's not just high end gamer GPUs, but all GPUs.

There have been reports about a few laptops being made in the last 5 or so years that still need radeonkms for their built in GPUs.

As Greg say, i386 desktops are slowly dying.  Hardware created in the last 15-ish years is amd64, and for desktop, both our and upstream effort is targeted at amd64 primarily, not i386 (not counting other arches, such as arm, which is also getting a lot of attention).

While i386 isn't outright unsupported, it is given less attention, and regressions will probably happen from time to time.
Comment 24 Anders Liljeborg 2020-10-08 16:30:09 UTC
Thanks very much for comments, specially from GregV and Niclas Zeising.

This is probably outside of the topic for this bug report, but how can I switch to amd64 without wiping the system currently using i386?

Maybe stupidly of me, I have only one partition, output from df:
1001 dataserv:~> df
Filesystem      1K-blocks      Used      Avail Capacity  Mounted on
/dev/raid/r0p2  941515716 643371372  222823088    74%    /
devfs                   1         1          0   100%    /dev
fdescfs                 1         1          0   100%    /dev/fd
procfs                  4         4          0   100%    /proc
linprocfs               4         4          0   100%    /compat/linux/proc
linsysfs                4         4          0   100%    /compat/linux/sys
/dev/da0       2838281452 873576216 1737642720    33%    /mnt/bup0

Output from mount:
1002 dataserv:~> mount
/dev/raid/r0p2 on / (ufs, local, journaled soft-updates)
devfs on /dev (devfs, local, multilabel)
fdescfs on /dev/fd (fdescfs)
procfs on /proc (procfs, local)
linprocfs on /compat/linux/proc (linprocfs, local)
linsysfs on /compat/linux/sys (linsysfs, local)
/dev/da0 on /mnt/bup0 (ufs, local)

Best wishes
Anders
Comment 25 Emmanuel Vadot freebsd_committer freebsd_triage 2021-11-19 14:45:00 UTC
Closing, if this is still happening with up to date package feel free to re-open.