+++ This bug was initially created as a clone of Bug #530393 +++

Description of problem:
When booting Fedora 12 Beta x86_64 with kernel-2.6.31.1-56 on a Acer TM6465WLMi (x86_64) I see the following:
...
tpm_tis: 00:0a: 1.2 TPM (device-id 0xB, rev-id 16)
...
(hangs for a couple of minutes)
tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
(hangs for a couple of minutes)
tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
(hangs for a couple of minutes)
... (boot continutues)
input: PS/2 Generic Mouse at...
(hangs for a couple of minutes)
tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
No TPM chip found: activating TPM-bypass
(boot continues and Gnome desktop starts)

Version-Release number of selected component (if applicable):
kernel-2.6.31.1-56

How reproducible:
Just boot F12

Steps to Reproduce:
1. boot F12
2. wait for it to happen
3. boot process continues
  
Actual results:
Boot F12, kernel boot hangs for a couple of minutes, then the error msgs start, it continues, hangs again for a couple of minutes, wait for more error msgs appear + TPM-bypass msg then the boot process continues

Expected results:
no hangs (and error msgs?)

Additional info:

--- Additional comment from eparis on 2009-10-22 10:38:59 PDT ---

A likely difference is that F12 builds IMA, which F11 did not.  Building IMA means that the TPM code is built in and is not a module.  It also means that the TPM is used on every boot.  I poked the TPM maintainer to see if he had initial thoughts on how to debug this issue.

--- Additional comment from srajiv.ibm.com on 2009-10-22 11:11:07 PDT ---

Looking at tpm_tis_send() it looks like the same problem with iTPM, 62 is mapped to the timeout error. Can you try the patch below?

http://marc.info/?l=tpmdd-devel&m=125264269616715&w=2

The driver must be built as a module and loaded with itpm=1. Given this I probably will need submit a patch that works when built in too, it's simple though, will do it meanwhile.

Thanks,
Rajiv

--- Additional comment from rh_bugzilla.nl on 2009-10-22 12:27:16 PDT ---

Rajiv: thank you for the feedback. Unfortunately I wouldn't know where to start to patch the rawhide kernel to do what you are asking.

Eric: any chance you (guys) could create a kernel with that patch and stick it somewhere for me to grab and test? If the goal is to include the TPM stuff in kernel and not as a module than perhaps it makes sense to first wait for Rajiv's patch that facilitates that? Either way I'll be happy to test anything you throw at me.

--- Additional comment from eparis on 2009-10-22 12:33:53 PDT ---

Sure, I can build an x86_64 kernel with that patch.  Might not be up until tomorrow.

--- Additional comment from rh_bugzilla.nl on 2009-10-29 14:49:09 PDT ---

Eric: any progress with that kernel?

--- Additional comment from awilliam on 2009-10-30 07:53:27 PDT ---

requested to be discussed as a blocker, so I'm adding it.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from eparis on 2009-10-30 11:43:59 PDT ---

I'm really sorry about the delay, I'll have a test kernel either tonight or tomorrow.

--- Additional comment from awilliam on 2009-10-30 11:44:57 PDT ---

Discussed at the blocker list today. We felt that the fact the system doesn't actually fail, just pauses for a while, combined with the fact eparis thinks this is down to bad hardware (though bad hardware that can be worked around), mean this isn't serious enough to be a blocker, so dropping from the list. Eric will try to provide the test kernel by the end of today, Patrick - that will help us confirm what exactly the problem is here. If Eric starts to get a bad feeling about the bug he'll put it back on teh blocker list.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from eparis on 2009-10-31 11:01:57 PDT ---

I haven't tested yet, but there are some kernels at http://people.redhat.com/~eparis/bz530393 which should have a patch which may help the situation.  You will need to boot with tpm_tis.itpm=1 on the kernel boot line.

If it works, can you attach a copy of dmesg after it boots?

--- Additional comment from awilliam on 2009-10-31 12:27:10 PDT ---

Patrick, please test as Eric requests. Thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from rh_bugzilla.nl on 2009-11-01 00:32:48 PDT ---

Adam: thanks for discussing it and your feedback
Eric: Thanks for creating the test kernel

Just tested the -105.1.bz530393 kernel. No joy. Here's what I did

1) install kernel & firmware

# yum localinstall --nogpgcheck kernel-2.6.31.5-105.1.bz530393.fc12.x86_64.rpm \
   kernel-firmware-2.6.31.5-105.1.bz530393.fc12.noarch.rpm

2) add tpm_tis.itpm=1 to /boot/grub/grub.conf

3) boot kernel

When booting the kernel I get the same errors (and waits) in spite of the iTPM workaround message showing up:

Linux agpgart interface v0.103
tpm_tis 00:0a: 1.2 TPM (device-id 0xB, rev-id 16)
tpm_tis 00:0a: Intel iTPM workaround enabled
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Battery Slot [BAT1] (battery absent)
tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
.
.
.
input: PS/2 Generic Mouse as /devices/platform/i8042/serio4/serio5/input/input8
tpm_tis 00:0a: tpm_transmit: tpm_send: error -62
No TPM chip found, activating TPM-bypass!


I'll add a copy of dmesg too.

--- Additional comment from rh_bugzilla.nl on 2009-11-01 00:33:58 PDT ---

Created attachment 366996 [details]
dmesg when booting 2.6.31.5-105.1.bz530393

--- Additional comment from eparis on 2009-11-01 06:09:48 PST ---

Just noticed the error code, -62 is -ETIME.  The iTPM code path is -EIO (-5).

--- Additional comment from cebbert on 2009-11-04 11:35:08 PST ---

*** Bug 532367 has been marked as a duplicate of this bug. ***

--- Additional comment from cebbert on 2009-11-04 12:10:56 PST ---

You should be able to work around this by adding "tpm_tis.interrupts=0" to the kernel boot options.

--- Additional comment from rh_bugzilla.nl on 2009-11-04 15:54:54 PST ---

That worked like a charm! Booting the kernel is no longer interrupted and I no longer see those error messages. Thank you all very much for your efforts. Most appreciated!

--- Additional comment from awilliam on 2009-11-16 23:56:02 PST ---

I don't believe that's a fix, it is - as Chuck said - a workaround. So re-opening. I'm not sure there's anything coherent for common bugs here, though. Chuck, Eric, what's the story?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from awilliam on 2009-11-20 13:26:48 PST ---

please do not adjust the priority and severity fields, Amir. By policy - https://fedoraproject.org/wiki/BugZappers/BugStatusWorkFlow - only the package maintainers should ever set the 'priority' field. The reporter may suggest a setting for the 'severity' field when reporting the bug, but once it has been triaged the value set by the triage team should only be overridden by the maintainer. No-one outside those three parties should ever set the 'severity' field. Thank you.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from hedayaty on 2009-11-20 18:37:40 PST ---

Sorry for that, but this is a huge bug. 
Though it is just a few days since FC12 is released but this has not been fixed.

Anyway after the bug is fixed when Vaio and Acer (or maybe more) laptop uses will need to add "tpm_tis.interrupts=0" to kernel during install and first time boot.
So people with these laptops probably will not be able to install and use fedora. No one expects to waits on black screen for 6 minutes! I suggest this to be mentioned in Fedora Common Bugs.

I am not a quality assurance expert, but the definition I just read 
    *  Urgent: the bug makes whole system unusable (or it is a security bug, which is per definition urgent)
    * High: the bug makes the program in question unusable
    * Medium: a real bug which makes program more difficult to use, at least part of the program is available; possibly workarounds are available
    * Low: anything else - cosmetic issues, corner cases with unusual (non-default) configurations, etc. 

Medium seems closer to definition but this is not just a program, It the kernel!

Anyway, I do not want to fight on this topic, it is better to talk on technical details and try to fix it. I agree that in big picture if third party or people start changing the priorities and severity it will make trouble.

--- Additional comment from awilliam on 2009-11-21 08:28:30 PST ---

you're reading too much into it. We've no information to indicate _all_ Sony and Acer laptops are affected (frankly that would be unlikely anyway, as there's very little that _all_ models from a single manufacturer have in common). All we know so far is that a single system is affected. If you also have an affected system, it would be useful for you to provide that information. Then, we'd know that two systems are affected. :)

yes, the severity is 'medium' because it does not render the application (and hence system) unusable. Priority is up to the kernel team. They don't really use this field at present, that's their choice.

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from marcet on 2009-11-23 00:05:07 PST ---

Sony SZ71VN/X is affected.

--- Additional comment from thomas on 2009-11-23 02:00:15 PST ---

All systems in my home were affected (all zepto laptops).
I thought it was a problem with my install media, so before I by accident let it wait for 10 minutes at boot, I had burned 6 different install cds and dvds.

--- Additional comment from awilliam on 2009-11-23 12:32:57 PST ---

thomas: what models specifically do you have?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from thomas on 2009-11-23 13:34:19 PST ---

6625WD and 6024W

--- Additional comment from granger.adrien on 2009-12-01 04:37:49 PST ---

Hi,
I'm running F12 x86_64 on my vaio SZ750N and I have the same problem.
I tried to install the fixed kernel as Patrick did and added tpm_tis.interrupts=0 into /boot/grub/grub.conf but the problem is still there.

Regards,
Adrien

--- Additional comment from nkoutsou on 2009-12-18 05:21:19 PST ---

Vaio SZ71XN/C also affected.

Workaround with kernel option "tpm_tis.interrupts=0" works 
on kernel 2.6.31.6-166.fc12.x86_64

Cheers
Nikitas

--- Additional comment from braviale on 2009-12-26 04:00:23 PST ---

Acer TravelMate 6592 (Intel Core 2 T7300 Processor) also affected.

Description of problem:

When booting Fedora 12 (Constantine) kernel-2.6.31.6-166.fc12.i686.PAE on an i686

I see the following:

tpm_tis 00:0b: tpm_transmit: tpm_send: error 4294967234
(hangs for a couple of minutes)
tpm_tis 00:0b: tpm_transmit: tpm_send: error 4294967234
(hangs for a couple of minutes)
tpm_tis 00:0b: tpm_transmit: tpm_send: error 4294967234
(hangs for a couple of minutes)
... (boot continutues)

Adding "tpm_tis.interrupts=0" into /boot/grub/grub.conf file solves the problem.

Regards,
Alessandro.

--- Additional comment from braviale on 2009-12-26 04:19:10 PST ---

Latest kernel 2.6.31.9-174.fc12.i686 completly solves the bug. Thanks.

--- Additional comment from paavo.nieminen on 2010-01-10 16:49:45 PST ---

Problem and workaround are exactly like in Comment 27 on my Acer TravelMate 6492 using kernel version 2.6.31.9-174.fc12.i686.PAE

My Acer TravelMate 6292 has never had this problem, even though it is quite similar to the 6492.

--- Additional comment from cedricv on 2010-01-12 05:20:58 PST ---

Same issue with 2.6.32.3-17.fc12.x86_64 on Sony Vaio SZ75MZ.

--- Additional comment from g.a.stark on 2010-01-14 01:43:20 PST ---

Same issue on Sony Vaio SZ750N

--- Additional comment from mark.richards on 2010-01-31 20:26:35 PST ---

I have this issue with LG R500 notebook, 2.6.31.12-174.2.3.fc12.x86_64.

--- Additional comment from jpederse on 2010-03-10 05:07:18 PST ---

Same problem with F13 Alpha with Acer TravelMate 6592

--- Additional comment from jpederse on 2010-03-10 10:07:39 PST ---

Just in case it matters; output is:

tpm_tis 00:0b: 1.2 TPM (device-id 0xB, rev-id 16)

tpm_transmit: tpm_send: error -62

--- Additional comment from fedora-triage-list on 2010-03-15 05:58:15 PDT ---


This bug appears to have been reported against 'rawhide' during the Fedora 13 development cycle.
Changing version to '13'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

--- Additional comment from hedayaty on 2010-05-06 05:29:29 PDT ---

I wanted to ask what happens to rest of users if "tpm_tis.interrupts=0" is added by kernel? Can Fedora add this by default until the bug gets fixed and if some users loose some functionality ask them to remove it from bootparams?

--- Additional comment from douglas.holmes.mil on 2010-05-11 05:24:39 PDT ---

I a have a Getac B300 Laptop where I have added "tpm_tis.interrupts=0" to Grub as instructed.  Still receive the same message during the elongated boot.  Running Kernel Versions:

2.6.31.5-127.fc12.i686.PAE
2.6.32.11-99.fc12.i686.PAE

Same problem for both.  Could be a user issue.  Not too familiar with GRUB.

--- Additional comment from awilliam on 2010-05-18 03:38:29 PDT ---

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from dchun529 on 2010-05-23 16:16:53 PDT ---

I have been having the same issue with my Asus F50SV-A2, this occurs when I try to boot into Fedora 13 Beta.  I was able to boot Fedora 12 on my laptop but never was able to use it because there were problems with the ACPI drivers.

I added the "tpm_tis.interrupts=0" into grub and my system is still locking up.
No TPM chip found: activating TPM-bypass

I'd appreciate any input.

--- Additional comment from txn2tahx3v on 2010-05-25 10:19:41 PDT ---

I get a similar thing on a Getac P470 GP.  BIOS defaults.

This bug may be a duplicate of bug 530393.

kernel: 2.6.32.12-115.fc12.i686.PAE

Here's what I see during boot...

tpm_tis 00:0b: 1.2 TPM (device-id 0xB, rev-id 16)
tpm_tis 00:0b: tpm_transmit: tpm_send: error 4294967234
tpm_tis 00:0b: tpm_transmit: tpm_send: error 4294967234
tpm_tis 00:0b: tpm_transmit: tpm_send: error 4294967234

The first error shows up after a two minute pause during boot.
Then the second and third each after another two minute hiatus.

Then the boot continues, only to pause later after...

 .
 .
usb 1-7: New USB device found, idVendor=05e3, idProduct=0608
usb 1-7: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-7: Product: USB2.0 Hub
usb 1-7.1: configuration #1 chosen from 1 choice

... and ...

tpm_tis 00:0b: tpm_transmit: tpm_send: error 4294967234
No TPM chip found, activating TPM-bypass!
  Magic number: 10:460:945
 .
 .

Again, a two-minute pause there.

As with others, adding 'tpm_tis.interrupts=0' to the kernel args makes it boot without the four two minute pauses.

--- Additional comment from txn2tahx3v on 2010-05-25 10:21:57 PDT ---

I meant that it seems to be a duplicate of bug 537459, not 530393 (which is this one, of course).

--- Additional comment from awilliam on 2010-05-25 14:55:13 PDT ---

*** Bug 537459 has been marked as a duplicate of this bug. ***

--- Additional comment from schlaffi.net on 2010-05-27 00:30:02 PDT ---

Same for

  *FC13 x86_64 release on
  *Acer TravelMate 6492-832G25N_UMTS using either of
  *kernel-2.6.33.3-85.fc13.x86_64 and
  *kernel-2.6.33.4-95.fc13.x86_64.

The ``tpm_tis.interrupts=0'' trick solves the problem.


The boot delay is roughly 10 min and also happens at the boot of the DVD-installer. (It was pure chance that I waited for so long and did not wait for FC14.)

--- Additional comment from awilliam on 2010-05-31 14:03:53 PDT ---



-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

--- Additional comment from srajiv.ibm.com on 2010-05-31 21:25:09 PDT ---

Created attachment 418456 [details]
TPM debugging patch

These TPMs aren't setting the right status after a command was sent to it, the attached patch attempts to read the command and also the TPM status value when so. Also please send out a tpm_version output when running the kernel with the workaround.

--Rajiv

--- Additional comment from schlaffi.net on 2010-05-31 23:23:11 PDT ---

(In reply to comment #43 and comment #45)

without having your patch applied:

# tpm_version -l debug
Tspi_Context_Create success
Tspi_Context_Connect failed: 0x00003011 - layer=tsp, code=0011 (17), Communication failure
Tspi_Context_FreeMemory success
Tspi_Context_Close success

hth

--- Additional comment from srajiv.ibm.com on 2010-06-01 05:12:24 PDT ---

Thanks, the tpm-tools applications need the TCS daemon running in order to send commands to the TPM, can you run tcsd -f& first and then run tpm_version? Sorry for not mentioning that earlier.

--- Additional comment from schlaffi.net on 2010-06-01 06:30:36 PDT ---

(In reply to comment #47)

# tpm_version
  TPM 1.2 Version Info:
  Chip Version:        1.2.1.2
  Spec Level:          2
  Errata Revision:     0
  TPM Vendor ID:       IFX
  TPM Version:         01010000
  Manufacturer Info:   49465800

does this help more?

--- Additional comment from hedayaty on 2010-06-01 13:01:04 PDT ---

Here is my output without patch

$ tpm_version -l debug
Tspi_Context_Create success
Tspi_Context_Connect success
Tspi_Context_GetTpmObject success
Trspi_UnloadBlob_CAP_VERSION_INFO success
  TPM 1.2 Version Info:
  Chip Version:        1.2.1.2
  Spec Level:          2
  Errata Revision:     0
  TPM Vendor ID:       IFX
Tspi_TPM_GetCapability success
  TPM Version:         01010000
Tspi_TPM_GetCapability success
  Manufacturer Info:   49465800
tpm_version succeeded
Tspi_Context_FreeMemory success
Tspi_Context_Close success


I downloaded a kernel, added the patch, modified the sepcfile and used 

rpmbuild --target=`uname -m` kernel.spec rpmbuild -bb --with baseonly --with firmware --without debuginfo

To build, it used up 4.3G remaining space on the partition and the process broke because of low disc space! What is wrong I am doing, I have not compiled the kernel for a few years

--- Additional comment from hedayaty on 2010-06-01 13:11:01 PDT ---

sorry I ment

rpmbuild --target=`uname -m` kernel.spec -bb --with baseonly --with
firmware --without debuginfo

--- Additional comment from srajiv.ibm.com on 2010-06-08 10:32:26 PDT ---

Ok, I tried to forcibly reproduce it here with my TPM, and since yours is working without interrupts it might be setting the status flags fine also, given when using polling the device driver also checks for the same values.
When using PNP (and not setting force option to 1), the IRQ is assigned through PNP, and I'd like to check whether the IRQ the driver is using is valid or not, can you place the contents of /proc/interrupts when not using the workaround? Wait_event_interruptible_timeout() fails if using an invalid IRQ.

Rajiv

--- Additional comment from schlaffi.net on 2010-06-11 13:56:39 PDT ---

(In reply to comment #51)

Whatever you wish :)

/proc/interrupts without workaround:

           CPU0       CPU1       
  0:     795184     701300   IO-APIC-edge      timer
  1:          5       2706   IO-APIC-edge      i8042
  8:          0          1   IO-APIC-edge      rtc0
  9:         31          7   IO-APIC-fasteoi   acpi
 11:          0          0   IO-APIC-edge      tpm0
 12:       1045       1542   IO-APIC-edge      i8042
 14:      30773      28710   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 18:         29         77   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb7
 19:         22      32627   IO-APIC-fasteoi   uhci_hcd:usb6
 20:          4         91   IO-APIC-fasteoi   yenta, firewire_ohci, mmc0
 21:        155        124   IO-APIC-fasteoi   uhci_hcd:usb4, yenta
 22:         88          1   IO-APIC-fasteoi   firewire_ohci
 23:          2          1   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb5
 28:      49762       2756   PCI-MSI-edge      ahci
 29:      11255     257572   PCI-MSI-edge      i915
 30:          1       2825   PCI-MSI-edge      eth0
 31:       1308        139   PCI-MSI-edge      hda_intel
 32:      42888      34688   PCI-MSI-edge      iwlagn
NMI:          0          0   Non-maskable interrupts
LOC:     721338     779100   Local timer interrupts
SPU:          0          0   Spurious interrupts
PMI:          0          0   Performance monitoring interrupts
PND:          0          0   Performance pending work
RES:      22538      17666   Rescheduling interrupts
CAL:        104        133   Function call interrupts
TLB:       3478       3814   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
MCE:          0          0   Machine check exceptions
MCP:         21         21   Machine check polls
ERR:          0
MIS:          0

hth

--- Additional comment from jpederse on 2010-06-28 03:49:31 PDT ---

Without the patch:

[root@localhost ~]# tpm_version -l debug
Tspi_Context_Create success
Tspi_Context_Connect success
Tspi_Context_GetTpmObject success
Trspi_UnloadBlob_CAP_VERSION_INFO success
  TPM 1.2 Version Info:
  Chip Version:        1.2.1.0
  Spec Level:          2
  Errata Revision:     0
  TPM Vendor ID:       IFX
Tspi_TPM_GetCapability success
  TPM Version:         01010000
Tspi_TPM_GetCapability success
  Manufacturer Info:   49465800
tpm_version succeeded
Tspi_Context_FreeMemory success
Tspi_Context_Close success


[root@localhost ~]# cat /proc/interrupts 
           CPU0       CPU1       
  0:     419673     314872   IO-APIC-edge      timer
  1:          5       1633   IO-APIC-edge      i8042
  8:         14          8   IO-APIC-edge      rtc0
  9:        956          1   IO-APIC-fasteoi   acpi
 12:         73     186678   IO-APIC-edge      i8042
 14:       8793       7039   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:          0          0   IO-APIC-fasteoi   uhci_hcd:usb3
 18:        112         91   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb7
 19:          0          0   IO-APIC-fasteoi   uhci_hcd:usb6
 20:          4         23   IO-APIC-fasteoi   yenta, mmc0, firewire_ohci
 21:          2          5   IO-APIC-fasteoi   uhci_hcd:usb4, yenta
 22:         86        743   IO-APIC-fasteoi   HDA Intel, firewire_ohci
 23:          4          1   IO-APIC-fasteoi   ehci_hcd:usb2, uhci_hcd:usb5
 29:      70127       2298   PCI-MSI-edge      ahci
 30:          2     232518   PCI-MSI-edge      eth0
 31:      36131      26827   PCI-MSI-edge      iwlagn
NMI:          0          0   Non-maskable interrupts
LOC:     337861     406099   Local timer interrupts
SPU:          0          0   Spurious interrupts
RES:      83567      58797   Rescheduling interrupts
CAL:         67         77   Function call interrupts
TLB:       7605       6194   TLB shootdowns
TRM:          0          0   Thermal event interrupts
THR:          0          0   Threshold APIC interrupts
ERR:          0
MIS:          0

--- Additional comment from dchun529 on 2010-07-06 01:36:26 PDT ---

I have tried numerous times to get this working, with tpm_tis.interrupt=0 and I even waited a hour.  The system never responded, am I the only one that has not been able to even get Fedora 12 or 13 installed because of this issue.

--- Additional comment from schlaffi.net on 2010-07-06 08:23:24 PDT ---

(In reply to comment #54)

try tpm_tis.interrupts=0 instead (note the difference). I am sure people will love it if you make the effort to vaguely write which system you are using...

--- Additional comment from dchun529 on 2010-07-06 09:03:45 PDT ---

I have tried that and probably every other combination of the command.  
tpm_tis.interrupts=0
tpm_tis.interrupt=0
tis_tpm.interrupt=0

Just to verify I tried it again with tpm_tis.interrupts=0 and it has been paused for about a hour now.

I have previously posted what system I have and details about my system but never got a response. 


https://bugzilla.redhat.com/show_bug.cgi?id=530393#c39

--- Additional comment from vctr.david on 2010-07-10 05:23:59 PDT ---

I've the same problem with an Asus F80s.

I tried adding the "tpm_tis.interrrupts=0" at the end of the kernel line in my boot.conf. But it doesn't work I'm still stuck with this message durin the boot :
"No TPM chip found: activating TPM-bypass !"

and then nothing :-(

Could anyone give me the entire file you used with "tpm_tis.interrrupts=0", maybe I used it a bad way.

Thank you.

--- Additional comment from myrick on 2010-08-18 09:10:15 PDT ---

Same problem here with a Sony VGN-SZ71VN/X!
the "tpm_tis.interrupts=0" workaround works for me. So I added it permanent to /boot/grub/menu.lst

@Sleipnir: you posted the parameter with 3 "r" - 2 are enough :-)

--- Additional comment from schlaffi.net on 2010-08-23 03:03:36 PDT ---

(In reply to comment #57)


/etc/grub.conf I use at the moment (obviously only suitable for my system):

title Fedora (2.6.34.3-37.fc13.x86_64)
	root (hd0,2)
	kernel /vmlinuz-2.6.34.3-37.fc13.x86_64 ro root=/dev/mapper/vg_system-lv_fc13x64 rd_LVM_LV=vg_system/lv_fc13x64 rd_NO_LUKS rd_NO_MD rd_NO_DM SYSFONT=latarcyrheb-sun16 KEYTABLE=de-latin1-nodeadkeys tpm_tis.interrupts=0 LANG=en_US.UTF-8
	initrd /initramfs-2.6.34.3-37.fc13.x86_64.img


hth

--- Additional comment from jpederse on 2010-08-28 08:05:54 PDT ---

Same story with Fedora 14 Alpha, as with Fedora 13 and 12

--- Additional comment from srajiv.ibm.com on 2010-08-29 22:47:47 PDT ---

Created attachment 441889 [details]
Fixes a TPM_SHORT timeout mishandling

This fixes the timeout issue, so the boot won't hang anymore. However, these TPMs won't work still on these platform if with interrupts enabled, I'll write another patch to fix this second issue.

Let me know of any problems with it.

Thanks,
Rajiv

--- Additional comment from srajiv.ibm.com on 2010-08-29 23:57:56 PDT ---

Created attachment 441896 [details]
Right fix

The previous one made tpm_get_timeouts() fail.

Again, this fixes the long boot problem, but still doesn't make these TPMs work with interrupts.

Thanks,
Rajiv

--- Additional comment from hedayaty on 2010-09-01 23:23:26 PDT ---

Thanks. Can you notify us when on FC13 or FC14-alpha the patches get applied?

--- Additional comment from cebbert on 2010-09-02 06:46:52 PDT ---

I've added the patch to rawhide: 2.6.36-0.15.rc3.git0

--- Additional comment from srajiv.ibm.com on 2010-09-02 11:01:55 PDT ---

I'll submit it to LKML soon.

Thanks

--- Additional comment from hedayaty on 2010-09-30 03:08:13 PDT ---

The bug is still in FC14-beta!