Description of problem: System is often frozen on login screen. Booting to init 3 to get a text login yields the same result. Version-Release number of selected component (if applicable): 2.6.27.5-117.fc10.x86_64 (but it doesn't seem to be x86_64 specific.) How reproducible: About 3 times in 5 tries, but it depends a lot. Sometimes, I can login on the first try, and sometimes I need up to ten tries to get a responsive system. Steps to Reproduce: 1. Boot system. (Rebooting, on the other hand, never hit the bug on my system.) Actual results: System frozen on gdm (or text login) screen. Keyboard and touchpad inputs are ignored. But the system isn't completelly dead. Pressing the power button will bring the shutdown window. I can't click it, but waiting 60 seconds will give a clean shutdown. Expected results: Responsive system. Additional info: Video: Intel 965. Wireless: Intel 3945. This seems to be related to iwl3945. Please check this thread: https://bugs.launchpad.net/intellinuxwireless/+bug/263059 This patch is likely to fix the issue: http://bugzilla.kernel.org/show_bug.cgi?id=11746 Also, I mentioned this in bug #473542, but created this report to avoid mixing different issues. If more information is needed, please let me know and I'll reply as soon as possible. Also, I'm willing to test any kernel updates that might come.
It seems that dynamic ftrace is broken on kernel 2.6.27 and is causing my issues. Can we get a .28 kernel or a .27 kernel with ftrace disabled?
Created attachment 325633 [details] dmesg of a boot that resulted in irresponsive system Disabling wifi in BIOS avoids system freezing. Also, the freezing starts right in the beggining of the boot - pressing ESC in Plymouth boot screen is ignored too. The attachment is my /var/log/dmesg.old.
Too early to talk. System has hung today with wifi disabled in BIOS. Again, the power button was responsive (raised the shutdown window, etc), but nothing else. It seems that if the system is off for a long time, it's hard to get a functional boot. On the other hand, when I get a good boot, the system works great.
I have talked to Pedro Matiello (in off) we have the same laptop (Dell Vostro 1310) and I'm having the same issue here. Simply the keyboard and touchpad don't work sometimes. Yes, I said sometimes and the most of times. The basic behavior is that when you turn on the laptop, the most of times the F10 system is not able to find the input devices and it forces you, either to plug external USB devices or turn off the machine using the power button. If you use a external USB mouse it works fine. Although I don't have a USB keyboard to test it here at this moment. After some research on the web I realized that it possibly can be related with the uvdev input feature in F10. By the way, I have tried a lot of kind of configuration cited on [1] and [2], but no luck until now. I'm going to attach some config files and hopefully it will help in something. [1] http://fedoraproject.org/wiki/Features/EvdevInputDriver [2] http://who-t.blogspot.com/2008/07/input-configuration-in-nutshell.html
Created attachment 326237 [details] Xorg.conf Xorg.conf generated by Xorg -configure and included the AutoAddDevices option.
Created attachment 326238 [details] 10-x11-input.fdi
Created attachment 326240 [details] Xorg.0.log
Created attachment 326242 [details] dmesg.txt
(In reply to comment #1) > It seems that dynamic ftrace is broken on kernel 2.6.27 and is causing my > issues. Can we get a .28 kernel or a .27 kernel with ftrace disabled? That was disabled long ago in Fedora. What makes you think it's enabled?
Is this log from a working session or from a broken one? It looks completely normal to me, with all the devices being added properly Try Option "AutoAddDevices" "off" in the ServerLayout though, just for a check.
If you get a good boot right after a failed one, the file /var/log/dmesg.old will have the log from the failed boot.
Hello, Chuck. I believed it was ftrace because of a bug in Ubuntu (caused by a combination of ftrace and iwl3945) that produced exactly the same symptoms. As iwl3945 seemed to be related to my issue (booting with wifi disabled in BIOS increased somehow my chances of getting a good boot, but that might have been just luck), I wrongly concluded that the bug was the same. Sorry for that. I did a clean reinstall here (kept only /home) and the bug is still present. For now, I've been using suspend to avoid hitting the bug, but that's definitely not optimal. The dmesg.old I uploaded before is from a failed boot.
Created attachment 326247 [details] dmesg.old from a boot failed
Created attachment 326248 [details] Xorg.0.log.old
Those two files above were created even using Option "AutoAddDevices" "off" in the ServerLayout section.
$ grep serio dmesg_bad.txt serio: i8042 KBD port at 0x60,0x64 irq 1 $ grep serio dmesg_good.txt serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 input: AT Translated Set 2 keyboard as /devices/platform/i8042/serio0/input/input5 input: PS/2 Mouse as /devices/platform/i8042/serio1/input/input7 input: AlpsPS/2 ALPS GlidePoint as /devices/platform/i8042/serio1/input/input8
As the most of times this issue makes the whole system unable to be use, I'm changing the priority of it. Thank you for the cooperation.
Blaming the kernel for this one, the input devices don't even show up in the dmesg output when it fails.
Peter, thank you for the explanation. Well, I have tried three different kernels until now and no luck. * 2.6.27.8-144.fc10.x86_64 (on koji right now) * 2.6.27.7-134.fc10.x86_64 * 2.6.27.5-117.fc10.x86_64 The dmesg diff between the failed and succeed boot is the same as above on comment #16.
It appears I'm hitting the same thing on my T43p. Keyboard input works early in boot process (e.g. typing in LUKS password) but once I hit GDM no input devices work. The built-in keyboard and mouse work (along with a USB keyboard/mouse) if I go into runlevel 3, but nothing works once X starts. What's strange is that my laptop was working perfectly until I did updates last night and rebooted this morning. Booting into the pre-update kernel (2.6.27.5-117.fc10.i686) hasn't helped.
Looks like I fixed this (at least what I am hitting) by downgrading from hal-info-20081022-2.fc10.noarch to hal-info-20081022-1.fc10.noarch.
Before downgrading hal-info in my testing, I also reverted kernel-firmware-2.6.27.7-134.fc10 to kernel-firmware-2.6.27.5-117.fc10.noarch. So it's possible that's also related to the fix, even though by itself didn't work.
This is a me too. I am experiencing hangs on my Lenovo T60. It is odd that it doesn't happen at home, but it happens reliably on the RH wireless routers. It happened to me in Westford and Atlanta offices. I am running 2.6.27.7-134.fc10.x86_64 now. I have noticed I get a message from NetworkManager right as the hang happens.
I am still experiencing the hang. I am running the 2.6.27.9-159.fc10.x86_64 kernel. I have noticed it only happens with WEP encryption. I have several WPA based places I connect and I have no trouble.
It looks like there's a fix in 2.6.30 and a workaround for previous kernels is to add the "i8042.reset" kernel option: https://bugs.launchpad.net/ubuntu/+bug/344698
This message is a reminder that Fedora 10 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 10. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '10'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 10's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 10 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.