Mailinglist Archive: opensuse-bugs (15782 mails)

< Previous Next >
[Bug 296434] New: kernel with CONFIG_NO_HZ looses interrupts
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Wed, 1 Aug 2007 07:25:40 -0600 (MDT)
  • Message-id: <bug-296434-21960@xxxxxxxxxxxxxxxxxxxxxxxxx/>
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@xxxxxxxxxxxxxxxxxxxxxx
        ReportedBy: matz@xxxxxxxxxx
         QAContact: qa@xxxxxxx
          Found By: Development


The symptoms here were already described on kernel@xxxxxxx 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.

< Previous Next >