Re: [drm] BUG: spinlock lockup suspected on CPU#0, swapper/0/1
Hi
On Tue, Jan 14, 2014 at 2:45 PM, Fengguang Wu 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 :00:02.0: Fatal error during GPU init: -6
[ 12.064914] Trying to free nonexistent resource
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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [drm] BUG: spinlock lockup suspected on CPU#0, swapper/0/1
Hi On Tue, Jan 14, 2014 at 2:45 PM, Fengguang Wu fengguang...@intel.com 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 :00:02.0: Fatal error during GPU init: -6 [ 12.064914] Trying to free nonexistent resource febf-00= 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 -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
