On Fri, Jun 07, 2019 at 06:37:23PM +0200, Borislav Petkov wrote:
> On Fri, Jun 07, 2019 at 02:49:42PM +, Ghannam, Yazen wrote:
> > Would you mind if the function name stayed the same? The reason is
> > that MCA_CTL is written here, which is the "init" part, and MCA_STATUS
> > is cleared.
> >
>
On Fri, Jun 07, 2019 at 05:08:04PM +, Ghannam, Yazen wrote:
> Right, I took that branch, squashed the locking fix into patch 2,
> fixed up the remaining patches, and then redid the last patch.
>
> I plan to send the result as a v4 of this patchset with all the links,
> version history, etc. Is
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, June 7, 2019 11:59 AM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
On Fri, Jun 07, 2019 at 04:44:24PM +, Ghannam, Yazen wrote:
> I have another version of this set that I can send today. It includes
> the changes for this patch and also includes the fix for the locking
> bug message.
>
> Should I send out the new version? Or do you want me to wait for any
>
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, June 7, 2019 11:37 AM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
On Fri, Jun 07, 2019 at 02:49:42PM +, Ghannam, Yazen wrote:
> Would you mind if the function name stayed the same? The reason is
> that MCA_CTL is written here, which is the "init" part, and MCA_STATUS
> is cleared.
>
> I can use another name for the check, e.g. __mcheck_cpu_check_banks()
> or
> -Original Message-
> From: Borislav Petkov
> Sent: Monday, May 27, 2019 6:29 PM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that g
On Thu, May 23, 2019 at 08:00:33PM +, Ghannam, Yazen wrote:
> I did a bit more testing and I noticed that writing "0" disables a bank with
> no way to reenable it.
>
> For example:
> 1) Read bank10.
> a) Succeeds; returns "fff".
> 2) Write "0" to bank10.
> a)
> -Original Message-
> From: Borislav Petkov
> Sent: Friday, May 17, 2019 3:02 PM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that g
On Fri, May 17, 2019 at 07:49:10PM +, Ghannam, Yazen wrote:
> > @@ -1569,7 +1575,13 @@ static void __mcheck_cpu_init_clear_banks(void)
> >
> > if (!b->init)
> > continue;
> > +
> > + /* Check if any bits are implemented in h/w */
> >
On Fri, May 17, 2019 at 12:44:05PM -0700, Luck, Tony wrote:
> Much neater :-)
Finally! :-)
> Acked-by: Tony Luck
Thx.
Yazen, any objections left?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, May 17, 2019 2:35 PM
> To: Luck, Tony
> Cc: Ghannam, Yazen ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
On Fri, May 17, 2019 at 09:34:31PM +0200, Borislav Petkov wrote:
> On Fri, May 17, 2019 at 11:06:07AM -0700, Luck, Tony wrote:
> > and thus end up with that extra level on indent for the rest
> > of the function.
>
> Ok:
>
> @@ -1569,7 +1575,13 @@ static void __mcheck_cpu_init_clear_banks(void)
On Fri, May 17, 2019 at 11:06:07AM -0700, Luck, Tony wrote:
> and thus end up with that extra level on indent for the rest
> of the function.
Ok:
---
diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
index 5bcecadcf4d9..25e501a853cd 100644
---
On Fri, May 17, 2019 at 07:48:17PM +0200, Borislav Petkov wrote:
> @@ -1562,15 +1567,21 @@ static void __mcheck_cpu_init_generic(void)
> static void __mcheck_cpu_init_clear_banks(void)
> {
> struct mce_bank *mce_banks = this_cpu_read(mce_banks_array);
> + u64 msrval;
> int i;
>
On Fri, May 17, 2019 at 10:26:49AM -0700, Luck, Tony wrote:
> Which is a quirk for some models where we don't want to do
> the "write all 1s and see what sticks"
Ok, then we have to do what you suggested yesterday. I've added a short
comment so that I don't get lost again next time.
---
diff
On Fri, May 17, 2019 at 06:37:29PM +0200, Borislav Petkov wrote:
> Now, the
>
> wrmsrl(msr_ops.ctl(i), -1)
> rdmsrl(msr_ops.ctl(i), val);
>
> method of throwing all 1s to see what sticks is what Intel wants, as
> Tony said. Is that going to be a problem on AMD?
It is what we want in
On Fri, May 17, 2019 at 03:46:07PM +, Ghannam, Yazen wrote:
> I think there are a couple of issues here.
> 1) The bank is being initialized without accounting for any quirks.
Almost. __mcheck_cpu_init_clear_banks() a little bit later corrects
that. I guess I can drop the
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Friday, May 17, 2019 5:10 AM
> To: Luck, Tony
> Cc: Ghannam, Yazen ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
On Thu, May 16, 2019 at 01:59:43PM -0700, Luck, Tony wrote:
> I think the intent of the original patch was to find out
> which bits are "implemented in hardware". I.e. throw all
> 1's at the register and see if any of them stick.
And, in addition, check ->init before showing/setting a bank:
---
On Thu, May 16, 2019 at 10:34:56PM +0200, Borislav Petkov wrote:
> On Thu, May 16, 2019 at 08:20:58PM +, Ghannam, Yazen wrote:
> > We don't actually know if there are bits set in hardware until we read
> > it back. So I don't think this is adding anything new.
>
> Bah, of course. We need to
On Thu, May 16, 2019 at 08:20:58PM +, Ghannam, Yazen wrote:
> We don't actually know if there are bits set in hardware until we read
> it back. So I don't think this is adding anything new.
Bah, of course. We need to read it first (pasting the whole function).
Now,
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Thursday, May 16, 2019 12:21 PM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
On Thu, May 16, 2019 at 05:09:11PM +, Ghannam, Yazen wrote:
> So that the sysfs files show the control values that are set in the
> hardware. It seemed like this would be more helpful than showing all
> 0xF's.
Yeah, but it has been like that since forever and it hasn't bugged
anybody.
> -Original Message-
> From: linux-edac-ow...@vger.kernel.org On
> Behalf Of Borislav Petkov
> Sent: Thursday, May 16, 2019 11:57 AM
> To: Ghannam, Yazen
> Cc: Luck, Tony ; linux-e...@vger.kernel.org;
> linux-kernel@vger.kernel.org; x...@kernel.org
> Subject: Re
On Thu, May 16, 2019 at 04:14:14PM +, Ghannam, Yazen wrote:
> I can put a vendor check on the read. Is that sufficient?
Or we can drop this patch. Remind me again pls why do we need it?
--
Regards/Gruss,
Boris.
Good mailing practices for 400: avoid top-posting and trim the reply.
> -Original Message-
> From: Luck, Tony
> Sent: Thursday, May 16, 2019 10:52 AM
> To: Ghannam, Yazen
> Cc: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; b...@suse.de;
> x...@kernel.org
> Subject: Re: [PATCH v3 5/6] x86/MCE: Save MCA control bits that g
On Tue, Apr 30, 2019 at 08:32:20PM +, Ghannam, Yazen wrote:
> diff --git a/arch/x86/kernel/cpu/mce/core.c b/arch/x86/kernel/cpu/mce/core.c
> index 986de830f26e..551366c155ef 100644
> --- a/arch/x86/kernel/cpu/mce/core.c
> +++ b/arch/x86/kernel/cpu/mce/core.c
> @@ -1567,10 +1567,13 @@ static
28 matches
Mail list logo
