Re: Radeon HD 7570M: drm: deep frustration with r339186

From: Johannes Lundberg <johalun0_at_gmail.com>
Date: Sat, 6 Oct 2018 10:05:43 +0100
On Sat, Oct 6, 2018 at 7:19 AM Pete Wright <pete_at_nomadlogic.org> wrote:

>
> On 10/5/18 6:34 PM, Graham Perrin wrote:
> > On 23/09/2018 08:09, Graham Perrin wrote:
> >
> >> Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with
> Radeon HD 7570M
> >> … better without drm-next-kmod; and (as expected, given the package
> message) drm-stable-kmod has known problems with UEFI.
> > Now (with r339186) it seems that drm-next-kmod is the only usable option.
> >
> > However, I'm sorry to say:
> >
> > - it does feel regressive, compared to working without drm-next-kmod
> with earlier versions of -CURRENT.
> >
> > I can no longer find a way to reliably suspend (sleep) the notebook.
>
> hey Graham - I'm struggling with suspend/resume issues as well on my end
> with recent 12-ALPHA releases.  can you verify that you can
> suspend/resume without loading the radeonkms.ko (i believe that is what
> you are using for gfx)?  on my systems it's broken regardless if i load
> the drm modules.
>
> also, what was the last version of CURRENT you were able to
> suspend/resume with?
>
>
> > At the time of writing my part-working configuration is as outlined
> below.
> >
> > However – frustratingly – for a while, an hour or so ago, it seemed as
> if the same configuration was useless; after a point, the screen would go
> blank (grey) and things would progress no further e.g. no login manager
> (sddm); no response to Control-Alt-F2; no response to Control-Alt-Delete.
> The apparent unpredictability leading to a dead-end situation has created a
> sense of unease; now I'm genuinely afraid to test suspend :-(
>
> i believe johannes lundberg is working on a fix for this issue. i'm in
> the same uneasy situation as you.  the system i use for dogfooding is
> also my main work laptop, and not having suspend/resume and other
> instability like this is certainly not ideal.  one potential fix
> workaround we've found is to not load the module via "kld_list" but
> rather load it by hand via "kldload" manually.  i believe the bug is in
> relation to how the BIOS allocates memory - i'll let him fill in details :)
>

Hi

This kld_list issue is only for newer Intel and drm-devel.

Regarding instability with CURRENT. When something changes in CURRENT that
might affect the drm drivers there's always a delay until the drm-kmod
packages have been rebuilt against the new source. If you're frequently
updating your -CURRENT system, it's safest to build drm-kmod from source at
the same time. Either with ports or from the github repo. We're working on
trying to reduce this lag but to avoid it completely is impossible when
living in -CURRENT.


for me at least it looks like system instability when loading drm-next
> kernels is separate from suspend/resume.  but its certainly possible my
> laptop is a snowflake :p
>
> hope this helps.
>
> -pete
>
>
> --
> Pete Wright
> pete_at_nomadlogic.org
> _at_nomadlogicLA
>
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
>
Received on Sat Oct 06 2018 - 07:06:22 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:18 UTC