DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:user-agent:mime-version:to:cc:subject
         :references:in-reply-to:x-enigmail-version:content-type
         :content-transfer-encoding;
        b=t6Y9PT3Vk5HomRS1ps6Oyk+bYNCu0URf1NDCH2ooWU4yosYGuJhPRUWkXKOGoMVPnx
         IxCQA2mmTlnWsgEErEombXEE7DR2UBNSQCs46TuU3vfm9Da4PqPbk8a33e8SMlHs7HhX
         6VwLUfaxIXU2DCpT3Rlws9MoV4RDOXFWjhy0k=
Message-ID: <4D62DCBA.9050609@gmail.com>
Date: Mon, 21 Feb 2011 22:44:26 +0100
From: Jiri Slaby <jirislaby@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; cs-CZ; rv:1.9.2.13) Gecko/20101206 SUSE/3.1.7 Thunderbird/3.1.7
MIME-Version: 1.0
To: Stefan Berger <stefanb@linux.vnet.ibm.com>
CC: Rajiv Andrade <srajiv@linux.vnet.ibm.com>,
        "Rafael J. Wysocki" <rjw@sisk.pl>,
        linux-pm <linux-pm@lists.linux-foundation.org>, stable@kernel.org,
        Linux kernel mailing list <linux-kernel@vger.kernel.org>,
        debora@linux.vnet.ibm.com,
        Linus Torvalds <torvalds@linux-foundation.org>, preining@logic.at
Subject: Re: 2.6.37.1 s2disk regression (TPM)
References: <4D60E93D.1050205@gmail.com> <4D60F108.9000106@gmail.com> <201102201151.11635.rjw@sisk.pl> <201102201248.10779.rjw@sisk.pl> <4D628521.8000205@linux.vnet.ibm.com> <4D629427.8020500@gmail.com> <4D629D03.90801@linux.vnet.ibm.com> <4D62CD93.3040206@gmail.com> <4D62D930.8060304@linux.vnet.ibm.com>
In-Reply-To: <4D62D930.8060304@linux.vnet.ibm.com>
Content-Type: text/plain; charset=ISO-8859-2
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1996
Lines: 52

On 02/21/2011 10:29 PM, Stefan Berger wrote:
> On 02/21/2011 03:39 PM, Jiri Slaby wrote:
>> On 02/21/2011 06:12 PM, Rajiv Andrade wrote:
>>> On 02/21/2011 01:34 PM, Jiri Slaby wrote:
>>>> There has to be another problem which caused my regression. And
>>>> since it
>>>> reports "Operation Timed out", the former default timeout values worked
>>>> for me, the ones read from TPM do not.
>>> Yes, it's highly due inconsistent timeout values reported by the TPM as
>>> I mentioned, my working timeouts are:
>>> 3020000 4510000 181000000
>> 1000000 2000 150000
>>
>> Actually the first one from HW is 1. This is one is HZ after correction
>> in get_timeout. So perhaps it is in ms, yes.
> 
> Following the specs, the timeouts are supposed to be in microseconds and
> ascending order for short, medium and long duration. Of course, if the
> device returns wrong timeouts, the command isn't going to succeed,
> failing the suspend in this case. Nevertheless, I think we need the
> patch I put in but at the same time we'll need a work-around for devices
> like this.

Yes, the patch is correct per se. But as it breaks bunch of machines it
cannot go in now. The rule is no regressions.

After you have the workaround it should go into the next rc1 after that.
Do you plan to add a dmi-based quirk? Or, IOW do you want me to attach
dmidecode output? Or are you going to base it solely on TPM
manufacturer/version?

> There was one person stating that this patch fixed are
> problem on his machine. 

Yes, I can see that. But we have to live with our mistakes.

> Can you find the 'caps' entry in /sys
> (/sys/devices/pnp0/00:06) and let us know its content?

TPM is at 00:0c:
Manufacturer: 0x49465800
TCG version: 1.2
Firmware version: 1.0

regards,
-- 
js
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/