[<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