All of lore.kernel.org
 help / color / mirror / Atom feed
From: Boris Petkov <bp@suse.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc: Johannes Hirte <johannes.hirte@datenkhaos.de>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: [3/3] x86/MCE/AMD: Get address from already initialized block
Date: Thu, 17 May 2018 15:44:15 +0200	[thread overview]
Message-ID: <20180517134415.GC27738@pd.tnic> (raw)

On Thu, May 17, 2018 at 01:04:19PM +0000, Ghannam, Yazen wrote:
> Yes, you're right. I thought using the existing data structures would work, but it
> seems I messed up the implementation.

Not only that - your idea wouldn't fly because the per-CPU stuff you
were using gets torn down when the CPU goes offline so you can't use
them on resume because they're not there yet.

> Banks 15 and 16 should have an address for block 1 also. Do you have PFEH
> enabled on your system? That would cause MISC0 to be RAZ so we won't
> get the MISC1 address. I'll try it myself also and let you know.

I check PFEH is enabled how?

> I think this good for now. We'll probably need to change it in the
> future, but maybe we can clean up all the thresholding blocks code and
> make it simpler when we do change it.

Ok.

> This hunk could go above the !block. Though maybe the macro is lighter than the
> array lookup. It'll work either way, but I'm just thinking out loud.

Yeah, it doesn't matter in that case.

> Since we're caching the values during init, we can drop all the
> *_on_cpu() calls. What do you think?

Well, if they're all the same on all CPUs, sure. That's your call.

WARNING: multiple messages have this Message-ID (diff)
From: Borislav Petkov <bp@suse.de>
To: "Ghannam, Yazen" <Yazen.Ghannam@amd.com>
Cc: Johannes Hirte <johannes.hirte@datenkhaos.de>,
	"linux-edac@vger.kernel.org" <linux-edac@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"tony.luck@intel.com" <tony.luck@intel.com>,
	"x86@kernel.org" <x86@kernel.org>
Subject: Re: [PATCH 3/3] x86/MCE/AMD: Get address from already initialized block
Date: Thu, 17 May 2018 15:44:15 +0200	[thread overview]
Message-ID: <20180517134415.GC27738@pd.tnic> (raw)
In-Reply-To: <CY4PR12MB1557AB31F5F9D1ECBDAC2DA6F8910@CY4PR12MB1557.namprd12.prod.outlook.com>

On Thu, May 17, 2018 at 01:04:19PM +0000, Ghannam, Yazen wrote:
> Yes, you're right. I thought using the existing data structures would work, but it
> seems I messed up the implementation.

Not only that - your idea wouldn't fly because the per-CPU stuff you
were using gets torn down when the CPU goes offline so you can't use
them on resume because they're not there yet.

> Banks 15 and 16 should have an address for block 1 also. Do you have PFEH
> enabled on your system? That would cause MISC0 to be RAZ so we won't
> get the MISC1 address. I'll try it myself also and let you know.

I check PFEH is enabled how?

> I think this good for now. We'll probably need to change it in the
> future, but maybe we can clean up all the thresholding blocks code and
> make it simpler when we do change it.

Ok.

> This hunk could go above the !block. Though maybe the macro is lighter than the
> array lookup. It'll work either way, but I'm just thinking out loud.

Yeah, it doesn't matter in that case.

> Since we're caching the values during init, we can drop all the
> *_on_cpu() calls. What do you think?

Well, if they're all the same on all CPUs, sure. That's your call.

-- 
Regards/Gruss,
    Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)
-- 

             reply	other threads:[~2018-05-17 13:44 UTC|newest]

Thread overview: 47+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-17 13:44 Boris Petkov [this message]
2018-05-17 13:44 ` [PATCH 3/3] x86/MCE/AMD: Get address from already initialized block Borislav Petkov
  -- strict thread matches above, loose matches on Subject: below --
2018-05-17 19:33 [3/3] " Boris Petkov
2018-05-17 19:33 ` [PATCH 3/3] " Borislav Petkov
2018-05-17 19:29 [3/3] " Johannes Hirte
2018-05-17 19:29 ` [PATCH 3/3] " Johannes Hirte
2018-05-17 18:31 [2/2] x86/MCE/AMD: Read MCx_MISC block addresses on any CPU Boris Petkov
2018-05-17 18:31 ` [PATCH 2/2] " Borislav Petkov
2018-05-17 18:30 [1/2] x86/MCE/AMD: Cache SMCA MISC block addresses Boris Petkov
2018-05-17 18:30 ` [PATCH 1/2] " Borislav Petkov
2018-05-17 14:05 [3/3] x86/MCE/AMD: Get address from already initialized block Yazen Ghannam
2018-05-17 14:05 ` [PATCH 3/3] " Ghannam, Yazen
2018-05-17 13:04 [3/3] " Yazen Ghannam
2018-05-17 13:04 ` [PATCH 3/3] " Ghannam, Yazen
2018-05-17 10:41 [3/3] " Boris Petkov
2018-05-17 10:41 ` [PATCH 3/3] " Borislav Petkov
2018-05-17  6:49 [3/3] " Johannes Hirte
2018-05-17  6:49 ` [PATCH 3/3] " Johannes Hirte
2018-05-16 22:46 [3/3] " Boris Petkov
2018-05-16 22:46 ` [PATCH 3/3] " Borislav Petkov
2018-05-15  9:39 [3/3] " Johannes Hirte
2018-05-15  9:39 ` [PATCH 3/3] " Johannes Hirte
2018-04-17 13:31 [3/3] " Yazen Ghannam
2018-04-17 13:31 ` [PATCH 3/3] " Ghannam, Yazen
2018-04-16 11:56 [3/3] " Johannes Hirte
2018-04-16 11:56 ` [PATCH 3/3] " Johannes Hirte
2018-04-14  0:42 [3/3] " Johannes Hirte
2018-04-14  0:42 ` [PATCH 3/3] " Johannes Hirte
2018-05-19 13:21 ` [tip:ras/urgent] x86/MCE/AMD: Cache SMCA MISC block addresses tip-bot for Borislav Petkov
2018-02-14 19:35 [1/3] x86/MCE/AMD: Redo function to get SMCA bank type Boris Petkov
2018-02-14 19:35 ` [PATCH 1/3] " Borislav Petkov
2018-02-14 16:38 [1/3] " Yazen Ghannam
2018-02-14 16:38 ` [PATCH 1/3] " Ghannam, Yazen
2018-02-14 16:28 [2/3] x86/MCE/AMD, EDAC/mce_amd: Enumerate Reserved " Yazen Ghannam
2018-02-14 16:28 ` [PATCH 2/3] " Ghannam, Yazen
2018-02-08 15:26 [3/3] x86/MCE/AMD: Get address from already initialized block Borislav Petkov
2018-02-08 15:26 ` [PATCH 3/3] " Borislav Petkov
2018-02-08 15:15 [2/3] x86/MCE/AMD, EDAC/mce_amd: Enumerate Reserved SMCA bank type Borislav Petkov
2018-02-08 15:15 ` [PATCH 2/3] " Borislav Petkov
2018-02-08 15:04 [1/3] x86/MCE/AMD: Redo function to get " Borislav Petkov
2018-02-08 15:04 ` [PATCH 1/3] " Borislav Petkov
2018-02-01 18:48 [3/3] x86/MCE/AMD: Get address from already initialized block Yazen Ghannam
2018-02-01 18:48 ` [PATCH 3/3] " Yazen Ghannam
2018-02-01 18:48 [2/3] x86/MCE/AMD, EDAC/mce_amd: Enumerate Reserved SMCA bank type Yazen Ghannam
2018-02-01 18:48 ` [PATCH 2/3] " Yazen Ghannam
2018-02-01 18:48 [1/3] x86/MCE/AMD: Redo function to get " Yazen Ghannam
2018-02-01 18:48 ` [PATCH 1/3] " Yazen Ghannam

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180517134415.GC27738@pd.tnic \
    --to=bp@suse.de \
    --cc=Yazen.Ghannam@amd.com \
    --cc=johannes.hirte@datenkhaos.de \
    --cc=linux-edac@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tony.luck@intel.com \
    --cc=x86@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.