X.Org occasionally crashing

kpedersen said:
Since the move to kernel modesetting, this is fine to use the modesetting driver (it is also accelerated). The usermode graphics drivers for Xorg have mostly been phased out. However in the case of amdgpu, radeon drivers they do provide some extra features, such as TearFree.

But Xorg should "do the right thing" without config (but as you have noticed, sometimes the digital world isn't quite perfect!). Not sure if you have already done this, but usually it can help to kldload the GPU modesetting driver (these are named differently to Xorg drivers!) before starting X. That way you can help isolate which part of the stack is unhappy.
Click to expand...
Do I have to enable tearfree? I had screen tearing before and still do. (Can see them by moving windows or watching videos)
By kldloading GPU modesetting driver do you mean something other than having radeonkms in kld_list (on /etc/rc.conf)?
 
Erichans said:
Try removing radeonkms from kld_list="radeonkms", i.e. not using drm-61-kmod. There's more to say about this, I'll try to write up something sensible (I hope) later.
Click to expand...
Doesn't seem to help it, now tty is in low res (X is fine) so it's properly applied but right on first attempt of fullscreen video it crashed again..
 

Attachments

HexagonWin said:
Do I have to enable tearfree? I had screen tearing before and still do. (Can see them by moving windows or watching videos)
By kldloading GPU modesetting driver do you mean something other than having radeonkms in kld_list (on /etc/rc.conf)?
Click to expand...
The modesetting(4) driver doesn't have TearFree. The i.e radeon(4) and amdgpu(4) drivers do. So the latter tend to be the better option if you find that your Xorg is defaulting to modesetting. You can tell by looking at the (admittedly very noisy) xorg.log.

Its quite confusing but the driver you put in the kld_list (radeonkms) is *different* to the modesetting, radeon, amdgpu drivers. The latter are Xorg drivers. The former is the KMS driver (i.e Xorg needs it. It doesn't need Xorg).

Basically it might be as simple as adding TearFree as an option in one of your xorg.conf files once the rest of your setup is working.
 
Cath O'Deray said:
I see a crash of fvwm, not X.
Click to expand...
Right.. I just noticed. For now I switched to another WM, maybe this was an FVWM2 issue after all..
kpedersen said:
The modesetting(4) driver doesn't have TearFree. The i.e radeon(4) and amdgpu(4) drivers do. So the latter tend to be the better option if you find that your Xorg is defaulting to modesetting. You can tell by looking at the (admittedly very noisy) xorg.log.

Its quite confusing but the driver you put in the kld_list (radeonkms) is *different* to the modesetting, radeon, amdgpu drivers. The latter are Xorg drivers. The former is the KMS driver (i.e Xorg needs it. It doesn't need Xorg).

Basically it might be as simple as adding TearFree as an option in one of your xorg.conf files once the rest of your setup is working.
Click to expand...
Xorg defaulted to modesetting before I installed the xf86-video-ati driver, now it's defaulting to that one. So this driver should have Tearfree capabilities but it isn't enabled by default? Right now I haven't enabled it manually and there's screen tearing.

Right now I removed radeonkms from kld_list but X11 is still working okay, is this unusual?
 
HexagonWin said:
Right.. I just noticed. For now I switched to another WM, maybe this was an FVWM2 issue after all..
Click to expand...
You might still want to look into that. I haven't really experienced fvwm dying on me in a quarter century of using it, so there may be some mangled WM config, or some general system instability.
 
HexagonWin said:
Erichans said:
Try removing radeonkms from kld_list="radeonkms", i.e. not using drm-61-kmod. There's more to say about this, I'll try to write up something sensible (I hope) later.
Click to expand...
Doesn't seem to help it, now tty is in low res (X is fine) so it's properly applied but right on first attempt of fullscreen video it crashed again..
Click to expand...
From your dmesg where you said you had removed radeonkms from your /etc/rc.conf:
Rich (BB code): 
---<<BOOT>>---
Copyright (c) 1992-2023 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
	The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 14.1-RELEASE-p3 GENERIC amd64
   [...]
ZFS filesystem version: 5
ZFS storage pool version: features support (5000)
[drm] radeon kernel modesetting enabled.
drmn0: <drmn> numa-domain 0 on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
sysctl_warn_reuse: can't re-use a leaf (hw.dri.debug)!
[drm] initializing kernel modesetting (CAICOS 0x1002:0x6779 0x1B0A:0x909D 0x00).
[drm ERROR :radeon_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO
ATOM BIOS: DeLL
I don't understand why or what generates this: "[drm] radeon kernel modesetting enabled."
It is either:
a. some setting in your /boot/loader.conf or /etc/rc.conf
- that either directly or indirectly sets it to be enabled
b. it is somehow enabled automatically: I have no clue what could do that.

Could you check especially a.? Also, when not starting Xorg does your dmesg show that kernel mode enabling also?
Remarkably, this quoted output is nearly identical with your dmesg output from message-#12 where you mention: "I have radeonkms fusefs on kld_list."

I also find the specific reference to "ATOM BIOS: DeLL" a bit suspect, check if there's a general BIOS/firmware update available or for your HD 6450 graphics card in particular.
 
Erichans said:
I don't understand why or what generates this: "[drm] radeon kernel modesetting enabled."
It is either:
a. some setting in your /boot/loader.conf or /etc/rc.conf
- that either directly or indirectly sets it to be enabled
b. it is somehow enabled automatically: I have no clue what could do that.

Could you check especially a.? Also, when not starting Xorg does your dmesg show that kernel mode enabling also?
Remarkably, this quoted output is nearly identical with your dmesg output from message-#12 where you mention: "I have radeonkms fusefs on kld_list."

I also find the specific reference to "ATOM BIOS: DeLL" a bit suspect, check if there's a general BIOS/firmware update available or for your HD 6450 graphics card in particular.
Click to expand...
Hmm.. to me it seems like that dmesg contains logs from multiple boots. I'm not sure why, I just ran sudo dmesg > dmesg.txt to generate them.
I can't find anything that would enable it, and I'm pretty sure it isn't enabled. When I do enable it I get crisp high-res 1920x1080 properly working on the tty as well, but now in my tty I have bigger/blurry fonts like in BIOS (so low res).

I had a missed BIOS update for my mainboard (A34, was running A33) so I recently installed it by booting Windows 10 on another SSD. Not sure if that has any effect.. And for the HD 6450 I'm not even sure where I should get "up"dates for it as the official resources are all gone. (so a firmware i get from the net might not even be newer than mine and can potentially be for another oem's card)
 
Right, it looks like you have a working/workable driver from x11-drivers/xf86-video-ati/ (not being further developed), albeit using User Mode Setting (UMS) and not using Kernel Mode Setting (KMS). That may limit various 2D/3D etc. acceleration methods.
For the graphics stack, UMS is being phased out, new developments use KMS.

However, for a not fully functioning drm-61-kmod using radeonkms, consider submitting a PR as mentioned by Emrion in message #10. You get these "drm" errors referencing the radeonkms reliably in your dmesg output (mentioned in your message here); I noticed at beginning of the log of the boot process:
Code: 
[drm ERROR :radeon_ib_ring_tests] radeon: failed testing IB on GFX ring (-60).
[drm ERROR :radeon_device_init] ib ring test failed (-60).
IMO you have a hook for developers to work on. Additional info when Xorg has started may be useful too.

Your AMD HD 6450 is frequently referenced by its alternate (code) name : CAICOS, that is part of the "Northern Island" group; you see that referenced in your Xorg logs and dmesg output.

Based on:
there should be a working Kernel Mode Setting supported driver for your HD 6450.
That means there must be a working pair:
  • a DRM-KMS driver like the kernel module radeonkms from graphics/drm-61-kmod referenced by kld_list="radeonkms" in rc.conf
  • an Xorg driver, that would be the general default modesetting driver* (modesetting_drv.so) referenced by Driver "modesetting" in a Section Device. Usually this gets loaded automatically when staring X.
For KMS to work in X you need these two that interact with each other.

A graphics driver that does not use KMS but instead uses User Mode Setting works in User Space. Such a driver does not need a counterpart DRM-KMS driver.
HexagonWin said:
Right now I removed radeonkms from kld_list but X11 is still working okay, is this unusual?
Click to expand...
So I think this is not unusual. When operating by itself it is only activated when X is started. When you have an appropriate DRM-KMS for your GPU driver kldload-ed, then before you start X you have additional benefits like GPU power management or extra (higher) resolution options available for your terminal.

The graphics stack contains a lot of parts that should all work together. More info at Kernel Mode Setting, Mode setting, and modesetting(4) and drm-kms(7)

___
* Unfortunately, your HD 6450 does not seem to be supported by the Xorg amdgpu driver from x11-drivers/xf86-video-amdgpu that is also able to drive KMS:
Description:
This package contains the X.Org xf86-video-amdgpu driver.

The amdgpu driver supports AMD Radeon chipsets: OLAND, HAINAN, TAHITI, PITCAIRN,
VERDE, BONAIRE, KABINI, MULLINS, KAVERI, HAWAII, TOPAZ, TONGA, CARRIZO, FIJI,
STONEY, POLARIS11, POLARIS10

On FreeBSD requires amdgpu KMS driver from graphics/drm-kmod.
Click to expand...
 
So to organize it seems like
- drm-515-kmod works fine (but prints [drm ERROR :btc_dpm_set_power_state] rv770_restrict_performance_levels_before_switch failed)
- drm-61-kmod doesn't work in most cases (prints both that message from 515 and others, weird artifact and etc)
- xf86-video-ati works fine without weird error (and sleeping & returning with acpiconf -s 3 works well btw)
- fvwm was the one crashing my session (changed my xinitrc to run xeyes after starting fvwm and now session doesn't crash, just needs to rerun DISPLAY=:0 fvwm from another tty when fvwm dies)

So.. to submit a bug report should I do for drm-61-kmod? or should that be done for drm-515-kmod as well since it prints that message though working fine?
This is my first time submitting such report in FreeBSD, is there a document somewhere? Thanks.
 
The FreeBSD Handbook: FreeBSD Glossary - PR entry or 4.8. Dealing with Broken Ports (--> Writing FreeBSD Problem Reports).

Just to clarify, you have the following combinations:
  1. using drm-61-kmod (kld_list=radeonkms) working with the Xorg modesetting driver
  2. using drm-515-kmod (kld_list=radeonkms) working with the Xorg modesetting driver
  3. using ONLY the Xorg radeon driver (Driver "radeon") from x11-drivers/xf86-video-ati
  4. for your std terminal: using drm-61-kmod (kld_list=radeonkms)
    for X: using the Xorg radeon driver (Driver "radeon") from x11-drivers/xf86-video-ati
The Xorg radeon (UMS) driver from x11-drivers/xf86-video-ati used in # 3 & 4 is old: no development there. I wouldn't submit a PR for that.

The combination in #4 is not an ideal one, but a workable combination for users; IMO not a "debuggable" one.

#2 (drm-515-kmod) is still being deployed with supported FreeBSD versions, especially the 13.x-branch. If you experience the same drm errors by just kldloading radeonkms in your dmesg output as shown in your message #9, then you could submit a PR for that. Possibly extended with your experienced errors that result when using X.

However, especially for 14.1 and beyond development is concentrated at drm-61-kmod (which will be the default package when 14.0-RELEASE goes EOL). Further, the same holds as what I mentioned for drm-515-kmod.

Perhaps others have useful suggestions, but my line of thinking is to submit one PR for drm-61-kmod. Consider:
  • In /boot/loader.conf set at the beginning verbose_loading="YES"
  • report the few relevant settings in rc.conf and any specific Xorg setting you used; the latter will probably show all up in the Xorg log file as well
  • attach dmesg output and Xorg log output; completely as you have done before.
    describe briefly the problems you experience and if you are willing, say that you'll be happy to provide further info or help otherwise.

If, while testing drm-515-kmod (#2) seems to work fine but does generate the same kind of errors in your dmeg output you could mention that with the relevant logs attachted. However, there has been a substantial development in the graphics stack internals for drm-61-kmod; as a consequence 515 & 61 may function differently in such a way that they require separate debugging. Thus, if you experience serious error behaviour that is not practically the same as with drm-61-kmod, then I'd submit a seperate PR for drm-515-kmod and crossreference the two.
 
1724329773018.pngdrm-kmod bugs are usually reported primarily in GitHub, there's a template (pictured).
 
You must log in or register to reply here.
Back
Top