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: <alpine.DEB.2.20.1707281734240.1828@nanos>
Date:   Fri, 28 Jul 2017 18:26:15 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Tomi Sarvela <tomi.p.sarvela@...el.com>
cc:     Martin Peres <martin.peres@...ux.intel.com>,
        jeffy.chen@...k-chips.com, linux-kernel@...r.kernel.org
Subject: Re: Suspend-resume failure on Intel Eagle Lake Core2Duo

On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> On 28/07/17 17:50, Thomas Gleixner wrote:
> > On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> > > On 28/07/17 17:13, Thomas Gleixner wrote:
> > > > On Fri, 28 Jul 2017, Tomi Sarvela wrote:
> > > > > On 28/07/17 16:15, Thomas Gleixner wrote:
> > > > > > Another question. Is the machine completely dead or not?
> > > > > 
> > > > > Completely dead. Powerled is on, so host isn't shut down.
> > > > 
> > > > So that means it does not even power the machine down. That's what I
> > > > expected least.
> > > > 
> > > > > Serial or network if don't give any signs of life.
> > > > 
> > > > > Patch applies cleanly but still getting the same error:
> > > > 
> > > > Sorry for the noise. I'm an idiot trying to do 10 things at once. This
> > > > time
> > > > it actually compiles and links.
> > > > 
> > > > If the machine does still not powerdown with this applied, then please
> > > > redo
> > > > the 'platform' test and grab the trace for that one.
> > > 
> > > This patch fixes the issue. Below is the dmesg from the testrun (sorry for
> > > the spam, we're primarily testing i915 issues).
> > 
> > Can you please retrieve the trace data from:
> > 
> > /sys/kernel/debug/tracing/trace
> > 
> > and provide that. The dmesg does not help much.
> 
> Right, here you go.

Thanks for providing the data. Just to be sure, that data was from a real
suspend, not the 'platform' test, right?

If so, that does not make any sense at all. The patch merily changes the
enable/resume path and adds the debug trace printks which have no influence
on the disable logic. But you said that the machine does not power off in
the bad case. That does not make any sense at all as the enable logic is
not involved at all in the suspend path.

Did you change anything else compared to the tests before ?

Thanks,

	tglx


Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ