Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ] - dri-devel - freedesktop.org experimental mailing list

25 Jul 2013


      On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek sedat.dilek@gmail.com wrote:
...
On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter daniel@ffwll.ch wrote:
...
On Thu, Jul 25, 2013 at 04:23:40PM +0200, Sedat Dilek wrote:
...
On Thu, Jul 25, 2013 at 3:36 PM, Daniel Vetter daniel@ffwll.ch wrote:
...
On Thu, Jul 25, 2013 at 12:37:44PM +0200, Sedat Dilek wrote:
...
On Thu, Jul 25, 2013 at 12:21 PM, Jani Nikula
jani.nikula@linux.intel.com wrote:
...
On Thu, 25 Jul 2013, Sedat Dilek sedat.dilek@gmail.com wrote:
> On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek sedat.dilek@gmail.com wrote:
>> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
>> jani.nikula@linux.intel.com wrote:
>>> On Thu, 25 Jul 2013, Sedat Dilek sedat.dilek@gmail.com wrote:
>>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell sfr@canb.auug.org.au wrote:
>>>>> Hi all,
>>>>>
>>>>> Changes since 20130724:
>>>>>
>>>>> Removed tree:
>>>>>         arm-dt (at maintainer's request)
>>>>>
>>>>> The wireless-next tree lost its build failure and gained a conflict
>>>>> against Linus' tree.
>>>>>
>>>>> The tty tree lost its build failure.
>>>>>
>>>>> The staging tree gained a build failure for which I disabled a driver.
>>>>>
>>>>> ----------------------------------------------------------------------------
>>>>>
>>>>
>>>> [ CCing drm and drm-intel folks ]
>>>>
>>>> With today's next-20130725 I see the following:
>>>
>>> Use of dev_priv->gt_lock in I915_WRITE through
>>> intel_disable_gt_powersave before spin lock init, caused by
>>>
>>> commit 181d1b9e31c668259d3798c521672afb8edd355c
>>> Author: Daniel Vetter daniel.vetter@ffwll.ch
>>> Date:   Sun Jul 21 13:16:24 2013 +0200
>>>
>>>     drm/i915: fix up gt init sequence fallout
>>>
>>
>> Ah, cool.
>>
>> I assumed/tested "drm/i915: fix the racy object accounting", but this
>> does not fix it.
>> Will try with yours.
>>
>
> Sorry, Jani.
>
> next-20130725 ships the patch you pointed, too.
Confused. I meant that the above mentioned commit "drm/i915: fix up gt
init sequence fallout" causes the problem. The patch I included in my
mail should fix it. Could you try that please?
[ Note2myself: Do not read half of the message... ]
The bad... Your patch needed some refresh against next-20130725 (guess
it's against drm-intel-nightly).
The good... YES, your patch fixes the issue for me!
The ugly... /me.
Feel free to add my:
   Tested-by: Sedat Dilek <sedat.dilek@gmail.com>


Thanks for the quick fix!
Thanks a lot for the report, since this should be something I should have
caught. And for added insult the offending patch is already in Linus' tree
:( Patch merged to -fixes.
Hmmm, don't you merge -fixes into -nightly?
I do, but it seems to only blow up with spinlock debugging enabling I
think. Our QA should run full debug buils in the -nightly testing, but
apparently they didn't catch this. I'm looking into what went wrong here
and fix up the process.
First, I thought I made my merge wrong, but there is no
$ grep spin_lock_init linux-next/drivers/gpu/drm/i915/i915_dma.c | grep gt_lock
Same in [1]:
...
        spin_lock_init(&dev_priv->irq_lock);
        spin_lock_init(&dev_priv->gpu_error.lock);
        spin_lock_init(&dev_priv->backlight.lock);
        spin_lock_init(&dev_priv->uncore.lock);
It's hiding in plain sight here ;-) -next has it renamed to
uncore.lock, so I've applied the patch to -fixes only. I've also
changed the patch in -fixes to cause an explicit conflict here, makes
merging a bit easier.
-Daniel
...
    spin_lock_init(&dev_priv->mm.object_stat_lock);

...

Sedat -

[1] http://cgit.freedesktop.org/~danvet/drm-intel/tree/drivers/gpu/drm/i915/i915...
...
-Daniel
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch