[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4D70FAC2.5010109@linux.vnet.ibm.com>
Date: Fri, 04 Mar 2011 11:44:18 -0300
From: Rajiv Andrade <srajiv@...ux.vnet.ibm.com>
To: "Ted Ts'o" <tytso@....edu>,
Linus Torvalds <torvalds@...ux-foundation.org>,
James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org
Subject: Re: [REGRESSION] tpm_tis on Lenovo T410 broken in 2.6.38-rc6
Hi Ted, sorry for the delay.
On 03/01/2011 06:37 PM, Ted Ts'o wrote:
> On Tue, Mar 01, 2011 at 06:14:25PM -0300, Rajiv Andrade wrote:
>> I was referring to the first, 9b29050f, and the commitc4ff4b82 reverted by Ted fixes a bug for other users.
> What's the bug that other users suffer by having a longer timeout? It
> means that if things fails it takes longer for them to get an error
> message in the case of something that's going to fail anyway, right?
> Somehow that seems less serious than the TPM simply completely failing
> to function caused by too-short timeouts. (My situation). So sorry
> if I'm feeling selfish, but a longer timeout before returning failure
> seems less important than my not being able to access the TPM at all.
The bug was that when running the kernel with IMA, at boot time, it
issues 3 TPM commands IIRC, given the 2 min timeout,
when the TPM didn't respond due to it not working with interrupts for
example, the boot hang for 6 minutes. The TPM device
driver then relies on the default values, given neither
tpm_get_timeouts() can succeed. Unfortunately, yes, I don't have a
fix for TPMs not working with interrupts yet, however we've been making
progress there recently, should be out soon.
I understand, and I didn't mean one was more or less important than the
other, just gave the reason I wrote it at that time,
considering that I wasn't aware of the effect you're facing.
You're not being selfish from my POV also, both bugs need to be fixed.
> So, the results of my experiments. First of all, trying to merge in
> your for_james branch doesn't help at all. I used the tip of Linus's
> tree as of this morning (commit 3e1f2356ce2) and then merged in your
> for-james tree (commit b83452256e). No go. I tried setting the
> interrupts parameter to both 0 and 1, and either way, things still
> didn't work.
>
> OK, next, I tried Linus's idea, which was to put a WARN macro here in
> tpm_calc_ordinal_duration:
>
> if (duration_idx != TPM_UNDEFINED) {
> duration = chip->vendor.duration[duration_idx];
> /* if duration is 0, it's because chip->vendor.duration wasn't \
> */
> /* filled yet, so we set the lowest timeout just to give enough\
> */
> /* time for tpm_get_timeouts() to succeed */
> NEW ----> WARN(duration<=0,
> "no duration for ordinal %x (diration_idx %d)",
> ordinal, duration_idx);
> return (duration<= 0 ? HZ : duration);
> } else
> return 2 * 60 * HZ;
> }
>
> That resulted in the following data (see attached), which you will
> hopefully find useful.
Thanks, it is. HZ isn't enough time for this TPM/setup to have short
timeout commands to succeed, including
the tpm_get_timeouts(). I was skeptic at first that this would be the
reason since I have the same machine,
and was working for me, the reason I asked for these parameters setup
attempts. I'll write a patch that will
contemplate the long boot time timeout and this bugs fixed, pursuing the
interrupts fix path.
Rajiv
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists