linux-kernel - Re: 3.16-rcX crashes on resume from Suspend-To-RAM

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: <1558893.86R7jAYGB3@vostro.rjw.lan>
Date:	Sat, 16 Aug 2014 02:46:39 +0200
From:	"Rafael J. Wysocki" <rjw@...ysocki.net>
To:	markus@...schke.com
Cc:	Zhang Rui <rui.zhang@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>,
	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org
Subject: Re: 3.16-rcX crashes on resume from Suspend-To-RAM

On Friday, August 15, 2014 10:17:42 AM Markus Gutschke wrote:
> Just wondering if any of you had any other ideas of what I could try
> to help debug this problem?

My theory is that there is a device in your system that we don't have a driver
for, but it had been enumerated as a PNP device before the change that triggered
the problem for you and we turned it off during suspend as part of the default
ACPI PNP device handling.

The reason why you're seeing a crash with the "platform" test level is most
likely that the _WAK control method does something unusual on your system.

The LNXSYBUS:00 thing from dmesg probably is a red herring.

I need the output of acpidump from the affected system, but please attach it
to the bug entry at https://bugzilla.kernel.org/show_bug.cgi?id=80911 that
Rui has created for this issue.

Also please check the list of PNP devices under

/sys/bus/pnp/devices/

before and after the commit you have found by bisection and let me know if
there are any differences.


> On Tue, Aug 12, 2014 at 9:11 AM, Markus Gutschke <markus@...schke.com> wrote:
> > As I said earlier in this thread, echo'ing "devices" into "pm_test"
> > does not result in a crash; but doing so for "platform" does.
> >
> > Markus
> >
> > On Aug 12, 2014 1:26 AM, "Zhang Rui" <rui.zhang@...el.com> wrote:
> >>
> >> On Sat, 2014-08-09 at 03:14 -0700, Markus Gutschke wrote:
> >> > I am back and have physical access to the machine now.
> >> >
> >> great!
> >>
> >> > I re-ran the test just to be sure, and I can confirm that "platform"
> >> > does in fact result in a crash.
> >> >
> >> what about "devices"?
> >> I mean
> >>
> >> # echo devices > /sys/power/pm_test
> >>
> >> and see if that triggers the crash.
> >>
> >> > Furthermore, I ran the test that Rui asked for. I suspended, resumed,
> >> > and upon crashing power-cycled the machine ASAP. "dmesg" suggests that
> >> > the problem is with LNXSYBUS:00 That doesn't tell me much, but
> >> > hopefully it makes sense to you guys.
> >> >
> >> [    0.930093]   Magic number: 10:810:122
> >> [    0.930185] acpi LNXSYBUS:00: hash matches
> >>
> >> This looks weird, ACPI will do nothing for LNXSYBUS devices during
> >> resume.
> >> Rafael, any thought on this?
> >>
> >> thanks,
> >> rui
> >>

-- 
I speak only for myself.
Rafael J. Wysocki, 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/