Hi On Tue, Jan 14, 2014 at 2:45 PM, Fengguang Wu <fengguang.wu@xxxxxxxxx> wrote: > Hi David, > > I'm not sure if this is a good bisect because the errors are noisy, > however it's good to inform you of this possibility. > > First bad commit may be a3483353c ("drm: check for !kdev in drm_unplug_minor()") To be honest, I doubt that it's somehow related to this commit. We replace "!device_is_registered(minor->kdev)" with a "!minor->kdev". Both of these expressions have no side-effects (especially the latter one) and they only evaluate to true during DRM unplugging. Having said that, your log also contains this: [ 12.058502] [drm] Initialized drm 1.1.0 20060810 [ 12.059918] [drm] radeon kernel modesetting enabled. [ 12.061791] [drm:cirrus_vram_init] *ERROR* can't reserve VRAM [ 12.063409] cirrus 0000:00:02.0: Fatal error during GPU init: -6 [ 12.064914] Trying to free nonexistent resource <00000000febf0000-000000= 00febf0fff> The DRM cirrus driver fails to load and given the error message I suspect the error-path is not clean. Dave Airlie should know more about cirrus, but I really think this is related to cirrus not correctly cleaning up it's resources. Dave, any ideas? Disbling CONFIG_CIRRUS should be a good workaround, in case anyone cares. The commit in question highly reduces the required stack-space during DRM unload (which includes the cirrus error-path) so I think the bisect was alright, but the commit is not the actual culprit. It just reveals some stack-corruption, I guess. Thanks David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel