Bug 150021
| Summary: | kernel panic: "kernel tried to execute NX-protected page" when resuming from hibernate to disk | ||
|---|---|---|---|
| Product: | Power Management | Reporter: | shuzzle |
| Component: | Hibernation/Suspend | Assignee: | Rafael J. Wysocki (rjw) |
| Status: | CLOSED CODE_FIX | ||
| Severity: | normal | CC: | jpoimboe, yu.c.chen |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 4.6.x | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
last working .config
git bisect result bisect.log Oops picture bisect.log to comment 11 hibernate-frame-fix.patch |
||
Created attachment 226391 [details]
git bisect result
Created attachment 226401 [details]
bisect.log
Can you please try 4.7 and see if the problem is still there and, if so, whether or not reverting commit 13523309495cdbd57a0d344c0d5d574987af007f makes it go away? I experience the same issue with linux-4.7. I reverted commit 13523309495cdbd57a0d344c0d5d574987af007f and the issue is gone. OK, thanks! From the bug subject it looks like you are able to see the panic at least. Would it be possible to capture it somehow or take a photo of it and attach that here? One more question: Do you use suspend to RAM in addition to using hibernation (suspend to disk)? Created attachment 226571 [details]
Oops picture
(In reply to Rafael J. Wysocki from comment #6) > One more question: Do you use suspend to RAM in addition to using > hibernation (suspend to disk)? With Kernel 4.7 resuming from hibernate to RAM works as expected while resuming from hibernate to disk doesn't. (In reply to shuzzle from comment #8) > (In reply to Rafael J. Wysocki from comment #6) > > One more question: Do you use suspend to RAM in addition to using > > hibernation (suspend to disk)? > > With Kernel 4.7 resuming from hibernate to RAM works as expected while > resuming from hibernate to disk doesn't. OK, thanks. To be more precise, the commit you have identified as the culprit only affects suspend to RAM. It doesn't even modify any code related to suspend to disk, so if you suspended to RAM, resumed and then attempted to suspend to disk, it might influenced things somehow, but otherwise it is hard to say what's up. So to clarify, if you boot 4.7 afresh and then suspend to disk, does the resume from it fail? In any case, please check if this patch (should apply on top of 4.7): https://patchwork.kernel.org/patch/9250263/ makes any difference for you. In case it doesn't and the CPU in your system is an Intel one, please also test this patch: https://patchwork.kernel.org/patch/9228667/ Well, this is embarassing. Since neither of both patches did fix it and the commit isn't involved in suspend to disk, I made the choice to 'bisect' again. So here's what I did: 1. 1.1 patched 4.7 kernel with both patches, but with one patch at a time though. No success. 2. 2.1. git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git linux-stable 2.2. git checkout 13523309495cdbd57a0d344c0d5d574987af007f 2.3. built the kernel which successfully resumes from suspend to disk! So I felt really bad and took another 2 hours bisecting to make sure what commit we'll really need to talk about. :( 3.1. git bisect start 3.2. git bisect bad master 3.3. Done a few kernel builds with 'git bisect good' and so on. 3.4. git tells me commit ef0f3ed5a4acfb24740480bf2e50b178724f094d fails. 4.1. git checkout master 4.2. built the kernel which fails to resume from suspend to disk 4.3. git checkout ef0f3ed5a4acfb24740480bf2e50b178724f094d 4.4. built the kernel which fails to resume from suspend to disk 4.5. git checkout ef0f3ed5a4acfb24740480bf2e50b178724f094d~ 4.6. built the kernel which SUCCESSFULLY resumes from suspend to disk So this is very embarassing to me. I am sorry for blaming the other commit. Please tell me if I can do any more to make sure it really is ef0f3ed5a4acfb24740480bf2e50b178724f094d this time. Created attachment 226651 [details] bisect.log to comment 11 (In reply to Rafael J. Wysocki from comment #9) > So to clarify, if you boot 4.7 afresh and then suspend to disk, does the > resume from it fail? Yes. It doesn't matter if or if not suspend to RAM has been used before suspend to disk. Yeah, that commit is at least directly related to suspend to disk, so that seems much more likely. Created attachment 226741 [details]
hibernate-frame-fix.patch
Could you please try and see if this patch fixes it?
(In reply to Josh Poimboeuf from comment #15) > Created attachment 226741 [details] > hibernate-frame-fix.patch > > Could you please try and see if this patch fixes it? I can confirm this patch fixes the issue I reported. Thanks. Cool! @Josh: Unless you have submitted this already, can you do that ASAP please? Closed as patch been merged: commit 4ce827b4cc58bec7952591b96cce2b28553e4d5b Author: Josh Poimboeuf <jpoimboe@redhat.com> Date: Thu Jul 28 23:15:21 2016 +0200 x86/power/64: Fix hibernation return address corruption |
Created attachment 226381 [details] last working .config Overview: When commit 13523309495cdbd57a0d344c0d5d574987af007f is applied to my kernel sources my kernel panics when trying to resume from hibernate to disk. Steps to Reproduce: 1. have a working hibernate/resume setup 2. compile 4.6.x kernel 3. boot and hibernate to disk 4. test various kernels using "git bisect". Actual Results: kernel panics when trying to resume from hibernate to disk. Expected Results: Resume from hibernate to disk like kernels without commit 13523309495cdbd57a0d344c0d5d574987af007f did. I attached my working .config of my 4.5.7 kernel. Any help will be appreciated. Thanks!