lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Thu, 25 Jul 2013 17:03:02 +0200
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Sedat Dilek <sedat.dilek@...il.com>,
	Jani Nikula <jani.nikula@...ux.intel.com>,
	Stephen Rothwell <sfr@...b.auug.org.au>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>,
	linux-kernel@...r.kernel.org,
	DRI <dri-devel@...ts.freedesktop.org>, linux-next@...r.kernel.org
Cc:	Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [Intel-gfx] linux-next: Tree for Jul 25 [ call-trace: drm |
 drm-intel related? ]

On Thu, Jul 25, 2013 at 4:27 PM, Daniel Vetter <daniel@...ll.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@...ll.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@...ux.intel.com> wrote:
>> >> > On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek@...il.com> wrote:
>> >> >> On Thu, Jul 25, 2013 at 12:02 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
>> >> >>> On Thu, Jul 25, 2013 at 11:44 AM, Jani Nikula
>> >> >>> <jani.nikula@...ux.intel.com> wrote:
>> >> >>>> On Thu, 25 Jul 2013, Sedat Dilek <sedat.dilek@...il.com> wrote:
>> >> >>>>> On Thu, Jul 25, 2013 at 7:12 AM, Stephen Rothwell <sfr@...b.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@...ll.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@...il.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);
	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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ