Re: 13.0 Current - r350702 exposed a Xorg failure

Graham, I loaded yesterday's new 13.0 Current r351067 snapshot and
re-installed FreeBSD. The basic install went well, and I gave my user
operator, wheel, & video permissions. I loaded Xorg via the pkg install
route, all 172 packages. I installed the drm-kmod pkg too. I rebooted and
ran startx as user and it failed, basically did not create the .serverauth
file. I pressed forward and did the install of my desktop, LXDE, with it's
config files. Still no go. I have looked at your good suggestions and the
results are at the end of this message. I had to copy them to paper as best
I could.

I guess you saw John Baldwin's email of 13 Aug about the changes in
drm-kmod. I played with my /etc/rc.conf and set the line to leave out the
path (/boot/modules/), just "kld_list="amdgpu.ko". That didn't work either.
I was wondering at that point if Pete Wright may be on track with his
suggestion that the permissions were set to root, but I don't think so, as
it all seems to be user - user in the user home directory, root - wheel in
/usr/local/bin where start lives, and root-wheel in /boot/modules where the
kmod files are. Then I started playing with the /etc/rc.conf file and got
some interesting results.

My machine is an HP All in One thing manufactured in 2014. It has a AMD E3
processor with integrated Radeon graphics. I had been using the newer
"amdgpu.ko" module for some weeks, at least through installs of Gnome, KDE,
Xfce, and two or three weeks of LXDE and it worked fine. I tried first
using John Baldwin's sugestion to leave out the path. Thant didn't work,
and I really think this advice was for those who are 1. Installing from
ports, not pkg, and 2. Compiling these modules into their kernel. Neither
apply to me, at least not yet, but I'm always ready to try if needed.

This is where it gets real interesting: I tried the older "radeonkms.ko",
and rebooted. The loading messages did not look promising, but no real
errors either. When I ran startx, it tried to load. I got a white screen,
that changed to a blank one after "some" time, and was unresponsive. I had
to use the power button to shutdown  Bnd guess what? When I rebooted and
performed a post-mortum, it had created an .serverauth file. So it makes we
think the permissions are ok, but there are some problems with my machine
and the amd kmod files. I looked in /boot/modules and both amdgpu.ko &
radeonkms.ko had dates of Aug 11. So the problem keeps shifting, but I'm
working on it.

pkg info | grep kmod :
drm-current-kmod-4.16.g20190806 DRM Modules for the linuxkpi-base KMS
components
drm-kmod-g20190806 Metaport of DRM Modules for the linuxkpi-base KMS
components
gpu-firmware-g20190620

pciconf -lv | grep -C 3 display :
6 lines that confirm my video setup: Kabini/Radeon HD 8280/R3 series
AMD/ATI  VGA

grep PORTS_MODULES /etc/make.conf: FILE/DIRECTORY NOT FOUND

pkg rquery %e drm-kmod : Message about the basic DRM metaport, no hard
info, looks like a sales pitch :)

Anyway, I continue to work on this, one step at a time. Open to any & all
corrections and suggestions.

The base install of r351067 is good, and I installed ports this time, so I
may do a pkg delete drm-kmod and make it from the ports. Maybe it would
suit my machine better.

Clay

On Wed, Aug 14, 2019 at 3:09 AM Graham Perrin <grahamperrin_at_gmail.com>
wrote:

> On 10/08/2019 04:56, Clay Daniels Jr. wrote:
> > drm-kmod was the same (g20190710)
>
> It's equally (if not more) important to consider what's installed by
> drm-kmod.
>
> Can you share output from these three commands?
>
> pkg info | grep kmod
>
> pciconf -lv | grep -C 3 display
>
> grep PORTS_MODULES /etc/make.conf
>
> Thanks.
>
> Also, FYI (to help understand the purpose of drm-kmod):
>
> pkg rquery %e drm-kmod
>
>