[Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm | drm-intel related? ]

Daniel Vetter daniel.vetter at ffwll.ch
Thu Jul 25 08:05:15 PDT 2013


On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
> On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter <daniel at 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 at 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 at linux.intel.com> wrote:
>>> >> > On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>>> >> >> On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>>> >> >>> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
>>> >> >>> <jani.nikula at linux.intel.com> wrote:
>>> >> >>>> On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek at gmail.com> wrote:
>>> >> >>>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell <sfr at 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 at 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 at 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_dma.c?h=drm-intel-nightly#n1477
>
>
>> -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


More information about the dri-devel mailing list