From: Bhaskar Upadhaya <bhaskar.upadhaya.linux@gmail.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Bhaskar Upadhaya <bupadhaya@marvell.com>,
linux-kernel@vger.kernel.org, linux-acpi@vger.kernel.org,
linux-edac@vger.kernel.org, lenb@kernel.org, rafael@kernel.org,
gkulkarni@marvell.com, rrichter@marvell.com
Subject: Re: [RFC PATCH] apei/ghes: fix ghes_poll_func by registering in non-deferrable mode
Date: Mon, 6 Jan 2020 16:33:19 +0530 [thread overview]
Message-ID: <CAEYJA6oXTxTmJEji5_Hup2oB+GrgGnmSTiS-nNuzbNzGJ9VESA@mail.gmail.com> (raw)
In-Reply-To: <20200102180130.GG8345@zn.tnic>
On Thu, Jan 2, 2020 at 11:31 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Tue, Dec 17, 2019 at 11:03:38PM -0800, Bhaskar Upadhaya wrote:
> > Currently Linux register ghes_poll_func with TIMER_DEFERRABLE flag,
> > because of which it is serviced when the CPU eventually wakes up with a
> > subsequent non-deferrable timer and not at the configured polling interval.
> >
> > For polling mode, the polling interval configured by firmware should not
> > be exceeded as per ACPI_6_3 spec[refer Table 18-394],
>
> I see
>
> "Table 18-394 Hardware Error Notification Structure"
>
> where does it say that the interval should not be exceeded and what is
> going to happen if it gets exceeded?
Definition of poll interval as per spec (referred ACPI 6.3):
"Indicates the poll interval in milliseconds OSPM should use to
periodically check the error source for the presence of an error
condition."
This indicates OSPM should periodically check error source within poll
interval, but with timer being configured with TIMER_DEFERRABLE, timer
is not called within poll interval limit
>
> IOW, are you fixing something you're observing on some platform or
> you're reading the spec only?
We are observing an issue in our ThunderX2 platforms wherein
ghes_poll_func is not called within poll interval when timer is
configured with TIMER_DEFERRABLE flag(For NO_HZ kernel) and hence we
are losing the error records.
>
> --
> Regards/Gruss,
> Boris.
>
> https://people.kernel.org/tglx/notes-about-netiquette
next prev parent reply other threads:[~2020-01-06 11:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-18 7:03 [RFC PATCH] apei/ghes: fix ghes_poll_func by registering in non-deferrable mode Bhaskar Upadhaya
2020-01-02 10:49 ` Bhaskar Upadhaya
2020-01-02 18:01 ` Borislav Petkov
2020-01-06 11:03 ` Bhaskar Upadhaya [this message]
2020-01-06 13:09 ` Borislav Petkov
2020-01-07 11:03 ` Bhaskar Upadhaya
2020-01-07 13:04 ` Robert Richter
2020-01-07 20:02 ` Borislav Petkov
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=CAEYJA6oXTxTmJEji5_Hup2oB+GrgGnmSTiS-nNuzbNzGJ9VESA@mail.gmail.com \
--to=bhaskar.upadhaya.linux@gmail.com \
--cc=bp@alien8.de \
--cc=bupadhaya@marvell.com \
--cc=gkulkarni@marvell.com \
--cc=lenb@kernel.org \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-edac@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=rafael@kernel.org \
--cc=rrichter@marvell.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).