* HT apparently not detected properly on 2.4.23
@ 2003-12-03 18:46 Ethan Weinstein
2003-12-03 19:40 ` Andre Tomt
2003-12-03 22:40 ` William Lee Irwin III
0 siblings, 2 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-03 18:46 UTC (permalink / raw)
To: linux-kernel
Hi,
With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
/proc/cpuinfo|proc/interrupts, with:
CONFIG_ACPI=y
CONFIG_ACPI_HT_ONLY=y
The same config with 2.4.23 only shows 2 cpus, even with:
CONFIG_NR_CPUS=4
Also, I believe this has been reported before, but the system only seems
to interrupt on CPU0 with either kernel, unless I apply a patch I found
here:
http://www.hardrock.org/kernel/2.4.22/irqbalance-2.4.22-MRC.patch
or run the `irqbalance' program.. which I don't care to do. This
problem _seems_ to be isolated to the Supermicro, as HT does seem
properly detected on several other SMP systems I have at work (compaq
ML370/ML380) with 2.4.23
-Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 18:46 HT apparently not detected properly on 2.4.23 Ethan Weinstein
@ 2003-12-03 19:40 ` Andre Tomt
2003-12-03 19:56 ` Mike Fedyk
2003-12-03 22:40 ` William Lee Irwin III
1 sibling, 1 reply; 16+ messages in thread
From: Andre Tomt @ 2003-12-03 19:40 UTC (permalink / raw)
To: linux-kernel; +Cc: Ethan Weinstein
On Wed, 2003-12-03 at 19:46, Ethan Weinstein wrote:
> Hi,
>
> With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
> xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
> /proc/cpuinfo|proc/interrupts, with:
> CONFIG_ACPI=y
> CONFIG_ACPI_HT_ONLY=y
> The same config with 2.4.23 only shows 2 cpus, even with:
> CONFIG_NR_CPUS=4
This may be the known problem about CONFIG_NR_CPU's not working properly
in all cases. Try up'ing it to 32.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 19:40 ` Andre Tomt
@ 2003-12-03 19:56 ` Mike Fedyk
2003-12-03 20:30 ` Ethan Weinstein
0 siblings, 1 reply; 16+ messages in thread
From: Mike Fedyk @ 2003-12-03 19:56 UTC (permalink / raw)
To: Andre Tomt; +Cc: linux-kernel, Ethan Weinstein
On Wed, Dec 03, 2003 at 08:40:51PM +0100, Andre Tomt wrote:
> On Wed, 2003-12-03 at 19:46, Ethan Weinstein wrote:
> > Hi,
> >
> > With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
> > xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
> > /proc/cpuinfo|proc/interrupts, with:
> > CONFIG_ACPI=y
> > CONFIG_ACPI_HT_ONLY=y
> > The same config with 2.4.23 only shows 2 cpus, even with:
> > CONFIG_NR_CPUS=4
>
> This may be the known problem about CONFIG_NR_CPU's not working properly
> in all cases. Try up'ing it to 32.
Depending on the logical addressing of your processors, CONFIG_NR_CPUS=8 may
work in this case too.
Some processors/motherboards logically address the CPUs other that 0-3 if
there are 4 processors.
Currently CONFIG_NR_CPUS needs to be big enough to hold the largest logical
processor number.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 19:56 ` Mike Fedyk
@ 2003-12-03 20:30 ` Ethan Weinstein
0 siblings, 0 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-03 20:30 UTC (permalink / raw)
To: linux-kernel
Mike Fedyk wrote:
> Depending on the logical addressing of your processors, CONFIG_NR_CPUS=8 may
> work in this case too.
>
> Some processors/motherboards logically address the CPUs other that 0-3 if
> there are 4 processors.
>
> Currently CONFIG_NR_CPUS needs to be big enough to hold the largest logical
> processor number.
Thanks. This rings a bell, I seem to remember what I thought to be
"impossible numbering" on the CPUs such as "CPU7" or somesuch in a
dmesg.. Will have to look through logs. I'll raise CONFIG_NR_CPUS and
see what I get. Now, the question is, why do we only interrupt on CPU0
on this pasrticular box|chipset with a vanilla kernel? ACPI problem? My
SMP G4 ppc has an option in menuconfig: "distribute interrupts on all
CPUs by default", the x86 has no such option.
Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 18:46 HT apparently not detected properly on 2.4.23 Ethan Weinstein
2003-12-03 19:40 ` Andre Tomt
@ 2003-12-03 22:40 ` William Lee Irwin III
2003-12-03 23:41 ` Ethan Weinstein
1 sibling, 1 reply; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-03 22:40 UTC (permalink / raw)
To: Ethan Weinstein; +Cc: linux-kernel
On Wed, Dec 03, 2003 at 01:46:38PM -0500, Ethan Weinstein wrote:
> With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
> xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
> /proc/cpuinfo|proc/interrupts, with:
> CONFIG_ACPI=y
> CONFIG_ACPI_HT_ONLY=y
> The same config with 2.4.23 only shows 2 cpus, even with:
> CONFIG_NR_CPUS=4
> Also, I believe this has been reported before, but the system only seems
> to interrupt on CPU0 with either kernel, unless I apply a patch I found
> here:
> http://www.hardrock.org/kernel/2.4.22/irqbalance-2.4.22-MRC.patch
> or run the `irqbalance' program.. which I don't care to do. This
> problem _seems_ to be isolated to the Supermicro, as HT does seem
> properly detected on several other SMP systems I have at work (compaq
> ML370/ML380) with 2.4.23
You probably have sparse physical APIC ID's.
-- wli
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 22:40 ` William Lee Irwin III
@ 2003-12-03 23:41 ` Ethan Weinstein
2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:46 ` William Lee Irwin III
0 siblings, 2 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-03 23:41 UTC (permalink / raw)
To: linux-kernel; +Cc: William Lee Irwin III
William Lee Irwin III wrote:
> On Wed, Dec 03, 2003 at 01:46:38PM -0500, Ethan Weinstein wrote:
>
>>With 2.4.22, my Supermicro X5DPL-iGM-O (E7501 chipset) with 2
>>xeons@2.4ghz and hypertherading enabled shows 4 cpu's in
>>/proc/cpuinfo|proc/interrupts, with:
>>CONFIG_ACPI=y
>>CONFIG_ACPI_HT_ONLY=y
>>The same config with 2.4.23 only shows 2 cpus, even with:
>>CONFIG_NR_CPUS=4
>>Also, I believe this has been reported before, but the system only seems
>>to interrupt on CPU0 with either kernel, unless I apply a patch I found
>>here:
>>http://www.hardrock.org/kernel/2.4.22/irqbalance-2.4.22-MRC.patch
>>or run the `irqbalance' program.. which I don't care to do. This
>>problem _seems_ to be isolated to the Supermicro, as HT does seem
>>properly detected on several other SMP systems I have at work (compaq
>>ML370/ML380) with 2.4.23
>
> You probably have sparse physical APIC ID's.
>
Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
it was the numbering scheme:
Dec 3 18:32:28 spicymeatball kernel: CPU 0 (0x0000) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #0 Pentium 4(tm)
XEON(tm) APIC version 16
Dec 3 18:32:28 spicymeatball kernel: LAPIC (acpi_id[0x0001] id[0x6]
enabled[1])
Dec 3 18:32:28 spicymeatball kernel: CPU 1 (0x0600) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #6 Pentium 4(tm)
XEON(tm) APIC version 16
Dec 3 18:32:28 spicymeatball kernel: LAPIC (acpi_id[0x0002] id[0x1]
enabled[1])
Dec 3 18:32:28 spicymeatball kernel: CPU 2 (0x0100) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #1 Pentium 4(tm)
XEON(tm) APIC version 16
Dec 3 18:32:28 spicymeatball kernel: LAPIC (acpi_id[0x0003] id[0x7]
enabled[1])
Dec 3 18:32:28 spicymeatball kernel: CPU 3 (0x0700) enabled
Dec 3 18:32:28 spicymeatball kernel: Processor #7 Pentium 4(tm)
XEON(tm) APIC version 16
But we're still only interrupting on CPU0 with this kernel.
-Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:41 ` Ethan Weinstein
@ 2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:18 ` Ethan Weinstein
2003-12-05 17:12 ` Marcelo Tosatti
2003-12-04 0:46 ` William Lee Irwin III
1 sibling, 2 replies; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-03 23:58 UTC (permalink / raw)
To: Ethan Weinstein; +Cc: linux-kernel
William Lee Irwin III wrote:
>>You probably have sparse physical APIC ID's.
On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
> it was the numbering scheme:
It's easy to fix this; just terminate the loop when the count of cpus
kicked hits NR_CPUS or the bit would overflow the map instead of the bit
hitting NR_CPUS. Compare smpboot.c in 2.4 vs. 2.6. No need for the extra
CONFIG_NR_CPUS bloat.
On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> But we're still only interrupting on CPU0 with this kernel.
That's P-IV retardation. Not really fixable, but irqbalance daemons
etc. can help mitigate the severity of the erratum. I'm not sure if
2.4 has the interfaces for the userspace solutions to work or the
kernel solutions either.
-- wli
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:58 ` William Lee Irwin III
@ 2003-12-04 0:18 ` Ethan Weinstein
2003-12-05 17:12 ` Marcelo Tosatti
1 sibling, 0 replies; 16+ messages in thread
From: Ethan Weinstein @ 2003-12-04 0:18 UTC (permalink / raw)
To: linux-kernel; +Cc: William Lee Irwin III
William Lee Irwin III wrote:
>
> On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
>
>>But we're still only interrupting on CPU0 with this kernel.
>
>
> That's P-IV retardation. Not really fixable, but irqbalance daemons
> etc. can help mitigate the severity of the erratum. I'm not sure if
> 2.4 has the interfaces for the userspace solutions to work or the
> kernel solutions either.
>
I somehow suspected that, and appreciate the clarification. I'll see if
I can't get that patch I found to apply to 2.4.23, it seems to solve
this a bit more elegantly than the irqbalance program.
CPU0 CPU1 CPU2 CPU3
0: 67962 69066 68010 68954 IO-APIC-edge timer
1: 1 0 0 1 IO-APIC-edge keyboard
2: 0 0 0 0 XT-PIC cascade
3: 10027 10944 9904 11063 IO-APIC-edge serial
8: 2 0 0 0 IO-APIC-edge rtc
16: 9 7 7 18 IO-APIC-level sym53c8xx
22: 6842 7336 7166 7429 IO-APIC-level eth0
48: 6429 6370 6202 6268 IO-APIC-level aic79xx
49: 1939 2018 2067 1949 IO-APIC-level aic79xx
54: 340 345 340 352 IO-APIC-level eth1
NMI: 0 0 0 0
LOC: 273824 273846 273844 273845
ERR: 0
MIS: 0
-Ethan
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:18 ` Ethan Weinstein
@ 2003-12-05 17:12 ` Marcelo Tosatti
2003-12-05 17:48 ` William Lee Irwin III
1 sibling, 1 reply; 16+ messages in thread
From: Marcelo Tosatti @ 2003-12-05 17:12 UTC (permalink / raw)
To: William Lee Irwin III; +Cc: Ethan Weinstein, linux-kernel
On Wed, 3 Dec 2003, William Lee Irwin III wrote:
> William Lee Irwin III wrote:
> >>You probably have sparse physical APIC ID's.
>
> On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> > Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
> > it was the numbering scheme:
>
> It's easy to fix this; just terminate the loop when the count of cpus
> kicked hits NR_CPUS or the bit would overflow the map instead of the bit
> hitting NR_CPUS. Compare smpboot.c in 2.4 vs. 2.6. No need for the extra
> CONFIG_NR_CPUS bloat.
>
>
> On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> > But we're still only interrupting on CPU0 with this kernel.
>
> That's P-IV retardation. Not really fixable, but irqbalance daemons
> etc. can help mitigate the severity of the erratum. I'm not sure if
> 2.4 has the interfaces for the userspace solutions to work or the
> kernel solutions either.
I think I will just remove CONFIG_NR_CPUS instead... it seems to bring
more trouble than advantages.
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-05 17:12 ` Marcelo Tosatti
@ 2003-12-05 17:48 ` William Lee Irwin III
2003-12-05 18:07 ` Re[2]: " Russell "Elik" Rademacher
0 siblings, 1 reply; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-05 17:48 UTC (permalink / raw)
To: Marcelo Tosatti; +Cc: Ethan Weinstein, linux-kernel
On Fri, Dec 05, 2003 at 03:12:14PM -0200, Marcelo Tosatti wrote:
> I think I will just remove CONFIG_NR_CPUS instead... it seems to bring
> more trouble than advantages.
I've gotten a success report from this patch (forwarded separately),
but that's okay.
To handle sparse physical APIC ID's within 2.4 limitations without
this patch, NR_CPUS == BITS_PER_LONG whenever CONFIG_SMP=y is an
effective requirement.
-- wli
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re[2]: HT apparently not detected properly on 2.4.23
2003-12-05 17:48 ` William Lee Irwin III
@ 2003-12-05 18:07 ` Russell "Elik" Rademacher
[not found] ` <3FD0CD65.5080307@stinkfoot.org>
0 siblings, 1 reply; 16+ messages in thread
From: Russell "Elik" Rademacher @ 2003-12-05 18:07 UTC (permalink / raw)
To: linux-kernel
Hmmmm.....
SO someone finally realized that HT is not being detected properly dispite all the boot time parameters in the lilo/grub with APIC turned on? It just seems to be a major problem since 2.4.21 version and I was hoping it was resolved. :)
This patch you mentioned, can you send a copy to me as well? Just want to get my clients off my back. :)
--
Best regards,
Russell "Elik" Rademacher
Freelance Remote System Adminstrator/Tech Support
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: HT apparently not detected properly on 2.4.23
2003-12-03 23:41 ` Ethan Weinstein
2003-12-03 23:58 ` William Lee Irwin III
@ 2003-12-04 0:46 ` William Lee Irwin III
1 sibling, 0 replies; 16+ messages in thread
From: William Lee Irwin III @ 2003-12-04 0:46 UTC (permalink / raw)
To: Ethan Weinstein; +Cc: linux-kernel
On Wed, Dec 03, 2003 at 06:41:36PM -0500, Ethan Weinstein wrote:
> Ok, setting CONFIG_NR_CPUS=8 does indeed solve the HT issue, looks like
> it was the numbering scheme:
Something like this might do the trick. NR_CPUS is already checked
indirectly via max_cpus.
-- wli
===== arch/i386/kernel/smpboot.c 1.17 vs edited =====
--- 1.17/arch/i386/kernel/smpboot.c Mon Nov 3 05:48:33 2003
+++ edited/arch/i386/kernel/smpboot.c Wed Dec 3 16:45:27 2003
@@ -1106,7 +1106,7 @@
*/
Dprintk("CPU present map: %lx\n", phys_cpu_present_map);
- for (bit = 0; bit < NR_CPUS; bit++) {
+ for (bit = 0; bit < BITS_PER_LONG; bit++) {
apicid = cpu_present_to_apicid(bit);
/* don't try to boot BAD_APICID */
^ permalink raw reply [flat|nested] 16+ messages in thread
end of thread, other threads:[~2003-12-05 23:38 UTC | newest]
Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-12-03 18:46 HT apparently not detected properly on 2.4.23 Ethan Weinstein
2003-12-03 19:40 ` Andre Tomt
2003-12-03 19:56 ` Mike Fedyk
2003-12-03 20:30 ` Ethan Weinstein
2003-12-03 22:40 ` William Lee Irwin III
2003-12-03 23:41 ` Ethan Weinstein
2003-12-03 23:58 ` William Lee Irwin III
2003-12-04 0:18 ` Ethan Weinstein
2003-12-05 17:12 ` Marcelo Tosatti
2003-12-05 17:48 ` William Lee Irwin III
2003-12-05 18:07 ` Re[2]: " Russell "Elik" Rademacher
[not found] ` <3FD0CD65.5080307@stinkfoot.org>
2003-12-05 23:02 ` Russell "Elik" Rademacher
2003-12-05 23:28 ` Ethan Weinstein
2003-12-05 23:31 ` Re[2]: " Russell "Elik" Rademacher
2003-12-05 23:38 ` William Lee Irwin III
2003-12-04 0:46 ` William Lee Irwin III
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).