Bug 243803 - Timer not moving on Intel D815EEA2 mainboard
Timer not moving on Intel D815EEA2 mainboard
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-06-11 19:22 EDT by Bojan Smojver
Modified: 2007-11-30 17:12 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-09-17 14:21:18 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Output of lspci -vv (6.27 KB, text/plain)
2007-06-11 19:22 EDT, Bojan Smojver
no flags Details

  None (edit)
Description Bojan Smojver 2007-06-11 19:22:42 EDT
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.
Like this:
-----------------------------
  0:        174    XT-PIC-XT        timer
-----------------------------

Version-Release number of selected component (if applicable):
2.6.21-1.3194.fc7

How reproducible:
Always.

Steps to Reproduce:
1. Boot.
  
Actual results:
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 :-)

Expected results:
Occasionally, we should see number of timer interrupts increase?

Additional info:
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.
Comment 1 Bojan Smojver 2007-06-11 19:22:42 EDT
Created attachment 156767 [details]
Output of lspci -vv
Comment 2 Christopher Brown 2007-09-16 17:13:59 EDT
Hello,

I'm reviewing this bug as part of the kernel bug triage project, an attempt to
isolate current bugs in the fedora kernel.

http://fedoraproject.org/wiki/KernelBugTriage

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.

Cheers
Chris
Comment 3 Bojan Smojver 2007-09-16 19:05:02 EDT
From what I can tell, all of these kernels have been working OK (currently I
have 2.6.22.5-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.
Comment 4 Christopher Brown 2007-09-17 05:41:55 EDT
Bojan,

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.

Cheers
Chris
Comment 5 Chuck Ebbert 2007-09-17 14:21:18 EDT
(In reply to comment #3)
> From what I can tell, all of these kernels have been working OK (currently I
> have 2.6.22.5-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.

Comment 6 Bojan Smojver 2007-09-17 17:12:18 EDT
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...
Comment 7 Chuck Ebbert 2007-09-17 17:26:35 EDT
(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.)
Comment 8 Bojan Smojver 2007-09-17 18:26:12 EDT
Thanks, that explains it then. LOC is being incremented on this box just fine.

Note You need to log in before you can comment on or make changes to this bug.