[Dumb question] 100k RTC interrupts/sec on SMP system: why?
Paul P Komkoff Jr
I have a couple of old SMP systems (Dual P3 on Intel STL2 boards), on
which I experience the following:
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
0 0 0 800752 45376 143064 0 0 0 8 96607 65 0 0 100 0 0
0 0 0 800752 45376 143064 0 0 0 0 96439 57 0 0 100 0 0
It's a completely idle system. Interrupts are coming from rtc.
This is a stock fedora SMP kernel.
IIRC, some time ago (years) I've read that rtc can be used somehow in
SMP but I don't remember the specifics. So, maybe you are familiar
with this and can give out a quick answer - what this 100K
interrupts/sec are about, and how to get rid of them (if possible).
Thanks!
--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Andrew Morton
Paul P Komkoff Jr <i...@stingr.net> wrote:
> Hi.
>
> I have a couple of old SMP systems (Dual P3 on Intel STL2 boards), on
> which I experience the following:
> procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
> 0 0 0 800752 45376 143064 0 0 0 8 96607 65 0 0 100 0 0
> 0 0 0 800752 45376 143064 0 0 0 0 96439 57 0 0 100 0 0
>
> It's a completely idle system. Interrupts are coming from rtc.
> This is a stock fedora SMP kernel.
>
> IIRC, some time ago (years) I've read that rtc can be used somehow in
> SMP but I don't remember the specifics. So, maybe you are familiar
> with this and can give out a quick answer - what this 100K
> interrupts/sec are about, and how to get rid of them (if possible).
>
I guess we could start with the full dmesg output and the kernel version?
Paul P Komkoff Jr
Hi, Andrew.
> I guess we could start with the full dmesg output and the kernel version?
I hoped that somebody like Alan or Davej will appear on the stage and
say "hah! I know, this is a feature (saidfeature)".
Well, so going the slow way. Attached dmesg and config.
This is generic fedora 686 kernel, so I'll try to play with kconfig
and see if something changes...
Paul P Komkoff Jr
Hi, Arjan!
> On Fri, 2006-11-10 at 15:35 +0300, Paul P Komkoff Jr wrote:
> > ce: <Cronyx Tau-PCI/32-Lite> at 0xfb013000 irq 217
>
> what kind of device is this? Did the driver come with the kernel?
It's E1 interface card, I use them for telephony.
I am pretty sure that Tau32 isn't guilty (I did tests with and without
it installed), see interrupts
[stingray@voipng ~]$ cat /proc/interrupts
CPU0 CPU1
0: 9833272 9829747 IO-APIC-edge timer
6: 3 2 IO-APIC-edge floppy
7: 1 1 IO-APIC-edge parport0
8: 3673166897 3674697116 IO-APIC-level rtc
10: 0 0 IO-APIC-level ohci_hcd:usb1
177: 586 401 IO-APIC-level acpi
185: 9787 6905 IO-APIC-level aic7xxx
193: 6 9 IO-APIC-level aic7xxx
201: 249751 6 IO-APIC-level eth0
217: 78926484 78899594 IO-APIC-level Cronyx Tau-PCI/32
NMI: 0 0
LOC: 19663975 19663974
ERR: 0
MIS: 0
This is after 22 hours of uptime.
> Also have you tried acpi=off or the linux firmware test kit (see url in
> sig) to check the bios?
Didn't acpi=off meant to hose interrupt routing, SMP, and poweroff?
I'll try it right now.
And thanks, I didn't know about firmware test kit either ... will
download it right now and test in a few hours.
--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
Arjan van de Ven
> Replying to Arjan van de Ven:
>
> 8: 1 0 IO-APIC-edge rtc
acpi=on had this
> 8: 3673166897 3674697116 IO-APIC-level rtc
spot the level-vs-edge difference.... your acpi interrupt routing looks
bust.
> So I got rid of "interrupt storm" but what I've lost (except poweroff)?
you can get power off with APM as well.
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
Len Brown
> On Fri, 2006-11-10 at 16:35 +0300, Paul P Komkoff Jr wrote:
> > Replying to Arjan van de Ven:
> > > Also have you tried acpi=off or the linux firmware test kit (see url in
> >
> > acpi=off fixed this.
> > 8: 1 0 IO-APIC-edge rtc
> acpi=on had this
>
> > 8: 3673166897 3674697116 IO-APIC-level rtc
>
> spot the level-vs-edge difference.... your acpi interrupt routing looks
> bust.
>
>
> > So I got rid of "interrupt storm" but what I've lost (except poweroff)?
>
> you can get power off with APM as well.
Servers don't have APM.
It seems this is an additional sighting of this BIOS bug:
http://bugzilla.kernel.org/show_bug.cgi?id=7679
(perhaps you can note that in the bug report)
pnpacpi=off should be a sufficient workaround for now.
thanks,
-Len
ps. there is nothing dumb about this question:-)