Messages in this thread | | | Date | Thu, 21 Nov 2013 09:22:02 +0100 | From | Francis Moreau <> | Subject | Re: 3.12: kernel panic when resuming from suspend to RAM (x86_64) |
| |
On 11/20/2013 12:15 PM, Borislav Petkov wrote: > 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: > [...] > > 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.
Hmm, I think it's more than that because if I'm removing both rtsx_pci_ms and memstick modules, then suspending and resuming doesn't oops anymore.
Also I took a look at the changes between v3.11 and v3.12 in this area and those changes match the issue I'm facing:
$ git log --oneline v3.11..v3.12 -- drivers/mfd/rtsx_pcr.c 09fd867 mfd: rtsx: Copyright modifications eb891c6 mfd: rtsx: Configure to enter a deeper power-saving mode in S3 7140812 mfd: rtsx: Move some actions from rtsx_pci_init_hw to individual extra_init_hw 5947c16 mfd: rtsx: Add shutdown callback in rtsx_pci_driver 773ccdf mfd: rtsx: Read vendor setting from config space
I'll try to bisect one more time those changes tonight to see if I can find out if one of those commits is the culprit.
> > 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." >
Sorry for not answering the first time, but yes my bios is uptodate.
Thanks.
| |