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

[Sedat Dilek <sedat.dilek@gmail.com>]

On Thu, Jul 25, 2013 at 5:05 PM, Daniel Vetter <daniel.vetter@ffwll.ch> wrote:
> 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.

Ah, I see... "drm/i915: Colocate all GT access routines in the same file"

@@ -1493,7 +1477,7 @@ int i915_driver_load(struct drm_device *dev,
unsigned long flags)
...
- spin_lock_init(&dev_priv->gt_lock);
+ spin_lock_init(&dev_priv->uncore.lock);
...

- Sedat -

http://cgit.freedesktop.org/~danvet/drm-intel/commit/drivers/gpu/drm/i915/i915_dma.c?h=drm-intel-nightly&id=907b28c56ea40629aa6595ddfa414ec2fc7da41c

> -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