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).
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
On Thu, 9 Nov 2006 13:09:53 +0300
Paul P Komkoff Jr <[email protected]> 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?
Replying to Andrew Morton:
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 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
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?
Also have you tried acpi=off or the linux firmware test kit (see url in
sig) to check the bios?
--
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
Replying to Arjan van de Ven:
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
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
So I got rid of "interrupt storm" but what I've lost (except poweroff)?
--
Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key
This message represents the official view of the voices in my head
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.
--
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
On Friday 10 November 2006 08:43, Arjan van de Ven wrote:
> 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:-)