On Fri, Aug 7, 2020 at 12:56 AM Tetsuo Handa <penguin-kernel@xxxxxxxxxxxxxxxxxxx> wrote: > > On 2020/08/07 0:39, Daniel Vetter wrote: > > On Thu, Aug 6, 2020 at 5:28 PM Christian König <christian.koenig@xxxxxxx> wrote: > >> > >> My best guess is that you are facing two separate bugs here. > >> > >> Crash #1 is somehow related to CRTCs and might even be cause by the > >> atomic-helper change you noted below. > > > > Yeah, and I think I know what's going on. Patch incoming. When testing > > that patch, please make sure you're testing on a kernel with shows > > crash pattern 1, but is not broken by crash pattern 2. > > -Daniel > > I confirmed that the patch at https://lkml.kernel.org/r/20200806154227.2255197-1-daniel.vetter@xxxxxxxx > changes crash pattern from 1 to 2. You can send the patch for avoiding Crash #1. > > > > >> > >> Crash #2 is caused because vmw_bo_create_and_populate() tries to > >> manually populate a BO object instead of relying on TTM to do it when > >> necessary. This indeed doesn't work any more because of "drm/ttm: make > >> TT creation purely optional v3". > >> > >> Question is why vmwgfx is doing this? > >> > >> Regards, > >> Christian. > >> > > F.Y.I. syzbot is reporting a similar NULL pointer dereference on virtio at > https://syzkaller.appspot.com/bug?id=955763105a919df5d19b8ed26f244d698ef15ac3 . > Bisection attempt is not made yet because reproducer is not found yet. Nah, that's a different one, fireworks in shmem helpers. vmw blows up due to ttm helper code. Those are two totally different ways to manage gpu memory, so definitely different bugs. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel