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: <20151125151100.GA31492@ulmo.nvidia.com>
Date:	Wed, 25 Nov 2015 16:11:00 +0100
From:	Thierry Reding <thierry.reding@...il.com>
To:	Tyler Baker <tyler.baker@...aro.org>
Cc:	Jon Hunter <jonathanh@...dia.com>,
	Peter De Schrijver <pdeschrijver@...dia.com>,
	Prashant Gaikwad <pgaikwad@...dia.com>,
	Michael Turquette <mturquette@...libre.com>,
	Stephen Boyd <sboyd@...eaurora.org>,
	Stephen Warren <swarren@...dotorg.org>,
	Alexandre Courbot <gnurou@...il.com>,
	linux-clk@...r.kernel.org, linux-tegra@...r.kernel.org,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Rhyland Klein <rklein@...dia.com>,
	Kevin's boot bot <khilman@...nel.org>
Subject: Re: [PATCH] clk: tegra: Fix bypassing of PLLs

On Mon, Nov 23, 2015 at 03:18:59PM -0800, Tyler Baker wrote:
> Hi Jon,
> 
> On 20 November 2015 at 07:11, Jon Hunter <jonathanh@...dia.com> wrote:
> > The _clk_disable_pll() function will attempt to place a PLL into bypass
> > if the TEGRA_PLL_BYPASS is specified for the PLL and then disable the PLL
> > by clearing the enable bit. To place the PLL into bypass, the bypass bit
> > needs to be set and not cleared. Fix this by setting the bypass bit and
> > not clearing it.
> >
> > Signed-off-by: Jon Hunter <jonathanh@...dia.com>
> 
> The kernelci.org bot recently detected a jetson-tk1 boot failure[1][2]
> in the tegra tree. This boot failure has only been observed when
> booting with a multi_v7_defconfig kernel variant. The bot bisected[3]
> this boot failure to this commit, and I confirmed reverting it on top
> of the tegra for-next branch resolves the issue. The ramdisk[4] used
> for booting is loaded with the modules from the build. It appears to
> me that as the modules are being loaded in userspace by eudev the
> jetson-tk1 locks up. I've sifted through the console logs a bit, and
> found this splat to be most interesting[5].  Can you confirm this
> issue on your end?

Just to close the loop on this: we've discussed this on IRC and came to
the conclusion that not using the bypass mode is safer (switching into
and out of bypass can glitch). I've dropped this patch for now and Jon
will be looking into a second revision of the patch which, in addition
to fixing bypass (the fix is legit, it just happens to break because of
the glitch, most likely), will also remove the BYPASS flag setting so
that bypass will not be used.

Thierry

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ