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 majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
