On Wed, Apr 2, 2014 at 9:55 AM, tip-bot for Chen, Gong <[email protected]> wrote:
> Commit-ID: 27f6c573e0f77f7d1cc907c1494c99a61e48b7d8
> Gitweb: http://git.kernel.org/tip/27f6c573e0f77f7d1cc907c1494c99a61e48b7d8
> Author: Chen, Gong <[email protected]>
> AuthorDate: Thu, 27 Mar 2014 21:24:36 -0400
> Committer: Tony Luck <[email protected]>
> CommitDate: Fri, 28 Mar 2014 13:40:16 -0700
>
> x86, CMCI: Add proper detection of end of CMCI storms
>
> When CMCI storm persists for a long time(at least beyond predefined
> threshold. It's 30 seconds for now), we can watch CMCI storm is
> detected immediately after it subsides.
>
> ...
> Dec 10 22:04:29 kernel: CMCI storm detected: switching to poll mode
> Dec 10 22:04:59 kernel: CMCI storm subsided: switching to interrupt mode
> Dec 10 22:04:59 kernel: CMCI storm detected: switching to poll mode
> Dec 10 22:05:29 kernel: CMCI storm subsided: switching to interrupt mode
> ...
>
> The problem is that our logic that determines that the storm has
> ended is incorrect. We announce the end, re-enable interrupts and
> realize that the storm is still going on, so we switch back to
> polling mode. Rinse, repeat.
>
> When a storm happens we disable signaling of errors via CMCI and begin
> polling machine check banks instead. If we find any logged errors,
> then we need to set a per-cpu flag so that our per-cpu tests that
> check whether the storm is ongoing will see that errors are still
> being logged independently of whether mce_notify_irq() says that the
> error has been fully processed.
>
> cmci_clear() is not the right tool to disable a bank. It disables the
> interrupt for the bank as desired, but it also clears the bit for
> this bank in "mce_banks_owned" so we will skip the bank when polling
> (so we fail to see that the storm continues because we stop looking).
> New cmci_storm_disable_banks() just disables the interrupt while
> allowing polling to continue.
>
> Reported-by: William Dauchy <[email protected]>
Could you use the following address instead?
Reported-by: William Dauchy <[email protected]>
Thanks,
> Signed-off-by: Chen, Gong <[email protected]>
> Signed-off-by: Tony Luck <[email protected]>
--
William
On Wed, Apr 02, 2014 at 10:51:49AM +0200, William Dauchy wrote:
> Could you use the following address instead?
> Reported-by: William Dauchy <[email protected]>
It is too late for that now as the patch is in -tip already... Unless
Ingo can still amend it, that is.
But, we're working on a real solution for the storm issue and there
we'll be asking you to test stuff anyway so we'll make sure to use this
mail address then, ok?
:-)
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--
On Apr02 11:01, Borislav Petkov wrote:
> It is too late for that now as the patch is in -tip already... Unless
> Ingo can still amend it, that is.
>
> But, we're working on a real solution for the storm issue and there
> we'll be asking you to test stuff anyway so we'll make sure to use this
> mail address then, ok?
ack
--
William
* Borislav Petkov <[email protected]> wrote:
> On Wed, Apr 02, 2014 at 10:51:49AM +0200, William Dauchy wrote:
> > Could you use the following address instead?
> > Reported-by: William Dauchy <[email protected]>
>
> It is too late for that now as the patch is in -tip already... Unless
> Ingo can still amend it, that is.
There are already patches on top of it, so it's not possible - but
even if it was the last one, since it got committed by Tony I cannot
rebase or amend it.
Thanks,
Ingo
On Wed, Apr 02, 2014 at 12:46:12PM +0200, Ingo Molnar wrote:
> There are already patches on top of it, so it's not possible - but
> even if it was the last one, since it got committed by Tony I cannot
> rebase or amend it.
Ah right, you pulled it from him, sure.
Thanks.
--
Regards/Gruss,
Boris.
Sent from a fat crate under my desk. Formatting is fine.
--