Re: [char-misc 3.11 V2] mei: me: fix hardware reset flow

[Shuah Khan]

On 07/30/2013 01:30 PM, Winkler, Tomas wrote:
>
>>
>   >>> Both H_IS and H_IE needs to be set to receive H_RDY interrupt
>>>>>
>>>>> 1. Assert H_IS to clear the interrupts during hw reset and use
>>>>> mei_me_reg_write instead of mei_hcsr_set as the later strips down
>>>>> the H_IS
>>>>>
>>>>> 2. fix interrupt disablement embarrassing typo
>>>>>     hcsr |= ~H_IE -> hcsr &= ~H_IE;
>>>>> this will remove the unwanted interrupt on power down
>>>>>
>>>>> 3. remove useless debug print outs
>>>>>
>>>>> Cc: Shuah Khan <shuah.kh@xxxxxxxxxxx>
>>>>> Cc: Konstantin Khlebnikov <khlebnikov@xxxxxxxxxx>
>>>>> Signed-off-by: Tomas Winkler <tomas.winkler@xxxxxxxxx>
>>>>> ---
>>>>>
>>>>> V2: Fixed typo in Shuah email
>>>>>
>>>>> Hope this finally resolve the ME reset issue for all
>>>>
>>>> Can I get a "Tested-by:" from someone to ensure that it really does
>>>> solve the problem?
>>>
>>> Yes,  please wait for ack/test results. It works for me but unfortunately I
>> cannot go over all  9 gens of  PCH and all their proliferations  where ME
>> resides.
>>> I'm putting some effort to have better legacy HW testing coverage but I'm
>> not there yet.
>>>
>>
>> Tomas,
>>
>> I have a test system that has shows the mei_me reset problem after boot-
>> up. I tested this patch on top of 3.11-rc3 that has the previous 4 patches. I am
>> seeing the issue still on this system:
>>
>> 00:03.0 Communication controller: Intel Corporation 82Q963/Q965 HECI
>> Controller (rev 02)
>>           Subsystem: Hewlett-Packard Company Device 2801
>>           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 41
>>           Region 0: Memory at f0521900 (64-bit, non-prefetchable) [size=16]
>>           Capabilities: <access denied>
>>           Kernel driver in use: mei_me
>>
>>
>> I am attaching the dmesg. Please let me know if you need any more
>> information from the system.
>
> I'm not sure this error though looks similar is coming from the same source,  this is even after boot up, which  I haven't seen before.
> Would it be possible you open more logs through dynamic debug on mei and mei_me modules
> To preserve it over reboot I add it into /etc/modprobe.d/mei.conf
> options mei dyndbg="+plf"
> options mei_me dyndbg="+plf"
>
> Thanks
> Tomas
>

Tomas,

I tested the patch on the system I saw this problem during 
suspend/resume sequence. After 10 suspend-to-disk reboot mode and 10 
suspend-to-disk platform mode tests, I couldn't reproduce the problem. 
So does this mean the problem went away. I don't know. With all your 
fixes I no longer can reproduce the problem during suspend/resume 
sequence. I used to see once every 3 or 4 suspend-to-resume attempts on 
this system.

The second machine I have I see the problem often during run-time and 
that has nothing to do with suspend/resume. I will get the dyndbg data 
you asked for from that system.

You have my Tested-by for the original suspend/resume problem I reported.

-- Shuah

Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research 
America (Silicon Valley) shuah.kh@xxxxxxxxxxx | (970) 672-0658
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/