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

[John Donnelly]

> On Nov 13, 2019, at 2:06 PM, Daniel Vetter <daniel at ffwll.ch> wrote:
> 
> 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


  Hi 

 I started a Bugzilla 


https://bugs.freedesktop.org/show_bug.cgi?id=112265