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
