https://bugzilla.novell.com/show_bug.cgi?id=296434 Summary: kernel with CONFIG_NO_HZ looses interrupts Product: openSUSE 10.3 Version: Alpha 6 Platform: i686 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel AssignedTo: kernel-maintainers@forge.provo.novell.com ReportedBy: matz@novell.com QAContact: qa@suse.de Found By: Development The symptoms here were already described on kernel@suse.de in the thread "[Bug 294120] powertop optimizations" . This bug report is to not loose the information therein. I have a Sony Vaio TX5MN/W, with an ultra low voltage CPU. I built a CONFIG_NO_HZ kernel out of our STABLE sources, using 2.6.22.1-6 as base, by changing the config file to activate these three settings: CONFIG_TICK_ONESHOT=y CONFIG_NO_HZ=y CONFIG_HIGH_RES_TIMERS=y The kernel works mostly fine, except that it sometimes seems to loose interrupts. It seems to only happen after resuming from suspend to RAM (from suspend to disk it's fine). The effect is, that for instance commands entered into shell don't make progress until some interrupt occurs (e.g. from key presses, or mouse moves, or because the wireless is activated and hence generates interrupts from time to time). E.g. it sometimes happens that "cat /tmp/somefile" doesn't give any output, until I press the shift key (for instance). I'm not sure which interrupts are lost. I know that at least timer interrupts are, which might be the only cause even for the above commands (they were entered in a graphic session, and X uses timers to control its output, so the non-occurring progress might only be lost timer interrupts, or also lost hard disc interrupts). That it's at least the timer interrupts lost can be shown by simple strace (reproducable 100%, when no other interrupts sources are active, i.e. wireless switched off, no ethernet connection, no USB modules loaded): % strace -f -tt bash -c "sleep 5 && echo bla" the strace will stop at the sleep 5 as expected, but that syscall will never return unless I press a key, i.e.: [pid 9974] 21:05:01.615569 mmap2(NULL, 254020, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7ca9000 [pid 9974] 21:05:01.615878 close(3) = 0 [pid 9974] 21:05:01.616233 nanosleep({5, 0}, here it will stop, then I press key and it resumes: NULL) = 0 [pid 9974] 21:05:11.840094 close(1) = 0 See the 10 seconds time difference. Thomas Renniger had the idea that it might be HPET which causes this, as it had some problems in the past to correctly wake up after resume. By default this system is indeed using HPET as time source. I've not yet tried to switch it to something else. -- 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.