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 <[email protected]> >>>>> Cc: Konstantin Khlebnikov <[email protected]> >>>>> Signed-off-by: Tomas Winkler <[email protected]> >>>>> --- >>>>> >>>>> 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) [email protected] | (970) 672-0658 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
