Kernel Bug Tracker – Bug 19112
220.127.116.11 and 18.104.22.168 regression: Acer notebook does not power off but shutdown only
Last modified: 2010-10-25 13:00:09 UTC
Created attachment 31532 [details]
Ubuntu waits any key press from me to power off notebook completely. I think shutdown is ok because hard disks powers off( only motherboard cooler is working).Notebook is Acer Aspire 7520G. Earlier it worked ok with the same configuration. All generic Ubuntu kernels are ok, preempt kernels are wrong beginning from 2.6.32-23. I tried 22.214.171.124 and .5 kernels and they are both wrong for me. I have also Winxp x64 installed and it is ok. There are no any wrong message in system log. ACPI is working ok. The system hangs and waits the key press after halt -f -p -i -d command started.
forgot to say - arch is amd64.
Is the Ubuntu's 2.6.32-23 a counterpart of 126.96.36.199 from kernel.org?
No, Ubuntu's 2.6.32-23 based on 188.8.131.52.
what is the latest upstream kernel that works?
184.108.40.206 worked ok. May be (no idea) 220.127.116.11 is ok too. I tested 2.6.35 kernels started from 18.104.22.168.
can you isolate which kernel between 22.214.171.124 and 126.96.36.199 causes the problem?
188.8.131.52 causes the problem for me. But the basic question is: why does it wait the key pressing from me at all? Does kernel code contain something like getch()?
Please say me where is this code and I will isolate this part for me.
184.108.40.206 works and 220.127.116.11 fails?
Okay, that is great, can you bisect which patch between those
stable releases introduced the problem?
The only one that jumps out at me is
"x86, apic: ack all pending irqs when crashed/on kexec"
so you could start by reverting that patch to see
if it caused it -- maybe we'll get lucky:-)
No, the kernel is not doing a getch(), but it is likely that there is
an issue with a timer not working and so that the interrupts of the
keyboard are causing the system to wake up and continue working...
Yes, I have found it powers off ok if hpet=disabled. So I'm forced to agree: it is timer problem. Also I have found that hpet problems is fixed (may be is not fixed but disguised) with 2.6.36-rc8. It is because the kernels from 2.6.32 to 2.6.35 have the problems with kde4 games. Any games (where timer is used) work in discontinuous manner (for example: ball twitches during its movement). Also the system powers off ok with 2.6.36-rc8 and hpet enabled. But I have found other strange issues with the kernels >= 2.6.35 (or may be it is xorg 1.9.0 + nvidia problem): mplayer using xv eats more cpu and any mouse movement in menu or toolbar is cause the interruptions of video or sound. I increased the latency of sound card (using setpci) and it seems the interruption of sound is discontinued but video is still slowest. Nvidia driver - 260.19.12.
I think this bug can be closed for now :)