Drm: mgag200. Video adapter issue with 5.4.0-rc3 ; no graphics

[Daniel Vetter]

On Wed, Nov 13, 2019 at 6:42 PM John Donnelly
<john.p.donnelly at oracle.com> wrote:
>
> Hi Thomas:  See below
>
> > On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann <tzimmermann at suse.de> wrote:
> >
> > Hi John
> >
> > Am 12.11.19 um 20:13 schrieb John Donnelly:
> >>
> >> In short .  I started   with :
> >>
> >> git bisect start
> >>
> >> git bisect bad be8454afc50f
> >>
> >> git bisect good fec88ab0af97
> >>
> >> And at the  the end of   bisects  showed this was the offending commit :
> >>
> >> c0a74c732568
> >>
> >> commit c0a74c732568ad347f7b3de281922808dab30504 (refs/bisect/bad)
> >> Author: Jani Nikula <jani.nikula at intel.com>
> >> Date:   Fri May 24 20:35:22 2019 +0300
> >>
> >>    drm/i915: Update DRIVER_DATE to 20190524
> >>
> >>    Signed-off-by: Jani Nikula <jani.nikula at intel.com>
> >>
> >> That does not have any real relevance
> >
> > No, that doesn't look right. The other bad commits you list below also
> > don't seem to be related.
>
>
>
> Thank you for your patience ;  I  started over and the bisect took to me to  this change that certainly reflects the behavior I am seeing :
>
> commit 81da87f63a1edebcf8cbb811d387e353d9f89c7a (refs/bisect/bad)
> Author: Thomas Zimmermann <tzimmermann at suse.de>
> Date:   Tue May 21 13:08:29 2019 +0200
>
>     drm: Replace drm_gem_vram_push_to_system() with kunmap + unpin
>
>     The push-to-system function forces a buffer out of video RAM. This decision
>     should rather be made by the memory manager. By replacing the function with
>     calls to the kunmap and unpin functions, the buffer's memory becomes available,
>     but the buffer remains in VRAM until it's evicted by a pin operation.
>
>     This patch replaces the remaining instances of drm_gem_vram_push_to_system()
>     in ast and mgag200, and removes the function from DRM.

Yeah that looks a lot more plausible as the culprit.

> My 1st impression is we need a method  that restores the previous behavior that pushes the content to the device .

Can you pls grab the debugsfs for the above broken kernel (without any
of the later reworks on top), both for console mode and after you
started gnome. Plus I guess booting with drm.debug=0xfe and full dmesg
(please note the timestamp when you started gnome, that helps with
sifting through it all, it's going to be a lot). You might need to
grab the full dmesg from logs on disk, please make sure it includes
everything from boot-up.

Thanks, Daniel

>
>
>
>
> >
> > You could also bisect between your original working commit (v4.18?) and
> > the one you want to upgrade to (v5.3?). It's only a few more builds but
> > might be might give better results.
> >
> > BTW, are you also converting Gnome from X11 to Wayland. I found that
> > Gnome's Wayland code is so slow on mgag200 that it's unusable. They
> > recently added a shadow FB [1] to improve performance, but it won't be
> > available before Gnome 3.36.
>
>
> I found this issue using
>
> gnome-desktop3-3.28.2-1.el8.x86_64
>
> If there is a more specific. RPM  I can look at for guidance I will .
>
>
> >
> > Best regards
> > Thomas
> >
> > [1] https://gitlab.gnome.org/GNOME/mutter/merge_requests/877/diffs
> >
> >>
> >>
> >> I am not sure if I did  the  bisects correctly .   After each test I did :
> >>
> >>
> >> #1  git bisect bad 827440a90146
> >>
> >> #2  git bisect bad f5b07b04e5f0
> >>
> >> #3  git bisect bad c0a74c732568
> >>
> >> #4  git bisect good 818f5cb3e8fb
> >>
> >> #5  git bisect good 6cfe7ec02e85
> >>
> >> #6 git bisect good f71e01a78bee
> >>
> >> #7  git bisect good 09a93ef3d60f
> >>
> >> #8  git bisect good f1e6b336bafa
> >>
> >> #9 git bisect good eaf20e6933dc
> >>
> >> #10  git bisect good 63e8dcdb4f8e
> >>
> >> #11  git bisect good 397049a03022
> >>
> >> I’ve restarted the bisect without appending the  <commit-id> after a  the “bad|good “  ,  and so far git  is showing the same selections.
>
>
> ======== snip ========
> _______________________________________________
> dri-devel mailing list
> dri-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel



-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch