Bug 474357 - F10: system frozen on login screen
F10: system frozen on login screen
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
high Severity urgent
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: Patch, Triaged
Depends On:
  Show dependency treegraph
Reported: 2008-12-03 09:16 EST by Pedro Matiello
Modified: 2009-12-18 02:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-12-18 02:07:23 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
dmesg of a boot that resulted in irresponsive system (34.58 KB, text/plain)
2008-12-03 22:42 EST, Pedro Matiello
no flags Details
Xorg.conf (2.15 KB, text/plain)
2008-12-08 20:39 EST, Diego Búrigo Zacarão
no flags Details
10-x11-input.fdi (906 bytes, text/plain)
2008-12-08 20:41 EST, Diego Búrigo Zacarão
no flags Details
Xorg.0.log (29.23 KB, text/plain)
2008-12-08 20:43 EST, Diego Búrigo Zacarão
no flags Details
dmesg.txt (41.61 KB, text/plain)
2008-12-08 20:44 EST, Diego Búrigo Zacarão
no flags Details
dmesg.old from a boot failed (38.83 KB, text/plain)
2008-12-08 21:12 EST, Diego Búrigo Zacarão
no flags Details
Xorg.0.log.old (25.86 KB, text/plain)
2008-12-08 21:13 EST, Diego Búrigo Zacarão
no flags Details

  None (edit)
Description Pedro Matiello 2008-12-03 09:16:34 EST
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):
(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:

This patch is likely to fix the issue:

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.
Comment 1 Pedro Matiello 2008-12-03 15:14:32 EST
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?
Comment 2 Pedro Matiello 2008-12-03 22:42:26 EST
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.
Comment 3 Pedro Matiello 2008-12-04 14:25:27 EST
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.
Comment 4 Diego Búrigo Zacarão 2008-12-08 20:36:46 EST
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
Comment 5 Diego Búrigo Zacarão 2008-12-08 20:39:52 EST
Created attachment 326237 [details]

Xorg.conf generated by Xorg -configure and included the AutoAddDevices option.
Comment 6 Diego Búrigo Zacarão 2008-12-08 20:41:18 EST
Created attachment 326238 [details]
Comment 7 Diego Búrigo Zacarão 2008-12-08 20:43:50 EST
Created attachment 326240 [details]
Comment 8 Diego Búrigo Zacarão 2008-12-08 20:44:38 EST
Created attachment 326242 [details]
Comment 9 Chuck Ebbert 2008-12-08 20:47:36 EST
(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?
Comment 10 Peter Hutterer 2008-12-08 20:50:49 EST
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.
Comment 11 Chuck Ebbert 2008-12-08 20:59:02 EST
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.
Comment 12 Pedro Matiello 2008-12-08 21:02:37 EST
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.
Comment 13 Diego Búrigo Zacarão 2008-12-08 21:12:48 EST
Created attachment 326247 [details]
dmesg.old from a boot failed
Comment 14 Diego Búrigo Zacarão 2008-12-08 21:13:53 EST
Created attachment 326248 [details]
Comment 15 Diego Búrigo Zacarão 2008-12-08 21:21:05 EST
Those two files above were created even using Option "AutoAddDevices" "off" in the ServerLayout section.
Comment 16 Chuck Ebbert 2008-12-08 21:47:03 EST
$ 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
Comment 17 Diego Búrigo Zacarão 2008-12-09 07:03:23 EST
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.
Comment 18 Peter Hutterer 2008-12-09 17:33:02 EST
Blaming the kernel for this one, the input devices don't even show up in the dmesg output when it fails.
Comment 19 Diego Búrigo Zacarão 2008-12-10 07:17:43 EST
Peter, thank you for the explanation.

Well, I have tried three different kernels until now and no luck.

  * (on koji right now)

The dmesg diff between the failed and succeed boot is the same as above on comment #16.
Comment 20 Evan McNabb 2008-12-10 10:11:09 EST
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 ( hasn't helped.
Comment 21 Evan McNabb 2008-12-10 10:28:33 EST
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.
Comment 22 Evan McNabb 2008-12-10 10:43:31 EST
Before downgrading hal-info in my testing, I also reverted kernel-firmware- to kernel-firmware- So it's possible that's also related to the fix, even though by itself didn't work.
Comment 23 James Kirkland 2008-12-15 17:42:28 EST
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 now.   I have noticed I get a message from NetworkManager right as the hang happens.
Comment 24 James Kirkland 2009-01-15 13:22:03 EST
I am still experiencing the hang.  I am running the kernel.   I have noticed it only happens with WEP encryption.  I have several WPA based places I connect and I have no trouble.
Comment 25 Diego 2009-07-21 13:03:44 EDT
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:
Comment 26 Bug Zapper 2009-11-18 02:44:48 EST
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: 
Comment 27 Bug Zapper 2009-12-18 02:07:23 EST
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.

Note You need to log in before you can comment on or make changes to this bug.