Re: loading amfgpu results in immefiate power off on 12.3-STABLE r371721

On Sun, Mar 27, 2022 at 11:09 AM Pete Wright <pete@nomadlogic.org> wrote:

>
>
> On 3/25/22 21:42, Chris wrote:
> > This probably isn't the correct list. But it's the closest of
> > all the lists I'm subscribed to. Please forgive me.
> > OK so here's what happened. I couldn't get the trackpad on a
> > Dell laptop I just got to work in FreeBSD-13. So after a couple
> > of days, I gave up and tried 12.3-STABLE r371721 today. Once I got
> > the network (wifi) going. I pkg installed drm-kmod && it's depends.
> > Added kld_list="amdgpu" to rc.conf && rebooted. The moment it
> > loaded, the screen went black and it powered off. Booted to
> > single-user, fsck && cp /var/log/messages to ~/ .
> > I'm attaching a copy in case it sheds any light on the cause.
> > The most interesting thing about all this, is that amdgpu
> > worked flawlessly on 13 -- go figure.
> >
>
> this discussion is probably best suited for the freebsd-x11 mailing
> list, but i think you can try a couple things:
>
> - give NomadBSD a spin (https://nomadbsd.org/).  it's a live USB image
> that does a really good job at auto-detecting hardware and giving you
> nice desktop.  it's based on freebsd-13.0.  you can also install it on
> your disk if everything looks good.  i frequently use it to test
> hardware support on new systems i encounter.
>
> - it's hard to tell without any hardware info provided, but its possible
> you have an older AMD gpu, as such you might want to try using radeonkms
> in rc.conf rather than amdgpu.
>
> if neither of those things help i'd definitely suggest subscribing to
> the freebsd-x11@ mailing list to get the appropriate eyes on things:
> https://lists.freebsd.org/subscription/freebsd-x11
>

I'd like to share with people that I'm working on a statement of what works
and what the graphics team will spend a lot of effort on vs continue to have
build support in the tree.

The short version is that the latest stable branch, the latest current and
the
last most-recent release will be the ones best supported. Anything older
than that (prior stable branches, even those supported by the rest of the
project) may work great, but may also be broken or perform less well or
support fewer newer graphics cards. In addition, cards older than about
a decade may stop working on an upgrade because upstream's attention
to these isn't so great or the driver is a binary driver that the upstream
vendor
has not upgraded to support its older cards with newer interfaces, etc.
Short of doubling or tripling the graphics team size (volunteers welcome),
it's too
hard to commit to more than this limited subset of support. Even with a
larger
active developer group, expanding beyond this envelope would be hard given
the size of the testing matrix...

Also, I don't think we've ever supported unloading the drm drivers, so it's
not
too surprising that didn't work.

Also, I know the older hardware thing is hard to swallow. I get that people
want
that stuff to work forever because it performs adequately. However, we are
heavily
dependent on leveraging the work of others to support what we can, so when
the
work we depend on starts to bitrot, our support for that hardware suffers
as well...

Warner


> -pete
>
> --
> Pete Wright
> pete@nomadlogic.org
> @nomadlogicLA
>
>
>