Op 09-10-17 om 11:59 schreef Chris Wilson: > Quoting Maarten Lankhorst (2017-10-09 10:41:29) >> Op 06-10-17 om 19:18 schreef Chris Wilson: >>> When we unregister the connector, we may have a pending hotplug work. >>> This needs to be cancel early during the teardown so that it does not >>> fire after we have freed the connector. Or else we may see something like: >> Well the nice thing is even if it's called modeset_retry_work, it just sets the link status to bad for DP. > Ok, and sends a hotplug event. At what point in the shutdown sequence > does that drm_kms_helper_hotplug_event() become invalid? Some digging makes me suspect at the very end of driver unload. So for this either is fine. But after some more digging, it's not enough, see below. >> I worry it might be too early, wouldn't intel_dp_connector_destroy be a better place? At that point we know userspace can no longer use it, >> because the last reference has been removed. > connector_destroy is after drm_kms_helper_poll_fini(), so that seems > suspect given a query about drm_kms_helper_hotplug_event() > > A hook from drm_atomic_helper_shutdown? Extending unregister to have a > late phase? > Well after some more digging the only case where early_unregister vs unregister matters is DP-MST, where we can lose connectors dynamically. As long as we never use modeset_retry_work on DP-MST connectors, everything is fine. Fortunately we don't do that, only used in DP connectors for now. But if you look at the backtrace, the first error is from intel_fbdev_fini, so we need to cancel the work after poll_fini, and before fbdev_fini. Fixing it in early_unregister is simply too late.. ~Maarten _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
