Public bug reported:
[Impact]
Dmesg shows a call trace after S3 cycle.
This has been fixed in v4.14-rc1 with
commit 9662d43f523dfc0dc242ec29c2921c43898d6ae5
Author: Yazen Ghannam <yazen.ghan...@amd.com>
Date: Mon Jul 24 12:12:28 2017 +0200
x86/mce/AMD: Allow any CPU to initialize the smca_banks array
Current SMCA implementations have the same banks on each CPU with the
non-core banks only visible to a "master thread" on each die. Practically,
this means the smca_banks array, which describes the banks, only needs to
be populated once by a single master thread.
CPU 0 seemed like a good candidate to do the populating. However, it's
possible that CPU 0 is not enabled in which case the smca_banks array won't
be populated.
Rather than try to figure out another master thread to do the populating,
we should just allow any CPU to populate the array.
Drop the CPU 0 check and return early if the bank was already initialized.
Also, drop the WARNing about an already initialized bank, since this will
be a common, expected occurrence.
The smca_banks array is only populated at boot time and CPUs are brought
online sequentially. So there's no need for locking around the array.
If the first CPU up is a master thread, then it will populate the array
with all banks, core and non-core. Every CPU afterwards will return
early. If the first CPU up is not a master thread, then it will populate
the array with all core banks. The first CPU afterwards that is a master
thread will skip populating the core banks and continue populating the
non-core banks.
Signed-off-by: Yazen Ghannam <yazen.ghan...@amd.com>
Signed-off-by: Borislav Petkov <b...@suse.de>
Acked-by: Jack Miller <j...@codezen.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Tony Luck <tony.l...@intel.com>
Cc: linux-edac <linux-e...@vger.kernel.org>
Link: http://lkml.kernel.org/r/20170724101228.17326-4...@alien8.de
Signed-off-by: Ingo Molnar <mi...@kernel.org>
[Test case]
Suspend/resume Raven Ridge, see that it doesn't show the call trace any
more.
[Regression potential]
4.14 released with it, and it fixes code which "for now" checked only
CPU 0, so regressions potential is slim to none.
** Affects: linux (Ubuntu)
Importance: Undecided
Assignee: Timo Aaltonen (tjaalton)
Status: Confirmed
** Affects: linux (Ubuntu Artful)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Artful)
Importance: Undecided
Status: New
** Changed in: linux (Ubuntu)
Status: New => Confirmed
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Timo Aaltonen (tjaalton)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1732894
Title:
CPU call trace on AMD Raven Ridge after S3
Status in linux package in Ubuntu:
Confirmed
Status in linux source package in Artful:
New
Bug description:
[Impact]
Dmesg shows a call trace after S3 cycle.
This has been fixed in v4.14-rc1 with
commit 9662d43f523dfc0dc242ec29c2921c43898d6ae5
Author: Yazen Ghannam <yazen.ghan...@amd.com>
Date: Mon Jul 24 12:12:28 2017 +0200
x86/mce/AMD: Allow any CPU to initialize the smca_banks array
Current SMCA implementations have the same banks on each CPU with the
non-core banks only visible to a "master thread" on each die. Practically,
this means the smca_banks array, which describes the banks, only needs to
be populated once by a single master thread.
CPU 0 seemed like a good candidate to do the populating. However, it's
possible that CPU 0 is not enabled in which case the smca_banks array
won't
be populated.
Rather than try to figure out another master thread to do the populating,
we should just allow any CPU to populate the array.
Drop the CPU 0 check and return early if the bank was already initialized.
Also, drop the WARNing about an already initialized bank, since this will
be a common, expected occurrence.
The smca_banks array is only populated at boot time and CPUs are brought
online sequentially. So there's no need for locking around the array.
If the first CPU up is a master thread, then it will populate the array
with all banks, core and non-core. Every CPU afterwards will return
early. If the first CPU up is not a master thread, then it will populate
the array with all core banks. The first CPU afterwards that is a master
thread will skip populating the core banks and continue populating the
non-core banks.
Signed-off-by: Yazen Ghannam <yazen.ghan...@amd.com>
Signed-off-by: Borislav Petkov <b...@suse.de>
Acked-by: Jack Miller <j...@codezen.org>
Cc: Linus Torvalds <torva...@linux-foundation.org>
Cc: Peter Zijlstra <pet...@infradead.org>
Cc: Thomas Gleixner <t...@linutronix.de>
Cc: Tony Luck <tony.l...@intel.com>
Cc: linux-edac <linux-e...@vger.kernel.org>
Link: http://lkml.kernel.org/r/20170724101228.17326-4...@alien8.de
Signed-off-by: Ingo Molnar <mi...@kernel.org>
[Test case]
Suspend/resume Raven Ridge, see that it doesn't show the call trace
any more.
[Regression potential]
4.14 released with it, and it fixes code which "for now" checked only
CPU 0, so regressions potential is slim to none.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1732894/+subscriptions
--
Mailing list: https://launchpad.net/~kernel-packages
Post to : kernel-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kernel-packages
More help : https://help.launchpad.net/ListHelp
