With tpm-correct-tpm-timeouts-to-jiffies-conversion.patch reverted, I
get -ETIME errors from libtpm2.0/utils/tpm_demo:
With the patch in place, the first read dies horribly, as reported by
strace -T -r utils/tpm_demo:
0.000969 open("/dev/tpm0", O_RDWR) = 3 <0.000080>
0.000237 write(3, "\0\301\0\0\0\22\0\0\0e\0\0\0\6\0\0\0\0", 18) = 18 <0.012652>
0.012814 read(3, 0x7fffd26cd430, 4096) = -1 ETIME (Timer expired) <0.000068>
0.000168 close(3) = 0 <0.000041>
0.000132 exit_group(-1) = ?
Note that the write() call took 0.012 seconds, but the read() was hit with
a -ETIME after only 0.000068 seconds, so it's obviously too short. With
the patch reverted, the timings look like:
0.000237 open("/dev/tpm0", O_RDWR) = 3 <0.000044>
0.000195 write(3, "\0\301\0\0\0\22\0\0\0e\0\0\0\6\0\0\0\0", 18) = 18 <0.012048>
0.012221 read(3, "\0\304\0\0\0\22\0\0\0\0\0\0\0\4\1\1\0\0", 4096) = 18 <0.000049>
0.000172 close(3) = 0 <0.000029>
and things continue merrily along...
Dumping the raw values in the 'data + TPM_GET_CAP_mumble' I see:
[ 2170.060661] timeout 1 = 750000
[ 2170.060866] timeout 2 = 2000000
[ 2170.060994] timeout 3 = 750000
[ 2170.061119] timeout 4 = 750000
[ 2170.072437] raw durations are 1000 2000000 120000000
(all values are before application of foo_to_jiffies)
So is the spec wrong, or is my chipset on drugs, or?
2008/7/11 <[email protected]>:
>
> So is the spec wrong, or is my chipset on drugs, or?
>
Can you provide configuration information?
- used TPM chip
- used TPM kernel modules
Regards
Marcin Obara
On Fri, 11 Jul 2008 21:39:52 +0200, Marcin Obara said:
> 2008/7/11 <[email protected]>:
>
> >
> > So is the spec wrong, or is my chipset on drugs, or?
> >
> Can you provide configuration information?
> - used TPM chip
> - used TPM kernel modules
This is on a Dell Latitude D820 with an x86_64 2.6.25-rc8-mm kernel.
% lsmod | grep tpm
tpm_tis 11660 0
tpm 13760 1 tpm_tis
tpm_bios 6464 1 tpm
dmesg says:
tpm_tis 00:0f: 1.2 TPM (device-id 0x1001, rev-id 2)
and lspnp -v says:
00:0f BCM0102 TPM chipset
state = active
mem 0xfed40000-0xfed44fff
io 0xcb0-0xcbb
(Yes, I'm confused why it's BCM0102 and not BCM0101)..
2008/7/11 <[email protected]>:
> With tpm-correct-tpm-timeouts-to-jiffies-conversion.patch reverted, I
> get -ETIME errors from libtpm2.0/utils/tpm_demo:
>
> With the patch in place, the first read dies horribly, as reported by
> strace -T -r utils/tpm_demo:
>
> 0.000969 open("/dev/tpm0", O_RDWR) = 3 <0.000080>
> 0.000237 write(3, "\0\301\0\0\0\22\0\0\0e\0\0\0\6\0\0\0\0", 18) = 18 <0.012652>
> 0.012814 read(3, 0x7fffd26cd430, 4096) = -1 ETIME (Timer expired) <0.000068>
> 0.000168 close(3) = 0 <0.000041>
> 0.000132 exit_group(-1) = ?
>
> Note that the write() call took 0.012 seconds, but the read() was hit with
> a -ETIME after only 0.000068 seconds, so it's obviously too short.
Not exactly.
read() call only returns result of already done TPM transmission.
All TPM transmission is done in write() call.
Transmission contains 3 timeoutable operations connected with timeout values:
- timeout 2 (_b) = 2000000 = 2 sec
in tpm_tis.c:tpm_tis_send():
if (wait_for_stat
(chip, TPM_STS_COMMAND_READY, chip->vendor.timeout_b,
&chip->vendor.int_queue) < 0) {
rc = -ETIME;
- for ordinal = 0xe0 - duration TPM_SHORT = 1000 = 0,001 sec
in tpm_tis.c:tpm_tis_send():
if (wait_for_stat
(chip, TPM_STS_DATA_AVAIL | TPM_STS_VALID,
tpm_calc_ordinal_duration(chip, ordinal),
&chip->vendor.read_queue) < 0) {
rc = -ETIME;
- timeout 3 (_c) = 750000 = 0,75 sec
in tmp_tis.c:recv_data():
wait_for_stat(chip,
TPM_STS_DATA_AVAIL | TPM_STS_VALID,
chip->vendor.timeout_c,
&chip->vendor.read_queue)
So for this example, we have timeouts:
- 2 sec (timeout_b)
- 0,001 sec (TPM_SHORT)
- 0,75 sec (timeout_c)
Transaction time was
0,013 sec ( > 0.001)
write() call response would be at least 0,75 sec if failed on
timeout_b or timeout_c.
It looks like duration TPM_SHORT = 1000 returned by your Broadcom chip
is too short (=wrong).
> Dumping the raw values in the 'data + TPM_GET_CAP_mumble' I see:
>
> [ 2170.060661] timeout 1 = 750000
> [ 2170.060866] timeout 2 = 2000000
> [ 2170.060994] timeout 3 = 750000
> [ 2170.061119] timeout 4 = 750000
> [ 2170.072437] raw durations are 1000 2000000 120000000
>
> (all values are before application of foo_to_jiffies)
>
> So is the spec wrong, or is my chipset on drugs, or?
So your chipset is on drugs.
It's strange range of returned timeouts/durations:
0,75 / 2 / 0,75 / 0,75 (sec)
0,001 / 2 / 120 (sec)
With reversed patch timeouts would be:
12,5 min / 33 min / 12,5 min / 12,5 min
1 sec / ~33 min / ~33 hours!!!!
I can not event imagine TPM driver hanging for over 1 day on one write() call .
In my opinion Broadcom 0102 TPM chip is broken.
Regards
Marcin