> On Nov 13, 2019, at 2:06 PM, Daniel Vetter <daniel@xxxxxxxx> wrote: > > On Wed, Nov 13, 2019 at 6:42 PM John Donnelly > <john.p.donnelly@xxxxxxxxxx> wrote: >> >> Hi Thomas: See below >> >>> On Nov 13, 2019, at 2:17 AM, Thomas Zimmermann <tzimmermann@xxxxxxx> 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@xxxxxxxxx> >>>> Date: Fri May 24 20:35:22 2019 +0300 >>>> >>>> drm/i915: Update DRIVER_DATE to 20190524 >>>> >>>> Signed-off-by: Jani Nikula <jani.nikula@xxxxxxxxx> >>>> >>>> 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@xxxxxxx> >> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
