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 ...
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.
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.
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.
$ 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.
(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
Better solution: # echo -e "blacklist mei\ninstall mei /bin/true" > /etc/modprobe.d/mei.conf # reboot
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.
# 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.
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 ~]$
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
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.
Are you still seeing this with the 3.9 kernels?
$ 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
(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?
(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
(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.
(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.
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.
(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
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
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.
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.
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.
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?
*** Bug 981053 has been marked as a duplicate of this bug. ***
Tom, you'll need the mei module if you want suspend to work.
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
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.
I saw these messages today with kernel-3.10.3-300.fc19.x86_64 after resuming from suspend.
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.
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.
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
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.
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
[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!
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.
These three relevant-looking fixes from 10 days ago are in the -stable branch but don't seem to have made it to 3.10.4: https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/misc/mei?id=dab9bf41b23fe700c4a74133e41eb6a21706031e https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/misc/mei?id=99f22c4ef24cf87b0dae6aabe6b5e620b62961d9 https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/misc/mei?id=315a383ad7dbd484fafb93ef08038e3dbafbb7a8
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.
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.
Created attachment 782623 [details] mei-me-fix-waiting-for-hw-ready.patch
Created attachment 782625 [details] mei-dont-have-to-clean-the-state-on-power-up.patch
Created attachment 782627 [details] mei-me-fix-reset-state-machine.patch
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.
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.
"Still unresolved" sounds like "Make the damn modules loadable so we can blacklist 'em" to me :-).
(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.
> 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.
(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.
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.
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...
I have to stick with the last 3.9 kernel (where I can at least blacklist the mei module) to have a usable system.
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)
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
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
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.
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?
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
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
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.
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.
In addition to #60, I notice that the problem of mei_me spamming seems to start after wake-up from suspend.
*** Bug 996156 has been marked as a duplicate of this bug. ***
*** Bug 995250 has been marked as a duplicate of this bug. ***
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.
Please test this scratch build when it completes: http://koji.fedoraproject.org/koji/taskinfo?taskID=5822807
(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.
(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.
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.
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
> 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
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.
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
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.
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.
(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.
I experience freezes/kernel panics daily as described above. I am running kernel 3.10.7-100.fc18.x86_64 on my Thinkpad T430.
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.
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
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
> 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
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.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".
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
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.
*** Bug 1000877 has been marked as a duplicate of this bug. ***
> 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
(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.
> 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.
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.
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.
(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.
(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.
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 :)
> 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
> 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.
(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.
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.
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.
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.
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.
*** Bug 1002492 has been marked as a duplicate of this bug. ***
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.
Created attachment 791841 [details] dmidecode for my dell optiplex 755
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.
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.
Created attachment 792080 [details] dmidecode for Thinkpad T520
Created attachment 792092 [details] dmidecode for Thinkpad T420
Created attachment 792590 [details] DMI decode output for Lenovo T430
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.
(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.)
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 ...
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.
Same problem here. Filling free space (about 40GB) in some minutes. /var/log/messages grow without limit.
After blacklisting the mei module, I had no more lockups or strange mei messages from the kernel.
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.
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
(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"
(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"
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.
(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.
(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.
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.
Created attachment 795767 [details] dmidecode for Lenovo B590
Just a me too. # uname -r 3.10.10-200.fc19.x86_64
*** Bug 1006939 has been marked as a duplicate of this bug. ***
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.
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.
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.
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.
How about voting for a bug? Wouldn't that produce the widest possible view?
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.
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
[michael@mach1 davinci]$ sudo lspci -nnvv | gzip > mj_lspci.gz Attached
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.
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.
Created attachment 797019 [details] lspci -nnvv
Created attachment 797020 [details] lspci -nnvv (comment was not good)
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
Created attachment 797041 [details] lspci -nnvv for my dell optiplex 755 This goes with the dmidecode output in attachment 791841 [details] (same machine)
Created attachment 797160 [details] dmidecode Dell Latitude 6430u
Created attachment 797162 [details] lspci -nnvv Dell Latitude 6430u
Created attachment 797200 [details] dmidecode for HP Pavilion dm4
Created attachment 797201 [details] lspci -vnn for HP Pavilion dm4
Created attachment 797261 [details] lenovo t420 lenovo t420 lspci -nnvv for mei bug
Created attachment 797284 [details] lspci -nnvv for lenovo t520 (with nvidia)
Created attachment 797300 [details] dmidecode ThinkPad x230
Created attachment 797301 [details] lspci -nnvv ThinkPad x230
Created attachment 797306 [details] lspci -nnvv ThinkPad T430
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
Created attachment 797340 [details] dmidecode -s bios-version dmidecode -s bios-version from asus k55a
Created attachment 797341 [details] uname -a uname -a from asus k55a
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.
Created attachment 797392 [details] dmesg, lspci -nvv, dmidecode for Lenovo T520 with mei blacklisted
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.
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
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
Created attachment 797554 [details] Lenovo B590 'lspci -nnvv' output
Seem to accidentally have created the attachment as a patch. Never mind that.
Created attachment 798282 [details] lspci -nnvv from Lenovo Thinkpad T520 with mei module blacklisted
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>
Created attachment 798677 [details] lspci -nnvv from Thinkpad T420s (blacklisted MEI module)
Created attachment 799135 [details] lspci -nnvv Just a quick "me too"; lspci -nnvv attached.
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.
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.
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))
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...
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.
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.
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.
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*.
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.
(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.
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!
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.
@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?
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.
(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
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).
*** Bug 1014639 has been marked as a duplicate of this bug. ***
(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.
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.
Can someone else test kernel-3.11.3/kernel-3.11.4 from regular repository and report here if the problem is gone?
Do not have problems with 3.11.1-200.fc19.x86_64 on Lenovo T520.
No issues the last few weeks on 3.11.1-3.11.3 on X230.
No problems with 3.11.3 on T520 and 3.11.{3/4} in T500.
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.
Hi Tom, are you able to verify if this problem occurs also in F20 Alpha (or a Nightly build)? Thank you.
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.
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?
(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.
Or you could ship F20 with a syslog conf that suppresses all mei messages :-).
(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
(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.
(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)
(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
Other patches seems to be included in kernel-3.12 in order to fix this regression: https://lkml.org/lkml/2013/9/2/162
(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.
I have Fedora 20 with 3.11.5-300 kernel and still have this problem
Created attachment 813339 [details] dmesg output
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.)
For me the problem seems to be solved with the latest kernels. Right now I'm running 3.11.7-200.fc19.x86_64 .
Kernel-3.11.7 seems to be ok for me on my system (it was heavily affected by this bug).
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
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?
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.
>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).
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
(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.
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
Still not fixed also for me
Created attachment 824363 [details] dmesg output
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
Created attachment 824668 [details] Intel DQ35MP - 3.11.7-200.fc19.x86_64 - lspci --nnvv
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.
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.
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
*********** 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.
This issue still occurs with 3.13.6-200 kernel
No more mei messages for me. Seems to be fixed.
Sorry but the issue is not fixed. I had to reboot and the mei messages are back.
For me it has been solved from a long time. Now running F20 with a 3.13.6-200 kernel on a Lenovo notebook.
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.
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.
and yes, i did a yum upgrade too
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.
Actually, ignore my last comment. The patch I'm thinking of isn't merged yet. Sigh.
It looks like it's gone on 3.15.0-0.rc1.git4.1.fc21.x86_64
(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.
*********** 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.
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
I have the same problem with 3.14.4-100 (fedora 19).
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.
Created attachment 898437 [details] dmidecode.log
Created attachment 898438 [details] dmidecode_output
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]
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
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.
(Just to be clear, I disabled MEI/AMT after finding that this issue was still occurring with the 3.14.x kernel.)
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.
Created attachment 902378 [details] dmidecode for kernel 3.14.5-200
Created attachment 902533 [details] demidecode for Intel board DQ35JO, bios JOQ3510J.86A.1143
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
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.
Created attachment 1107400 [details] Intel DG45 dmidecode output
Created attachment 1107401 [details] Intel DG45 HECI controller lspci
Created attachment 1107402 [details] Intel DG45 QST demo app testing mei_me kernel debug log
(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?