Re: MEI ?

This is the ELKS (Linux-8086) mailing list, not the Linux kernel mailing 
list

On 9/14/2017 1:44 PM, Jason Vas Dias wrote:
> Running 4.12.10 under x86_64, and with all previous 4.x versions
> as I remember, I see an attempt to load the MEI driver on my
> CPU, which is :
>    $ cpuinfo 'model name'
>    Intel(R) Core(TM) i7-4910MQ CPU @ 2.90GHz
> A 4 CPU 8 core 2.9ghz - 3.9ghz Haswell .
>
>    $ lspci -vnk -s 00:16.0
> 00:16.0 0780: 8086:8c3a (rev 04)
> 	Subsystem: 1558:5106
> 	Flags: bus master, fast devsel, latency 0, IRQ 29
> 	Memory at f7c1e000 (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
>
>
> But the mei driver gets disabled :
>
> kernel: [   27.493573] device class 'mei': registering
> kernel: [   27.493589] bus: 'mei': registered
> kernel: [   27.493592] bus: 'pci': add driver mei_me
> kernel: [   27.493600] bus: 'pci': driver_probe_device: matched device
> 0000:00:16.0 with driver mei_me
> kernel: [   27.493603] bus: 'pci': really_probe: probing driver mei_me
> with device 0000:00:16.0
> kernel: [   27.493607] mei_me 0000:00:16.0: no default pinctrl state
> kernel: [   27.494530] device: 'mei0': device_add
> kernel: [   27.494551] PM: Adding info for No Bus:mei0
> kernel: [   27.494698] driver: 'mei_me': driver_bound: bound to device
> '0000:00:16.0'
> kernel: [   27.494701] bus: 'pci': really_probe: bound device
> 0000:00:16.0 to driver mei_me
> kernel: [   27.494756] bus: 'pci': add driver mei_txe
> kernel: [   27.751153] bus: 'mei': add driver mei_wdt
> kernel: [   58.209075] mei_me 0000:00:16.0: timer: init clients
> timeout hbm_state = 2.
> kernel: [   58.210064] mei_me 0000:00:16.0: unexpected reset:
> dev_state = INIT_CLIENTS fw status = 1E000042 60002106 00000200
> 00000000 00000000 00000000
> jvdlux kernel: [   88.929484] mei_me 0000:00:16.0: timer: init clients
> timeout hbm_state = 2.
>   kernel: [   88.931704] mei_me 0000:00:16.0: unexpected reset:
> dev_state = INIT_CLIENTS fw status = 1E000042 60002106 00000200
> 00000000 00000000 00000000
> kernel: [  119.648100] mei_me 0000:00:16.0: timer: init clients
> timeout hbm_state = 2.
> kernel: [  119.648121] mei_me 0000:00:16.0: unexpected reset:
> dev_state = INIT_CLIENTS fw status = 1E000042 60002106 00000200
> 00000000 00000000 00000000
> kernel: [  119.648126] mei_me 0000:00:16.0: reset: reached maximal
> consecutive resets: disabling the device
>
>
> I am actually glad, have read about what it is meant to do, with "AMT"
> etc,  that
> this "spy in the cab" does appear to be disabled on my platform.
>
> Is it really disabled ?   I cannot use any of the Intel MEI query programs -
> they are unable to open /dev/mei0, so it looks to be certainly disabled in
> userpace .
>
> But the thought that I have a whole processor and embedded operating system
> on my system that I have zero control over is frightening and annoying that I
> cannot make use of it .
>
> Can anyone tell if this is an ARC Core running ThreadX, or an Intel
> Quark running
> MINIX, as suggested on Wikipedia ?
>
> Am I correct in understanding there is no way of utilizing this MEI
> processor to run
> any code not signed with an Intel Key, even if I managed to flash the
> MEI embedded OS in ROM ?
>
> Am I right in thinking it is currently completely unused and disabled
> on my system ?
>
> Is this version of MEI + linux MEI driver capable of doing "Wakeup from LAN" on
> receipt of an ethernet packet or wifi packet ? Any way of fixing it so
> it can do this?
>
> Any advice much appreciated,
> Thanks & Regards,
> Jason Vas Dias
>
>
> Am I right in understand
> --
> To unsubscribe from this list: send the line "unsubscribe linux-8086" in
> the body of a message to [email protected]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html