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.
Created attachment 213502 [details] Xorg.o.log
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
(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
drm-legacy-kmod comes with a drm2.ko as well.
Are you using drm-legacy-kmod or drm-fbsd12.0-kmod? What happens if you try the modesetting driver instead?
(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.
(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?
(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. :-)
Created attachment 213885 [details] Boot messages, reboot after kernel panic
(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.
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
xf86-video-ati-legacy has been deprecated and removed, since it broke after the xorg-server 1.20 update. Is this still relevant?
This port was removed on 2020-09-16 in r548803
Does this mean I have to get a newer graphics card?
(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.
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.
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.
(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.
(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 ?
(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
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
(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!
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.
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
Closing, if this is still happening with up to date package feel free to re-open.