linux-kernel - Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Jul 2007 19:53:19 -0400
From:	Valdis.Kletnieks@...edu
To:	Bjorn Helgaas <bjorn.helgaas@...com>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Kylene Hall <kjhall@...ibm.com>, tpm@...horst.net,
	linux-kernel@...r.kernel.org
Subject: Re: 2.6.23-rc1-mm1 - seems OK on Dell Latitude D820, except for tpm_tis

On Fri, 27 Jul 2007 16:43:13 MDT, Bjorn Helgaas said:

> I don't know why tpm_tis_init() is messing around trying different
> IRQs between 3 and 16.  That looks suspiciously x86-dependent.
> 
> Maybe if you don't have PNP (though I doubt TPMs exist on any
> pre-PNPBIOS machines) the "check-IRQ" loop would be necessary.

Well, it's a 6 month old Dell Latitude, and PNP is most certainly there,
as a number of other things get configured using it as well.

> But you're using the PNP probe, and PNP should just tell you what
> IRQ the device is configured for (and whether the IRQ can be
> shared -- see 8250_pnp.c for an example).
> 
> The BIOS should have configured the TPM IRQ, and if we go and
> mess with that IRQ setting without going through the PNP interface,
> e.g., the ACPI _SRS method, we're liable to mess something up.  The
> TPM is often behind a few bridges, and if the bridge has any IRQ
> routing configuration, only the BIOS knows how to keep that in
> sync with the TPM IRQ configuration.
> 
> > Just for the record, I see this in /sys:
> > 
> > % cat /sys/bus/pnp/devices/00:0e/id
> > BCM0102
> > PNP0c31
> 
> What's in /sys/bus/pnp/devices/00:0e/resources?

% cat /sys/bus/pnp/devices/00:0e/resources
state = active
io 0x378-0x37f
io 0x778-0x77b
irq 7
dma 1

IRQ 7.  That would certainly explain why I was seeing massive timeouts
when the driver chose to use IRQ 3. ;)

I'll test-drive your patch from Monday's e-mail when I get home tonight.


Content of type "application/pgp-signature" skipped