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

[Winkler, Tomas]

> 
> 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

Thanks very much for your effort!!!
I'm really curious for the second machine output.

Thanks
Tomas

--
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/