Can you try blacklisting mei and mei-me and see if that helps? If it does, we might blacklist those two modules by default.

Blacklisting mei-me fixed the crashes on 3.10.5

As of yesterday, I upgraded to 3.10.7 and re-enabled mei-me. So far this is going well. I checked syslog and it's clean, the mei-me errors that flooded syslog with millions of lines on 3.10.5 are gone now.

Anyone knows the purpose of mei/mei-me modules? this desktop worked very smoothly without them :D

Another driver from Intel: http://lwn.net/Articles/440292/

Still Here
 

On a fresh install of current (Sat Aug 17 03:30:00 UTC 2013) immediately upon resume from S3 I still get the mei-me flood to /var/log/syslog.
Blacklisting the two modules eliminates the problem, however from lspci my machine has the chip for mei
On a brighter note, Now current with 3.10.7 properly enumerates all my external USB devices in dmesg
I will be testing current further as time goes by.
John

Clean syslog and no crashes so far, marking as solved.

unfortunately I encountered a crash with the 3.10.7 kernel :(

I can also confirm kernel crash even with Linux 3.10.7 . Sometimes attempt to suspend/hibernate only kills X server followed by an immediate resume without any message in syslog that would describe the issue.

I guess I posted too soon, just had the first 3.10.7 crash on this machine with the now familiar mei-me message flood in syslog, blacklisting this module again.

I see greg has just put out a 3.10.8 rapidly followed by a 3.10.9.

A quick grep -i mei-me shows nothing in either changelog.
So my guess is I'm still waiting for a fix. Fortunately PV's recommendation to blacklist the mei-me module is a good temporary fix. I will still give the 3.10.9 a try.
john

Hi volkerdi, sorry for the late response. Just tried blacklisting the modules and even modprobe -r them immediately to do a quick suspend, it seems to work as I'm typing this response upon resume (actually I did this a couple of times to confirm) :D Thanks!

Yep. I guess it all depends on whether the mei--me code is the primary cause of the fault, or just a secondary victim of another bug elsewhere in the kernel. Having had a quick read through the Changelog there look to be a number of important fixes in this batch, so worth having all the same.

Yes I gave 3.10.9 a try.
Hope springs eternal.
But no cigar.
Failed after first resume from S3 with the mei-me flood
john

Looks like mei/mei-me are gone as of the latest slackware-current updates (Aug. 21 --> 3.10.9)

Your right it is gone for Slackware.
The bug is not fixed. What PV has done is no longer build the module in his .config i.e.
which works for me as I already had it blacklisted. For now probably the best workaround unless the module is needed for something. I still don't know what it is used for even though my i5 lists it under lspci
john