On Thu, May 21, 2015 at 04:30:34PM +0200, Nicolas Kalkhof wrote: > Hi Daniel, > > > Ah, Chris hunch against my claim that this is impossible was spot-on. Can > > you please try the below hack please and grab dmesg? Hopefully the kernel > > won't die any more at least. > > Unfortunately the patch doesn't keep my machine from crashing. > > image of stack trace: http://imgur.com/CV5ho1B > dmesg: http://pastebin.com/T69SPT3g > > it seems that the problem now occurs in drm_atomic_get_connector_state. Hm something seems to be deeply wrong here. And the oops you've captured still doesn't include the debug messages before things go boom. Can you please replace the WARN_ON in my previous patch with a BUG_ON? That should stop the machine at least and hopefully prevents it all from going boom. And please play around with dmesg -n to get these debug messages to the console. I really need them to figure out what's going wrong here. -Daniel > > (gdb) list *drm_atomic_get_connector_state+0x40 > 0xff0 is in drm_atomic_get_connector_state (drivers/gpu/drm/drm_atomic.c:652). > 647 * > 648 * Note that we only grab the indexes once we have the right lock to > 649 * prevent hotplug/unplugging of connectors. So removal is no problem, > 650 * at most the array is a bit too large. > 651 */ > 652 if (index >= state->num_connector) { > 653 DRM_DEBUG_ATOMIC("Hot-added connector would overflow state array, restarting\n"); > 654 return ERR_PTR(-EAGAIN); > 655 } > 656 > (gdb) > > HTH > Nic -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
