3.10.5 kernel unstable?
 

Been running Slackware current on this desktop with different kernels, all very stable. I upgraded to the stock 3.10.5 kernel (Aug. 7) then applied the Aug. 8 updates. The system had a complete crash a few hours ago, out of the blue, while I was reading a webpage (only Firefox, Konqueror and Konsole were loaded).

I think this is the first time I've ever seen a total crash on Linux, don't know if it's the latest kernel or a combination of other factors, all I could do was take a snapshot of the screen and do a hard reboot.

This happens for me also, on a Dell Inspiron 5110. It would help if your image would be a bit more clear, but the last line suggests (drm_kms_helper) that it has something to do with the DRM interface. The same goes for my laptop.

It crashes when playing YouTube videos, and suspend to ram also got broken, it just flashes the caps-lock key, and blanks the screen.
How ironic the Slackware changelog for the update:
"Looks like 3.10.x got LTS status, but more importantly fixes the power issue on resume with some Intel machines.".

I'd suggest to temporarily disable/remove all non-stock kernel modules like virtualbox's or graphics adapter's and try if it would cause better stability. If you are running machine with an integrated Intel GA using the messy i915 driver you are probably out of luck as there were wild changes in recent past fixing various longstanding issues but bringing new ones. Some of the crap is fixed in 3.11.x but diffs cann't be applied to 3.10.x and devs are currently too busy/lazy/incompetent to backport them :(

Hey dunric, thanks for the tips. I'll try to remove the vbox drivers, and see if that makes any difference. Also, I've tested 3.11-rc4, but it also panics with the same symptoms.
I've managed to take a picture of the panic, too.

Same problem here!
I finally got it fixed by blacklisting module 'mei-me'
Can't take credit as I got the recommendation from fearless leader PV
Of course the configuration of the kernel must include
built as modules so's we can blacklist them.
Hope that helps
John

Sorry! Should have included that my problem also include a flood of the lines below in syslog. However the last line of my and your kernel dump are identical.

The blacklisting doesn't solve the intermittent panics for me, unfortunatelly.

On my box [intel i7-3632QM quad core with intel HD4000 graphics] no panic problems but ran into this bug when attaching external mass-storage (my phone) via an USB-cable

On an USB3 bus it appeared exactly as a bug reported for 3.10.3:
http://comments.gmane.org/gmane.linux.usb.general/91405

Now I am trying this patch --which did not make it to 3.10.5:
http://marc.info/?l=linux-usb&m=137523956310060&w=2

.....

Ok, recompiled and rebooted..
.....

Yes, with the lines
added to <path-to-kernel-source>/drivers/scsi/scsi.c as described in the patch-file, my phone is now recognised.

From the screendump it seems the panic is related to the nouveau driver. I can't say I'm surprised, as several previous versions of that driver have caused hard lock-ups on some of my systems.

Have you tried the proprietary Nvidia drivers? The latest version should compile cleanly against a 3.10.5 kernel. Granted, these drivers have a few issues of their own, but that may not affect your particular card/chip.

This laptop has two graphic cards, a discrete NVIDIA and an integrated Intel. I'm turning off the NVIDIA card during boot as soon as I can (via the /sys/kernel/debug/vgaswitcheroo/switch file), and just using the Intel. I don't want to have anything to do with NVIDIA cards, or with its proprietary drivers; if I could, I'd take that video card off of the laptop...

Sounds like a personal problem. :scratch: What did they do to you?

The 3.10.5 kernel, xorg 1.14.2, and the Nvidia 325.15 driver are working perfectly on this box (other than the audio volume problem that started after the 3.8.13 kernel).

Heh, me crashing too. The `mei' module issue is not yet fixed even in the last 3.10.5 kernel.
There are mei init/reset/timeout patches do work for some people. Look innocent, trying myself.

Kernel development has got some twists, also do not remember so many issues or so frequent crashes for the long time. Not only kernel but also other popular software like Firefox or GNOME are getting crippled in the recent past.

Tough decisions for Pat to avoid carrying-in instabilities in otherwise rock-solid Slackware.

fwiw, one of my machines occasionally panics after resume (sometimes immediately, sometimes a minute later), and has been doing so since 3.9. However, since i use kernel patches and proprietary modules i don't have anyone to complain to...

edit: intel core i7 (bloomfield) system with nvidia blob

The 3.10.5 kernel is running fine for me on three slackware-current boxes(32 bit). The boxes have Intel video cards. All is well here.

Hi!
I use S64-14_current with vmlinuz-3.10.5 in Asus I5 PC...Works fine.
Intel stuff work too ;)
First I use default .config file to compile.
So no problemas!

Both my Slackware and LFS partitions use 3.10.5 without any issues at the moment. I'm even using the Slackware 3.10.5 config for LFS too.

Another testimonial... 3.10.5 is running here without issues on Phenom II/Nvidia.

I have a different experience. My 3.10 kernel crashes horribly as a VirtualBox (ver 4.2.16) guest (host is Windows 8) unless I turn off both pre-emption and dynamic tick. Looks like the OP's 3.10 crashes as a VirtualBox host, instead.

I'm running current with 3.10.5 kernel as a guest OS, with guest additions installed, under virtualbox 4.2.16 r86992 with windows 7 ultimate as the host OS. I've not experience one issue with it. Runs flawlessly. I'm using the generic kernel too.

Thanks for pointing out the details about your syslog. I looked under /var/log/ and it turns out syslog's size has ballooned to 522MB in the past 2-3 days with millions of lines similar to the ones you posted above.
I just blacklisted mei-me as I had a second crash earlier today, will see how this goes.

Shaky hands, and forgot to turn off the flash :D but the lines look almost identical to the ones in the image you posted.

Yes the crash occurs on a desktop running Slack current with 3.10.5 and is a VirtualBox host, not a guest.

The desktop is running the stock Slackware kernel and modules + VirtualBox as a host. If blacklisting module mei-me doesn't do it then I'd rather revert the kernel (3.2.x through 3.9.x have all been rock solid on that pc).

I'm monitoring another machine, a laptop with Intel HD 3000, running the same kernel (no issues so far).
Both machines seem to use the i915 driver, the desktop has an integrated Intel Graphics Media Accelerator, not sure if this is a different chip than the laptop's HD 3000 but so far the laptop has been very stable.

sigh.

I too had the same kernel crash.

Using a "stock" slackware-current, without binary blobs, nor virtualbox... my hardware is a sony vaio VPCEC4C5E with a radeon card.

This is the first time in... I don't know, 5+ years... then 2 times in 2 days... the first time I didn't notice, the second one I noticed the same "Worqueue: events mei_timer [mei]" present in the screen shot of the first message...

Does it crash with 3.10.6?

I know stats aren't the full story, and severity of bugs is just as if not more important than quantity, but does anyone else find the following somewhat scary on something that is supposed to be "stable"?
On the plus side 3.10.7 ought to be much better than 3.10.0 was after that little lot, but how bad must 3.10.0 have been to need all that!

Maybe you folks will have better luck with 3.10.6.

Or 3.10.7...

Just upgraded. Running well here. :)

Kernels 3.10.5 to 3.10.7 are not resuming from suspend on my personal ThinkPad X200, while it runs fine on my work's T420. Seems to be an issue on Core 2 Duo ThinkPads: https://bugzilla.redhat.com/show_bug.cgi?id=989373

interesting news
 

Not only the 3.10.x series was being marked as LTS but will have too the new features of 3.11 and 3.12.

http://www.linuxfoundation.org/news-...ether-ltsi-310

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

Just a quick report.
3.10.10 fixes the mei-me flood after resume from S3

I built it back into 3.10.10 as modules (mei-me) (mei)
Removed the Blacklist
I can S3 suspend and resume as many times as I like and no flood.
I still don't know what it is used for even though my i5 lists it under lspci

John
If anyone is still having MEI problems there is an additional fix in 3.10.11

Marking this thread as solved (since introduction of 3.10.9).

The flood is back on 3.10.17 on Slackware 14.1 rc2, ThinkPad T420:

Calling Master Chief...

There's no changes in mei modules in 3.10.16 and also 3.10.17 ChangeLog, however, there seems to be changes in 3.10.15 and i think this is the related commit

I'm seeing the same thing with Slackware64 14.1rc2 on a ThinkPad T520. I actually noticed this issue for the first time on 3.10.17, and this is not the first time I're resumed on this kernel. Seems like this is an intermittent issue.

I've blacklisted the mei_me module.