Hi Jarkko and MicroFish,
I'm following up on this discussion:
https://www.mail-archive.com/[email protected]/msg2652132.html
I would like to add a Fujitsu/Intel platform with what appears to be a
related NVS resource reservation failure. I have not tested the proposed
patch; this is an additional hardware report.
Hardware and software:
System: FUJITSU FMVU14003
Board: FJNB2B5
CPU: Intel Core i5-7300U (family 6, model 142, stepping 9)
BIOS: Version 1.33, 11/25/2025
OS: NixOS 26.05
Running kernel: 7.2.5 (NixOS build)
/proc/sys/kernel/tainted: 0
On this machine, the TPM2 table specifies StartMethod 2 (ACPI Start).
The control area, rather than the MMIO range reported by _CRS, lies
inside ACPI NVS:
TPM2 table (length 52, revision 3, checksum valid):
ControlAddress: 0x000000008ff6e000
StartMethod: 2
Relevant /proc/iomem entries:
8d77f000-8ff7efff : ACPI Non-volatile Storage
fed40000-fed44fff : MSFT0101:00
The TPM SSDT declares _CRS with base 0xfed40000 and length 0x5000.
It also contains:
OperationRegion (TPMR, SystemMemory, 0xFED40000, 0x5000)
OperationRegion (TNVS, SystemMemory, 0x8FF6F000, 0x27)
OperationRegion (CONA, SystemMemory, 0x8FF6E000, 0x30)
The kernel reports:
tpm_crb_acpi MSFT0101:00: error -EBUSY: can't request region for
resource [mem 0x8ff6e000-0x8ff6e02f]
tpm_crb_acpi MSFT0101:00: probe with driver tpm_crb_acpi failed with error -16
ima: No TPM chip found, activating TPM-bypass!
Neither /dev/tpm0 nor /dev/tpmrm0 exists, and both /sys/class/tpm and
/sys/class/tpmrm are empty. The ACPI device has status 15 and an existing
platform physical_node, so platform device creation itself succeeded.
Based on the ACPI tables and source inspection, this appears to reach the
iores == NULL path in crb_map_res() when crb_map_io() first maps the
48-byte control area. That area lies outside _CRS but within the NVS
reservation. This is an inference from the tables and error range;
I have not instrumented the driver to trace the call path.
Earlier boot logs show the same error and address on BIOS 1.10, 1.30
with kernel 7.2.6. I do not have a known-good Linux kernel on this machine,
so I am not reporting this as a confirmed regression. The TPM works in
Windows on the same machine; its TPM firmware has also been updated.
The vendor of the TPM is infineon, but the exact TPM firmware revision
has not been collected here.
The missing devices cause systemd 260.2 to wait 90 seconds in the initrd
and another 90 seconds after switching to the real root. We have prepared
systemd.tpm2_wait=0 as a local workaround for the boot delay; it does not
restore the TPM device.
Does this look like another instance of the NVS mapping issue, and is
there a preferred revised patch or targeted diagnostic for this ACPI
StartMethod 2 layout? I can provide the raw TPM2 table and TPM SSDT,
including its disassembly, if useful.
Best Regards,
Delton Ding
