From: James Bottomley <James.Bottomley@HansenPartnership.com>
To: Hao Wu <hao.wu@rubrik.com>
Cc: peterhuewe@gmx.de, jarkko.sakkinen@linux.intel.com, jgg@ziepe.ca,
arnd@arndb.de, gregkh@linuxfoundation.org,
Hamza Attak <hamza@hpe.com>,
nayna@linux.vnet.ibm.com, why2jjj.linux@gmail.com,
zohar@linux.vnet.ibm.com, linux-integrity@vger.kernel.org,
Paul Menzel <pmenzel@molgen.mpg.de>,
Ken Goldman <kgold@linux.ibm.com>,
Seungyeop Han <seungyeop.han@rubrik.com>,
Shrihari Kalkar <shrihari.kalkar@rubrik.com>,
Anish Jhaveri <anish.jhaveri@rubrik.com>
Subject: Re: [PATCH] Fix Atmel TPM crash caused by too frequent queries
Date: Sun, 27 Sep 2020 11:25:39 -0700 [thread overview]
Message-ID: <cf5c8035b7183522fb8a5df4baa95bd24288e61f.camel@HansenPartnership.com> (raw)
In-Reply-To: <DFD7629C-05BF-46C1-B3D7-92FBBC176D9E@rubrik.com>
On Sat, 2020-09-26 at 16:10 -0700, Hao Wu wrote:
> Resending following email in plaintext.
>
> ----
>
> Hi James,
>
> Thanks for following up.
>
> We have actually tried change
> TPM_TIMEOUT_USECS_MIN / TPM_TIMEOUT_USECS_MAX
> according to https://patchwork.kernel.org/patch/10520247/
> It does not solve the problem for ATMEL chip. The chips facing crash
> is
> not experimental, but happens commonly in
> the production systems we and our customers are using.
> It is widely found in Cisco 220 / 240 systems which are using
> Ateml chips.
Well, I came up with the values in that patch by trial and error ....
all I know is they work for my nuvoton. If they're not right for you,
see if you can find what values actually do work for your TPM. The
difference between msleep and usleep_range is that the former can have
an indefinitely long timeout and the latter has a range bounded one.
If you think msleep works for you, the chances are it doesn't and
you're relying on the large upper bound to make the bug infrequent
enough for you not to see it. Playing with the values in usleep range
will help you find what the actual timeout is and eliminate the problem
for good.
James
next prev parent reply other threads:[~2020-09-27 18:25 UTC|newest]
Thread overview: 51+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-26 22:31 [PATCH] Fix Atmel TPM crash caused by too frequent queries Hao Wu
2020-09-26 22:57 ` James Bottomley
2020-09-26 23:10 ` Hao Wu
2020-09-27 18:25 ` James Bottomley [this message]
2020-09-28 0:11 ` Hao Wu
2020-09-28 0:15 ` Hao Wu
2020-09-28 1:22 ` James Bottomley
2020-09-28 5:59 ` Hao Wu
2020-09-28 22:11 ` James Bottomley
2020-09-29 4:46 ` Hao Wu
2020-09-30 2:16 ` Jarkko Sakkinen
2020-09-30 14:54 ` James Bottomley
2020-09-30 15:37 ` Jarkko Sakkinen
2020-09-30 20:48 ` James Bottomley
2020-09-30 21:09 ` Jarkko Sakkinen
2020-09-30 22:31 ` James Bottomley
2020-10-01 1:50 ` Jarkko Sakkinen
2020-10-01 4:53 ` James Bottomley
2020-10-01 18:15 ` Nayna
2020-10-01 18:32 ` James Bottomley
2020-10-01 23:04 ` Jarkko Sakkinen
2020-10-17 6:11 ` Hao Wu
2020-10-18 5:09 ` Jarkko Sakkinen
2020-10-18 5:20 ` Hao Wu
2020-11-14 4:39 ` Hao Wu
2020-11-18 21:11 ` Jarkko Sakkinen
2020-11-18 23:23 ` Hao Wu
2021-05-09 6:18 ` Hao Wu
2021-05-09 6:31 ` Hao Wu
2021-05-10 2:17 ` Mimi Zohar
2021-05-10 3:15 ` Hao Wu
2021-05-10 17:28 ` Jarkko Sakkinen
2020-09-28 1:08 ` Jarkko Sakkinen
2020-09-28 6:03 ` Hao Wu
2020-09-28 14:16 ` Jarkko Sakkinen
2020-09-28 17:49 ` Hao Wu
2020-09-28 19:47 ` Jarkko Sakkinen
2020-09-28 20:27 ` Hao Wu
2020-09-30 2:11 ` Jarkko Sakkinen
2020-09-30 3:41 ` Hao Wu
[not found] ` <EA1EE8F8-F054-4E1B-B830-231398D33CB8@rubrik.com>
2020-10-01 14:16 ` Mimi Zohar
-- strict thread matches above, loose matches on Subject: below --
2021-06-20 23:18 Hao Wu
2021-06-23 13:35 ` Jarkko Sakkinen
2021-06-24 5:49 ` Hao Wu
2021-06-29 20:06 ` Jarkko Sakkinen
2021-06-30 4:27 ` Hao Wu
2021-06-24 5:33 ` Hao Wu
2021-06-29 20:07 ` Jarkko Sakkinen
2020-09-14 6:13 Hao Wu
2020-09-14 6:17 ` Greg KH
2020-09-15 2:52 ` Hao Wu
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=cf5c8035b7183522fb8a5df4baa95bd24288e61f.camel@HansenPartnership.com \
--to=james.bottomley@hansenpartnership.com \
--cc=anish.jhaveri@rubrik.com \
--cc=arnd@arndb.de \
--cc=gregkh@linuxfoundation.org \
--cc=hamza@hpe.com \
--cc=hao.wu@rubrik.com \
--cc=jarkko.sakkinen@linux.intel.com \
--cc=jgg@ziepe.ca \
--cc=kgold@linux.ibm.com \
--cc=linux-integrity@vger.kernel.org \
--cc=nayna@linux.vnet.ibm.com \
--cc=peterhuewe@gmx.de \
--cc=pmenzel@molgen.mpg.de \
--cc=seungyeop.han@rubrik.com \
--cc=shrihari.kalkar@rubrik.com \
--cc=why2jjj.linux@gmail.com \
--cc=zohar@linux.vnet.ibm.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).