Created attachment 520262 [details] Screen Shot of the message lines displayed during the 15 min. stall During boot, the machine stalls for about 15 minutes before it continues. During this time 4 message lines are written to the screen a couple of minutes apart. The kernel used is 2.6.28. When I try to boot using 2.6.30, the machine never get's further than a blank screen. I have attached an image of the screen containing the 4 message lines right before it continues the regular boot. I don't know which log files are needed for this, so please let me know, and I will attach them. P.S. This problem is not only attached to the installed system. I had the same problem with the USB Live Installer.
I have now tried to boot up the USB Installer on another machine, an Asus Aspire One (First model) and I get the same problem. The other laptop is a Zepto Znote 6625WD. So this issue is not restricted to the specific hardware in the first laptop.
Fedora 15 never used 2.6.28 or 2.6.30... what exactly are you trying to boot?
Sorry, I made a type error. I mean 2.6.38 and 2.6.40. Just add 10 to the version I typed.
Could you add 'rdblacklist=tpm_tis" to the kernel command line and see what happens after that?
Ok I just tried that but it makes no difference
I made some more google searches on this issue and I found an older Fedora bug report: https://bugzilla.redhat.com/show_bug.cgi?id=530393 Adding "tpm_tis.interrupts=0" to the kernel command line removes the stall. However, I don't know what TPM does, but adding the kernel command line makes gnome shell start in fallback mode with a lower resolution? The GPU is a nVidia GeForce 8600M GT. It seams that adding the command line disables the nouveau driver or something.
Hmm. After I rebooted twice using the kernel command line, the graphics works. Don't know why it stopped working for a while, but it seams that "tpm_tis.interrupts=0" works like a charm. Is there any way to fix the Fedora kernel so that it will work without this work-around? This issue is a Fedora-only bug. Never had this problem with other distro's suck as Debian, Ubuntu or Archlinux.
(In reply to comment #7) > Is there any way to fix the Fedora kernel so that it will work without this > work-around? This issue is a Fedora-only bug. Never had this problem with other > distro's suck as Debian, Ubuntu or Archlinux. When you added the rdblacklist=tpm_tis to the kernel command line, did the messages from tpm_tis go away? I would have expected the module to not be loaded at all, so either the blacklist didn't take for some reason, or something else is odd. Are any of those other distributions loading the tpm_tis module for you? Is there a particular kernel where this started happening?
The previous messages are gone yes. The only message in "dmesg" that is related to TPM is the fallowing "tpm_tis 00:0a: 1.2 TPM (device-id 0xB, rev-id 16)" Also I checked the loaded modules in Ubuntu, and no, the TPM module is not loaded by default.
(In reply to comment #9) > The previous messages are gone yes. > The only message in "dmesg" that is related to TPM is the fallowing > > "tpm_tis 00:0a: 1.2 TPM (device-id 0xB, rev-id 16)" That means the module is still getting loaded. Perhaps this is done after the initramfs has switched root. In that case, you can add: blacklist tpm_tis to /etc/modprobe.d/blacklist.conf That should prevent the module from loading entirely. If you'd still like it loaded, you can alternatively create a file called "tpm.conf" in /etc/modprobe.d with the contents: options tpm_tis interrupts=0 (or just add it to the end of dist.conf). There are a few commits upstream to this driver that might also help. If you have time, you could try booting the F16 Beta Live image and see if you get the hang as well.
Using Fedora 16 Beta, I get the TMP error and stall time even with the additional kernel command line. It works with the 15'th live disk but not the 16'th.
Sorry. Wrote TMP instead of TPM. Blacklisting it does not work, but setting interrupts=0 works fine, so I will stick to that if there is nothing else to be done.
I believe this was fixed in the 3.3 kernel. Do you still see this with 3.3 on F16?