Message-ID: <CALGCz1pk4G3MGiWgabU=qHi9L46Pgp7zJB1TsdKTpiLpd8VgUA@mail.gmail.com>
Date:	Sat, 16 Aug 2014 02:54:35 -0700
From:	Markus Gutschke <markus@...schke.com>
To:	"Rafael J. Wysocki" <rjw@...ysocki.net>
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

I collected all the data that you asked for and attached it to the
bug: https://bugzilla.kernel.org/show_bug.cgi?id=80911

Yes, both acpidump output and the list of PNP devices changes when I
update the kernel. I was hoping to give you a brief "diff" output for
the changes; but there are too many changes for that to make much
sense. In any case, you can see it by running:

  diff -u last-good/dirtree_\!sys\!devices\!pnp0.txt
first-bad/dirtree_\!sys\!devices\!pnp0.txt

I included a README.txt that describes the contents of all the files.
I hope this makes some sense and I hope it is sufficiently complete
for you to make progress in debugging why my machine is unhappy.
Please don't hesitate to ask, if you think I can provide other data
and/or run other tests.


Markus


On Fri, Aug 15, 2014 at 5:46 PM, Rafael J. Wysocki <rjw@...ysocki.net> wrote:
> 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.

View attachment "README.txt" of type "text/plain" (1386 bytes)

Powered by blists - more mailing lists