On Tuesday 31 July 2007 03:31:43 pm [EMAIL PROTECTED] wrote:
> On Tue, 31 Jul 2007 14:01:21 MDT, Bjorn Helgaas said:
> > So, the BIOS is telling us that at least as currently configured, the
> > TPM can't use interrupts. /sys/devices/pnp0/00:0f/options should have
> > all the *possible* TPM
On Tue, 31 Jul 2007 14:01:21 MDT, Bjorn Helgaas said:
> So, the BIOS is telling us that at least as currently configured, the
> TPM can't use interrupts. /sys/devices/pnp0/00:0f/options should have
> all the *possible* TPM configurations. I would guess that none of them
> shows an IRQ either.
On Tuesday 31 July 2007 12:48:29 pm [EMAIL PROTECTED] wrote:
> Scratch that. When I wrote the first note, I was at home, and the TPM chip
> did its PNP thing and became 00:0e. I failed to notice that in my reply,
> I was at work, and the printer port on the docking station became 00:0e and
> the
On Mon, 30 Jul 2007 19:53:19 EDT, [EMAIL PROTECTED] said:
> > > 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 =
On Mon, 30 Jul 2007 19:53:19 EDT, [EMAIL PROTECTED] said:
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
On Tuesday 31 July 2007 12:48:29 pm [EMAIL PROTECTED] wrote:
Scratch that. When I wrote the first note, I was at home, and the TPM chip
did its PNP thing and became 00:0e. I failed to notice that in my reply,
I was at work, and the printer port on the docking station became 00:0e and
the TPM
On Tue, 31 Jul 2007 14:01:21 MDT, Bjorn Helgaas said:
So, the BIOS is telling us that at least as currently configured, the
TPM can't use interrupts. /sys/devices/pnp0/00:0f/options should have
all the *possible* TPM configurations. I would guess that none of them
shows an IRQ either.
On Tuesday 31 July 2007 03:31:43 pm [EMAIL PROTECTED] wrote:
On Tue, 31 Jul 2007 14:01:21 MDT, Bjorn Helgaas said:
So, the BIOS is telling us that at least as currently configured, the
TPM can't use interrupts. /sys/devices/pnp0/00:0f/options should have
all the *possible* TPM
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"
On Friday 27 July 2007 04:43:13 pm Bjorn Helgaas wrote:
> On Friday 27 July 2007 07:28:09 am [EMAIL PROTECTED] wrote:
> > Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
> >
> > for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {
> >
On Friday 27 July 2007 04:43:13 pm Bjorn Helgaas wrote:
On Friday 27 July 2007 07:28:09 am [EMAIL PROTECTED] wrote:
Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
for (i = 3; i 16 chip-vendor.irq == 0; i++) {
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
On Friday 27 July 2007 07:28:09 am [EMAIL PROTECTED] wrote:
> Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
>
> for (i = 3; i < 16 && chip->vendor.irq == 0; i++) {
> iowrite8(i, chip->vendor.iobase +
>
On Fri, 27 Jul 2007 11:07:01 PDT, Andrew Morton said:
> On Fri, 27 Jul 2007 09:28:09 -0400
> [EMAIL PROTECTED] wrote:
> > And we have a winner. In my bisect 'hunt' file, I ended at:
> >
> > fs-use-kmem_cache_zalloc-instead.patch GOOD
> > # remove-kconfig-setting-config_debug_shirq.patch: Ingo
On Fri, 27 Jul 2007 09:28:09 -0400
[EMAIL PROTECTED] wrote:
> On Fri, 27 Jul 2007 00:00:32 EDT, [EMAIL PROTECTED] said:
>
> > Apparently, things go pear-shaped in tis_tpm_send(), when they get to the
> > 'if (chip->vendor.irq)' - under 22-rc6-mm1, we never got into this code,
> > because earlier
On Fri, 27 Jul 2007 00:00:32 EDT, [EMAIL PROTECTED] said:
> Apparently, things go pear-shaped in tis_tpm_send(), when they get to the
> 'if (chip->vendor.irq)' - under 22-rc6-mm1, we never got into this code,
> because earlier initialization complained it couldn't get IRQ8. Now, we
> get IRQ3,
On Fri, 27 Jul 2007 00:00:32 EDT, [EMAIL PROTECTED] said:
Apparently, things go pear-shaped in tis_tpm_send(), when they get to the
'if (chip-vendor.irq)' - under 22-rc6-mm1, we never got into this code,
because earlier initialization complained it couldn't get IRQ8. Now, we
get IRQ3, and
On Fri, 27 Jul 2007 09:28:09 -0400
[EMAIL PROTECTED] wrote:
On Fri, 27 Jul 2007 00:00:32 EDT, [EMAIL PROTECTED] said:
Apparently, things go pear-shaped in tis_tpm_send(), when they get to the
'if (chip-vendor.irq)' - under 22-rc6-mm1, we never got into this code,
because earlier
On Fri, 27 Jul 2007 11:07:01 PDT, Andrew Morton said:
On Fri, 27 Jul 2007 09:28:09 -0400
[EMAIL PROTECTED] wrote:
And we have a winner. In my bisect 'hunt' file, I ended at:
fs-use-kmem_cache_zalloc-instead.patch GOOD
# remove-kconfig-setting-config_debug_shirq.patch: Ingo worried
On Friday 27 July 2007 07:28:09 am [EMAIL PROTECTED] wrote:
Looks like the problematic code is in tpm_tis.c tpm_tis_init() near here:
for (i = 3; i 16 chip-vendor.irq == 0; i++) {
iowrite8(i, chip-vendor.iobase +
On Wed, 25 Jul 2007 20:37:37 PDT, Andrew Morton said:
> I can't imagine what we did to break tpm_tis, sorry. Nothing has changed
> in there for ages.
>
> Perhaps something broke at the bus level. It would be useful to add
OK, so I made a more intrusive printk-all-over patch to track what it
On Wed, 25 Jul 2007 20:37:37 PDT, Andrew Morton said:
I can't imagine what we did to break tpm_tis, sorry. Nothing has changed
in there for ages.
Perhaps something broke at the bus level. It would be useful to add
OK, so I made a more intrusive printk-all-over patch to track what it was
On Wed, 25 Jul 2007 18:03:14 -0400 [EMAIL PROTECTED] wrote:
> On Wed, 25 Jul 2007 04:03:04 PDT, Andrew Morton said:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/
>
> It built and booted on the first try for my Dell Latitude D820 laptop, Core2
>
On Wed, 25 Jul 2007 04:03:04 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/
It built and booted on the first try for my Dell Latitude D820 laptop, Core2
T7200 x86_64 kernel. Now at about 5 hours of uptime. I guess I got lucky
On Wed, 25 Jul 2007 04:03:04 PDT, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/
It built and booted on the first try for my Dell Latitude D820 laptop, Core2
T7200 x86_64 kernel. Now at about 5 hours of uptime. I guess I got lucky
On Wed, 25 Jul 2007 18:03:14 -0400 [EMAIL PROTECTED] wrote:
On Wed, 25 Jul 2007 04:03:04 PDT, Andrew Morton said:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc1/2.6.23-rc1-mm1/
It built and booted on the first try for my Dell Latitude D820 laptop, Core2
T7200
26 matches
Mail list logo
