Red Hat Bugzilla – Bug 243803
Timer not moving on Intel D815EEA2 mainboard
Last modified: 2007-11-30 17:12:07 EST
Description of problem:
First off, I'm not sure if this is a bug or a feature, but I'll report it
nevertheless, given that my other machines do not observe this behaviour. If I
do "watch cat /proc/interrupts" on this box, I can see the timer standing still.
0: 174 XT-PIC-XT timer
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Timer is standing still. I get it - we have a tickless kernel now - but I was
under the impression it shouldn't be _this_ tickless :-)
Occasionally, we should see number of timer interrupts increase?
The system is working fine and there is nothing I can determine to be wrong with
it. My boot line contains acpi=noirq, because otherwise my third NIC won't work.
I tried booting without that and the timer was still standing still.
Created attachment 156767 [details]
Output of lspci -vv
I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.
I am CC'ing myself to this bug and will try and assist you in resolving it if I can.
There hasn't been much activity on this bug for a while. Could you tell me if
you are still having problems with the latest kernel? Watching interrupts works
as expected, updating fine on my laptop. i386 kernels are tickless now certainly
- you might want to install powertop and have a play if you haven't already.
If the problem no longer exists then please close this bug or I'll do so in a
few days if there is no additional information lodged.
From what I can tell, all of these kernels have been working OK (currently I
have 188.8.131.52-76.fc7), it's just that when you do 'cat /proc/interrupts' the
timer interrupt isn't going anywhere after boot. At present, I have 748 timer
interrupts in over 3 days of uptime. This sounds a bit low to me. Or maybe I'm
misunderstanding the tickless kernel here. But then again, my Core based laptop
keeps advancing the number of timer interrupts, so I doubt that I am.
Please note that I have to boot with acpi=noirq on this hardware - not sure if
this makes a difference. This machine is not a laptop - it's actually a 2RU
server, with that motherboard (P3 based) in it.
You might want to reboot and add nohz=off as a boot flag (this disables
dynticks), then see if you get the same output from watch processor interrupts.
(In reply to comment #3)
> From what I can tell, all of these kernels have been working OK (currently I
> have 184.108.40.206-76.fc7), it's just that when you do 'cat /proc/interrupts' the
> timer interrupt isn't going anywhere after boot.
Timer works a whole new way now. Those first few interrupts are from before
highres mode kicked in.
OK, thanks Chuck. Does that mean that all my other i686 machines are not using
highres mode (given they advance the timer)? All of them are relatively recent
Core based machines (Inspiron 6400), so I would think they'd have highres mode...
(In reply to comment #6)
> OK, thanks Chuck. Does that mean that all my other i686 machines are not using
> highres mode (given they advance the timer)? All of them are relatively recent
> Core based machines (Inspiron 6400), so I would think they'd have highres mode...
It depends on which timer source they use. (You will see the LOC [local APIC]
count increment but not interrupt 0.)
Thanks, that explains it then. LOC is being incremented on this box just fine.