linux-kernel - Re: Linux 3.10-rc7

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]

Message-ID: <20130625125437.6e7bb2d4@jbarnes-desktop>
Date:	Tue, 25 Jun 2013 12:54:37 -0700
From:	Jesse Barnes <jbarnes@...tuousgeek.org>
To:	Daniel Vetter <daniel.vetter@...ll.ch>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Shuah Khan <shuah.kh@...sung.com>,
	Chris Wilson <chris@...is-wilson.co.uk>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	"shuahkhan@...il.com" <shuahkhan@...il.com>,
	Dave Airlie <airlied@...hat.com>,
	intel-gfx <intel-gfx@...ts.freedesktop.org>
Subject: Re: Linux 3.10-rc7

On Tue, 25 Jun 2013 21:37:37 +0200
Daniel Vetter <daniel.vetter@...ll.ch> wrote:

> On Tue, Jun 25, 2013 at 9:05 PM, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> > Adding the appropriate cc'd.. I'm not seeing why this would start
> > happening now, but there's been a number of commits that touch the
> > intel crtc 'active' state and hotplug logic, so I'm assuming one of
> > them is to blame.. Lots of small changes around
> > ironlake_crtc_mode_set() etc.
> >
> > This warning seems to imply that the pll activity count is buggered.
> > Anybody? Chris/Daniel/Dave?
> 
> Hm, looks like a new one. On a quick guess it's an ugly interaction
> between the new state restore code we've added for vt-switchless
> resume in 3.10 and the lack of proper pch pll refcount reconstruction
> when taking over foreign state. I'm thinking of
> 1) hibernate to disk with every crtc switched off
> 2) after power cycle boot into the loader kernel with crtc enables
> 3) restore the hibernated kernel image
> 4) restored kernel reads out current hw state and restores the old
> state by disabling everything
> 5) we hit the WARN(!pll->active) and also the follow-up assert since
> the hw pch pll is indeed on (it's driving the crtc we're disabling
> after all), but our state reconstruction failed to track this
> properly.
> 
> Dunno on a quick guess what to do this late in the -rc to duct-tape
> this WARN away, since we should at least try to shut down the pch pll
> (which we currently won't do). For 3.11 I've completely revamped the
> pch pll code with massively increased paranoia and much better
> tracking of the hw state. It's not all merged yet (some will probably
> miss 3.11), but the refcounting part is all in -next.
> 
> So I think the first step would be to test latest linux-next (or the
> drm-intel-nightly branch from
> http://cgit.freedesktop.org/~danvet/drm-intel/ if you just want the
> drm parts on top of a recent -rc). Also it'd be good to corrobate my
> guess of what's going on with a dmesg with drm debugging enabled
> (drm.debug=0xe).
> 
> Adding more lists to cc + Jesse since he's the guilty one for the
> vt-switchless state restore stuff.

Yeah, looks like we don't fetch the PLL state on resume from hibernate,
leading to this warning.  The refcount is nonzero, indicating the pll
is in use, but the active field is clear, which means we're missing an
update somewhere.

Shuah, just to confirm, does your resume actually work ok aside from
the warning?  I *think* it's harmless in this case, but does indicate a
real bug in our state tracking... trying to come up with a patch now.

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center
--
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/