Hi
with kernel 2.4.21-pre2:
pc:~ # cat /proc/interrupts
CPU0 CPU1
0: 29372 0 IO-APIC-edge timer
1: 504 0 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
8: 2 0 IO-APIC-edge rtc
9: 0 0 IO-APIC-edge acpi
12: 8078 0 IO-APIC-edge PS/2 Mouse
14: 7 0 IO-APIC-edge ide0
16: 8690 0 IO-APIC-level aic7xxx
18: 241 0 IO-APIC-level eth0
NMI: 0 0
LOC: 29276 29275
ERR: 0
MIS: 0
Booting with "noapic" or "acpi=off" doesn't make a difference.
With kernel 2.4.20 both CPU's handled the same amount of interrupts.
I haven't checked this with 2.4.21-pre1.
The CPU's are PIII@500
pc:~ # lspci
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge
(rev 03)
00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev
03)
00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01)
00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01)
00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
00:0b.0 SCSI storage controller: Adaptec AIC-7880U (rev 01)
00:11.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL-8139/8139C/8139C+ (rev 10)
01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP
1X/2X (rev 5c)
please cc me because I'm not on the list
Mine does this too. 2.4.20. Iwill dp400 board running dual 2.4Ghz
Xeons with HT enabled.
I have to boot by passing "noapic" to the kernel, otherwise
/cat/proc/interrupts will show the interrupt numbers wrong,
however. not doing this changes nothing.
Can someone help with this? If you can help I can dedicate the
necessary time in getting you whatever info you need.
Thanks
On Saturday 28 December 2002 03:56 am, Hans Lambrechts wrote:
> Hi
>
> with kernel 2.4.21-pre2:
>
> pc:~ # cat /proc/interrupts
> CPU0 CPU1
> 0: 29372 0 IO-APIC-edge timer
> 1: 504 0 IO-APIC-edge keyboard
> 2: 0 0 XT-PIC cascade
> 8: 2 0 IO-APIC-edge rtc
> 9: 0 0 IO-APIC-edge acpi
> 12: 8078 0 IO-APIC-edge PS/2 Mouse
> 14: 7 0 IO-APIC-edge ide0
> 16: 8690 0 IO-APIC-level aic7xxx
> 18: 241 0 IO-APIC-level eth0
> NMI: 0 0
> LOC: 29276 29275
> ERR: 0
> MIS: 0
>
> Booting with "noapic" or "acpi=off" doesn't make a difference.
> With kernel 2.4.20 both CPU's handled the same amount of
> interrupts. I haven't checked this with 2.4.21-pre1.
>
> The CPU's are PIII@500
>
> pc:~ # lspci
> 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host
> bridge (rev 03)
> 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP
> bridge (rev 03)
> 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
> 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev
> 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB
> (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI
> (rev 02) 00:0b.0 SCSI storage controller: Adaptec AIC-7880U (rev
> 01) 00:11.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
> RTL-8139/8139C/8139C+ (rev 10)
> 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage
> Pro AGP 1X/2X (rev 5c)
>
> please cc me because I'm not on the list
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in the body of a message to
> [email protected]
> More majordomo info at
> http://vger.kernel.org/majordomo-info.html Please read the FAQ at
> http://www.tux.org/lkml/
me three, I get the following /proc/interrupts:
CPU0 CPU1
0: 54567949 0 IO-APIC-edge timer
1: 2 0 IO-APIC-edge keyboard
2: 0 0 XT-PIC cascade
3: 3053053 0 IO-APIC-edge serial
14: 13055425 0 IO-APIC-edge ide0
15: 21991640 0 IO-APIC-edge ide1
24: 147016482 0 IO-APIC-level eth0
26: 1720744 0 IO-APIC-level aic7xxx
27: 16 0 IO-APIC-level aic7xxx
NMI: 0 0
LOC: 54568206 54570366
ERR: 0
MIS: 0
lspci:
00:00.0 Host bridge: Relience Computer CNB20HE (rev 05)
00:00.1 Host bridge: Relience Computer CNB20HE (rev 05)
Let me know if I can provide any further info.
--
Alistair Riddell - BOFH
IT Manager, George Watson's College, Edinburgh
Tel: +44 131 446 6070 Fax: +44 131 452 8594
Microsoft - because god hates us
On Sat, 2002-12-28 at 17:03, Ron Cooper wrote:
> Mine does this too. 2.4.20. Iwill dp400 board running dual 2.4Ghz
> Xeons with HT enabled.
>
> I have to boot by passing "noapic" to the kernel, otherwise
> /cat/proc/interrupts will show the interrupt numbers wrong,
> however. not doing this changes nothing.
"noapic" will deliver all IRQ's to IRQ0. Note btw - IRQ numbers *do*
change in APIC mode
On Sunday 29 December 2002 07:35 pm, Alan Cox wrote:
> On Sat, 2002-12-28 at 17:03, Ron Cooper wrote:
> > Mine does this too. 2.4.20. Iwill dp400 board running dual
> > 2.4Ghz Xeons with HT enabled.
> >
> > I have to boot by passing "noapic" to the kernel, otherwise
> > /cat/proc/interrupts will show the interrupt numbers wrong,
> > however. not doing this changes nothing.
>
> "noapic" will deliver all IRQ's to IRQ0. Note btw - IRQ numbers
> *do* change in APIC mode
>
> -
Thank you for your reply and for the information.
Any reason to be disturbed by the fact /proc/interrupts only shows
CPU0 with irq counts while CPU1 is always zero?
All the VIA chipsets I have that are SMP report both CPU's in the
interrupt counts. This IWILL board with the I860 chipset does not
no matter which kernel I try.
I'd like to fix this but I dont know how. But I am willing to
assist and devote any time necessary to someone who may have the
knowledge fix it. There have to be others out there experiencing
this same issue so its not a wasted cause in my estimation.
Alan, do you have any commentary on this issue?
Cheers
Ron
On Monday 30 December 2002 02:35, you wrote:
> On Sat, 2002-12-28 at 17:03, Ron Cooper wrote:
> > Mine does this too. 2.4.20. Iwill dp400 board running dual 2.4Ghz
> > Xeons with HT enabled.
> >
> > I have to boot by passing "noapic" to the kernel, otherwise
> > /cat/proc/interrupts will show the interrupt numbers wrong,
> > however. not doing this changes nothing.
>
> "noapic" will deliver all IRQ's to IRQ0. Note btw - IRQ numbers *do*
> change in APIC mode
Hi Alan,
maybe this snippet from patch-2.4.21-pre2.gz is the culprit:
diff -Naur -X /home/marcelo/lib/dontdiff linux-2.4.20/arch/i386/kernel/apic.c linux-2.4.21/arch/i386/kernel/apic.c
--- linux-2.4.20/arch/i386/kernel/apic.c 2002-12-18 18:27:05.000000000 +0000
+++ linux-2.4.21/arch/i386/kernel/apic.c 2002-12-18 18:58:08.000000000 +0000
@@ -261,6 +261,16 @@
apic_write_around(APIC_LVT1, value);
}
+static unsigned long calculate_ldr(unsigned long old)
+{
+ unsigned long id;
+ if(clustered_apic_mode == CLUSTERED_APIC_XAPIC)
+ id = physical_to_logical_apicid(hard_smp_processor_id());
+ else
+ id = 1UL << smp_processor_id();
+ return (old & ~APIC_LDR_MASK)|SET_APIC_LOGICAL_ID(id);
+}
+
void __init setup_local_APIC (void)
{
unsigned long value, ver, maxlvt;
@@ -298,15 +308,16 @@
* for us. Otherwise put the APIC into clustered or flat
* delivery mode. Must be "all ones" explicitly for 82489DX.
*/
- apic_write_around(APIC_DFR, APIC_DFR_FLAT);
+ if(clustered_apic_mode == CLUSTERED_APIC_XAPIC)
+ apic_write_around(APIC_DFR, APIC_DFR_CLUSTER);
+ else
+ apic_write_around(APIC_DFR, APIC_DFR_FLAT);
/*
* Set up the logical destination ID.
*/
value = apic_read(APIC_LDR);
- value &= ~APIC_LDR_MASK;
- value |= (1<<(smp_processor_id()+24));
- apic_write_around(APIC_LDR, value);
+ apic_write_around(APIC_LDR, calculate_ldr(value));
}
On Mon, 2002-12-30 at 11:40, Hans Lambrechts wrote:
> maybe this snippet from patch-2.4.21-pre2.gz is the culprit:
Shouldn't be but it is possibly the cause. There are some measurable
APIC handling changes in 2.4.21 that might trip something up