http://bugzilla.novell.com/show_bug.cgi?id=579932 http://bugzilla.novell.com/show_bug.cgi?id=579932#c2 --- Comment #2 from Elmar Stellnberger 2010-02-18 12:46:32 UTC --- Created an attachment (id=343185) --> (http://bugzilla.novell.com/attachment.cgi?id=343185) dmesgs after audio-hangs The behaviour has now been different than before the last reboot. Now the audio hangs started to vanish as soon as I move the mouse or press any key.

echo w > /proc/sysrq-trigger; dmesg >dmesg.X

-- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=579932 http://bugzilla.novell.com/show_bug.cgi?id=579932#c3 --- Comment #3 from Elmar Stellnberger 2010-03-09 11:36:51 UTC --- Still the same for the current 2.6.33-5.99.1.3899278-desktop kernel. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=579932 http://bugzilla.novell.com/show_bug.cgi?id=579932#c5 Elmar Stellnberger changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Major --- Comment #5 from Elmar Stellnberger 2010-03-13 16:48:19 UTC --- Still there with 2.6.33-5.99.11.63bda4e-desktop. Please have a look at this and assign an appropriate priority. That way the system can only be used for text editing and compiling not for music, video playback or any other multimedia apps. Definitely not enough for a contemporate OS! We did not have a stable kernel release for years by now (softirq 100% bug). Please concentrate your effort to get one, at last. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=579932 http://bugzilla.novell.com/show_bug.cgi?id=579932#c7 --- Comment #7 from Elmar Stellnberger 2010-07-10 10:09:22 UTC --- Why does it have to update at all?? A freshly installed program should not need any update. Just imagine a user who is offline and in need of mysql!! What a bad pitfall. Please look forward into integrating any necessary updates to the mysql-daemon right into the package. Moreover self-updates pose an additional security risk. -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=579932 http://bugzilla.novell.com/show_bug.cgi?id=579932#c9 --- Comment #9 from Jiri Slaby 2010-07-28 13:40:53 UTC --- (In reply to comment #8)

sh.. wrong place for Comment 7. Why does bugzilla always switch the current bug after a post?! This is a real annoyance!!

Turn it off in your bugzilla preferences... -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=579932 http://bugzilla.novell.com/show_bug.cgi?id=579932#c11 --- Comment #11 from Jiri Slaby 2010-07-28 13:49:09 UTC --- (In reply to comment #0)

After updating to kernel 2.6.33-rc7-2.99.14.0943949-desktop the audio and video playbck hangs often for quite a while although the CPU usage is very low.

BTW updating from what version? -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

http://bugzilla.novell.com/show_bug.cgi?id=579932 http://bugzilla.novell.com/show_bug.cgi?id=579932#c12 Elmar Stellnberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|estellnb@gmail.com | --- Comment #12 from Elmar Stellnberger 2010-07-30 17:58:32 UTC --- Tried with alsa-test.wav/GM and no scattering occurred (2.6.34-12.3 desktop). On the contrary it has been very tough with RC2(?) & RC1(2.6.34-9.3). I thereby hope that it had been resolved for GM. However more extensive testing will be required since the error has only occasionally occurred in the beginning (add. wanna sandbox my media player before I play possibly contaminated mp3s on a fresh installation.). Marking as resolved-worksform. Please remind me next week or so for the final test results. BTW updating from what version? Hmm, unfortunately I can`t tell you any more since that was too long in the past (has been some kernel of 11.2, later than the final release). -- Configure bugmail: http://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c14 Andreas Nordal changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED CC| |andreas_nordal_4@hotmail.co | |m Version|RC 2 |Final Resolution|WORKSFORME | Severity|Major |Critical --- Comment #14 from Andreas Nordal 2010-08-24 19:07:10 UTC --- Reopening because audio/video playback also hangs in the final version of OpenSuSE 11.3. In fact, my testing shows that _any_ real-time program _will_ eventually make the scheduler seem to hang if run long enough. The bug appears at least with kernels 2.6.34-12-desktop and 2.6.34-12-vanilla provided by OpenSuSE repos. I was unable to boot with 2.6.31-rc8-rt9-6-rt. These kernels have been untainted by proprietary drivers; I am using nouveau exclusively. I have not tested any release candidates, but this is at least a regression since 11.2. Specifically, in 11.2, the hang randomly occured during boot, shutdown and suspend to RAM (suspend to disk never worked for me), whereas in 11.3, the hang occurs when the computer is on. Once the computer hangs, it hangs forever, until I do one of the following: - press or release any key except the Fn key - move the mouse cursor - right/left-click with the touchpad - plug or unplug AC power - switch on/off the rf-killswitch (the WiFi button) Plugging or unplugging the ethernet cable did not have any effect. My computer was able to hang 9 hours without making any progress during the installation; it would probably still do so, hadn't I interrupted it. I have observed that the hang will eventually occur during: - playing video: Sounds like it hangs and resumes a hundred times per second, before it randomly stops resuming. Executing ´yes´ simultaneously makes it play smooth without hanging. - playing audio: The login sound of KDE is partially repeated infinitely (a symptom of http://en.wikipedia.org/wiki/Buffer_underrun#Multimedia_playback) - downloading: webbrowsing, using zypper, updating in the process of installation - blinking text in the terminal - blinking cursors in various programs - the screensaver IO bound or CPU bound tasks do not seem to trigger the hang. Only tasks that are frequently sleeping. I made a test program that repeatedly calls clock_nanosleep (alternatively sleep and usleep), like any real-time program does. Empirically, it seems that these function calls have a certain probability of hanging the kernel - short and frequent sleeps or many instances of the running program, and the kernel hangs sooner. When run as root, the program will succeed to acquire the highest priority with FIFO policy and lock its memory in RAM, but still hangs (perhaps less frequently). In other words: Since this program cannot meet its deadlines, nothing can! Conclusion: The scheduler does not work properly on my computer. My computer is a laptop (Multicom Compal IFL90+): Intel Core 2 Duo T8100 Nvidia GeForce 8600M GT Intel PRO/Wireless 4965 AGN Broadcom NetLink BCM5787M Gigabit Ethernet What else do you need to know? -- 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.

From kernel.org, I downloaded and compiled kernels 2.6.32.20 (which lacks Nouveau) and 2.6.35.3 without Nouveau. In both cases, the desktop activities noted above worked as they should (without needing to move the mouse like a maniac or execute ´yes´ in the background). However, the hang is still

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c16 --- Comment #16 from Andreas Nordal 2010-08-26 19:55:25 UTC --- The hang is triggered by audio/video/screensaver/cursorblinking/terminaltextblinking/webbrowsing only when using Nouveau!!! triggered by my program, rt-benchmark. Why is it possible to hang the kernel in the first place (or at least prevent real-time tasks from running)? As far as I understand, this question remains and must be the real bug! You don't even need to be root to trigger such a hang, and the hang affects even the highest priority tasks. Therefore, I leave the bug open as critical. There is not necessarily anything wrong with Nouveau. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Andreas Nordal changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Real-time programs and |Kernel stops waking |Nouveau causes kernel to |sleeping tasks when running |stop waking up sleeping |a sleeping task or Nouveau. |tasks until user interrupts |Resumes on user input. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c18 Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEEDINFO InfoProvider| |estellnb@gmail.com --- Comment #18 from Jiri Slaby 2010-08-31 10:06:32 UTC --- Could you try to boot with clocksource=jiffies kernel parameter? And then with nolapic_timer? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c20 --- Comment #20 from Jiri Slaby 2010-09-01 21:28:24 UTC --- (In reply to comment #19)

Good news! Quick testing of 2.6.35.3: - clocksource=jiffies _completely_ did the trick!!! - clocksource=nolapic_timer did not, although the hangs were less frequent.

nolapic_timer is a standalone parameter. Try without "clocksource=". What is you clocksource anyway (dmesg|grep clock should tell)? If it is tsc, you may also try clocksource=hpet to have high precision timers.

Specifically, with clocksource=jiffies: .. - On the downside, rt-benchmark was no longer schedulable if intervals were shorter than about 0.001 seconds.

Which is expected when HZ is set to 1000 HZ (jiffies are updated in this frequency). -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c22 --- Comment #22 from Jiri Slaby 2010-09-02 21:45:04 UTC --- (In reply to comment #21)

The unaffected 2.6.32.20 is of course impossible to hang, yet Powertop works flawless.

Actually what clock source is user there? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c24 --- Comment #24 from Andreas Nordal 2010-09-04 18:38:37 UTC --- The newest kernel, 2.6.35.4, is also affected. Its changelog lists 2 changes about "apic". Here is something I found in dmesg after booting 2.6.35.4 (the start of every line, which is "[ 0.000000] ", is omitted for brevity): ACPI: RSDP 00000000000f7b40 00024 (v02 Compal) ACPI: XSDT 000000007fed7c40 00094 (v01 Compal CRESTLNE 06040000 LTP 00000000) ACPI: FACP 000000007fedfbd2 000F4 (v03 INTEL CRESTLNE 06040000 ALAN 00000001) ACPI: DSDT 000000007fed9b51 0600D (v02 Compal CRESTLNE 06040000 INTL 20061109) ACPI: FACS 000000007fee2fc0 00040 ACPI: APIC 000000007fedfcc6 00068 (v01 INTEL CRESTLNE 06040000 LOHR 0000005A) ACPI: HPET 000000007fedfd2e 00038 (v01 Compal CRESTLNE 06040000 LOHR 0000005A) ACPI: MCFG 000000007fedfd66 0003C (v01 INTEL CRESTLNE 06040000 LOHR 0000005A) ACPI: TCPA 000000007fedfda2 00032 (v01 Intel CRESTLNE 06040000 LOHR 0000005A) ACPI: TMOR 000000007fedfdd4 00026 (v01 PTLTD 06040000 PTL 00000003) ACPI: SLIC 000000007fedfdfa 00176 (v01 Compal CRESTLNE 06040000 TBD 00000001) ACPI: APIC 000000007fedff70 00068 (v01 PTLTD ? APIC 06040000 LTP 00000000) ACPI: BOOT 000000007fedffd8 00028 (v01 PTLTD $SBFTBL$ 06040000 LTP 00000001) ACPI: SSDT 000000007fed9502 0064F (v01 SataRe SataPri 00001000 INTL 20050624) ACPI: SSDT 000000007fed8e70 00692 (v01 SataRe SataSec 00001000 INTL 20050624) ACPI: SSDT 000000007fed8260 0025F (v01 PmRef Cpu0Tst 00003000 INTL 20050624) ACPI: SSDT 000000007fed81ba 000A6 (v01 PmRef Cpu1Tst 00003000 INTL 20050624) ACPI: SSDT 000000007fed7cd4 004E6 (v01 PmRef CpuPm 00003000 INTL 20050624) ACPI: BIOS bug: multiple APIC/MADT found, using 2 ACPI: If "acpi_apic_instance=0" works better, notify linux-acpi@vger.kernel.org ACPI: Local APIC address 0xfee00000 Faking a node at 0000000000000000-000000007fed0000 Initmem setup node 0 0000000000000000-000000007fed0000 NODE_DATA [0000000001c531c0 - 0000000001c581bf] [ffffea0000000000-ffffea0001bfffff] PMD -> [ffff880002600000-ffff8800041fffff] on node 0 Zone PFN ranges: DMA 0x00000010 -> 0x00001000 DMA32 0x00001000 -> 0x00100000 Normal empty Movable zone start PFN for each node early_node_map[2] active PFN ranges 0: 0x00000010 -> 0x0000009f 0: 0x00000100 -> 0x0007fed0 On node 0 totalpages: 523871 DMA zone: 56 pages used for memmap DMA zone: 0 pages reserved DMA zone: 3927 pages, LIFO batch:0 DMA32 zone: 7108 pages used for memmap DMA32 zone: 512780 pages, LIFO batch:31 ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information ACPI: HPET id: 0x8086a201 base: 0xfed00000 Note the "BIOS bug", where it uses apic 2 and suggests 0. Normally, it uses 0 and suggests 2, but I booted with acpi_apic_instance=2 this time, which didn't work any better or worse. 2.6.35.3 also suggests 2, but i have not tried the suggestion there. I have a Phoenix BIOS. I just wonder how this bug could be overlooked. It has been in the kernel since around 2.6.33, is probably not specific to OpenSUSE, and it causes lousy desktop experience, to say the least. @Elmar: Do you see any hardware we have in common? @Jiri : Are kernel developers informed, or will they be? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c26 --- Comment #26 from Jiri Slaby 2010-09-10 09:08:18 UTC --- Well, there is an upstream thread which may explain this: http://lkml.org/lkml/2010/9/9/426 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c27 --- Comment #27 from Jiri Slaby 2010-09-10 09:22:11 UTC --- (In reply to comment #26)

Well, there is an upstream thread which may explain this: http://lkml.org/lkml/2010/9/9/426

Actually not quite. The patch is not in 2.6.34, it's only in 2.6.35. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c29 --- Comment #29 from Elmar Stellnberger 2010-09-16 16:00:41 UTC --- Too, bad. Can`t we backport and apply the patch to the 2.6.34-kernel? I have just had a kernel update, unfortunately not solving this. If something is as critical as this we should really push forward an update as soon as possible because otherwise we are going to lose users. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c31 --- Comment #31 from Andreas Nordal 2010-09-30 10:13:29 UTC ---

The patch is not in 2.6.34, it's only in 2.6.35. 2.6.35.7, which was released yesterday, is still broken.

@Jiri : Are kernel developers informed, or will they be? Sorry for my stupid question. As the changelog of 2.6.34.7 reveals, you must be a kernel developer.

-- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c33 --- Comment #33 from Andreas Nordal 2010-10-01 18:28:53 UTC --- Sorry, I am not using OpenSUSE anymore, and rpm2cpio was unable to extract kernel-source-vanilla-2.6.36-rc5.23.1.noarch.rpm. I will try 2.6.36-rc6 from kernel.org later. Thanks for the hint. Yes, OpenSUSE (temporarily) lost a user indirectly because of this bug. I had to abandon the ship after YaST silently decided to install the nvidia driver, at which point the running kernel already had that driver, only zypper didn't know, because it was an out-of-repo driver installation on my own out-of-repo kernel. Result: Xorg mysteriously damaged beyond repair. Solution: Gentoo respects my kernels. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c35 Andreas Nordal changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #385176|0 |1 is obsolete| | --- Comment #35 from Andreas Nordal 2010-10-01 20:02:55 UTC --- Created an attachment (id=392654) --> (http://bugzilla.novell.com/attachment.cgi?id=392654) improved rt-benchmark program The modified rt-benchmark used in my previous post. Makes it easier to log the intervals of hangtime for long periods. Changelog: * Only outputs when a deadline is missed. * Several deadline misses in a row => 1 line of output. * More informative output: time of last run. * New option added, to specify output file. When used, it will try to run as a daemon. Warning: Will run in foreground if unable to open the file. * Its output format resembles that of dmesg. Can be interleaved with dmesg by something like `rt-benchmark fmisses.txt; dmesg > dmesg.txt; sort -mnk 2 dmesg.txt misses.txt > interleaved.txt` -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c37 --- Comment #37 from Jiri Slaby 2010-10-04 17:29:32 UTC --- (In reply to comment #36)

...

I will try 2.6.36-rc6 from kernel.org later. No luck. Same shit.

Ok. I raised the problem upstream and they need: Can we get dmesg, output of proc/timer_list and output of /proc/acpi/processor/CPU0/power for a working and a non working kernel please ? I think a working kernel was 2.6.32, wasn't it? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c39 --- Comment #39 from Jiri Slaby 2010-10-04 21:33:38 UTC --- (In reply to comment #38)

3 | bad | hang 229s under heavy rt-benchmarking. No hang for 30min | | idling. No boot/shutdown hang reproducible.

I think rt-benchmark could be a different issue. I would mark this as good. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|andreas_nordal_4@hotmail.co | |m | -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |andreas_nordal_4@hotmail.co | |m -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c43 Andreas Nordal changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|NORESPONSE | --- Comment #43 from Andreas Nordal 2010-12-17 16:40:55 UTC --- Sorry for taking so long, but I had some exams to finish. Went testing with/without "nolapic_timer" (an other workaround, using it right now), hope it doesn't matter. Output of cat /proc/acpi/processor/CPU0/power -With nolapic_timer: active state: C0 max_cstate: C8 maximum allowed latency: 2000000000 usec states: C1: type[C1] promotion[--] demotion[--] latency[001] usage[00000000] duration[00000000000000000000] C2: type[C2] promotion[--] demotion[--] latency[001] usage[00000000] duration[00000000000000000000] C3: type[C3] promotion[--] demotion[--] latency[162] usage[00000000] duration[00000000000000000000] -Without nolapic_timer: active state: C0 max_cstate: C8 maximum allowed latency: 2000000000 usec states: C1: type[C1] promotion[--] demotion[--] latency[001] usage[00091494] duration[00000000000000000000] C2: type[C2] promotion[--] demotion[--] latency[001] usage[12439642] duration[00000000007279143969] C3: type[C3] promotion[--] demotion[--] latency[162] usage[01895548] duration[00000000092318699150] I am using the default kernel in fedora 14, "kernel-2.6.35.9-64.fc14.x86_64". The above output was collected after some time of light rt-benchmarking while doing a little webbrowsing and testing audio and video playback. In the latter case, I actually watched a 162 minutes long film (!). This kernel impresses me. Without nolapic_timer, it probably hangs just as frequent as 2.6.35.7, but the longest hang (recorded by rt-benchmark) was less than 4 seconds, which explains how I managed to watch a movie. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c45 --- Comment #45 from Nik Swiridow 2010-12-18 08:27:30 UTC --- It seems that with "nolapic_timer" your processor always runs in C0 state. So it is not a good solution for laptops (temperature in idle will be high). Probably you better try the kernel boot option "acpi_skip_timer_override"? If it will help, please, paste the output of grep . -r /sys/devices/system/cpu/cpu0/cpuidle/ About the BIOS update, please read carefully http://lddubeau.com/avaktavyam/linux-on-a-compal-ifl90 (and all those comments too) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Jiri Slaby changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |ASSIGNED -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c48 --- Comment #48 from Andreas Nordal 2011-01-16 15:04:06 UTC --- My computer was ordered march 25 2008. There is a newer BIOS at http://ftp.compal.com/asp/driver_dnd/e_download.asp?M_path=/Download/NB/JFL9..., released august 4 2008. If I understand the included changelogs right, the 3 only changes relevant to JFL models concern "warm boot" and communication with "thermal" sensor/chip, the newest of which predates my computer by 102 days. The 2 only updates made later than 2007 (concerning IFT and IFL models) are labeled "Fix ICH8M B2 S3 resume failure" and "Update UCODE for Merom CPU". The first sounds like a suspend-to-RAM issue I don't have. Secondly, my CPU is a Penryn T8100, not a Merom. Unless my current BIOS is ancient, I doubt this slightly newer one will have any effect on my computer, let alone fix hpet (which it doesn't mention). I will ask Multicom just to be sure. I don't want to invest the time and risk for no hope. I'm waiting for coreboot ;) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c50 --- Comment #50 from Andreas Nordal 2011-01-28 15:11:55 UTC --- It was not hard to tell that "processor.max_cstate=1" worked and "processor.max_cstate=2" did not. Below is the output of "grep . -r /sys/devices/system/cpu/cpu0/cpuidle/" under the various kernel commands: With nolapic_timer: /sys/devices/system/cpu/cpu0/cpuidle/state0/name:C0 /sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE /sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0 /sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295 /sys/devices/system/cpu/cpu0/cpuidle/state0/usage:221938 /sys/devices/system/cpu/cpu0/cpuidle/state0/time:538117852 /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1 /sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI FFH INTEL MWAIT 0x0 /sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state1/power:1000 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage:0 /sys/devices/system/cpu/cpu0/cpuidle/state1/time:0 /sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2 /sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI FFH INTEL MWAIT 0x10 /sys/devices/system/cpu/cpu0/cpuidle/state2/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state2/power:500 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage:0 /sys/devices/system/cpu/cpu0/cpuidle/state2/time:0 /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3 /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH INTEL MWAIT 0x50 /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:162 /sys/devices/system/cpu/cpu0/cpuidle/state3/power:100 /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:0 /sys/devices/system/cpu/cpu0/cpuidle/state3/time:0 With processor.max_cstate=1: /sys/devices/system/cpu/cpu0/cpuidle/: No such file or directory With processor.max_cstate=2: /sys/devices/system/cpu/cpu0/cpuidle/state0/name:C0 /sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE /sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0 /sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295 /sys/devices/system/cpu/cpu0/cpuidle/state0/usage:114 /sys/devices/system/cpu/cpu0/cpuidle/state0/time:52416 /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1 /sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI FFH INTEL MWAIT 0x0 /sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state1/power:1000 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage:9212 /sys/devices/system/cpu/cpu0/cpuidle/state1/time:598101 /sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2 /sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI FFH INTEL MWAIT 0x10 /sys/devices/system/cpu/cpu0/cpuidle/state2/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state2/power:500 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage:398553 /sys/devices/system/cpu/cpu0/cpuidle/state2/time:195062754 With no workaround: /sys/devices/system/cpu/cpu0/cpuidle/state0/name:C0 /sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE /sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0 /sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295 /sys/devices/system/cpu/cpu0/cpuidle/state0/usage:4857 /sys/devices/system/cpu/cpu0/cpuidle/state0/time:83419 /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1 /sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI FFH INTEL MWAIT 0x0 /sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state1/power:1000 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage:78437 /sys/devices/system/cpu/cpu0/cpuidle/state1/time:5581403 /sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2 /sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI FFH INTEL MWAIT 0x10 /sys/devices/system/cpu/cpu0/cpuidle/state2/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state2/power:500 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage:1320758 /sys/devices/system/cpu/cpu0/cpuidle/state2/time:262335334 /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3 /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH INTEL MWAIT 0x50 /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:162 /sys/devices/system/cpu/cpu0/cpuidle/state3/power:100 /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:68278 /sys/devices/system/cpu/cpu0/cpuidle/state3/time:114859261 While testing this, I discovered a side effect of nolapic_timer that has bothered me for a while: Playing a sound has a program-specific probability of putting the soundcard in what I would describe as "spark gap modulation mode", which sounds freakin' awful. Restarting X always resets to normal mode. There are at least 2 severities of spark gap modulation, depending on which, normal mode can also be restored by playing a sound in Amarok using the Xine backend. Playing a sound in Audacity has a 100% probability of invoking spark gap modulation. BIOS news: My bios is version 1.16. The newest is 1.18. The changelogs list only 2 changes from 1.16 (se my previous post or below). Multicom says: * The changes listed for IFT also applies to JFT models like mine. * Bios upgrading is done at my own risk (may brick the motherboard). * Upgrading is recommended (without indication to whether it helps). I followed the guide at http://lddubeau.com/avaktavyam/linux-on-a-compal-ifl90, but FreeDOS failed to install itself to my 1GB USB stick for no apparent reason. Since I don't see how "Fix ICH8M B2 S3 resume failure" or "Update UCODE for Merom CPU" is going to fix hpet, I won't try any harder. Also, I depend on this computer, so I'm afraid my merge window is closed until summer. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c52 --- Comment #52 from Nik Swiridow 2011-02-12 18:15:16 UTC --- There are many other options that you can try: "noapic", "hpet=disable", "nohz=off", "nolapic". But it seems all of them have side effects (high temperature in idle, broken sound, no SMP). So, my advise for you: -inform the Kernel Team http://bugzilla.kernel.org/ about your problem (broken lapic timer in C2 state?). -use any distro with a kernel older than 2.6.20 until the bug will be fixed. I'm almost sure that "OpenSUSE 10.2" will work fine on your laptop... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c54 --- Comment #54 from Elmar Stellnberger 2011-02-12 18:30:29 UTC --- No, it is actually as bad as this! I know that I have tested both os10.3 and 10.2 (somewhere around 2008 if I am right) - and I know exactly on from when this problem has started to occur. The problem about os10.2 is that it has no esata support and thus can not be used on notebooks as customary nowadays. -- 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.

Which is the last "good" kernel then? I remember babysitting Opensuse 10.2 during boot/shutdown. That was not a

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c56 --- Comment #56 from Andreas Nordal 2011-02-13 19:05:40 UTC --- problem with 11.1. However, I have a vague memory of a lagging clock that might be older, I'm not sure. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c58 --- Comment #58 from Elmar Stellnberger 2011-02-15 21:52:47 UTC --- Well. As it was observed with 2.6.33-rc7-2.99.14.0943949-desktop first it needs having been an update kernel for openSUSE 11.2 (kernel-2.6.31.5-0.1.1) from ftp://ftp.suse.com/pub/projects/kernel/kotd/master because 11.3 already has 2.6.34. Andreas, you are consequently definitely right that the audio hangs started not before 2.6.31 (Sorry for the comment before upwards; I have had perturbated (resp. confounded) it with another bug). When bisecting start rather more near 2.6.33 because I regularely kept updating the kernel these times so that the leap won`t be as far as back to 2.6.31 (as perhaps back to 2.6.33-rc6). -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c60 --- Comment #60 from Nik Swiridow 2011-03-02 14:44:40 UTC ---

* Could these messages (from the bottom of dmesg) be indicative of this bug, or is it just me?: [ 133.022562] CE: hpet increased min_delta_ns to 7500 nsec

It means that the hpet timer is unstable. With "nolapic" you will probably have only one CPU. Another possible kernel option: "nmi_watchdog=1" "nmi_watchdog=2" And I still wonder if there are any good working old kernels? "OS 10.2" Live-DVD is available: http://ftp.hosteurope.de/mirror/ftp.opensuse.org/discontinued/10.2/iso/dvd/o... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c61 --- Comment #61 from Andreas Nordal 2011-03-12 23:44:19 UTC --- Oh yeah! The 2.6.18.2-34-default kernel of the suggested OpenSUSE 10.2 live-DVD is good. rt-benchmark missed only 12 deadlines of 0.01s in 4 hours, and dmesg says "Using HPET for base-timer". Note that this is 32-bit, for a change. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c63 --- Comment #63 from Nik Swiridow 2011-03-16 07:22:39 UTC --- Some other old Live CD: http://old-releases.ubuntu.com/releases/edgy/ http://old-releases.ubuntu.com/releases/feisty/ http://old-releases.ubuntu.com/releases/gutsy/ -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c65 --- Comment #65 from Nik Swiridow 2011-03-20 08:34:30 UTC ---

grep: /sys/devices/system/cpu/cpu0/cpuidle: No such file or directory #Note: The only file in cpu0 directory is cpufreq

Please use "cat /proc/acpi/processor/CPU0/power" instead. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c67 --- Comment #67 from Andreas Nordal 2011-03-28 17:41:41 UTC --- The problem is not 64-bit specific. The 32-bit version of Kubuntu 10.10 running as live-CD hangs willingly. I just measured a 115 second hang, and the clock is lagging. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c69 --- Comment #69 from Andreas Nordal 2011-03-29 15:09:11 UTC --- uname -a Linux Microknoppix 2.6.28 #4 SMP PREEMPT Sat Jan 3 09:16:41 CET 2009 i686 GNU/Linux dmesg | grep -i clocksource [ 154.834092] Clocksource tsc unstable (delta = -68586322 ns) I am using some version of Adriane Knoppix (can't read on the DVD when it is inside the computer). rt-benchmark is also unhappy: [ 1112.117092922] rt-benchmark: Not scheduled since 1064.624037507 Audio playback is smooth, though. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c71 --- Comment #71 from Elmar Stellnberger 2011-03-29 21:40:42 UTC --- Comment 68: Andreas, there are wonderful console audio players: I do personally prefer cmus (:a ~/Musik, press 5 for directory view, 4 for playlist, Return/[E]nqueue on titles and [C] to continue playing the 4list) while; use +- in cmus or alsamixer for noise level ctrl. mp3blaster would be another option. Your Xorg problem may be related to: https://bugs.freedesktop.org/show_bug.cgi?id=32393 ? Besides this there are usually plenty of options to get Xorg to work: use different drivers: radeon, radeonhd, fglrx (proprietary) for ATI cards and nouveau, nv(elder cards), nvidiagfxNN (NN~age of card,: proprietary via ), see also: build.os.org/search. vesafb should always work since vesa refers to the VESA BIOS (a standard); Xorg -configure/ editing /etc/X11/xorg.conf may be of help. Most times just disabling 3D accelaration by 'Option "DRI" "off"' in the Device section will help; afaik there was also an X project using framebuffers different from Xorg. (It is really a pity that SaX2 is no more supported; I believe it would really help many users: bug 539004. I still have my xorg.confs backuped from this time.) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c73 --- Comment #73 from Andreas Nordal 2011-03-30 00:25:53 UTC --- Comment 69: It was Knoppix 6, a fine DVD included with the "Linux Format" magazine, april 2009. It hung during shutdown too (not 100% sure). Now, I'm trying the slightly older Ubuntu 8.10 32bit. Behaves exactly the same: Linux ubuntu 2.6.27-7-generic #1 SMP Fri Oct 24 06:42:44 UTC 2008 i686 GNU/Linux [ 3.000235] Clocksource tsc unstable (delta = -153532416 ns) [ 4166.800360203] rt-benchmark: Not scheduled since 4081.927005633 Audio playback is smooth (as expected: audio susceptibility came later). Comment 71: Elmar, thanks for the tips. But I have my doubts cmus could have saved me with that hopelessly old Ubuntu 6.10, or that your mentioned Xorg bug is sufficiently old to be applicable. However with OpenSUSE 11.3, my computer sometimes suddenly ignored all user input (no kernel panic). The proprietary Nvidia driver solved that for me. I'm not really after testing audio anymore. What concerns me is that somewhere between kernel 2.6.18 and 2.6.27, something created the very ability to hang for unbounded time. At least on my computer. I hereby ask for help to verify this. It would be very helpful if you could give rt-benchmark a try! Also, there are people out there on similar bug reports, mostly having hangs during boot. I honestly believe they should try: sudo rt-benchmark t0.01 d0.01 and track down the unbounded hang. It would also be interesting to know whether they have Phoenix BIOSes. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c75 --- Comment #75 from Andreas Nordal 2011-03-30 23:31:04 UTC ---

We need to be very careful in never intermangling different issues when reporting bugs. That worries me too. Sorry for extending the scope of your bugreport, but I suspect your Scaleo has a more general problem, and I need your verification.

Nonetheless I do continue to regard audio/video playback as the ideal test case for this hpet/apic related issue. An ideal testcase (or rather general) is what I tried to make with rt-benchmark. As written in my first post, it was not only about audio/video for me.

We must not leave things like this That's the spirit! Sorry for letting that one go. Guess I should contact you if I see anything suspicious;)

-- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c77 --- Comment #77 from Andreas Nordal 2011-04-14 21:54:18 UTC --- Created an attachment (id=425046) --> (http://bugzilla.novell.com/attachment.cgi?id=425046) terminal sessions with Ubuntu 7.04 and Ubuntu 7.10 Ubuntu 7.04 and 7.10 are also good. Their kernels are 2.6.20 and 2.6.22. Terminal sessions show that CPU states C2 and C3 are in use. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c79 Andreas Nordal changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #425046|0 |1 is obsolete| | --- Comment #79 from Andreas Nordal 2011-04-16 16:10:48 UTC --- Created an attachment (id=425274) --> (http://bugzilla.novell.com/attachment.cgi?id=425274) terminal sessions with 3 good and 3 bad kernels Strange 1: Ubuntu 7.10 i686 is bad. (did not test 7.04 i686) Strange 2: While nohz=off worked for Ubuntu 8.10 i686, it did not seem to affect Ubuntu 7.10 i686 at all. The longest hang with 8.10 was 178.9 seconds. The longest hang with 7.10 was 1.987 seconds. This is because 7.10 autoresumes (typically within 1s). In case anyone wonders, my criterion for good/bad is whether rt-benchmark running with normal (dynamic) priority affects schedulability of that other rt-benchmark with top (real-time) priority. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c81 --- Comment #81 from Andreas Nordal 2011-04-20 22:58:38 UTC --- Created an attachment (id=426001) --> (http://bugzilla.novell.com/attachment.cgi?id=426001) /boot/config* for ubuntu 7.10, 32 and 64 bit The whole config files. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c83 --- Comment #83 from Andreas Nordal 2011-04-24 16:48:43 UTC --- Created an attachment (id=426330) --> (http://bugzilla.novell.com/attachment.cgi?id=426330) terminal sessions with Ubuntu 7.10 & OS 11.4, using highres=off nohz=off With "highres=off nohz=off", 32-bit Ubuntu 7.10 and 64-bit OpenSuse 11.4 are good. I didn't bring Ubuntu 8.10 on easter holiday. I am thrilled by your dyn-ticks discovery, Nik. You must be on the right track, because the addition of highres=off helped for Ubuntu 7.10 (remember that nohz=off alone did not). I assume this was the answer you needed, so that Ubuntu 8.10 is not of crucial importance now. I assume you want the usual terminal sessions. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c85 --- Comment #85 from Nik Swiridow 2011-04-25 17:50:32 UTC --- I've seen your logs, Andreas. Ubuntu 7.10 with "highres=off nohz=off" is OK. But OpenSuse 11.4 is still not entering in C2/C3 states. However, you can build a custom kernel for OpenSuse 11.3/11.4 with the following features: CONFIG_HZ_250=y CONFIG_HZ=250 CONFIG_HIGH_RES_TIMERS=n CONFIG_NO_HZ=n (and don't forget to set CONFIG_DEBUG_INFO=n to make it smaller.) This might help... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c87 --- Comment #87 from Andreas Nordal 2011-04-30 19:50:34 UTC --- In OpenSuse 11.4: I zypper-installed kernel-source, took the .config from /proc/config.gz and did the necessary modifications (nothing else) using make nconfig, so that: # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_HZ_250=y CONFIG_HZ=250 # CONFIG_DEBUG_INFO is not set I forgot to make oldconfig, but hey, it compiled. Installed it according to README.SUSE. I am now running 2.6.37.6-1.2-desktop instead of 2.6.37.1-1.2-desktop. This config is "good". I can not hang the kernel with rt-benchmark. Why this is different from booting with "highres=off nohz=off" is beyond me, but I did get some surprises: * No sound. Tried mplayer with alsa, oss, pulse. * Xorg failed to start, not only because of the disappearance of the proprietary nvidia kernel module, but I had to chmod 4755 /usr/bin/Xorg. * Rt-benchmark succeeds to set scheduling parameters. This had been a problem unique to OpenSuse 11.4. * Powertop works flawlessly. (shouldn't it require CONFIG_NOHZ to be enabled?) * The mouse pointer disappeared while writing this. The "Commit" button is therefore hard to hit. Sorry for the long post. You are probably wondering whether C2-C3 states are used. I think they are: Excerpt from powertop: C1 mwait 0,0ms ( 0,0%) C2 mwait 1,2ms ( 6,3%) C6 mwait 1,9ms (89,4%) grep . -r /sys/devices/system/cpu/cpu0/cpuidle/ /sys/devices/system/cpu/cpu0/cpuidle/state0/name:POLL /sys/devices/system/cpu/cpu0/cpuidle/state0/desc:CPUIDLE CORE POLL IDLE /sys/devices/system/cpu/cpu0/cpuidle/state0/latency:0 /sys/devices/system/cpu/cpu0/cpuidle/state0/power:4294967295 /sys/devices/system/cpu/cpu0/cpuidle/state0/usage:0 /sys/devices/system/cpu/cpu0/cpuidle/state0/time:0 /sys/devices/system/cpu/cpu0/cpuidle/state1/name:C1 /sys/devices/system/cpu/cpu0/cpuidle/state1/desc:ACPI FFH INTEL MWAIT 0x0 /sys/devices/system/cpu/cpu0/cpuidle/state1/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state1/power:4294967294 /sys/devices/system/cpu/cpu0/cpuidle/state1/usage:6099 /sys/devices/system/cpu/cpu0/cpuidle/state1/time:5092863 /sys/devices/system/cpu/cpu0/cpuidle/state2/name:C2 /sys/devices/system/cpu/cpu0/cpuidle/state2/desc:ACPI FFH INTEL MWAIT 0x10 /sys/devices/system/cpu/cpu0/cpuidle/state2/latency:1 /sys/devices/system/cpu/cpu0/cpuidle/state2/power:4294967293 /sys/devices/system/cpu/cpu0/cpuidle/state2/usage:297998 /sys/devices/system/cpu/cpu0/cpuidle/state2/time:489357083 /sys/devices/system/cpu/cpu0/cpuidle/state3/name:C3 /sys/devices/system/cpu/cpu0/cpuidle/state3/desc:ACPI FFH INTEL MWAIT 0x50 /sys/devices/system/cpu/cpu0/cpuidle/state3/latency:162 /sys/devices/system/cpu/cpu0/cpuidle/state3/power:4294967292 /sys/devices/system/cpu/cpu0/cpuidle/state3/usage:4559404 /sys/devices/system/cpu/cpu0/cpuidle/state3/time:10327850075 Small correction to my previous post: It should of course be "258ms", not "25Bms". I used tesseract to convert the screenshot taken by my phone camera into text. I also tried biosbits on two desktop computers, both with Intel processors (Pentium 4 and Pentium D). The Pentium D failed both tests very similarly (with 4 MSR inconsistencies). The uniprocessor Pentium 4 did not have MSR inconsistencies and only marginally failed the SMI test with a latency of 191µs. Maybe it is difficult to pass these tests... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c89 --- Comment #89 from Nik Swiridow 2011-05-01 15:05:25 UTC ---

All works fine now

Okay. I had intended to give you a link with more simple instruction :) http://www.howtoforge.com/kernel_compilation_suse_p2 (Page 1 is a bit obsolete, but overall it is a very good guide)

but I have a feeling that the battery is draining faster than normal.

Have you reinstalled the proprietary Nvidia driver for the new kernel? Please check all your power management settings (Display, Video Card, Processor). NOHZ=off really can slightly reduce powersaving (especially when HZ=1000). But on the other hand the processor uses C2/C6 states now. So, more testing needed (CPU temperature in idle etc.)

Maybe it is difficult to pass these tests...

Maybe. Though SMI latency = 549us is quite high. Anyway, only vendor can fix it... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c91 --- Comment #91 from Elmar Stellnberger 2011-05-03 20:11:24 UTC --- Still the same for kernel 2.6.39-0.0.71.da138d8.x86_64 (without clocksource=jiffies). Music playback hangs almost instantaneously. When running the rt-benchmark program it outputs a new timestamp as soon as I move the mouse upon a thereby finished hang: [ 394.438843543] rt-benchmark started: interval=1.000000000 deadline=1.000000000 [ 394.438843543] rt-benchmark started: interval=1.000000000 deadline=1.000000000 [ 444.585252963] rt-benchmark: Not scheduled since 401.438843543 [ 492.847545509] rt-benchmark: Not scheduled since 468.438843543 [ 544.793453990] rt-benchmark: Not scheduled since 537.438843543 [ 559.105284199] rt-benchmark: Not scheduled since 554.438843543 [ 562.193381848] rt-benchmark: Not scheduled since 560.438843543 [ 566.305279335] rt-benchmark: Not scheduled since 563.438843543 [ 569.033344164] rt-benchmark: Not scheduled since 567.438843543 [ 576.857325251] rt-benchmark: Not scheduled since 573.438843543 [ 580.409271777] rt-benchmark: Not scheduled since 578.438843543 [ 582.921271415] rt-benchmark: Not scheduled since 581.438843543 [ 586.465299324] rt-benchmark: Not scheduled since 583.438843543 [ 636.592390802] rt-benchmark: Not scheduled since 616.438843543 [ 700.595669857] rt-benchmark: Not scheduled since 641.438843543 [ 764.597500676] rt-benchmark: Not scheduled since 703.438843543 [ 827.771259993] rt-benchmark: Not scheduled since 766.438843543 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Andreas Nordal changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Kernel stops waking |NOHZ hangs with Phoenix |sleeping tasks when running |BIOS. Triggered by |a sleeping task. Resumes on |short-sleeping tasks. Needs |user input. Workaround: |interrupt from peripheral |clocksource=jiffies |device to resume -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c94 --- Comment #94 from Nik Swiridow 2011-06-12 15:14:15 UTC --- Andreas, are you not satisfied with your custom kernel? And what does intel_idle say about your processor? dmesg | grep "intel_idle" "The intel_idle is a cpuidle driver that loads on specific Intel processors in lieu of the legacy ACPI processor_idle driver. The intent is to make Linux more efficient on these processors, as intel_idle knows more than ACPI, as well as make Linux more immune to ACPI BIOS bugs." -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c96 --- Comment #96 from Andreas Nordal 2011-07-10 15:20:30 UTC --- The problem can not alone be caused by SMI latency. I'm borrowing a Dell Latitude E6500 for a summer internship. It is probably a little over a year old. It runs OpenSuse 11.4 flawlessly and looks sane in rt-benchmark. However, it failed all tests that biosbits had to offer, in particular, its maximum SMI latency was consistently ~8 times higher than my previous record! --- Testing SMI latency... Warning: touching the keyboard can affect the results of this test. Starting pass #1. Calibrating the TSC. Starting pass #2. Wait here, I will be back in 15 seconds. 0 < t <= 1us; average = 80ns; count = 186281344 Times between first few observations: 116ns 113ns 101ns 90ns 90ns 100us < t <= 1ms; average = 331us; count = 31 Times between first few observations: 824ms 200ms 791ms 234ms 757ms 1ms < t <= 10ms; average = 3227us; count = 2 Times between first few observations: 10ms Summary of impact: observed maximum latency = 4437us SMI latency < 150us to minimize risk of OS timeouts FAIL Risk of OS timeouts exists with this observed latency. Summary: 0 passed, 1 failed Hit the Escape key to exit this test (automatically exits after 30 seconds). Press any key to continue... --- Running MSR consistency test suite... (MSR 0x40 consistent): FAIL (2 different values) 1 CPU 0x00000000dcf9afae: 0x0 1 CPU 0x00000000dcf9aae7: 0x1 (MSR 0x14e consistent): FAIL (2 different values) 1 CPU 0x0000000000882000: 0x0 1 CPU 0x0000000048004040: 0x1 (MSR 0x1c9 consistent): FAIL (2 different values) 1 CPU 0x0000000000000001: 0x0 1 CPU 0x0000000000000003: 0x1 (HBR 8x4B2 consistent): FAIL (2 different values) 1 CPU 0x00000000dd7ef2e8: 0x0 1 CPU 0x00000000dd7ef000: 0x1 Summary: 4816 passed, 4 failed Press any key to continue... --- Btw, I haven't given up updating my bios. I will try the method suggested by Multicom, which requires Windows 98 (!) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c98 --- Comment #98 from Nik Swiridow 2011-12-03 14:28:32 UTC --- Is this bug still present in OpenSUSE 12.1 ? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Jeff Mahoney changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW Component|Kernel |Kernel AssignedTo|kernel-maintainers@forge.pr |rjw@suse.com |ovo.novell.com | Product|openSUSE 11.3 |openSUSE 12.1 OS/Version|openSUSE 11.3 |openSUSE 12.1 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Rafael Wysocki changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO InfoProvider| |estellnb@gmail.com Severity|Critical |Normal -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c102 --- Comment #102 from Andreas Nordal 2012-03-13 17:44:34 UTC --- Created an attachment (id=481244) --> (http://bugzilla.novell.com/attachment.cgi?id=481244) deadline misses >50ms with kernel-default-3.1.9-1.4.1.x86_64 The result of 10 hours of rt-benchmarking kernel-default-3.1.9-1.4.1.x86_64 with no workaround: * Several 1 second hangs! * The average of 6 clock comparisons indicate a clock lag of 0.08s, but this was very inaccurate due to network latency. Without checking, it is probably not statistically significant. I don't think my clock lagged at all. My clock can clearly not have lagged the equivalent of all the hangtime, which I suspected was a symptom of this bug. So if >1s scheduling latency is normal, we have a new (!) "good" kernel (although not impressive). I think we should look at the difference between the -default and -desktop kernels, and try to explain what makes only the -default one "good"/predictable. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c103 Rafael Wysocki changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEEDINFO InfoProvider| |estellnb@gmail.com --- Comment #103 from Rafael Wysocki 2012-03-13 22:48:22 UTC --- We will. :-) Please test the idle=nomwait workaround on the desktop kernel in the meantime. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c105 --- Comment #105 from Andreas Nordal 2012-03-14 14:48:55 UTC --- idle=nomwait didn't work. As with no workaround, it looks very promising for a couple of minutes (rt-benchmark schedulable below 1ms), before suddenly hanging ~60s (59.2s in this test). I'm doubting my own methods again: It seems, the behavioral difference between -desktop and -default, is that -desktop likes to resume after ~60s, while -default likes to resume after ~1s. In other words, they both hang, and none is "good". For this hypothesis to be true, clock lag is no longer a symptom (might be verified for -desktop too). This bug was soo much easier to test before, when kernels hung indefinately, and the clock lagged. There isn't a watchdog barking every minute/second? Oh, one accidental difference I have introduced: Since comment #101, -default was tested with X and the Nvidia driver. Excuse: -default is my workhorse kernel, and X refuses to work on other kernels because xorg.conf is in the way and Nouveau is disabled (I cannot have Nvidia installed (manually, see bug 743007) on both kernels, or have separate configuration files for each kernel, can I?). -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c107 Andreas Nordal changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |ASSIGNED InfoProvider|estellnb@gmail.com | --- Comment #107 from Andreas Nordal 2012-03-14 22:48:48 UTC --- Created an attachment (id=481494) --> (http://bugzilla.novell.com/attachment.cgi?id=481494) bootcharts for -desktop and -default 3.1.9 kernels with/without nolapic Approximate boot times in seconds according to the bootcharts: default nolapic 48.5 default no workaround 43.75 desktop nolapic 40.4 desktop no workaround 42.3 X was only working in the -default kernel. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c109 --- Comment #109 from Nik Swiridow 2012-03-16 18:27:16 UTC --- Patch fixing c-state transitions when NOHZ=off : https://lkml.org/lkml/2012/1/17/321 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c111 --- Comment #111 from Andreas Nordal 2012-03-19 10:51:58 UTC ---

I'm not sure we can do much about that in the kernel, unless there is at least one NOHZ kernel that worked for you on that machine. Do you have such a kernel by chance? No, it looks like the last working kernel predates NOHZ (comment #82).

The problem at hand is that NOHZ=on doesn't work, though, isn't it? Yes, but Nik found that NOHZ=off had the side effect of disabling C2/C3 states (comment #85). The nohz= kernel option is therefore a choice between two evils.

-- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c113 Rafael Wysocki changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |RESOLVED InfoProvider|andreas_nordal_4@hotmail.co | |m | Resolution| |WONTFIX --- Comment #113 from Rafael Wysocki 2012-03-28 22:59:45 UTC --- As I said, I think this is a hardware/BIOS issue and I don't think we can work around it completely without disabling the higher C states. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c115 --- Comment #115 from Elmar Stellnberger 2012-04-28 20:13:28 UTC --- Isn`t there any workaround like disabling C2 state temporarily? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c117 --- Comment #117 from Elmar Stellnberger 2012-04-30 08:56:34 UTC --- C2 is the 2nd idle state. The external I/O Controller Hub blocks interrupts to the processor. And so on with C3, C4, etc. I'll discuss this further down in this paper. By the way, there is nothing preventing the OS from busy waiting in its idle state, and thus keeping the processor in C0, as did older operating systems. http://software.intel.com/en-us/blogs/2008/03/27/update-c-states-c-states-an... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c119 --- Comment #119 from Jeff Mahoney 2012-05-01 17:03:31 EDT --- Rafael, what's the upstream fix? Isn't processor.max_cstate=1 just a workaround? -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c121 --- Comment #121 from Elmar Stellnberger 2012-05-02 13:18:56 UTC --- If this is true a processor.max_wait_cstate=1 should apply for all Core 2 Duo systems. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c123 --- Comment #123 from Rafael Wysocki 2012-05-02 21:32:15 UTC --- (In reply to comment #121)

If this is true a processor.max_wait_cstate=1 should apply for all Core 2 Duo systems.

This definitely is not the case. It usually isn't necessary to use processor.max_cstate=1 on those systems. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c125 --- Comment #125 from Elmar Stellnberger 2012-05-19 07:08:25 UTC --- FS Amilo Xi 2550 (Fujistu Siemens) Intel Core 2 Duo T9300 Phoenix BIOS v1.15 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c127 --- Comment #127 from Elmar Stellnberger 2013-02-11 15:32:59 UTC --- No, it definitely does not work with openSUSE 12.3 RC1 kernel 3.7.6-1.2-desktop. Music playback still hangs from time to time when there is a low system workload (simply do nothing and wait). Please test with caution! -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c129 --- Comment #129 from Nik Swiridow 2013-02-13 18:00:07 UTC --- (In reply to comment #127)

Please test with caution!

I've posted Bandini's (another happy owner of Amilo Xi 2550) report here just for your information. I didn't test it myself. Please, read this topic carefully https://bugs.launchpad.net/ubuntu/+source/linux/+bug/620455 --- Comment #130 from Nik Swiridow 2013-02-13 18:00:10 UTC --- (In reply to comment #127)

Please test with caution!

I've posted Bandini's (another happy owner of Amilo Xi 2550) report here just for your information. I didn't test it myself. Please, read this topic carefully https://bugs.launchpad.net/ubuntu/+source/linux/+bug/620455 -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c131 --- Comment #131 from Andreas Nordal 2013-02-28 22:53:48 UTC --- (In reply to comment #128)

If this is resolved upstream; could someone please add the respective URL at bugzilla.kernel.org.

Let's continue at https://bugzilla.kernel.org/show_bug.cgi?id=12118 which you have already done ;) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c133 --- Comment #133 from Elmar Stellnberger 2013-03-11 12:02:28 UTC --- Created an attachment (id=529109) --> (http://bugzilla.novell.com/attachment.cgi?id=529109) benchmark-t0.001-d0.001-3.7.9-1.1-desktop kernel 3.7.9-1.1-desktop: better even without noapic: makes trtrtr on hangs instead of repeating the sound in ~1s intervals on hangs -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c135 --- Comment #135 from Elmar Stellnberger 2013-03-11 12:06:47 UTC --- Created an attachment (id=529114) --> (http://bugzilla.novell.com/attachment.cgi?id=529114) benchmark-t0.0001-d0.0001-3.7.9-1.1-desktop-noapic kernel 3.7.9-1.1-desktop, noapic: hangs in 0.1ms intervals -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c Elmar Stellnberger changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #529113|application/octet-stream |text/plain mime type| | -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c137 Elmar Stellnberger changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|UPSTREAM | --- Comment #137 from Elmar Stellnberger 2013-03-11 15:46:13 UTC --- Hey this is an issue on ANY multicore system! I have just tested rt-benchmark on my PB dots E2 with an Intel Atom CPU N550 4x@1,5Ghz: rt-benchmark behaves exactly in the same way. This means the issue is not only restricted to core2duo systems. Thus I would suggest to ship openSUSE 12.3 with the noapic option by default; please make this issue a shipment stopper. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c139 --- Comment #139 from Borislav Petkov 2013-05-13 23:32:30 UTC --- Ok, I got assigned to this so let's start slow, simple and from scratch: Can anyone try the latest *upstream* kernel (that's 3.10-rc1 currently) and describe exactly what the issue is and how I can reproduce it. Thanks. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c141 --- Comment #141 from Elmar Stellnberger 2013-05-16 19:28:38 UTC --- Created an attachment (id=539663) --> (http://bugzilla.novell.com/attachment.cgi?id=539663) benchmark-kernel-3.9.2-3-t0.0001-d0.0001 with apic -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c143 --- Comment #143 from Elmar Stellnberger 2013-05-16 19:39:47 UTC --- Borislav: There have been many gradual improvements to this bug in the recent years however without fully resolving it. You may test for it on your own by downloading and compiling the rt-benchmark utility running it with "./rt-benchmark t0.0001 d0.0001" (attachement #3). Nonetheless I still doubt that fully resolving this issue will be possible by some more bug fixes. See Comment #117. Keeping one core in C0 state whenever a timer is pending on the short term may be the only solution. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c145 --- Comment #145 from Elmar Stellnberger 2013-05-16 19:46:27 UTC --- for the very short sleeping tasks t=0.0001s, only ;) -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c147 Mike Galbraith changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mgalbraith@suse.com --- Comment #147 from Mike Galbraith 2013-05-18 08:52:31 UTC --- (In reply to comment #146)

This looks like something for the sched people. Adding Mike.

So, a couple of observations I was able to make; I want to highly emphasize here that I'm no sched guy.

* AFAICT, your synthetic benchmark sets sleep intervals of about 1 ms which is very close to the scheduling latency I was able to observe through watching vmstat while building the kernel. It showed 800-900 context switches per second which is something a little more than 1ms. I'm not sure the stock kernel can even handle such small sleep intervals.

Well, that's kind of a trick question. A PREEMPT kernel can handle that depending on hardware/firmware and how tight your jitter tolerance is. My old Q6600 box running a PREEMPT/250 Hz kernel can easily meet a 1KHz periodic demand even under hefty load iff I don't expect too much worst case wise. On an isolated core as below, I can expect a whole lot more.. marge:~ # cgexec -g cpuset:rtcpus jitter -c 3 -p 99 -t 30 -f 1000 -d 10 -t 25 CPU3 priority: 99 timer freq: 1000 Hz (1000000 ns) tolerance: 25 usecs, stats interval: 10 secs jitter: 3.82 min: 2.81 max: 6.63 mean: 3.00 stddev: 0.13 jitter: 4.47 min: 2.82 max: 7.29 mean: 3.00 stddev: 0.13 jitter: 2.96 min: 2.81 max: 5.77 mean: 3.00 stddev: 0.12 jitter: 5.06 min: 2.81 max: 7.87 mean: 3.00 stddev: 0.14 jitter: 3.13 min: 2.82 max: 5.95 mean: 3.00 stddev: 0.13 jitter: 28.05 min: 2.84 max: 30.88 mean: 13.91 stddev: 5.28 27 > 25 us hits min: 26.12 max: 30.88 mean: 27.49 stddev: 1.22 jitter: 32.72 min: 3.78 max: 36.51 mean: 16.40 stddev: 0.96 25 > 25 us hits min: 26.56 max: 36.51 mean: 27.55 stddev: 1.97 jitter: 32.61 min: 3.84 max: 36.45 mean: 16.41 stddev: 1.02 31 > 25 us hits min: 26.12 max: 36.45 mean: 27.54 stddev: 2.34 jitter: 22.54 min: 5.12 max: 27.66 mean: 16.41 stddev: 0.71 18 > 25 us hits min: 26.42 max: 27.66 mean: 26.89 stddev: 0.31 ..but above, you can plainly see where I killed the cpuhog that was keeping CPU3 away from cstates. The firmware on this box is ok (no SMI), but the core2 CPU itself isn't particularly wonderful. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c149 --- Comment #149 from Mike Galbraith 2013-05-19 05:59:14 UTC --- (In reply to comment #148)

(In reply to comment #147)

...

Well, that's kind of a trick question. A PREEMPT kernel can handle that depending on hardware/firmware and how tight your jitter tolerance is. My old Q6600 box running a PREEMPT/250 Hz kernel can easily meet a 1KHz periodic demand even under hefty load iff I don't expect too much worst case wise.

Hehe, I think this is exactly the problem: reportedly, current kernel leads to "degraded music playback and gaming quality".

And yep, it must very well be hardware/firmware-dependent because audio runs just fine on my box here, even under heavy load (I don't play games :-)).

Here too. If it's _not_ one of those crippled up hpet inflicted boxen (can't help at all there), I'd fire up tracer with wakeup_rt tracer and see what's going on if an rt task doesn't hit the CPU in short order. A full ms wakeup latency is definitely not considered to be in short order for an rt task ;-) You can forget that 100us constraint though, it's not really achievable under load with a non-rt kernel, and certainly not when you add tracing overhead on top. If THP is on, turn that off (I traced >600us held in kernel by that in NOPREEMPT kernel iirc), and run some normal load where sound doesn't play well.

...

On an isolated core as below, I can expect a whole lot more..

Hmm, I was wondering whether NO_HZ_FULL would help even on an SMI-plagued hw? That would be an interesting thing to try.

There's nothing at all you can do for SMIs afaik, unless your BIOS will let you turn the darn things off. My core2 box won't even enter tickless mode. Per Frederic, the unstable tsc precludes that. Booting tsc=reliable didn't help though...

...

jitter: 22.54 min: 5.12 max: 27.66 mean: 16.41 stddev: 0.71 18 > 25 us hits min: 26.42 max: 27.66 mean: 26.89 stddev: 0.31

..but above, you can plainly see where I killed the cpuhog that was keeping CPU3 away from cstates. The firmware on this box is ok (no SMI),

How am I to read this? As in "jitter grows when the core is allowed to go in deeper C-states?"

Yeah.

...

but the core2 CPU itself isn't particularly wonderful.

Why? I don't think the CPU itself has any fault in this - it is the glue around it which makes it misbehave, like C-states and such. If you keep it powered on throughout with idle=poll, for example, C-states influence should be gone. I even heard RT-folk do that in certain cases.

Ok, the combo of old core2 cpu and its associated old glue isn't wonderful for rt. I have no idea what specific silicon gnomes in specific cubicles do from 9 to 5 ;-) An Intel guy told me core2 had latency issues, maybe he was talking about glue, dunno. Funny thing with my core2 box is just keeping it away from cstates isn't enough, it has to be kept kept churning and burning to eliminate the idle jitter. Hohum, kind off topic, but mentioned wrt that 100us thing, it all contributes, and as you can see from my box, a substantial chunk of that unofficial, but frequently mentioned and pulled out of thin air, target latency number is pre-consumed. If I don't set cpufreq to performance, there goes a bunch more. Add nohz, etc etc... -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c151 --- Comment #151 from Borislav Petkov 2013-05-19 11:02:05 UTC --- Only the HPET aspect first. (In reply to comment #149)

If it's _not_ one of those crippled up hpet inflicted boxen (can't help at all there),

I don't think anyone can, especially if the HPET is updated/managed in SMM. And by the looks of it, the box is using HPET: [ 3.761653] Monitor-Mwait will be used to enter C-1 state [ 3.761675] Monitor-Mwait will be used to enter C-3 state [ 3.761681] Marking TSC unstable due to TSC halts in idle [ 3.761706] Switching to clocksource hpet it switches away from tsc since it gets turned off in some C-state != C0. Elmar, can you upload a recent dmesg from booting on this box (both SUSE and 3.9.2 kernel). Also, can you try booting with "hpet=disable" on the kernel command line and see whether you can repro then? Thanks. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c153 --- Comment #153 from Mike Galbraith 2013-05-19 18:19:47 UTC --- (In reply to comment #152)

(In reply to comment #149)

...

If it's _not_ one of those crippled up hpet inflicted boxen (can't help at all there), I'd fire up tracer with wakeup_rt tracer and see what's going on if an rt task doesn't hit the CPU in short order. A full ms wakeup latency is definitely not considered to be in short order for an rt task ;-)

Ok.

...

You can forget that 100us constraint though, it's not really achievable under load with a non-rt kernel, and certainly not when you add tracing overhead on top. If THP is on, turn that off (I traced

...

600us held in kernel by that in NOPREEMPT kernel iirc), and run some normal load where sound doesn't play well.

Well, I'd still like to stay within the reasonable here since it is the stock kernel and we're talking about audio (I'm not saying RT folk is unreasonable :-)). If it can stomach higher latencies without becoming noticeable, then we're fine.

Audio playback is generally so heavily buffered that it's pretty boring, can and must tolerate a LOT of scheduling latency because it's done by plain old SCHED_OTHER tasks that have no idea or control over when they'll be preempted, or for how long. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c155 --- Comment #155 from Mike Galbraith 2013-05-20 09:57:40 UTC --- (In reply to comment #154)

(In reply to comment #153)

...

...

Well, I'd still like to stay within the reasonable here since it is the stock kernel and we're talking about audio (I'm not saying RT folk is unreasonable :-)). If it can stomach higher latencies without becoming noticeable, then we're fine.

Audio playback is generally so heavily buffered that it's pretty boring, can and must tolerate a LOT of scheduling latency because it's done by plain old SCHED_OTHER tasks that have no idea or control over when they'll be preempted, or for how long.

Yep, and reportedly it still causes degradation in audio performance. I'd be nice to have a good reproducer for this observation though ...

My little Toshiba Satellite lappy is blessed with a tsc that stops, so uses hpet clocksource (unless I boot processor.max_cstate=1). Audio playback is peachy, as is playing a DVD serfing etc, both with and without a competing load, ie w. wo. entering C-[23]. read_hpet() is pretty horrible kernel overhead wise, but everything works just fine with openSUSE-12.3 kernel or mainline. Hohum.. my hpet is not the right flavor of trash. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c157 --- Comment #157 from Borislav Petkov 2013-05-20 13:30:38 UTC --- Right, your HPET is fast :) Elmar can you boot with "hpet=disable" and try to reproduce? Thanks. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c159 --- Comment #159 from Elmar Stellnberger 2013-06-10 13:31:45 UTC --- Created an attachment (id=543534) --> (http://bugzilla.novell.com/attachment.cgi?id=543534) benchmark-kernel-3.9.2-3-t0.0001-d0.0001-hpet -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c161 --- Comment #161 from Andreas Nordal 2013-06-15 15:01:48 UTC --- (In reply to comment #139)

Can anyone describe exactly what the issue is and how I can reproduce it

This is about system-wide hangs (no task making progress), that: * resumes immediately on user input (from keyboard, mouse, laptop lid, plugging AC power) * easily lasts for hours on some kernels if your patience permits, to speculatively small (centisecs) on others. In one occasion, X had the effect of limiting my hangs to just up under 1 second. * occur under light load — an effective remedy is to open a terminal and issue `yes`. A 100% effective workaround is "processor.max_cstate=1". * occurs more frequently when playing audio, running rt-benchmark, and running wget. How to reproduce: 1. Watch glxgears (or something that updates the screen) while playing audio. 2. Observe that glxgears hangs whenever your audio player hangs, and that sound is repeated for the duration of this hang. 3. If you're lucky, you may test your patience by letting it hang, and when you feel for it, move your mouse 1mm, and observe that all tasks resume. If you're less lucky and only see/hear small hangs, you may still observe that keeping your mouse in motion prevents hanging. The role of rt-benchmark is to measure duration of hangs. My affected laptop has a broken screen, so I'm no longer able to test. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c163 --- Comment #163 from Borislav Petkov 2013-06-17 07:05:02 UTC --- Yes, it all points to either HPET having high latency because it is dealt with in SMM mode or the hardware is generally spending hundreds of milliseconds in SMM doing whatever it thinks it is doing, which delays normal system processing considerably. Btw, Mike, you could try to boot with hpet=disable so that you can fallback to the acpi_pm timer and see whether you can see delays then (look for the last message "Switching to clocksource ..." in dmesg to tell you what timer you're falling back on - /proc/timer_list should have that info too, though). Thanks. -- 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.

https://bugzilla.novell.com/show_bug.cgi?id=579932 https://bugzilla.novell.com/show_bug.cgi?id=579932#c165 Borislav Petkov changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |RESOLVED Resolution| |INVALID --- Comment #165 from Borislav Petkov 2013-07-21 19:50:31 UTC --- I'm gonna close this one as this looks like a hardware-related issue, HPET in this particular case. One other thing to test that comes to mind is boot with "idle=poll" and see if the hangs happen then. So guys feel free to reopen this if I've missed anything. Thanks. -- 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.