George Dunlap: > On Fri, May 18, 2018 at 5:19 PM, Marek Marczykowski > <marma...@invisiblethingslab.com> wrote: >> On Fri, May 18, 2018 at 09:54:37AM -0600, Jan Beulich wrote: >>>>>> On 18.05.18 at 17:33, <marma...@invisiblethingslab.com> wrote: >>>> Yes, I'm happy to help with that. As I've said, the basic test is very >>>> simple (rtcwake command) and already very useful. The fact that it is(?) >>>> broken on staging doesn't make it easier, >>> >>> Details on the breakage would be appreciated (on a separate thread), >>> unless you plan to address it yourself. I recall Simon(?) mentioning this as >>> well, but also not providing sufficient data to consider looking into it >>> (perhaps simply because it wasn't easy to obtain useful data, as >>> frequently is the case with S3 resume). I think it would be nice if we could >>> release 4.11 without a regression here. >> >> I only know that Simon have tested it and it fails. Cc'ing him.
I run into the same problem as George below (see [1] for the inital report). > Well I tried it with a post-RC 4.11 and got the below. I haven't done > any investigation. > > -George > [...] > (XEN) *** DOUBLE FAULT *** > (XEN) ----[ Xen-4.11-rc x86_64 debug=y Not tainted ]---- > (XEN) CPU: 0 > (XEN) RIP: e008:[<ffff82d080377944>] handle_exception+0x9c/0xf7 > (XEN) RFLAGS: 0000000000010006 CONTEXT: hypervisor > (XEN) rax: ffffc900422480b8 rbx: 0000000000000000 rcx: 0000000000000005 > (XEN) rdx: 0000000000000000 rsi: 0000000000000000 rdi: 0000000000000000 > (XEN) rbp: 000036ffbddb7f27 rsp: ffffc90042248000 r8: 0000000000000000 > (XEN) r9: 0000000000000000 r10: 0000000000000000 r11: 0000000000000000 > (XEN) r12: 0000000000000000 r13: 0000000000000000 r14: ffffc9004224ffff > (XEN) r15: 0000000000000000 cr0: 000000008005003b cr4: 00000000000026e0 > (XEN) cr3: 000000018a100000 cr2: ffffc90042247ff8 > (XEN) fsb: 00007f6242d95700 gsb: ffff88003dc00000 gss: 0000000000000000 > (XEN) ds: 0000 es: 0000 fs: 0000 gs: 0000 ss: e010 cs: e008 > (XEN) Current stack base ffffc90042248000 differs from expected > ffff8300dfa80000 > (XEN) Valid stack range: ffffc9004224e000-ffffc90042250000, > sp=ffffc90042248000, tss.rsp0=ffff8300dfa87fa0 > (XEN) No stack overflow detected. Skipping stack trace. > (XEN) > (XEN) **************************************** > (XEN) Panic on CPU 0: > (XEN) DOUBLE FAULT -- system shutdown > (XEN) **************************************** > (XEN) > (XEN) Reboot in five seconds... I have done some more testing in the meantime. The issue also affect 4.10.1, but not 4.10.0. That's useful since it makes the bisect shorter. A bisect identifies 8462c575d9 "x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings" as the commit which breaks suspend. 8462c575d9 is a squashed backport of: 422588e885 x86/xpti: Hide almost all of .text and all .data/.rodata/.bss mappings d1d6fc97d6 x86/xpti: really hide almost all of Xen image 044fedfaa2 x86/traps: Put idt_table[] back into .bss And indeed, reverting those on staging fixes suspend. (This also matches the behavior that xpti=off fixes suspend as George already reported earlier today). [1]: https://lists.xenproject.org/archives/html/xen-devel/2018-04/msg01137.html
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
