Quoting Daniel Vetter (2017-07-14 20:14:38) > First thing we need to do is unregister the fbdev instance, but we > can't just go ahead and kfree it. That must wait until the hotplug and > polling work are stopped, since they can race with the with the > teardown. That means we need to split up the fbdev teardown into the > unregister part and the cleanup part. > > I originally suspected that this was broken in one of the unload > shuffles, but on closer inspection the oldest sequence I've dug out > also gets this wrong. Just not quite so badly. > > I've run drv_module_reload a few hundred times and it's rock solid > compared to insta-death beforehand. This bug seems to have been > uncovered by > > commit 88be58be886f1215cc73dc8c273c985eecd7385c > Author: Daniel Vetter <daniel.vetter@xxxxxxxx> > Date: Thu Jul 6 15:00:19 2017 +0200 > > drm/i915/fbdev: Always forward hotplug events > > But the effect of that seems to only be to increase the race window > enough to make it blow up easier. I'm not exactly clear on what's > going on there ... > > Testcase: igt/drv_module_reload > Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=101791 > Cc: martin.peres@xxxxxxx > Cc: chris@xxxxxxxxxxxxxxxxxx > Signed-off-by: Daniel Vetter <daniel.vetter@xxxxxxxxx> Splitting out the unregister and running it early makes sense and is how we expect to unload to proceed. Reviewed-by: Chris Wilson <chris@xxxxxxxxxxxxxxxxxx> Nit: > @@ -1383,7 +1383,6 @@ void i915_driver_unload(struct drm_device *dev) > intel_gvt_cleanup(dev_priv); > > i915_driver_unregister(dev_priv); > - > intel_modeset_cleanup(dev); I think it will useful to maintain the visual break here. (I know next patch moves it again...) -Chris _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
