On 03/07/2018 10:33 AM, Paul Menzel wrote:
Dear Stephen,
Thank you for your quick response.
Am Dienstag, den 06.03.2018, 11:57 -0500 schrieb Stephen Douthit:
On 03/06/2018 11:04 AM, Paul Menzel wrote:
On 03/02/18 17:31, Kevin O'Connor wrote:
On Tue, Feb 27, 2018 at 02:17:08PM -0500, Stephen Douthit wrote:
[…]
Thanks. I committed this series.
The second commit introduced a regression with coreboot on the ASRock E350M1. There are a bunch of time-outs, causing the startup to be really slow. With no serial console, the user thinks, it’s not working and start to debug.
Looking through the the user manual for that board I don't see that it has a TPM, or even the header for one, so a timeout seems correct.
Indeed, no TPM is present.
Thanks for confirming.
Multiple 750ms timeouts does seem pretty painful though. I hadn't considered that tis_probe() would be called multiple times if no TPM was present.
What's the preferred way to have a probe function run and bail before rerunning the timeout? Just put a static flag in tis_probe()? The attached patch takes that approach. Please let me know if that fixes the issue for you, or if there's some other preferred pattern I should use here.
Unfortunately, that didn’t help.
$ git log --oneline -2 fd1cbb4 (HEAD -> master, origin/master, origin/HEAD) tpm: Save tis_probe() result to avoid a reun of lengthy timeouts 5adc8bd tpm: Handle unimplemented TIS_REG_IFACE_ID in tis_get_tpm_version()
And the time-outs seem to be around 20 seconds or more. Please find the log with time stamps attached (`sudo ./readserial.py /dev/ttyUSB0`).
Yikes, 20 seconds is the medium duration timeout, not the default A timeout of 750ms. I was poking the wrong area with the last patch. It looks like tis_probe() is propagating the return from tis_wait_access() in the no device present case.
Please try the attached patch instead of the 'tpm: Save tis_probe...' and see if that works better.
Thanks, Steve