[HP Compaq dc7700 Small Form Factor PC] mei unexpected reset in kernel 3.8

[Ldx]

Right after upgrading kernel from 3.5 to 3.8 (Ubuntu 13.04), the syslog got flooded by a large number of such messages:

(cut)
May 5 15:33:15 compaq-aldo kernel: [ 205.064042] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 5 15:33:21 compaq-aldo kernel: [ 211.076029] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 5 15:33:27 compaq-aldo kernel: [ 217.088035] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 5 15:33:33 compaq-aldo kernel: [ 223.100039] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
May 5 15:33:39 compaq-aldo kernel: [ 229.112045] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
(cut)

This was associated by non reliable ethernet functionality, i.e. transfer of large files from my Ubuntu box to a local NAS connected via ethernet got hanging with no other apparent errors or diagnostics: nautilus copy just stopped transferring data, leaving the copy window there with the progress bar stopped.

I tried to reboot, but this behaviour is perfectly reproducible.

This is one of the first syslog lines got from that kernel:

May 5 15:30:15 compaq-aldo kernel: [ 0.000000] Linux version 3.8.0-19-generic (buildd@roseapple) (gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1) ) #30-Ubuntu SMP Wed May 1 16:36:13 UTC 2013 (Ubuntu 3.8.0-19.30-generic 3.8.8)

I attach the whole syslog from boot of that kernel.

On the same box, launching a previsous kernel (3.5) works flawlessly. For the time being, I removed 3.8 kernel from my box, now running 3.5.

Kind regards
Aldo
---
ApportVersion: 2.9.2-0ubuntu8
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC1: ldx 2074 F.... pulseaudio
 /dev/snd/controlC0: ldx 2074 F.... pulseaudio
CRDA: Error: command ['iw', 'reg', 'get'] failed with exit code 1: nl80211 not found.
DistroRelease: Ubuntu 13.04
HibernationDevice: RESUME=UUID=32cc5d6d-43c1-4e97-a8b7-10b71aac3e29
InstallationDate: Installed on 2013-01-04 (121 days ago)
InstallationMedia: Ubuntu 12.10 "Quantal Quetzal" - Release i386 (20121017.2)
IwConfig:
 lo no wireless extensions.

 eth0 no wireless extensions.
MachineType: Hewlett-Packard HP Compaq dc7700 Small Form Factor
MarkForUpload: True
Package: linux (not installed)
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=it_IT.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.8.0-19-generic root=UUID=38ce1d51-c3cf-438d-b395-f7c4744e2e37 ro quiet splash vt.handoff=7
ProcVersionSignature: Ubuntu 3.8.0-19.30-generic 3.8.8
RelatedPackageVersions:
 linux-restricted-modules-3.8.0-19-generic N/A
 linux-backports-modules-3.8.0-19-generic N/A
 linux-firmware 1.106
RfKill:

Tags: raring
Uname: Linux 3.8.0-19-generic i686
UpgradeStatus: Upgraded to raring on 2013-04-26 (9 days ago)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo wireshark
dmi.bios.date: 04/13/2007
dmi.bios.vendor: Hewlett-Packard
dmi.bios.version: 786E1 v01.10
dmi.board.name: 0A54h
dmi.board.vendor: Hewlett-Packard
dmi.chassis.asset.tag: CZC7451V4Q
dmi.chassis.type: 4
dmi.chassis.vendor: Hewlett-Packard
dmi.modalias: dmi:bvnHewlett-Packard:bvr786E1v01.10:bd04/13/2007:svnHewlett-Packard:pnHPCompaqdc7700SmallFormFactor:pvr:rvnHewlett-Packard:rn0A54h:rvr:cvnHewlett-Packard:ct4:cvr:
dmi.product.name: HP Compaq dc7700 Small Form Factor
dmi.sys.vendor: Hewlett-Packard

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1176577

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Ldx (a-giove)]

apport information

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.9 kernel[0].

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.9-saucy/

[Ldx (a-giove)]

Joseph, thank you for your comment.

I installed the kernel you pointed me:

3.9.0-030900-generic #201305071030 SMP Tue May 7 14:39:20 UTC 2013 i686 i686 i686 GNU/Linux

rebooted and the reset doesn't appear anymore.

Now I'm copying some large file over the network and it seems to work properly, so I can tell that the but is already solved by the upstream kernel. :-)

[Ldx (a-giove)]

Sorry, last sentence contains a typo: "the but is already solved" should be read "the bug is already solved".

[Ldx (a-giove)]

SORRY.

The bug has *NOT* been fixed in kernel 3.9. It was *apparently* fixed because after installing kernel 3.9 i just did a warm reboot. With a cold boot the problem is still present in 3.9. :-(

I try to investigate more about this issue and post new info as soon as I can.

[Ldx (a-giove)]

I tried a number of different boot-reboot sequences. The only kernel that never shows the problem is 3.5. Quite frequently, warm reboots 3.5 => 3.9 show no problem (but not always).

So I confirm that the bug is NOT fixed in upstream kernel.

[Red Five (nelson-butterworth)]

I believe I have the same issue with my Dell Optiplex 755 small form factor desktop. I just upgraded from 12.10 to 13.04 with kernel 3.8.0-19-generic amd64. I'm using it as a firewall/router, so it has 2 Intel Pro/1000 gigabit ethernet adapters installed (one onboard, one PCI). I get streams of the same MEI error message as the original report above, and the PCI ID from the error corresponds to the PCI GbE adapter; I also get frequent reports of TX Unit Hang Detected on the system's onboard GbE adapter, which causes an auto-reset of the adapter and loss of internet connectivity for 10-15sec. The MEI error on eth0 (PCI, internet side) occurs every few (3-10) seconds, while the TX Unit Hang error/reset on eth1 (onboard, LAN side) occurs randomly a few times a day so far.

The odd thing is that I have another Optiplex 755, a mini-tower unit, which has only the onboard GbE NIC. I just upgraded it from 12.10 to 13.04 as well, again with kernel 3.8.0-19-generic amd64, and I get neither the MEI errors nor the TX Unit Hang Detected messages. In both systems the onboard GbE NIC uses the e1000e driver, while on my firewall box the additional PCI GbE NIC uses the e1000 driver.

I just rebooted the firewall box to kernel 3.5.0-28-generic amd64, and so far I haven't seen the MEI errors appear. Time will tell whether the TX Unit Hang errors will appear. I think for now I will remove the rest of the kernels and keep 3.5.0-28.

[tsmolen (smolen)]

I have a full tower Dell Optiplex 755 and see this message.

tsmolen@tsmolen:~$ uname -a
Linux tsmolen 3.8.0-21-generic #32-Ubuntu SMP Tue May 14 22:16:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
 Subsystem: Dell OptiPlex 755
 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 f0200800 (64-bit, non-prefetchable) [size=16]
 Capabilities: <access denied>
 Kernel driver in use: mei

[16270.972017] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16276.984021] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16282.996016] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16289.008026] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16295.020015] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16301.032017] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16307.044027] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16313.056018] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16319.068018] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16325.080016] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16331.092027] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16337.104022] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16343.116018] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16349.128020] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16355.140020] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16361.152016] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16367.164021] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16373.176024] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16379.188031] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16385.200025] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16391.212019] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16397.224021] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16403.236017] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16409.248019] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16415.260015] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16421.272018] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16427.284019] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16433.296018] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16439.308019] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16445.320019] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16451.332024] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16457.344019] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16463.356017] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16469.368019] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[16475.380018] mei 0000:00:03.0: unexpected reset: dev_sta...

[Kevin Shanahan (kmshanah-x)]

Note that this bug affects me on Arch Linux x86_64 kernel 3.9.4. Hardware is also a Dell Optiplex 755.

[Romano Giannetti (romano-giannetti)]

Affects me, with a 32-bit kernel too. What are the negative effects of blacklisting the module?

Romano

00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
        Subsystem: Dell OptiPlex 755
        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-
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at f0200800 (64-bit, non-prefetchable) [size=16]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+
                Address: 00000000fee0300c Data: 4122

[Toyota4Runner (curiousgeorge77)]

I also am experiencing the same issues as above on an Optiplex 755.

Ubuntu 13.04 32bit
Kernel 3.8.0-25-generic

Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
        Subsystem: Dell OptiPlex 755
        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 f0200000 (64-bit, non-prefetchable) [size=16]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [8c] MSI: Enable+ Count=1/1 Maskable- 64bit+
                Address: 00000000fee0100c Data: 41e1
        Kernel driver in use: mei

[ 20.912637] mei 0000:00:03.0: setting latency timer to 64
[ 20.912687] mei 0000:00:03.0: irq 44 for MSI/MSI-X
[ 25.924042] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 31.936045] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 37.948043] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 43.960035] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 49.972043] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 55.984042] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 61.996044] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 68.008043] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 74.020043] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 80.032041] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 86.044065] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 92.056062] mei 0000:00:03.0: unexpected reset: dev_state = RESETING

[Mark Crook (markcrooknz)]

Ubuntu 13.04 64 bit
Linux mark-laptop 3.8.0-26-generic #38-Ubuntu SMP Mon Jun 17 21:43:33 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

[ 10.609344] IPv6: wlan0: IPv6 duplicate address <mac address> detected!
[ 10.825506] ptrace of pid 2049 was attempted by: dbsrv12 (pid 2082)
[ 13.616068] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 19.628078] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
[ 25.640105] mei 0000:00:03.0: unexpected reset: dev_state = RESETING
...

Everything appears to be working normally despite the messages.

[Luis Henriques (henrix)]

This issue seems to been fixed upstream by the serie:

   - dab9bf4 mei: me: fix waiting for hw ready
   - 99f22c4 mei: don't have to clean the state on power up
   - 315a383 mei: me: fix reset state machine
   - 9310f61 mei: hbm: fix typo in error message

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

I've built a Raring test kernel containing only 2 of the patches: 99f22c4 and 315a383 (9310f61 is a typo fix and dab9bf4 doesn't seem to be applicable to 3.8 kernels). The test kernel has been uploaded here:

http://people.canonical.com/~henrix/lp1176577/

Could someone please see if it fixes the issue? Thanks!

[Jan-Marek Glogowski (jmglogow)]

I patched the source from 3.8.0-27.40 (there aren't any changes for the mei driver in any Ubuntu 3.8 kernels) and just build the module. The dmesg log still continues to fill with "mei reset" messages.

Since the mei driver has changed a lot since 3.8, I tried to backport the mei driver from git AKA 3.11-rc5+ (commit dab9bf41b23fe700c4a74133e41eb6a21706031e) for a test.

The backport patch is very minimal and stops the messages, but since I don't use the Intel AMT interface, I don't know if it's working as expected.

[Toyota4Runner (curiousgeorge77)]

Just upgraded 3 machines to 64bit 13.10 and am still being flooded with the message when I do a dmesg. The only way I can stop it is by blacklisting mei and mei_me, as within minutes dmesg is full of the reset messages and doesn't contain any useful info any longer.

Linux DESKTOP 3.11.0-12-generic #19-Ubuntu SMP Wed Oct 9 16:20:46 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
 Subsystem: Lenovo Device 3037
 Flags: fast devsel, IRQ 16
 Memory at d04a6000 (64-bit, non-prefetchable) [size=16]
 Capabilities: [50] Power Management version 3
 Capabilities: [8c] MSI: Enable- Count=1/1 Maskable- 64bit+

[ 34.364025] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 34.364033] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 40.376040] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 40.376049] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 46.392024] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 46.392032] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 52.404029] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 52.404038] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 58.416027] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 58.416037] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 64.428025] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 64.428035] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 70.440037] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 70.440046] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 76.452022] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 76.452031] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 82.464034] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 82.464043] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 88.476027] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 88.476036] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 94.488017] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 94.488027] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 100.500015] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 100.500023] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 106.512014] mei_me 0000:00:03.0: reset: connect/disconnect timeout.
[ 106.512021] mei_me 0000:00:03.0: unexpected reset: dev_state = RESETTING
[ 107.854296] mei_me 0000:00:03.0: stop

[Philip Guyton (phil-lxnet)]

Just to add that I also have this bug in Kubuntu 13.10 and had it in Ubuntu 13.04 on the same hardware previously.

Machine is a Dell Optiplex 755

My kernel is currently 3.11.0-13-generic 64 bit.

lspci -vv

00:03.0 Communication controller: Intel Corporation 82Q35 Express MEI Controller (rev 02)
        Subsystem: Dell OptiPlex 755
        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 f4200800 (64-bit, non-prefetchable) [size=16]
        Capabilities: <access denied>
        Kernel driver in use: mei_me

[KrautOS (krautos)]

Still present in 14.04 daily image on HP 6910p laptops ;( Needed to blacklist mei and mei_me like said before.

[penalvch (penalvch)]

KrautOS, thank you for your comment. So your hardware and problem may be tracked, could you please file a new report with Ubuntu by executing the following in a terminal while booted into a Ubuntu repository kernel (not a mainline one) via:
ubuntu-bug linux

For more on this, please read the official Ubuntu documentation:
Ubuntu Bug Control and Ubuntu Bug Squad: https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue
Ubuntu Kernel Team: https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports
Ubuntu Community: https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Thank you for your understanding.

Helpful bug reporting tips:
https://wiki.ubuntu.com/ReportingBugs

[Lonnie Lee Best (launchpad-startport)]

I installed Ubuntu 14.04 server on one of these HP Compaq dc7700 Small Form Factor PC machines.

After the first boot (after install), the command prompt constantly gets messages that look like this:
[ 1352.248013] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[ 1357.248022] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[ 1358.248033] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[ 1359.248053] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[ 135.2486063] mei_me 0000:00:03.0: timer: connect/disconnect timeout.

Every second this machine is on, logged in or not, these alerts bombard the terminal every second.

[Lonnie Lee Best (launchpad-startport)]

Dang, I just downgraded by doing a fresh install of server 12.04.4 (instead of server 14.04) (hoping this would go away).

No luck! It constantly posts these same mei_me alerts to the terminal; it makes it hard to even type commands; it constantly interrupts your typing flow.

[KrautOS (krautos)]

Then same on my old thick clients ;) AFAIK only fixable by blacklisting
the "mei" and "mei_me" kernel modules. But that should be better than
with a full text processing command, otherwise it gets nasty.

Am 17.04.2014 22:41, schrieb Lonnie Lee Best:
> Dang, I just downgraded by doing a fresh install of server 12.04.4
> (instead of server 14.04) (hoping this would go away).
>
> No luck! It constantly posts these same mei_me alerts to the terminal;
> it makes it hard to even type commands; it constantly interrupts your
> typing flow.
>

[TEN (launchpad-20-ten)]

Sigh (or in Bavarian actually, fittingly "mei" ;-)), this same bug since 12.04 seems back with the Ubuntu 14.04 LTS, stopping the installer (which loops slides infinitely without message nor progress) after it has mounted the /-to-be below /tmp to copy from USB.

See also https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1196155 (referenced in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1203520) and http://askubuntu.com/questions/419853/mei-me-unexpected-reset - hope we'll get rid of it much faster this time around, since the HP 7x00 CMTs and Dell 7xx Optiplexes are quite likely candidates to be made LTS machines (so how does this keep slipping into releases?).

How (and if, precisely when?) could one easily blacklist mei (and mei_me, if need be) when booting a LiveCD?

[TEN (launchpad-20-ten)]

It is possible to select Try rather than Install on the Live CD, then open a Ctrl-Alt-T window and invoke the following before starting the installation process via the icon on the trial desktop:
sudo rmmod mei_me
sudo rmmod mei

After installation has completed, /etc/modprobe.d/blacklist-mei.conf may be created as a workaround with these contents (then reboot):
blacklist mei_me
blacklist mei

Not sure how to report this as affecting https://bugs.launchpad.net/ubuntu/trusty/+source/linux (since linux-lts-trusty was the only package found but is tracking much less) - please complete/elaborate.

[Alexander Usyskin (sanniu)]

linux_3.13.0-32.57 kernel have patch to disable driver for broken grantly fw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301118
Can you check if this resolves your issue?

[Ldx (a-giove)]

Il 29/07/2014 16:08, Alexander Usyskin ha scritto:
> linux_3.13.0-32.57 kernel have patch to disable driver for broken grantly fw: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1301118
> Can you check if this resolves your issue?
>

Alexander, it seems that the bug you mentioned is quite old and maybe my
kernel already has the patch: 3.13.0-32-generic

Moreover, the bug itself seems quite different from that one affects my PC.

Last but not least, it's not clear to me how to install and test the
mentioned kernel patch.

Kind regards
Aldo

[Alexander Usyskin (sanniu)]

You have to look at exact package version to know if you have new enough kernel.
linux_3.13.0-32.57 kernel is out in -updates repository, so you can simply update your system to this package version.
The bug manifestation differs depending on kernel version, there are many iterations in of driver.
Can you post a dmesg from last kernel?

[Ldx (a-giove)]

Alexander, the dmesg content is 64k of text, so I put it into my dropbox instead of posting here:

https://dl.dropboxusercontent.com/u/50220945/dmesg

Kind regards
Aldo

[Alexander Usyskin (sanniu)]

[ 25.216133] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
[ 25.216143] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED

Ok, dmesg looks good from mei driver point of view. Do you have network slowdown (or other problems that manifests with 3.8) with this kernel?
The resetting message as you have in log usually means that is some is wrong with FW/HW - mei driver not receiving reply in timely manner.

To debug it future, you can enable dynamic debug for mei driver :
echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control
and wait for next reset

[Ldx (a-giove)]

Il 10/08/2014 12:01, Alexander Usyskin ha scritto:
> [ 25.216133] mei_me 0000:00:03.0: timer: connect/disconnect timeout.
> [ 25.216143] mei_me 0000:00:03.0: unexpected reset: dev_state = ENABLED
>
> Ok, dmesg looks good from mei driver point of view. Do you have network slowdown (or other problems that manifests with 3.8) with this kernel?

 From time to time, big file copy (hundreds of MB) hang, but it's a rare
event. For testing I've just copied a couple of files for a total of 3.5
GB with some speed issues. Speed was > 10 MB/s over a 100 mbps ethernet
for the major part of the transfer, then dropped down to 5 MB/s after ~2
GB (only for the bigger of the two files). I didn't investigate about
possible roles of the LAN switch, though.

> The resetting message as you have in log usually means that is some is wrong with FW/HW - mei driver not receiving reply in timely manner.
>
> To debug it future, you can enable dynamic debug for mei driver :
> echo -n 'module mei +lfp' > /sys/kernel/debug/dynamic_debug/control
> echo -n 'module mei_me +lfp' > /sys/kernel/debug/dynamic_debug/control
> and wait for next reset
>

Thanks for the info. Once I enable debug, what should I look for?

Thank you.
Aldo

[Alexander Usyskin (sanniu)]

> Thanks for the info. Once I enable debug, what should I look for?

I trying to look where connect process is stuck, if driver really write data to FW or not.

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[penalvch (penalvch)]

Ldx, could you please advise if this is still reproducible in a supported release?