Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64)

From: Borislav Petkov
Date: Wed Nov 20 2013 - 06:15:53 EST


On Wed, Nov 20, 2013 at 10:45:05AM +0100, Francis Moreau wrote:
> Unfortunately the bisect session didn't give any positive results: I
> couldn't be sure if a specific revision was good or bad because the
> bug wasn't reproductible every time.
>
> But I got a different kernel oops on my stripped system that may give
> us a clue: http://imgur.com/zdCknbY
>
> Does this help ?

Unfortunately, this is the second oops:

"Oops: 0000 [#2] ..."

The first has scrolled off but I can see the RIP: ioread32+0x40 and the
code must be:

ffffffff812a1e40 <ioread32>:
ffffffff812a1e40: 48 81 ff ff ff 03 00 cmp $0x3ffff,%rdi
ffffffff812a1e47: 77 37 ja ffffffff812a1e80 <ioread32+0x40>

...

ffffffff812a1e77: 66 0f 1f 84 00 00 00 nopw 0x0(%rax,%rax,1)
ffffffff812a1e7e: 00 00
ffffffff812a1e80: 8b 07 mov (%rdi),%eax <--- faulting insn
ffffffff812a1e82: c3 retq
ffffffff812a1e83: 66 66 66 66 2e 0f 1f data32 data32 data32 nopw %cs:0x0(%rax,%rax,1)
ffffffff812a1e8a: 84 00 00 00 00 00

and judging by the instruction, that's addr in %rdi which we try to read
and I'd guess %rdi contains garbage after resume.

IOW, this looks like another corruption that happens when you suspend to
ram.

I asked you already but you didn't say:

"Also, you can check for BIOS updates for your machine and if there are,
check their changelogs whether they fix something suspend-related."

--
Regards/Gruss,
Boris.

Sent from a fat crate under my desk. Formatting is fine.
--
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/