There was a Kconfig bug found sometime back which made CONFIG_X86_VSMP
disappear from the .config. The bug description is as follows:
On a linux-2.6.25.6 source tree, x86_64 arch,
1. Use make menuconfig to select "Processor type and features" menu
2. Change Subarchitecture type from "PC-Compatible" to
"Support for ScaleMP vSMP"
3. Exit and save configuration. Make sure CONFIG_X86_VSMP is selected in
.config
4. Build the kernel and recheck the .config for CONFIG_X86_VSMP --
CONFIG_X86_VSMP disappeared! However, vsmp bits get built and linked
in. On booting up the resulting kernel on a ScaleMP vSMPowered machine,
dmesg shows printks that ought to happen if CONFIG_X86_VSMP is set, however,
/proc/config.gz says CONFIG_X86_VSMP is unset! The inter-node cacheline
setting (CONFIG_X86_INTERNODE_CACHE_BYTE) which is dependent on
CONFIG_X86_VSMP is not set correctly in /proc/config.gz either. Hence,
we can't be sure if INTERNODE_CACHE_BYTE is set correctly
5. Running 'make oldconfig' or 'make menuconfig' again after 3. causes
CONFIG_X86_VSMP to vanish.
This bug was reported sometime back and fixed in x86 tree and eventually in
2.6.26-rc.
The original bug report can be found at:
http://lkml.org/lkml/2008/2/26/318
The fixes were posted by Roman in the same thread:
http://lkml.org/lkml/2008/2/28/575
The fixes consisted of 3 patches, but the first one is sufficient to fix the
problem in 2.6.25
The commits in mainline for the fix are:
823c248e7cc75b4f22da914b01f8e5433cff197e
48981178869bf7d9770f11fc361996ad11217a75
5a1aa8a1aff6191ecc55f21d8b5f0e47108ed91b
Please consider a trimmed down version of the first patch --
823c248e7cc75b4f22da914b01f8e5433cff197e, which is sufficient to fix
the CONFIG_X86_VSMP disappearance for stable release. CONFIG_X86_VSMP
has been well supported and working well since 2.6.16. Not able to choose
CONFIG_X86_VSMP reliably is a major regression. Users compiling
kernel.org 2.6.25 kernel for vSMP have been reporting problems which are
mainly due to CONFIG_X86_VSMP disappearing. In addition /proc/config.gz
mismatch due to the bug is a major PITA.
I am including a trimmed down patch of
823c248e7cc75b4f22da914b01f8e5433cff197e to fix CONFIG_VSMP as per
stable policy. This was tested and found to fix the problem mentioned
above. Please apply.
Thanks,
Kiran
---
x86: fix recursive dependencies with CONFIG_VSMP
Trimmed down version of the commit
823c248e7cc75b4f22da914b01f8e5433cff197e
Originally-by: Roman Zippel <[email protected]>
Signed-off-by: Ravikiran Thirumalai <[email protected]>
Index: linux-2.6.25.6/arch/x86/Kconfig
===================================================================
--- linux-2.6.25.6.orig/arch/x86/Kconfig 2008-06-12 18:09:37.000000000 -0700
+++ linux-2.6.25.6/arch/x86/Kconfig 2008-06-12 18:25:04.000000000 -0700
@@ -339,7 +339,7 @@ config X86_RDC321X
config X86_VSMP
bool "Support for ScaleMP vSMP"
- depends on X86_64 && PCI
+ depends on X86_64
help
Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
supposed to run on these EM64T-based machines. Only choose this option
@@ -1391,7 +1391,7 @@ endmenu
menu "Bus options (PCI etc.)"
config PCI
- bool "PCI support" if !X86_VISWS
+ bool "PCI support" if !X86_VISWS && !X86_VSMP
depends on !X86_VOYAGER
default y
select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
* Ravikiran G Thirumalai <[email protected]> wrote:
> I am including a trimmed down patch of
> 823c248e7cc75b4f22da914b01f8e5433cff197e to fix CONFIG_VSMP as per
> stable policy. This was tested and found to fix the problem mentioned
> above. Please apply.
hm, but why did you trim it down? I'd suggest we use the full
823c248e7cc75b4 patch because that's what had been tested upstream.
Ingo
On Fri, Jun 13, 2008 at 06:48:58AM +0200, Ingo Molnar wrote:
>
>* Ravikiran G Thirumalai <[email protected]> wrote:
>
>> I am including a trimmed down patch of
>> 823c248e7cc75b4f22da914b01f8e5433cff197e to fix CONFIG_VSMP as per
>> stable policy. This was tested and found to fix the problem mentioned
>> above. Please apply.
>
>hm, but why did you trim it down? I'd suggest we use the full
>823c248e7cc75b4 patch because that's what had been tested upstream.
Was just following the "It must fix only one thing" rule for stable,
and being a bit over-conservative I guess. The changes were only to VSMP
parts keeping the impact minimal.
If 823c248e7cc75b4f22da914b01f8e5433cff197e can be applied completely then
great! Here's the commit slightly re-diffed for 2.6.25
Thanks,
Kiran
---
From: Roman Zippel <[email protected]>
Mainline commit: 823c248e7cc75b4f22da914b01f8e5433cff197e
x86: fix recursive dependencies
The proper dependency check uncovered a few dependency problems,
the sub-architecture used a mixture of selects and depends on SMP
and PCI dependency was messed up.
Signed-off-by: Ravikiran Thirumalai <[email protected]>
Index: linux-2.6.25.4/arch/x86/Kconfig
===================================================================
--- linux-2.6.25.4.orig/arch/x86/Kconfig 2008-05-15 08:00:12.000000000 -0700
+++ linux-2.6.25.4/arch/x86/Kconfig 2008-06-06 16:05:46.405250939 -0700
@@ -253,8 +253,7 @@ config X86_ELAN
config X86_VOYAGER
bool "Voyager (NCR)"
- depends on X86_32
- select SMP if !BROKEN
+ depends on X86_32 && (SMP || BROKEN)
help
Voyager is an MCA-based 32-way capable SMP architecture proprietary
to NCR Corp. Machine classes 345x/35xx/4100/51xx are Voyager-based.
@@ -266,9 +265,8 @@ config X86_VOYAGER
config X86_NUMAQ
bool "NUMAQ (IBM/Sequent)"
- select SMP
+ depends on SMP && X86_32
select NUMA
- depends on X86_32
help
This option is used for getting Linux to run on a (IBM/Sequent) NUMA
multiquad box. This changes the way that processors are bootstrapped,
@@ -339,7 +337,7 @@ config X86_RDC321X
config X86_VSMP
bool "Support for ScaleMP vSMP"
- depends on X86_64 && PCI
+ depends on X86_64
help
Support for ScaleMP vSMP systems. Say 'Y' here if this kernel is
supposed to run on these EM64T-based machines. Only choose this option
@@ -1391,7 +1389,7 @@ endmenu
menu "Bus options (PCI etc.)"
config PCI
- bool "PCI support" if !X86_VISWS
+ bool "PCI support" if !X86_VISWS && !X86_VSMP
depends on !X86_VOYAGER
default y
select ARCH_SUPPORTS_MSI if (X86_LOCAL_APIC && X86_IO_APIC)
* Ravikiran G Thirumalai <[email protected]> wrote:
> If 823c248e7cc75b4f22da914b01f8e5433cff197e can be applied completely then
> great! Here's the commit slightly re-diffed for 2.6.25
>
> Thanks,
> Kiran
>
> ---
>
> From: Roman Zippel <[email protected]>
> Mainline commit: 823c248e7cc75b4f22da914b01f8e5433cff197e
>
> x86: fix recursive dependencies
>
> The proper dependency check uncovered a few dependency problems,
> the sub-architecture used a mixture of selects and depends on SMP
> and PCI dependency was messed up.
>
>
> Signed-off-by: Ravikiran Thirumalai <[email protected]>
btw., you can keep signoffs in such cases, i.e. make it:
Signed-off-by: Roman Zippel <[email protected]>
Signed-off-by: Ingo Molnar <[email protected]>
Signed-off-by: Ravikiran Thirumalai <[email protected]>
Ingo