On Thu, Jul 25, 2013 at 5:34 PM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
> On Thu, Jul 25, 2013 at 5:05 PM, Daniel Vetter <daniel.vetter@xxxxxxxx> wrote:
>> On Thu, Jul 25, 2013 at 5:03 PM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>>> On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter <daniel@xxxxxxxx> 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@xxxxxxxx> 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@xxxxxxxxxxxxxxx> wrote:
>>>>> >> > On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>>>>> >> >> On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>>>>> >> >>> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
>>>>> >> >>> <jani.nikula@xxxxxxxxxxxxxxx> wrote:
>>>>> >> >>>> On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote:
>>>>> >> >>>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell <sfr@xxxxxxxxxxxxxxxx> 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@xxxxxxxx>
>>>>> >> >>>> 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@xxxxxxxxx>
>>>>> >>
>>>>> >> 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);
> ...
>
Might be OT, but I cannot use my X graphics stack containing
libdrm-2.4.46, mesa-9.1.5 and intel-ddx 2.21.12-git (tried also
v2.21.11).
Switching back to the one from Ubuntu/precise lets my X start.
[ 40.379] (II) AIGLX: enabled GLX_MESA_copy_sub_buffer
[ 40.379] (II) AIGLX: enabled GLX_INTEL_swap_event
[ 40.380] (II) AIGLX: enabled GLX_SGI_swap_control and GLX_MESA_swap_control
[ 40.380] (II) AIGLX: GLX_EXT_texture_from_pixmap backed by buffer objects
[ 40.380] (II) AIGLX: Loaded and initialized i965
[ 40.380] (II) GLX: Initialized DRI2 GL provider for screen 0
[ 40.380]
Fatal server error:
[ 40.380] failed to create screen resources
[ 40.380]
Please consult the The X.Org Foundation support
at http://wiki.x.org
for help.
[ 40.380] Please also check the log file at "/var/log/Xorg.0.log"
for additional information.
[ 40.380]
[ 40.380] (II) AIGLX: Suspending AIGLX clients for VT switch
[ 40.396] ddxSigGiveUp: Closing log
[ 40.398] Server terminated with error (1). Closing log file.
- Sedat -
> - 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
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
