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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1407206650.10148.28.camel@rzhang1-toshiba>
Date:	Tue, 05 Aug 2014 10:44:10 +0800
From:	Zhang Rui <rui.zhang@...el.com>
To:	markus@...schke.com
Cc:	Pavel Machek <pavel@....cz>, linux-kernel@...r.kernel.org,
	"Rafael J. Wysocki" <rafael.j.wysocki@...el.com>,
	Mika Westerberg <mika.westerberg@...ux.intel.com>
Subject: Re: 3.16-rcX crashes on resume from Suspend-To-RAM

Hi, Markus,

On Mon, 2014-08-04 at 09:06 -0700, Markus Gutschke wrote:
> Thanks for checking in. And no, I have not heard from Zhang since my
> last e-mail. I suspect he is still working on finding a solution.

Yes, I was trying to find out what differences commit
b04c58b1ed26317bfb4b33d3a2d16377fc6acd0f brings, and why it breaks
suspend. But so far, I didn't make any progress. Thus I do need your
help to do more test.

>  But
> you are of course right, reverting the patch in the meantime might be
> a good idea. I would love to be able to suspend my laptop again. But I
> defer to Zhang for the final decision. As long as it gets fixed
> eventually, I can personally live with a few weeks of delay while
> things get worked out. And of course, as offered before, I'll run
> whatever tests Zhang asks me to do.
> 
Great. Thanks for your help, please
1. make sure your kernel is built with CONFIG_PM_DEBUG and
CONFIG_PM_TRACE_RTC set.
2. in b04c58b1ed26317bfb4b33d3a2d16377fc6acd0f kernel, try "echo devices
> /sys/power/pm_test && echo mem > /sys/power/states", and wait for 10
seconds and see if the system can be resumed automatically.
3. if the test fails, please try a normal suspend, and reboot the kernel
ASAP after the hang, better in one minute, and then attach the dmesg
output after boot. Hopefully, we can find out which driver breaks your
machine by the suspend/resume trace feature. 

thanks,
rui

> Markus
> 
> On Mon, Aug 4, 2014 at 7:16 AM, Pavel Machek <pavel@....cz> wrote:
> > On Sat 2014-07-26 08:52:34, Markus Gutschke wrote:
> >> Sorry for the delay. Remotely debugging kernels over a shared and
> >> flaky 1MBps terrestrial wireless connection is quite a new experience
> >> to me.
> >>
> >> In any case, I was able to collect all the data that you asked for. I
> >> then used "pm-suspend" to put the machine to sleep and asked a helper
> >> to physically press the power button to wake the computer back up. My
> >> helper told me that it crashed just as before, and they had to
> >> power-cycle the machine to bring it back to life.
> >>
> >> Please let me know, what other data I can get for you. And thank you
> >> very much for putting up with my slow turn-around. I should have much
> >> better response time again in about two to three weeks when I return
> >> to civilization.
> >
> > Was this solved, somehow?
> >
> > If not, can we revert the patch that causes it?
> >                                                                 Pavel
> >
> > --
> > (english) http://www.livejournal.com/~pavelmachek
> > (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


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