Arch Linux

Kernel panics are quite random...
I managed to get a "platform" suspend without kernel panic (first boot on the syslog with resumedelay=30). I got some
ACPI Error: Method parse/execution failed
CPI Error: [_T_0] Namespace lookup failure, AE_ALREADY_EXISTS

Then I reboot to try to reproduce that, but I get a kernel panic, this time partially logged by journald :
BUG: unable to handle kernel paging request at ffffc900175a0014
[...]
Call Trace:
[<ffffffffa05cc525>] ? rtsx_pci_card_detect+0x55/0x1d0 [rtsx_pci]
[...]

User space had enough time to wake up.

Next reboots are less interesting because kernels errors were not logged.

I have a similar issue when resuming: userspace resumes fine but soon I've got a black screen. Last time instead of the black screen, I got a kernel panic which can be seen here: http://imgur.com/f5uWFTY

I reported this to LKML: https://lkml.org/lkml/2013/11/17/21

Thanks.

Did you try version 3.11.6 ?
http://seblu.net/a/arm/week/core/os/x86_64/linux-3.11.6-1-x86_64.pkg.tar.xz

Not yet. But I'm going to install first a new archlinux system on an usb stick in order to do some testing and preserve my current system.

After that I'll try the previsous kernel and if it works, I'll try to make a git-bisect session.

I have the exact same problem as @fmoreau and went through the LKML thread (well, its archived version from http://www.gossamer-threads.com/lists/engine?do=post_view_flat;post=1817516;page=1;sb=post_latest_reply;so=ASC;mh=25;list=linux). Penultimate message (http://www.gossamer-threads.com/lists/linux/kernel/1825540#1825540) offers a patch that should work around the issue with the rtsx driver (it happens that I also have a Clevo laptop, W540EU in my case).

Question for @fmoreau : what is the temporary solution while waiting for this patch to be integrated into the kernel ? Downgrade to 3.11.6, blacklist rtsx_pci module (it appears I have two entry for a realtek device, one of unassigned class that uses the rtsx driver/module and one for the Ethernet controller using r8169), build myself a kernel integrating this patch (this would be the first time I dig into kernel compiling, so I'm not so eager to follow this solution)?
Thanks

Well, the easiest workaround is to simply unload the boggus modules (rtsx_pci_ms and memstick). In my understanding they're only used for accessing SD cards. After that suspend/resume cycles should work.

Sadly, the driver's developer doesn't seem to care about this bug. Maybe you could confirm on LKML that you're also hit by this bug, it might help to make things done.

Thanks for your quick reply, this is what I did. In my case I simply blacklisted the rtsx_pci module (the only one loaded) and suspend to RAM worked as intended. Now it resumes without a flaw, which is nice.
Joining the LKML thread and adding my use case was my first intention, but given the complexity of the procedures routinely asked there, and my likely inability to provide relevant info (the bisect thing killed me ;-)) besides my absence of knowledge of how to present the case, I preferred contacting you here/subscribing to the Arch bug. Although I saw the developper/maintainer's contact info in the output of modinfo rtsx_pci (that's Wei WANG, right?), I didn't know if emailing him was an acceptable way to further this issue...

I'm preparing a mail to the LKML thread, but what info should I include for my report to be useful?
Thanks

I think simply telling that you're also affected by this bug is enough. That might give more importance to this bug.

Most of the information needed to debug and fix it has been dig out therefore I don't think you'll be asked to provide more information.

Thanks

This should be fixed in 3.12.8 by commit named : "mfd: rtsx_pcr: Disable interrupts before cancelling delayed works"

Nice ! Thanks for all the digging, to you and kernel developers.

Thanks for your support on this issue.

Cheers.

Another thank you for your involvement and follow-up. Great news.