Description of problem: After installing 2.6.35.13-91.fc14.x86_64 on my Compaq Presario CQ61 (AMD Sempron M120), my laptop does not boot up smoothly. When selecting 13-91.fc14 from GRUB, I have to slide my finger on the trackpad to get the computer to finish the start up sequence and get to the login screen. I have to continue to slide my finger on the trackpad to get through the login sequence to get to my desktop. Shutting down my laptop runs into a similar problem. On the shutdown screen, the machine eventually just stops, and I have to finish the process by pressing the power key to shut it down manually. Booting into 2.6.35.12-90.fc14.x86_64, my machine boots up and logs in without any problem. Version-Release number of selected component (if applicable): 2.6.35.13-91.fc14.x86_64 How reproducible: Each and every single time Steps to Reproduce: 1. Start laptop 2. Select 2.6.35.13-91.fc14.x86_64 from GRUB 3. Press <ENTER> Actual results: The bootup screen is blank. I have to move my finger on trackpad to get the sequence to start. Eventually (and rather slowly), the login window is displayed. I log in, and I have to slide my finger on the trackpad to get through the KDE login sequence. Finally, the desktop appears. Expected results: Turn on laptop. Select 2.6.35.13-91.fc14.x86_64 from GRUB. It boots on its own. Login window is displayed. I type in my username/password, and KDE desktop appears on its own. Shutdown actually shuts down and turns laptop off. Additional info:
This problem does not seem to be limited to just booting and shut-down. The computer appears to hang any time the mouse isn't being moved around. I am experiencing the same booting and shut-down issues stated by the original poster after updating to kernel 2.6.35.13-91.fc14.x86_64. However, I have also noticed that other tasks (such as downloading files, checking for software updates, and even the system monitor) simply stop responding unless the mouse is continually moved around.
*** Bug 703508 has been marked as a duplicate of this bug. ***
Can you compare the "flags" line in /proc/cpuinfo and see if there is any difference between 2.6.35.12 and 2.6.35.13?
(In reply to comment #3) > Can you compare the "flags" line in /proc/cpuinfo and see if there is any > difference between 2.6.35.12 and 2.6.35.13? Here is the flags line from the cpuinfo file with each kernel loaded. Looks like there is an extra one in .13.. -------------- Kernel 2.6.35.13: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up rep_good arat Kernel 2.6.35.12: flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx mmxext lm 3dnowext 3dnow up rep_good
Created attachment 498612 [details] dmesg for 2.6.35.12
Created attachment 498613 [details] cpuinfo for 2.6.35.12
Created attachment 498615 [details] dmesg for 2.6.35.13
Created attachment 498616 [details] cpuinfo for 2.6.35.13
Created attachment 498644 [details] cpuinfo for 13-91.fc14 As requested
Created attachment 498645 [details] cpuinfo for 12-90.fc14 As requested
Please install the msr-tools package and post the output from the following commands: rdmsr 0xc0010140 rdmsr 0xc0010141 rdmsr 0xc0010055
rdmsr 0xc0010140 gives 2 rdmsr 0xc0010141 gives 0 rdmsr 0xc0010055 gives 0
Now can we get the contents of /proc/acpi/processor/CPU0/power ?
Created attachment 498834 [details] CPU0/power for 13-91 As requested
Created attachment 498835 [details] CPU0/power for 12-90 For 2.6.35.12-90
I have the same problem with this kernel (13-91.fc14.x86_64). I have been using the down arrow to switch between splash screen and text to get it to advance after hang on boot and shut down. Also noticed that my clock settings were messed up after update. All worked fine with previous kernel. HP Pavillion laptop, AMD Turion 64.
You should be able to work around this bug by adding "processor.max_cstate=1" to the kernel boot options. This will reduce battery life though.
With the added parameter, system boots normally. In response to comment #13, Contents of /proc/acpi/processor/CPU0/power: ============================================================================= :::::::::::::: power.2.6.35.12-88.fc14.x86_64 :::::::::::::: active state: C0 max_cstate: C8 maximum allowed latency: 2000000000 usec states: C1: type[C1] promotion[--] demotion[--] latency[000] usage[00001781] duration[00000000000000000000] C2: <not supported> C3: type[C3] promotion[--] demotion[--] latency[083] usage[00005329] duration[00000000000108275111] :::::::::::::: power.2.6.35.13-91.fc14.x86_64 :::::::::::::: active state: C0 max_cstate: C1 maximum allowed latency: 2000000000 usec states: C1: type[C1] promotion[--] demotion[--] latency[000] usage[00000000] duration[00000000000000000000] ============================================================================= These were both taken in mode 1. Version 2.6.35.13-91 was started with the extra parameter.
(In reply to comment #17) > You should be able to work around this bug by adding "processor.max_cstate=1" > to the kernel boot options. This will reduce battery life though. By adding the parameter to the boot option, I was able to boot successfully in the 13-91 kernel. My battery is taking quite a hit, however.
*** Bug 705644 has been marked as a duplicate of this bug. ***
Just as an additional datapoint: My (duplicate) bug 705664 happened on a Compaq Presario with a Turion 64.
kernel-2.6.35.13-92.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/kernel-2.6.35.13-92.fc14
kernel-2.6.35.13-92.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
Worked for me... thanks
*** Bug 712204 has been marked as a duplicate of this bug. ***