Xorg under 13.1-RELEASE was running fine with my preferred graphics device.

Yesterday, I updated to 13.2-RELEASE.
The freebsd-update to 13.2 went smoothly enough.
Next, I did "pkg upgrade".

Unfortunately, I then discovered that X wouldn't start,
so I tried "pkg upgrade -f" and rebooted yet again.

X still won't start, whether running as myself or as root.

The log file lines for both graphics devices says (edited):
The PCI device [...] has a kernel module claiming it.
This driver cannot operate until it has been unloaded.

kldstat, aside from the modules I'm sure are unrelated, lists
the following as loaded:

intpm.ko, smbus.ko, uhid.ko, usbhid.ko, hidbus.ko,
wmt.ko, ums.ko, green_saver.ko

Also curious, X is logging to /var/log/Xorg.1.log at the moment instead of
to Xorg.0.log (which does exist and was written a couple hours ago).

lsof shows no processes with the devices open (as expected from the
error message saying a kernel module has them). "ps agx" shows no X
server running and nothing on v9.

Anyone have any suggestions? TIA,
-WBE

On Wed, 12 Apr 2023 01:06:01 -0400
Winston <wbe@UBEBLOCK.psr.com.invalid> wrote:

> Xorg under 13.1-RELEASE was running fine with my preferred graphics device.
>
> Yesterday, I updated to 13.2-RELEASE.
> The freebsd-update to 13.2 went smoothly enough.
> Next, I did "pkg upgrade".
>
> Unfortunately, I then discovered that X wouldn't start,
> so I tried "pkg upgrade -f" and rebooted yet again.
>
> X still won't start, whether running as myself or as root.
>
> The log file lines for both graphics devices says (edited):
> The PCI device [...] has a kernel module claiming it.
> This driver cannot operate until it has been unloaded.
>
> kldstat, aside from the modules I'm sure are unrelated, lists
> the following as loaded:
>
> intpm.ko, smbus.ko, uhid.ko, usbhid.ko, hidbus.ko,
> wmt.ko, ums.ko, green_saver.ko
>
> Also curious, X is logging to /var/log/Xorg.1.log at the moment instead of
> to Xorg.0.log (which does exist and was written a couple hours ago).
>
> lsof shows no processes with the devices open (as expected from the
> error message saying a kernel module has them). "ps agx" shows no X
> server running and nothing on v9.
>
> Anyone have any suggestions? TIA,
> -WB

I need a module compiled from ports to run X11.

kld_list="i915kms.ko"

It won't update properly from a repository. I need to compile it.

Your module is likely different.

Not sure that is your problem.

In article <20230412173952.75f03789@happy.dwarf7.net>,
<george@invalid.com> wrote:
>I need a module compiled from ports to run X11.
>
>kld_list="i915kms.ko"
>
>It won't update properly from a repository. I need to compile it.

graphics/drm-fbsd13-kmod works fine for me under 13.2.
Loads automatically upon startx(1)

>Your module is likely different.

For reasons I can't remember and I failed to document the OP is
in my killfile, but the output of pciconf(8) might be a good start
if you're going to invest some cycles on helping him debug.

John
groenveld@acm.org

In response to my asking for help getting X to run after upgrading to
13.2-RELEASE, <george@invalid.com> kindly replied:
>>I need a module compiled from ports to run X11.

>>kld_list="i915kms.ko"

>>It won't update properly from a repository. I need to compile it.
>>Your module is likely different.

I'll keep that in mind, but that seems more like the kind of problem a
new graphics card might have. The machine in question has pretty old
graphics, and even the built-in (motherboard) graphics with generic
drivers like vesa won't start up any more. (The virtual terminals work,
at least.) The risk is more likely that they're no longer supported,
except that I'd be surprised if support vanished between minor versions.
I do see that the official Nvidia 304 driver for one of the devices says
it won't work with X 1.20 or later, but I haven't used that driver (or
even installed it).

groenveld@acm.org (John D Groenveld) then replied:
> For reasons I can't remember and I failed to document the OP is
> in my killfile,

I don't know why I would be either, but OK.

> ... the output of pciconf(8) might be a good start

1) "pciconf -l" (which is what I assume you had in mind) lists both
graphics devices:

vgapci0@pci0:3:3:0: class=0x030000 rev=0xa1 hdr=0x00 vendor=0x10de device=0x0221 subvendor=0x3842 subdevice=0xb399
vgapci1@pci0:3:4:0: class=0x030000 rev=0x0a hdr=0x00 vendor=0x102b device=0x0532 subvendor=0x15d9 subdevice=0xba11

2) The machine in question has a rather complete xorg.conf that
describes the devices, the drivers to use, etc., so I don't think
failing now would be a result of some change in Xorg's default
startup. I compared the Xorg.0.log from a few days ago with the
current one, and all the setup stuff looks the same, except now it
dies saying a kernel module is claiming the device ... The same
xorg.conf worked a couple days ago under 13.1 with Xorg X Server
1.21.1.4 with the "nv" driver. It's not working today under 13.2
with Xorg X Server 1.21.1.8 with any driver. The PCI device numbers
are the same as they were before, and the Xorg.0.log file description
of the devices matches (i.e., the graphics cards didn't swap numbers
with each other after the upgrade and reboot).

Additional things I've tried since my original post:

* I Google'd the error message, found a bunch of articles dating from
mid-2000s to 2019, and tried pretty much everything anyone suggested.
None worked. Using alternate drivers, including vesa (the machine has
BIOS, not UEFI), didn't help.

* One reference was the X11 section of the FreeBSD Handbook, dated
March 2023. Tried what that said. No improvement.

* Several places recommended deleting the xorg.conf file altogether.
Tried that. X still didn't start, but it did die a bit differently
when its fallback (looking for /dev/dri/card0) failed (no /dev/dri/).

* I note that the log file says the server relies on udev. However, I
see no program named udev. apropos (man -k) finds nothing either.

* One article referenced "lspci" with -k which looked potentially
helpful, since it could show which kernel module owns (or could own)
the PCI device. I found lspci in the pciutils pkg. Unfortunately,
-k only works on Linux and isn't even a valid switch in the pkg
repository version.

* I renamed /usr/local/lib/xorg/modules/drivers/nvidia_drv.so to ensure
neither it nor glx gets loaded. "Xorg -configure" still dies saying
a kernel module is claiming the device.

Sorry if this rambled a bit. I've spent the day trying one thing after
another, looking for any clue as to how to make progress, and nothing so
far seems to have helped.

Still TIA,
-WBE

In my previous article, I wrote:
> I note that the log file says the server relies on udev.
> However, I see no program named udev.

I've learned that udev and libudev.so are related to devd, so saying
the X server relies on that makes sense. I've now read many devd .conf
files, but haven't figured out a solution yet.
-WBE

I found a solution, for now at least:

revert back to the previous version (16) of
"/usr/local/lib/libpciaccess.so.0.11.1".

I don't see a way to tell pkg to revert back to the previous version,
and the only version of libpciaccess in the repository is 17, so I had
to revert manually.

What pkg calls version 16 has the exact same file name (ending in
0.11.1) as version 17. The new version is slightly bigger and says
compiled for 13.1 instead of 13.0. 16 works (for me); 17 does not.

Others, with entirely different hardware, reported this same problem
years ago: see FreeBSD bugs 239065 and 239200 where it happened under
FreeBSD 11 and 12 with libpciaccess 14 (broken) vs. 13.5 (OK). The
solution then was to downgrade to 13.5 or upgrade to just-released 16.

I'll file a bug report through bugzilla.
-WBE

I've now found that others reported a similar problem since late last
month with different hardware and drivers. See FreeBSD bug 270509.
-WBE