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 > > > > > > > > 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@xxxxxxxxxxxxxxxxxxxxx > https://lists.freedesktop.org/mailman/listinfo/dri-devel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
