Bug 29992

Created attachment 49472 [details]
My .config without INTEL_IDLE

can't be relatred to bug 26502 because that failure
is specific to acpi_idle, and here you're running intel_idle.

can you revert the two intel_idle patches that were
applied to 2.6.37.stable and re-test?
(you can just grab the intel_idle.c from 2.6.37.0 and compile that)

also, please describe the machine model
and supply the output from dmesg

do any cmdline params work around the hang?
eg "nolapic_timer" or "hpet=disable" etc

It works with kernel 2.6.37.2 and intel_idle.c from 2.6.37.0.

I didn't forget to add intel_idle kernel option, make clean and recompile.

Created attachment 49882 [details]
My dmesg

Created attachment 49892 [details]
/proc/cpuinfo

I forget to add my motherboard: asus p7p55d le

The difference between what worked and what failed was these two patches:


ommit 0f212b87548cc4598fb7c77d92bfef23d5ee4d1a
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Mon Jan 24 08:00:01 2011 +0000

    fix a shutdown regression in intel_idle
    
    commit ec30f343d61391ab23705e50a525da1d55395780 upstream.


commit 0f076e96eae1e03f5fd988911c7062dee22e14a6
Author: Shaohua Li <shaohua.li@intel.com>
Date:   Mon Jan 10 09:38:12 2011 +0800

    intel_idle: open broadcast clock event
    
    commit 2a2d31c8dc6f1ebcf5eab1d93a0cb0fb4ed57c7c upstream.

BTW. does the upstream 2.6.38-rc kernel also fail?
Also, I assume the failing kernel works properly if you
boot with "intel_idle.max_cstate=0", yes?

> cpuidle: using governor ladder

# CONFIG_NO_HZ is not set

Does this problem go away with CONFIG_NO_HZ=y ?

Yes it go away with CONFIG_NO_HZ=y

I have no time today to try .38-rc kernel.
I'll try tomorrow.


Thanks


N.B: intel_idle.max_cstate=0 <---- Where I have to put that ?

That would go on the kernel commandline. (hitting e on the selected kernel in grub and inserting it there)

please try a .38-rc kernel.
does reverting the two commits mentioned in comment #7 fix the problem?

It's OK with the .38-rc7

To revert the two commits I use the intel_idle.c from 2.6.37.0 version with .37.2 kernel.

since .38-rc7 works, this means the intel-idle changes might not be the reason. we might need to backport something else related to timer to 2.6.37.
any chance you can try "nolapic_timer" or "hpet=disable"? this will help us to isolate the problem.

I am experiencing this issue with 2.6.37.1 & 2.6.37.2 as well

Hardware profile: http://www.smolts.org/client/show/pub_1a849a4e-cf37-4b09-92a6-304e1f8d9968

Downstream bug report: https://bugzilla.novell.com/show_bug.cgi?id=675161

Test with other params as per comment #13 in this report

pass only: intel_idle.max_cstate=0
result: System boots normally and behaves as expected with no further issues

pass only: nolapic_timer
result: hang/crash during boot as per this bug report

pass only: hpet=disable
result: system sometimes boots, but completely locks up soon after

De Ganseman Amaury,
please clarify comment #12.  Did un-modified 2.6.38-rc work,
or did you revert patches from it?  At this point 2.6.38 is released,
so please report if that, unmodified, works.  Also, I assume that
you are still building with CONFIG_NO_HZ=n, since that was the only
way to provoke the failure?

Graham, does this issue go away with CONFIG_NO_HZ=y for you also?

Graham, does reverting the two intel_idle patches make 2.6.37 work,
or make 2.6.38 work?

...Ping...

Please reply to questions above and re-open if still an issue
with a modern kernel.

No issues with newer kernel.