Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1727884 > unrolled thread

[PATCH 0/2] Fix resume failure due to PCID

Started byAndy Lutomirski <luto@kernel.org>
First post2017-09-07 05:00 +0200
Last post2017-09-07 11:00 +0200
Articles 4 — 4 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH 0/2] Fix resume failure due to PCID Andy Lutomirski <luto@kernel.org> - 2017-09-07 05:00 +0200
    Re: [PATCH 0/2] Fix resume failure due to PCID Linus Torvalds <torvalds@linux-foundation.org> - 2017-09-07 05:30 +0200
      Re: [PATCH 0/2] Fix resume failure due to PCID Andy Lutomirski <luto@amacapital.net> - 2017-09-07 06:20 +0200
    Re: [PATCH 0/2] Fix resume failure due to PCID Borislav Petkov <bp@suse.de> - 2017-09-07 11:00 +0200

#1727884 — [PATCH 0/2] Fix resume failure due to PCID

FromAndy Lutomirski <luto@kernel.org>
Date2017-09-07 05:00 +0200
Subject[PATCH 0/2] Fix resume failure due to PCID
Message-ID<umVcR-29h-5@gated-at.bofh.it>
Patch 1 is the fix.  Patch 2 is a comment that would have kept me from
chasing down a false lead.

I've tested patch 2 using CPU hotplug and suspend/resume.  I haven't
tested hibernation or kexec because I don't know how.  (If I do
systemctl hibernate on my laptop, it happily writes out a hiberation
image somewhere and then it equally happily ignores it on the next
boot.  I don't know how to test kexec.)

I haven't tested the 32-bit version.  I'll try to get to that
tomorrow.

Andy Lutomirski (2):
  x86/mm: Reinitialize TLB state on hotplug and resume
  x86/mm: Document how CR4.PCIDE restore works

 arch/x86/include/asm/tlbflush.h |  2 ++
 arch/x86/kernel/cpu/common.c    | 15 ++++++++++++++
 arch/x86/mm/tlb.c               | 44 +++++++++++++++++++++++++++++++++++++++++
 arch/x86/power/cpu.c            |  1 +
 4 files changed, 62 insertions(+)

-- 
2.13.5

[toc] | [next] | [standalone]


#1727895

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2017-09-07 05:30 +0200
Message-ID<umVFT-2AG-3@gated-at.bofh.it>
In reply to#1727884
On Wed, Sep 6, 2017 at 7:54 PM, Andy Lutomirski <luto@kernel.org> wrote:
> Patch 1 is the fix.  Patch 2 is a comment that would have kept me from
> chasing down a false lead.

Yes, this seems to fix things for me. Thanks.

Of course, right now that laptop has no working wifi with tip-of-tree
due to some issues with the networking tree, but that's an independent
thing and I could suspend and resume with this. So applied and pushed
out,

                Linus

[toc] | [prev] | [next] | [standalone]


#1727898

FromAndy Lutomirski <luto@amacapital.net>
Date2017-09-07 06:20 +0200
Message-ID<umWsh-35p-9@gated-at.bofh.it>
In reply to#1727895

> On Sep 6, 2017, at 8:25 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote:
> 
>> On Wed, Sep 6, 2017 at 7:54 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> Patch 1 is the fix.  Patch 2 is a comment that would have kept me from
>> chasing down a false lead.
> 
> Yes, this seems to fix things for me. Thanks.
> 
> Of course, right now that laptop has no working wifi with tip-of-tree
> due to some issues with the networking tree, but that's an independent
> thing and I could suspend and resume with this. So applied and pushed
> out,
> 
>                Linus


Great!

FWIW, there's still a possible glitch where doing EFI calls could corrupt ASID 0.  I figured that fixing that could wait for tomorrow.

[toc] | [prev] | [next] | [standalone]


#1728046

FromBorislav Petkov <bp@suse.de>
Date2017-09-07 11:00 +0200
Message-ID<un0Pg-61N-13@gated-at.bofh.it>
In reply to#1727884
On Wed, Sep 06, 2017 at 07:54:52PM -0700, Andy Lutomirski wrote:
> Patch 1 is the fix.  Patch 2 is a comment that would have kept me from
> chasing down a false lead.
> 
> I've tested patch 2 using CPU hotplug and suspend/resume.  I haven't
> tested hibernation or kexec because I don't know how.  (If I do
> systemctl hibernate on my laptop, it happily writes out a hiberation
> image somewhere and then it equally happily ignores it on the next
> boot.

Do you have this in cmdline?

        resume=         [SWSUSP]
                        Specify the partition device for software suspend
                        Format:
                        {/dev/<dev> | PARTUUID=<uuid> | <int>:<int> | <hex>}



> I don't know how to test kexec.)

You boot with something like this:

crashkernel=512M-2G:128M,2G-64G:256M,64G-:512M

Check dmesg to see whether it managed to reserve memory. Then you do:

# kexec --noefi -l bzImage --initrd=initrd.img --reuse-cmdline

# kexec -e

That last one loads it.

Anyway, something like that. I have this in my notes saying it worked at
some point.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web