https://bugzilla.novell.com/show_bug.cgi?id=579932
https://bugzilla.novell.com/show_bug.cgi?id=579932#c101
--- Comment #101 from Andreas Nordal 2012-03-13 01:10:58 UTC ---
Yes, processor.max_cstate=1 very evidently works for
kernel-desktop-3.1.9-1.4.1.x86_64 of openSUSE 12.1. With no workaround, this
kernel hangs when playing audio and resumes by itself mostly after a few
seconds (a 61.8s hang was observed today).
I can test more workarounds if you want, but for now, I want to tell you that
kernel-default-3.1.9-1.4.1.x86_64 of openSUSE 12.1 seems to need no workaround!
No idea why, but well done, openSUSE developers!
The -default kernel with no workaround:
* During >30min music playback, rt-benchmark found 7 hangs longer than 20ms,
the longest 48.55 ms. Either the hangs didn't affect mplayer, or I didn't hear
them.
* The 3 workarounds "processor.max_cstate=1", "nohz=off" and "nolapic_timer"
greatly impacted schedulability of rt-benchmark (for better or worse), but the
maximum hangtime was more consistent at 40-60 ms.
Whether the -default kernel is 100% sane is difficult for me to say based on
the above result, because the hangs are so short. A userspace program like
rt-benchmark cannot see the difference between actual kernel hangs and just
coarse scheduling. (I previously falsified the "nohz=off" workaround (comment
#59) based on similar subsecond hangs, which I am not feeling so confident
about.) As a more scientific method, I will try to provoke hangs with heavy
rt-benchmarking overnight, and see if my clock has lagged behind.
Below is an overview of workarounds from previous posts:
Workarounds not falsified (these are worth testing):
* processor.max_cstate=1
* nolapic_timer
* nohz=off highres=off
* hpet=disable highres=off (not tested, just out of curiousity)
* idle=nowait
Falsified workarounds:
* nohz=off (actually works well but falsified on thin reason)
* hpet=disable (same as nohz=off)
* noapic
* processor.max_cstate=2
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.