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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 30 Jul 2013 19:30:24 +0000
From:	"Winkler, Tomas" <tomas.winkler@...el.com>
To:	Shuah Khan <shuah.kh@...sung.com>
CC:	Greg KH <gregkh@...uxfoundation.org>,
	"arnd@...db.de" <arnd@...db.de>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"Konstantin Khlebnikov" <khlebnikov@...nvz.org>
Subject: RE: [char-misc 3.11 V2] mei: me: fix hardware reset flow


>
 >>> 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@...sung.com>
> >>> Cc: Konstantin Khlebnikov <khlebnikov@...nvz.org>
> >>> Signed-off-by: Tomas Winkler <tomas.winkler@...el.com>
> >>> ---
> >>>
> >>> 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
 

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/