[SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

caligula · 2013-08-12 07:03:56

Ever since I upgraded to the 3.10.x series, I am not able to use my computer.
It started with the very annoying issue with resume: https://bugzilla.kernel.org/show_bug.cgi?id=60530

In 3.10.5 this was fixed, only to be replaced by a worse problem - every few hours, my entire system locks up. Nothing helps - not even the magic sysrq key.

Trying to debug this with journalctl leads to an interesting phenomenon - the log ends at Aug 10 16:58:58, but if I go further down, I'm back at Aug 09 21:41:36, and if I keep going I'm at Aug 10 16:58:58 again (and so on and so on - the log never ends!).

The last log messages are:

Aug 10 16:58:58 arch kernel: pci 0000:00:16.0: reg 10: [mem 0xf7a1a000-0xf7a1a00f 64bit]
Aug 10 16:58:58 arch kernel: pci 0000:00:16.0: PME# supported from D0 D3hot D3cold
Aug 10 16:58:58 arch kernel: pci 0000:00:1a.0: [8086:1e2d] type 00 class 0x0c0320
Aug 10 16:58:58 arch kernel: pci 0000:00:1a.0: reg 10: [mem 0xf7a18000-0xf7a183ff]
Aug 10 16:58:58 arch kernel: pci 0000:00:1a.0: PME# supported from D0 D3hot D3cold
Aug 10 16:58:58 arch kernel: pci 0000:00:1a.0: System wakeup disabled by ACPI
Aug 10 16:58:58 arch kernel: pci 0000:00:1b.0: [8086:1e20] type 00 class 0x040300
Aug 10 16:58:58 arch kernel: pci 0000:00:1b.0: reg 10: [mem 0xf7a10000-0xf7a13fff 64bit]
Aug 10 16:58:58 arch kernel: pci 0000:00:1b.0: PME# supported from D0 D3hot D3cold
Aug 10 16:58:58 arch kernel: pci 0000:00:1b.0: System wakeup disabled by ACPI
Aug 10 16:58:58 arch kernel: pci 0000:00:1c.0: [8086:1e10] type 01 class 0x060400
Aug 10 16:58:58 arch kernel: pci 0000:00:1c.0: PME# supported from D0 D3hot D3cold
Aug 10 16:58:58 arch kernel: pci 0000:00:1c.0: System wakeup disabled by ACPI
Aug 10 16:58:58 arch kernel: pci 0000:00:1c.1: [8086:1e12] type 01 class 0x060400
Aug 10 16:58:58 arch kernel: pci 0000:00:1c.1: PME# supported from D0 D3hot D3cold
Aug 10 16:58:58 arch kernel: pci 0000:00:1c.3: [8086:1e16] type 01 class 0x060400

Or, if you look at Aug 09 21:41:36 as the "last log":

Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: reset: wrong host start response
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: reset: wrong host start response
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 09 21:41:36 arch kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

Very fun stuff!

EDIT:
Hardware:

00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM76 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108M [GeForce GT 635M] (rev ff)
03:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. Device 5289 (rev 01)
04:00.2 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 0a)

Last edited by caligula (2013-08-20 06:21:49)

jasonwryan · 2013-08-12 07:12:00

Please edit your post and use a less ranty title. It will also likely attract more constructive suggestions...
https://wiki.archlinux.org/index.php/Fo … ow_to_Post

Some details about your hardware may help as well.

caligula · 2013-08-12 07:18:30

jasonwryan wrote:

Please edit your post and use a less ranty title. It will also likely attract more constructive suggestions...
https://wiki.archlinux.org/index.php/Fo … ow_to_Post

Some details about your hardware may help as well.

Wasn't meant as a rant. All in good spirits

seiichiro0185 · 2013-08-12 11:52:16

Interesting, I seem to have the same problem. Complete lockup of the system and repeating log in journalctl. For me it seems to be connected to using compton, which I tried recently. With compton active and running the system would lock up every few hours, but when using the XFCE integrated compositor it didn't occur again (although I just switched back yesterday, so I may just have been lucky so far). Hardware for me is simmilar It's a Laptop with Intel i3 (Ivy Bridge) with integrated graphics, Intel Wifi and Realtek Ethernet.

Edit:

Just for the record, here is my HW-Info (Lenovo Thinkpad E130)

00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1c.5 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 6 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
03:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4)
04:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader (rev 01)
09:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 07)

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Core(TM) i3-3217U CPU @ 1.80GHz
Stepping:              9
CPU MHz:               1782.000
BogoMIPS:              3593.27
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
NUMA node0 CPU(s):     0-3

Last edited by seiichiro0185 (2013-08-13 16:12:25)

beatgammit · 2013-08-13 06:07:27

I have the same problem, but I don't use compton (just xmonad w/ xmobar and dmenu). I've tested suspend-resume, but it seems unrelated. I haven't, however, had it lock up when I didn't suspend, but I haven't verified this since it's a laptop.

One other thing I noticed is that journalctl complains of huge log files before it gives up the ghost. This seems consistent with the mei_me logs though. I meant to post here, but I didn't get around to it until now.

Here's my hardware info for comparison:

$ lscpi
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
02:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 07)
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)

I'm on a Lenovo Thinkpad 430, and I don't quite have the same hardware as you, but it seems we have the same integrated GPU. For comparison:

$ lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Core(TM) i5-3230M CPU @ 2.60GHz
Stepping:              9
CPU MHz:               1326.000
BogoMIPS:              5190.13
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
NUMA node0 CPU(s):     0-3

I moved back to 3.9.9, and that seemed to help, but my crappy wireless seems to be even worse on that kernel.

BTW, I also get the same lockups, but I don't seem to have a sysrq key on this laptop (leave it to Lenovo to remove that...), so I can't verify that it's the same total lockup. Switching gettys, however, does *not* work when it's locked up, so it's probably the same thing.

Last edited by beatgammit (2013-08-14 02:08:02)

WonderWoofy · 2013-08-13 06:13:58

beatgammit wrote:

03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)

I'm sorry about this ^^^ It really sucks on Linux.

About your issue though. You said 3.10.5 is causing you problems, but did you try 3.10.6 from [testing]. There has been ongoing work on i915, so it might be worth trying to go forward in kernel versions rather than backward.

beatgammit · 2013-08-14 02:15:46

WonderWoofy wrote:

beatgammit wrote:
03:00.0 Network controller: Realtek Semiconductor Co., Ltd. RTL8188CE 802.11b/g/n WiFi Adapter (rev 01)
I'm sorry about this ^^^ It really sucks on Linux.

Yeah, it does. It seems more reliable if I leave a ping running, so it's probably a power save thing.

WonderWoofy wrote:

About your issue though. You said 3.10.5 is causing you problems, but did you try 3.10.6 from [testing]. There has been ongoing work on i915, so it might be worth trying to go forward in kernel versions rather than backward.

It appears 3.10.6 has hit [core]... upgrading.

If this fixes my problem, it'll likely fix the OP's as well. If it doesn't, I'll have to scan through the kernel bugs and see what other options there are.

EDIT:

I upgraded to 3.10.6, and I haven't gotten a crash yet, even after a few suspend/resume cycles. I am, however, still getting errors in journalctl:

$ journalctl -x
snip...
Aug 13 20:18:07 jarvis kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 13 20:18:07 jarvis kernel: mei_me 0000:00:16.0: reset: wrong host start response
Aug 13 20:18:07 jarvis kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 13 20:18:07 jarvis kernel: mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 13 20:18:07 jarvis kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 13 20:18:07 jarvis kernel: mei_me 0000:00:16.0: reset: wrong host start response
Aug 13 20:18:07 jarvis kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 13 20:18:07 jarvis systemd[1]: Unit systemd-journald.service entered failed state.
snip...

It seems journald is still crashing, but it at least recovered. After this, I get mei_me errors every 30 seconds:

Aug 13 20:19:06 jarvis kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 13 20:19:06 jarvis kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 13 20:19:36 jarvis kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 13 20:19:36 jarvis kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

I'm not sure how severe these are, so I'll report back if I get a hard lockup. It seemed to happen a few hours after resuming, so I'm not 100% confident the problem is fixed. I think this is triggered by waking from sleep, so I'll try rebooting and verify this.

EDIT:

For some reason, the first resume didn't trigger it, but the second did. This time I got into an awful journald reboot loop (after expanding logs to 2.9G, probably due to mei_me exploding), expecting to lock up.

EDIT:

Locked up. The new kernel doesn't seem to fix it for me... ='( It seems like it may be a little better though...

OP: have you noticed anything different in the 3.10.6 kernel?

Last edited by beatgammit (2013-08-14 04:28:26)

WonderWoofy · 2013-08-14 02:38:12

About the wireless card... have you fixed up the module to not sure the low power stuff? Use modinfo -p rtl8192ce to see what the different options are. I think I found a mild improvment when I turned off the firmware low power, software pow power, ips (whatever that stands for), and then used software encoding. So fwlps=0 swlps=0 ips=0 and swenc=0.

beatgammit · 2013-08-14 04:33:25

WonderWoofy wrote:

About the wireless card... have you fixed up the module to not sure the low power stuff? Use modinfo -p rtl8192ce to see what the different options are. I think I found a mild improvment when I turned off the firmware low power, software pow power, ips (whatever that stands for), and then used software encoding. So fwlps=0 swlps=0 ips=0 and swenc=0.

Thanks! It still sucks a little, but it definitely helped.

Last edited by beatgammit (2013-08-14 04:37:08)

brian jolly · 2013-08-15 01:00:18

I'm seeing the same behavior on a Lenovo T420 using 3.10.6-2-ARCH (i3wm and dmenu)
It's usually hours between freezes, and doesn't seem to matter if the system was freshly booted or if suspend was used.

$ lspci
00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:16.3 Serial controller: Intel Corporation 6 Series/C200 Series Chipset Family KT Controller (rev 04)
00:19.0 Ethernet controller: Intel Corporation 82579LM Gigabit Network Connection (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.1 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 (rev b4)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation QM67 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)
0d:00.0 System peripheral: Ricoh Co Ltd PCIe SDXC/MMC Host Controller (rev 08)

$lscpu
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 42
Model name:            Intel(R) Core(TM) i5-2520M CPU @ 2.50GHz
Stepping:              7
CPU MHz:               1025.000
BogoMIPS:              4986.73
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072

seiichiro0185 · 2013-08-15 16:05:16

For me it seems to be fixed (for the moment) on kernel 3.10.6. Even after reactivating compton and serveral suspend/resume cycles I didn't get any freeze until now. I'll keep an eye on the matter, as it seems like it isn't fully fixed yet like described by the previous posters.

Last edited by seiichiro0185 (2013-08-15 16:05:44)

spaesani · 2013-08-16 05:38:26

Same issue with an Intel Mobile PM965/GM965 MEI controller.

Redhat has it as a bug (since march 2013) : https://bugzilla.redhat.com/show_bug.cgi?id=917081

Real headache when installing over wifi as the message mucks up stdout (I got around it and installed ok. nice installer btw).

Anyone know where to start looking?

mkopta · 2013-08-17 07:09:03

I have the same issue with Lenovo Thinkpad E330 on Linux 3.10.6-2. Randomly freezes. Suspend does not affect the problem anyhow. Mostly it happens, when I try to play a video with mplayer2 and seek by arrows or play a flash video on youtube. Switching to ethernet connection instead of wireless does not affect the problem anyhow either. I have switched to kernel 3.10.7-1 from testing and removed and blacklisted kernel module mei and mei_me. Seems to work so far.

JesusMcCloud · 2013-08-17 12:09:09

Same freezing problem ever since upgrading to 3.10.y on a Lenovo Thinkpad E330.

lspci      
00:00.0 Host bridge: Intel Corporation 3rd Gen Core processor DRAM Controller (rev 09)
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
00:14.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller (rev 04)
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 (rev c4)
00:1c.1 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 (rev c4)
00:1c.2 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 (rev c4)
00:1c.3 PCI bridge: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 4 (rev c4)
00:1d.0 USB controller: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM77 Express Chipset LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] (rev 04)
00:1f.3 SMBus: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller (rev 04)
02:00.0 Network controller: Intel Corporation Centrino Wireless-N 2230 (rev c4)
03:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS5209 PCI Express Card Reader (rev 01)
08:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168 PCI Express Gigabit Ethernet controller (rev 07)

lscpu        
Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                4
On-line CPU(s) list:   0-3
Thread(s) per core:    2
Core(s) per socket:    2
Socket(s):             1
NUMA node(s):          1
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 58
Model name:            Intel(R) Core(TM) i3-3110M CPU @ 2.40GHz
Stepping:              9
CPU MHz:               1944.000
BogoMIPS:              4791.69
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              3072K
NUMA node0 CPU(s):     0-3

Last edited by JesusMcCloud (2013-08-17 12:11:22)

xwhatsit · 2013-08-18 05:52:04

Having the same issue on an X220 with an i5-2410M. I'll try rmmod'ing mei_me (this will wipe out my suspend I'm assuming), but hopefully will mean I don't risk filesystem corruption by having to hold down the power button.

EDIT: blacklisting mei_me hasn't stopped me from suspending to RAM, so let's see if the freezes go away.

Last edited by xwhatsit (2013-08-18 06:01:40)

WonderWoofy · 2013-08-18 06:09:34

Interestingly, on my Core2Duo machine, I was having the crazy out of control mei_me module. So I blacklisted it, thinking I too was giving up suspend to ram... but suspend still works... flawlessly.

Onyros · 2013-08-19 00:01:38

This is strangely not affecting me, taking into account the number of Thinkpads affected (and I have a X220, with an i5-2540M), but I'll keep an eye on this one for the future. Haven't noticed any freezes (fresh boots or after suspend), with any kind of uptime, ranging from a couple of hours to a few days on a time.

What I sometimes notice is that when resuming from suspend, the cores max out at the highest frequency - which I "solve" by suspending and resuming again. Never delved too much into it, really. (Because I forget about it, as it happens sporadically)

Running 3.10.6. What's the module for, anyway?

spaesani · 2013-08-19 06:16:04

My system wasn' t freezing up. Only getting a repeating message on the screen (which filled up the log as well).

In my case lsmod revealed the mei_me module for the mobile mei controller.

I unloaded it and the messages stopped (and the log file doesn't get filled up) and wifi continues to work.
I'm not sure if this helps anyone else with the freeze issue but it worked for the issue I was having and it may relate to the issue here
(as noted in the redhat bug report earlier)

One thing though, I don't really know what my X61T's mobile mei controller is used for. I suspect it's for the phone jack port's modem (which I can do without untill the mei_me module kinks are worked out)

Can anyone confirm if in fact the X61T's mobile mei controller is just the phone modem?

Last edited by spaesani (2013-08-19 06:19:21)

mkopta · 2013-08-19 13:07:59

After running for two days with blacklisted mei (and with 3.10.7-1) I haven't had any freeze. I can suspend and do everything as before. Didn't notice anything else except usable system. What the hell is mei anyway?

spaesani · 2013-08-19 20:07:32

What is mei? Good question..

This refers to the driver (module) itself.
http://cateee.net/lkddb/web-lkddb/INTEL_MEI_ME.html

This is related and gives some indication
http://cateee.net/lkddb/web-lkddb/HECI.html

From the later (link):
"The Intel Management Engine Interface (Intel MEI) driver allows applications to access the Active Management Technology firmware and other Management Engine sub-systems."

Far as I can see deactivating the mei_me module will deactivate "allowing applications to access the Active Management Technology firmware and other Management Engine sub-systems" but, seeing as that some have deactivated/blacklisted the mei_me module without issue, not deactivate accessing the firmware or hardware per se, eg: via a 'regular' driver.

Can anyone confirm this? (I'll keep checking on my end)

Last edited by spaesani (2013-08-19 20:50:01)

stefseel · 2013-08-19 21:42:18

I have the same probem with my Thinkpad T430. I upgraded to kernel 3.10.7-1 today and blacklisted mei and mei_me modules, I'll if it helps.

caligula · 2013-08-20 06:21:25

I've also blacklisted the mei module and so far everything works without problem.
Let's hope it'll be (really) resolved in future kernel versions.

caligula · 2013-08-20 10:34:40

Does anyone else experience this new issue after blacklisting mei?
After I resume from suspend and wait for a while, I have a process systemd-journald which takes up something like 12% CPU and 140MB memore - and then a whole load (A LOT, maybe even 100+) of "systemd-coredump" instances, which take up 15MB each. Eventually my system starts coughing up and then dies a slow and horrible death.

EDIT: seems to be something else entirely, my bad: https://bbs.archlinux.org/viewtopic.php?id=168524

Last edited by caligula (2013-08-20 10:36:46)

Arch Linux

#1 2013-08-12 07:03:56

[SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#2 2013-08-12 07:12:00

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#3 2013-08-12 07:18:30

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#4 2013-08-12 11:52:16

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#5 2013-08-13 06:07:27

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#6 2013-08-13 06:13:58

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#7 2013-08-14 02:15:46

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#8 2013-08-14 02:38:12

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#9 2013-08-14 04:33:25

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#10 2013-08-15 01:00:18

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#11 2013-08-15 16:05:16

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#12 2013-08-16 05:38:26

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#13 2013-08-17 07:09:03

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#14 2013-08-17 12:09:09

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#15 2013-08-18 05:52:04

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#16 2013-08-18 06:09:34

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#17 2013-08-19 00:01:38

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#18 2013-08-19 06:16:04

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#19 2013-08-19 13:07:59

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#20 2013-08-19 20:07:32

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#21 2013-08-19 21:42:18

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#22 2013-08-20 06:21:25

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

#23 2013-08-20 10:34:40

Re: [SOLVED] Kernel 3.10.x - System freezes after upgrade to 3.10.5

Board footer