Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

kelloco2 · 2013-07-25 16:50:00

Hi!
I worked and had just surprised me a kernel panic. I found some information - https://lkml.org/lkml/2013/7/8/339
hmm ...so I do not know. This BUG is patched or not? I use linux 3.10.2-1

Logs:

lip 25 17:26:32 laptop_kasus kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
lip 25 17:26:32 laptop_kasus kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
lip 25 17:27:02 laptop_kasus kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
lip 25 17:27:02 laptop_kasus kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
lip 25 17:27:32 laptop_kasus kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
lip 25 17:27:32 laptop_kasus kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
lip 25 17:28:02 laptop_kasus kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
lip 25 17:28:02 laptop_kasus kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
lip 25 17:28:30 laptop_kasus su[2635]: (to kelloco2) kelloco2 on none
lip 25 17:28:30 laptop_kasus su[2635]: pam_unix(su:session): session opened for user root by (uid=1000)
lip 25 17:28:32 laptop_kasus kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
lip 25 17:28:32 laptop_kasus kernel: mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
lip 25 17:28:42 laptop_kasus su[2635]: pam_unix(su:session): session closed for user root
lip 25 17:29:02 laptop_kasus kernel: mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.

EDIT: after resume Xorg completely going crazy. artifacts appear then hangs ;/

Last edited by kelloco2 (2013-07-25 20:12:04)

Lekensteyn · 2013-07-29 22:12:47

I just had a hard lock-up running Linux 3.10.0 with CONFIG_INTEL_MEI{,_ME}=y. Strange, I had many suspend/resume cycles (in 17 days) without issues, but this evening I had this issue within a minute after resume.

WonderWoofy · 2013-07-29 22:40:26

Lekensteyn wrote:

I just had a hard lock-up running Linux 3.10.0 with CONFIG_INTEL_MEI{,_ME}=y. Strange, I had many suspend/resume cycles (in 17 days) without issues, but this evening I had this issue within a minute after resume.

I have to wonder why you are running 3.10.0... I'm assuming that must be a typo?

Lekensteyn · 2013-07-29 22:47:43

Nope, I do not use Arch stock kernel. I'm currently cooking 3.11-rc3. I was running 3.10.0 because I haven't rebooted for 17 days.

WonderWoofy · 2013-07-29 22:56:01

So if you are currently building your own mainline kernel... don't you think you should try that first? I mean, of what significance will these errors be in a few minutes when you reboot into your new kernel?

Edit: Oh I see, you are just confirming the OPs report... you are not the OP. Sorry about that.

Last edited by WonderWoofy (2013-07-29 22:56:45)

ryzion · 2013-07-30 07:37:28

Same problem here as in https://bbs.archlinux.org/viewtopic.php?id=166432

This bug still persists for me in linux-3.10.3-1

Mr.Smith1974 · 2013-08-10 14:24:46

I have this bug in 3.10.5-1

WonderWoofy · 2013-08-10 21:53:19

I get this even with 3.11rc4 on my Core2Duo E8400. It is actually linux-git (from Linus' git tree) built on Aug 8th at about 6PM PDT.

For now I have just blacklisted the mei-me module, as I don't have it built into my kernel. I imagine though that even with it built into the kernel it could be disabled from the kernel command line for the time being. I have noticed no ill effects so far...

kelloco2 · 2013-08-19 20:49:59

What is the module mei_me used for? Only provide the interface /sys/* for Intel GPU for the card? I blacklisted this module and the problem doesn't occur.

find /sys/bus/pci/drivers/mei_me/ -type l|sed 's#^.*/##'

echo 0000:00:16.0 > /sys/bus/pci/drivers/mei_me/unbind

- replace 0000:00:16.0 with your number
also seems to help. Is this correct solution to the problem? Does anyone know what mei_me driver is doing and is it required?

Last edited by kelloco2 (2013-08-19 20:59:43)

IceHand · 2013-08-24 10:59:17

kelloco2 wrote:

find /sys/bus/pci/drivers/mei_me/ -type l|sed 's#^.*/##'

echo 0000:00:16.0 > /sys/bus/pci/drivers/mei_me/unbind

I don't think that's necessary. Blacklisting “mei_me” and “mei” should be enough. See here for a similar problem and an explanation what mei is: https://bbs.archlinux.org/viewtopic.php … 2#p1314282

kelloco2 · 2013-08-24 12:05:25

Yes I know; after blacklist mei_me those actions aren't needed. Thanks for the link. I quote a sentence from this link
Let's hope it'll be (really) resolved in future kernel versions. For now blacklist solves the problem.

Arch Linux

#1 2013-07-25 16:50:00

Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#2 2013-07-29 22:12:47

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#3 2013-07-29 22:40:26

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#4 2013-07-29 22:47:43

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#5 2013-07-29 22:56:01

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#6 2013-07-30 07:37:28

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#7 2013-08-10 14:24:46

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#8 2013-08-10 21:53:19

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#9 2013-08-19 20:49:59

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#10 2013-08-24 10:59:17

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

#11 2013-08-24 12:05:25

Re: Kernel panic after suspend resume. Intel GPU. Flood of mei_me errors

Board footer