patch tpm-correct-tpm-timeouts-to-jiffies-conversion.patch breaks stuff

patch tpm-correct-tpm-timeouts-to-jiffies-conversion.patch breaks stuff

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 1378 bytes --]

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?

[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: patch tpm-correct-tpm-timeouts-to-jiffies-conversion.patch breaks stuff

[Marcin Obara]

2008/7/11  <Valdis.Kletnieks@vt.edu>:

>
> 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

Re: patch tpm-correct-tpm-timeouts-to-jiffies-conversion.patch breaks stuff

[Valdis.Kletnieks]

[-- Attachment #1: Type: text/plain, Size: 699 bytes --]

On Fri, 11 Jul 2008 21:39:52 +0200, Marcin Obara said:
> 2008/7/11  <Valdis.Kletnieks@vt.edu>:
> 
> >
> > 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)..


[-- Attachment #2: Type: application/pgp-signature, Size: 226 bytes --]

Re: patch tpm-correct-tpm-timeouts-to-jiffies-conversion.patch breaks stuff

[Marcin Obara]

2008/7/11  <Valdis.Kletnieks@vt.edu>:
> 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