Hi Paul,
> tpm tpm0: Unable to read burstcount
> tpm tpm0: tpm_transmit: tpm_send: error -16
> tpm_tis tpm_tis: Could not get TPM timeouts and durations
This looks like a regression I had on ThinkPad X61S.
You can try with a patch from the following commit
which fixed it for me:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d70fe9d9c3a4c627f9757cbba5d628687b121c1
It is included in mainline kernel 4.10.2.
Maciej
On Wed, Apr 05, 2017 at 01:03:42PM +0200, Maciej S. Szmigiero wrote:
> Hi Paul,
>
> > tpm tpm0: Unable to read burstcount
> > tpm tpm0: tpm_transmit: tpm_send: error -16
> > tpm_tis tpm_tis: Could not get TPM timeouts and durations
>
> This looks like a regression I had on ThinkPad X61S.
>
> You can try with a patch from the following commit
> which fixed it for me:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d70fe9d9c3a4c627f9757cbba5d628687b121c1
>
> It is included in mainline kernel 4.10.2.
>
> Maciej
Paul, Maciej, thank you. Please keep us updated.
/Jarkko
Dear Maciej,
On 2017-04-05 13:03, Maciej S. Szmigiero wrote:
>> tpm tpm0: Unable to read burstcount
>> tpm tpm0: tpm_transmit: tpm_send: error -16
>> tpm_tis tpm_tis: Could not get TPM timeouts and durations
>
> This looks like a regression I had on ThinkPad X61S.
>
> You can try with a patch from the following commit
> which fixed it for me:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d70fe9d9c3a4c627f9757cbba5d628687b121c1
>
> It is included in mainline kernel 4.10.2.
Indeed, that improves the situation. I still need to pass `force=1` to
the module to get `/dev/tpm0`. No idea, why it’s not in included in
Linux 4.9 yet.
```
$ more /proc/version
Linux version 4.11.0-rc5+ (root@d44d03a193d6) (gcc version 6.3.0
20170321 (Debian 6.3.0-10) ) #2 SMP Tue Apr 4 21:07:08 UTC 2017
$ journalctl -k -o cat | grep tpm
tpm_tis tpm_tis: 1.2 TPM (device-id 0x3202, rev-id 5)
tpm tpm0: Issuing TPM_STARTUP
tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A
10000->10000us B 10000->10000us C 0->752000us D 0->752000us
$ more /sys/class/tpm/tpm0/device/caps
Manufacturer: 0x41544d4c
TCG version: 1.2
Firmware version: 11.5
$ sudo tpm_version
Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17),
Communication failure
```
So do you have an idea, what “ACPI requirements” changed in the `tpm`
module since Linux 3.16 to be loaded automatically?
Kind regards,
Paul
On 04/06/17 08:18, Paul Menzel wrote:
> Dear Maciej,
>
> On 2017-04-05 13:03, Maciej S. Szmigiero wrote:
>
>>> tpm tpm0: Unable to read burstcount
>>> tpm tpm0: tpm_transmit: tpm_send: error -16
>>> tpm_tis tpm_tis: Could not get TPM timeouts and durations
>>
>> This looks like a regression I had on ThinkPad X61S.
>>
>> You can try with a patch from the following commit
>> which fixed it for me:
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=1d70fe9d9c3a4c627f9757cbba5d628687b121c1
>>
>> It is included in mainline kernel 4.10.2.
>
> Indeed, that improves the situation. I still need to pass `force=1` to the module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9 yet.
>
> ```
> $ more /proc/version
> Linux version 4.11.0-rc5+ (root@d44d03a193d6) (gcc version 6.3.0 20170321 (Debian 6.3.0-10) ) #2 SMP Tue Apr 4 21:07:08 UTC 2017
> $ journalctl -k -o cat | grep tpm
> tpm_tis tpm_tis: 1.2 TPM (device-id 0x3202, rev-id 5)
> tpm tpm0: Issuing TPM_STARTUP
> tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A 10000->10000us B 10000->10000us C 0->752000us D 0->752000us
> $ more /sys/class/tpm/tpm0/device/caps
> Manufacturer: 0x41544d4c
> TCG version: 1.2
> Firmware version: 11.5
> $ sudo tpm_version
> Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17), Communication failure
> ```
>
> So do you have an idea, what “ACPI requirements” changed in the `tpm` module since Linux 3.16 to be loaded automatically?
Unfortunately I can't help here as I am just a normal TPM user who
happened to hit and fix that timeouts regression, but maybe others
on ML will know something more about it.
> Kind regards,
>
> Paul
Best regards,
Maciej
On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
> Indeed, that improves the situation. I still need to pass `force=1` to the
> module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9
> yet.
Fair point.. Jarkko - could you forward that patch to -stable?
> $ journalctl -k -o cat | grep tpm
> tpm_tis tpm_tis: 1.2 TPM (device-id 0x3202, rev-id 5)
> tpm tpm0: Issuing TPM_STARTUP
> tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A 10000->10000us B
> 10000->10000us C 0->752000us D 0->752000us
There could be more relavent kernel messages than this, try
grep -i tpm
?
> So do you have an idea, what “ACPI requirements” changed in the `tpm` module
> since Linux 3.16 to be loaded automatically?
We added direct ACPI binding to the driver in addition to PNP, so if
you have an ACPI table it goes down that path and does some additional
validation of what is in the TPM. The BIOS must provide a
acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
minimum.
There are FW_BUG prints if those fail, so check your dmesg closely?
http://lxr.free-electrons.com/source/drivers/char/tpm/tpm_tis.c#L250
If not, can you annotate in some printk's into tpm_tis_acpi_init and
recompile/re-test?
Jason
On 2017-04-06 18:55, Jason Gunthorpe wrote:
> On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
>
>> Indeed, that improves the situation. I still need to pass `force=1` to
>> the
>> module to get `/dev/tpm0`. No idea, why it’s not in included in Linux
>> 4.9
>> yet.
>
> Fair point.. Jarkko - could you forward that patch to -stable?
>
>> $ journalctl -k -o cat | grep tpm
>> tpm_tis tpm_tis: 1.2 TPM (device-id 0x3202, rev-id 5)
>> tpm tpm0: Issuing TPM_STARTUP
>> tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A
>> 10000->10000us B
>> 10000->10000us C 0->752000us D 0->752000us
>
> There could be more relavent kernel messages than this, try
> grep -i tpm
>
> ?
At least I don’t spot more messages.
```
$ journalctl -b -3 -o cat | grep -i -e "Linux version" -e tpm
Linux version 4.11.0-rc5+ (root@d44d03a193d6) (gcc version 6.3.0
20170321 (Debian 6.3.0-10) ) #2 SMP Tue Apr 4 21:07:08 UTC 2017
joey : TTY=pts/6 ; PWD=/home/joey ; USER=root ; COMMAND=/usr/bin/apt
install tpm-tools
new user: name=tss, UID=123, GID=137, home=/var/lib/tpm,
shell=/bin/false
joey : TTY=pts/6 ; PWD=/home/joey ; USER=root ; COMMAND=/sbin/modprobe
-r tpm_tis tpm
joey : TTY=pts/6 ; PWD=/home/joey ; USER=root ; COMMAND=/sbin/modprobe
tpm_tis force=1
tpm_tis tpm_tis: 1.2 TPM (device-id 0x3202, rev-id 5)
tpm tpm0: Issuing TPM_STARTUP
tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A
10000->10000us B 10000->10000us C 0->752000us D 0->752000us
```
>> So do you have an idea, what “ACPI requirements” changed in the `tpm`
>> module
>> since Linux 3.16 to be loaded automatically?
>
> We added direct ACPI binding to the driver in addition to PNP, so if
> you have an ACPI table it goes down that path and does some additional
> validation of what is in the TPM. The BIOS must provide a
> acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
> minimum.
Is it correct, that this is added in/for 4.11, so just recently? Testing
with Linux 4.10.8, everything is detected just fine.
```
$ journalctl -k -o cat | grep -i tpm
tpm_tis 00:08: 1.2 TPM (device-id 0x3202, rev-id 5)
tpm tpm0: A TPM error (38) occurred attempting to determine the timeouts
tpm tpm0: Issuing TPM_STARTUP
tpm tpm0: [Hardware Error]: Adjusting reported timeouts: A
10000->10000us B 10000->10000us C 0->752000us D 0->752000us
```
> There are FW_BUG prints if those fail, so check your dmesg closely?
>
> http://lxr.free-electrons.com/source/drivers/char/tpm/tpm_tis.c#L250
>
> If not, can you annotate in some printk's into tpm_tis_acpi_init and
> recompile/re-test?
If nothing comes to mind with the new information above, then I could do
that. But I don’t know, if I’ll have time in the next two weeks for
that.
Kind regards,
Paul
On Thu, Apr 06, 2017 at 10:55:57AM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 06, 2017 at 08:18:33AM +0200, Paul Menzel wrote:
>
> > Indeed, that improves the situation. I still need to pass `force=1` to the
> > module to get `/dev/tpm0`. No idea, why it’s not in included in Linux 4.9
> > yet.
>
> Fair point.. Jarkko - could you forward that patch to -stable?
Yes.
/Jarkko
On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> >We added direct ACPI binding to the driver in addition to PNP, so if
> >you have an ACPI table it goes down that path and does some additional
> >validation of what is in the TPM. The BIOS must provide a
> >acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
> >minimum.
>
> Is it correct, that this is added in/for 4.11, so just recently? Testing
> with Linux 4.10.8, everything is detected just fine.
No, it is quite a bit older.. And it should only go for TPM2, which I
don't think you have??
Maybe Jarkko has a guess, but sure sounds like something is recently
broken in 4.11
Jason
On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> > >We added direct ACPI binding to the driver in addition to PNP, so if
> > >you have an ACPI table it goes down that path and does some additional
> > >validation of what is in the TPM. The BIOS must provide a
> > >acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
> > >minimum.
> >
> > Is it correct, that this is added in/for 4.11, so just recently? Testing
> > with Linux 4.10.8, everything is detected just fine.
>
> No, it is quite a bit older.. And it should only go for TPM2, which I
> don't think you have??
>
> Maybe Jarkko has a guess, but sure sounds like something is recently
> broken in 4.11
>
> Jason
I'll come back to this. I have to re-read the whole mail thread to
get back into the context. Lots of multitasking because of release
and so forth. Sorry for the latency!
/Jarkko
Dear Jarkko,
On 2017-04-07 22:13, Jarkko Sakkinen wrote:
> On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
>> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
>> > >We added direct ACPI binding to the driver in addition to PNP, so if
>> > >you have an ACPI table it goes down that path and does some additional
>> > >validation of what is in the TPM. The BIOS must provide a
>> > >acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
>> > >minimum.
>> >
>> > Is it correct, that this is added in/for 4.11, so just recently? Testing
>> > with Linux 4.10.8, everything is detected just fine.
>>
>> No, it is quite a bit older.. And it should only go for TPM2, which I
>> don't think you have??
>>
>> Maybe Jarkko has a guess, but sure sounds like something is recently
>> broken in 4.11
>>
>> Jason
>
> I'll come back to this. I have to re-read the whole mail thread to
> get back into the context. Lots of multitasking because of release
> and so forth. Sorry for the latency!
I started bisecting this issue. This is the current state.
```
# git bisect log
# bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag
'dm-4.11-changes' of
git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
# good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10
git bisect start 'HEAD' 'v4.10'
# good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag
'regmap-v4.11' of
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d
```
Kind regards,
Paul
Hi Paul,
On Thu, 6 Apr 2017 10:55:57 -0600
Jason Gunthorpe <[email protected]> wrote:
> We added direct ACPI binding to the driver in addition to PNP, so if
> you have an ACPI table it goes down that path and does some additional
> validation of what is in the TPM. The BIOS must provide a
> acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
> minimum.
I am working on it[1]. This commit has not been merged and is a work in
progress. It is however available in coreboot's gerrit.
So far with it and a recent kernel and the patch mentioned above:
- The linux driver finds the TPM automatically and doesn't require
force=1
- The driver however still require itpm=1 to fully work: without it the
tpm is found, but I wasn't able to read the PCRs.
Since I use a rolling release distribution, the kenrel version I use
tend to change quite fast, I can re-test if needed.
I need to improve the following in my patch:
- The IDs readings obviously need to be fixed.
- I want to make it work without itpm=1 if possible. I'll test with
INTC0102 as it is in the driver in the is_itpm function, and it was
also suggested to me by someone on IRC.
I also still need to investigate more why the itpm workaround is needed.
Does the TPM shipped in such laptops respect the specifications?
Is the wiring bad?
References:
-----------
[1]https://review.coreboot.org/cgit/coreboot.git/commit/?id=060cf4e0f50f765f85e3ecedd836eed85d1571fe
Denis.
On Sat, Apr 08, 2017 at 12:40:25PM +0200, Denis 'GNUtoo' Carikli wrote:
> I am working on it[1]. This commit has not been merged and is a work in
> progress. It is however available in coreboot's gerrit.
How did this work on any kernels if there was no PNP or ACPI entry?
FWIW, I wonder if coreboot is missing the code for wait_startup
in drivers/char/tpm/tpm_tis_core.c. If you don't do that step then
the DID/VID might not read properly.
> So far with it and a recent kernel and the patch mentioned above:
> - The linux driver finds the TPM automatically and doesn't require
> force=1
> - The driver however still require itpm=1 to fully work: without it the
> tpm is found, but I wasn't able to read the PCRs.
Unless it is an actual broken intel TPM you should never use
itpm=1. Juding by the log messages, it certainly is not.
Intel mode breaks the driver and removes certain error detection, eg
it may erronously succeed.
It is more likely that the failure to read PCRs reflects reality and
itpm=1 just supresses that error detection.
The TPM may need to be setup (eg cleared, EK generated, p/vflags setup
etc, etc) before it will support PCRs.
Usually the BIOS would do these steps when the TPM is first enabled,
you probably need to do them in userspace instead.
WARNING: Failure to provision the TPM properly before first use
could leave it in 'factory test' mode, which basically means it
doesn't work properly at all.
> - I want to make it work without itpm=1 if possible. I'll test with
> INTC0102 as it is in the driver in the is_itpm function, and it was
> also suggested to me by someone on IRC.
Don't do this unless it is actually that TPM.
Jason
Dear Linux folks,
It turns out that stricter checks in the ACPI subsystem, introduced in
commit 57707a9a77 (ACPICA: Resources: Not a valid resource if buffer
length too long) [1], cause the TPM module not to be loaded anymore on
the Lenovo X60 with coreboot [2].
Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel:
> On 2017-04-07 22:13, Jarkko Sakkinen wrote:
> > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> >> > >We added direct ACPI binding to the driver in addition to PNP, so if
> >> > >you have an ACPI table it goes down that path and does some additional
> >> > >validation of what is in the TPM. The BIOS must provide a
> >> > >acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
> >> > >minimum.
> >> >
> >> > Is it correct, that this is added in/for 4.11, so just recently? Testing
> >> > with Linux 4.10.8, everything is detected just fine.
> >>
> >> No, it is quite a bit older.. And it should only go for TPM2, which I
> >> don't think you have??
> >>
> >> Maybe Jarkko has a guess, but sure sounds like something is recently
> >> broken in 4.11
> >
> > I'll come back to this. I have to re-read the whole mail thread to
> > get back into the context. Lots of multitasking because of release
> > and so forth. Sorry for the latency!
>
> I started bisecting this issue. This is the current state.
[…]
Here are the results.
```
git bisect log
# bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag 'dm-4.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
# good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10
git bisect start 'HEAD' 'v4.10'
# good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag 'regmap-v4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d
# bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix build paravirt build on arm and arm64
git bisect bad fd4a61e08aa79f2b7835b25c6f94f27bd2d65990
# good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag 'leds_for_4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
git bisect good 7aa7d608112baf63a0b1278955f9619427373807
# good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag 'pm-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
git bisect good 02c3de1105228e367320e7fdeffbf511904f398c
# bad: [6c24337f22115d669e24ce990842dab667371b4d] Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt
git bisect bad 6c24337f22115d669e24ce990842dab667371b4d
# bad: [a74d1cafc22e100a9b59c50943ca09c37e03dce8] Merge branches 'acpi-bus', 'acpi-sleep' and 'acpi-processor'
git bisect bad a74d1cafc22e100a9b59c50943ca09c37e03dce8
# bad: [ce87e09dd88c61f9088768a7708828423549725c] ACPICA: Parser: Allow method invocations as target operands
git bisect bad ce87e09dd88c61f9088768a7708828423549725c
# good: [0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076] ACPICA: Hardware: Add sleep register hooks
git bisect good 0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076
# good: [a654b8ca6d28736995de767ba62e801fd806a3b2] ACPICA: Disassembler: Add Switch/Case disassembly support
git bisect good a654b8ca6d28736995de767ba62e801fd806a3b2
# bad: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA: Resources: Not a valid resource if buffer length too long
git bisect bad 57707a9a7780fab426b8ae9b4c7b65b912a748b3
# good: [7225d0467c59e55566df396d6ecd5baf26ef3d9b] ACPICA: Utilities: Update debug output
git bisect good 7225d0467c59e55566df396d6ecd5baf26ef3d9b
# first bad commit: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA: Resources: Not a valid resource if buffer length too long
```
I suggest, that just a warning is printed in this case, or that an
option is added to enable some kind of “strict mode” or a quirk table.
Please find the decompiled DSDT attached. The code to generate the ASL
coreboot code is available [3].
Please tell me, what information you need.
Kind regards,
Paul
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57707a9a778
[2] https://review.coreboot.org/13410/
[3] https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/pc80/tpm/tpm.c
On Sun, Apr 09, 2017 at 07:34:43PM +0200, Paul Menzel wrote:
> Dear Linux folks,
>
>
> It turns out that stricter checks in the ACPI subsystem, introduced in
> commit 57707a9a77 (ACPICA: Resources: Not a valid resource if buffer
> length too long) [1], cause the TPM module not to be loaded anymore on
> the Lenovo X60 with coreboot [2].
>
> Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel:
> > On 2017-04-07 22:13, Jarkko Sakkinen wrote:
> > > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> > >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> > >> > >We added direct ACPI binding to the driver in addition to PNP, so if
> > >> > >you have an ACPI table it goes down that path and does some additional
> > >> > >validation of what is in the TPM. The BIOS must provide a
> > >> > >acpi_dev_resource_memory and a ACPI_SIG_TPM2 for the ACPI entry at a
> > >> > >minimum.
> > >> >
> > >> > Is it correct, that this is added in/for 4.11, so just recently? Testing
> > >> > with Linux 4.10.8, everything is detected just fine.
> > >>
> > >> No, it is quite a bit older.. And it should only go for TPM2, which I
> > >> don't think you have??
> > >>
> > >> Maybe Jarkko has a guess, but sure sounds like something is recently
> > >> broken in 4.11
> > >
> > > I'll come back to this. I have to re-read the whole mail thread to
> > > get back into the context. Lots of multitasking because of release
> > > and so forth. Sorry for the latency!
> >
> > I started bisecting this issue. This is the current state.
>
> […]
>
> Here are the results.
>
> ```
> git bisect log
> # bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag 'dm-4.11-changes' of git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> # good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10
> git bisect start 'HEAD' 'v4.10'
> # good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag 'regmap-v4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d
> # bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix build paravirt build on arm and arm64
> git bisect bad fd4a61e08aa79f2b7835b25c6f94f27bd2d65990
> # good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag 'leds_for_4.11' of git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
> git bisect good 7aa7d608112baf63a0b1278955f9619427373807
> # good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag 'pm-4.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> git bisect good 02c3de1105228e367320e7fdeffbf511904f398c
> # bad: [6c24337f22115d669e24ce990842dab667371b4d] Merge tag 'fscrypt-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt
> git bisect bad 6c24337f22115d669e24ce990842dab667371b4d
> # bad: [a74d1cafc22e100a9b59c50943ca09c37e03dce8] Merge branches 'acpi-bus', 'acpi-sleep' and 'acpi-processor'
> git bisect bad a74d1cafc22e100a9b59c50943ca09c37e03dce8
> # bad: [ce87e09dd88c61f9088768a7708828423549725c] ACPICA: Parser: Allow method invocations as target operands
> git bisect bad ce87e09dd88c61f9088768a7708828423549725c
> # good: [0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076] ACPICA: Hardware: Add sleep register hooks
> git bisect good 0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076
> # good: [a654b8ca6d28736995de767ba62e801fd806a3b2] ACPICA: Disassembler: Add Switch/Case disassembly support
> git bisect good a654b8ca6d28736995de767ba62e801fd806a3b2
> # bad: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA: Resources: Not a valid resource if buffer length too long
> git bisect bad 57707a9a7780fab426b8ae9b4c7b65b912a748b3
> # good: [7225d0467c59e55566df396d6ecd5baf26ef3d9b] ACPICA: Utilities: Update debug output
> git bisect good 7225d0467c59e55566df396d6ecd5baf26ef3d9b
> # first bad commit: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA: Resources: Not a valid resource if buffer length too long
> ```
>
> I suggest, that just a warning is printed in this case, or that an
> option is added to enable some kind of “strict mode” or a quirk table.
>
> Please find the decompiled DSDT attached. The code to generate the ASL
> coreboot code is available [3].
>
> Please tell me, what information you need.
>
>
> Kind regards,
>
> Paul
>
>
> [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=57707a9a778
> [2] https://review.coreboot.org/13410/
> [3] https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/pc80/tpm/tpm.c
Hi,
Thank you for bisecting the issue. It would have been hard to achieve this
without the hardware. Do you want to create a patch for ACPICA?
/Jarkko
I'll try to look at it today
Bob
> -----Original Message-----
> From: Jarkko Sakkinen [mailto:[email protected]]
> Sent: Tuesday, April 11, 2017 3:58 PM
> To: Paul Menzel <[email protected]>
> Cc: Moore, Robert <[email protected]>; Maciej S. Szmigiero
> <[email protected]>; [email protected]; Arthur
> Heymans <[email protected]>; [email protected];
> [email protected]; Zheng, Lv <[email protected]>; Wysocki, Rafael J
> <[email protected]>
> Subject: Re: [Regression Linux 4.11] TPM module not loaded anymore (was:
> Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)
>
> On Sun, Apr 09, 2017 at 07:34:43PM +0200, Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > It turns out that stricter checks in the ACPI subsystem, introduced in
> > commit 57707a9a77 (ACPICA: Resources: Not a valid resource if buffer
> > length too long) [1], cause the TPM module not to be loaded anymore on
> > the Lenovo X60 with coreboot [2].
> >
> > Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel:
> > > On 2017-04-07 22:13, Jarkko Sakkinen wrote:
> > > > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> > > >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> > > >> > >We added direct ACPI binding to the driver in addition to PNP,
> > > >> > >so if you have an ACPI table it goes down that path and does
> > > >> > >some additional validation of what is in the TPM. The BIOS
> > > >> > >must provide a acpi_dev_resource_memory and a ACPI_SIG_TPM2
> > > >> > >for the ACPI entry at a minimum.
> > > >> >
> > > >> > Is it correct, that this is added in/for 4.11, so just
> > > >> > recently? Testing with Linux 4.10.8, everything is detected
> just fine.
> > > >>
> > > >> No, it is quite a bit older.. And it should only go for TPM2,
> > > >> which I don't think you have??
> > > >>
> > > >> Maybe Jarkko has a guess, but sure sounds like something is
> > > >> recently broken in 4.11
> > > >
> > > > I'll come back to this. I have to re-read the whole mail thread to
> > > > get back into the context. Lots of multitasking because of release
> > > > and so forth. Sorry for the latency!
> > >
> > > I started bisecting this issue. This is the current state.
> >
> > […]
> >
> > Here are the results.
> >
> > ```
> > git bisect log
> > # bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag
> > 'dm-4.11-changes' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> > # good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10 git
> > bisect start 'HEAD' 'v4.10'
> > # good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag
> > 'regmap-v4.11' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d
> > # bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix
> > build paravirt build on arm and arm64 git bisect bad
> > fd4a61e08aa79f2b7835b25c6f94f27bd2d65990
> > # good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag
> > 'leds_for_4.11' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
> > git bisect good 7aa7d608112baf63a0b1278955f9619427373807
> > # good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag
> > 'pm-4.11-rc1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> > git bisect good 02c3de1105228e367320e7fdeffbf511904f398c
> > # bad: [6c24337f22115d669e24ce990842dab667371b4d] Merge tag
> > 'fscrypt-for-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt
> > git bisect bad 6c24337f22115d669e24ce990842dab667371b4d
> > # bad: [a74d1cafc22e100a9b59c50943ca09c37e03dce8] Merge branches
> 'acpi-bus', 'acpi-sleep' and 'acpi-processor'
> > git bisect bad a74d1cafc22e100a9b59c50943ca09c37e03dce8
> > # bad: [ce87e09dd88c61f9088768a7708828423549725c] ACPICA: Parser:
> > Allow method invocations as target operands git bisect bad
> > ce87e09dd88c61f9088768a7708828423549725c
> > # good: [0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076] ACPICA: Hardware:
> > Add sleep register hooks git bisect good
> > 0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076
> > # good: [a654b8ca6d28736995de767ba62e801fd806a3b2] ACPICA:
> > Disassembler: Add Switch/Case disassembly support git bisect good
> > a654b8ca6d28736995de767ba62e801fd806a3b2
> > # bad: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA: Resources:
> > Not a valid resource if buffer length too long git bisect bad
> > 57707a9a7780fab426b8ae9b4c7b65b912a748b3
> > # good: [7225d0467c59e55566df396d6ecd5baf26ef3d9b] ACPICA: Utilities:
> > Update debug output git bisect good
> > 7225d0467c59e55566df396d6ecd5baf26ef3d9b
> > # first bad commit: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA:
> > Resources: Not a valid resource if buffer length too long ```
> >
> > I suggest, that just a warning is printed in this case, or that an
> > option is added to enable some kind of “strict mode” or a quirk table.
> >
> > Please find the decompiled DSDT attached. The code to generate the ASL
> > coreboot code is available [3].
> >
> > Please tell me, what information you need.
> >
> >
> > Kind regards,
> >
> > Paul
> >
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
> > mit/?id=57707a9a778 [2] https://review.coreboot.org/13410/
> > [3]
> > https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/pc80/tp
> > m/tpm.c
>
> Hi,
>
> Thank you for bisecting the issue. It would have been hard to achieve
> this without the hardware. Do you want to create a patch for ACPICA?
>
> /Jarkko
Please post the acpidump for this machine so we can analyze the actual AML byte code.
Thanks.
> -----Original Message-----
> From: Jarkko Sakkinen [mailto:[email protected]]
> Sent: Tuesday, April 11, 2017 3:58 PM
> To: Paul Menzel <[email protected]>
> Cc: Moore, Robert <[email protected]>; Maciej S. Szmigiero
> <[email protected]>; [email protected]; Arthur
> Heymans <[email protected]>; [email protected];
> [email protected]; Zheng, Lv <[email protected]>; Wysocki, Rafael J
> <[email protected]>
> Subject: Re: [Regression Linux 4.11] TPM module not loaded anymore (was:
> Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)
>
> On Sun, Apr 09, 2017 at 07:34:43PM +0200, Paul Menzel wrote:
> > Dear Linux folks,
> >
> >
> > It turns out that stricter checks in the ACPI subsystem, introduced in
> > commit 57707a9a77 (ACPICA: Resources: Not a valid resource if buffer
> > length too long) [1], cause the TPM module not to be loaded anymore on
> > the Lenovo X60 with coreboot [2].
> >
> > Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel:
> > > On 2017-04-07 22:13, Jarkko Sakkinen wrote:
> > > > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> > > >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> > > >> > >We added direct ACPI binding to the driver in addition to PNP,
> > > >> > >so if you have an ACPI table it goes down that path and does
> > > >> > >some additional validation of what is in the TPM. The BIOS
> > > >> > >must provide a acpi_dev_resource_memory and a ACPI_SIG_TPM2
> > > >> > >for the ACPI entry at a minimum.
> > > >> >
> > > >> > Is it correct, that this is added in/for 4.11, so just
> > > >> > recently? Testing with Linux 4.10.8, everything is detected
> just fine.
> > > >>
> > > >> No, it is quite a bit older.. And it should only go for TPM2,
> > > >> which I don't think you have??
> > > >>
> > > >> Maybe Jarkko has a guess, but sure sounds like something is
> > > >> recently broken in 4.11
> > > >
> > > > I'll come back to this. I have to re-read the whole mail thread to
> > > > get back into the context. Lots of multitasking because of release
> > > > and so forth. Sorry for the latency!
> > >
> > > I started bisecting this issue. This is the current state.
> >
> > […]
> >
> > Here are the results.
> >
> > ```
> > git bisect log
> > # bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag
> > 'dm-4.11-changes' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> > # good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10 git
> > bisect start 'HEAD' 'v4.10'
> > # good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag
> > 'regmap-v4.11' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d
> > # bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix
> > build paravirt build on arm and arm64 git bisect bad
> > fd4a61e08aa79f2b7835b25c6f94f27bd2d65990
> > # good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag
> > 'leds_for_4.11' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-leds
> > git bisect good 7aa7d608112baf63a0b1278955f9619427373807
> > # good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag
> > 'pm-4.11-rc1' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> > git bisect good 02c3de1105228e367320e7fdeffbf511904f398c
> > # bad: [6c24337f22115d669e24ce990842dab667371b4d] Merge tag
> > 'fscrypt-for-linus' of
> > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt
> > git bisect bad 6c24337f22115d669e24ce990842dab667371b4d
> > # bad: [a74d1cafc22e100a9b59c50943ca09c37e03dce8] Merge branches
> 'acpi-bus', 'acpi-sleep' and 'acpi-processor'
> > git bisect bad a74d1cafc22e100a9b59c50943ca09c37e03dce8
> > # bad: [ce87e09dd88c61f9088768a7708828423549725c] ACPICA: Parser:
> > Allow method invocations as target operands git bisect bad
> > ce87e09dd88c61f9088768a7708828423549725c
> > # good: [0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076] ACPICA: Hardware:
> > Add sleep register hooks git bisect good
> > 0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076
> > # good: [a654b8ca6d28736995de767ba62e801fd806a3b2] ACPICA:
> > Disassembler: Add Switch/Case disassembly support git bisect good
> > a654b8ca6d28736995de767ba62e801fd806a3b2
> > # bad: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA: Resources:
> > Not a valid resource if buffer length too long git bisect bad
> > 57707a9a7780fab426b8ae9b4c7b65b912a748b3
> > # good: [7225d0467c59e55566df396d6ecd5baf26ef3d9b] ACPICA: Utilities:
> > Update debug output git bisect good
> > 7225d0467c59e55566df396d6ecd5baf26ef3d9b
> > # first bad commit: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA:
> > Resources: Not a valid resource if buffer length too long ```
> >
> > I suggest, that just a warning is printed in this case, or that an
> > option is added to enable some kind of “strict mode” or a quirk table.
> >
> > Please find the decompiled DSDT attached. The code to generate the ASL
> > coreboot code is available [3].
> >
> > Please tell me, what information you need.
> >
> >
> > Kind regards,
> >
> > Paul
> >
> >
> > [1]
> > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/com
> > mit/?id=57707a9a778 [2] https://review.coreboot.org/13410/
> > [3]
> > https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/pc80/tp
> > m/tpm.c
>
> Hi,
>
> Thank you for bisecting the issue. It would have been hard to achieve
> this without the hardware. Do you want to create a patch for ACPICA?
>
> /Jarkko
And probably the dmesg if error messages appear in there.
> -----Original Message-----
> From: Moore, Robert
> Sent: Wednesday, April 12, 2017 8:53 AM
> To: 'Jarkko Sakkinen' <[email protected]>; Paul Menzel
> <[email protected]>
> Cc: Maciej S. Szmigiero <[email protected]>; linux-
> [email protected]; Arthur Heymans <[email protected]>; tpmdd-
> [email protected]; [email protected]; Zheng, Lv
> <[email protected]>; Wysocki, Rafael J <[email protected]>
> Subject: RE: [Regression Linux 4.11] TPM module not loaded anymore (was:
> Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)
>
> Please post the acpidump for this machine so we can analyze the actual
> AML byte code.
> Thanks.
>
>
> > -----Original Message-----
> > From: Jarkko Sakkinen [mailto:[email protected]]
> > Sent: Tuesday, April 11, 2017 3:58 PM
> > To: Paul Menzel <[email protected]>
> > Cc: Moore, Robert <[email protected]>; Maciej S. Szmigiero
> > <[email protected]>; [email protected]; Arthur
> > Heymans <[email protected]>; [email protected];
> > [email protected]; Zheng, Lv <[email protected]>; Wysocki, Rafael J
> > <[email protected]>
> > Subject: Re: [Regression Linux 4.11] TPM module not loaded anymore
> (was:
> > Regression between Linux 3.16 and 4.8/4.9 on Lenovo X60 with coreboot)
> >
> > On Sun, Apr 09, 2017 at 07:34:43PM +0200, Paul Menzel wrote:
> > > Dear Linux folks,
> > >
> > >
> > > It turns out that stricter checks in the ACPI subsystem, introduced
> > > in commit 57707a9a77 (ACPICA: Resources: Not a valid resource if
> > > buffer length too long) [1], cause the TPM module not to be loaded
> > > anymore on the Lenovo X60 with coreboot [2].
> > >
> > > Am Freitag, den 07.04.2017, 22:58 +0200 schrieb Paul Menzel:
> > > > On 2017-04-07 22:13, Jarkko Sakkinen wrote:
> > > > > On Thu, Apr 06, 2017 at 01:10:13PM -0600, Jason Gunthorpe wrote:
> > > > >> On Thu, Apr 06, 2017 at 08:26:22PM +0200, Paul Menzel wrote:
> > > > >> > >We added direct ACPI binding to the driver in addition to
> > > > >> > >PNP, so if you have an ACPI table it goes down that path and
> > > > >> > >does some additional validation of what is in the TPM. The
> > > > >> > >BIOS must provide a acpi_dev_resource_memory and a
> > > > >> > >ACPI_SIG_TPM2 for the ACPI entry at a minimum.
> > > > >> >
> > > > >> > Is it correct, that this is added in/for 4.11, so just
> > > > >> > recently? Testing with Linux 4.10.8, everything is detected
> > just fine.
> > > > >>
> > > > >> No, it is quite a bit older.. And it should only go for TPM2,
> > > > >> which I don't think you have??
> > > > >>
> > > > >> Maybe Jarkko has a guess, but sure sounds like something is
> > > > >> recently broken in 4.11
> > > > >
> > > > > I'll come back to this. I have to re-read the whole mail thread
> > > > > to get back into the context. Lots of multitasking because of
> > > > > release and so forth. Sorry for the latency!
> > > >
> > > > I started bisecting this issue. This is the current state.
> > >
> > > […]
> > >
> > > Here are the results.
> > >
> > > ```
> > > git bisect log
> > > # bad: [7a771ceac771d009f7203c40b256b0608d7ea2f8] Merge tag
> > > 'dm-4.11-changes' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/device-mapper/linux-dm
> > > # good: [c470abd4fde40ea6a0846a2beab642a578c0b8cd] Linux 4.10 git
> > > bisect start 'HEAD' 'v4.10'
> > > # good: [b3de5ad688f0f52457e73767f95a640ab4158d0d] Merge tag
> > > 'regmap-v4.11' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
> > > git bisect good b3de5ad688f0f52457e73767f95a640ab4158d0d
> > > # bad: [fd4a61e08aa79f2b7835b25c6f94f27bd2d65990] sched/core: Fix
> > > build paravirt build on arm and arm64 git bisect bad
> > > fd4a61e08aa79f2b7835b25c6f94f27bd2d65990
> > > # good: [7aa7d608112baf63a0b1278955f9619427373807] Merge tag
> > > 'leds_for_4.11' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/j.anaszewski/linux-led
> > > s git bisect good 7aa7d608112baf63a0b1278955f9619427373807
> > > # good: [02c3de1105228e367320e7fdeffbf511904f398c] Merge tag
> > > 'pm-4.11-rc1' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
> > > git bisect good 02c3de1105228e367320e7fdeffbf511904f398c
> > > # bad: [6c24337f22115d669e24ce990842dab667371b4d] Merge tag
> > > 'fscrypt-for-linus' of
> > > git://git.kernel.org/pub/scm/linux/kernel/git/tytso/fscrypt
> > > git bisect bad 6c24337f22115d669e24ce990842dab667371b4d
> > > # bad: [a74d1cafc22e100a9b59c50943ca09c37e03dce8] Merge branches
> > 'acpi-bus', 'acpi-sleep' and 'acpi-processor'
> > > git bisect bad a74d1cafc22e100a9b59c50943ca09c37e03dce8
> > > # bad: [ce87e09dd88c61f9088768a7708828423549725c] ACPICA: Parser:
> > > Allow method invocations as target operands git bisect bad
> > > ce87e09dd88c61f9088768a7708828423549725c
> > > # good: [0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076] ACPICA: Hardware:
> > > Add sleep register hooks git bisect good
> > > 0fc5e8f4e4b33ddfa1d1d673fcd420d6e13eb076
> > > # good: [a654b8ca6d28736995de767ba62e801fd806a3b2] ACPICA:
> > > Disassembler: Add Switch/Case disassembly support git bisect good
> > > a654b8ca6d28736995de767ba62e801fd806a3b2
> > > # bad: [57707a9a7780fab426b8ae9b4c7b65b912a748b3] ACPICA: Resources:
> > > Not a valid resource if buffer length too long git bisect bad
> > > 57707a9a7780fab426b8ae9b4c7b65b912a748b3
> > > # good: [7225d0467c59e55566df396d6ecd5baf26ef3d9b] ACPICA:
> Utilities:
> > > Update debug output git bisect good
> > > 7225d0467c59e55566df396d6ecd5baf26ef3d9b
> > > # first bad commit: [57707a9a7780fab426b8ae9b4c7b65b912a748b3]
> ACPICA:
> > > Resources: Not a valid resource if buffer length too long ```
> > >
> > > I suggest, that just a warning is printed in this case, or that an
> > > option is added to enable some kind of “strict mode” or a quirk
> table.
> > >
> > > Please find the decompiled DSDT attached. The code to generate the
> > > ASL coreboot code is available [3].
> > >
> > > Please tell me, what information you need.
> > >
> > >
> > > Kind regards,
> > >
> > > Paul
> > >
> > >
> > > [1]
> > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/c
> > > om
> > > mit/?id=57707a9a778 [2] https://review.coreboot.org/13410/
> > > [3]
> > > https://review.coreboot.org/cgit/coreboot.git/tree/src/drivers/pc80/
> > > tp
> > > m/tpm.c
> >
> > Hi,
> >
> > Thank you for bisecting the issue. It would have been hard to achieve
> > this without the hardware. Do you want to create a patch for ACPICA?
> >
> > /Jarkko
Dear Robert,
Thank you for looking into this.
On 2017-04-12 17:54, Moore, Robert wrote:
> And probably the dmesg if error messages appear in there.
Linux doesn’t log any messages, as the `tpm` module doesn’t load. Please
find the output of `sudo acpidump` attached.
[…]
Kind regards,
Paul
PS: Doesn’t your mail client support to easily reply in interleaved
style?
> -----Original Message-----
> From: Paul Menzel [mailto:[email protected]]
> Sent: Wednesday, April 12, 2017 2:27 PM
> To: Moore, Robert <[email protected]>
> Cc: Jarkko Sakkinen <[email protected]>; Maciej S.
> Szmigiero <[email protected]>; [email protected];
> Arthur Heymans <[email protected]>; [email protected];
> [email protected]; Zheng, Lv <[email protected]>; Wysocki, Rafael J
> <[email protected]>; [email protected]
> Subject: RE: [Regression Linux 4.11] TPM module not loaded anymore
>
> Dear Robert,
>
>
> Thank you for looking into this.
>
>
> On 2017-04-12 17:54, Moore, Robert wrote:
> > And probably the dmesg if error messages appear in there.
>
> Linux doesn’t log any messages, as the `tpm` module doesn’t load. Please
> find the output of `sudo acpidump` attached.
>
> […]
>
[Moore, Robert]
Do you have any idea what control method(s) are executing? The DSDT and SSDT in the acpidump load fine here, and all predefined control methods in these tables execute OK.
We need to root-cause this problem, as a simple revert will break the customers that the fix was intended for in the first place.
Bob
>
> Kind regards,
>
> Paul
>
>
> PS: Doesn’t your mail client support to easily reply in interleaved
> style?
Dear Robert,
Thank you for your reply.
On 2017-04-12 23:49, Moore, Robert wrote:
>> On 2017-04-12 17:54, Moore, Robert wrote:
>> > And probably the dmesg if error messages appear in there.
>>
>> Linux doesn’t log any messages, as the `tpm` module doesn’t load.
>> Please
>> find the output of `sudo acpidump` attached.
>>
>> […]
>
> Do you have any idea what control method(s) are executing? The DSDT
> and SSDT in the acpidump load fine here, and all predefined control
> methods in these tables execute OK.
Sorry, I don’t know what’s done.
> We need to root-cause this problem, as a simple revert will break the
> customers that the fix was intended for in the first place.
I know, but I have no idea how to root-cause this. If nothing can be
found, a revert is required by Linux’ no-regression-policy.
Kind regards,
Paul