Kernel panic during drm/nouveau init 5.3.0-rc7-next-20190903

Gerd Hoffmann kraxel at redhat.com
Mon Sep 23 06:38:03 UTC 2019


> > 'Git bisect' has identified the following commits as being 'bad'.
> >
> > b96f3e7c8069b749a40ca3a33c97835d57dd45d2 is the first bad commit
> > commit b96f3e7c8069b749a40ca3a33c97835d57dd45d2
> > Author: Gerd Hoffmann <kraxel at redhat.com>
> > Date:   Mon Aug 5 16:01:10 2019 +0200
> >
> >     drm/ttm: use gem vma_node
> >
> >     Drop vma_node from ttm_buffer_object, use the gem struct
> >     (base.vma_node) instead.
> >
> >     Signed-off-by: Gerd Hoffmann <kraxel at redhat.com>
> >     Reviewed-by: Christian K├Ânig <christian.koenig at amd.com>
> >     Link: http://patchwork.freedesktop.org/patch/msgid/20190805140119.7337-9-kraxel@redhat.com

> > Today, I upgraded the kernel to 5.3.0-next-20190919, which booted fine
> > with no Xorg regressions to report.
> >
> > Just wondering if the earlier kernels would not boot for me because of
> > the changes introduced by the 'bad' commits being perhaps incomplete?

Yes, we had a regression in nouveau, fixed by this patch (in drm-misc-next):

commit 019cbd4a4feb3aa3a917d78e7110e3011bbff6d5
Author: Thierry Reding <treding at nvidia.com>
Date:   Wed Aug 14 11:00:48 2019 +0200

    drm/nouveau: Initialize GEM object before TTM object
    
    TTM assumes that drivers initialize the embedded GEM object before
    calling the ttm_bo_init() function. This is not currently the case
    in the Nouveau driver. Fix this by splitting up nouveau_bo_new()
    into nouveau_bo_alloc() and nouveau_bo_init() so that the GEM can
    be initialized before TTM BO initialization when necessary.
    
    Fixes: b96f3e7c8069 ("drm/ttm: use gem vma_node")
    Acked-by: Gerd Hoffmann <kraxel at redhat.com>
    Acked-by: Ben Skeggs <bskeggs at redhat.com>
    Signed-off-by: Thierry Reding <treding at nvidia.com>
    Link: https://patchwork.freedesktop.org/patch/msgid/20190814093524.GA31345@ulmo

HTH,
  Gerd



More information about the dri-devel mailing list