Bug 917081 - mei kernel module problems
mei kernel module problems
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
20
x86_64 Linux
unspecified Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
: 981053 995250 996156 1000877 1002492 1006939 1014639 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-01 11:16 EST by Gabriel VLASIU
Modified: 2016-04-11 04:28 EDT (History)
106 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1017756 (view as bug list)
Environment:
Last Closed: 2014-11-05 19:25:26 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
Patch that collects the non-cosmetic mei driver fixes that were committed to stable upstream after 3.10.4 was cut (22.40 KB, patch)
2013-08-03 01:29 EDT, Dimitris
no flags Details | Diff
mei-me-fix-waiting-for-hw-ready.patch (1.48 KB, patch)
2013-08-04 21:42 EDT, Dimitris
no flags Details | Diff
mei-dont-have-to-clean-the-state-on-power-up.patch (1.03 KB, patch)
2013-08-04 21:43 EDT, Dimitris
no flags Details | Diff
mei-me-fix-reset-state-machine.patch (1.27 KB, patch)
2013-08-04 21:44 EDT, Dimitris
no flags Details | Diff
dmidecode for my dell optiplex 755 (18.67 KB, text/plain)
2013-08-29 10:21 EDT, Tom Horsley
no flags Details
dmidecode output on HP tm2t-2100 (10.50 KB, text/plain)
2013-08-29 13:36 EDT, Jeremy Uchitel
no flags Details
dmidecode for Thinkpad X200s (14.57 KB, text/plain)
2013-08-29 14:20 EDT, Dimitris
no flags Details
dmidecode for Thinkpad T520 (14.21 KB, text/plain)
2013-08-30 04:09 EDT, Nils Philippsen
no flags Details
dmidecode for Thinkpad T420 (16.80 KB, text/plain)
2013-08-30 05:19 EDT, filip.brinkmann
no flags Details
DMI decode output for Lenovo T430 (16.25 KB, text/plain)
2013-09-01 08:18 EDT, Fabrice Salvaire
no flags Details
Darryl Pierce - Lenovo T530 MEI error log entries (37.16 KB, text/plain)
2013-09-01 09:59 EDT, Darryl L. Pierce
no flags Details
dmidecode for Lenovo B590 (15.22 KB, text/plain)
2013-09-09 18:56 EDT, Markus
no flags Details
lspci -nnvv for Thinkpad X200s (24.62 KB, text/plain)
2013-09-12 16:27 EDT, Dimitris
no flags Details
lspci -nnvv (4.12 KB, application/octet-stream)
2013-09-12 16:28 EDT, Michael Jordan
no flags Details
lspci -nnvv (comment was not good) (34.04 KB, text/plain)
2013-09-12 16:30 EDT, Mukundan Ragavan
no flags Details
lspci -nnvv (9.79 KB, text/plain)
2013-09-12 17:21 EDT, Dmitri A. Sergatskov
no flags Details
lspci -nnvv for my dell optiplex 755 (20.90 KB, text/plain)
2013-09-12 18:07 EDT, Tom Horsley
no flags Details
dmidecode Dell Latitude 6430u (26.69 KB, text/plain)
2013-09-13 02:59 EDT, Marco Driusso
no flags Details
lspci -nnvv Dell Latitude 6430u (9.43 KB, text/plain)
2013-09-13 03:01 EDT, Marco Driusso
no flags Details
dmidecode for HP Pavilion dm4 (10.51 KB, text/plain)
2013-09-13 03:55 EDT, Milan Bouchet-Valat
no flags Details
lspci -vnn for HP Pavilion dm4 (23.68 KB, text/plain)
2013-09-13 03:56 EDT, Milan Bouchet-Valat
no flags Details
lenovo t420 (10.58 KB, text/plain)
2013-09-13 06:39 EDT, Mohammed Arafa
no flags Details
lspci -nnvv for lenovo t520 (with nvidia) (10.72 KB, text/plain)
2013-09-13 06:55 EDT, Vetoshkin Nikita
no flags Details
dmidecode ThinkPad x230 (16.12 KB, text/plain)
2013-09-13 07:33 EDT, Patrick C. F. Ernzer
no flags Details
lspci -nnvv ThinkPad x230 (23.04 KB, text/plain)
2013-09-13 07:34 EDT, Patrick C. F. Ernzer
no flags Details
lspci -nnvv ThinkPad T430 (23.07 KB, text/plain)
2013-09-13 07:56 EDT, kubrick@fgv6.net
no flags Details
lspci -nnvv (55.53 KB, text/plain)
2013-09-13 09:37 EDT, sanbor
no flags Details
dmidecode -s bios-version (9 bytes, text/plain)
2013-09-13 09:39 EDT, sanbor
no flags Details
uname -a (115 bytes, text/plain)
2013-09-13 09:40 EDT, sanbor
no flags Details
dmesg, lspci -nvv, dmidecode for Lenovo T520 with mei blacklisted (27.80 KB, application/x-bzip)
2013-09-13 11:38 EDT, Mike Gahagan
no flags Details
Lenovo B590 'lspci -nnvv' output (23.15 KB, patch)
2013-09-14 01:45 EDT, Markus
no flags Details | Diff
lspci -nnvv from Lenovo Thinkpad T520 with mei module blacklisted (27.88 KB, text/plain)
2013-09-16 09:25 EDT, Nils Philippsen
no flags Details
lspci -nnvv from Thinkpad T420s (blacklisted MEI module) (28.54 KB, text/plain)
2013-09-17 04:43 EDT, Will Foster
no flags Details
lspci -nnvv (10.75 KB, text/plain)
2013-09-18 03:04 EDT, Mikkel Lauritsen
no flags Details
lspci -nnvv 3.10.11 Fedora 19 Fujitsu T901 (12.39 KB, text/plain)
2013-09-24 08:57 EDT, Kevin
no flags Details
dmesg output (84.85 KB, text/plain)
2013-10-17 10:02 EDT, Mikhail
no flags Details
dmesg output (93.64 KB, text/x-log)
2013-11-15 04:27 EST, Mikhail
no flags Details
Intel DQ35MP - 3.11.7-200.fc19.x86_64 - lspci --nnvv (2.67 KB, text/plain)
2013-11-15 14:17 EST, Lukas Koranda
no flags Details
dmidecode.log (10.91 KB, text/x-log)
2014-05-22 12:58 EDT, Mikhail
no flags Details
dmidecode_output (14.26 KB, text/plain)
2014-05-22 13:02 EDT, Mukundan Ragavan
no flags Details
dmidecode.txt (7.48 KB, text/plain)
2014-05-22 13:17 EDT, Gabriel VLASIU
no flags Details
dmidecode for kernel 3.14.5-200 (18.89 KB, text/plain)
2014-06-04 22:06 EDT, Dan Mossor [danofsatx]
no flags Details
demidecode for Intel board DQ35JO, bios JOQ3510J.86A.1143 (13.31 KB, text/plain)
2014-06-05 09:14 EDT, Eddie Lania
no flags Details
Intel DG45 dmidecode output (15.29 KB, text/plain)
2015-12-18 15:14 EST, tuksgig
no flags Details
Intel DG45 HECI controller lspci (566 bytes, text/plain)
2015-12-18 15:16 EST, tuksgig
no flags Details
Intel DG45 QST demo app testing mei_me kernel debug log (34.94 KB, text/plain)
2015-12-18 15:19 EST, tuksgig
no flags Details

  None (edit)
Description Gabriel VLASIU 2013-03-01 11:16:34 EST
Description of problem:

Booting kernel 3.8.1-201:

[   24.742778] mei 0000:00:03.0: setting latency timer to 64
[   24.742849] mei 0000:00:03.0: irq 45 for MSI/MSI-X
[   29.752052] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   35.764067] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   41.776073] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   47.788036] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   53.800086] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   59.812087] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   65.824107] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   71.840101] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   77.856031] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   83.868108] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   89.904053] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   95.916114] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  101.928112] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  107.944113] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  113.960115] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  119.976119] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  125.992113] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  132.008112] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  138.020079] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  144.032121] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  150.044042] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  156.056102] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  162.068075] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  168.080106] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  174.092095] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  180.104030] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  186.116028] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  192.128053] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  198.140028] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  204.152037] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  210.164077] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  216.176088] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  222.188116] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  228.200108] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  234.212106] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  240.224102] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  246.236053] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  252.248109] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  258.260085] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  264.272114] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  270.284086] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  276.296108] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  282.308114] mei 0000:00:03.0: unexpected reset: dev_state = RESETING

# lspci -v
...
00:03.0 Communication controller: Intel Corporation Mobile PM965/GM965 MEI Controller (rev 0c)
        Subsystem: Hewlett-Packard Company Device 30c3
        Flags: bus master, fast devsel, latency 0, IRQ 45
        Memory at e8000000 (64-bit, non-prefetchable) [size=16]
        Capabilities: <access denied>
        Kernel driver in use: mei
...
Comment 1 Bert DeKnuydt 2013-03-04 03:35:39 EST
Similar here:

Kernel 3.8.1-201.fc18.x86_64

"dmesg | grep -i mei"
[   19.729594] mei 0000:00:03.0: setting latency timer to 64
[   19.732165] mei 0000:00:03.0: irq 48 for MSI/MSI-X
[   24.744022] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   30.756025] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   36.768326] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
(repeats every 6 seconds)

But: "lspci -v"

00:03.0 Communication controller: Intel Corporation 82Q963/Q965 HECI Controller (rev 02)
        Subsystem: Intel Corporation Device 4f43
        Flags: bus master, fast devsel, latency 0, IRQ 48
        Memory at e3227100 (64-bit, non-prefetchable) [size=16]
        Capabilities: [50] Power Management version 3
        Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Kernel driver in use: mei

"modprobe -r mei" stops the nagging.

There is no '/dev/mei'; the MEI stuff is switched off in my BIOS, iirc.
Comment 2 Tom Horsley 2013-03-06 08:10:18 EST
I'm seeing this as well now that I have kernel 3.8.1-201.fc18.x86_64. For
me, the device involved seems to be:

00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)

The dmesg output has a lot of this stuff in it:

[  173.668031] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  179.680074] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  185.692027] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  191.704029] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  197.716029] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  203.728031] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  209.740040] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  215.752032] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  221.764031] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
...

The is on a Dell Optiplex 755 desktop system.
Comment 3 Tom Horsley 2013-03-20 07:41:34 EDT
The new kernel kernel-3.8.3-203.fc18.x86_64 is spewing these messages even
more. They used to stop after a while, but now I seem to get 1 every 6
seconds:

[   60.648033] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   66.660043] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   72.672115] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   78.684038] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   84.696034] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   90.708032] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   96.720041] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  102.732043] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  108.744040] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  114.756032] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  120.768034] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  126.780034] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  132.792041] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  138.804045] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  144.816036] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  150.828034] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  156.840039] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  162.852063] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  168.864071] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  174.876086] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  180.888043] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  186.900050] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  192.912027] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  198.924027] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  204.936038] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  210.948053] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  216.960064] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  222.972036] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  228.984024] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  234.996031] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  241.008033] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  247.020038] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  253.032033] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  259.044032] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  265.056029] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  271.068031] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  277.080046] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  283.092044] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  289.104036] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  295.116026] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[  301.128048] mei 0000:00:03.0: unexpected reset: dev_state = RESETING

Can anyone explain what the "mei" module does for me? I've looked up mei
on google and can't make heads nor tails of the descriptions I have found.
Comment 4 Patrick O'Callaghan 2013-03-22 08:17:11 EDT
$ lspci
00:00.0 Host bridge: Intel Corporation 82Q963/Q965 Memory Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)
00:03.0 Communication controller: Intel Corporation 82Q963/Q965 HECI Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1c.1 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 2 (rev 02)
00:1c.2 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 3 (rev 02)
00:1c.3 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 4 (rev 02)
00:1c.4 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 5 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.2 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #3 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HO (ICH8DO) LPC Interface Controller (rev 02)
00:1f.2 SATA controller: Intel Corporation 82801HR/HO/HH (ICH8R/DO/DH) 6 port SATA Controller [AHCI mode] (rev 02)
00:1f.3 SMBus: Intel Corporation 82801H (ICH8 Family) SMBus Controller (rev 02)
02:00.0 IDE interface: Marvell Technology Group Ltd. 88SE6101/6102 single-port PATA133 interface (rev b1)
06:03.0 FireWire (IEEE 1394): Texas Instruments TSB43AB22A IEEE-1394a-2000 Controller (PHY/Link) [iOHCI-Lynx]

So I don't seem to have a "mei", whatever that is, and yet I'm getting these messages all the time:

$ dmesg|grep mei|wc -l
2339

However, following Comment #1 above, "modprobe -r mei" seems to stop it.
Comment 5 Patrick O'Callaghan 2013-03-22 08:18:35 EDT
(In reply to comment #4)
...

> However, following Comment #1 above, "modprobe -r mei" seems to stop it.

Sorry, this is kernel-3.8.3-203.fc18.x86_64
Comment 6 Gabriel VLASIU 2013-03-22 08:22:02 EDT
Better solution:

# echo -e "blacklist mei\ninstall mei /bin/true" > /etc/modprobe.d/mei.conf
# reboot
Comment 7 Tom Horsley 2013-03-22 08:40:07 EDT
I just used the blacklist directive by itself and it seemed to work,
but I also needed to do:

dracut --force

To get the blacklist info up into the initrd file.
Comment 8 Gabriel VLASIU 2013-03-22 08:52:53 EDT
# cat mei.conf 
blacklist mei
# lsmod | grep mei
#
# modprobe mei
# lsmod | grep mei
mei                    75052  0 
# rmmod mei
# echo "install mei /bin/true" >> /etc/modprobe.d/mei.conf
# modprobe mei
# lsmod | grep mei
#

I don't have mei module in initrd file. I can't imagine why you have-it.
Comment 9 purpleidea 2013-03-24 02:25:32 EDT
Don't know what's wrong, but I can't read dmesg properly! See below:

[james@server ~]$ dmesg | grep mei | wc -l
2113
[james@server ~]$ dmesg | grep mei | tail -n 1
[12722.204044] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[james@server ~]$ dmesg | awk '{print substr($0, index($0,$2))}' | grep mei | sort | uniq | wc -l
1662
[james@server ~]$ cat /etc/issue
Fedora release 18 (Spherical Cow)
Kernel \r on an \m (\l)

[james@server ~]$ uname -a
Linux server 3.8.3-203.fc18.x86_64 #1 SMP Mon Mar 18 12:59:28 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
[james@server ~]$ lspci 
00:00.0 Host bridge: Intel Corporation 82Q963/Q965 Memory Controller Hub (rev 02)
00:02.0 VGA compatible controller: Intel Corporation 82Q963/Q965 Integrated Graphics Controller (rev 02)
00:03.0 Communication controller: Intel Corporation 82Q963/Q965 HECI Controller (rev 02)
00:19.0 Ethernet controller: Intel Corporation 82566DM Gigabit Network Connection (rev 02)
00:1a.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #4 (rev 02)
00:1a.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #5 (rev 02)
00:1a.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #2 (rev 02)
00:1b.0 Audio device: Intel Corporation 82801H (ICH8 Family) HD Audio Controller (rev 02)
00:1c.0 PCI bridge: Intel Corporation 82801H (ICH8 Family) PCI Express Port 1 (rev 02)
00:1d.0 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #1 (rev 02)
00:1d.1 USB controller: Intel Corporation 82801H (ICH8 Family) USB UHCI Controller #2 (rev 02)
00:1d.7 USB controller: Intel Corporation 82801H (ICH8 Family) USB2 EHCI Controller #1 (rev 02)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev f2)
00:1f.0 ISA bridge: Intel Corporation 82801HO (ICH8DO) LPC Interface Controller (rev 02)
00:1f.2 IDE interface: Intel Corporation 82801H (ICH8 Family) 4 port SATA Controller [IDE mode] (rev 02)
[james@server ~]$
Comment 10 Fedora End Of Life 2013-04-03 11:45:08 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19
Comment 11 markzzzsmith 2013-04-05 18:31:55 EDT
Hi,

This happening to me too, also on a Dell Optiplex 755, on Fedora 17 / kernel version 3.8.4-102.fc17.x86_64.

I've black listed the mei module as per Gabriel VLASIU's comment.

I don't know if it is related, however I'm also now having trouble with suspend and resume. The machine takes a lot longer to suspend than it used to e.g. 20 to 30 seconds, and then doesn't resume successfully - it sits and 'thinks' for a while, then either locks up, or reboots to POST.

I'm happy to create another bug report for the suspend/resume problem as it may be unrelated, however what I'm curious about is if other people who've reported this mei problem are also seeing the same suspend/resume behaviour. If so, I think that would indicate the suspend/resume problem is another symptom of this mei problem.
Comment 12 Josh Boyer 2013-05-13 14:35:08 EDT
Are you still seeing this with the 3.9 kernels?
Comment 13 purpleidea 2013-05-13 14:58:29 EDT
$ uname -a
Linux freed 3.8.9-200.fc18.x86_64 #1 SMP Fri Apr 26 12:50:07 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 14 Josh Boyer 2013-05-13 15:00:52 EDT
(In reply to comment #13)
> $ uname -a
> Linux freed 3.8.9-200.fc18.x86_64 #1 SMP Fri Apr 26 12:50:07 UTC 2013 x86_64
> x86_64 x86_64 GNU/Linux

That is not helpful.

Did you mean you still see the issue with that kernel version, or is it fixed? 

Did you realize that I asked about the 3.9 kernel, not the 3.8 kernel?

Are you aware this is an f19 bug at the moment, but 3.9 is also built for f18?
Comment 15 purpleidea 2013-05-13 15:08:47 EDT
(In reply to comment #14)
> (In reply to comment #13)
> > $ uname -a
> > Linux freed 3.8.9-200.fc18.x86_64 #1 SMP Fri Apr 26 12:50:07 UTC 2013 x86_64
> > x86_64 x86_64 GNU/Linux
> 
> That is not helpful.
> 
> Did you mean you still see the issue with that kernel version, or is it
> fixed? 
> 
> Did you realize that I asked about the 3.9 kernel, not the 3.8 kernel?
> 
> Are you aware this is an f19 bug at the moment, but 3.9 is also built for
> f18?

I thought my answer was obvious sorry.
I get the issue with that particular kernel.
Can't comment on others.
Cheers
Comment 16 Josh Boyer 2013-05-13 15:14:39 EDT
(In reply to comment #15)
> (In reply to comment #14)
> > (In reply to comment #13)
> > > $ uname -a
> > > Linux freed 3.8.9-200.fc18.x86_64 #1 SMP Fri Apr 26 12:50:07 UTC 2013 x86_64
> > > x86_64 x86_64 GNU/Linux
> > 
> > That is not helpful.
> > 
> > Did you mean you still see the issue with that kernel version, or is it
> > fixed? 
> > 
> > Did you realize that I asked about the 3.9 kernel, not the 3.8 kernel?
> > 
> > Are you aware this is an f19 bug at the moment, but 3.9 is also built for
> > f18?
> 
> I thought my answer was obvious sorry.
> I get the issue with that particular kernel.

Ok.  That isn't surprising.

> Can't comment on others.

Then please stop clearing the needinfo flag.
Comment 17 purpleidea 2013-05-13 15:18:36 EDT
(In reply to comment #16)
> (In reply to comment #15)
> > (In reply to comment #14)
> > > (In reply to comment #13)
> > > > $ uname -a
> > > > Linux freed 3.8.9-200.fc18.x86_64 #1 SMP Fri Apr 26 12:50:07 UTC 2013 x86_64
> > > > x86_64 x86_64 GNU/Linux
> > > 
> > > That is not helpful.
> > > 
> > > Did you mean you still see the issue with that kernel version, or is it
> > > fixed? 
> > > 
> > > Did you realize that I asked about the 3.9 kernel, not the 3.8 kernel?
> > > 
> > > Are you aware this is an f19 bug at the moment, but 3.9 is also built for
> > > f18?
> > 
> > I thought my answer was obvious sorry.
> > I get the issue with that particular kernel.
> 
> Ok.  That isn't surprising.
> 
> > Can't comment on others.
> 
> Then please stop clearing the needinfo flag.
It seems to be checked by default. Looks like a new bugzilla.
Comment 18 Gabriel VLASIU 2013-05-13 16:21:23 EDT
kernel 3.9.2-200

After boot:

# dmesg | grep -i mei
[   10.379613] mei 0000:00:03.0: setting latency timer to 64
[   10.379692] mei 0000:00:03.0: irq 45 for MSI/MSI-X
[   15.392033] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   21.404076] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   27.416075] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   33.428105] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   39.440107] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[   45.456081] mei 0000:00:03.0: unexpected reset: dev_state = RESETING

No more messages after "[   45.456081] mei ...".

# rmmod mei
# modprobe mei

May 13 23:15:29 xxxxxxx kernel: [  487.694135] mei 0000:00:03.0: stop
May 13 23:15:37 xxxxxxx kernel: [  496.036106] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:15:43 xxxxxxx kernel: [  502.048101] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:15:49 xxxxxxx kernel: [  508.060092] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:15:55 xxxxxxx kernel: [  514.072118] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:01 xxxxxxx kernel: [  520.084106] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:07 xxxxxxx kernel: [  526.096103] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:13 xxxxxxx kernel: [  532.108090] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:19 xxxxxxx kernel: [  538.120028] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:25 xxxxxxx kernel: [  544.132098] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:31 xxxxxxx kernel: [  550.144083] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:37 xxxxxxx kernel: [  556.156102] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:43 xxxxxxx kernel: [  562.168108] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:49 xxxxxxx kernel: [  568.180101] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:16:55 xxxxxxx kernel: [  574.192099] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:01 xxxxxxx kernel: [  580.204096] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:07 xxxxxxx kernel: [  586.216055] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:13 xxxxxxx kernel: [  592.228087] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:19 xxxxxxx kernel: [  598.240054] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:26 xxxxxxx kernel: [  604.252096] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:32 xxxxxxx kernel: [  610.264135] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:38 xxxxxxx kernel: [  616.276060] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:44 xxxxxxx kernel: [  622.288078] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:50 xxxxxxx kernel: [  628.300088] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:17:56 xxxxxxx kernel: [  634.312092] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:18:02 xxxxxxx kernel: [  640.324041] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 13 23:18:08 xxxxxxx kernel: [  646.336102] mei 0000:00:03.0: unexpected reset: dev_state = RESETING

And so on every 6 seconds.
Comment 19 purpleidea 2013-05-26 15:39:32 EDT
(In reply to Josh Boyer from comment #14)
> (In reply to comment #13)
> > $ uname -a
> > Linux freed 3.8.9-200.fc18.x86_64 #1 SMP Fri Apr 26 12:50:07 UTC 2013 x86_64
> > x86_64 x86_64 GNU/Linux
> 
> That is not helpful.
> 
> Did you mean you still see the issue with that kernel version, or is it
> fixed? 
> 
> Did you realize that I asked about the 3.9 kernel, not the 3.8 kernel?
> 
> Are you aware this is an f19 bug at the moment, but 3.9 is also built for
> f18?

Do you realize this is still affecting both 3.8 and 3.9 users?
Is this going to be backported to F18 ?
# uname -a
Linux machine 3.9.3-201.fc18.x86_64 #1 SMP Tue May 21 17:02:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 20 Need Real Name 2013-06-12 13:04:25 EDT
I see mei problems too. From dmesg

[   44.569164] mei 0000:00:16.0: Device doesn't have valid ME Interface
[   44.569171] mei 0000:00:16.0: initialization failed.

This is Fedora 18:

Linux bin.astro.cornell.edu 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 21 Tom Horsley 2013-06-12 13:53:30 EDT
In my fedora19 beta with 3.9.4-301.fc19.x86_64 I was also seeing the unexpected reset messages every few seconds. I had to blacklist the module again.
Comment 22 Gabriel VLASIU 2013-07-24 15:03:58 EDT
kernel 3.10.2-301.fc19.x86_64:

[ 1262.284082] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 1262.284102] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 1268.296043] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 1268.296062] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 1274.308061] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 1274.308074] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 1280.320052] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 1280.320065] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
.....

Over and over again the same bogus messages since mei/mei_me are not compiled as modules any more:

$ grep INTEL_MEI /boot/config-3.10.2-301.fc19.x86_64 
CONFIG_INTEL_MEI=y
CONFIG_INTEL_MEI_ME=y

The only way to get rid of those messages is to tell rsyslog to ignore them (maybe someone else also need this).

$ cat /etc/rsyslog.d/01-blocklist.conf 
# mei bogus messages
:msg,contains,"mei_me 0000:00:03.0: reset: connect/disconnect timeout." ~
:msg,contains,"mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING" ~

Until this bug is fixed, please compile mei/mei_me as a modules again so we can blacklist them again! Thank you.
Comment 23 markzzzsmith 2013-07-24 17:05:06 EDT
Unfortunately, blacklisting the mei module causes this problem to reappear:

https://bugzilla.redhat.com/show_bug.cgi?id=842444

Has this bug been escalated to the kernel mei maintainers? It's been around for quite a while, and as it hasn't been fixed in a number of kernel releases since then, so I'm wondering if they don't know about it.
Comment 24 Tom Horsley 2013-07-29 07:51:54 EDT
Me three! I just got kernel-3.10.3-300.fc19.x86_64 and in just a few minutes my /var/log/messages grew by over 300MB, filled with this nonsense:

Jul 29 07:37:46 tomh kernel: [   72.200112] mei_me 0000:00:03.0: reset: wrong host start response
Jul 29 07:37:46 tomh kernel: [   72.200120] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Jul 29 07:37:46 tomh kernel: [   72.200163] mei_me 0000:00:03.0: reset: unexpected enumeration response hbm.
Jul 29 07:37:46 tomh kernel: [   72.200168] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Jul 29 07:37:46 tomh kernel: [   72.200450] mei_me 0000:00:03.0: reset: wrong host start response
Jul 29 07:37:46 tomh kernel: [   72.200455] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING

I used to be able to blacklist the module, but no more I guess.

I'll just have to tell yum to stop getting kernel updates till this bug is fixed.

lspci on my system says:

00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)

The actual machine is a Dell Optiplex 755.

Couldn't someone at least teach the stupid module to disable itself when it gets reset umpteen times in a row in a span of 2 seconds?
Comment 25 Josh Boyer 2013-07-29 08:22:47 EDT
*** Bug 981053 has been marked as a duplicate of this bug. ***
Comment 26 markzzzsmith 2013-07-29 17:31:13 EDT
Tom, you'll need the mei module if you want suspend to work.
Comment 27 Dimitris 2013-07-29 19:10:18 EDT
Me four with Thinkpad X200s and:

>$ uname -a
>Linux gaspode 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

>$ lspci
>00:00.0 Host bridge: Intel Corporation Mobile 4 Series Chipset Memory Controller Hub (rev 07)
>00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
>00:02.1 Display controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
>00:03.0 Communication controller: Intel Corporation Mobile 4 Series Chipset MEI Controller (rev 07)
>00:19.0 Ethernet controller: Intel Corporation 82567LM Gigabit Network Connection (rev 03)
>00:1a.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4 (rev 03)
>00:1a.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5 (rev 03)
>00:1a.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6 (rev 03)
>00:1a.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2 (rev 03)
>00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 03)
>00:1c.0 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 1 (rev 03)
>00:1c.1 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 2 (rev 03)
>00:1c.3 PCI bridge: Intel Corporation 82801I (ICH9 Family) PCI Express Port 4 (rev 03)
>00:1d.0 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1 (rev 03)
>00:1d.1 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2 (rev 03)
>00:1d.2 USB controller: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3 (rev 03)
>00:1d.7 USB controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1 (rev 03)
>00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev 93)
>00:1f.0 ISA bridge: Intel Corporation ICH9M-E LPC Interface Controller (rev 03)
>00:1f.2 SATA controller: Intel Corporation 82801IBM/IEM (ICH9M/ICH9M-E) 4 port SATA Controller [AHCI mode] (rev 03)
>00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 03)
>03:00.0 Network controller: Intel Corporation Ultimate N WiFi Link 5300
Comment 28 Tom Horsley 2013-07-29 19:47:00 EDT
I don't give a rat's ass about suspend, especially compared to log files that grow at 300MB a minute :-). I also tend to suspect that a mei module that is getting reset every few nanoseconds isn't going to be very helpful in the suspend department anyway.

In fact, I couldn't even shutdown the system cleanly because it was spending all its time spewing log messages and couldn't proceed through the shutdown. I had to flip the switch on the UPS and yank the power to reboot into old kernel.
Comment 29 Tim Waugh 2013-07-30 06:20:45 EDT
I saw these messages today with kernel-3.10.3-300.fc19.x86_64 after resuming from suspend.
Comment 30 Dimitris 2013-07-30 19:10:34 EDT
FWIW, tried 3.11.0-0.rc3.git0.1.fc20.x86_64 in the context of another bug report (#990323) and this seems to have been fixed in that version.

A very basic search for mei_me on bugzilla.kernel.org doesn't show anything relevant.
Comment 31 Vince Herried 2013-07-30 23:33:21 EDT
me also....
00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
        Subsystem: Dell OptiPlex 755
        Flags: bus master, fast devsel, latency 0, IRQ 42
        Memory at f0200800 (64-bit, non-prefetchable) [size=16]
        Capabilities: [50] Power Management version 3
        Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
        Kernel driver in use: mei_me

zillions of errors no kernel to fall back on, new install.
dell optiplex 755

hmmm wonder if f18 is still around, just finshed fedup to 19.
Comment 32 Vince Herried 2013-07-30 23:34:35 EDT
32 bit uname -a
Linux desk1.home.vjh 3.10.3-300.fc19.i686.PAE #1 SMP Fri Jul 26 00:12:34 UTC 2013 i686 i686 i386 GNU/Linux
Comment 33 Edouard Bourguignon 2013-07-31 13:11:02 EDT
haven't seen anymore messages about mei_me since I have kernel-3.10.4-300.fc19.x86_64, but I have only suspend a few times.
Comment 34 Dimitris 2013-07-31 15:08:37 EDT
Still here with 3.10.4-300.fc19.x86_64 after resume from hibernate:

> $ dmesg |grep -c mei_me
> 2278

which consists of lots of:

> [ 1627.861328] mei_me 0000:00:03.0: reset: wrong host start response
> [ 1627.861334] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Comment 35 Michael Jordan 2013-07-31 23:07:31 EDT
[michael@mach1 proc]$ uname -a
Linux mach1 3.10.3-300.fc19.x86_64 #1 SMP Fri Jul 26 00:00:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[ 2993.396031] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 2999.412023] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 2999.412033] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3005.424023] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3005.424032] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3011.436023] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3011.436033] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3017.448016] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3017.448026] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3023.460014] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3023.460024] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3029.472021] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3029.472030] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3035.484015] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3035.484025] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3041.496027] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3041.496037] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3047.508020] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3047.508029] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3053.520024] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3053.520034] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3059.532028] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3059.532038] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3065.544151] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3065.544161] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3071.556021] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3071.556031] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3077.568018] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3077.568028] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3083.580019] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3083.580030] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3089.592025] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3089.592035] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3095.604026] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3095.604036] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3101.616019] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3101.616029] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3107.628026] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3107.628036] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3113.640024] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3113.640034] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3119.652018] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3119.652029] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3125.664021] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3125.664032] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3131.676024] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3131.676034] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3137.688023] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3137.688033] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3143.700020] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3143.700030] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3149.712019] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3149.712029] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3155.724015] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3155.724025] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3161.736016] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3161.736025] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3167.748016] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3167.748027] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3173.760020] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3173.760030] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3179.772028] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3179.772038] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3185.784036] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3185.784046] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 3191.796032] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 3191.796041] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING

Two brand new FC19 installs in identical systems
I can't blacklist or remove mei as it appears to be compiled *into* the kernel now!

(&<

Intel Management Engine - don't want it, don't need it. Please make it go away!
Comment 36 Tom Horsley 2013-08-02 07:53:35 EDT
kernel-3.10.4-300.fc19.x86_64 is only slightly better. Instead of generating the mei resets every 5 milliseconds, it is back to generating them every 5 seconds, but it is still unusable. What the hell was wrong with mei being a loadable module we could blacklist? Is there a kernel option that can turn it off somehow?

For now, I'll  have to add kernel-3.10.4 to the yum exclude list and uninstall it.
Comment 38 Dimitris 2013-08-03 01:29:53 EDT
Created attachment 782221 [details]
Patch that collects the non-cosmetic mei driver fixes that were committed to stable upstream after 3.10.4 was cut

Collected the changes from the three commits above into a patch and rebuilt a local 3.10.4-300.fc19.x86_64 build, so far mei_me is behaving itself across suspends and hibernates for me.

This also seems to have "fixed" (rather, masked) bug 990323.
Comment 39 dirk 2013-08-03 18:33:53 EDT
I have the same problem, sometimes appearing (in the same second) tens of thousends of lines in /var/log/messages of the mei_me kind as described above. 

I have this with Fedora 19 x86_64 with all recent updates with 

kernel 3.10.4-300.fc19.x86_64

on two different machines:

Thinkpad X220 with Sandy-Bridge, and
Thinkpad X230 with Ivy-Bridge.
Comment 40 Dimitris 2013-08-04 21:42:24 EDT
Created attachment 782623 [details]
mei-me-fix-waiting-for-hw-ready.patch
Comment 41 Dimitris 2013-08-04 21:43:33 EDT
Created attachment 782625 [details]
mei-dont-have-to-clean-the-state-on-power-up.patch
Comment 42 Dimitris 2013-08-04 21:44:25 EDT
Created attachment 782627 [details]
mei-me-fix-reset-state-machine.patch
Comment 43 Dimitris 2013-08-04 21:55:08 EDT
3.10.5 upstream didn't pick this up either.  I've civilized the changes into three different patches that just replicate the relevant commits from Thomas Winkler upstream, referenced in comment 37.  Added these to 3.10.4-300.fc19.x86_64, rebuilt locally and seems to fix the issue nicely here.
Comment 44 Dimitris 2013-08-04 22:43:49 EDT
I guess this is still unresolved upstream on different (newer than mine) hardware:

https://lkml.org/lkml/2013/7/17/213

I'll stay quiet now.
Comment 45 Tom Horsley 2013-08-05 06:10:13 EDT
"Still unresolved" sounds like "Make the damn modules loadable so we can blacklist 'em" to me :-).
Comment 46 Josh Boyer 2013-08-05 09:28:15 EDT
(In reply to Tom Horsley from comment #45)
> "Still unresolved" sounds like "Make the damn modules loadable so we can
> blacklist 'em" to me :-).

They actually are set like that in the config-* chunks.  We recently noticed that they're now getting built-in in spite of that.  Something changed in the upstream Kconfig files to force it to built-in.  We'll revisit that soon.
Comment 47 Gabriel VLASIU 2013-08-05 11:09:08 EDT
> They actually are set like that in the config-* chunks.
Actually, not quite true.

$ grep INTEL_MEI config-x86-generic 
CONFIG_INTEL_MEI=m
CONFIG_INTEL_MEI_ME=y

Just set CONFIG_INTEL_MEI_ME=m and mei && mei-me will be both built as modules.
Comment 48 Josh Boyer 2013-08-05 11:12:46 EDT
(In reply to Gabriel VLASIU from comment #47)
> > They actually are set like that in the config-* chunks.
> Actually, not quite true.

It is true.

> $ grep INTEL_MEI config-x86-generic 
> CONFIG_INTEL_MEI=m
> CONFIG_INTEL_MEI_ME=y

MEI_ME used to be an add-on option to the MEI driver.  Upstream later split it out to be it's own thing, changing the Kconfig file.  As I said.

> Just set CONFIG_INTEL_MEI_ME=m and mei && mei-me will be both built as
> modules.

Yes, we're aware of that.
Comment 49 Michel van der List 2013-08-09 09:34:38 EDT
This bug appears to be eating my machine. Just upgraded to 3.10.4-300.fc19. Guess I'll try to boot to an older version to see if it matters.
Comment 50 Michel van der List 2013-08-09 09:50:35 EDT
After booting 3.10.3-300, it seems to have slowed down the messages significantly. Reading through this, no idea whether it's just a different hardware state. I had to turn the box off after trying to reboot, since it just went to the console and spewed 1000s of messages at me with no clear end in sight...
Comment 51 Tom Horsley 2013-08-09 10:08:08 EDT
I have to stick with the last 3.9 kernel (where I can at least blacklist the mei module) to have a usable system.
Comment 52 Michael Gruys 2013-08-10 11:17:25 EDT
I have noticed it is solved in 3.10.5-201.fc19.x86_64
(after enabling [updates-testing] in /etc/yum.repos.d/fedora-updates-testing.repo and yum update)
Comment 53 Dimitris 2013-08-10 17:10:36 EDT
It does seem that 3.10.5-201.fc19.x86_64 building this as a module has made it stay quiet for me too.  A suspend or hibernate cycle now only results in one error:

[  107.030476] mei_me 0000:00:03.0: suspend
[  107.037055] mei_me 0000:00:03.0: wait hw ready failed. status = 0x0
[  107.554318] mei_me 0000:00:03.0: irq 45 for MSI/MSI-X
Comment 54 Edouard Bourguignon 2013-08-12 04:31:17 EDT
Still having flooding messages from kernel when resuming after long suspend on 3.10.5-201, just before kernel hangs:

Aug 12 09:19:44 taran kernel: [33056.291039] mei_me 0000:00:16.0: reset: wrong host start response
Aug 12 09:19:44 taran kernel: [33056.291042] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 12 09:19:44 taran kernel: [33056.291058] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.

Intel i5-3337U on Samsung np740U
Comment 55 Michel van der List 2013-08-12 12:56:55 EDT
Moving to 3.10.5-201 solves the problem for me, since I have:
  # cat /etc/modprobe.d/mei.conf 
  blacklist mei
  install mei /bin/true

dmesg now just shows:
  # dmesg | grep mei
  [   11.931932] mei_me: Unknown symbol mei_start (err 0)
  [   11.931952] mei_me: Unknown symbol mei_deregister (err 0)
  [   11.931961] mei_me: Unknown symbol mei_irq_read_handler (err 0)
  [   11.931968] mei_me: Unknown symbol mei_stop (err 0)
  [   11.931975] mei_me: Unknown symbol mei_register (err 0)
  [   11.931987] mei_me: Unknown symbol mei_reset (err 0)
  [   11.931997] mei_me: Unknown symbol mei_irq_compl_handler (err 0)
  [   11.932020] mei_me: Unknown symbol mei_device_init (err 0)
  [   11.932030] mei_me: Unknown symbol mei_irq_write_handler (err 0)

No idea if this is useful to anyone.
Comment 56 Tom Horsley 2013-08-12 14:22:33 EDT
I already blacklisted mei_me as well, and don't get any messages :-).

BTW: As long as we have this relevant bug, can anyone explain what on earth the mei module actually does?

Every single web page I look at on Intel's site is either impressive technobabble designed to make IT managers think it must mean something important because it is utterly opaque, or when I can actually extract information, implies that all this technology works behind the scenes completely out of reach of the running operating system.

So what the heck is the kernel module needed for?
Comment 57 Michel van der List 2013-08-13 10:14:26 EDT
I found this blog post where it is explained (windows centric in this case)
to be for [1]:
   First let us cover what are the key Intel Technologies that utilize
   the MEI Driver:

   Intel® Active Management Technology  (AMT)
   Intel® Anti-Theft (AT)  Technology

So this appears to be a driver that talks to the 'manageability engine'
in the BIOS, which seems mostly of interest to enterprise shops that
manage large fleets of systems. My understanding is incomplete and
probably somewhat off target, but I do know I have *no* need for this
in my Fedora system :-).

[1] http://software.intel.com/en-us/blogs/2011/11/22/communication-error-between-application-and-intel-me-module-fw-update-client
Comment 58 Oliver Ruebenacker 2013-08-13 15:33:44 EDT
     Hello,

  I'm getting random kermel panics and they seem to coincide with the following messages in /var/log/messages repeated many many times:

Aug 13 11:00:14 localhost kernel: [ 9218.462055] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 13 11:00:14 localhost kernel: [ 9218.462067] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 13 11:00:44 localhost kernel: [ 9248.555829] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 13 11:00:44 localhost kernel: [ 9248.555850] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 13 11:01:14 localhost kernel: [ 9278.649750] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 13 11:01:14 localhost kernel: [ 9278.649761] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

[oruebenacker@localhost log]$ uname -a
Linux localhost.localdomain 3.10.5-201.fc19.x86_64 #1 SMP Wed Aug 7 16:25:24 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 59 Michael J. Chudobiak 2013-08-13 15:50:54 EDT
I was unable to boot my HP DC7700 with kernel-3.10.5-201.fc19.x86_64, due to mei-related kernel crashes.

Then comment 57 jogged my memory, and I remembered that long ago I had disabled the Intel Management Engine in BIOS, because of a networking issue (long since fixed).

Re-enabling the IME (by accessing its special UI by pressing Ctrl+P during power-up, not the normal BIOS screen) made everything work again.

Summary: If you are suffering from this bug, make sure the Intel Management Engine is enabled on your system.
Comment 60 Martijn Faassen 2013-08-13 18:21:25 EDT
I just suffered my second hard freeze in a few days; X11 freezes, it's also network unreachable. It seems to have started after a 'yum update' a few days ago.

I'm on Fedora 18.

$ uname -a
Linux cosmos 3.10.4-100.fc18.x86_64 #1 SMP Thu Aug 1 21:13:27 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I see a huge amount of "mei_me" messages in /var/log/messages. The freeze seems to coincide with a few lines full of ^@^@ being written into the log.
Comment 61 Martijn Faassen 2013-08-13 18:22:56 EDT
In addition to #60, I notice that the problem of mei_me spamming seems to start after wake-up from suspend.
Comment 62 Josh Boyer 2013-08-15 09:56:50 EDT
*** Bug 996156 has been marked as a duplicate of this bug. ***
Comment 63 Josh Boyer 2013-08-15 10:12:07 EDT
*** Bug 995250 has been marked as a duplicate of this bug. ***
Comment 64 Steve Grubb 2013-08-16 10:41:59 EDT
Just noticed today that my /var/log/messages was 80Gb in size. Its full of these mei_me reset/unexpected reset  messages. I'm on the 3.10.6-200.fc19.x86_64 kernel.
Comment 65 Josh Boyer 2013-08-16 13:20:53 EDT
Please test this scratch build when it completes:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5822807
Comment 66 jonathan baron 2013-08-16 13:25:20 EDT
(In reply to Steve Grubb from comment #64)
> Just noticed today that my /var/log/messages was 80Gb in size. Its full of
> these mei_me reset/unexpected reset  messages. I'm on the
> 3.10.6-200.fc19.x86_64 kernel.

Same problem with 3.10.6-100 in Fedora 18. Started with 3.10.4-100, but I did not have this problem with 3.9.11-200. These log messages are associated with "kernel panic" crashes, which happen when the Lenovo T510 is just sitting doing nothing, but connected to the Internet. They happen every few minutes, and then the crash.
Comment 67 Vetoshkin Nikita 2013-08-16 16:46:10 EDT
(In reply to Josh Boyer from comment #65)
> Please test this scratch build when it completes:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5822807

Installed. Running 3.10.7-200.1.fc19.x86_64. After suspend have full log of these:
[  608.403178] mei_me 0000:00:16.0: reset: wrong host start response
[  608.403181] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[  608.403193] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Comment 68 Mark Wielaard 2013-08-16 18:44:59 EDT
I had a random hang of my thinkpad x220 and a log full of mei_me messages in /var/log/messages with 3.10.5-201.fc19.x86_64.
Comment 69 Darryl L. Pierce 2013-08-17 17:34:26 EDT
I was in the middle of performing a weekly backup when my system crashed with the same messages. Looking in /var/log/messages I see the error going back to an hour earlier. I've suspended and resumed several times today, but this time the system died.

Aug 17 16:15:16 mcpierce-laptop kernel: [10081.222613] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.222620] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.222626] mei_me 0000:00:16.0: version message writet failed
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.222630] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.224727] mei_me 0000:00:16.0: reset: wrong host start response
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.224743] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225433] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225442] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225737] mei_me 0000:00:16.0: reset: wrong host start response
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225742] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225769] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225771] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225883] mei_me 0000:00:16.0: reset: wrong host start response
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.225888] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226106] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226110] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226317] mei_me 0000:00:16.0: reset: wrong host start response
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226321] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226338] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226342] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226497] mei_me 0000:00:16.0: reset: wrong host start response
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226501] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226752] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226757] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226957] mei_me 0000:00:16.0: reset: wrong host start response
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226962] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226989] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.226991] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.227091] mei_me 0000:00:16.0: reset: wrong host start response
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.227094] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.227296] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.227300] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 17 16:15:16 mcpierce-laptop kernel: [10081.227508] mei_me 0000:00:16.0: reset: wrong host start response
Comment 70 Gabriel VLASIU 2013-08-18 03:47:52 EDT
> Please test this scratch build when it completes:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5822807

Aug 18 10:35:21 xxxx -bash: HISTORY: PID=1953 USER=root UID=0 modprobe mei-me
Aug 18 10:35:26 xxxx kernel: [  273.060076] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 18 10:35:26 xxxx kernel: [  273.060093] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 18 10:35:32 xxxx kernel: [  279.072070] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 18 10:35:32 xxxx kernel: [  279.072088] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 18 10:35:38 xxxx kernel: [  285.084069] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 18 10:35:38 xxxx kernel: [  285.084088] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 18 10:35:45 xxxx kernel: [  291.096087] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 18 10:35:45 xxxx kernel: [  291.096106] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 18 10:35:51 xxxx kernel: [  297.109072] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 18 10:35:51 xxxx kernel: [  297.109092] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 18 10:35:57 xxxx kernel: [  303.120104] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 18 10:35:57 xxxx kernel: [  303.120122] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 18 10:36:03 xxxx kernel: [  309.132096] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 18 10:36:03 xxxx kernel: [  309.132113] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 18 10:36:04 xxxx -bash: HISTORY: PID=1953 USER=root UID=0 rmmod mei-me
Aug 18 10:36:04 xxxx kernel: [  310.354594] mei_me 0000:00:03.0: stop
Aug 18 10:36:05 xxxx -bash: HISTORY: PID=1953 USER=root UID=0 rmmod mei
Comment 71 Marc-Andre Laverdiere 2013-08-20 16:43:08 EDT
I am facing the same issue as Mark Wielaard on a Thinkpad T430. It happened twice today with kernel-3.10.7-200.fc19.x86_64. I have not had this before.

It happened both on the battery and when connected to the power. I am typing something, screen freeze, and /var/log/messages has a ton of such error messages.

I am going back to 3.10.5 for the time being and will update if the behavior appears on that kernel too.
Comment 72 Marc-Andre Laverdiere 2013-08-20 16:46:18 EDT
As a clarification, here are the messages in the log. They always come in pairs like this:

Aug 20 16:29:54 O8HW000506 kernel: [ 5414.919583] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 20 16:29:54 O8HW000506 kernel: [ 5414.919603] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Comment 73 John Glotzer 2013-08-20 17:24:37 EDT
Happened to me I think as soon as I updated a Thinkpad W520 from F18 to F19 but have never seen it on another machine which is a desktop which also has F19 (both x86_64). I have had 3 kernels so far on the Thinkpad --  3.10.5-201, 3.10.6-200 and 3.10.7-200 and I *think* it's happened with all three kernels but can't be 100% sure. Definitely has happened with 3.10.7 - this morning. When it happens the caps lock key blinks and it's a hard freeze with thousands of mei msgs in the logfile. I just blacklisted mei

#cat /etc/modprobe.d/mei.conf
blacklist mei
install mei /bin/true

and so far so good but it is a bit early to tell.
Comment 74 Michael Jordan 2013-08-20 17:37:43 EDT
3.10.7-200.fc19.x86_64 #1 SMP Thu Aug 15 23:19:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Same issue, and I have now enabled and configured MEI in the BIOS. I finally pulled and blacklisted mei.
Comment 75 Nils Philippsen 2013-08-23 05:21:04 EDT
(In reply to John Glotzer from comment #73)
> Definitely has happened with 3.10.7 -
> this morning. When it happens the caps lock key blinks and it's a hard
> freeze with thousands of mei msgs in the logfile.

Same here, I can attach a screenshot of the preceding kernel BUG before it panicked, if that helps.
Comment 76 rf 2013-08-23 13:17:26 EDT
I experience freezes/kernel panics daily as described above. I am running kernel 3.10.7-100.fc18.x86_64 on my Thinkpad T430.
Comment 77 Pekka Kaitaniemi 2013-08-23 14:14:05 EDT
I experienced crashes every time when resuming after suspend to RAM on my Thinkpad X301 due to this problem with Fedora 19 3.10 kernels from 3.10.6 up to and including 3.10.9-200.fc19. The workaround suggested in comment 6 and comment 7 seems to work here too.

This same issue has been reported as bug 994824 and I originally wrote my comments there.

Another thing (which may or may not be relevant)... when I produced a crash dump trying to investigate this issue today (using kernel 3.10.9-200.fc19) I managed to get a vmcore file that makes the debugger crash. The issue is tracked as bug 1000440.
Comment 78 Josh Boyer 2013-08-23 17:31:30 EDT
Here's a scratch build with all known mei patches backported.  Please test and let us know if your issue is resolved (without the mei modules blacklisted).

http://koji.fedoraproject.org/koji/taskinfo?taskID=5847415
Comment 79 Pekka Kaitaniemi 2013-08-23 18:52:44 EDT
It seems that suspend/resume works with this patched kernel (based on a few successful attempts) on my Thinkpad X301.

I have the mei module loaded:
(mael@shadow, ~) >>= lsmod | grep mei
mei_me                 18421  0 
mei                    76781  1 mei_me
Comment 80 Gabriel VLASIU 2013-08-25 03:13:10 EDT
> Here's a scratch build with all known mei patches backported.  Please test
> and let us know if your issue is resolved (without the mei modules
> blacklisted).
>
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5847415

Aug 25 10:06:37 xxxx -bash: HISTORY: PID=2074 USER=root UID=0 modprobe mei-me
Aug 25 10:06:42 xxxx kernel: [  291.116096] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 25 10:06:42 xxxx kernel: [  291.116116] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 25 10:06:48 xxxx kernel: [  297.128095] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 25 10:06:48 xxxx kernel: [  297.128114] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 25 10:06:54 xxxx kernel: [  303.141068] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 25 10:06:54 xxxx kernel: [  303.141087] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 25 10:07:00 xxxx kernel: [  309.152045] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 25 10:07:00 xxxx kernel: [  309.152065] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 25 10:07:06 xxxx kernel: [  315.164095] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 25 10:07:06 xxxx kernel: [  315.164113] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 25 10:07:07 xxxx -bash: HISTORY: PID=2074 USER=root UID=0 rmmod mei-me
Aug 25 10:07:07 xxxx kernel: [  315.963154] mei_me 0000:00:03.0: stop
Aug 25 10:07:10 xxxx -bash: HISTORY: PID=2074 USER=root UID=0 rmmod mei
Comment 81 Stefan Becker 2013-08-25 07:21:20 EDT
Adding my system to the long list. I just had another hard-freeze and it turned out that this and  the last hard-freeze from 10 days ago was caused by the same issue.

Dell Latitude E6420, BIOS A17, Fedora 19, x86_64.


Both hard-freezes happened with the 3.10.5 kernel:

Aug 11 14:11:56 XXX kernel: [    0.000000] Linux version 3.10.5-201.fc19
.x86_64 (mockbuild@bkernel01.phx2.fedoraproject.org) (gcc version 4.8.1 20130603
 (Red Hat 4.8.1-1) (GCC) ) #1 SMP Wed Aug 7 16:25:24 UTC 2013


I see the following messages in my /var/log/messages:

Aug 25 13:24:29 XXX kernel: [314167.894793] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 25 13:24:29 XXX kernel: [314167.904203] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 25 13:24:59 XXX kernel: [314197.934388] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 25 13:24:59 XXX kernel: [314197.943780] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING


According to /var/log/messages history this problem started for me with 3.10.5:

# for f in /var/log/messages*; do echo -n "$f: "; fgrep mei_me $f | fgrep RESETTING | wc -l; done
/var/log/messages: 316317
/var/log/messages-20130818: 48806
/var/log/messages-20130811: 0
/var/log/messages-20130807: 0
/var/log/messages-20130730: 0


I've now updated to 

  Linux XXX 3.10.9-200.fc19.x86_64 #1 SMP Wed Aug 21 19:27:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

and blacklisted mei & mei_me.

I tried suspend-to-RAM and suspend-to-disk and both seem to work fine. So I don't quite understand the comment "you need MEI for suspend".
Comment 82 Marco Driusso 2013-08-26 05:21:43 EDT
Same here on a Dell Latitude 6430u, Fedora 18, x86_64.

I had 3 or 4 hard-freeze caused by the same issue on different 3.10 kernels. The /var/log/messages logs are full of these messages:

Aug 25 16:12:50 xxx kernel: [16811.458792] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 25 16:12:50 xxx kernel: [16811.458800] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 25 16:12:50 xxx kernel: [16811.458807] mei_me 0000:00:16.0: version message writet failed
Aug 25 16:12:50 xxx kernel: [16811.458810] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 25 16:12:50 xxx kernel: [16811.459265] mei_me 0000:00:16.0: reset: wrong host start response
Aug 25 16:12:50 xxx kernel: [16811.459268] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

and then:

Aug 25 16:12:51 xxx kernel: [16812.157366] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 25 16:12:51 xxx kernel: [16812.157370] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 25 16:12:51 xxx kernel: [16812.157408] mei_me 0000:00:16.0: reset: wrong host start response
Aug 25 16:12:51 xxx kernel: [16812.157411] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 25 16:12:51 xxx kernel: [16812.157426] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Aug 25 16:12:51 xxx kernel: [16812.157437] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

and then:

Aug 25 17:09:57 xxx kernel: [20237.686736] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Aug 25 17:09:57 xxx kernel: [20237.686753] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Aug 25 17:10:27 xxx kernel: [20267.742203] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.

and then hard-freeze.


According to the /var/log/messages history, the problem for me started after the upgrade from kernel 3.9.11 to 3.10.6. Then every 3.10 kernel presented the issue (respectively 3.10.9-100.fc18.x86_64, kernel-3.10.7-100.fc18.x86_64 and kernel-3.10.6-100.fc18.x86_64).

# for f in /var/log/messages*; do echo -n "$f: "; fgrep mei_me $f | fgrep RESETTING | wc -l; done
/var/log/messages: 24607
/var/log/messages-20130805: 0
/var/log/messages-20130811: 0  <- kernel-3.9.11-200.fc18.x86_64
/var/log/messages-20130818: 194811  <- kernel-3.10.6-100.fc18.x86_64
/var/log/messages-20130825: 1051834


Additional informations:

$ lspci -vv -s 00:16.0
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
	Subsystem: Dell Device 0584
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 44
	Region 0: Memory at f7e3c000 (64-bit, non-prefetchable) [size=16]
	Capabilities: <access denied>
	Kernel driver in use: mei_me
Comment 83 Josh Boyer 2013-08-26 09:37:55 EDT
OK, one more scratch build to test, this time with just the 4 patches submitted for the 3.10.y stable kernel.  Thanks for testing, we appreciate it:

http://koji.fedoraproject.org/koji/taskinfo?taskID=5854464

When you test, please include the output of `uname -a` in any failure or success reports.
Comment 84 Josh Boyer 2013-08-26 10:59:32 EDT
*** Bug 1000877 has been marked as a duplicate of this bug. ***
Comment 85 Gabriel VLASIU 2013-08-26 12:28:44 EDT
> OK, one more scratch build to test, this time with just the 4 patches submitted
> for the 3.10.y stable kernel.  Thanks for testing, we appreciate it:
> 
> http://koji.fedoraproject.org/koji/taskinfo?taskID=5854464
Aug 26 19:13:36 xxxx -bash: HISTORY: PID=1626 USER=root UID=0 modprobe mei-me
Aug 26 19:13:41 xxxx kernel: [  113.652074] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 26 19:13:41 xxxx kernel: [  113.652206] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 26 19:13:47 xxxx kernel: [  119.664069] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 26 19:13:47 xxxx kernel: [  119.664219] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 26 19:13:53 xxxx kernel: [  125.676112] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 26 19:13:53 xxxx kernel: [  125.676211] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 26 19:13:59 xxxx kernel: [  131.688088] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 26 19:13:59 xxxx kernel: [  131.688239] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 26 19:14:05 xxxx kernel: [  137.700110] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 26 19:14:05 xxxx kernel: [  137.700263] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 26 19:14:11 xxxx kernel: [  143.712086] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Aug 26 19:14:11 xxxx kernel: [  143.712185] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Aug 26 19:14:12 xxxx -bash: HISTORY: PID=1626 USER=root UID=0 rmmod mei-me
Aug 26 19:14:12 xxxx kernel: [  144.470102] mei_me 0000:00:03.0: stop
Aug 26 19:14:14 xxxx -bash: HISTORY: PID=1626 USER=root UID=0 rmmod mei

> When you test, please include the output of `uname -a` in any failure or 
> success reports.
Pointless. But anyway, here it is:

# uname -a
Linux xxxx.vlasiu.net 3.10.9-200.3.fc19.x86_64 #1 SMP Mon Aug 26 14:07:13 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 86 Josh Boyer 2013-08-26 13:11:26 EDT
(In reply to Gabriel VLASIU from comment #85)
> > OK, one more scratch build to test, this time with just the 4 patches submitted
> > for the 3.10.y stable kernel.  Thanks for testing, we appreciate it:
> > 
> > http://koji.fedoraproject.org/koji/taskinfo?taskID=5854464
> Aug 26 19:13:36 xxxx -bash: HISTORY: PID=1626 USER=root UID=0 modprobe mei-me
> Aug 26 19:13:41 xxxx kernel: [  113.652074] mei_me 0000:00:03.0: reset:
> connect/disconnect timeout.
> Aug 26 19:13:41 xxxx kernel: [  113.652206] mei_me 0000:00:03.0: unexpected
> reset: dev_state = RESETTING
> Aug 26 19:13:47 xxxx kernel: [  119.664069] mei_me 0000:00:03.0: reset:
> connect/disconnect timeout.
> Aug 26 19:13:47 xxxx kernel: [  119.664219] mei_me 0000:00:03.0: unexpected
> reset: dev_state = RESETTING
> Aug 26 19:13:53 xxxx kernel: [  125.676112] mei_me 0000:00:03.0: reset:
> connect/disconnect timeout.
> Aug 26 19:13:53 xxxx kernel: [  125.676211] mei_me 0000:00:03.0: unexpected
> reset: dev_state = RESETTING
> Aug 26 19:13:59 xxxx kernel: [  131.688088] mei_me 0000:00:03.0: reset:
> connect/disconnect timeout.
> Aug 26 19:13:59 xxxx kernel: [  131.688239] mei_me 0000:00:03.0: unexpected
> reset: dev_state = RESETTING
> Aug 26 19:14:05 xxxx kernel: [  137.700110] mei_me 0000:00:03.0: reset:
> connect/disconnect timeout.
> Aug 26 19:14:05 xxxx kernel: [  137.700263] mei_me 0000:00:03.0: unexpected
> reset: dev_state = RESETTING
> Aug 26 19:14:11 xxxx kernel: [  143.712086] mei_me 0000:00:03.0: reset:
> connect/disconnect timeout.
> Aug 26 19:14:11 xxxx kernel: [  143.712185] mei_me 0000:00:03.0: unexpected
> reset: dev_state = RESETTING
> Aug 26 19:14:12 xxxx -bash: HISTORY: PID=1626 USER=root UID=0 rmmod mei-me
> Aug 26 19:14:12 xxxx kernel: [  144.470102] mei_me 0000:00:03.0: stop
> Aug 26 19:14:14 xxxx -bash: HISTORY: PID=1626 USER=root UID=0 rmmod mei

So to be clear here, if you do a fresh power on of your machine and load the mei module(s), this is what you get?  Not just from a suspend/resume, but loading them any time?

We have multiple bug reports with mei/mei_me and most of them are issues with resume.  These scratch builds seem to resolve those issues, but if my summary of the problem above is correct we'll need to look more closely here.

> > When you test, please include the output of `uname -a` in any failure or 
> > success reports.
> Pointless. But anyway, here it is:

It's not.  People keep piling onto various bugs and posting results without quoting which kernel they're running.  It's confusing to say the least, so this helps the maintainers.
Comment 87 Gabriel VLASIU 2013-08-26 13:42:46 EDT
> So to be clear here, if you do a fresh power on of your machine and load the
> mei module(s), this is what you get?
$ wget http://kojipkgs.fedoraproject.org//work/tasks/4467/5854467/kernel-3.10.9-200.3.fc19.x86_64.rpm
# yum install kernel-3.10.9-200.3.fc19.x86_64.rpm
# reboot
...
# modprobe mei-me
...
# rmmod mei-me
# rmmod mei

> Not just from a suspend/resume, but loading them any time?
From 1994 up to now, I never ever suspend/hibernate my machines. Not a single time. Not even for testing.
Those who suspend/hibernate... well, don't do it.

> It's not. People keep piling onto various bugs and posting results without
> quoting which kernel they're running.  It's confusing to say the least, so
> this helps the maintainers.
You told us to test 3.10.9-200.3. I'm not sure about others, but I will definitely not going to put results here from a different version of kernel. So for me at least, it's pointless.
Comment 88 Steve Grubb 2013-08-26 14:02:18 EDT
I also get all these errors in my logs and I never use suspend/resume - its a desktop system. Sometimes the system hangs during boot, sometimes it freezes while I'm using the computer.
Comment 89 Luca Petrucci 2013-08-26 14:57:49 EDT
Same problem here on a Lenovo notebook equipped with the Intel integrated graphic card.
It happens with all the latest 3.10 kernels (from 3.10.5). Works fine with the 3.9. branch.
Blacklisting the mei modules solves the problem.
Regards.
Comment 90 markzzzsmith 2013-08-26 17:05:00 EDT
(In reply to Gabriel VLASIU from comment #87)
> > So to be clear here, if you do a fresh power on of your machine and load the
> > mei module(s), this is what you get?
> $ wget
> http://kojipkgs.fedoraproject.org//work/tasks/4467/5854467/kernel-3.10.9-200.
> 3.fc19.x86_64.rpm
> # yum install kernel-3.10.9-200.3.fc19.x86_64.rpm
> # reboot
> ...
> # modprobe mei-me
> ...
> # rmmod mei-me
> # rmmod mei
> 
> > Not just from a suspend/resume, but loading them any time?
> From 1994 up to now, I never ever suspend/hibernate my machines. Not a
> single time. Not even for testing.
> Those who suspend/hibernate... well, don't do it.
> 

So when I get my electricity bill, you'll send me some money to cover running my desktop running 24x7, instead of now suspending/hibernating it for the around 15 hours a day when I'm not using it?

Just because you've never had a reason to suspend/hibernate, doesn't mean others don't have a good reason to do so.

> > It's not. People keep piling onto various bugs and posting results without
> > quoting which kernel they're running.  It's confusing to say the least, so
> > this helps the maintainers.
> You told us to test 3.10.9-200.3. I'm not sure about others, but I will
> definitely not going to put results here from a different version of kernel.
> So for me at least, it's pointless.
Comment 91 markzzzsmith 2013-08-26 17:08:30 EDT
(In reply to Luca Petrucci from comment #89)
> Same problem here on a Lenovo notebook equipped with the Intel integrated
> graphic card.
> It happens with all the latest 3.10 kernels (from 3.10.5). Works fine with
> the 3.9. branch.
> Blacklisting the mei modules solves the problem.

Actually it doesn't solve the problem. All it does is stops the log messages - the symptom. Blacklisting the mei module will cause the MEI watchdog to reboot 30 seconds after returning from suspend.

> Regards.
Comment 92 Dimitris 2013-08-26 22:10:10 EDT
Some of this seems hardware (generation) dependent to me.

I built Josh's 3.10.9-200.3 scratch kernel from its source RPM (more on why below) and it does seem to fix the few warnings that mei_me was emitting under 3.10.{6,7,9} on this older (Montevina vintage) Thinkpad.

(Note that hangs/freezes were no longer a problem on this machine, without any patches, as of 3.10.6 from @updates, when mei_me was again configured as a module (which I did not blacklist).)

Now, the reason I built from source (other than my mild paranoia of being able to diff -r against the @updates SRPM) was that the last/fourth diff in mei-3.10.y.patch was one I hadn't seen before, and can't find in the git.kernel.org linux-stable tree.  Also couldn't find any feedback on it on LKML other than the author's posting.  The other three I had already tried with 3.10.4 and they again did the trick on this machine.  As it happens the full set of patches also work fine here.

Hope this helps more than confuses :)
Comment 93 Dimitris 2013-08-26 22:36:51 EDT
> can't find in the git.kernel.org linux-stable tree

It's there, among other changes (not backported in the scratch build) that seem to be getting staged for 3.11:

https://git.kernel.org/cgit/linux/kernel/git/gregkh/char-misc.git/log/drivers/misc/mei?h=char-misc-next
Comment 94 Marco Driusso 2013-08-27 05:36:30 EDT
> So to be clear here, if you do a fresh power on of your machine and load the
> mei module(s), this is what you get?  Not just from a suspend/resume, but
> loading them any time?
> 
> We have multiple bug reports with mei/mei_me and most of them are issues
> with resume.  These scratch builds seem to resolve those issues, but if my
> summary of the problem above is correct we'll need to look more closely here.

In my case the hard-freezes seem to happen randomly.
The resason why I ascribe the mei module to be the cause of the freezes is that every time my system freezed, the /var/log/messages presented tons of "mei_me RESETTING" messages at the time of the freeze.
Comment 95 Stefan Becker 2013-08-27 06:55:42 EDT
(In reply to Stefan Becker from comment #81)
> Dell Latitude E6420, BIOS A17, Fedora 19, x86_64.
> ...
> I've now updated to 
> 
>   Linux XXX 3.10.9-200.fc19.x86_64 #1 SMP Wed Aug 21 19:27:58 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
> 
> and blacklisted mei & mei_me.
> 
> I tried suspend-to-RAM and suspend-to-disk and both seem to work fine. So I
> don't quite understand the comment "you need MEI for suspend".

I went through all the options in the BIOS and couldn't find anything about the management engine. I tried the "CTRL+P" during boot -> nothing.

So I can only assume that ME is disabled on this laptop HW and that's why suspend/resume works without mei(_me) modules loaded.
Comment 96 Martijn Faassen 2013-08-27 12:32:33 EDT
I'm having hard freezes at random times possibly hours after resume, but so far they've *only* happened after a resume. After a fresh reboot I don't have the freezes, however. The kernel log is full of the mei stuff.

So I strongly suspect that in my case the wake up from resume triggers a crash later.
Comment 97 James 2013-08-28 03:01:49 EDT
I have the same issue in F18 with kernel 3.10.9-100.fc18.x86_64. Just blacklisted mei_me and mei, let's see if it helps.

We have not seen such bad kernel hang issues in Fedora in a long time. I mean, the system felt like Windows for a while. I don't quite understand why the severity of this bug has been determined to be low.
Comment 98 Marc-Andre Laverdiere 2013-08-28 20:50:01 EDT
I just had a freeze today, and the last messages are repeated

mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

Since that system was unattended at that moment, I do not know what would've happened. I am running 3.10.9-200.fc19.x86_64.
Comment 99 Edouard Lefebvre 2013-08-29 07:04:37 EDT
I had a freeze this morning too, with kernel 3.10.9-200.fc19.x86_64 :

mei_me 0000:00:16.0: reset: wrong host start response
mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Comment 100 kubrick@fgv6.net 2013-08-29 07:49:33 EDT
*** Bug 1002492 has been marked as a duplicate of this bug. ***
Comment 101 Josh Boyer 2013-08-29 09:38:24 EDT
I emailed the upstream maintainer of the mei drivers.  Apparently when they added support for newer hardware, they introduced a reset recursion on some older machines.  They're working on fixing it, but there is no solution at the moment.

For everyone that cannot even load the drivers without them looping in reset, can you please attached the output of dmidecode as a plain text attachment.  I might be able to introduce a blacklist in the driver as a temporary workaround.  In effect this is the same thing as just blacklisting it via the module blacklist, just in the driver itself.
Comment 102 Tom Horsley 2013-08-29 10:21:55 EDT
Created attachment 791841 [details]
dmidecode for my dell optiplex 755
Comment 103 Jeremy Uchitel 2013-08-29 13:36:21 EDT
Created attachment 791919 [details]
dmidecode output on HP tm2t-2100

I am also seeing the reset messages that freeze my system under F19.  Currently running 3.10.9-200 kernel. This did not happen with older kernels under F18.  Freezes seem to occur at random and not necessarily after a wake-up from suspend.
Comment 104 Dimitris 2013-08-29 14:20:05 EDT
Created attachment 791935 [details]
dmidecode for Thinkpad X200s

The mei-3.10.y.patch in kernel 3.10.9-200.3.fc19.x86_64 fixes this problem on this machine.  However, without the patch:

- Kernels 3.10.{6,7,9}:  Driver is built and loaded as a module, no blacklist:  One or two messages like:

> Aug 23 14:47:52 gaspode kernel: mei_me 0000:00:03.0: version message writet failed
> Aug 23 14:47:52 gaspode kernel: mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING

appear in the log after resumes from suspend or hibernate, but no system hangs.

- Kernels 3.10.{3,4}:  Driver was built in:  After resume from suspend/hibernate, I saw huge numbers of these messages.  Occasionally, after (but not immediately after) a resume, I'd see system hangs.

The message storm in these older kernels also seemed to trigger a problem in systemd-journald (bug 990323).  That happened right after resume.
Comment 105 Nils Philippsen 2013-08-30 04:09:58 EDT
Created attachment 792080 [details]
dmidecode for Thinkpad T520
Comment 106 filip.brinkmann 2013-08-30 05:19:30 EDT
Created attachment 792092 [details]
dmidecode for Thinkpad T420
Comment 107 Fabrice Salvaire 2013-09-01 08:18:25 EDT
Created attachment 792590 [details]
DMI decode output for Lenovo T430
Comment 108 Darryl L. Pierce 2013-09-01 09:59:48 EDT
Created attachment 792595 [details]
Darryl Pierce - Lenovo T530 MEI error log entries

output from /var/log/messages between the time my laptop resumed and the mei error occurred.
Comment 109 Karel Volný 2013-09-04 04:28:06 EDT
(In reply to Darryl L. Pierce from comment #108)
> Created attachment 792595 [details]
> Darryl Pierce - Lenovo T530 MEI error log entries
> 
> output from /var/log/messages between the time my laptop resumed and the mei
> error occurred.

+1 for another T530; messages look very similar (except that I didn't have usb flash attached, but there are the same NM errors etc.)
Comment 110 Mark Goodwin 2013-09-04 21:56:17 EDT
getting hard lockups on a f19/T520 every now and then. Same MEI messages as already reported immediately prior to the hang. Have upgraded to latest f19 3.10.10-200.fc19 ...
Comment 111 Patrick Uiterwijk 2013-09-05 09:11:21 EDT
Hitting the same error messages on a X230 with kernel 3.10.10-200.fc19.x86_64.
It filled my 35G free on / in about 30 minutes.
Comment 112 Paolo Leoni 2013-09-05 11:23:27 EDT
Same problem here. Filling free space (about 40GB) in some minutes.
/var/log/messages grow without limit.
Comment 113 Luca Petrucci 2013-09-05 12:19:41 EDT
After blacklisting the mei module, I had no more lockups or strange mei messages from the kernel.
Comment 114 Mohammed Arafa 2013-09-05 20:31:56 EDT
ditto here

[root@notebook log]# lsmod  | grep -i mei
mei_me                 18568  0 
mei                    76656  1 mei_me
[root@notebook log]# lspci | grep -i mei
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
[root@notebook log]# 

Sep  5 20:26:06 notebook kernel: [77989.162770] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep  5 20:26:06 notebook kernel: [77989.162773] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep  5 20:26:06 notebook kernel: [77989.162786] mei_me 0000:00:16.0: reset: wrong host start response

[root@notebook log]# uname -rm
3.10.10-200.fc19.x86_64 x86_64


also this is the first time i notice it.
Comment 115 markusN 2013-09-06 00:49:40 EDT
same message flooding here, eating my disk space:

...
Sep  6 06:47:18 oboe kernel: [21152.371031] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep  6 06:47:18 oboe kernel: [21152.371034] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep  6 06:47:18 oboe kernel: [21152.371066] mei_me 0000:00:16.0: reset: wrong host start response
Sep  6 06:47:18 oboe kernel: [21152.371069] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep  6 06:47:18 oboe kernel: [21152.371082] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep  6 06:47:18 oboe kernel: [21152.371085] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep  6 06:47:18 oboe kernel: [21152.371116] mei_me 0000:00:16.0: reset: wrong host start response
Sep  6 06:47:18 oboe kernel: [21152.371119] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep  6 06:47:18 oboe kernel: [21152.371132] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep  6 06:47:18 oboe kernel: [21152.371135] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep  6 06:47:18 oboe kernel: [21152.371167] mei_me 0000:00:16.0: reset: wrong host start response^C

[root@oboe log]# lspci | grep -i mei
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)

[root@oboe log]# dmidecode -s bios-version
X202E.206

[root@oboe log]# uname -a
Linux oboe.localdomain 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
Comment 116 markusN 2013-09-06 01:20:41 EDT
(In reply to markusN from comment #115)
> same message flooding here, eating my disk space:
>
...
> [root@oboe log]# dmidecode -s bios-version
> X202E.206
> 
> [root@oboe log]# uname -a
> Linux oboe.localdomain 3.10.10-200.fc19.x86_64 #1 SMP Thu Aug 29 19:05:45
> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

lspci -v
00:16.0 Communication controller: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 (rev 04)
	Subsystem: ASUSTeK Computer Inc. Device 108d
	Flags: bus master, fast devsel, latency 0, IRQ 43
	Memory at f7e22000 (64-bit, non-prefetchable) [size=16]
	Capabilities: <access denied>
	Kernel driver in use: mei_me

I could apparently stop the mei_me message flooding with

yum remove libva-intel-driver
(which provides HW video decode support for Intel integrated graphics.
 /usr/lib64/dri/i965_drv_video.so)

and then reboot (and delete the flooded /var/log/messages file(s)).

Related kernel list discussion:
https://lkml.org/lkml/2013/7/30/680
"mei: me: fix hardware reset flow"
Comment 117 markusN 2013-09-06 04:27:51 EDT
(In reply to markusN from comment #116)
> I could apparently stop the mei_me message flooding with
> 
> yum remove libva-intel-driver

I spoke to fast, the problem came back at next resume.

> Related kernel list discussion:
> https://lkml.org/lkml/2013/7/30/680
> "mei: me: fix hardware reset flow"
Comment 118 Michael Jordan 2013-09-06 07:09:49 EDT
Odd thing is, I have identical hardware running Ubuntu server

Linux mach2 3.2.0-52-generic #78-Ubuntu SMP Fri Jul 26 16:21:44 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

mei module has been running - and I haven't had a bit of trouble out of it. No log spamming.
Comment 119 Josh Boyer 2013-09-06 07:58:11 EDT
(In reply to markusN from comment #117) 
> > Related kernel list discussion:
> > https://lkml.org/lkml/2013/7/30/680
> > "mei: me: fix hardware reset flow"

We're already carrying that patch.
Comment 120 Josh Boyer 2013-09-06 07:59:38 EDT
(In reply to Michael Jordan from comment #118)
> Odd thing is, I have identical hardware running Ubuntu server
> 
> Linux mach2 3.2.0-52-generic #78-Ubuntu SMP Fri Jul 26 16:21:44 UTC 2013
> x86_64 x86_64 x86_64 GNU/Linux
> 
> mei module has been running - and I haven't had a bit of trouble out of it.
> No log spamming.

That isn't odd.  That's a much older kernel.  As I mentioned in comment #101, the issue came with they added new hardware support to the driver.
Comment 121 Markus 2013-09-09 18:49:48 EDT
Still present on 3.10.10-200.fc19.i686 on a brand new Lenovo B590 laptop, log file is now 22GB and grew 4GB in 15 minutes. messages was spammed with the following (i.e. nothing new I suppose):

Sep 10 08:33:54 localhost kernel: [111723.801484] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801497] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.801500] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801531] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.801534] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801548] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.801550] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801581] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.801584] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801598] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.801600] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801631] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.801634] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801660] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.801663] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801677] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.801680] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801799] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.801804] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801820] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.801824] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801864] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.801867] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801881] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.801884] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801958] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.801963] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.801978] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.801983] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.802023] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.802026] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.802040] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.802043] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.802116] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:33:54 localhost kernel: [111723.802121] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.802151] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 10 08:33:54 localhost kernel: [111723.802174] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 10 08:33:54 localhost kernel: [111723.802191] mei_me 0000:00:16.0: stop
Sep 10 08:33:54 localhost kernel: [111723.802209] mei_me 0000:00:16.0: reset: wrong host start response
Sep 10 08:34:01 localhost kernel: [111730.808168] mei_me 0000:00:16.0: wait hw ready failed. status = -110

Bug is also accompanied by high CPU usage. Removing and reloading the module works at times but whether this trick works seems completely random.
Comment 122 Markus 2013-09-09 18:56:24 EDT
Created attachment 795767 [details]
dmidecode for Lenovo B590
Comment 123 Mukundan Ragavan 2013-09-10 12:45:22 EDT
Just a me too.

# uname -r
3.10.10-200.fc19.x86_64
Comment 124 Josh Boyer 2013-09-11 10:31:30 EDT
*** Bug 1006939 has been marked as a duplicate of this bug. ***
Comment 125 sanbor 2013-09-12 11:52:11 EDT
Hello there! A coworker convinced me to try Fedora. I drop my Ubuntu and tried Fedora for my daily work.

After one day of using it, I started to have Mysql problems. I tried to restart the mysql service and systemd was giving me errors.
I tried to reinstall mariadb-server and got a disk-full error.

After some research I discovered that my disk was full. The workaround was to do "rm /var/log/messages && ln -sf /dev/null /var/log/messages".

The reason that I'm telling the complete story is in order to get someone to change the priority and severity of this bug because it's affecting users.
Comment 126 Amir Aharoni 2013-09-12 12:30:03 EDT
I am still happy about Fedora despite this bug. It should be properly fixed of course. Until it's properly fixed, this workaround seems to be working for me:

1. Add the following lines to /etc/modprobe.d/blacklist.conf
blacklist mei
blacklist mei_me

2. Run `sudo dracut --force`.

3. Delete the overblown /var/log/messages if needed.

4. Reboot.

This seems to have resolved the problem. This assumes that you don't actually need the functionality provided by this module. I am actually still not compltely sure that I know what does it do, but before doing the workaround I experienced excessive writing to /var/log/messages after every suspend operation and now this doesn't happen anymore and the suspend function still works well.

Use this at your own risk, of course.
Comment 127 John Glotzer 2013-09-12 14:34:56 EDT
Yeah I'd have to agree - the severity is ranked "low" while the priority is ranked "unspecified". If a kernel crash (or freeze which is functionally the same since you have to power cycle the box to get back to a working state) is "low" - then what has to go wrong to merit getting rated "high" severity? What is worse than a kernel crash?

If the answer is that this is because "not all" hardware is affected (which is true) - judging by the number or contributors to this bugzilla it may be "not all" but it is still "quite a lot". I think the priority and the severity should both be raised.
Comment 128 Josh Boyer 2013-09-12 15:06:39 EDT
Being 100% transparent, the priority and severity fields in bugzilla are ignored.  They're user settable, which means everyone that reports a bug thinks their bug is high priority and extremely severe because it's impacting them on their machine.  The maintainers, who have to take a wider view, would waste a lot of time mucking with those settings and arguing over them.  So we ignore them.

This bug isn't forgotten.
Comment 129 Oliver Ruebenacker 2013-09-12 15:11:26 EDT
How about voting for a bug? Wouldn't that produce the widest possible view?
Comment 130 Josh Boyer 2013-09-12 16:07:19 EDT
My apologies.  Earlier I had asked for the output of dmidecode, and I should have also asked for the output of lscpi -nnvv.  Those impacted, please attach that as well.
Comment 131 Darryl L. Pierce 2013-09-12 16:13:46 EDT
From my Lenovo W530:
00:00.0 Host bridge [0600]: Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09)
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: <access denied>

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200 v2/3rd Gen Core processor PCI Express Root Port [8086:0151] (rev 09) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00005000-00005fff
	Memory behind bridge: f2000000-f30fffff
	Prefetchable memory behind bridge: 00000000e0000000-00000000f1ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:14.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB xHCI Host Controller [8086:1e31] (rev 04) (prog-if 30 [XHCI])
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 42
	Region 0: Memory at f5320000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: <access denied>
	Kernel driver in use: xhci_hcd

00:16.0 Communication controller [0780]: Intel Corporation 7 Series/C210 Series Chipset Family MEI Controller #1 [8086:1e3a] (rev 04)
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 43
	Region 0: Memory at f5335000 (64-bit, non-prefetchable) [size=16]
	Capabilities: <access denied>
	Kernel driver in use: mei_me

00:16.3 Serial controller [0700]: Intel Corporation 7 Series/C210 Series Chipset Family KT Controller [8086:1e3d] (rev 04) (prog-if 02 [16550])
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 19
	Region 0: I/O ports at 6070 [size=8]
	Region 1: Memory at f533c000 (32-bit, non-prefetchable) [size=4K]
	Capabilities: <access denied>
	Kernel driver in use: serial

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)
	Subsystem: Lenovo Device [17aa:21f3]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 44
	Region 0: Memory at f5300000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at f533b000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at 6040 [size=32]
	Capabilities: <access denied>
	Kernel driver in use: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #2 [8086:1e2d] (rev 04) (prog-if 20 [EHCI])
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f533a000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci

00:1b.0 Audio device [0403]: Intel Corporation 7 Series/C210 Series Chipset Family High Definition Audio Controller [8086:1e20] (rev 04)
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 45
	Region 0: Memory at f5330000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 1 [8086:1e10] (rev c4) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 00004000-00004fff
	Memory behind bridge: f4a00000-f52fffff
	Prefetchable memory behind bridge: 00000000f3100000-00000000f38fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 2 [8086:1e12] (rev c4) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	Memory behind bridge: f4900000-f49fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.2 PCI bridge [0604]: Intel Corporation 7 Series/C210 Series Chipset Family PCI Express Root Port 3 [8086:1e14] (rev c4) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=04, subordinate=0b, sec-latency=0
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: f4100000-f48fffff
	Prefetchable memory behind bridge: 00000000f3900000-00000000f40fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1d.0 USB controller [0c03]: Intel Corporation 7 Series/C210 Series Chipset Family USB Enhanced Host Controller #1 [8086:1e26] (rev 04) (prog-if 20 [EHCI])
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at f5339000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci

00:1f.0 ISA bridge [0601]: Intel Corporation QM77 Express Chipset LPC Controller [8086:1e55] (rev 04)
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: <access denied>
	Kernel driver in use: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 7 Series Chipset Family 6-port SATA Controller [AHCI mode] [8086:1e03] (rev 04) (prog-if 01 [AHCI 1.0])
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 41
	Region 0: I/O ports at 6068 [size=8]
	Region 1: I/O ports at 607c [size=4]
	Region 2: I/O ports at 6060 [size=8]
	Region 3: I/O ports at 6078 [size=4]
	Region 4: I/O ports at 6020 [size=32]
	Region 5: Memory at f5338000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 7 Series/C210 Series Chipset Family SMBus Controller [8086:1e22] (rev 04)
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin C routed to IRQ 18
	Region 0: Memory at f5334000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at efa0 [size=32]
	Kernel driver in use: i801_smbus

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF108M [NVS 5400M] [10de:0def] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 3: Memory at f0000000 (64-bit, prefetchable) [size=32M]
	Region 5: I/O ports at 5000 [size=128]
	Expansion ROM at f3080000 [disabled] [size=512K]
	Capabilities: <access denied>
	Kernel driver in use: nouveau

01:00.1 Audio device [0403]: NVIDIA Corporation GF108 High Definition Audio Controller [10de:0bea] (rev a1)
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 17
	Region 0: Memory at f3000000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel

02:00.0 System peripheral [0880]: Ricoh Co Ltd PCIe SDXC/MMC Host Controller [1180:e823] (rev 08) (prog-if 01)
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f4a01000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <access denied>
	Kernel driver in use: sdhci-pci

02:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller [1180:e832] (rev 04) (prog-if 10 [OHCI])
	Subsystem: Lenovo Device [17aa:21f6]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 19
	Region 0: Memory at f4a00000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: firewire_ohci

03:00.0 Network controller [0280]: Intel Corporation Centrino Ultimate-N 6300 [8086:4238] (rev 3e)
	Subsystem: Intel Corporation Centrino Ultimate-N 6300 3x3 AGN [8086:1111]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 46
	Region 0: Memory at f4900000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi
Comment 132 Michael Jordan 2013-09-12 16:27:11 EDT
[michael@mach1 davinci]$ sudo lspci -nnvv | gzip > mj_lspci.gz

Attached
Comment 133 Dimitris 2013-09-12 16:27:55 EDT
Created attachment 797018 [details]
lspci -nnvv for Thinkpad X200s

Impact is conditional, see comment 104.  Also, the patches in kernel 3.10.10-200.fc19 do seem to address this.
Comment 134 Mukundan Ragavan 2013-09-12 16:28:45 EDT
lspci from my Lenovo T520



00:00.0 Host bridge [0600]: Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0104] (rev 09)
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: <access denied>

00:01.0 PCI bridge [0604]: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port [8086:0101] (rev 09) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 00005000-00005fff
	Memory behind bridge: f2000000-f30fffff
	Prefetchable memory behind bridge: 00000000e0000000-00000000f1ffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:16.0 Communication controller [0780]: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04)
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 42
	Region 0: Memory at f5225000 (64-bit, non-prefetchable) [size=16]
	Capabilities: <access denied>
	Kernel driver in use: mei_me

00:19.0 Ethernet controller [0200]: Intel Corporation 82579LM Gigabit Network Connection [8086:1502] (rev 04)
	Subsystem: Lenovo Device [17aa:21ce]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 43
	Region 0: Memory at f5200000 (32-bit, non-prefetchable) [size=128K]
	Region 1: Memory at f522b000 (32-bit, non-prefetchable) [size=4K]
	Region 2: I/O ports at 6040 [size=32]
	Capabilities: <access denied>
	Kernel driver in use: e1000e

00:1a.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 [8086:1c2d] (rev 04) (prog-if 20 [EHCI])
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f522a000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci

00:1b.0 Audio device [0403]: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller [8086:1c20] (rev 04)
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 44
	Region 0: Memory at f5220000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel

00:1c.0 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 [8086:1c10] (rev b4) (prog-if 00 [Normal decode])
	Control: I/O- Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.1 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 2 [8086:1c12] (rev b4) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	Memory behind bridge: f5100000-f51fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.3 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 [8086:1c16] (rev b4) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=05, subordinate=0c, sec-latency=0
	I/O behind bridge: 00004000-00004fff
	Memory behind bridge: f4900000-f50fffff
	Prefetchable memory behind bridge: 00000000f3100000-00000000f38fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1c.4 PCI bridge [0604]: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 [8086:1c18] (rev b4) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Bus: primary=00, secondary=0d, subordinate=0d, sec-latency=0
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: f4100000-f48fffff
	Prefetchable memory behind bridge: 00000000f3900000-00000000f40fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: <access denied>
	Kernel driver in use: pcieport

00:1d.0 USB controller [0c03]: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 [8086:1c26] (rev 04) (prog-if 20 [EHCI])
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 23
	Region 0: Memory at f5229000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>
	Kernel driver in use: ehci-pci

00:1f.0 ISA bridge [0601]: Intel Corporation QM67 Express Chipset Family LPC Controller [8086:1c4f] (rev 04)
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Capabilities: <access denied>
	Kernel driver in use: lpc_ich

00:1f.2 SATA controller [0106]: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04) (prog-if 01 [AHCI 1.0])
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin B routed to IRQ 41
	Region 0: I/O ports at 6068 [size=8]
	Region 1: I/O ports at 607c [size=4]
	Region 2: I/O ports at 6060 [size=8]
	Region 3: I/O ports at 6078 [size=4]
	Region 4: I/O ports at 6020 [size=32]
	Region 5: Memory at f5228000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: ahci

00:1f.3 SMBus [0c05]: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller [8086:1c22] (rev 04)
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin C routed to IRQ 18
	Region 0: Memory at f5224000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at efa0 [size=32]
	Kernel driver in use: i801_smbus

01:00.0 VGA compatible controller [0300]: NVIDIA Corporation GF119M [Quadro NVS 4200M] [10de:1057] (rev a1) (prog-if 00 [VGA controller])
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f2000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 3: Memory at f0000000 (64-bit, prefetchable) [size=32M]
	Region 5: I/O ports at 5000 [size=128]
	[virtual] Expansion ROM at f3080000 [disabled] [size=512K]
	Capabilities: <access denied>
	Kernel driver in use: nvidia

01:00.1 Audio device [0403]: NVIDIA Corporation GF119 HDMI Audio Controller [10de:0e08] (rev a1)
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin B routed to IRQ 17
	Region 0: Memory at f3000000 (32-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>
	Kernel driver in use: snd_hda_intel

03:00.0 Network controller [0280]: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] [8086:0085] (rev 34)
	Subsystem: Intel Corporation Centrino Advanced-N 6205 AGN [8086:1311]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 45
	Region 0: Memory at f5100000 (64-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>
	Kernel driver in use: iwlwifi

0d:00.0 System peripheral [0880]: Ricoh Co Ltd MMC/SD Host Controller [1180:e822] (rev 08) (prog-if 01)
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f4101000 (32-bit, non-prefetchable) [size=256]
	Capabilities: <access denied>
	Kernel driver in use: sdhci-pci

0d:00.3 FireWire (IEEE 1394) [0c00]: Ricoh Co Ltd R5C832 PCIe IEEE 1394 Controller [1180:e832] (rev 04) (prog-if 10 [OHCI])
	Subsystem: Lenovo Device [17aa:21cf]
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 64 bytes
	Interrupt: pin D routed to IRQ 19
	Region 0: Memory at f4100000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>
	Kernel driver in use: firewire_ohci




Also attached.
Comment 135 Michael Jordan 2013-09-12 16:28:54 EDT
Created attachment 797019 [details]
lspci -nnvv
Comment 136 Mukundan Ragavan 2013-09-12 16:30:42 EDT
Created attachment 797020 [details]
lspci -nnvv (comment was not good)
Comment 137 Dmitri A. Sergatskov 2013-09-12 17:21:40 EDT
Created attachment 797033 [details]
lspci -nnvv

3.10.9-200.2.fc19.x86_64 is good
all other recent kernels bad (computer hangs)

i7-2600K + dz68bc intel m/b
Comment 138 Tom Horsley 2013-09-12 18:07:48 EDT
Created attachment 797041 [details]
lspci -nnvv for my dell optiplex 755

This goes with the dmidecode output in attachment 791841 [details] (same machine)
Comment 139 Marco Driusso 2013-09-13 02:59:37 EDT
Created attachment 797160 [details]
dmidecode Dell Latitude 6430u
Comment 140 Marco Driusso 2013-09-13 03:01:14 EDT
Created attachment 797162 [details]
lspci -nnvv Dell Latitude 6430u
Comment 141 Milan Bouchet-Valat 2013-09-13 03:55:43 EDT
Created attachment 797200 [details]
dmidecode for HP Pavilion dm4
Comment 142 Milan Bouchet-Valat 2013-09-13 03:56:30 EDT
Created attachment 797201 [details]
lspci -vnn for HP Pavilion dm4
Comment 143 Mohammed Arafa 2013-09-13 06:39:42 EDT
Created attachment 797261 [details]
lenovo t420

lenovo t420 lspci -nnvv for mei bug
Comment 144 Vetoshkin Nikita 2013-09-13 06:55:30 EDT
Created attachment 797284 [details]
lspci -nnvv for lenovo t520 (with nvidia)
Comment 145 Patrick C. F. Ernzer 2013-09-13 07:33:03 EDT
Created attachment 797300 [details]
dmidecode ThinkPad x230
Comment 146 Patrick C. F. Ernzer 2013-09-13 07:34:00 EDT
Created attachment 797301 [details]
lspci -nnvv ThinkPad x230
Comment 147 kubrick@fgv6.net 2013-09-13 07:56:16 EDT
Created attachment 797306 [details]
lspci -nnvv ThinkPad T430
Comment 148 sanbor 2013-09-13 09:37:51 EDT
Created attachment 797339 [details]
lspci -nnvv

lspci -nnvv of my machine that was having problems. I have disabled the log of kernel messages from systemd in order to avoid message spamming. My computer is a notebook Asus k55a
Comment 149 sanbor 2013-09-13 09:39:37 EDT
Created attachment 797340 [details]
dmidecode -s bios-version

dmidecode -s bios-version from asus k55a
Comment 150 sanbor 2013-09-13 09:40:47 EDT
Created attachment 797341 [details]
uname -a

uname -a from asus k55a
Comment 151 Marco Driusso 2013-09-13 09:44:49 EDT
In my case (Dell Latitude 6430u, dmidecode and lspci attached; Fedora 18 x86) blacklisting the mei and mei_me drivers worked and since then I had no hard freezes and no mei message spamming in /var/log/messages.
Comment 152 Mike Gahagan 2013-09-13 11:38:13 EDT
Created attachment 797392 [details]
dmesg, lspci -nvv, dmidecode for Lenovo T520 with mei blacklisted
Comment 153 Jim McElwaine 2013-09-13 16:24:01 EDT
I think I have this bug too on an ASUS UX51V
I get log messages like
Sep 13 18:14:31 ezo kernel: [ 1337.726669] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
Sep 13 18:14:31 ezo kernel: [ 1337.726682] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.


These accumulate at a rate of around 30GB and hour!

Needless to say this is not good on a  machine with SSD and about as serious as a bug can be. After using linux for 20 years I'm also pretty amazed that my machine now regularly hangs and has to be rebooted.
Comment 154 sanbor 2013-09-13 16:41:04 EDT
Today I did yum upgrade and I got a new version of kernel that might solve the problem.

I'm saying might because I have disabled the kernel logging in order to avoid the flood of messages in /var/log/messages.
What I did is to edit the rsyslog with vi:
vi /etc/rsyslog.conf
And comment the following line
#$ModLoad imklog   # provides kernel logging support (previously done by rklogd)

Save and quit (:x) and restart systemctl:
systemctl --system daemon-reload
Comment 155 Andrew Cowie 2013-09-13 20:34:12 EDT
Latest Fedora 19 kernel 3.10.11-200.fc19.x86_64 did not fix the problem; when it triggers several GB of logs every ten minutes filling up the root partition; this time I only caught it because I heard the fan going...

AfC
Comment 156 Markus 2013-09-14 01:45:06 EDT
Created attachment 797554 [details]
Lenovo B590 'lspci -nnvv' output
Comment 157 Markus 2013-09-14 01:48:53 EDT
Seem to accidentally have created the attachment as a patch. Never mind that.
Comment 158 Nils Philippsen 2013-09-16 09:25:50 EDT
Created attachment 798282 [details]
lspci -nnvv from Lenovo Thinkpad T520 with mei module blacklisted
Comment 159 Will Foster 2013-09-17 04:41:07 EDT
I can confirm this happens to me as well ::

kernel: 3.10.11-200.fc19.x86_64
dist:     Fedora 19 x86_64 (latest errata)
model: Thinkpad T420s

(attached lspci -nnvv)
I have the mei and mei_me modules blacklisted

This has not occurred since removing the "mei" modules.

== I did the following to blacklist the modules ==

echo "blacklist mei_me" > /etc/modprobe.d/blacklist-mei.conf
echo "blacklist mei" >> /etc/modprobe.d/blacklist-mei.conf

cp /etc/default/grub /etc/default/grub.bak
sed -i 's/quiet/rdblacklist=mei rdblacklist=mei_me quiet/' /etc/default/grub
grub2-mkconfig -o /boot/grub2/grub.cfg

<reboot>
Comment 160 Will Foster 2013-09-17 04:43:30 EDT
Created attachment 798677 [details]
lspci -nnvv from Thinkpad T420s (blacklisted MEI module)
Comment 161 Mikkel Lauritsen 2013-09-18 03:04:06 EDT
Created attachment 799135 [details]
lspci -nnvv

Just a quick "me too"; lspci -nnvv attached.
Comment 162 Robert Binkhorst 2013-09-19 04:28:50 EDT
quick me too on this one:

Sep 19 10:10:48 server kernel: [745589.645120] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
Sep 19 10:10:48 server kernel: [745589.645123] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)

On a Thinkpad x220

These messages are filling up my root partition.
Comment 163 sara.alderweireldt@gmail.com 2013-09-19 06:05:24 EDT
and me too:

Sep 19 11:28:09 schrodinger kernel: [ 5052.005565] mei_me 0000:00:16.0: reset: init clients timeout hbm_state = 1.
Sep 19 11:28:09 schrodinger kernel: [ 5052.005576] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING

Running kernel: 3.10.11-200.fc19.x86_64
On a Zenbook UX31a

No problems after switching back to 3.10.9-200.fc19.x86_64.
I've just gotten 3.11.1-200.fc19.x86_64, let's see where that takes me.
Comment 164 Dmitri A. Sergatskov 2013-09-19 09:31:33 EDT
3.10.9-200 and now 3.11.1-200 are the only kernels out of the recent batch which
work fine on my machine (i7-2600K + dz68bc intel m/b

Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 [8086:1c3a] (rev 04))
Comment 165 Dobmec 2013-09-19 11:32:23 EDT
I had the same problem on a ASUS UX31A since kernel 3.10. I noticed it when the system told me that I had no more space on my / partition, with a /var/log/messages of about 50G (On a SSD...).
I found the following temporary workaround: when the flood of mei_me messages started (usually after each suspend to ram), I called the instruction 
echo 0000:00:16.0 > /sys/bus/pci/drivers/mei_me/unbind

Now, it seems that the last kernel update to 3.11.1-200 fixed the problem...
Comment 166 Kevin 2013-09-24 08:57:59 EDT
Created attachment 802213 [details]
lspci -nnvv 3.10.11 Fedora 19 Fujitsu T901

uname -r
3.10.11-200.fc19.x86_64

Fujitsu T901, convertable laptop.

Resumed, after ~30minutes noticed fan spinning and heat. irq/47-mei_me using 90% cpu, rsyslog 35%.

dmesg | grep -i mei
[49789.961421] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[49789.961434] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
*Wall of repeating errors sniped*
[49789.988288] mei_me 0000:00:16.0: reset: unexpected enumeration response hbm.
[49789.988290] mei_me 0000:00:16.0: unexpected reset: dev_state = RESETTING
[49789.988292] mei_me 0000:00:16.0: suspend
[49789.988311] mei_me 0000:00:16.0: reset: wrong host start response
[49796.996366] mei_me 0000:00:16.0: wait hw ready failed. status = -110
[49797.257348] mei_me 0000:00:16.0: irq 47 for MSI/MSI-X

Suspendend, went for walk, and resumed with processes gone.

Having this problem for some time now. Will try blacklisting.

Thanks.
Comment 167 Markus 2013-09-25 18:50:34 EDT
I've been using 3.11.1-200 kernel for about a week now, the problem has not reappeared even after numerous suspend/resume cycles. Bug seems to have been fixed.
Comment 168 Amir Aharoni 2013-09-26 14:37:42 EDT
I am now with 3.10.12-100.fc18.x86_64. I disabled the blacklisting of mei and mei_me, rebooted, and the system seems to work well, without blowing the /var/log/messages. My machine is Lenovo T420s.
Comment 169 Markus 2013-09-27 07:45:07 EDT
Apparently I spoke too soon; the problem still exists. However, it happens far less frequently and appears to stop by itself after a file (while previously it would just fill the disc without intervention, this time I didn't even notice anything - I was fixing another unrelated issue and realised that I have a massive 1.4GB messages log with the familiar mei error messages.) Another strange thing is that these messages *seem* to have been output in a really small span of time - I watched several minutes of 'grep mei /var/log/messages' print messages from the *exact same second*.
Comment 170 Fedora Blocker Bugs Application 2013-09-27 08:42:26 EDT
Proposed as a Blocker for 20-beta by Fedora user deepsky using the blocker tracking app because:

 This bug is causing a very unstable situation on a apparently large number of pc.
System become unusable because root partion is filled with the huge size of /var/log/messages (about ~50 Gb and more) caused by this bug.
Comment 171 Amir Aharoni 2013-09-27 13:27:37 EDT
(In reply to Markus from comment #169)
> Apparently I spoke too soon; the problem still exists. However, it happens
> far less frequently and appears to stop by itself after a file (while
> previously it would just fill the disc without intervention, this time I
> didn't even notice anything - I was fixing another unrelated issue and
> realised that I have a massive 1.4GB messages log with the familiar mei
> error messages.) Another strange thing is that these messages *seem* to have
> been output in a really small span of time - I watched several minutes of
> 'grep mei /var/log/messages' print messages from the *exact same second*.

True :(

It came back for me, too, had to blacklist again.
Comment 172 Jóhann B. Guðmundsson 2013-09-30 06:33:29 EDT
Why is this being proposed as a blocker since this is happening on GA release and there is no one that actually seem to have tested this on 3.11/3,12 or even is running f20/rawhide? 

Removing blocker bug status since there is no one that actually is affected by this on F20 and reporters do not add this to the f20 unless you are a) running the latest kernel version there as well as are actually experiencing it!
Comment 173 markzzzsmith 2013-10-01 05:13:56 EDT
Just received 3.11.2-201.fc19.x86_64, here is an update on what I'm experiencing on my Dell Optiplex 755.

Without any module blacklisting, both the 'mei' and 'mei_me' modules are loaded, and I immediately start seeing the mei RESETTING kernel log messages. These messages stop if I manually remove the 'mei_me' module.

Blacklisting the 'mei_me' module causes both of the 'mei_me' and 'mei' modules to not be loaded automatically at boot. The trouble with that is that it seems that the 'mei' module is necessary to prevent the system rebooting 30 seconds after resume from suspend (it seems an mei related hardware watchdog goes off, causing the reboot).

Manually loading only the 'mei' module at boot via a manual module load file in /etc/sysconfig/modules -

[mark@opy modules]$ cat mei.modules 
#!/bin/sh

exec /sbin/modprobe mei >/dev/null 2>&1
[mark@opy modules]$ 

fixes the suspend/resume issue.

As I don't seem to be using any of the 'mei_me' module features, this is a suitable work around for me - I don't get any RESETTING kernel log messages, and I can use suspend/resume.
Comment 174 Paolo Leoni 2013-10-01 05:49:50 EDT
@Jòhann: as you can read in the post above, this bug has been revealed also in 3.11 branch, so it's probably also in F20.

Btw, is there someone that can test this bug on F20 Alpha or nightly?
Comment 175 Paolo Leoni 2013-10-01 06:00:39 EDT
There is a duplicate of this bug that is referring to a kernel included in F20 rawhide (kernel-3.10.0-1.fc20.x86_64):
https://bugzilla.redhat.com/show_bug.cgi?id=981053

It's very important to verify if this issue is present in 3.11.y included in F20.

If it's true (probably), I think this should be considered a blocker bug.
Comment 176 Jóhann B. Guðmundsson 2013-10-01 06:30:53 EDT
(In reply to Paolo Leoni from comment #174)
> @Jòhann: as you can read in the post above, this bug has been revealed also
> in 3.11 branch, so it's probably also in F20.

Well I have thinkpad T420 and I used to be affected by this bug ( henced I'm cc ) but I have not seen this with 3.11.x as well as the 3.11 kernel development versions which I'm running here on F18 

All I got in my logs all the way back to july is ( and I'm not blacklisting anything )...

Oct 01 07:23:34 odin.valhalla.is kernel: mei_me 0000:00:16.0: irq 43 for MSI/MSI-X
Oct 01 08:52:16 odin.valhalla.is kernel: mei_me 0000:00:16.0: setting latency timer to 64
Oct 01 08:52:16 odin.valhalla.is kernel: mei_me 0000:00:16.0: irq 45 for MSI/MSI-X


In anycase we need to get a confirmation that 3.9.* and previous work as well as 3.11 and the workaround (  blacklisting the mei_me module in /etc/modprobe.d/modprobe.conf ) does not work for the affected hw
Comment 177 Paolo Leoni 2013-10-01 07:03:31 EDT
I have an Asus Notebook with F19 and it's heavily affected by this bug with kernel-3.10.y kernel.

About 2/3 weeks ago I installed kernel-3.9.9 on it, and I can confirm that this problem is gone (suspension has been heavily used).

I tried to test this bug with F20 Alpha without luck (suspension is causing me system hangs due to another bug, I guess).
Comment 178 Josh Boyer 2013-10-02 09:07:52 EDT
*** Bug 1014639 has been marked as a duplicate of this bug. ***
Comment 179 markzzzsmith 2013-10-06 03:07:54 EDT
(In reply to markzzzsmith from comment #173)
> Just received 3.11.2-201.fc19.x86_64, here is an update on what I'm
> experiencing on my Dell Optiplex 755.
> 
> Without any module blacklisting, both the 'mei' and 'mei_me' modules are
> loaded, and I immediately start seeing the mei RESETTING kernel log
> messages. These messages stop if I manually remove the 'mei_me' module.
> 
> Blacklisting the 'mei_me' module causes both of the 'mei_me' and 'mei'
> modules to not be loaded automatically at boot. The trouble with that is
> that it seems that the 'mei' module is necessary to prevent the system
> rebooting 30 seconds after resume from suspend (it seems an mei related
> hardware watchdog goes off, causing the reboot).
> 
> Manually loading only the 'mei' module at boot via a manual module load file
> in /etc/sysconfig/modules -
> 
> [mark@opy modules]$ cat mei.modules 
> #!/bin/sh
> 
> exec /sbin/modprobe mei >/dev/null 2>&1
> [mark@opy modules]$ 
> 
> fixes the suspend/resume issue.
> 
> As I don't seem to be using any of the 'mei_me' module features, this is a
> suitable work around for me - I don't get any RESETTING kernel log messages,
> and I can use suspend/resume.

Unfortunately this isn't working after all, resuming from suspend isn't working successfully with just the mei module installed.
Comment 180 Marc-Andre Laverdiere 2013-10-12 10:55:29 EDT
I just wanted to let everybody know that the issue hasn't been appearing lately. I am using kernel 3.11.3-201.fc19.x86_64 on a Thinkpad T430.
Comment 181 Paolo Leoni 2013-10-14 06:15:31 EDT
Can someone else test kernel-3.11.3/kernel-3.11.4 from regular repository and report here if the problem is gone?
Comment 182 Vetoshkin Nikita 2013-10-14 06:22:08 EDT
Do not have problems with 3.11.1-200.fc19.x86_64 on Lenovo T520.
Comment 183 Patrick Uiterwijk 2013-10-14 07:21:48 EDT
No issues the last few weeks on 3.11.1-3.11.3 on X230.
Comment 184 Mukundan Ragavan 2013-10-14 07:32:53 EDT
No problems with 3.11.3 on T520 and 3.11.{3/4} in T500.
Comment 185 Tom Horsley 2013-10-14 07:46:50 EDT
The dell optiplex in comment 138 still gets the reset messages every 6 seconds when I reboot without blacklisting the modules:

Linux tomh 3.11.3-201.fc19.x86_64 #1 SMP Thu Oct 3 00:47:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Oct 14 07:42:08 tomh kernel: [  110.296046] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Oct 14 07:42:14 tomh kernel: [  116.308022] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Oct 14 07:42:14 tomh kernel: [  116.308033] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Oct 14 07:42:20 tomh kernel: [  122.320035] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Oct 14 07:42:20 tomh kernel: [  122.320047] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Oct 14 07:42:26 tomh kernel: [  128.336033] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Oct 14 07:42:26 tomh kernel: [  128.336045] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Oct 14 07:42:29 tomh kernel: [  131.124069] mei_me 0000:00:03.0: stop

modeprobe -r makes it stop.
Comment 186 Paolo Leoni 2013-10-14 08:58:18 EDT
Hi Tom,
are you able to verify if this problem occurs also in F20 Alpha (or a Nightly build)?

Thank you.
Comment 187 Tom Horsley 2013-10-14 10:34:15 EDT
I'm running the alpha live image from a USB stick now, and dmesg shows this nonsense after booting:

...
[   56.200055] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[   62.212073] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[   62.212085] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[   68.224021] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[   68.224034] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[   74.236028] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[   74.236040] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[   80.248044] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[   80.248056] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[   86.260028] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[   86.260040] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[   92.272045] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[   92.272057] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
...

The alpha is running this kernel:

Linux localhost 3.11.0-300.fc20.x86_64 #1 SMP Thu Sep 5 18:52:54 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

It is actually worse since it appears to be happening every second rather than every 6 seconds.

Again, modprobe -r mei_me does make it stop.
Comment 188 Paolo Leoni 2013-10-14 11:10:54 EDT
Thank you Tom.

So, actual situation is:

kernels > 3.9.X are affected by this problem on some (many?) systems, much probably also in F20 Alpha.

Jóhann B. Guðmundsson, I think this could be a blocker for F20 Beta.

Do you agree?
Comment 189 Josh Boyer 2013-10-14 11:22:48 EDT
(In reply to Paolo Leoni from comment #188)
> Thank you Tom.
> 
> So, actual situation is:
> 
> kernels > 3.9.X are affected by this problem on some (many?) systems, much
> probably also in F20 Alpha.

This is a known issue upstream in all kernels after 3.9.  See comment #101.

The kinds of machines where this hits show the messages immediately upon module load (as far as we can tell) and the upstream developer hasn't been able to fix it yet.  We don't have a great idea on how many/common those machines are.  The only solution/workaround we have at the moment is blacklisting.

> Jóhann B. Guðmundsson, I think this could be a blocker for F20 Beta.
> 
> Do you agree?

I won't comment either way, but the only existing solution we have is blacklisting.  If we're going to block F20 for a solution other than that, I have no idea how long we'll be waiting.  We also can't just turn the modules off because some machines need them to reboot.
Comment 190 Tom Horsley 2013-10-14 12:25:31 EDT
Or you could ship F20 with a syslog conf that suppresses all mei messages :-).
Comment 191 Jóhann B. Guðmundsson 2013-10-14 13:12:38 EDT
(In reply to Paolo Leoni from comment #188)
> Thank you Tom.
> 
> So, actual situation is:
> 
> kernels > 3.9.X are affected by this problem on some (many?) systems, much
> probably also in F20 Alpha.
> 
> Jóhann B. Guðmundsson, I think this could be a blocker for F20 Beta.
> 
> Do you agree?

No release note material as in how to blacklist it. 3.11 seems to be in order
Comment 192 Jóhann B. Guðmundsson 2013-10-14 13:20:09 EDT
(In reply to Tom Horsley from comment #190)
> Or you could ship F20 with a syslog conf that suppresses all mei messages
> :-).

I'm not sure if it's wise nor doable. I'm a bit rusty in the printk tweaking but I do belive we would have to suppress all kern_err msg to achive it which is not so good ( + I think this is dev_err msg or atleast should be, not kern_err so I'm unsure printk tweaks can suppress that) but feel free to echo "<values>" > /proc/sys/kernel/printk to see if you can.
Comment 193 Ryan Sawhill 2013-10-14 13:25:14 EDT
(In reply to Jóhann B. Guðmundsson from comment #192)
> (In reply to Tom Horsley from comment #190)
> > Or you could ship F20 with a syslog conf that suppresses all mei messages
> > :-).
> 
> I'm not sure if it's wise nor doable. I'm a bit rusty in the printk tweaking
> but I do belive we would have to suppress all kern_err msg to achive it
> which is not so good ( + I think this is dev_err msg or atleast should be,
> not kern_err so I'm unsure printk tweaks can suppress that) but feel free to
> echo "<values>" > /proc/sys/kernel/printk to see if you can.

For the record: it's trivial to add an rsyslog rule that discards such messages.

(http://www.rsyslog.com/doc/rsyslog_conf_filter.html)
Comment 194 Jóhann B. Guðmundsson 2013-10-14 14:03:12 EDT
(In reply to Ryan Sawhill from comment #193)
> (In reply to Jóhann B. Guðmundsson from comment #192)
> > (In reply to Tom Horsley from comment #190)
> > > Or you could ship F20 with a syslog conf that suppresses all mei messages
> > > :-).
> > 
> > I'm not sure if it's wise nor doable. I'm a bit rusty in the printk tweaking
> > but I do belive we would have to suppress all kern_err msg to achive it
> > which is not so good ( + I think this is dev_err msg or atleast should be,
> > not kern_err so I'm unsure printk tweaks can suppress that) but feel free to
> > echo "<values>" > /proc/sys/kernel/printk to see if you can.
> 
> For the record: it's trivial to add an rsyslog rule that discards such
> messages.
> 
> (http://www.rsyslog.com/doc/rsyslog_conf_filter.html)

Discarding this still costs and users should be disabling rsyslog to prevent this being outputting both journal and txt files
Comment 195 Paolo Leoni 2013-10-16 06:41:53 EDT
Other patches seems to be included in kernel-3.12 in order to fix this regression:

https://lkml.org/lkml/2013/9/2/162
Comment 196 Josh Boyer 2013-10-16 08:25:26 EDT
(In reply to Paolo Leoni from comment #195)
> Other patches seems to be included in kernel-3.12 in order to fix this
> regression:
> 
> https://lkml.org/lkml/2013/9/2/162

Those were all CC'd to stable.  They've been included in upstream 3.11.4.  F18/F19 is already at 3.11.4, and has 3.11.5 pending in updates-testing.
Comment 197 Mikhail 2013-10-17 10:00:40 EDT
I have Fedora 20 with 3.11.5-300 kernel and still have this problem
Comment 198 Mikhail 2013-10-17 10:02:21 EDT
Created attachment 813339 [details]
dmesg output
Comment 199 Markus 2013-11-11 02:08:44 EST
This issue hasn't reappeared on my machine with 3.11.6-xxx kernels (or indeed any kernels from last month or so, though I've lost track of which exact versions I've used.)
Comment 200 Luca Petrucci 2013-11-12 11:57:11 EST
For me the problem seems to be solved with the latest kernels.
Right now I'm running 3.11.7-200.fc19.x86_64 .
Comment 201 Paolo Leoni 2013-11-12 12:44:21 EST
Kernel-3.11.7 seems to be ok for me on my system (it was heavily affected by this bug).
Comment 202 Tom Horsley 2013-11-13 08:24:20 EST
All these glowing reports convinced me to try booting without the blacklist entry when installing updates this morning. Not fixed on my dell optiplex 755. I still get the reset messages about every 6 seconds.

This is with kernel 3.11.7-200.fc19.x86_64.

The blacklist entry is back now :-).

Nov 13 08:09:30 tomh kernel: [   19.856028] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Nov 13 08:09:30 tomh kernel: [   19.857854] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Nov 13 08:09:36 tomh kernel: [   25.872114] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
Nov 13 08:09:36 tomh kernel: [   25.873916] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Comment 203 Mohammed Arafa 2013-11-13 08:42:43 EST
my laptop rebooted this morning with a processor issue it hung for 30 seconds for me to read something about opening mcelog. 
when the os came back up the mcelog was empty. 

is this related?
Comment 204 Josh Boyer 2013-11-13 09:45:20 EST
Tom, is AMT/MEI enabled in the BIOS on your optiplex?  If so, does disabling it in the BIOS allow you to remove the blacklist?  If it's already disabled and you still get these errors on module load, that would be really strange and good to know.
Comment 205 Tom Horsley 2013-11-13 10:27:49 EST
>Tom, is AMT/MEI enabled in the BIOS on your optiplex?

I looked for that stuff in the BIOS back when this all started and could not find anything I could interpret as being related to that in any BIOS option, so apparently whatever the setting is cannot be controlled from the BIOS (or has such an obscure label I can't recognize it).
Comment 206 Michael Jordan 2013-11-14 05:05:49 EST
I was attacked by the last go-round of this bug (I am beginning to think virus here). The only way I could find to solve it completely was to blacklist in modprobe.conf. Apparently one of Fedora's too-frequent polite updates destroyed modprobe.conf and now the bug is back at it full steam ahead!

Linux mach1 3.11.7-200.fc19.x86_64 #1 SMP Mon Nov 4 14:09:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

This time I have recreated the modprobe.conf under my user name and given it perms 600, then pulled mei and mei_me. Messages have stopped. We'll see if this solution stays any further assaults.

Michael
Comment 207 Edgar Hoch 2013-11-14 06:30:23 EST
(In reply to Michael Jordan from comment #206)
> blacklist in modprobe.conf. Apparently one of Fedora's too-frequent polite
> updates destroyed modprobe.conf and now the bug is back at it full steam
> ahead!

Instead of creating /etc/modprobe.conf, you may create a new file in /etc/modprobe.d/ (with suffix .conf). This new file will be not changed by package updates if you choose a name which is not used by any other packages.
Comment 208 Mike Gahagan 2013-11-14 09:32:45 EST
I've removed my blacklist file and re-enabled mei in the BIOS on my Lenovo T520 and it seems that recent kernels have made this go away. 3.11.7-200 survived several suspend/resume cycles for me
Comment 209 Mikhail 2013-11-15 04:26:36 EST
Still not fixed also for me
Comment 210 Mikhail 2013-11-15 04:27:52 EST
Created attachment 824363 [details]
dmesg output
Comment 211 Lukas Koranda 2013-11-15 14:13:02 EST
System:
Linux dq35mp.example.net 3.11.7-200.fc19.x86_64 #1 SMP Mon Nov 4 14:09:03 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

Hardware:
00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
00:03.2 IDE interface: Intel Corporation 82Q35 Express PT IDER Controller (rev 02)
00:03.3 Serial controller: Intel Corporation 82Q35 Express Serial KT Controller (rev 02)

Message:
[  746.619081] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[  746.619135] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
Comment 212 Lukas Koranda 2013-11-15 14:17:06 EST
Created attachment 824668 [details]
Intel DQ35MP - 3.11.7-200.fc19.x86_64 - lspci --nnvv
Comment 213 marc 2013-12-17 13:55:12 EST
This may be a simple solution, such as faulty USB device. Disconnect any unused USB devices, and replace your keyboard and mouse with know good.
Also, boot from a live ISO, see if error message occurs again.
Comment 214 markzzzsmith 2013-12-30 19:26:08 EST
Still occurring for me with 3.12.5-200.fc19.x86_64, on a Dell Optiplex 755.

Only way to stop the messages is to remove/blacklist the mei_me module. Haven't tried to suspend/resume without this module, as it hasn't worked in the past, and I've crashed this box enough as it is.

Upgraded to the latest bios (A22) just in case it would make a difference, but it didn't.
Comment 215 Mohammed Arafa 2014-01-02 14:35:29 EST
its occuring on f20 too

i am going to implement the blacklist work around as it causing way too much noise

and no .. there are no faulty usb devices attached to my laptop
Comment 216 Justin M. Forbes 2014-03-10 10:51:01 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 19 kernel bugs.

Fedora 19 has now been rebased to 3.13.5-100.fc19.  Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 217 Mikhail 2014-03-10 10:58:01 EDT
This issue still occurs with 3.13.6-200 kernel
Comment 218 Gabriel VLASIU 2014-03-15 14:28:22 EDT
No more mei messages for me. Seems to be fixed.
Comment 219 Gabriel VLASIU 2014-03-16 04:00:23 EDT
Sorry but the issue is not fixed. I had to reboot and the mei messages are back.
Comment 220 Luca Petrucci 2014-03-16 08:15:03 EDT
For me it has been solved from a long time.
Now running F20 with a 3.13.6-200 kernel on a Lenovo notebook.
Comment 221 Need Real Name 2014-03-16 11:08:28 EDT
I still get the messages

Device doesn't have valid ME Interface
iitialization failed

early in the boot.

3.13.6-200.fc20.x86_64

It isn't clear whether this has any impact later on.
Comment 222 Mohammed Arafa 2014-04-14 17:26:42 EDT
i just did a fresh install of fedora 20 on a physical machine and it was interrupting my getty/vt session

blacklisting it worked wonders. i am so happy.
Comment 223 Mohammed Arafa 2014-04-14 17:27:27 EDT
and yes, i did a yum upgrade too
Comment 224 Josh Boyer 2014-04-15 08:02:18 EDT
So in theory, there might be another commit or two coming in 3.14 that fixes this issue on Dell machines.  Apparently the Dell boxes are supposed to have MEI disabled in firmware and the driver wasn't checking the appropriate bits for that.  If anyone wants to try a 3.14 or 3.15-rc1 kernel and report back, that would be appreciated.  They are both in koji.
Comment 225 Josh Boyer 2014-04-15 09:40:40 EDT
Actually, ignore my last comment.  The patch I'm thinking of isn't merged yet.  Sigh.
Comment 226 Lukas Koranda 2014-04-19 14:00:35 EDT
It looks like it's gone on 3.15.0-0.rc1.git4.1.fc21.x86_64
Comment 227 Josh Boyer 2014-04-21 10:20:05 EDT
(In reply to Lukas Koranda from comment #226)
> It looks like it's gone on 3.15.0-0.rc1.git4.1.fc21.x86_64

Right.  That contains the patch I was thinking of in comment #224.  It's CC'd to stable, so hopefully it will show up soon.
Comment 228 Justin M. Forbes 2014-05-21 15:40:53 EDT
*********** MASS BUG UPDATE **************

We apologize for the inconvenience.  There is a large number of bugs to go through and several of them have gone stale.  Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs.

Fedora 20 has now been rebased to 3.14.4-200.fc20.  Please test this kernel update (or newer) and let us know if you issue has been resolved or if it is still present with the newer kernel.

If you experience different issues, please open a new bug report for those.
Comment 229 Mikhail 2014-05-22 01:10:38 EDT
Problem still not fixed



[11304.328029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11304.328040] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11310.340043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11310.340053] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11316.352021] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11316.352029] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11322.364034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11322.364044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11328.376038] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11328.376048] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11334.388035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11334.388045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11340.400026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11340.400037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11346.412031] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11346.412041] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11352.424036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11352.424045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11358.436036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11358.436045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11364.448036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11364.448046] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11370.460028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11370.460038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11376.472035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11376.472043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11382.484039] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11382.484049] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11388.496027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11388.496035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11394.508028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11394.508038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11400.520034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11400.520044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11406.532035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11406.532045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11412.544031] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11412.544041] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11418.556037] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11418.556047] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11424.568033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11424.568043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11430.580034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11430.580044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11436.592026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11436.592036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11442.604035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11442.604044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11448.616027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11448.616037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11454.628034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11454.628044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11460.640047] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11460.640057] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11466.652036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11466.652046] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11472.664032] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11472.664042] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11478.676033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11478.676043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11484.688037] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11484.688047] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11490.700029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11490.700039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11496.712035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11496.712043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11502.724029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11502.724039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11508.736033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11508.736043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11514.748031] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11514.748039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11520.760033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11520.760043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11526.772026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11526.772037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11532.784034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11532.784044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11538.796029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11538.796039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11544.808033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11544.808043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11550.820035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11550.820045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11556.832037] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11556.832048] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11562.844034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11562.844044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11568.856042] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11568.856052] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11574.868025] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11574.868034] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11580.880060] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11580.880069] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11586.892042] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11586.892052] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11592.904046] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11592.904056] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11598.916030] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11598.916040] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11604.928024] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11604.928034] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11610.940030] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11610.940040] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11616.952028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11616.952038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11622.964029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11622.964039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11628.976038] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11628.976047] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11634.988033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11634.988043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11641.000047] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11641.000055] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11647.012042] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11647.012052] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11653.024027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11653.024038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11659.036046] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11659.036056] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11665.048051] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11665.048061] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11671.060042] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11671.060051] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11677.072043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11677.072053] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11683.084048] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11683.084059] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11689.096040] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11689.096050] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11695.108025] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11695.108035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11701.120026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11701.120035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11707.132026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11707.132036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11713.144031] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11713.144041] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11719.156031] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11719.156038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11725.168027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11725.168037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11731.180033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11731.180043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11737.192035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11737.192043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11743.204036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11743.204046] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11749.216037] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11749.216047] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11755.228040] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11755.228050] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11761.240025] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11761.240035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11767.252029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11767.252037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11773.264027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11773.264034] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11779.276029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11779.276039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11785.288028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11785.288038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11791.300036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11791.300045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11797.312034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11797.312044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11803.324028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11803.324038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11809.336038] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11809.336049] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11815.348027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11815.348036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11821.360034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11821.360044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11827.372024] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11827.372033] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11833.384028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11833.384038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11839.396028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11839.396038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11845.408038] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11845.408048] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11851.420032] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11851.420042] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11857.432021] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11857.432027] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11863.444033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11863.444043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11869.456045] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11869.456053] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11875.468045] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11875.468054] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11881.480033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11881.480044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11887.492035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11887.492042] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11893.504025] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11893.504035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11899.516032] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11899.516042] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11905.528028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11905.528038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11911.540030] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11911.540040] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11917.552027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11917.552037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11923.564031] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11923.564039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11929.576043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11929.576054] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11935.588043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11935.588054] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11941.600052] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11941.600063] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11947.612014] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11947.612022] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11953.624034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11953.624043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11959.636038] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11959.636048] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11965.648034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11965.648043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11971.660034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11971.660045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11977.672034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11977.672044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11983.684028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11983.684038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11989.696026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11989.696036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[11995.708029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[11995.708039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12001.720041] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12001.720051] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12007.732036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12007.732046] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12013.744050] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12013.744059] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12019.756033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12019.756043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12025.768034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12025.768043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12031.780026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12031.780036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12037.792034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12037.792044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12043.804028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12043.804036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12049.816033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12049.816043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12055.828026] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12055.828036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12061.840032] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12061.840041] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12067.852021] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12067.852030] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12073.864027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12073.864037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12079.876027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12079.876037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12085.888044] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12085.888052] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12091.900043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12091.900054] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12097.912041] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12097.912051] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12103.924045] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12103.924055] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12109.936035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12109.936044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12115.948050] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12115.948060] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12121.960046] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12121.960056] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12127.973048] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12127.973058] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12133.984034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12133.984045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12139.996025] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12139.996035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12146.008025] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12146.008035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12152.020029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12152.020039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12158.032032] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12158.032042] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12164.044035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12164.044045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12170.056037] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12170.056047] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12176.068033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12176.068043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12182.080036] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12182.080045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12188.095042] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12188.095052] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12194.104030] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12194.104040] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12200.116043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12200.116053] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12206.128034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12206.128044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12212.140024] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12212.140035] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12218.152022] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12218.152033] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12224.164024] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12224.164033] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12230.176030] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12230.176040] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12236.188028] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12236.188038] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12242.200035] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12242.200045] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12248.212043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12248.212053] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12254.224022] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12254.224031] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12260.236027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12260.236037] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12266.248043] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12266.248053] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12272.260031] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12272.260041] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12278.272029] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12278.272039] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12284.284027] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12284.284036] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
[12290.296032] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[12290.296042] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
Comment 230 Gabriel VLASIU 2014-05-22 12:40:42 EDT
I have the same problem with 3.14.4-100 (fedora 19).
Comment 231 Josh Boyer 2014-05-22 12:47:28 EDT
GRRR.

OK, this bug is becoming unweidly.  If you're still seeing an issue with this driver on 3.14.4, please attach the full output of dmidecode from your machine.
Comment 232 Mikhail 2014-05-22 12:58:24 EDT
Created attachment 898437 [details]
dmidecode.log
Comment 233 Mukundan Ragavan 2014-05-22 13:02:23 EDT
Created attachment 898438 [details]
dmidecode_output
Comment 234 Tom Horsley 2014-05-22 13:02:43 EDT
I'm running kernel-3.14.4-200.fc20.x86_64 on my Dell Optiplex 755 now and just tried a "modprobe mei_me" and soon after this started appearing in the log:

May 22 12:53:02 tomh kernel: [19055.923034] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:02 tomh kernel: [19055.923044] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 12:53:02 tomh kernel: mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:02 tomh kernel: mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 12:53:08 tomh kernel: [19061.935033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:08 tomh kernel: [19061.935043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 12:53:08 tomh kernel: mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:08 tomh kernel: mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 12:53:14 tomh kernel: [19067.947033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:14 tomh kernel: [19067.947043] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 12:53:14 tomh kernel: mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:14 tomh kernel: mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 12:53:20 tomh kernel: [19073.959038] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:20 tomh kernel: [19073.959048] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 12:53:20 tomh kernel: mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 12:53:20 tomh kernel: mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED

etc...

I attached my dmidecode a while back as attachment #791841 [details]
Comment 235 Gabriel VLASIU 2014-05-22 13:17:17 EDT
Created attachment 898439 [details]
dmidecode.txt

May 22 20:16:30 imhotep kernel: [ 4468.132089] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 20:16:30 imhotep kernel: [ 4468.132105] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 20:16:36 imhotep kernel: [ 4474.144066] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 20:16:36 imhotep kernel: [ 4474.144080] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 20:16:42 imhotep kernel: [ 4480.156091] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 20:16:42 imhotep kernel: [ 4480.156105] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 20:16:48 imhotep kernel: [ 4486.168090] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 20:16:48 imhotep kernel: [ 4486.168104] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
May 22 20:16:54 imhotep kernel: [ 4492.180097] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
May 22 20:16:54 imhotep kernel: [ 4492.180111] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
Comment 236 markzzzsmith 2014-05-22 16:48:31 EDT
I was still seeing it too on my Dell Optiplex 755. I ended up switching the Management Engine off using the following instructions:

http://thoughtsdaily.wordpress.com/2011/11/08/disable-intel-amt-on-dell-optiplex-755/

and now the mei and mei_me modules don't load any more.

I would prefer to be able to switch it back on, the value it provides even to those not using MEI/Intel-AMT is a hardware watch dog.

My experience was that without the mei_me module, when resuming from suspend, the hardware watchdog would go off, causing the machine to reboot, making suspend/resume unusable (Hibernate/resume still works). Loading the mei_me module solves that problem, but of course you then get these constant log messages.
Comment 237 markzzzsmith 2014-05-22 16:49:27 EDT
(Just to be clear, I disabled MEI/AMT after finding that this issue was still occurring with the 3.14.x kernel.)
Comment 238 Dan Mossor [danofsatx] 2014-06-04 22:04:40 EDT
This is still present in 3.14.5-200.fc20.x86_64.

Dell Optiplex 755, just like all the rest - I actually have 4 Optiplex 755 mini towers in operation, and all exhibit the same behavior. Attaching dmidecode output.
Comment 239 Dan Mossor [danofsatx] 2014-06-04 22:06:33 EDT
Created attachment 902378 [details]
dmidecode for kernel 3.14.5-200
Comment 240 Eddie Lania 2014-06-05 09:14:22 EDT
Created attachment 902533 [details]
demidecode for Intel board DQ35JO, bios JOQ3510J.86A.1143
Comment 241 David W. Legg 2014-09-16 15:27:28 EDT
Well done chaps.  Seems fixed in kernel 3.16.2-200.fc20.x86_64 #1 SMP Mon Sep 8 11:54:45 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Comment 242 tuksgig 2015-12-18 15:09:17 EST
On Fedora 23 and Intel DG45 motherboard suspend resume I still get mei errors and fan speed goes to maximum:

#uname -a
Linux localhost.localdomain 4.2.6-301.fc23.x86_64 #1 SMP Fri Nov 20 22:22:41 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

For fun I added:

# echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control

and tried running a patched version of Intel's QST SDK tools from https://github.com/gigaplex/Intel_QST_SDK. Usually it works fine, but once mei goes titsup there's no communication.

Attached find all the particulars.
Comment 243 tuksgig 2015-12-18 15:14 EST
Created attachment 1107400 [details]
Intel DG45 dmidecode output
Comment 244 tuksgig 2015-12-18 15:16 EST
Created attachment 1107401 [details]
Intel DG45 HECI controller lspci
Comment 245 tuksgig 2015-12-18 15:19 EST
Created attachment 1107402 [details]
Intel DG45 QST demo app testing mei_me kernel debug log
Comment 246 Linus Ping 2016-04-11 04:28:16 EDT
(In reply to Need Real Name from comment #20)
> I see mei problems too. From dmesg
> 
> [   44.569164] mei 0000:00:16.0: Device doesn't have valid ME Interface
> [   44.569171] mei 0000:00:16.0: initialization failed.
> 
> This is Fedora 18:
> 
> Linux bin.astro.cornell.edu 3.9.4-200.fc18.x86_64 #1 SMP Fri May 24 20:10:49
> UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

I saw that too, have you fixed it?

Note You need to log in before you can comment on or make changes to this bug.