On Sun, Sep 27, 2020 at 11:25:39AM -0700, James Bottomley wrote: > 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 I think I should revert 424eaf910c329, up until more legit values are found. /Jarkko
