* Re: Every semaphore call results in "uninterruptable sleep"
@ 2002-11-15 18:03 Manfred Spraul
2002-11-16 13:26 ` Xeon with HyperThreading and linux-2.4.20-rc2 Steffen Persvold
0 siblings, 1 reply; 10+ messages in thread
From: Manfred Spraul @ 2002-11-15 18:03 UTC (permalink / raw)
To: Kammerloher, Josef, linux-kernel
>
>
>Every semaphore function (semget(),..) , "ipcs -s" ... results in
>"uninterruptable sleep".
>The processes cannot be killed by kill -9.
>
>
Enable sysrequest, then press Alt+SysRQ+T.
It will dump the kernel stack of all processes.
Run in through ksymoops and send the results to the list.
--
Manfred
^ permalink raw reply [flat|nested] 10+ messages in thread* Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-15 18:03 Every semaphore call results in "uninterruptable sleep" Manfred Spraul @ 2002-11-16 13:26 ` Steffen Persvold 2002-11-19 21:09 ` [BUG?] " Steffen Persvold 0 siblings, 1 reply; 10+ messages in thread From: Steffen Persvold @ 2002-11-16 13:26 UTC (permalink / raw) To: linux-kernel Hi all, I've two boxes with Dual Xeons 1.8 GHz and HT option enabled in BIOS. When I boot 2.4.20-rc2 with default arguments the kernel detects 4 processors and also reports 4 processors in /proc/cpuinfo wiht the "ht" feature. However, if I boot with the "noht" option (wich I believed turned off HT and therefore only two processors should be available), the kernel still detects 4 processors, _but_ now the "ht" feature in /proc/cpuinfo is not there. Is this the intention of the "noht" option ? If so, are there any options available to turn off HT support in the kernel completely, so that I don't have to go into the BIOS to turn it off ? If you want to I can provide the dmesg output and .config. I think this issue is not just related to 2.4.20-rc2, but earlier kernels aswell. Regards, -- Steffen Persvold | Scali AS mailto:sp@scali.com | http://www.scali.com Tel: (+47) 2262 8950 | Olaf Helsets vei 6 Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY ^ permalink raw reply [flat|nested] 10+ messages in thread
* [BUG?] Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-16 13:26 ` Xeon with HyperThreading and linux-2.4.20-rc2 Steffen Persvold @ 2002-11-19 21:09 ` Steffen Persvold 2002-11-19 21:42 ` Hugh Dickins 0 siblings, 1 reply; 10+ messages in thread From: Steffen Persvold @ 2002-11-19 21:09 UTC (permalink / raw) To: linux-kernel Hi all, I've two boxes with Dual Xeons 1.8 GHz and HT option enabled in BIOS. When I boot 2.4.20-rc2 with default arguments the kernel detects 4 processors and also reports 4 processors in /proc/cpuinfo wiht the "ht" feature. However, if I boot with the "noht" option (wich I believed turned off HT and therefore only two processors should be available), the kernel still detects 4 processors, _but_ now the "ht" feature in /proc/cpuinfo is not there. Is this the intention of the "noht" option ? If so, are there any options available to turn off HT support in the kernel completely, so that I don't have to go into the BIOS to turn it off ? If you want to I can provide the dmesg output and .config. I think this issue is not just related to 2.4.20-rc2, but earlier kernels aswell. Regards, -- Steffen Persvold | Scali AS mailto:sp@scali.com | http://www.scali.com Tel: (+47) 2262 8950 | Olaf Helsets vei 6 Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG?] Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-19 21:09 ` [BUG?] " Steffen Persvold @ 2002-11-19 21:42 ` Hugh Dickins 2002-11-20 9:56 ` Steffen Persvold 0 siblings, 1 reply; 10+ messages in thread From: Hugh Dickins @ 2002-11-19 21:42 UTC (permalink / raw) To: Steffen Persvold; +Cc: linux-kernel On Tue, 19 Nov 2002, Steffen Persvold wrote: > > I've two boxes with Dual Xeons 1.8 GHz and HT option enabled in BIOS. When > I boot 2.4.20-rc2 with default arguments the kernel detects 4 processors and > also reports 4 processors in /proc/cpuinfo wiht the "ht" feature. > > However, if I boot with the "noht" option (wich I believed turned off HT > and therefore only two processors should be available), the kernel still > detects 4 processors, _but_ now the "ht" feature in /proc/cpuinfo is not > there. Is this the intention of the "noht" option ? No, the intention of the "noht" option is as you believed, and it used to work that way. I looked at latest sourcec, didn't see anything obviously wrong. Sorry, but I don't have a suitable HT machine to check at present. > If so, are there any > options available to turn off HT support in the kernel completely, so that > I don't have to go into the BIOS to turn it off ? > > If you want to I can provide the dmesg output and .config. > > I think this issue is not just related to 2.4.20-rc2, but earlier kernels > aswell. Could others check and report if 2.4.20-rc2 "noht" works for them or not? Thanks, Hugh ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG?] Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-19 21:42 ` Hugh Dickins @ 2002-11-20 9:56 ` Steffen Persvold 2002-11-20 12:53 ` Hugh Dickins 0 siblings, 1 reply; 10+ messages in thread From: Steffen Persvold @ 2002-11-20 9:56 UTC (permalink / raw) To: Hugh Dickins; +Cc: linux-kernel On Tue, 19 Nov 2002, Hugh Dickins wrote: > On Tue, 19 Nov 2002, Steffen Persvold wrote: > > > > I've two boxes with Dual Xeons 1.8 GHz and HT option enabled in BIOS. When > > I boot 2.4.20-rc2 with default arguments the kernel detects 4 processors and > > also reports 4 processors in /proc/cpuinfo wiht the "ht" feature. > > > > However, if I boot with the "noht" option (wich I believed turned off HT > > and therefore only two processors should be available), the kernel still > > detects 4 processors, _but_ now the "ht" feature in /proc/cpuinfo is not > > there. Is this the intention of the "noht" option ? > > No, the intention of the "noht" option is as you believed, and it used to > work that way. I looked at latest sourcec, didn't see anything obviously > wrong. Sorry, but I don't have a suitable HT machine to check at present. > > > If so, are there any > > options available to turn off HT support in the kernel completely, so that > > I don't have to go into the BIOS to turn it off ? > > > > If you want to I can provide the dmesg output and .config. > > > > I think this issue is not just related to 2.4.20-rc2, but earlier kernels > > aswell. > > Could others check and report if 2.4.20-rc2 "noht" works for them or not? > Thanks for your reply Hugh, After digging into it a bit, I _think_ I know what happens. When the machine is bootet with default parameters, the processors are detected in the ACPI table, and the MP table search is skipped : Linux version 2.4.20-rc2 (root@puma1.office.scali.no) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #4 SMP Sat Nov 16 14:06:13 CET 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f400 (usable) BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000d8000 - 00000000000e0000 (reserved) BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003fef0000 (usable) BIOS-e820: 000000003fef0000 - 000000003fefc000 (ACPI data) BIOS-e820: 000000003fefc000 - 000000003ff00000 (ACPI NVS) BIOS-e820: 000000003ff00000 - 000000003ff80000 (usable) BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f7030 hm, page 000f7000 reserved twice. hm, page 000f8000 reserved twice. hm, page 0009f000 reserved twice. hm, page 000a0000 reserved twice. On node 0 totalpages: 262016 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32640 pages. ACPI: Searched entire block, no RSDP was found. ACPI: RSDP located at physical address c00f7090 RSD PTR v0 [PTLTD ] __va_range(0x3fef84e0, 0x68): idx=8 mapped at ffff6000 ACPI table found: RSDT v1 [PTLTD RSDT 1540.0] __va_range(0x3fefbe78, 0x24): idx=8 mapped at ffff6000 __va_range(0x3fefbe78, 0x74): idx=8 mapped at ffff6000 ACPI table found: FACP v1 [INTEL K_CANYON 1540.0] __va_range(0x3fefbeec, 0x24): idx=8 mapped at ffff6000 __va_range(0x3fefbeec, 0x9c): idx=8 mapped at ffff6000 ACPI table found: APIC v1 [PTLTD APIC 1540.0] __va_range(0x3fefbeec, 0x9c): idx=8 mapped at ffff6000 LAPIC (acpi_id[0x0000] id[0x0] enabled[1]) CPU 0 (0x0000) enabledProcessor #0 Pentium 4(tm) XEON(tm) APIC version 16 LAPIC (acpi_id[0x0001] id[0x6] enabled[1]) CPU 1 (0x0600) enabledProcessor #6 Pentium 4(tm) XEON(tm) APIC version 16 LAPIC (acpi_id[0x0002] id[0x1] enabled[1]) CPU 2 (0x0100) enabledProcessor #1 Pentium 4(tm) XEON(tm) APIC version 16 LAPIC (acpi_id[0x0003] id[0x7] enabled[1]) CPU 3 (0x0700) enabledProcessor #7 Pentium 4(tm) XEON(tm) APIC version 16 IOAPIC (id[0x2] address[0xfec00000] global_irq_base[0x0]) IOAPIC (id[0x3] address[0xfec80000] global_irq_base[0x18]) IOAPIC (id[0x4] address[0xfec80400] global_irq_base[0x30]) INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x1] trigger[0x1]) INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] trigger[0x3]) LAPIC_NMI (acpi_id[0x0000] polarity[0x1] trigger[0x1] lint[0x1]) LAPIC_NMI (acpi_id[0x0001] polarity[0x1] trigger[0x1] lint[0x1]) LAPIC_NMI (acpi_id[0x0002] polarity[0x1] trigger[0x1] lint[0x1]) LAPIC_NMI (acpi_id[0x0003] polarity[0x1] trigger[0x1] lint[0x1]) 4 CPUs total Local APIC address fee00000 __va_range(0x3fefbf88, 0x24): idx=8 mapped at ffff6000 __va_range(0x3fefbf88, 0x28): idx=8 mapped at ffff6000 ACPI table found: BOOT v1 [PTLTD $SBFTBL$ 1540.0] __va_range(0x3fefbfb0, 0x24): idx=8 mapped at ffff6000 __va_range(0x3fefbfb0, 0x50): idx=8 mapped at ffff6000 ACPI table found: SPCR v1 [PTLTD $UCRTBL$ 1540.0] Enabling the CPU's according to the ACPI table Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: Product ID: Kings Canyon APIC at: 0xFEE00000 I/O APIC #2 Version 32 at 0xFEC00000. I/O APIC #3 Version 32 at 0xFEC80000. I/O APIC #4 Version 32 at 0xFEC80400. Processors: 4 Kernel command line: ro root=LABEL=/ console=ttyS0,9600n8 nmi_watchdog=1 [snip] However, when I boot the machine with the "noht" option the ACPI table search is skipped, _but_ it still finds 4 processors in the MP table : Linux version 2.4.20-rc2 (root@puma1.office.scali.no) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #4 SMP Sat Nov 16 14:06:13 CET 2002 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f400 (usable) BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) BIOS-e820: 00000000000d8000 - 00000000000e0000 (reserved) BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003fef0000 (usable) BIOS-e820: 000000003fef0000 - 000000003fefc000 (ACPI data) BIOS-e820: 000000003fefc000 - 000000003ff00000 (ACPI NVS) BIOS-e820: 000000003ff00000 - 000000003ff80000 (usable) BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) 127MB HIGHMEM available. 896MB LOWMEM available. found SMP MP-table at 000f7030 hm, page 000f7000 reserved twice. hm, page 000f8000 reserved twice. hm, page 0009f000 reserved twice. hm, page 000a0000 reserved twice. On node 0 totalpages: 262016 zone(0): 4096 pages. zone(1): 225280 pages. zone(2): 32640 pages. Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: Product ID: Kings Canyon APIC at: 0xFEE00000 Processor #0 Pentium 4(tm) XEON(tm) APIC version 20 Processor #6 Pentium 4(tm) XEON(tm) APIC version 20 Processor #1 Pentium 4(tm) XEON(tm) APIC version 20 Processor #7 Pentium 4(tm) XEON(tm) APIC version 20 I/O APIC #2 Version 32 at 0xFEC00000. I/O APIC #3 Version 32 at 0xFEC80000. I/O APIC #4 Version 32 at 0xFEC80400. Processors: 4 Kernel command line: ro root=LABEL=/ console=ttyS0,9600n8 nmi_watchdog=1 noht Since the HT feature is enabled in the BIOS it seems normal to me that 4 processors are reported both in the MP table and in the ACPI table. Shouldn't the 'noht' option handle this ? I have two of these machines and can assist in testing out patches etc. Regards, -- Steffen Persvold | Scali AS mailto:sp@scali.com | http://www.scali.com Tel: (+47) 2262 8950 | Olaf Helsets vei 6 Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG?] Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-20 9:56 ` Steffen Persvold @ 2002-11-20 12:53 ` Hugh Dickins 2002-11-20 13:04 ` Arjan van de Ven 0 siblings, 1 reply; 10+ messages in thread From: Hugh Dickins @ 2002-11-20 12:53 UTC (permalink / raw) To: Steffen Persvold; +Cc: Jun Nakajima, Arjan van de Ven, linux-kernel On Wed, 20 Nov 2002, Steffen Persvold wrote: > On Tue, 19 Nov 2002, Hugh Dickins wrote: > > On Tue, 19 Nov 2002, Steffen Persvold wrote: > > > > > > I've two boxes with Dual Xeons 1.8 GHz and HT option enabled in BIOS. When > > > I boot 2.4.20-rc2 with default arguments the kernel detects 4 processors and > > > also reports 4 processors in /proc/cpuinfo wiht the "ht" feature. > > > > > > However, if I boot with the "noht" option (wich I believed turned off HT > > > and therefore only two processors should be available), the kernel still > > > detects 4 processors, _but_ now the "ht" feature in /proc/cpuinfo is not > > > there. Is this the intention of the "noht" option ? > > > > No, the intention of the "noht" option is as you believed, and it used to > > work that way. I looked at latest sourcec, didn't see anything obviously > > wrong. Sorry, but I don't have a suitable HT machine to check at present. > > > > > If so, are there any > > > options available to turn off HT support in the kernel completely, so that > > > I don't have to go into the BIOS to turn it off ? > > > > > > If you want to I can provide the dmesg output and .config. > > > > > > I think this issue is not just related to 2.4.20-rc2, but earlier kernels > > > aswell. > > > > Could others check and report if 2.4.20-rc2 "noht" works for them or not? > > > > Thanks for your reply Hugh, > > After digging into it a bit, I _think_ I know what happens. When the > machine is bootet with default parameters, the processors are detected in > the ACPI table, and the MP table search is skipped : > > Linux version 2.4.20-rc2 (root@puma1.office.scali.no) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #4 SMP Sat Nov 16 14:06:13 CET 2002 > BIOS-provided physical RAM map: > BIOS-e820: 0000000000000000 - 000000000009f400 (usable) > BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) > BIOS-e820: 00000000000d8000 - 00000000000e0000 (reserved) > BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) > BIOS-e820: 0000000000100000 - 000000003fef0000 (usable) > BIOS-e820: 000000003fef0000 - 000000003fefc000 (ACPI data) > BIOS-e820: 000000003fefc000 - 000000003ff00000 (ACPI NVS) > BIOS-e820: 000000003ff00000 - 000000003ff80000 (usable) > BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) > BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) > BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) > 127MB HIGHMEM available. > 896MB LOWMEM available. > found SMP MP-table at 000f7030 > hm, page 000f7000 reserved twice. > hm, page 000f8000 reserved twice. > hm, page 0009f000 reserved twice. > hm, page 000a0000 reserved twice. > On node 0 totalpages: 262016 > zone(0): 4096 pages. > zone(1): 225280 pages. > zone(2): 32640 pages. > ACPI: Searched entire block, no RSDP was found. > ACPI: RSDP located at physical address c00f7090 > RSD PTR v0 [PTLTD ] > __va_range(0x3fef84e0, 0x68): idx=8 mapped at ffff6000 > ACPI table found: RSDT v1 [PTLTD RSDT 1540.0] > __va_range(0x3fefbe78, 0x24): idx=8 mapped at ffff6000 > __va_range(0x3fefbe78, 0x74): idx=8 mapped at ffff6000 > ACPI table found: FACP v1 [INTEL K_CANYON 1540.0] > __va_range(0x3fefbeec, 0x24): idx=8 mapped at ffff6000 > __va_range(0x3fefbeec, 0x9c): idx=8 mapped at ffff6000 > ACPI table found: APIC v1 [PTLTD APIC 1540.0] > __va_range(0x3fefbeec, 0x9c): idx=8 mapped at ffff6000 > LAPIC (acpi_id[0x0000] id[0x0] enabled[1]) > CPU 0 (0x0000) enabledProcessor #0 Pentium 4(tm) XEON(tm) APIC version 16 > > LAPIC (acpi_id[0x0001] id[0x6] enabled[1]) > CPU 1 (0x0600) enabledProcessor #6 Pentium 4(tm) XEON(tm) APIC version 16 > > LAPIC (acpi_id[0x0002] id[0x1] enabled[1]) > CPU 2 (0x0100) enabledProcessor #1 Pentium 4(tm) XEON(tm) APIC version 16 > > LAPIC (acpi_id[0x0003] id[0x7] enabled[1]) > CPU 3 (0x0700) enabledProcessor #7 Pentium 4(tm) XEON(tm) APIC version 16 > > IOAPIC (id[0x2] address[0xfec00000] global_irq_base[0x0]) > IOAPIC (id[0x3] address[0xfec80000] global_irq_base[0x18]) > IOAPIC (id[0x4] address[0xfec80400] global_irq_base[0x30]) > INT_SRC_OVR (bus[0] irq[0x0] global_irq[0x2] polarity[0x1] trigger[0x1]) > INT_SRC_OVR (bus[0] irq[0x9] global_irq[0x9] polarity[0x1] trigger[0x3]) > LAPIC_NMI (acpi_id[0x0000] polarity[0x1] trigger[0x1] lint[0x1]) > LAPIC_NMI (acpi_id[0x0001] polarity[0x1] trigger[0x1] lint[0x1]) > LAPIC_NMI (acpi_id[0x0002] polarity[0x1] trigger[0x1] lint[0x1]) > LAPIC_NMI (acpi_id[0x0003] polarity[0x1] trigger[0x1] lint[0x1]) > 4 CPUs total > Local APIC address fee00000 > __va_range(0x3fefbf88, 0x24): idx=8 mapped at ffff6000 > __va_range(0x3fefbf88, 0x28): idx=8 mapped at ffff6000 > ACPI table found: BOOT v1 [PTLTD $SBFTBL$ 1540.0] > __va_range(0x3fefbfb0, 0x24): idx=8 mapped at ffff6000 > __va_range(0x3fefbfb0, 0x50): idx=8 mapped at ffff6000 > ACPI table found: SPCR v1 [PTLTD $UCRTBL$ 1540.0] > Enabling the CPU's according to the ACPI table > Intel MultiProcessor Specification v1.4 > Virtual Wire compatibility mode. > OEM ID: Product ID: Kings Canyon APIC at: 0xFEE00000 > I/O APIC #2 Version 32 at 0xFEC00000. > I/O APIC #3 Version 32 at 0xFEC80000. > I/O APIC #4 Version 32 at 0xFEC80400. > Processors: 4 > Kernel command line: ro root=LABEL=/ console=ttyS0,9600n8 nmi_watchdog=1 > [snip] > > > However, when I boot the machine with the "noht" option the ACPI table > search is skipped, _but_ it still finds 4 processors in the MP table : > > Linux version 2.4.20-rc2 (root@puma1.office.scali.no) (gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7)) #4 SMP Sat Nov 16 14:06:13 CET 2002 > BIOS-provided physical RAM map: > BIOS-e820: 0000000000000000 - 000000000009f400 (usable) > BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved) > BIOS-e820: 00000000000d8000 - 00000000000e0000 (reserved) > BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) > BIOS-e820: 0000000000100000 - 000000003fef0000 (usable) > BIOS-e820: 000000003fef0000 - 000000003fefc000 (ACPI data) > BIOS-e820: 000000003fefc000 - 000000003ff00000 (ACPI NVS) > BIOS-e820: 000000003ff00000 - 000000003ff80000 (usable) > BIOS-e820: 000000003ff80000 - 0000000040000000 (reserved) > BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > BIOS-e820: 00000000ff800000 - 00000000ffc00000 (reserved) > BIOS-e820: 00000000fff00000 - 0000000100000000 (reserved) > 127MB HIGHMEM available. > 896MB LOWMEM available. > found SMP MP-table at 000f7030 > hm, page 000f7000 reserved twice. > hm, page 000f8000 reserved twice. > hm, page 0009f000 reserved twice. > hm, page 000a0000 reserved twice. > On node 0 totalpages: 262016 > zone(0): 4096 pages. > zone(1): 225280 pages. > zone(2): 32640 pages. > Intel MultiProcessor Specification v1.4 > Virtual Wire compatibility mode. > OEM ID: Product ID: Kings Canyon APIC at: 0xFEE00000 > Processor #0 Pentium 4(tm) XEON(tm) APIC version 20 > Processor #6 Pentium 4(tm) XEON(tm) APIC version 20 > Processor #1 Pentium 4(tm) XEON(tm) APIC version 20 > Processor #7 Pentium 4(tm) XEON(tm) APIC version 20 > I/O APIC #2 Version 32 at 0xFEC00000. > I/O APIC #3 Version 32 at 0xFEC80000. > I/O APIC #4 Version 32 at 0xFEC80400. > Processors: 4 > Kernel command line: ro root=LABEL=/ console=ttyS0,9600n8 nmi_watchdog=1 noht > > Since the HT feature is enabled in the BIOS it seems normal to me that 4 > processors are reported both in the MP table and in the ACPI table. > Shouldn't the 'noht' option handle this ? > > I have two of these machines and can assist in testing out patches etc. I know too little to comment definitively, but it's my understanding that a dual HT machine should only show 2 processors in its MP table, their siblings only appearing through analysis of the ACPI tables. Whether it's that your MP table has been wrongly set up, or that you've really been given 4 processors when you only asked for 2 (sue your supplier!), I cannot say. I've copied Jun at Intel and Arjan at RedHat, and hope they can shed more light on this. Hugh ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG?] Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-20 12:53 ` Hugh Dickins @ 2002-11-20 13:04 ` Arjan van de Ven 2002-11-20 13:27 ` Steffen Persvold 0 siblings, 1 reply; 10+ messages in thread From: Arjan van de Ven @ 2002-11-20 13:04 UTC (permalink / raw) To: Hugh Dickins Cc: Steffen Persvold, Jun Nakajima, Arjan van de Ven, linux-kernel On Wed, Nov 20, 2002 at 12:53:04PM +0000, Hugh Dickins wrote: > > I know too little to comment definitively, but it's my understanding > that a dual HT machine should only show 2 processors in its MP table, > their siblings only appearing through analysis of the ACPI tables. > > Whether it's that your MP table has been wrongly set up, or that > you've really been given 4 processors when you only asked for 2 > (sue your supplier!), I cannot say. I've copied Jun at Intel > and Arjan at RedHat, and hope they can shed more light on this. Linux has zero problem with a sane MP table that lists all CPU's. Intel normally seems to recommend against it (maybe N3.51 doesn't like it or so) but it's all fair as far as I'm concerned. The bios is supposed to offer you a choice to disable hyperthreading, use that ;) Greetings, Arjan van de Ven -- But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it. [sect.2 GPL] ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG?] Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-20 13:04 ` Arjan van de Ven @ 2002-11-20 13:27 ` Steffen Persvold 2002-11-20 13:26 ` Arjan van de Ven 0 siblings, 1 reply; 10+ messages in thread From: Steffen Persvold @ 2002-11-20 13:27 UTC (permalink / raw) To: Arjan van de Ven; +Cc: Hugh Dickins, Jun Nakajima, linux-kernel On Wed, 20 Nov 2002, Arjan van de Ven wrote: > On Wed, Nov 20, 2002 at 12:53:04PM +0000, Hugh Dickins wrote: > > > > I know too little to comment definitively, but it's my understanding > > that a dual HT machine should only show 2 processors in its MP table, > > their siblings only appearing through analysis of the ACPI tables. > > > > Whether it's that your MP table has been wrongly set up, or that > > you've really been given 4 processors when you only asked for 2 > > (sue your supplier!), I cannot say. I've copied Jun at Intel > > and Arjan at RedHat, and hope they can shed more light on this. > > Linux has zero problem with a sane MP table that lists all > CPU's. Intel normally seems to recommend against it (maybe N3.51 doesn't > like it or so) but it's all fair as far as I'm concerned. > The bios is supposed to offer you a choice > to disable hyperthreading, use that ;) > Sure, the bios has this option (and it works). I just believed the 'noht' option would disable it from a kernel perspective. I understand that if the MP table lists 4 processors, the kernel must think it is 4 processors and enable them. But what is the purpose of the 'noht' option ? If it is to avoid scanning the ACPI table for CPUs, wouldn't it be less confusing to call it something like 'acpismp=disable', since you apparently can't disable the siblings anyway (when they are also listed in the MP table) ? Regards, -- Steffen Persvold | Scali AS mailto:sp@scali.com | http://www.scali.com Tel: (+47) 2262 8950 | Olaf Helsets vei 6 Fax: (+47) 2262 8951 | N0621 Oslo, NORWAY ^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: [BUG?] Xeon with HyperThreading and linux-2.4.20-rc2 2002-11-20 13:27 ` Steffen Persvold @ 2002-11-20 13:26 ` Arjan van de Ven 0 siblings, 0 replies; 10+ messages in thread From: Arjan van de Ven @ 2002-11-20 13:26 UTC (permalink / raw) To: Steffen Persvold Cc: Arjan van de Ven, Hugh Dickins, Jun Nakajima, linux-kernel On Wed, Nov 20, 2002 at 02:27:20PM +0100, Steffen Persvold wrote: > > Sure, the bios has this option (and it works). I just believed the 'noht' > option would disable it from a kernel perspective. I understand that if > the MP table lists 4 processors, the kernel must think it is 4 processors > and enable them. But what is the purpose of the 'noht' option ? If it is > to avoid scanning the ACPI table for CPUs, wouldn't it be less confusing > to call it something like 'acpismp=disable', since you apparently can't > disable the siblings anyway (when they are also listed in the MP table) ? in theory we can, at least with the O(1) scheduling infrastructure it's easy. it's just that nobody cared enough so far to do it ^ permalink raw reply [flat|nested] 10+ messages in thread
* Every semaphore call results in "uninterruptable sleep" @ 2002-11-15 12:01 Kammerloher, Josef 0 siblings, 0 replies; 10+ messages in thread From: Kammerloher, Josef @ 2002-11-15 12:01 UTC (permalink / raw) To: 'linux-kernel@vger.kernel.org' I use SuSE 8.1 ( kernel 2.4.19-4GB) and a program with semaphores. It runs okay on many PCs and laptops except one laptop (with Pentium Mobile). Every semaphore function (semget(),..) , "ipcs -s" ... results in "uninterruptable sleep". The processes cannot be killed by kill -9. cat /proc/sys/kernel/sem returns 250 256000 32 1024 I always use the default kernel without special configurations. What can I do ?? Thanks for your help, Josef ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2002-11-20 13:19 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2002-11-15 18:03 Every semaphore call results in "uninterruptable sleep" Manfred Spraul 2002-11-16 13:26 ` Xeon with HyperThreading and linux-2.4.20-rc2 Steffen Persvold 2002-11-19 21:09 ` [BUG?] " Steffen Persvold 2002-11-19 21:42 ` Hugh Dickins 2002-11-20 9:56 ` Steffen Persvold 2002-11-20 12:53 ` Hugh Dickins 2002-11-20 13:04 ` Arjan van de Ven 2002-11-20 13:27 ` Steffen Persvold 2002-11-20 13:26 ` Arjan van de Ven -- strict thread matches above, loose matches on Subject: below -- 2002-11-15 12:01 Every semaphore call results in "uninterruptable sleep" Kammerloher, Josef
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.