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

[John Donnelly]

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.


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




> 
> 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 ========