On Tue, Jul 30, 2013 at 4:10 PM, Maarten Lankhorst <maarten.lankhorst@xxxxxxxxxxxxx> wrote: > Op 30-07-13 04:42, Ben Skeggs schreef: >> On Tue, Jul 23, 2013 at 11:43 PM, Maarten Lankhorst >> <maarten.lankhorst@xxxxxxxxxxxxx> wrote: >>> Sort of fixes mmiotrace for me again, I could sear I sent a similar patch before >>> the rework to event interface, so I guess it got reintroduced. >> I don't know how/why you think this fixes anything. The interrupt >> handler can't possibly be called until after priv->base.vblank has >> been initialised... >> >> Seriously, go look, the subdev interrupt handler pointer isn't filled >> in (and can't be) until after nouveau_disp_create() has been called, >> and nouveau_disp_create() initialises priv->base.vblank before it >> returns... >> > There's also a disp_dtor function right above it and without a smp_wmb > the writes could still be reordered in the constructor. O:-) A spinlock would > be needed to make sure that no interrupt is in process if you set intr to null > before destroying vblank event, though. > > I can probably try to get the oops again indicating that priv->base.vblank was null in the interrupt handler if you want, > iirc it happened reliably during mmiotracing. It would've had to have happened during a module unload in that case, I can't see how else it could've possibly happened. The destructor case is valid though, but not really a critical issue, so I'd rather find a better solution than these hacked checks :) I'll add it to the list... Ben. > > ~Maarten _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
