Re: RFC: [2.6 patch] better i386 CPU selection

Re: RFC: [2.6 patch] better i386 CPU selection

[Mikael Pettersson]

On Sun, 7 Sep 2003 19:51:50 +0200, Adrian Bunk wrote:
>> >In 2.6 selecting M486 means that only the 486 is supported.
>> 
>> Can you prove your claim about 2.6?
>> 
>> There is to the best of my knowledge nothing in 2.6.0-test4
>> that prevents a kernel compiled for CPU type N from working
>> with CPU types >N. Just to prove it, I built a CONFIG_M486
>> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.
>
>Look at X86_L1_CACHE_SHIFT in arch/i386/Kconfig.

I have. All it does is change how much space the kernel
allocates to spinlocks and some other structures. This is
merely an optimisation primarily for SMP. This does not
prevent code from executing correctly on CPUs having a
different actual L1 cache line size.

>> (In case 2 configure for PIII and use that on PIII and P4.)
>> 
>> Maybe I'm missing something but I don't see any problem here.
>
>In current 2.6 this is only legal with X86_GENERIC enabled.

No. You're over-interpreting X86_GENERIC. All it does is
change some optimisation defaults. It is not required for
correctness.

/Mikael

Re: RFC: [2.6 patch] better i386 CPU selection

[John Bradford]

> > Nothing will change, except that if you want to support all CPUs, you 
> > have to select all CPUs instead of 386.
>
> This is incorrect.  You don't want to change the behavior that people 
> are relying on.

Does it matter over a major version change?  Surely as long as the
help text is sufficiently updated it's OK?  Loads of other things have
subtly changed...

John.

Re: RFC: [2.6 patch] better i386 CPU selection

[John Bradford]

> > > I don't like the current user interface that says "if you want to
> > > support both an Athlon and a Pentium 4 in your kernel use the Pentium III
> > > option. And for better optimization, also check the "generic" option".

If we go with the bitmap of processors to support idea, the generic option will be unnecessary.

You would then be able to:

* Support, (I.E. include workarounds for, and not include instructions
  that are not supported by), as many or as few processors as you
  desire.

* Optimise, (I.E. set alignment, and code generation within the subset
  of instructions permitted in the 'Support' selection above), for one
  specific processor.

> > The big issue with your ifdefing of workarounds is that it causes subtle
> > support problems. A lot of settings for specific CPUs boot and work
> > fine on other CPUs (possibly with small performance impact, but they're
> > rarely noticeable without explicit benchmarking). Just when you don't
> > include the workarounds for the bugs on these other CPUs it will boot and
> > even run, but fail mysteriously once a month. And that would be a support
> > nightmare.

> it sounds like a nessasary part of this patch would be to detect the CPU
> type and complain VERY loudly if it's not one supported by the build.
>
> This is probably a good idea anyway.

It is a good idea for 99% of kernels, but still needs to be configurable.

Maybe the option should not be present in the kernel configurator, and
require manual editing of the .config file to enable it.

John.

Re: RFC: [2.6 patch] better i386 CPU selection

[Andi Kleen]

Adrian Bunk <bunk@fs.tum.de> writes:
>
> I don't like the current user interface that says "if you want to 
> support both an Athlon and a Pentium 4 in your kernel use the Pentium III
> option. And for better optimization, also check the "generic" option".

The big issue with your ifdefing of workarounds is that it causes subtle 
support problems. A lot of settings for specific CPUs boot and work
fine on other CPUs (possibly with small performance impact, but they're
rarely noticeable without explicit benchmarking). Just when you don't 
include the workarounds for the bugs on these other CPUs it will boot and 
even run, but fail mysteriously once a month. And that would be a support 
nightmare.

-Andi

Re: RFC: [2.6 patch] better i386 CPU selection

[David Lang]

On Sun, 14 Sep 2003, Andi Kleen wrote:

> Adrian Bunk <bunk@fs.tum.de> writes:
> >
> > I don't like the current user interface that says "if you want to
> > support both an Athlon and a Pentium 4 in your kernel use the Pentium III
> > option. And for better optimization, also check the "generic" option".
>
> The big issue with your ifdefing of workarounds is that it causes subtle
> support problems. A lot of settings for specific CPUs boot and work
> fine on other CPUs (possibly with small performance impact, but they're
> rarely noticeable without explicit benchmarking). Just when you don't
> include the workarounds for the bugs on these other CPUs it will boot and
> even run, but fail mysteriously once a month. And that would be a support
> nightmare.
>

it sounds like a nessasary part of this patch would be to detect the CPU
type and complain VERY loudly if it's not one supported by the build.

This is probably a good idea anyway.

David Lang

RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

The most important changes since the first version of this patch:
- arch/i386/Makefile updates
- X86_GOOD_APIC -> X86_BAD_APIC
- made arch/i386/kernel/cpu{,mtrr/}/Makefile CPU specific

A 2.6.0-test5 kernel with this patch applied compiled and bootet on
my K6.

This patch makes the bzImage for my computer (same .config, same 
compiler, same compiler options) a good 5 kB smaller.

I'd appreciate it if more people could try this patch and report whether 
their kernel compiles and works.


The patch below tries to implement a better i386 CPU selection.

In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
on a 486 and above.

In 2.6 selecting M486 means that only the 486 is supported.

The help text for the X86_GENERIC option says it generates a generic 
kernel but the implementation is that it supports CPUs of the selected 
M* option and above.

There are two different needs:
1. the installation kernel of a distribution should support all CPUs 
   this distribution supports (perhaps starting with the 386)
2. a sysadmin might e.g. want a kernel that support both a Pentium-III
   and a Pentium 4, but doesn't need to support a 386

The implementation in 2.4 was near to satisfy need 2., if X86_GENERIC in 
2.6 was implemented as the help text says it would satisfy the need
of 1.

The patch below against 2.6.0-test5 does a different implementation that
lets you select all CPUs you want to support and it should therefore
suit both needs.

Changes:
- changed the i386 CPU selection from a choice to single options for
  every cpu
- renamed the M* variables to CPU_*, this is needed to ask the users
  upgrading from older kernels instead of silently changing the 
  semantics
- made arch/i386/kernel/cpu/Makefile CPU specific
- made arch/i386/kernel/cpu/mtrr/Makefile CPU specific
- X86_GOOD_APIC -> X86_BAD_APIC
- AMD Elan is a different subarch, you can't configure a kernel that 
  runs on both the AMD Elan and other i386 CPUs
- added optimizing CFLAGS for the AMD Elan
- gcc 2.95 supports -march=k6 (no need for check_gcc)
- even gcc 3.3 doesn't seem to support -march=c3-2, use -march=c3 
- help text changes/updates

Questions/TODO:
- please check whether my changes to arch/i386/kernel/cpu{,mtrr/}/Makefile
  are correct
- which CPUs exactly need X86_ALIGNMENT_16?
- change include/asm-i386/module.h to use some kind of bitmask


diffstat output:

 arch/i386/Kconfig                  |  255 ++++++++++++-----------------
 arch/i386/Makefile                 |  104 +++++++++--
 arch/i386/boot/setup.S             |    2 
 arch/i386/kernel/cpu/Makefile      |   34 ++-
 arch/i386/kernel/cpu/common.c      |   27 +++
 arch/i386/kernel/cpu/mtrr/Makefile |   14 +
 arch/i386/kernel/cpu/mtrr/main.c   |   14 +
 arch/i386/lib/mmx.c                |    2 
 arch/i386/mm/init.c                |    6 
 drivers/serial/8250.h              |    2 
 include/asm-i386/apic.h            |    4 
 include/asm-i386/bugs.h            |    7 
 include/asm-i386/module.h          |    2 
 include/asm-i386/processor.h       |    4 
 include/asm-i386/timex.h           |    2 
 15 files changed, 292 insertions(+), 187 deletions(-)


cu
Adrian

--- linux-2.6.0-test5-cpu/arch/i386/Kconfig.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/Kconfig	2003-09-13 14:25:12.000000000 +0200
@@ -43,6 +43,15 @@
 	help
 	  Choose this option if your computer is a standard PC or compatible.
 
+config X86_ELAN
+	bool "Elan"
+	help
+	  Select this for an AMD Elan processor.
+	
+	  Do not use this option for K6/Athlon/Opteron processors!
+	
+	  If unsure choose "PC-compatible" instead.
+
 config X86_VOYAGER
 	bool "Voyager (NCR)"
 	help
@@ -125,48 +134,19 @@
 	default y
 	depends on SMP && X86_ES7000 && MPENTIUMIII
 
-choice
-	prompt "Processor family"
-	default M686
 
-config M386
-	bool "386"
-	---help---
-	  This is the processor type of your CPU. This information is used for
-	  optimizing purposes. In order to compile a kernel that can run on
-	  all x86 CPU types (albeit not optimally fast), you can specify
-	  "386" here.
-
-	  The kernel will not necessarily run on earlier architectures than
-	  the one you have chosen, e.g. a Pentium optimized kernel will run on
-	  a PPro, but not necessarily on a i486.
-
-	  Here are the settings recommended for greatest speed:
-	  - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
-	  486DLC/DLC2, UMC 486SX-S and NexGen Nx586.  Only "386" kernels
-	  will run on a 386 class machine.
-	  - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
-	  SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
-	  - "586" for generic Pentium CPUs lacking the TSC
-	  (time stamp counter) register.
-	  - "Pentium-Classic" for the Intel Pentium.
-	  - "Pentium-MMX" for the Intel Pentium MMX.
-	  - "Pentium-Pro" for the Intel Pentium Pro.
-	  - "Pentium-II" for the Intel Pentium II or pre-Coppermine Celeron.
-	  - "Pentium-III" for the Intel Pentium III or Coppermine Celeron.
-	  - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
-	  - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
-	  - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
-	  - "Crusoe" for the Transmeta Crusoe series.
-	  - "Winchip-C6" for original IDT Winchip.
-	  - "Winchip-2" for IDT Winchip 2.
-	  - "Winchip-2A" for IDT Winchips with 3dNow! capabilities.
-	  - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
-	  - "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above).
+if !X86_ELAN
+
+menu "Processor support"
 
-	  If you don't know what to do, choose "386".
+comment "Select all processors your kernel should support"
 
-config M486
+config CPU_386
+	bool "386"
+	help
+	  Select this for a 386 series processor.
+
+config CPU_486
 	bool "486"
 	help
 	  Select this for a 486 series processor, either Intel or one of the
@@ -174,227 +154,220 @@
 	  DX2, and DX4 variants; also SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or
 	  U5S.
 
-config M586
+config CPU_586
 	bool "586/K5/5x86/6x86/6x86MX"
 	help
-	  Select this for an 586 or 686 series processor such as the AMD K5,
-	  the Intel 5x86 or 6x86, or the Intel 6x86MX.  This choice does not
-	  assume the RDTSC (Read Time Stamp Counter) instruction.
+	  Select this for a non-Intel 586 or 686 series processor such as
+	  the AMD K5 or the Cyrix 6x86MX.
+	
+	  Several CPUs that have their own options below (e.g. AMD K6,
+	  Duron, Athlon and Opteeron, IDT Winchip, Cyrix III and
+	  VIA C3) do _not_ need this option.
+	
+	  This choice does not assume the RDTSC (Read Time Stamp Counter)
+	  instruction.
 
-config M586TSC
+config CPU_586TSC
 	bool "Pentium-Classic"
 	help
 	  Select this for a Pentium Classic processor with the RDTSC (Read
-	  Time Stamp Counter) instruction for benchmarking.
+	  Time Stamp Counter) instruction.
 
-config M586MMX
+config CPU_586MMX
 	bool "Pentium-MMX"
 	help
 	  Select this for a Pentium with the MMX graphics/multimedia
 	  extended instructions.
 
-config M686
+config CPU_686
 	bool "Pentium-Pro"
 	help
-	  Select this for Intel Pentium Pro chips.  This enables the use of
-	  Pentium Pro extended instructions, and disables the init-time guard
-	  against the f00f bug found in earlier Pentiums.
+	  Select this for Intel Pentium Pro chips.
 
-config MPENTIUMII
+config CPU_PENTIUMII
 	bool "Pentium-II/Celeron(pre-Coppermine)"
 	help
 	  Select this for Intel chips based on the Pentium-II and
-	  pre-Coppermine Celeron core.  This option enables an unaligned
-	  copy optimization, compiles the kernel with optimization flags
-	  tailored for the chip, and applies any applicable Pentium Pro
-	  optimizations.
+	  pre-Coppermine Celeron core.
 
-config MPENTIUMIII
+config CPU_PENTIUMIII
 	bool "Pentium-III/Celeron(Coppermine)/Pentium-III Xeon"
 	help
 	  Select this for Intel chips based on the Pentium-III and
-	  Celeron-Coppermine core.  This option enables use of some
-	  extended prefetch instructions in addition to the Pentium II
-	  extensions.
+	  Celeron-Coppermine core.
 
-config MPENTIUM4
+config CPU_PENTIUM4
 	bool "Pentium-4/Celeron(P4-based)/Xeon"
 	help
 	  Select this for Intel Pentium 4 chips.  This includes both
-	  the Pentium 4 and P4-based Celeron chips.  This option
-	  enables compile flags optimized for the chip, uses the
-	  correct cache shift, and applies any applicable Pentium III
-	  optimizations.
+	  the Pentium 4 and P4-based Celeron chips.
 
-config MK6
+config CPU_K6
 	bool "K6/K6-II/K6-III"
 	help
-	  Select this for an AMD K6-family processor.  Enables use of
-	  some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD K6, K6-II or K6-III (aka K6-3D).
 
-config MK7
+config CPU_K7
 	bool "Athlon/Duron/K7"
 	help
-	  Select this for an AMD Athlon K7-family processor.  Enables use of
-	  some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD Athlon K7-family processor.
 
-config MK8
+config CPU_K8
 	bool "Opteron/Athlon64/Hammer/K8"
 	help
-	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.  Enables
-	  use of some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.
 
-config MELAN
-	bool "Elan"
-
-config MCRUSOE
+config CPU_CRUSOE
 	bool "Crusoe"
 	help
-	  Select this for a Transmeta Crusoe processor.  Treats the processor
-	  like a 586 with TSC, and sets some GCC optimization flags (like a
-	  Pentium Pro with no alignment requirements).
+	  Select this for a Transmeta Crusoe processor.
 
-config MWINCHIPC6
+config CPU_WINCHIPC6
 	bool "Winchip-C6"
 	help
-	  Select this for an IDT Winchip C6 chip.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment requirements.
+	  Select this for an IDT Winchip C6 chip.
 
-config MWINCHIP2
+config CPU_WINCHIP2
 	bool "Winchip-2"
 	help
-	  Select this for an IDT Winchip-2.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment requirements.
+	  Select this for an IDT Winchip-2.
 
-config MWINCHIP3D
+config CPU_WINCHIP3D
 	bool "Winchip-2A/Winchip-3"
 	help
-	  Select this for an IDT Winchip-2A or 3.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment reqirements.  Also enable out of order memory
-	  stores for this CPU, which can increase performance of some
-	  operations.
-
-config MCYRIXIII
-	bool "CyrixIII/VIA-C3"
-	help
-	  Select this for a Cyrix III or C3 chip.  Presently Linux and GCC
-	  treat this chip as a generic 586. Whilst the CPU is 686 class,
-	  it lacks the cmov extension which gcc assumes is present when
-	  generating 686 code.
-	  Note that Nehemiah (Model 9) and above will not boot with this
-	  kernel due to them lacking the 3DNow! instructions used in earlier
-	  incarnations of the CPU.
+	  Select this for an IDT Winchip-2A or 3 with 3dNow!
+	  capabilities.
+
+config CPU_CYRIXIII
+	bool "Cyrix III/VIA C3"
+	help
+	  Select this for a Cyrix III or VIA C3 chip.
 
-config MVIAC3_2
+	  Note that Nehemiah (Model 9) and above need the next
+	  option instead.
+
+config CPU_VIAC3_2
 	bool "VIA C3-2 (Nehemiah)"
 	help
-	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
-	  of SSE and tells gcc to treat the CPU as a 686.
-	  Note, this kernel will not boot on older (pre model 9) C3s.
+	  Select this for a VIA C3 "Nehemiah" (model 9 and above).
 
-endchoice
+endmenu
 
-config X86_GENERIC
-       bool "Generic x86 support" 
-       help
-       	  Including some tuning for non selected x86 CPUs too.
-	  when it has moderate overhead. This is intended for generic 
-	  distributions kernels.
+endif
+
+#
+# helper options
+#
+config CPU_INTEL
+	bool
+	depends on CPU_386 || CPU_486 || CPU_586TSC || CPU_686 || CPU_PENTIUMII || CPU_PENTIUMIII || CPU_PENTIUM4
+
+config CPU_WINCHIP
+	bool
+	depends on CPU_WINCHIPC6 || CPU_WINCHIP2 || CPU_WINCHIP3D
+	default y
+
+config CPU_ONLY_K7
+	bool
+	depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_K8
+	bool
+	depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_WINCHIP
+	bool
+	depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
+	default y
 
 #
 # Define implied options from the CPU selection here
 #
 config X86_CMPXCHG
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_XADD
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_L1_CACHE_SHIFT
 	int
-	default "7" if MPENTIUM4 || X86_GENERIC
-	default "4" if MELAN || M486 || M386
-	default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2
-	default "6" if MK7 || MK8
+	default "7" if CPU_PENTIUM4
+	default "6" if CPU_K7 || CPU_K8
+	default "5" if CPU_WINCHIP || CPU_CRUSOE || CPU_CYRIXIII || CPU_K6 || CPU_PENTIUMIII || CPU_PENTIUMII || CPU_686 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_VIAC3_2
+	default "4" if X86_ELAN || CPU_486 || CPU_386
 
 config RWSEM_GENERIC_SPINLOCK
 	bool
-	depends on M386
+	depends on CPU_386
 	default y
 
 config RWSEM_XCHGADD_ALGORITHM
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_PPRO_FENCE
 	bool
-	depends on M686 || M586MMX || M586TSC || M586 || M486 || M386
+	depends on CPU_686
 	default y
 
 config X86_F00F_BUG
 	bool
-	depends on M586MMX || M586TSC || M586 || M486 || M386
+	depends on CPU_586MMX || CPU_586TSC
 	default y
 
 config X86_WP_WORKS_OK
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_INVLPG
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_BSWAP
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_POPAD_OK
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_ALIGNMENT_16
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
+	depends on CPU_WINCHIP || CPU_CYRIXIII || X86_ELAN || CPU_K6 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_486 || CPU_VIAC3_2
 	default y
 
-config X86_GOOD_APIC
+config X86_BAD_APIC
 	bool
-	depends on MK7 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
+	depends on CPU_586TSC
 	default y
 
 config X86_INTEL_USERCOPY
 	bool
-	depends on MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
+	depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_686 && !CPU_K6 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
 	default y
 
 config X86_USE_PPRO_CHECKSUM
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2
+	depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !X86_ELAN && !CPU_CRUSOE
 	default y
 
 config X86_USE_3DNOW
 	bool
-	depends on MCYRIXIII || MK7
+	depends on !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_VIAC3_2
 	default y
 
 config X86_OOSTORE
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6
+	depends on CPU_ONLY_WINCHIP
 	default y
 
 config HUGETLB_PAGE
@@ -517,7 +490,7 @@
 
 config X86_TSC
 	bool
-	depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
+	depends on !X86_NUMAQ && !CPU_386 && !CPU_486 && !CPU_586 && !X86_ELAN && !CPU_WINCHIPC6
 	default y
 
 config X86_MCE
--- linux-2.6.0-test5-cpu/arch/i386/Makefile.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/Makefile	2003-09-13 12:51:08.000000000 +0200
@@ -28,28 +28,94 @@
 
 align := $(subst -functions=0,,$(call check_gcc,-falign-functions=0,-malign-functions=0))
 
-cflags-$(CONFIG_M386)		+= -march=i386
-cflags-$(CONFIG_M486)		+= -march=i486
-cflags-$(CONFIG_M586)		+= -march=i586
-cflags-$(CONFIG_M586TSC)	+= -march=i586
-cflags-$(CONFIG_M586MMX)	+= $(call check_gcc,-march=pentium-mmx,-march=i586)
-cflags-$(CONFIG_M686)		+= -march=i686
-cflags-$(CONFIG_MPENTIUMII)	+= $(call check_gcc,-march=pentium2,-march=i686)
-cflags-$(CONFIG_MPENTIUMIII)	+= $(call check_gcc,-march=pentium3,-march=i686)
-cflags-$(CONFIG_MPENTIUM4)	+= $(call check_gcc,-march=pentium4,-march=i686)
-cflags-$(CONFIG_MK6)		+= $(call check_gcc,-march=k6,-march=i586)
+ifdef CONFIG_CPU_PENTIUM4
+  cpuflags-y	:= $(call check_gcc,-march=pentium4,-march=i686)
+endif
+
+ifdef CONFIG_CPU_K8
+  ifdef CONFIG_CPU_PENTIUM4
+    cpuflags-y	:= $(call check_gcc,-march=pentium3,-march=i686)
+  else
+    cpuflags-y	:= $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
+  endif
+endif
+
 # Please note, that patches that add -march=athlon-xp and friends are pointless.
 # They make zero difference whatsosever to performance at this time.
-cflags-$(CONFIG_MK7)		+= $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
-cflags-$(CONFIG_MK8)		+= $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
-cflags-$(CONFIG_MCRUSOE)	+= -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MWINCHIPC6)	+= $(call check_gcc,-march=winchip-c6,-march=i586)
-cflags-$(CONFIG_MWINCHIP2)	+= $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MWINCHIP3D)	+= $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MCYRIXIII)	+= $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MVIAC3_2)	+= $(call check_gcc,-march=c3-2,-march=i686)
+ifdef CONFIG_CPU_K7
+  ifdef CONFIG_CPU_PENTIUM4
+    cpuflags-y	:= $(call check_gcc,-march=pentium3,-march=i686)
+  else
+    cpuflags-y	:= $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
+  endif
+endif
+
+ifdef CONFIG_CPU_PENTIUMIII
+cpuflags-y	:= $(call check_gcc,-march=pentium3,-march=i686)
+endif
+
+ifdef CONFIG_CPU_PENTIUMII
+cpuflags-y	:= $(call check_gcc,-march=pentium2,-march=i686)
+endif
+
+ifdef CONFIG_CPU_VIAC3_2
+  cpuflags-y  := $(call check_gcc,-march=c3,-march=i686)
+endif
+
+ifdef CONFIG_CPU_CRUSOE
+  cpuflags-y	:= -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_686
+  cpuflags-y      := -march=i686
+endif
+
+# supports i686 without cmov
+ifdef CONFIG_CPU_CYRIXIII
+  cpuflags-y	:= $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_K6
+  cpuflags-y	:= -march=k6
+endif
+
+ifdef CONFIG_CPU_586MMX
+  cpuflags-y	:= $(call check_gcc,-march=pentium-mmx,-march=i586)
+endif
+
+# Winchip supports i586
+ifdef CONFIG_CPU_WINCHIPC6
+  cpuflags-y	:= $(call check_gcc,-march=winchip-c6,-march=i486)
+endif
+ifdef CONFIG_CPU_WINCHIP2
+  cpuflags-y	:= $(call check_gcc,-march=winchip2,-march=i486)
+endif
+ifdef CPU_WINCHIP3D
+  cpuflags-y	:= $(call check_gcc,-march=winchip2,-march=i486)
+endif
+
+ifdef CONFIG_CPU_586TSC
+cpuflags-y	:= -march=i586
+endif
+
+ifdef CONFIG_CPU_586
+  cpuflags-y	:= -march=i586
+endif
+
+ifdef CONFIG_X86_ELAN
+  cpuflags-y	:= -march=i486
+endif
+
+ifdef CONFIG_CPU_486
+  cpuflags-y	:= -march=i486
+endif
+
+ifdef CONFIG_CPU_386
+  cpuflags-y	:= -march=i386
+endif
+
 
-CFLAGS += $(cflags-y)
+CFLAGS += $(cpuflags-y)
 
 # Default subarch .c files
 mcore-y  := mach-default
--- linux-2.6.0-test5-cpu/include/asm-i386/processor.h.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/processor.h	2003-09-13 11:14:10.000000000 +0200
@@ -541,7 +541,7 @@
 #define K7_NOP7        ".byte 0x8D,0x04,0x05,0,0,0,0\n"
 #define K7_NOP8        K7_NOP7 ASM_NOP1
 
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
 #define ASM_NOP1 K8_NOP1
 #define ASM_NOP2 K8_NOP2
 #define ASM_NOP3 K8_NOP3
@@ -550,7 +550,7 @@
 #define ASM_NOP6 K8_NOP6
 #define ASM_NOP7 K8_NOP7
 #define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
 #define ASM_NOP1 K7_NOP1
 #define ASM_NOP2 K7_NOP2
 #define ASM_NOP3 K7_NOP3
--- linux-2.6.0-test5-cpu/drivers/serial/8250.h.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/drivers/serial/8250.h	2003-09-13 11:14:10.000000000 +0200
@@ -44,7 +44,7 @@
 
 #undef SERIAL_DEBUG_PCI
 
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
 #define SERIAL_INLINE
 #endif
   
--- linux-2.6.0-test5-cpu/arch/i386/boot/setup.S.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/boot/setup.S	2003-09-13 11:14:10.000000000 +0200
@@ -744,7 +744,7 @@
 # AMD Elan bug fix by Robert Schwebel.
 #
 
-#if defined(CONFIG_MELAN)
+#if defined(CONFIG_X86_ELAN)
 	movb $0x02, %al			# alternate A20 gate
 	outb %al, $0x92			# this works on SC410/SC520
 a20_elan_wait:
--- linux-2.6.0-test5-cpu/include/asm-i386/timex.h.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/timex.h	2003-09-13 11:14:10.000000000 +0200
@@ -12,7 +12,7 @@
 #ifdef CONFIG_X86_PC9800
    extern int CLOCK_TICK_RATE;
 #else
-#ifdef CONFIG_MELAN
+#ifdef CONFIG_X86_ELAN
 #  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
 #else
 #  define CLOCK_TICK_RATE 1193182 /* Underlying HZ */
--- linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c	2003-09-13 11:17:00.000000000 +0200
@@ -121,7 +121,7 @@
 	return p;
 }
 
-#ifdef CONFIG_MK7
+#ifndef CONFIG_CPU_CYRIXIII
 
 /*
  *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/Makefile.old	2003-09-13 11:25:13.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/Makefile	2003-09-13 14:21:27.000000000 +0200
@@ -2,16 +2,32 @@
 # Makefile for x86-compatible CPU details and quirks
 #
 
-obj-y	:=	common.o proc.o
+obj-y			:=	common.o proc.o
+
+
+obj-$(CONFIG_CPU_486)		+=	amd.o
+obj-$(CONFIG_CPU_586)		+=	amd.o
+obj-$(CONFIG_CPU_K6)		+=	amd.o
+obj-$(CONFIG_CPU_K7)		+=	amd.o
+obj-$(CONFIG_CPU_K8)		+=	amd.o
+
+obj-$(CONFIG_CPU_WINCHIP)	+=	centaur.o
+obj-$(CONFIG_CPU_CYRIXIII)	+=	centaur.o
+obj-$(CONFIG_CPU_VIAC3_2)	+=	centaur.o
+
+obj-$(CONFIG_CPU_486)		+=	cyrix.o
+obj-$(CONFIG_CPU_586)		+=	cyrix.o
+
+obj-$(CONFIG_CPU_INTEL)		+=	intel.o
+
+obj-$(CONFIG_CPU_586)		+=	nexgen.o
+
+obj-$(CONFIG_CPU_586)		+=	rise.o
+
+obj-$(CONFIG_CPU_CRUSOE)	+=	transmeta.o
+
+obj-$(CONFIG_CPU_486)		+=	umc.o
 
-obj-y	+=	amd.o
-obj-y	+=	cyrix.o
-obj-y	+=	centaur.o
-obj-y	+=	transmeta.o
-obj-y	+=	intel.o
-obj-y	+=	rise.o
-obj-y	+=	nexgen.o
-obj-y	+=	umc.o
 
 obj-$(CONFIG_X86_MCE)	+=	mcheck/
 
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/common.c.old	2003-09-13 13:58:07.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/common.c	2003-09-13 14:20:59.000000000 +0200
@@ -434,15 +434,42 @@
 
 void __init early_cpu_init(void)
 {
+
+#if defined(CONFIG_CPU_INTEL)
 	intel_cpu_init();
+#endif
+
+#if defined(CONFIG_CPU_486) || defined(CONFIG_CPU_586)
 	cyrix_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486)
 	nsc_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486) || defined(CONFIG_CPU_586) || defined(CONFIG_CPU_K6) || defined(CONFIG_CPU_K7) || defined(CONFIG_CPU_K8)
 	amd_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
 	centaur_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_CRUSOE)
 	transmeta_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_586)
 	rise_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_586)
 	nexgen_init_cpu();
+#endif
+
+#if defined(CONFIG_CPU_486)
 	umc_init_cpu();
+#endif
 
 #ifdef CONFIG_DEBUG_PAGEALLOC
 	/* pse is not compatible with on-the-fly unmapping,
--- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old	2003-09-13 14:18:04.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c	2003-09-13 14:23:26.000000000 +0200
@@ -436,8 +436,12 @@
 	if (!mem_map)
 		BUG();
 #endif
-	
+
+#ifdef CONFIG_CPU_686
 	bad_ppro = ppro_with_ram_bug();
+#else
+	bad_ppro = 0;
+#endif
 
 #ifdef CONFIG_HIGHMEM
 	/* check that fixmap and pkmap do not overlap */
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/Makefile.old	2003-09-13 11:25:27.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/Makefile	2003-09-13 14:14:20.000000000 +0200
@@ -1,5 +1,11 @@
-obj-y		:= main.o if.o generic.o state.o
-obj-y		+= amd.o
-obj-y		+= cyrix.o
-obj-y		+= centaur.o
+obj-y				:= main.o if.o generic.o state.o
+
+obj-$(CONFIG_CPU_K6)		+= amd.o
+
+obj-$(CONFIG_CPU_586)		+= cyrix.o
+
+obj-$(CONFIG_CPU_WINCHIP)	+= centaur.o
+obj-$(CONFIG_CPU_CYRIXIII)	+= centaur.o
+obj-$(CONFIG_CPU_VIAC3_2)	+= centaur.o
+
 
--- linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/main.c.old	2003-09-13 14:04:35.000000000 +0200
+++ linux-2.6.0-test5-cpu/arch/i386/kernel/cpu/mtrr/main.c	2003-09-13 14:09:11.000000000 +0200
@@ -475,12 +475,16 @@
 		printk(KERN_WARNING "mtrr: register: %d too big\n", reg);
 		goto out;
 	}
+
+#if defined(CONFIG_CPU_586)
 	if (is_cpu(CYRIX) && !use_intel()) {
 		if ((reg == 3) && arr3_protected) {
 			printk(KERN_WARNING "mtrr: ARR3 cannot be changed\n");
 			goto out;
 		}
 	}
+#endif
+
 	mtrr_if->get(reg, &lbase, &lsize, &ltype);
 	if (lsize < 1) {
 		printk(KERN_WARNING "mtrr: MTRR %d not used\n", reg);
@@ -536,9 +540,19 @@
 
 static void __init init_ifs(void)
 {
+
+#if defined(CONFIG_CPU_K6)
 	amd_init_mtrr();
+#endif
+
+#if defined(CONFIG_CPU_586)
 	cyrix_init_mtrr();
+#endif
+
+#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
 	centaur_init_mtrr();
+#endif
+
 }
 
 static void init_other_cpus(void)
--- linux-2.6.0-test5-cpu/include/asm-i386/bugs.h.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/bugs.h	2003-09-13 11:16:23.000000000 +0200
@@ -152,9 +152,8 @@
  * - In order to run on anything without a TSC, we need to be
  *   compiled for a i486.
  * - In order to support the local APIC on a buggy Pentium machine,
- *   we need to be compiled with CONFIG_X86_GOOD_APIC disabled,
- *   which happens implicitly if compiled for a Pentium or lower
- *   (unless an advanced selection of CPU features is used) as an
+ *   we need to be compiled with CONFIG_X86_BAD_APIC enabled,
+ *   which happens implicitly if compiled for a Pentium as an
  *   otherwise config implies a properly working local APIC without
  *   the need to do extra reads from the APIC.
 */
@@ -185,7 +184,7 @@
  * integrated APIC (see 11AP erratum in "Pentium Processor
  * Specification Update").
  */
-#if defined(CONFIG_X86_LOCAL_APIC) && defined(CONFIG_X86_GOOD_APIC)
+#if defined(CONFIG_X86_LOCAL_APIC) && !defined(CONFIG_X86_BAD_APIC)
 	if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL
 	    && cpu_has_apic
 	    && boot_cpu_data.x86 == 5
--- linux-2.6.0-test5-cpu/include/asm-i386/apic.h.old	2003-09-13 11:14:00.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/apic.h	2003-09-13 11:15:42.000000000 +0200
@@ -41,7 +41,7 @@
 	do { } while ( apic_read( APIC_ICR ) & APIC_ICR_BUSY );
 }
 
-#ifdef CONFIG_X86_GOOD_APIC
+#ifndef CONFIG_X86_BAD_APIC
 # define FORCE_READ_AROUND_WRITE 0
 # define apic_read_around(x)
 # define apic_write_around(x,y) apic_write((x),(y))
@@ -56,7 +56,7 @@
 	/*
 	 * ack_APIC_irq() actually gets compiled as a single instruction:
 	 * - a single rmw on Pentium/82489DX
-	 * - a single write on P6+ cores (CONFIG_X86_GOOD_APIC)
+	 * - a single write on P6+ cores (!CONFIG_X86_BAD_APIC)
 	 * ... yummie.
 	 */
 
--- linux-2.6.0-test5-cpu/include/asm-i386/module.h.old	2003-09-13 12:52:18.000000000 +0200
+++ linux-2.6.0-test5-cpu/include/asm-i386/module.h	2003-09-13 13:03:13.000000000 +0200
@@ -49,7 +49,7 @@
 #elif CONFIG_MVIAC3_2
 #define MODULE_PROC_FAMILY "VIAC3-2 "
 #else
-#error unknown processor family
+#define MODULE_PROC_FAMILY "this needs to be fixed"
 #endif
 
 #define MODULE_ARCH_VERMAGIC MODULE_PROC_FAMILY

Re: RFC: [2.6 patch] better i386 CPU selection

[Kevin P. Fleming]

Adrian Bunk wrote:

> I'd appreciate it if more people could try this patch and report whether 
> their kernel compiles and works.

Compiling with config below produces linking errors:

arch/i386/lib/lib.a(usercopy.o): In function `__copy_to_user_ll':
usercopy.o(.text+0x279): undefined reference to `movsl_mask'
arch/i386/lib/lib.a(usercopy.o): In function `__copy_from_user_ll':
usercopy.o(.text+0x2e9): undefined reference to `movsl_mask'

.config:

CONFIG_X86=y
CONFIG_MMU=y
CONFIG_UID16=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_EXPERIMENTAL=y
CONFIG_CLEAN_COMPILE=y
CONFIG_STANDALONE=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_SYSVIPC=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_KALLSYMS=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_X86_PC=y
CONFIG_CPU_K7=y
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_TSC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_NOHIGHMEM=y
CONFIG_MTRR=y
CONFIG_ACPI_HT=y
CONFIG_ACPI=y
CONFIG_ACPI_BOOT=y
CONFIG_ACPI_BUS=y
CONFIG_ACPI_INTERPRETER=y
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_PCI=y
CONFIG_ACPI_SYSTEM=y
CONFIG_PCI=y
CONFIG_PCI_GODIRECT=y
CONFIG_PCI_DIRECT=y
CONFIG_HOTPLUG=y
CONFIG_BINFMT_ELF=y
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_IDE=y
CONFIG_BLK_DEV_IDE=y
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_IDEDISK_MULTI_MODE=y
CONFIG_BLK_DEV_IDECD=y
CONFIG_BLK_DEV_IDEFLOPPY=y
CONFIG_IDE_TASKFILE_IO=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_IDEPCI_SHARE_IRQ=y
CONFIG_BLK_DEV_IDEDMA_PCI=y
CONFIG_IDEDMA_PCI_AUTO=y
CONFIG_BLK_DEV_ADMA=y
CONFIG_BLK_DEV_SIS5513=y
CONFIG_BLK_DEV_VIA82CXXX=y
CONFIG_BLK_DEV_IDEDMA=y
CONFIG_IDEDMA_AUTO=y
CONFIG_SCSI=y
CONFIG_BLK_DEV_SD=y
CONFIG_CHR_DEV_ST=y
CONFIG_BLK_DEV_3W_XXXX_RAID=y
CONFIG_SCSI_AIC7XXX=y
CONFIG_MD=y
CONFIG_BLK_DEV_DM=y
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_INET=y
CONFIG_NETFILTER=y
CONFIG_IP_NF_CONNTRACK=y
CONFIG_IP_NF_FTP=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_STATE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_NAT=y
CONFIG_IP_NF_NAT_NEEDED=y
CONFIG_IP_NF_TARGET_MASQUERADE=y
CONFIG_IP_NF_TARGET_REDIRECT=y
CONFIG_IP_NF_NAT_FTP=y
CONFIG_IP_NF_TARGET_LOG=y
CONFIG_IPV6_SCTP__=y
CONFIG_NETDEVICES=y
CONFIG_TUN=y
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
CONFIG_NET_TULIP=y
CONFIG_TULIP=y
CONFIG_TULIP_MMIO=y
CONFIG_NET_PCI=y
CONFIG_NATSEMI=y
CONFIG_SIS900=y
CONFIG_NS83820=y
# Token Ring devices (depends on LLC=y)
CONFIG_INPUT=y
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_EVDEV=y
CONFIG_SOUND_GAMEPORT=y
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
CONFIG_SERIAL_8250=y
CONFIG_SERIAL_8250_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
CONFIG_UNIX98_PTYS=y
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
CONFIG_AGP=y
CONFIG_AGP_SIS=y
CONFIG_AGP_VIA=y
CONFIG_DRM=y
CONFIG_DRM_R128=y
CONFIG_EXT2_FS=y
CONFIG_XFS_FS=y
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_PROC_FS=y
CONFIG_DEVFS_FS=y
CONFIG_DEVFS_MOUNT=y
CONFIG_DEVPTS_FS=y
CONFIG_TMPFS=y
CONFIG_RAMFS=y
CONFIG_NFSD=y
CONFIG_NFSD_V3=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_SUNRPC=y
CONFIG_MSDOS_PARTITION=y
CONFIG_NLS=y
CONFIG_FB=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_ATY128=y
CONFIG_VGA_CONSOLE=y
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_PCI_CONSOLE=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_CLUT224=y
CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_INTEL8X0=y
CONFIG_USB=y
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DYNAMIC_MINORS=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_UHCI_HCD=y
CONFIG_USB_PRINTER=y
CONFIG_USB_STORAGE=y
CONFIG_USB_HID=y
CONFIG_USB_HIDINPUT=y
CONFIG_USB_USBNET=y
CONFIG_USB_CDCETHER=y
CONFIG_DEBUG_KERNEL=y
CONFIG_MAGIC_SYSRQ=y
CONFIG_X86_EXTRA_IRQS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_X86_BIOS_REBOOT=y

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sat, Sep 13, 2003 at 07:20:00AM -0700, Kevin P. Fleming wrote:
> Adrian Bunk wrote:
> 
> >I'd appreciate it if more people could try this patch and report whether 
> >their kernel compiles and works.
> 
> Compiling with config below produces linking errors:
> 
> arch/i386/lib/lib.a(usercopy.o): In function `__copy_to_user_ll':
> usercopy.o(.text+0x279): undefined reference to `movsl_mask'
> arch/i386/lib/lib.a(usercopy.o): In function `__copy_from_user_ll':
> usercopy.o(.text+0x2e9): undefined reference to `movsl_mask'
> 
> .config:
>...

Thanks for your report. I found the problem and I'll send an updated 
patch soon.

cu
Adrian

BTW: It's easier if you send the complete .config.

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Dave Jones]

On Sat, Sep 13, 2003 at 02:51:03PM +0200, Adrian Bunk wrote:

 > This patch makes the bzImage for my computer (same .config, same 
 > compiler, same compiler options) a good 5 kB smaller.

For the invasiveness of the patch, 5KB really is a questionable gain..

 > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
 > on a 486 and above.
 > In 2.6 selecting M486 means that only the 486 is supported.

What are you basing this on ? This seems bogus to me.
Last I checked, I could for eg, boot a 386 kernel on an Athlon.

 > +config CPU_VIAC3_2
 >  	bool "VIA C3-2 (Nehemiah)"
 >  	help
 > -	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
 > -	  of SSE and tells gcc to treat the CPU as a 686.
 > -	  Note, this kernel will not boot on older (pre model 9) C3s.
 > +	  Select this for a VIA C3 "Nehemiah" (model 9 and above).

You lost an important part of helptext.

 > +config CPU_ONLY_K7
 > +	bool
 > +	depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
 > +
 > +config CPU_ONLY_K8
 > +	bool
 > +	depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
 > +
 > +config CPU_ONLY_WINCHIP
 > +	bool
 > +	depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
 > +	default y

These are hurrendous.  Each time we add support for a new CPU we
have to update each and every one of these. This won't fly,
someone *WILL* miss one. We've had this sort of thing happen before,
and its an accident waiting to happen.

 > +
 > +ifdef CONFIG_CPU_K8
 > +  ifdef CONFIG_CPU_PENTIUM4
 > +    cpuflags-y	:= $(call check_gcc,-march=pentium3,-march=i686)
 > +  else
 > +    cpuflags-y	:= $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
 > +  endif
 > +endif
 > +

These horrible nesting things are also a real PITA, as theres >1 case
that needs updating when something changes for a particular
vendor/family.  The cflags-$foo stuff in 2.6 was just starting to
become readable, and you want to undo that?

 > --- linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c.old	2003-09-13 11:14:00.000000000 +0200
 > +++ linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c	2003-09-13 11:17:00.000000000 +0200
 > @@ -121,7 +121,7 @@
 >  	return p;
 >  }
 >  
 > -#ifdef CONFIG_MK7
 > +#ifndef CONFIG_CPU_CYRIXIII
 >  
 >  /*
 >   *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and

wtf ?

 > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old	2003-09-13 14:18:04.000000000 +0200
 > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c	2003-09-13 14:23:26.000000000 +0200
 > @@ -436,8 +436,12 @@
 >  	if (!mem_map)
 >  		BUG();
 >  #endif
 > -	
 > +
 > +#ifdef CONFIG_CPU_686
 >  	bad_ppro = ppro_with_ram_bug();
 > +#else
 > +	bad_ppro = 0;
 > +#endif
 >  

If we boot a 386 kernel on a ppro with that bug, this goes bang.

 >  static void __init init_ifs(void)
 >  {
 > +
 > +#if defined(CONFIG_CPU_K6)
 >  	amd_init_mtrr();
 > +#endif
 > +
 > +#if defined(CONFIG_CPU_586)
 >  	cyrix_init_mtrr();
 > +#endif
 > +
 > +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
 >  	centaur_init_mtrr();
 > +#endif
 > +

For the handful of bytes saved in the mtrr driver, I'm more concerned
about ifdef noise, and the fact that we don't have a compile once-run
everywhere MTRR driver anymore unless you pick your options right

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sat, Sep 13, 2003 at 05:11:49PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 02:51:03PM +0200, Adrian Bunk wrote:
> 
>  > This patch makes the bzImage for my computer (same .config, same 
>  > compiler, same compiler options) a good 5 kB smaller.
> 
> For the invasiveness of the patch, 5KB really is a questionable gain..

I should have stated that the arch/i386/kernel/cpu{,/mtrr}/Makefile 
parts are an example of what is possible with such a CPU selection 
schema.

I'll send a splitted patch where this is only an optional enhanchement.

>  > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
>  > on a 486 and above.
>  > In 2.6 selecting M486 means that only the 486 is supported.
> 
> What are you basing this on ? This seems bogus to me.
> Last I checked, I could for eg, boot a 386 kernel on an Athlon.

It currently works. The question is the exact semantics of X86_GENERIC. 
If you read the description of X86_GENERIC it implicitely says a kernel 
for a 386 isn't generic.

>  > +config CPU_VIAC3_2
>  >  	bool "VIA C3-2 (Nehemiah)"
>  >  	help
>  > -	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
>  > -	  of SSE and tells gcc to treat the CPU as a 686.
>  > -	  Note, this kernel will not boot on older (pre model 9) C3s.
>  > +	  Select this for a VIA C3 "Nehemiah" (model 9 and above).
> 
> You lost an important part of helptext.

With the patch to the Makefile the "enables usage of SSE and tells gcc
to treat the CPU as a 686" is only true if you don't compile support for 
older CPUs.

>...
>  > +
>  > +ifdef CONFIG_CPU_K8
>  > +  ifdef CONFIG_CPU_PENTIUM4
>  > +    cpuflags-y	:= $(call check_gcc,-march=pentium3,-march=i686)
>  > +  else
>  > +    cpuflags-y	:= $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
>  > +  endif
>  > +endif
>  > +
> 
> These horrible nesting things are also a real PITA, as theres >1 case
> that needs updating when something changes for a particular
> vendor/family.  The cflags-$foo stuff in 2.6 was just starting to
> become readable, and you want to undo that?

The idea is to move the question "Which CPU option supports bot an
Athlon and a Pentium 4?" from the user to the kernel. The user no longer 
has to take care of this, he simply selects all CPUs he wants to 
support.

>  > --- linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c.old	2003-09-13 11:14:00.000000000 +0200
>  > +++ linux-2.6.0-test5-cpu/arch/i386/lib/mmx.c	2003-09-13 11:17:00.000000000 +0200
>  > @@ -121,7 +121,7 @@
>  >  	return p;
>  >  }
>  >  
>  > -#ifdef CONFIG_MK7
>  > +#ifndef CONFIG_CPU_CYRIXIII
>  >  
>  >  /*
>  >   *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
> 
> wtf ?

It's logical considering the dependencies of X86_USE_3DNOW.

But thinking about it a second time, it seems a CONFIG_CPU_ONLY_K7 does 
the same and is less error prone.

>  > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old	2003-09-13 14:18:04.000000000 +0200
>  > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c	2003-09-13 14:23:26.000000000 +0200
>  > @@ -436,8 +436,12 @@
>  >  	if (!mem_map)
>  >  		BUG();
>  >  #endif
>  > -	
>  > +
>  > +#ifdef CONFIG_CPU_686
>  >  	bad_ppro = ppro_with_ram_bug();
>  > +#else
>  > +	bad_ppro = 0;
>  > +#endif
>  >  
> 
> If we boot a 386 kernel on a ppro with that bug, this goes bang.

ppro_with_ram_bug checks for one specific ppro bug.
On a 386 this funtion returns 0.

This is part of the (optional) part of this patch that selects only the 
needed parts in arch/i386/kernel/cpu/Makefile. When compiling a kernel 
without any support for Intel CPUs I got a linker error. It could be 
CONFIG_CPU_INTEL (since that's when arch/i386/kernel/cpu/intel.c gets 
compiled) but since this function returns 1 only for some ppro's I've 
optimized it to ppro_with_ram_bug.

>  >  static void __init init_ifs(void)
>  >  {
>  > +
>  > +#if defined(CONFIG_CPU_K6)
>  >  	amd_init_mtrr();
>  > +#endif
>  > +
>  > +#if defined(CONFIG_CPU_586)
>  >  	cyrix_init_mtrr();
>  > +#endif
>  > +
>  > +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
>  >  	centaur_init_mtrr();
>  > +#endif
>  > +
> 
> For the handful of bytes saved in the mtrr driver, I'm more concerned
> about ifdef noise, and the fact that we don't have a compile once-run
> everywhere MTRR driver anymore unless you pick your options right

You have a "compile once-run everywhere MTRR driver" if you select all 
CPUs.

As stated above, this isn't part of the core patch.

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Dave Jones]

On Sat, Sep 13, 2003 at 06:41:46PM +0200, Adrian Bunk wrote:

 > >  > In 2.6 selecting M486 means that only the 486 is supported.
 > > 
 > > What are you basing this on ? This seems bogus to me.
 > > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
 > 
 > It currently works.

Exactly, then your first statement above is bogus.
 
 > The question is the exact semantics of X86_GENERIC. 
 > If you read the description of X86_GENERIC it implicitely says a kernel 
 > for a 386 isn't generic.

Apart from using incorrect cache line alignments on P4, an i386 kernel
is no more, no less generic than one compiled with X86_GENERIC

 > >  > +config CPU_VIAC3_2
 > >  >  	bool "VIA C3-2 (Nehemiah)"
 > >  >  	help
 > >  > -	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
 > >  > -	  of SSE and tells gcc to treat the CPU as a 686.
 > >  > -	  Note, this kernel will not boot on older (pre model 9) C3s.
 > >  > +	  Select this for a VIA C3 "Nehemiah" (model 9 and above).
 > > 
 > > You lost an important part of helptext.
 > With the patch to the Makefile the "enables usage of SSE and tells gcc
 > to treat the CPU as a 686" is only true if you don't compile support for 
 > older CPUs.

Incidentally, looking closer you broke this option.

+ifdef CONFIG_CPU_VIAC3_2
+  cpuflags-y  := $(call check_gcc,-march=c3,-march=i686)
+endif

Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
prefetches.  One thing that just occured to me, it may be possible
to dispose of this option completley now that Andi's runtime
patching code is in. If I get time I'll take a look at that.

 > >  > +ifdef CONFIG_CPU_K8
 > >  > +  ifdef CONFIG_CPU_PENTIUM4
 > >  > +    cpuflags-y	:= $(call check_gcc,-march=pentium3,-march=i686)
 > >  > +  else
 > >  > +    cpuflags-y	:= $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
 > >  > +  endif
 > >  > +endif
 > >  > +
 > > 
 > > These horrible nesting things are also a real PITA, as theres >1 case
 > > that needs updating when something changes for a particular
 > > vendor/family.  The cflags-$foo stuff in 2.6 was just starting to
 > > become readable, and you want to undo that?
 > 
 > The idea is to move the question "Which CPU option supports bot an
 > Athlon and a Pentium 4?" from the user to the kernel. The user no longer 
 > has to take care of this, he simply selects all CPUs he wants to 
 > support.

That should be solved using CONFIG_X86_GENERIC, not fuglifying the Makefiles.
Seriously, I think this is completely the wrong approach. Seriously, how many
mails does l-k get of people saying, "Oh duh, my no booting kernel was
because I chose to compile for Athlon, and I have a Pentium 4" or the likes?
This seems to be a solution in search of a problem.

 > >  > -#ifdef CONFIG_MK7
 > >  > +#ifndef CONFIG_CPU_CYRIXIII
 > >  >  
 > >  >  /*
 > >  >   *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
 > > 
 > > wtf ?
 > 
 > It's logical considering the dependencies of X86_USE_3DNOW.
 > 
 > But thinking about it a second time, it seems a CONFIG_CPU_ONLY_K7 does 
 > the same and is less error prone.

X86_USE_3DNOW would seem more logical to me. I never checked if this
was a win on C3, but as that also has 3dnow its possibly worth looking into.

 > >  > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old	2003-09-13 14:18:04.000000000 +0200
 > >  > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c	2003-09-13 14:23:26.000000000 +0200
 > >  > @@ -436,8 +436,12 @@
 > >  >  	if (!mem_map)
 > >  >  		BUG();
 > >  >  #endif
 > >  > -	
 > >  > +
 > >  > +#ifdef CONFIG_CPU_686
 > >  >  	bad_ppro = ppro_with_ram_bug();
 > >  > +#else
 > >  > +	bad_ppro = 0;
 > >  > +#endif
 > >  >  
 > > 
 > > If we boot a 386 kernel on a ppro with that bug, this goes bang.
 > 
 > ppro_with_ram_bug checks for one specific ppro bug.
 > On a 386 this funtion returns 0.

I'm not talking about running it on a 386. I'm talking about running
a kernel _compiled as 386_, on a PPro which has the bug this fixes.
With your patch, this code does nothing, and the bug doesn't get worked
around. Currently, it does the right thing. You're saving a half dozen
or so bytes, and making things like vendor boot kernels (typically
compiled as 386) not perform a necessary errata workaround.
And "You can select 486/586/686 too" is not an answer. These kernels
need to be small, and errata workarounds should NEVER be compiled out
for exactly this reason.

 > >  >  static void __init init_ifs(void)
 > >  >  {
 > >  > +
 > >  > +#if defined(CONFIG_CPU_K6)
 > >  >  	amd_init_mtrr();
 > >  > +#endif
 > >  > +
 > >  > +#if defined(CONFIG_CPU_586)
 > >  >  	cyrix_init_mtrr();
 > >  > +#endif
 > >  > +
 > >  > +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
 > >  >  	centaur_init_mtrr();
 > >  > +#endif
 > >  > +
 > > 
 > > For the handful of bytes saved in the mtrr driver, I'm more concerned
 > > about ifdef noise, and the fact that we don't have a compile once-run
 > > everywhere MTRR driver anymore unless you pick your options right
 > 
 > You have a "compile once-run everywhere MTRR driver" if you select all 
 > CPUs.

That doesn't solve the 'looks ugly as all hell' problem.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sat, Sep 13, 2003 at 06:21:30PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 06:41:46PM +0200, Adrian Bunk wrote:
> 
>  > >  > In 2.6 selecting M486 means that only the 486 is supported.
>  > > 
>  > > What are you basing this on ? This seems bogus to me.
>  > > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
>  > 
>  > It currently works.
> 
> Exactly, then your first statement above is bogus.

It was a leftover from a first version where I had a misunderstanding 
regarding the exact effects of X86_L1_CACHE_SHIFT.

If it should continue to work as it currently works the description 
"Generic x86 support" is _very_ misleading.

What does a user think on which machines a kernel will run after he 
enabled the following options?
  - "Athlon/Duron/K7"
  - "Generic x86 support"

>  > The question is the exact semantics of X86_GENERIC. 
>  > If you read the description of X86_GENERIC it implicitely says a kernel 
>  > for a 386 isn't generic.
> 
> Apart from using incorrect cache line alignments on P4, an i386 kernel
> is no more, no less generic than one compiled with X86_GENERIC

plus X86_INTEL_USERCOPY

>  > >  > +config CPU_VIAC3_2
>  > >  >  	bool "VIA C3-2 (Nehemiah)"
>  > >  >  	help
>  > >  > -	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
>  > >  > -	  of SSE and tells gcc to treat the CPU as a 686.
>  > >  > -	  Note, this kernel will not boot on older (pre model 9) C3s.
>  > >  > +	  Select this for a VIA C3 "Nehemiah" (model 9 and above).
>  > > 
>  > > You lost an important part of helptext.
>  > With the patch to the Makefile the "enables usage of SSE and tells gcc
>  > to treat the CPU as a 686" is only true if you don't compile support for 
>  > older CPUs.
> 
> Incidentally, looking closer you broke this option.
> 
> +ifdef CONFIG_CPU_VIAC3_2
> +  cpuflags-y  := $(call check_gcc,-march=c3,-march=i686)
> +endif
> 
> Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
> prefetches.  One thing that just occured to me, it may be possible
>...

Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.

That's the reason why I changed this -march setting (as noted in my 
changelog).

>...
>  > >  > -#ifdef CONFIG_MK7
>  > >  > +#ifndef CONFIG_CPU_CYRIXIII
>  > >  >  
>  > >  >  /*
>  > >  >   *	The K7 has streaming cache bypass load/store. The Cyrix III, K6 and
>  > > 
>  > > wtf ?
>  > 
>  > It's logical considering the dependencies of X86_USE_3DNOW.
>  > 
>  > But thinking about it a second time, it seems a CONFIG_CPU_ONLY_K7 does 
>  > the same and is less error prone.
> 
> X86_USE_3DNOW would seem more logical to me. I never checked if this
> was a win on C3, but as that also has 3dnow its possibly worth looking into.

Current -test5 (without my patch) has

config X86_USE_3DNOW
        bool
        depends on MCYRIXIII || MK7
        default y

This #ifdef is there to differenciate between the K7 and the generic MMX 
implementation.

>  > >  > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old	2003-09-13 14:18:04.000000000 +0200
>  > >  > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c	2003-09-13 14:23:26.000000000 +0200
>  > >  > @@ -436,8 +436,12 @@
>  > >  >  	if (!mem_map)
>  > >  >  		BUG();
>  > >  >  #endif
>  > >  > -	
>  > >  > +
>  > >  > +#ifdef CONFIG_CPU_686
>  > >  >  	bad_ppro = ppro_with_ram_bug();
>  > >  > +#else
>  > >  > +	bad_ppro = 0;
>  > >  > +#endif
>  > >  >  
>  > > 
>  > > If we boot a 386 kernel on a ppro with that bug, this goes bang.
>  > 
>  > ppro_with_ram_bug checks for one specific ppro bug.
>  > On a 386 this funtion returns 0.
> 
> I'm not talking about running it on a 386. I'm talking about running
> a kernel _compiled as 386_, on a PPro which has the bug this fixes.
> With your patch, this code does nothing, and the bug doesn't get worked
> around. Currently, it does the right thing. You're saving a half dozen
> or so bytes, and making things like vendor boot kernels (typically
> compiled as 386) not perform a necessary errata workaround.

Well, this is an optional part of my patch. It will be splitted from the 
main part.

> And "You can select 486/586/686 too" is not an answer. These kernels
> need to be small, and errata workarounds should NEVER be compiled out
> for exactly this reason.
>...

Why is a kernel compiled with support for all CPUs necessarily much
bigger than a current M386 kernel?

OTOH, why waste space on a 486 for 3DNow! support?

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Dave Jones]

On Sat, Sep 13, 2003 at 08:22:12PM +0200, Adrian Bunk wrote:

 > What does a user think on which machines a kernel will run after he 
 > enabled the following options?
 >   - "Athlon/Duron/K7"
 >   - "Generic x86 support"

Currently, as you can only choose one of them, it should be obvious.
With your 'you can choose n number of options' patch, it becomes
confusing why there is a generic option at all.

 > >  > If you read the description of X86_GENERIC it implicitely says a kernel 
 > >  > for a 386 isn't generic.
 > > Apart from using incorrect cache line alignments on P4, an i386 kernel
 > > is no more, no less generic than one compiled with X86_GENERIC
 > plus X86_INTEL_USERCOPY

Sure, but that still doesn't prevent it being used on any system as
a generic kernel.

 > > Incidentally, looking closer you broke this option.
 > > 
 > > +ifdef CONFIG_CPU_VIAC3_2
 > > +  cpuflags-y  := $(call check_gcc,-march=c3,-march=i686)
 > > +endif
 > > 
 > > Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
 > > prefetches.  One thing that just occured to me, it may be possible
 > >...
 > 
 > Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.

the 3.3.2 and 3.4 branches have it.

 > > And "You can select 486/586/686 too" is not an answer. These kernels
 > > need to be small, and errata workarounds should NEVER be compiled out
 > > for exactly this reason.
 > >...
 > Why is a kernel compiled with support for all CPUs necessarily much
 > bigger than a current M386 kernel?

Adding in stuff like cpu specific memory copy routines for example.
There have been several cases where vendors haven't been able to squeeze a
boot kernel onto a CD by 40 or so bytes in the past, leading to a last
minute scavenge to try and reclaim that space. Every little helps.

 > OTOH, why waste space on a 486 for 3DNow! support?

I'm arguing for errata workarounds, not extended support.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sat, Sep 13, 2003 at 07:35:29PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 08:22:12PM +0200, Adrian Bunk wrote:
> 
>  > What does a user think on which machines a kernel will run after he 
>  > enabled the following options?
>  >   - "Athlon/Duron/K7"
>  >   - "Generic x86 support"
> 
> Currently, as you can only choose one of them, it should be obvious.
> With your 'you can choose n number of options' patch, it becomes
> confusing why there is a generic option at all.

No, currently you first choose the CPU. This CPU selection selects most 
settings like the CPU features (e.g. enables X86_F00F_BUG) and the gcc 
optimization flags.

The "Generic x86 support" question is asked later.

My patch removes the generic option since it's no longer needed.

>...
>  > > Incidentally, looking closer you broke this option.
>  > > 
>  > > +ifdef CONFIG_CPU_VIAC3_2
>  > > +  cpuflags-y  := $(call check_gcc,-march=c3,-march=i686)
>  > > +endif
>  > > 
>  > > Its C3_2 becauase it needs -march=c3-2 to use SSE instead of 3dnow
>  > > prefetches.  One thing that just occured to me, it may be possible
>  > >...
>  > 
>  > Which gcc does support -march=c3-2 ? gcc 3.3.1 doesn't support it.
> 
> the 3.3.2 and 3.4 branches have it.

Ah I didn't know that. The 20030831 snapshot of the 3.3 branch in Debian 
unstable was the latest gcc I checked.

>  > > And "You can select 486/586/686 too" is not an answer. These kernels
>  > > need to be small, and errata workarounds should NEVER be compiled out
>  > > for exactly this reason.
>  > >...
>  > Why is a kernel compiled with support for all CPUs necessarily much
>  > bigger than a current M386 kernel?
> 
> Adding in stuff like cpu specific memory copy routines for example.
> There have been several cases where vendors haven't been able to squeeze a
> boot kernel onto a CD by 40 or so bytes in the past, leading to a last
> minute scavenge to try and reclaim that space. Every little helps.
> 
>  > OTOH, why waste space on a 486 for 3DNow! support?
> 
> I'm arguing for errata workarounds, not extended support.

I'll send the cpu selection patch with the arch/i386/kernel/cpu/ and 
arch/i386/kernel/cpu/mtrr/ stuff as separate patches.

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Jeff Garzik]

On Sat, Sep 13, 2003 at 05:11:49PM +0100, Dave Jones wrote:
> 
>  > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
>  > on a 486 and above.
>  > In 2.6 selecting M486 means that only the 486 is supported.
> 
> What are you basing this on ? This seems bogus to me.
> Last I checked, I could for eg, boot a 386 kernel on an Athlon.

If you know that you're only booting on a 486, why include all the junk
needed solely for later processors?


> 
>  > +config CPU_ONLY_K7
>  > +	bool
>  > +	depends on CPU_K7 && !CPU_INTEL && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
>  > +
>  > +config CPU_ONLY_K8
>  > +	bool
>  > +	depends on CPU_K8 && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
>  > +
>  > +config CPU_ONLY_WINCHIP
>  > +	bool
>  > +	depends on CPU_WINCHIP && !CPU_INTEL && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
>  > +	default y
> 
> These are hurrendous.  Each time we add support for a new CPU we
> have to update each and every one of these. This won't fly,
> someone *WILL* miss one. We've had this sort of thing happen before,
> and its an accident waiting to happen.

Agreed


>  > --- linux-2.6.0-test5-cpu/arch/i386/mm/init.c.old	2003-09-13 14:18:04.000000000 +0200
>  > +++ linux-2.6.0-test5-cpu/arch/i386/mm/init.c	2003-09-13 14:23:26.000000000 +0200
>  > @@ -436,8 +436,12 @@
>  >  	if (!mem_map)
>  >  		BUG();
>  >  #endif
>  > -	
>  > +
>  > +#ifdef CONFIG_CPU_686
>  >  	bad_ppro = ppro_with_ram_bug();
>  > +#else
>  > +	bad_ppro = 0;
>  > +#endif
>  >  
> 
> If we boot a 386 kernel on a ppro with that bug, this goes bang.

Echo my first comment.  I think it's fair to make this stuff
fine-grained -- as long as present behavior is preserved.  So IMO
fine-grained "I really want this cpu, and this cpu only" stuff really
requires a dependency on CONFIG_EMBEDDED.  When !CONFIG_EMBEDDED, for
example, it would define CONFIG_CPU_686 to ensure the required 686
pieces were in place.

I like the general direction of Adrian's patch, and think that moving in
this direction will provide a lot of hidden maintenance _benefits_ after
the initial pain...  But.  Adrian's patch is a tough thing to get right,
and IMO requires a lot of testing.


>  >  static void __init init_ifs(void)
>  >  {
>  > +
>  > +#if defined(CONFIG_CPU_K6)
>  >  	amd_init_mtrr();
>  > +#endif
>  > +
>  > +#if defined(CONFIG_CPU_586)
>  >  	cyrix_init_mtrr();
>  > +#endif
>  > +
>  > +#if defined(CONFIG_CPU_WINCHIP) || defined(CONFIG_CPU_CYRIXIII) || defined(CONFIG_CPU_VIAC3_2)
>  >  	centaur_init_mtrr();
>  > +#endif
>  > +
> 
> For the handful of bytes saved in the mtrr driver, I'm more concerned
> about ifdef noise, and the fact that we don't have a compile once-run
> everywhere MTRR driver anymore unless you pick your options right

The arch/i386/kernel/cpu stuff is so modular, code like the above just
screams for an ->init_mtrr() hook in there.  drivers/char/hw_random.c
(portably) depends on VIA RNG's xstore instruction, which implies a
dependency on code and settings in arch/i386/*.  So, there's nothing
fundamentally wrong with sticking your fingers in there, IMO...

	Jeff

Re: RFC: [2.6 patch] better i386 CPU selection

[Dave Jones]

On Sat, Sep 13, 2003 at 02:21:59PM -0400, Jeff Garzik wrote:

 > >  > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
 > >  > on a 486 and above.
 > >  > In 2.6 selecting M486 means that only the 486 is supported.
 > > 
 > > What are you basing this on ? This seems bogus to me.
 > > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
 > 
 > If you know that you're only booting on a 486, why include all the junk
 > needed solely for later processors?

Reread. a kernel _compiled for 386_
Precisely what junk do you mean ?

 > > If we boot a 386 kernel on a ppro with that bug, this goes bang.
 > Echo my first comment.

Echo 2 lines above. People do use 386 kernels for install kernels
on distros. Removing errata workarounds means distros start randomly
exploding during installs.

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: RFC: [2.6 patch] better i386 CPU selection

[Jeff Garzik]

On Sat, Sep 13, 2003 at 07:37:58PM +0100, Dave Jones wrote:
> On Sat, Sep 13, 2003 at 02:21:59PM -0400, Jeff Garzik wrote:
> 
>  > >  > In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
>  > >  > on a 486 and above.
>  > >  > In 2.6 selecting M486 means that only the 486 is supported.
>  > > 
>  > > What are you basing this on ? This seems bogus to me.
>  > > Last I checked, I could for eg, boot a 386 kernel on an Athlon.
>  > 
>  > If you know that you're only booting on a 486, why include all the junk
>  > needed solely for later processors?
> 
> Reread. a kernel _compiled for 386_
> Precisely what junk do you mean ?
> 
>  > > If we boot a 386 kernel on a ppro with that bug, this goes bang.
>  > Echo my first comment.
> 
> Echo 2 lines above. People do use 386 kernels for install kernels
> on distros. Removing errata workarounds means distros start randomly
> exploding during installs.

You're not understanding the model.  I understand your comment about
using 386 kernels for install kernels.  If Adrian's patch is done
right, _absolutely nothing should change_ in your described scenario.

Distros would continue doing what they've always done, and would
continue to get the behavior they have always gotten.

Unless you're a power user and select CONFIG_EMBEDDED, of course.
Then behavior changes.

	Jeff

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Sad, 2003-09-13 at 19:53, Jeff Garzik wrote:
> You're not understanding the model.  I understand your comment about
> using 386 kernels for install kernels.  If Adrian's patch is done
> right, _absolutely nothing should change_ in your described scenario.

Duh sorry - althoug Im unconvinced the ifdef explosion is worth it for
the tiny ones (the few hundred byte workarounds)

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sat, Sep 13, 2003 at 02:53:19PM -0400, Jeff Garzik wrote:
> > 
> > Echo 2 lines above. People do use 386 kernels for install kernels
> > on distros. Removing errata workarounds means distros start randomly
> > exploding during installs.
> 
> You're not understanding the model.  I understand your comment about
> using 386 kernels for install kernels.  If Adrian's patch is done
> right, _absolutely nothing should change_ in your described scenario.
> 
> Distros would continue doing what they've always done, and would
> continue to get the behavior they have always gotten.
>...

I'm not sure whether you understand my intention.

Nothing will change, except that if you want to support all CPUs, you 
have to select all CPUs instead of 386.

My main intention is to get a clear user interface (user = person 
compiling the kernel) that suits everyone's needs and to put all the 
logic what to do when you plan to support several different CPUs into 
the kernel.

I don't like the current user interface that says "if you want to 
support both an Athlon and a Pentium 4 in your kernel use the Pentium III
option. And for better optimization, also check the "generic" option".

> 	Jeff

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Jeff Garzik]

Adrian Bunk wrote:
> I'm not sure whether you understand my intention.
> 
> Nothing will change, except that if you want to support all CPUs, you 
> have to select all CPUs instead of 386.

This is incorrect.  You don't want to change the behavior that people 
are relying on.  I wasn't describing your intentions, I was describing 
what you _should_ do ;-)

	Jeff

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Sad, 2003-09-13 at 19:21, Jeff Garzik wrote:
> If you know that you're only booting on a 486, why include all the junk
> needed solely for later processors?

Because its a nightmare to provide a billion CPU specific kernels, a set
of foo and higher kernels and a "generic kernel", then do it for each
platform 2.6 supports for x86, then test it.

The submission already looks like something out of a puzzle book

Re: RFC: [2.6 patch] better i386 CPU selection

[Mikael Pettersson]

On Sat, 13 Sep 2003 00:51:39 +0200, Adrian Bunk <bunk@fs.tum.de> wrote:
>> > > - Which CPUs exactly need X86_ALIGNMENT_16?
>> >
>> >Unsure. This could use testing on a few systems.
>> 
>> K7s and P5s (and 486s too if I remember correctly) strongly prefer
>> code entry points and loop labels to be 16-byte aligned. This is
>> due to the way code is fetched from L1.
>>...
>
>Hm, that's pretty different from the definition in -test5:
>
>config X86_ALIGNMENT_16
>        bool
>        depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || 
>          MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
>        default y

My comment referred to data from Intel and AMD code optimisation
guides.

The kernel only uses X86_ALIGNMENT_16 to derive two __ALIGN macros
for assembly code, but it doesn't use them except in one place in
the pnpbios code.

gcc -march=<cpu type> should generate appropriate alignment for
function entries and loop labels.

I suspect X86_ALIGNMENT_16 is a left-over from old code.
Perhaps its time to retire it.

/Mikael

Re: RFC: [2.6 patch] better i386 CPU selection

[Mikael Pettersson]

On Sat, 13 Sep 2003 01:23:04 +0200, Adrian Bunk <bunk@fs.tum.de> wrote:
>Considering this, I can simply do the following in my proposal of 
>offering every CPU type to the user?
>
>config X86_BAD_APIC
>	bool
>	depends on CPU_586TSC
>	default y

That depends on your semantics for CPU_586TSC.
If it is required for support of pre-MMX P5s, then yes.
With the current semantics, where a CPU choice simply
sets a lower bound, then no.

/Mikael

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sat, Sep 13, 2003 at 01:02:36PM +0200, Mikael Pettersson wrote:
> On Sat, 13 Sep 2003 01:23:04 +0200, Adrian Bunk <bunk@fs.tum.de> wrote:
> >Considering this, I can simply do the following in my proposal of 
> >offering every CPU type to the user?
> >
> >config X86_BAD_APIC
> >	bool
> >	depends on CPU_586TSC
> >	default y
> 
> That depends on your semantics for CPU_586TSC.
> If it is required for support of pre-MMX P5s, then yes.
> With the current semantics, where a CPU choice simply
> sets a lower bound, then no.

The intention of my "better i386 CPU selection" patch is that you select 
all CPUs you want to support.

The semantics is that e.g. CPU_486 doesn't enable support for Pentiums.

> /Mikael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Mikael Pettersson]

On Fri, 12 Sep 2003 21:07:28 +0200, Adrian Bunk <bunk@fs.tum.de> wrote:
>[
>My questions might sound silly - I simply don't have the x86
>knowledge, but I want to get the dependencies as good as possible.
>]
>
>All Cyrix/VIA/IDT/Transmeta processors have a working APIC?

None of them do.

>What about the original 386?

Nope.

>Then I can simply change it in my patch to
>
>config X86_GOOD_APIC
>        bool
>	depends on !CPU_586TSC
>	default y

GOOD_APIC is Intel P5MMX, Intel P6 and above, and AMD K7 and above.
Nothing else has GOOD_APIC: P5 Classic because of the bug, and the
rest because they don't have local APIC at all.

/Mikael

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Fri, Sep 12, 2003 at 11:38:03PM +0200, Mikael Pettersson wrote:
>...
> GOOD_APIC is Intel P5MMX, Intel P6 and above, and AMD K7 and above.
> Nothing else has GOOD_APIC: P5 Classic because of the bug, and the
> rest because they don't have local APIC at all.

Ah, thanks for this information.

Considering this, I can simply do the following in my proposal of 
offering every CPU type to the user?

config X86_BAD_APIC
	bool
	depends on CPU_586TSC
	default y


> /Mikael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Maciej W. Rozycki]

On Fri, 12 Sep 2003, Mikael Pettersson wrote:

> GOOD_APIC is Intel P5MMX, Intel P6 and above, and AMD K7 and above.
> Nothing else has GOOD_APIC: P5 Classic because of the bug, and the
> rest because they don't have local APIC at all.

 Other systems may (and do) have an external APIC.  This includes i486 and
all Pentium systems.  Note that the code doing a run-time check in
<asm/bugs.h> does a check for X86_FEATURE_APIC in
boot_cpu_data.x86_capability -- if the bit is reset then the local APIC is
external (there's no on-chip local APIC or it's disabled) and the test
does not panic() even if the stepping indicates the erratum is present.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: RFC: [2.6 patch] better i386 CPU selection

[Mikael Pettersson]

On Thu, 11 Sep 2003 12:04:35 +0100, Dave Jones wrote:
>On Thu, Sep 11, 2003 at 08:28:16AM +0200, Adrian Bunk wrote:
>
> > - Does the Cyrix III support 686 instructions?
>
>Depends on your definition of 686. If you follow the Intel
>definition (where CMOV is optional), yes. If you follow the gcc
>definition (where CMOV is assumed), no.
>Except for the latest Nehemiah cores (which now have CMOV).

To be fair to gcc, no Intel P6 or above to date has shipped
without CMOV.

> > - Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
> >   -march=i686 (except optimizations of otherwise compatible code)?
>
>Not afaik.
>
> > - Which CPUs exactly need X86_ALIGNMENT_16?
>
>Unsure. This could use testing on a few systems.

K7s and P5s (and 486s too if I remember correctly) strongly prefer
code entry points and loop labels to be 16-byte aligned. This is
due to the way code is fetched from L1.

>
> > - X86_GOOD_APIC: Are there really that many processors with a bad APIC?
>
>Mikael ?

Most pre-MMX P5s have a bug which breaks back-to-back writes to
the local APIC space (P5 erratum 11AP), requiring the kernel to
insert a dummy read before each local APIC write. GOOD_APIC is
for P5MMX and above which don't have this bug.

I have a P5 chip with this erratum I sometimes use for testing
(since it's pre-MMX and thus pre-RDPMC), and I know of people
still using dual P5 boxes with these early chips.

/Mikael

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Fri, Sep 12, 2003 at 10:09:20PM +0200, Mikael Pettersson wrote:
>...
> > > - Which CPUs exactly need X86_ALIGNMENT_16?
> >
> >Unsure. This could use testing on a few systems.
> 
> K7s and P5s (and 486s too if I remember correctly) strongly prefer
> code entry points and loop labels to be 16-byte aligned. This is
> due to the way code is fetched from L1.
>...

Hm, that's pretty different from the definition in -test5:

config X86_ALIGNMENT_16
        bool
        depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || 
          MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
        default y



> /Mikael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Mikael Pettersson]

On Sun, 7 Sep 2003 18:43:41 +0100, Jamie Lokier wrote:
>> There is to the best of my knowledge nothing in 2.6.0-test4
>> that prevents a kernel compiled for CPU type N from working
>> with CPU types >N. Just to prove it, I built a CONFIG_M486
>> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.
>
>You may be right, although I wonder if there are real problems like an
>SMP Pentium kernel not setting up MTRRs when run on an SMP P3.

Only if you omit CONFIG_MTRR. MTRR support is independent of
which CPU type you chose to optimise for.

>The main problems are:
>
>	1. Optimisation.  A kernel optimised for P3 but compatible
>	   with 486 needs to use 64 byte cache line alignment, and TSC
>	   for timing, but not use any SSE instructions.

A 486 kernel will use TSC if there is one. CONFIG_TSC (derived
from configured CPU type) allows the kernel to skip checking
for _not_ having a TSC; !CONFIG_TSC only means it has to check
before using it.

>	2. The CPU types are not a total order.  Say I want a kernel
>	   that supports Athlons and a Centaur for my cluster.  What
>	   CPU setting should I use?  What CPU setting will give my the best
>	   performing kernel - and is that the same as the one for smallest
>	   kernel?

CONFIG_M586 supports both, with some performance loss for the K7,
but that's your choice.

>	3. Like 2, but for embedded systems.  I'm (hypothetically)
>	   selling a cable modem which was originally based on one
>	   CPU, but we changed to a different one because it was
>	   cheaper.  I need to send out a firmware upgrade, and it is
>	   convenient to use a kernel which can run on either model.
>	   But I don't want to compile in support for every x86,
>	   because space is tight, and I want it to run as fast as it
>	   can given that it could run on either of the two chips.

So configure for the lowest common denominator. As long as your
embedded system isn't SMP, L1 cache line size assumptions don't
matter much, so you only lose (a) gcc -march= optimisations that
aren't common to both CPU types you support, and (b) some features
(like TSC if it isn't common to both) may need a runtime test
and/or dynamic dispatch. Given your insistence on having a common
kernel, this is the best you can do.

>I'm not sure if an Athlon is "lower" than a PII or not....  Which do I
>option do I pick, to run on either of those without including
>redundant stuff for older CPUs?

K7 is PIII (or PII, but I don't think so) + some stuff.

Admittedly, the kernel could include some more performance-tweaking
CONFIG options (mainly for L1 cache size and gcc -mcpu= values),
but that's a simple thing to add if necessary.

/Mikael

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sun, Sep 07, 2003 at 11:46:58PM +0200, Mikael Pettersson wrote:
>...
> Admittedly, the kernel could include some more performance-tweaking
> CONFIG options (mainly for L1 cache size and gcc -mcpu= values),
> but that's a simple thing to add if necessary.

-march implies -mcpu.

> /Mikael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Mikael Pettersson]

On Sun, 7 Sep 2003 13:28:13 +0200, Adrian Bunk wrote:
>The patch below tries to implement a better i386 CPU selection.
>
>In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
>on a 486 and above.
>
>In 2.6 selecting M486 means that only the 486 is supported.

Can you prove your claim about 2.6?

There is to the best of my knowledge nothing in 2.6.0-test4
that prevents a kernel compiled for CPU type N from working
with CPU types >N. Just to prove it, I built a CONFIG_M486
2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.

>There are two different needs:
>1. the installation kernel of a distribution should support all CPUs 
>   this distribution supports (perhaps starting with the 386)
>2. a sysadmin might e.g. want a kernel that support both a Pentium-III
>   and a Pentium 4, but doesn't need to support a 386

How are 1 and 2 different? Both need support for CPU type N
or higher. Since a kernel configured for a lower CPU type
still works on higher CPU types, where is the problem?
(In case 2 configure for PIII and use that on PIII and P4.)

Maybe I'm missing something but I don't see any problem here.

/Mikael

Re: RFC: [2.6 patch] better i386 CPU selection

[Jamie Lokier]

Mikael Pettersson wrote:
> There is to the best of my knowledge nothing in 2.6.0-test4
> that prevents a kernel compiled for CPU type N from working
> with CPU types >N. Just to prove it, I built a CONFIG_M486
> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.

You may be right, although I wonder if there are real problems like an
SMP Pentium kernel not setting up MTRRs when run on an SMP P3.

The main problems are:

	1. Optimisation.  A kernel optimised for P3 but compatible
	   with 486 needs to use 64 byte cache line alignment, and TSC
	   for timing, but not use any SSE instructions.

	   This is different from a kernel optimised for a 486.

	2. The CPU types are not a total order.  Say I want a kernel
	   that supports Athlons and a Centaur for my cluster.  What
	   CPU setting should I use?  What CPU setting will give my the best
	   performing kernel - and is that the same as the one for smallest
	   kernel?

	3. Like 2, but for embedded systems.  I'm (hypothetically)
	   selling a cable modem which was originally based on one
	   CPU, but we changed to a different one because it was
	   cheaper.  I need to send out a firmware upgrade, and it is
	   convenient to use a kernel which can run on either model.
	   But I don't want to compile in support for every x86,
	   because space is tight, and I want it to run as fast as it
	   can given that it could run on either of the two chips.

> How are 1 and 2 different? Both need support for CPU type N
> or higher. Since a kernel configured for a lower CPU type
> still works on higher CPU types, where is the problem?
> (In case 2 configure for PIII and use that on PIII and P4.)

I'm not sure if an Athlon is "lower" than a PII or not....  Which do I
option do I pick, to run on either of those without including
redundant stuff for older CPUs?

-- Jamie

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Sul, 2003-09-07 at 18:43, Jamie Lokier wrote:
> 	2. The CPU types are not a total order.  Say I want a kernel
> 	   that supports Athlons and a Centaur for my cluster.  What
> 	   CPU setting should I use?  What CPU setting will give my the best
> 	   performing kernel - and is that the same as the one for smallest
> 	   kernel?

You'd use two kernels. There is no sane other answer to that specific
case 8)

> 	   But I don't want to compile in support for every x86,
> 	   because space is tight, and I want it to run as fast as it
> 	   can given that it could run on either of the two chips.

The code size differential is noise except for FPU emulation, and thats
in part sloppy because we could have __fpuseg and eject it at boot if
not needed ;)

386 kernels are slow because of user space handling and lack of bswap
486 kernels basically work on anything just fine

> I'm not sure if an Athlon is "lower" than a PII or not....  Which do I
> option do I pick, to run on either of those without including
> redundant stuff for older CPUs?

Right now its ordered

386 - 486 - 586 - 586+TSC - 686 - PPro - PII - PIII - PIV

Geode is a branch off 586+TSC and supports 686+ too
Athlon branches off from PIII if I remember rightly
Winchip branches off from 586 and supports all later x86 too
ELAN is its own weird world
Xmeta comes off 686 somewhere depending how you handle PGE

Re: RFC: [2.6 patch] better i386 CPU selection

[Rogier Wolff]

On Sun, Sep 07, 2003 at 07:09:49PM +0100, Alan Cox wrote:
> On Sul, 2003-09-07 at 18:43, Jamie Lokier wrote:
> > 	2. The CPU types are not a total order.  Say I want a kernel
> > 	   that supports Athlons and a Centaur for my cluster.  What
> > 	   CPU setting should I use?  What CPU setting will give my the best
> > 	   performing kernel - and is that the same as the one for smallest
> > 	   kernel?
> 
> You'd use two kernels. There is no sane other answer to that specific
> case 8)

Ehmm. In some cases, having multiple kernels is a pain in the @55. 

Having the option to make a generic kernel should remain. One that
works on as much as possible CPUs. Even if it's a bit suboptimal on
some CPUs. 

Also it would be nice if we can make the boot code run on anything
until the point where the CPU is detected. Then we can give a nice
message that the kernel was not compiled for this cpu instead of a 
blank-screen-hang. If we have to compile printk for 386 for this
then so be it. If your printk becomes 20 or 40% slower, then so be
it. If printk is critical to your kernel performance, then youve
got a problem anyway.... 

			Roger. 

-- 
** R.E.Wolff@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
**** "Linux is like a wigwam -  no windows, no gates, apache inside!" ****

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Llu, 2003-09-08 at 09:17, Rogier Wolff wrote:
> > You'd use two kernels. There is no sane other answer to that specific
> > case 8)
> 
> Ehmm. In some cases, having multiple kernels is a pain in the @55. 

Right but for the winchip its 10-30% difference in performance the
others are the odd %age point (except 386)

> Also it would be nice if we can make the boot code run on anything
> until the point where the CPU is detected.

Thats hard because we run a lot of the kernel before that point. So 
you'd want to write the asm checks for it in boot.S really, or export
CPU flag lists and model data and make the boot loader able to do so,
that also means grub can be taught to boot the best kernel of a set and
handle stuff itself

Re: RFC: [2.6 patch] better i386 CPU selection

[Pavel Machek]

Hi!

> > > 	2. The CPU types are not a total order.  Say I want a kernel
> > > 	   that supports Athlons and a Centaur for my cluster.  What
> > > 	   CPU setting should I use?  What CPU setting will give my the best
> > > 	   performing kernel - and is that the same as the one for smallest
> > > 	   kernel?
> > 
> > You'd use two kernels. There is no sane other answer to that specific
> > case 8)
> 
> Ehmm. In some cases, having multiple kernels is a pain in the @55. 
> 
> Having the option to make a generic kernel should remain. One that
> works on as much as possible CPUs. Even if it's a bit suboptimal on
> some CPUs. 
> 
> Also it would be nice if we can make the boot code run on anything
> until the point where the CPU is detected. Then we can give a nice
> message that the kernel was not compiled for this cpu instead of a 
> blank-screen-hang. If we have to compile printk for 386 for this

Better yet do the check in i386/boot/setup.S; its assembly anyway... I
actually had check there (or somewhere near that :-) for x86-64. Not
sure where it is now.
								Pavel
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sun, Sep 07, 2003 at 07:09:49PM +0100, Alan Cox wrote:
>...
> > I'm not sure if an Athlon is "lower" than a PII or not....  Which do I
> > option do I pick, to run on either of those without including
> > redundant stuff for older CPUs?
> 
> Right now its ordered
> 
> 386 - 486 - 586 - 586+TSC - 686 - PPro - PII - PIII - PIV
> 
> Geode is a branch off 586+TSC and supports 686+ too
> Athlon branches off from PIII if I remember rightly
> Winchip branches off from 586 and supports all later x86 too
> ELAN is its own weird world
> Xmeta comes off 686 somewhere depending how you handle PGE

x86 is a complicated family...

My current list of CPU specific questions is:

- Does the Cyrix III support 686 instructions?
- Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
  -march=i686 (except optimizations of otherwise compatible code)?
- Which CPUs exactly need X86_ALIGNMENT_16?
- X86_GOOD_APIC: Are there really that many processors with a bad APIC?

TIA
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Dave Jones]

On Thu, Sep 11, 2003 at 08:28:16AM +0200, Adrian Bunk wrote:

 > - Does the Cyrix III support 686 instructions?

Depends on your definition of 686. If you follow the Intel
definition (where CMOV is optional), yes. If you follow the gcc
definition (where CMOV is assumed), no.
Except for the latest Nehemiah cores (which now have CMOV).

 > - Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
 >   -march=i686 (except optimizations of otherwise compatible code)?

Not afaik.

 > - Which CPUs exactly need X86_ALIGNMENT_16?

Unsure. This could use testing on a few systems.

 > - X86_GOOD_APIC: Are there really that many processors with a bad APIC?

Mikael ?

		Dave

-- 
 Dave Jones     http://www.codemonkey.org.uk

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Thu, Sep 11, 2003 at 12:04:35PM +0100, Dave Jones wrote:
> On Thu, Sep 11, 2003 at 08:28:16AM +0200, Adrian Bunk wrote:
> 
>  > - Does the Cyrix III support 686 instructions?
> 
> Depends on your definition of 686. If you follow the Intel
> definition (where CMOV is optional), yes. If you follow the gcc
> definition (where CMOV is assumed), no.
> Except for the latest Nehemiah cores (which now have CMOV).
>...

Thanks for this information.

Since I'm looking for the options to pass to gcc I have to follow the 
gcc definition...

> 		Dave

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Maciej W. Rozycki]

On Thu, 11 Sep 2003, Adrian Bunk wrote:

> - X86_GOOD_APIC: Are there really that many processors with a bad APIC?

 Only early revisions of the P54C (75-200MHz) Pentium processors are
affected: steppings B1, B3, B5, C2 and cB1 (or 1, 2, 4, 5 and 11) as
reported by cpuid).  MMX Pentia and later chips are OK as well as any
systems using external i82489DX APICs (so far i486, P5 (60/66MHz) Pentium
and P54C Pentium systems with i82489DX APICs has been found, AFAIK).  Once
I proposed the option to be user-selectable as an advanced CPU option
(<asm/bugs.h> does appropriate validation), but the proposal was rejected
as incomprehesible to an average user doing a kernel build. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Thu, Sep 11, 2003 at 02:10:43PM +0200, Maciej W. Rozycki wrote:
> On Thu, 11 Sep 2003, Adrian Bunk wrote:
> 
> > - X86_GOOD_APIC: Are there really that many processors with a bad APIC?
> 
>  Only early revisions of the P54C (75-200MHz) Pentium processors are
> affected: steppings B1, B3, B5, C2 and cB1 (or 1, 2, 4, 5 and 11) as
> reported by cpuid).  MMX Pentia and later chips are OK as well as any
> systems using external i82489DX APICs (so far i486, P5 (60/66MHz) Pentium
> and P54C Pentium systems with i82489DX APICs has been found, AFAIK).  Once
> I proposed the option to be user-selectable as an advanced CPU option
> (<asm/bugs.h> does appropriate validation), but the proposal was rejected
> as incomprehesible to an average user doing a kernel build. 

[
My questions might sound silly - I simply don't have the x86
knowledge, but I want to get the dependencies as good as possible.
]

All Cyrix/VIA/IDT/Transmeta processors have a working APIC?

What about the original 386?

Then I can simply change it in my patch to

config X86_GOOD_APIC
        bool
	depends on !CPU_586TSC
	default y

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Maciej W. Rozycki]

On Fri, 12 Sep 2003, Adrian Bunk wrote:

> What about the original 386?

 The i386 is irrelevant -- it didn't have an on-chip APIC and it didn't
directly support an external one.  At the time the APIC was manufactured,
i386 systems were inefficient enough not to justify designing glue logic
for the APIC.

> Then I can simply change it in my patch to
> 
> config X86_GOOD_APIC
>         bool
> 	depends on !CPU_586TSC
> 	default y

 It's a good estimate, although Pentium systems support an external APIC
which is always good.  If the on-chip APIC is used, a system suffers from
the erratum as mentioned previously, if an external one is used, a system
is good.

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Iau, 2003-09-11 at 07:28, Adrian Bunk wrote:
> - Does the Cyrix III support 686 instructions?

Original Cyrix III supports the IA32 P6 definition
VIA C3 supports the IA32 P6 definition
The later ones also support cmov (the gcc i686 definition)

They run 486 scheduling better it seems because its a single issue
machine. Turn off the padding tho.

> - Do -march=winchip{2,-c6} and -march=c3{,-2} add anything not in
>   -march=i686 (except optimizations of otherwise compatible code)?

Its i586 ish (but runs best with 486 code kept compact as with the C3).
It lacks some bits of Pentium (lot of profiling, appendix H type stuff)
but is 586 + optional extras in other areas.

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Thu, Sep 11, 2003 at 03:25:10PM +0100, Alan Cox wrote:
> On Iau, 2003-09-11 at 07:28, Adrian Bunk wrote:
> > - Does the Cyrix III support 686 instructions?
> 
> Original Cyrix III supports the IA32 P6 definition
> VIA C3 supports the IA32 P6 definition
> The later ones also support cmov (the gcc i686 definition)
>...

Ah, thanks.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sun, Sep 07, 2003 at 06:47:51PM +0200, Mikael Pettersson wrote:
> On Sun, 7 Sep 2003 13:28:13 +0200, Adrian Bunk wrote:
> >The patch below tries to implement a better i386 CPU selection.
> >
> >In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
> >on a 486 and above.
> >
> >In 2.6 selecting M486 means that only the 486 is supported.
> 
> Can you prove your claim about 2.6?
> 
> There is to the best of my knowledge nothing in 2.6.0-test4
> that prevents a kernel compiled for CPU type N from working
> with CPU types >N. Just to prove it, I built a CONFIG_M486
> 2.6.0-test4 and booted it w/o problems on P4, PIII, and K6-III.

Look at X86_L1_CACHE_SHIFT in arch/i386/Kconfig.

> >There are two different needs:
> >1. the installation kernel of a distribution should support all CPUs 
> >   this distribution supports (perhaps starting with the 386)
> >2. a sysadmin might e.g. want a kernel that support both a Pentium-III
> >   and a Pentium 4, but doesn't need to support a 386
> 
> How are 1 and 2 different? Both need support for CPU type N
> or higher. Since a kernel configured for a lower CPU type
> still works on higher CPU types, where is the problem?
> (In case 2 configure for PIII and use that on PIII and P4.)
> 
> Maybe I'm missing something but I don't see any problem here.

In current 2.6 this is only legal with X86_GENERIC enabled.

> /Mikael

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

The patch below tries to implement a better i386 CPU selection.

In 2.4 selecting e.g. M486 has the semantics to get a kernel that runs 
on a 486 and above.

In 2.6 selecting M486 means that only the 486 is supported.

The help text for the X86_GENERIC option says it generates a generic 
kernel but the implementation is that it supports CPUs of the selected 
M* option and above.

There are two different needs:
1. the installation kernel of a distribution should support all CPUs 
   this distribution supports (perhaps starting with the 386)
2. a sysadmin might e.g. want a kernel that support both a Pentium-III
   and a Pentium 4, but doesn't need to support a 386

The implementation in 2.4 was near to satisfy need 2., if X86_GENERIC in 
2.6 was implemented as the help text says it would satisfy the need
of 1.

The patch below against 2.6.0-test4-mm5 does a different implementation
that lets you select all CPUs you want to support and it should
therefore suit both needs.

Changes:
- changed the i386 CPU selection from a choice to single options for
  every cpu
- renamed the M* variables to CPU_*, this is needed to ask the users
  upgrading from older kernels instead of silently changing the 
  semantics
- AMD Elan is a different subarch, you can't configure a kernel that 
  runs on both the AMD Elan and other i386 CPUs
- help text changes

Questions/TODO:
- @Rusty:
  what's your opinion on making MODULE_PROC_FAMILY in 
  include/asm-i386/module.h some kind of bitmask?
- @Robert:
  there were no Elan CFLAGS in arch/i386/Makefile???
- which CPUs exactly need X86_ALIGNMENT_16?
- X86_GOOD_APIC: are there really that many processors with a bad APIC?
- could someone with a deeper knowledge of i386 CPUs comment on whether
  I got the CFLAGS in arch/i386/Makefile right for all possible CPU
  combinations?
- Kconfig handling of no CPU selected

diffstat output:

 arch/i386/Kconfig            |  237 ++++++++++++++---------------------
 arch/i386/Makefile           |   98 +++++++++++---
 arch/i386/boot/setup.S       |    2
 drivers/serial/8250.h        |    2
 include/asm-i386/processor.h |    4
 include/asm-i386/timex.h     |    2
 6 files changed, 184 insertions(+), 161 deletions(-)


A 2.6.0-test4-mm5 kernel with this patch applied compiled and bootet on
my PC.


cu
Adrian

--- linux-2.6.0-test4-mm5/arch/i386/Kconfig.old	2003-09-05 08:34:00.000000000 +0200
+++ linux-2.6.0-test4-mm5/arch/i386/Kconfig	2003-09-05 13:02:46.000000000 +0200
@@ -43,6 +43,15 @@
 	help
 	  Choose this option if your computer is a standard PC or compatible.
 
+config X86_ELAN
+	bool "Elan"
+	help
+	  Select this for an AMD Elan processor.
+	
+	  Do not use this option for K6/Athlon/Opteron processors!
+	
+	  If unsure choose "PC-compatible" instead.
+
 config X86_VOYAGER
 	bool "Voyager (NCR)"
 	help
@@ -125,48 +134,19 @@
 	default y
 	depends on SMP && X86_ES7000 && MPENTIUMIII
 
-choice
-	prompt "Processor family"
-	default M686
 
-config M386
-	bool "386"
-	---help---
-	  This is the processor type of your CPU. This information is used for
-	  optimizing purposes. In order to compile a kernel that can run on
-	  all x86 CPU types (albeit not optimally fast), you can specify
-	  "386" here.
-
-	  The kernel will not necessarily run on earlier architectures than
-	  the one you have chosen, e.g. a Pentium optimized kernel will run on
-	  a PPro, but not necessarily on a i486.
-
-	  Here are the settings recommended for greatest speed:
-	  - "386" for the AMD/Cyrix/Intel 386DX/DXL/SL/SLC/SX, Cyrix/TI
-	  486DLC/DLC2, UMC 486SX-S and NexGen Nx586.  Only "386" kernels
-	  will run on a 386 class machine.
-	  - "486" for the AMD/Cyrix/IBM/Intel 486DX/DX2/DX4 or
-	  SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or U5S.
-	  - "586" for generic Pentium CPUs lacking the TSC
-	  (time stamp counter) register.
-	  - "Pentium-Classic" for the Intel Pentium.
-	  - "Pentium-MMX" for the Intel Pentium MMX.
-	  - "Pentium-Pro" for the Intel Pentium Pro.
-	  - "Pentium-II" for the Intel Pentium II or pre-Coppermine Celeron.
-	  - "Pentium-III" for the Intel Pentium III or Coppermine Celeron.
-	  - "Pentium-4" for the Intel Pentium 4 or P4-based Celeron.
-	  - "K6" for the AMD K6, K6-II and K6-III (aka K6-3D).
-	  - "Athlon" for the AMD K7 family (Athlon/Duron/Thunderbird).
-	  - "Crusoe" for the Transmeta Crusoe series.
-	  - "Winchip-C6" for original IDT Winchip.
-	  - "Winchip-2" for IDT Winchip 2.
-	  - "Winchip-2A" for IDT Winchips with 3dNow! capabilities.
-	  - "CyrixIII/VIA C3" for VIA Cyrix III or VIA C3.
-	  - "VIA C3-2 for VIA C3-2 "Nehemiah" (model 9 and above).
+if !X86_ELAN
 
-	  If you don't know what to do, choose "386".
+menu "Processor support"
 
-config M486
+comment "Select all processors your kernel should support"
+
+config CPU_386
+	bool "386"
+	help
+	  Select this for a 386 series processor.
+
+config CPU_486
 	bool "486"
 	help
 	  Select this for a 486 series processor, either Intel or one of the
@@ -174,227 +154,210 @@
 	  DX2, and DX4 variants; also SL/SLC/SLC2/SLC3/SX/SX2 and UMC U5D or
 	  U5S.
 
-config M586
+config CPU_586
 	bool "586/K5/5x86/6x86/6x86MX"
 	help
 	  Select this for an 586 or 686 series processor such as the AMD K5,
 	  the Intel 5x86 or 6x86, or the Intel 6x86MX.  This choice does not
 	  assume the RDTSC (Read Time Stamp Counter) instruction.
 
-config M586TSC
+config CPU_586TSC
 	bool "Pentium-Classic"
 	help
 	  Select this for a Pentium Classic processor with the RDTSC (Read
-	  Time Stamp Counter) instruction for benchmarking.
+	  Time Stamp Counter) instruction.
 
-config M586MMX
+config CPU_586MMX
 	bool "Pentium-MMX"
 	help
 	  Select this for a Pentium with the MMX graphics/multimedia
 	  extended instructions.
 
-config M686
+config CPU_686
 	bool "Pentium-Pro"
 	help
-	  Select this for Intel Pentium Pro chips.  This enables the use of
-	  Pentium Pro extended instructions, and disables the init-time guard
-	  against the f00f bug found in earlier Pentiums.
+	  Select this for Intel Pentium Pro chips.
 
-config MPENTIUMII
+config CPU_PENTIUMII
 	bool "Pentium-II/Celeron(pre-Coppermine)"
 	help
 	  Select this for Intel chips based on the Pentium-II and
-	  pre-Coppermine Celeron core.  This option enables an unaligned
-	  copy optimization, compiles the kernel with optimization flags
-	  tailored for the chip, and applies any applicable Pentium Pro
-	  optimizations.
+	  pre-Coppermine Celeron core.
 
-config MPENTIUMIII
+config CPU_PENTIUMIII
 	bool "Pentium-III/Celeron(Coppermine)/Pentium-III Xeon"
 	help
 	  Select this for Intel chips based on the Pentium-III and
-	  Celeron-Coppermine core.  This option enables use of some
-	  extended prefetch instructions in addition to the Pentium II
-	  extensions.
+	  Celeron-Coppermine core.
 
-config MPENTIUM4
+config CPU_PENTIUM4
 	bool "Pentium-4/Celeron(P4-based)/Xeon"
 	help
 	  Select this for Intel Pentium 4 chips.  This includes both
-	  the Pentium 4 and P4-based Celeron chips.  This option
-	  enables compile flags optimized for the chip, uses the
-	  correct cache shift, and applies any applicable Pentium III
-	  optimizations.
+	  the Pentium 4 and P4-based Celeron chips.
 
-config MK6
+config CPU_K6
 	bool "K6/K6-II/K6-III"
 	help
-	  Select this for an AMD K6-family processor.  Enables use of
-	  some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD K6, K6-II or K6-III (aka K6-3D).
 
-config MK7
+config CPU_K7
 	bool "Athlon/Duron/K7"
 	help
-	  Select this for an AMD Athlon K7-family processor.  Enables use of
-	  some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD Athlon K7-family processor.
 
-config MK8
+config CPU_K8
 	bool "Opteron/Athlon64/Hammer/K8"
 	help
-	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.  Enables
-	  use of some extended instructions, and passes appropriate optimization
-	  flags to GCC.
+	  Select this for an AMD Opteron or Athlon64 Hammer-family processor.
 
-config MELAN
-	bool "Elan"
-
-config MCRUSOE
+config CPU_CRUSOE
 	bool "Crusoe"
 	help
-	  Select this for a Transmeta Crusoe processor.  Treats the processor
-	  like a 586 with TSC, and sets some GCC optimization flags (like a
-	  Pentium Pro with no alignment requirements).
+	  Select this for a Transmeta Crusoe processor.
 
-config MWINCHIPC6
+config CPU_WINCHIPC6
 	bool "Winchip-C6"
 	help
-	  Select this for an IDT Winchip C6 chip.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment requirements.
+	  Select this for an IDT Winchip C6 chip.
 
-config MWINCHIP2
+config CPU_WINCHIP2
 	bool "Winchip-2"
 	help
-	  Select this for an IDT Winchip-2.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment requirements.
+	  Select this for an IDT Winchip-2.
 
-config MWINCHIP3D
+config CPU_WINCHIP3D
 	bool "Winchip-2A/Winchip-3"
 	help
-	  Select this for an IDT Winchip-2A or 3.  Linux and GCC
-	  treat this chip as a 586TSC with some extended instructions
-	  and alignment reqirements.  Also enable out of order memory
-	  stores for this CPU, which can increase performance of some
-	  operations.
-
-config MCYRIXIII
-	bool "CyrixIII/VIA-C3"
-	help
-	  Select this for a Cyrix III or C3 chip.  Presently Linux and GCC
-	  treat this chip as a generic 586. Whilst the CPU is 686 class,
-	  it lacks the cmov extension which gcc assumes is present when
-	  generating 686 code.
-	  Note that Nehemiah (Model 9) and above will not boot with this
-	  kernel due to them lacking the 3DNow! instructions used in earlier
-	  incarnations of the CPU.
+	  Select this for an IDT Winchip-2A or 3 with 3dNow!
+	  capabilities.
+
+config CPU_CYRIXIII
+	bool "Cyrix III/VIA C3"
+	help
+	  Select this for a Cyrix III or VIA C3 chip.
 
-config MVIAC3_2
+	  Note that Nehemiah (Model 9) and above need the next
+	  option instead.
+
+config CPU_VIAC3_2
 	bool "VIA C3-2 (Nehemiah)"
 	help
-	  Select this for a VIA C3 "Nehemiah". Selecting this enables usage
-	  of SSE and tells gcc to treat the CPU as a 686.
-	  Note, this kernel will not boot on older (pre model 9) C3s.
+	  Select this for a VIA C3 "Nehemiah" (model 9 and above).
 
-endchoice
+endmenu
 
-config X86_GENERIC
-       bool "Generic x86 support" 
-       help
-       	  Including some tuning for non selected x86 CPUs too.
-	  when it has moderate overhead. This is intended for generic 
-	  distributions kernels.
+endif
+
+#
+# helper options
+#
+config CPU_WINCHIP
+	bool
+	depends on CPU_WINCHIPC6 || CPU_WINCHIP2 || CPU_WINCHIP3D
+	default y
+
+config CPU_ONLY_K7
+	bool
+	depends on CPU_K7 && !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_K8
+	bool
+	depends on CPU_K8 && !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K7 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
+
+config CPU_ONLY_WINCHIP
+	bool
+	depends on CPU_WINCHIP && !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K7 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_CYRIXIII && !CPU_VIAC3_2
+	default y
 
 #
 # Define implied options from the CPU selection here
 #
 config X86_CMPXCHG
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_XADD
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_L1_CACHE_SHIFT
 	int
-	default "7" if MPENTIUM4 || X86_GENERIC
-	default "4" if MELAN || M486 || M386
-	default "5" if MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCRUSOE || MCYRIXIII || MK6 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || M586 || MVIAC3_2
-	default "6" if MK7 || MK8
+	default "7" if CPU_PENTIUM4
+	default "6" if CPU_K7 || CPU_K8
+	default "5" if CPU_WINCHIP || CPU_CRUSOE || CPU_CYRIXIII || CPU_K6 || CPU_PENTIUMIII || CPU_PENTIUMII || CPU_686 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_VIAC3_2
+	default "4" if X86_ELAN || CPU_486 || CPU_386
 
 config RWSEM_GENERIC_SPINLOCK
 	bool
-	depends on M386
+	depends on CPU_386
 	default y
 
 config RWSEM_XCHGADD_ALGORITHM
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_PPRO_FENCE
 	bool
-	depends on M686 || M586MMX || M586TSC || M586 || M486 || M386
+	depends on CPU_686
 	default y
 
 config X86_F00F_BUG
 	bool
-	depends on M586MMX || M586TSC || M586 || M486 || M386
+	depends on CPU_586MMX || CPU_586TSC
 	default y
 
 config X86_WP_WORKS_OK
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_INVLPG
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_BSWAP
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_POPAD_OK
 	bool
-	depends on !M386
+	depends on !CPU_386
 	default y
 
 config X86_ALIGNMENT_16
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MELAN || MK6 || M586MMX || M586TSC || M586 || M486 || MVIAC3_2
+	depends on CPU_WINCHIP || CPU_CYRIXIII || X86_ELAN || CPU_K6 || CPU_586MMX || CPU_586TSC || CPU_586 || CPU_486 || CPU_VIAC3_2
 	default y
 
 config X86_GOOD_APIC
 	bool
-	depends on MK7 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || MK8
+	depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_K6 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
 	default y
 
 config X86_INTEL_USERCOPY
 	bool
-	depends on MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M586MMX || X86_GENERIC || MK8 || MK7
+	depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_686 && !CPU_K6 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_CYRIXIII && !CPU_VIAC3_2
 	default y
 
 config X86_USE_PPRO_CHECKSUM
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6 || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || MK8 || MVIAC3_2
+	depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !X86_ELAN && !CPU_CRUSOE
 	default y
 
 config X86_USE_3DNOW
 	bool
-	depends on MCYRIXIII || MK7
+	depends on !CPU_386 && !CPU_486 && !CPU_586 && !CPU_586TSC && !CPU_586MMX && !CPU_686 && !CPU_PENTIUMII && !CPU_PENTIUMIII && !CPU_PENTIUM4 && !CPU_K6 && !CPU_K8 && !X86_ELAN && !CPU_CRUSOE && !CPU_WINCHIP && !CPU_VIAC3_2
 	default y
 
 config X86_OOSTORE
 	bool
-	depends on MWINCHIP3D || MWINCHIP2 || MWINCHIPC6
+	depends on CPU_ONLY_WINCHIP
 	default y
 
 config X86_4G
@@ -565,7 +528,7 @@
 
 config X86_TSC
 	bool
-	depends on (MWINCHIP3D || MWINCHIP2 || MCRUSOE || MCYRIXIII || MK7 || MK6 || MPENTIUM4 || MPENTIUMIII || MPENTIUMII || M686 || M586MMX || M586TSC || MK8 || MVIAC3_2) && !X86_NUMAQ
+	depends on !X86_NUMAQ && !CPU_386 && !CPU_486 && !CPU_586 && !X86_ELAN && !CPU_WINCHIPC6
 	default y
 
 config X86_MCE
--- linux-2.6.0-test4-mm5/arch/i386/Makefile.old	2003-09-05 10:22:38.000000000 +0200
+++ linux-2.6.0-test4-mm5/arch/i386/Makefile	2003-09-05 13:03:02.000000000 +0200
@@ -28,28 +28,88 @@
 
 align := $(subst -functions=0,,$(call check_gcc,-falign-functions=0,-malign-functions=0))
 
-cflags-$(CONFIG_M386)		+= -march=i386
-cflags-$(CONFIG_M486)		+= -march=i486
-cflags-$(CONFIG_M586)		+= -march=i586
-cflags-$(CONFIG_M586TSC)	+= -march=i586
-cflags-$(CONFIG_M586MMX)	+= $(call check_gcc,-march=pentium-mmx,-march=i586)
-cflags-$(CONFIG_M686)		+= -march=i686
-cflags-$(CONFIG_MPENTIUMII)	+= $(call check_gcc,-march=pentium2,-march=i686)
-cflags-$(CONFIG_MPENTIUMIII)	+= $(call check_gcc,-march=pentium3,-march=i686)
-cflags-$(CONFIG_MPENTIUM4)	+= $(call check_gcc,-march=pentium4,-march=i686)
-cflags-$(CONFIG_MK6)		+= $(call check_gcc,-march=k6,-march=i586)
+ifdef CONFIG_CPU_PENTIUM4
+  CFLAGS_CPU	:= $(call check_gcc,-march=pentium4,-march=i686)
+endif
+
+ifdef CONFIG_CPU_PENTIUMIII
+CFLAGS_CPU	:= $(call check_gcc,-march=pentium3,-march=i686)
+endif
+
+ifdef CONFIG_CPU_PENTIUMII
+CFLAGS_CPU	:= $(call check_gcc,-march=pentium2,-march=i686)
+endif
+
+ifdef CONFIG_CPU_K8
+  CFLAGS_CPU	:= $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
+endif
+
 # Please note, that patches that add -march=athlon-xp and friends are pointless.
 # They make zero difference whatsosever to performance at this time.
-cflags-$(CONFIG_MK7)		+= $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
-cflags-$(CONFIG_MK8)		+= $(call check_gcc,-march=k8,$(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4))
-cflags-$(CONFIG_MCRUSOE)	+= -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MWINCHIPC6)	+= $(call check_gcc,-march=winchip-c6,-march=i586)
-cflags-$(CONFIG_MWINCHIP2)	+= $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MWINCHIP3D)	+= $(call check_gcc,-march=winchip2,-march=i586)
-cflags-$(CONFIG_MCYRIXIII)	+= $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
-cflags-$(CONFIG_MVIAC3_2)	+= $(call check_gcc,-march=c3-2,-march=i686)
+ifdef CONFIG_CPU_K7
+  CFLAGS_CPU	:= $(call check_gcc,-march=athlon,-march=i686 $(align)-functions=4)
+endif
+
+ifdef CONFIG_CPU_VIAC3_2
+  CFLAGS_CPU  := $(call check_gcc,-march=c3-2,-march=i686)
+endif
+
+ifdef CONFIG_CPU_CYRIXIII
+  CFLAGS_CPU	:= $(call check_gcc,-march=c3,-march=i486) $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_CRUSOE
+  CFLAGS_CPU	:= -march=i686 $(align)-functions=0 $(align)-jumps=0 $(align)-loops=0
+endif
+
+ifdef CONFIG_CPU_686
+  CFLAGS_CPU      := -march=i686
+endif
+
+ifdef CONFIG_CPU_K6
+  CFLAGS_CPU	:= $(call check_gcc,-march=k6,-march=i586)
+endif
+
+ifdef CONFIG_CPU_586MMX
+  CFLAGS_CPU	:= $(call check_gcc,-march=pentium-mmx,-march=i586)
+endif
+
+ifdef CONFIG_CPU_ONLY_WINCHIP
+  ifdef CONFIG_CPU_WINCHIPC6
+    CFLAGS_CPU	:= $(call check_gcc,-march=winchip-c6,-march=i586)
+  else
+    ifdef CONFIG_CPU_WINCHIP2
+      CFLAGS_CPU	:= $(call check_gcc,-march=winchip2,-march=i586)
+    else
+      ifdef CPU_WINCHIP3D
+        CFLAGS_CPU	:= $(call check_gcc,-march=winchip2,-march=i586)
+      endif
+    endif
+  endif
+else
+  ifdef CPU_WINCHIP
+    CFLAGS_CPU	:= -march=i586
+  endif
+endif
+
+ifdef CONFIG_CPU_586TSC
+CFLAGS_CPU	:= -march=i586
+endif
+
+ifdef CONFIG_CPU_586
+  CFLAGS_CPU	:= -march=i586
+endif
+
+ifdef CONFIG_CPU_486
+  CFLAGS_CPU	:= -march=i486
+endif
+
+ifdef CONFIG_CPU_386
+  CFLAGS_CPU	:= -march=i386
+endif
+
 
-CFLAGS += $(cflags-y)
+CFLAGS += $(CFLAGS_CPU)
 
 # Default subarch .c files
 mcore-y  := mach-default
--- linux-2.6.0-test4-mm5/include/asm-i386/processor.h.old	2003-09-05 12:46:37.000000000 +0200
+++ linux-2.6.0-test4-mm5/include/asm-i386/processor.h	2003-09-05 12:47:08.000000000 +0200
@@ -544,7 +544,7 @@
 #define K7_NOP7        ".byte 0x8D,0x04,0x05,0,0,0,0\n"
 #define K7_NOP8        K7_NOP7 ASM_NOP1
 
-#ifdef CONFIG_MK8
+#ifdef CONFIG_CPU_ONLY_K8
 #define ASM_NOP1 K8_NOP1
 #define ASM_NOP2 K8_NOP2
 #define ASM_NOP3 K8_NOP3
@@ -553,7 +553,7 @@
 #define ASM_NOP6 K8_NOP6
 #define ASM_NOP7 K8_NOP7
 #define ASM_NOP8 K8_NOP8
-#elif defined(CONFIG_MK7)
+#elif defined(CONFIG_CPU_ONLY_K7)
 #define ASM_NOP1 K7_NOP1
 #define ASM_NOP2 K7_NOP2
 #define ASM_NOP3 K7_NOP3
--- linux-2.6.0-test4-mm5/drivers/serial/8250.h.old	2003-09-05 10:21:47.000000000 +0200
+++ linux-2.6.0-test4-mm5/drivers/serial/8250.h	2003-09-05 10:22:03.000000000 +0200
@@ -44,7 +44,7 @@
 
 #undef SERIAL_DEBUG_PCI
 
-#if defined(__i386__) && (defined(CONFIG_M386) || defined(CONFIG_M486))
+#if defined(__i386__) && (defined(CONFIG_CPU_386) || defined(CONFIG_CPU_486))
 #define SERIAL_INLINE
 #endif
   
--- linux-2.6.0-test4-mm5/arch/i386/boot/setup.S.old	2003-09-05 12:35:25.000000000 +0200
+++ linux-2.6.0-test4-mm5/arch/i386/boot/setup.S	2003-09-05 12:35:38.000000000 +0200
@@ -744,7 +744,7 @@
 # AMD Elan bug fix by Robert Schwebel.
 #
 
-#if defined(CONFIG_MELAN)
+#if defined(CONFIG_X86_ELAN)
 	movb $0x02, %al			# alternate A20 gate
 	outb %al, $0x92			# this works on SC410/SC520
 a20_elan_wait:
--- linux-2.6.0-test4-mm5/include/asm-i386/timex.h.old	2003-09-05 12:36:47.000000000 +0200
+++ linux-2.6.0-test4-mm5/include/asm-i386/timex.h	2003-09-05 12:36:59.000000000 +0200
@@ -12,7 +12,7 @@
 #ifdef CONFIG_X86_PC9800
    extern int CLOCK_TICK_RATE;
 #else
-#ifdef CONFIG_MELAN
+#ifdef CONFIG_X86_ELAN
 #  define CLOCK_TICK_RATE 1189200 /* AMD Elan has different frequency! */
 #else
 #  define CLOCK_TICK_RATE 1193182 /* Underlying HZ */

Re: RFC: [2.6 patch] better i386 CPU selection

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1550 bytes --]

On Sun, 2003-09-07 13:28:13 +0200, Adrian Bunk <bunk@fs.tum.de>
wrote in message <20030907112813.GQ14436@fs.tum.de>:
> There are two different needs:
> 1. the installation kernel of a distribution should support all CPUs 
>    this distribution supports (perhaps starting with the 386)

So far, no major distribution does support an i386. Basically, this has
leaked in by some broken patch to libstdc++ which was not observed for a
long time. To support i386, an additional emulator for additional i486
needs to be compiled-in, too. I had a short try to port Debian's patch
into 2.6.x, but it oopsed :-> If I get some time, I'll finish that.
Before we have thie i486-emu-for-i386 in, i386 support in the kernel
doesn't make *any* sense on it's own...

> Changes:
> - changed the i386 CPU selection from a choice to single options for
>   every cpu
> - renamed the M* variables to CPU_*, this is needed to ask the users
>   upgrading from older kernels instead of silently changing the 
>   semantics
> - AMD Elan is a different subarch, you can't configure a kernel that 
>   runs on both the AMD Elan and other i386 CPUs

Oh well, the Elan is a beasty thing:) However, I like your overall
approach, though.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sun, Sep 07, 2003 at 01:46:47PM +0200, Jan-Benedict Glaw wrote:
> On Sun, 2003-09-07 13:28:13 +0200, Adrian Bunk <bunk@fs.tum.de>
> wrote in message <20030907112813.GQ14436@fs.tum.de>:
> > There are two different needs:
> > 1. the installation kernel of a distribution should support all CPUs 
> >    this distribution supports (perhaps starting with the 386)
> 
> So far, no major distribution does support an i386. Basically, this has
> leaked in by some broken patch to libstdc++ which was not observed for a
> long time. To support i386, an additional emulator for additional i486
> needs to be compiled-in, too. I had a short try to port Debian's patch
> into 2.6.x, but it oopsed :-> If I get some time, I'll finish that.
> Before we have thie i486-emu-for-i386 in, i386 support in the kernel
> doesn't make *any* sense on it's own...
>...

This is not related to the issues my patch addresses.

If you want to read my mail with a s/386/486/g and the contents should 
still be valid.

> MfG, JBG

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1472 bytes --]

On Sun, 2003-09-07 15:17:32 +0200, Adrian Bunk <bunk@fs.tum.de>
wrote in message <20030907131732.GU14436@fs.tum.de>:
> On Sun, Sep 07, 2003 at 01:46:47PM +0200, Jan-Benedict Glaw wrote:
> > On Sun, 2003-09-07 13:28:13 +0200, Adrian Bunk <bunk@fs.tum.de>
> > wrote in message <20030907112813.GQ14436@fs.tum.de>:
> > > There are two different needs:
> > > 1. the installation kernel of a distribution should support all CPUs 
> > >    this distribution supports (perhaps starting with the 386)
> > 
> > So far, no major distribution does support an i386. Basically, this has
> > leaked in by some broken patch to libstdc++ which was not observed for a
> > long time. To support i386, an additional emulator for additional i486
> > needs to be compiled-in, too. I had a short try to port Debian's patch
> > into 2.6.x, but it oopsed :-> If I get some time, I'll finish that.
> > Before we have thie i486-emu-for-i386 in, i386 support in the kernel
> > doesn't make *any* sense on it's own...
> >...
> 
> This is not related to the issues my patch addresses.

This is why I wrote that I basically like the overall concept of your
patch.

MfG, JBG

-- 
   Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481
   "Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg
    fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!
      ret = do_actions((curr | FREE_SPEECH) & ~(IRAQ_WAR_2 | DRM | TCPA));

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: RFC: [2.6 patch] better i386 CPU selection

[Sam Ravnborg]

On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
Could you change this:
> +ifdef CONFIG_CPU_386
> +  CFLAGS_CPU	:= -march=i386
> +endif
> +
>  
> -CFLAGS += $(cflags-y)
> +CFLAGS += $(CFLAGS_CPU)

to:
cpuflags-$(CONFIG_CPU_386) := -march=i386
CFLAGS += $(cflags-y) $(cpuflags-y)

I kept cflags-y, but you may have totally eliminated that?

	Sam

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sun, Sep 07, 2003 at 02:42:37PM +0200, Sam Ravnborg wrote:
> On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
> Could you change this:
> > +ifdef CONFIG_CPU_386
> > +  CFLAGS_CPU	:= -march=i386
> > +endif
> > +
> >  
> > -CFLAGS += $(cflags-y)
> > +CFLAGS += $(CFLAGS_CPU)
> 
> to:
> cpuflags-$(CONFIG_CPU_386) := -march=i386
> CFLAGS += $(cflags-y) $(cpuflags-y)

If I understand you correctly this doesn't change the functionality,
it's a s/CFLAGS_CPU/cpuflags-y/g ?

> I kept cflags-y, but you may have totally eliminated that?

AFAIK the cflags-y did what your proposed cpuflags-y does.

> 	Sam

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Robert Schwebel]

On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
> The patch below tries to implement a better i386 CPU selection.

Did you look at how rmk does CPU selection in the ARM tree? He has
developed a very sophisticated scheme as there are lots of completely
different cpu implementations, using a few cores. It might be an idea to
make the schemes more uniform than they are now. 

> There are two different needs:
> 1. the installation kernel of a distribution should support all CPUs 
>    this distribution supports (perhaps starting with the 386)

Ack. 

> 2. a sysadmin might e.g. want a kernel that support both a Pentium-III
>    and a Pentium 4, but doesn't need to support a 386

Ack. 

3. Embedded forlks might want to make a kernel which has support for
exactly the used processor and nothing more. 

> Changes:
[...]
> - AMD Elan is a different subarch, you can't configure a kernel that 
>   runs on both the AMD Elan and other i386 CPUs

Ack. Same with for example Geode. And the subarchs might have different
implementations, like Elan SC400, Elan SC410, Elan SC520. 

> - @Robert:
>   there were no Elan CFLAGS in arch/i386/Makefile???

That seems to have evolved since I last touched the Elan stuff. The
Elans are more or less 486 cores with some edges, so adding -march=i486
should be ok. 

> - which CPUs exactly need X86_ALIGNMENT_16?

I've just copied that from 486. 

> A 2.6.0-test4-mm5 kernel with this patch applied compiled and bootet on
> my PC.

I could do some tests on an Elan board, but not earlier than end of next
week as I'm out of office for some days...

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstraße 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sun, Sep 07, 2003 at 02:42:51PM +0200, Robert Schwebel wrote:
> On Sun, Sep 07, 2003 at 01:28:13PM +0200, Adrian Bunk wrote:
> > The patch below tries to implement a better i386 CPU selection.
> 
> Did you look at how rmk does CPU selection in the ARM tree? He has
> developed a very sophisticated scheme as there are lots of completely
> different cpu implementations, using a few cores. It might be an idea to
> make the schemes more uniform than they are now. 

I didn't look at the ARM Makefile. Thanks for the note, I'll have a look 
at it before I'll do the revision of this patch.

>...
> > Changes:
> [...]
> > - AMD Elan is a different subarch, you can't configure a kernel that 
> >   runs on both the AMD Elan and other i386 CPUs
> 
> Ack. Same with for example Geode. And the subarchs might have different

It seems the Geode support isn't fully merged in 2.6?

> implementations, like Elan SC400, Elan SC410, Elan SC520. 

It should be no problem to add a "Processor support" menu for the Elan
that allows you to specify which Elan CPUs you plan to support.

> > - @Robert:
> >   there were no Elan CFLAGS in arch/i386/Makefile???
> 
> That seems to have evolved since I last touched the Elan stuff. The
> Elans are more or less 486 cores with some edges, so adding -march=i486
> should be ok. 
>...

Thanks, I'll do this.

> Robert

Thanks for your comments
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Robert Schwebel]

On Sun, Sep 07, 2003 at 03:00:34PM +0200, Adrian Bunk wrote:
> I didn't look at the ARM Makefile. Thanks for the note, I'll have a
> look at it before I'll do the revision of this patch.

You should definitely discuss this with rmk. How do the PPC folks handle
CPU selection? 

> > Ack. Same with for example Geode. And the subarchs might have different
> 
> It seems the Geode support isn't fully merged in 2.6?

That's also my impression, although I didn't have much time to look at
the state. As far as I remember Christer Weinigel has recently done some
work in this direction. 

> It should be no problem to add a "Processor support" menu for the Elan
> that allows you to specify which Elan CPUs you plan to support.

Great. 

Robert 
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstraße 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: RFC: [2.6 patch] better i386 CPU selection

[Tom Rini]

On Sun, Sep 07, 2003 at 03:14:43PM +0200, Robert Schwebel wrote:

> On Sun, Sep 07, 2003 at 03:00:34PM +0200, Adrian Bunk wrote:
> > I didn't look at the ARM Makefile. Thanks for the note, I'll have a
> > look at it before I'll do the revision of this patch.
> 
> You should definitely discuss this with rmk. How do the PPC folks handle
> CPU selection? 

We don't allow for one kernel to work on something outside of a
'family', nor do we (aside from MULTIPLATFORM) allow a kernel to work on
> 1 board type (maybe we'll fix that in 2.7).  You can pick 8xx
(MPC8xx line), 8260 (MPC826x/MPC827x, and should be fixed up to into
classic), 6xx/7xx/74xx (aka 'classic' PPC, 40x and 44x.

-- 
Tom Rini
http://gate.crashing.org/~trini/

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Sul, 2003-09-07 at 14:00, Adrian Bunk wrote:
> > Ack. Same with for example Geode. And the subarchs might have different
> 
> It seems the Geode support isn't fully merged in 2.6?

Geode is just another PC, well at least in software. In hardware its
rather different and uses a lot of clever magic.

Re: RFC: [2.6 patch] better i386 CPU selection

[Robert Schwebel]

On Sun, Sep 07, 2003 at 06:31:36PM +0100, Alan Cox wrote:
> Geode is just another PC, well at least in software. In hardware its
> rather different and uses a lot of clever magic.

It seems to be similar to the Elan: the core is "just another PC", but
in several places you need to know that you have a Geode so that you can
provide the right tweaks and fixes. 

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstraße 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Sul, 2003-09-07 at 18:48, Robert Schwebel wrote:
> It seems to be similar to the Elan: the core is "just another PC", but
> in several places you need to know that you have a Geode so that you can
> provide the right tweaks and fixes. 

ELAN is "like a PC", Geode is a PC, to software. You can run a generic
386/486/586/586+MMX kernel on a Geode CPU. The Geode support just picks
the right compile options and our setup code turns on some handy CPU
features we can use

Re: RFC: [2.6 patch] better i386 CPU selection

[Robert Schwebel]

On Sun, Sep 07, 2003 at 07:04:12PM +0100, Alan Cox wrote:
> ELAN is "like a PC", Geode is a PC, to software. You can run a generic
> 386/486/586/586+MMX kernel on a Geode CPU. The Geode support just picks
> the right compile options and our setup code turns on some handy CPU
> features we can use

Hmm, I'm not so sure. I've not much experience with Geode yet, but from
my first RTAI tests it surely has several problems which might require
an #ifdef CONFIG_MGEODE or something similar. As long as this is
possible everything's ok with me ;)

Robert
-- 
 Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de
 Pengutronix - Linux Solutions for Science and Industry
   Handelsregister:  Amtsgericht Hildesheim, HRA 2686
     Hornemannstraße 12,  31137 Hildesheim, Germany
    Phone: +49-5121-28619-0 |  Fax: +49-5121-28619-4

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Sul, 2003-09-07 at 19:26, Robert Schwebel wrote:
> my first RTAI tests it surely has several problems which might require
> an #ifdef CONFIG_MGEODE or something similar. As long as this is
> possible everything's ok with me ;)

Lots of the geode hardware is emulated by SMM code, it makes hard real
time on the Geode an 'interesting' world and does limit the latency you
can achieve. Its actually a lot better than say the Dell BIOS battery
SMM seems to be but its not insubstantial at times.

rdtsc before and after an inb/outb is most fascinating 8)

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

On Sul, 2003-09-07 at 19:26, Robert Schwebel wrote:
> my first RTAI tests it surely has several problems which might require
> an #ifdef CONFIG_MGEODE or something similar. As long as this is
> possible everything's ok with me ;)

Lots of the geode hardware is emulated by SMM code, it makes hard real
time on the Geode an 'interesting' world and does limit the latency you
can achieve. Its actually a lot better than say the Dell BIOS battery
SMM seems to be but its not insubstantial at times.

rdtsc before and after an inb/outb is most fascinating 8)

Re: RFC: [2.6 patch] better i386 CPU selection

[Alan Cox]

This would be a good point to fix the winchip compile options properly
in 2.6 while you are at it. You should select -m486 (preferably
-m486 and then turn off the padding options)

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Sun, Sep 07, 2003 at 06:25:30PM +0100, Alan Cox wrote:

> This would be a good point to fix the winchip compile options properly
> in 2.6 while you are at it. You should select -m486 (preferably
> -m486 and then turn off the padding options)

You are talking about the default for gcc versions that don't support 
-march=winchip{2,-c6} ?

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Rusty Russell]

In message <20030907112813.GQ14436@fs.tum.de> you write:
> - @Rusty:
>   what's your opinion on making MODULE_PROC_FAMILY in 
>   include/asm-i386/module.h some kind of bitmask?

The current one is readable, which is good, and Linus asked for it,
which makes it kinda moot.  And really, if you compile a module with
M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
for CPU seleciton, I want the poor user to have to use "modprobe -f".

Hope that clarifies,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Mon, Sep 08, 2003 at 10:46:30AM +1000, Rusty Russell wrote:
> In message <20030907112813.GQ14436@fs.tum.de> you write:
> > - @Rusty:
> >   what's your opinion on making MODULE_PROC_FAMILY in 
> >   include/asm-i386/module.h some kind of bitmask?
> 
> The current one is readable, which is good, and Linus asked for it,
> which makes it kinda moot.  And really, if you compile a module with
> M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
> for CPU seleciton, I want the poor user to have to use "modprobe -f".

I agree, my thoughts go in the direction

bit 0 CPU_386
bit 1 CPU_486
bit 2 CPU_586
...

And you should need a "modprobe -f" if the bitmask in the module differs 
from the bitmask in the kernel.

> Hope that clarifies,
> Rusty.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Re: RFC: [2.6 patch] better i386 CPU selection

[Rusty Russell]

In message <20030908142920.GB28062@fs.tum.de> you write:
> On Mon, Sep 08, 2003 at 10:46:30AM +1000, Rusty Russell wrote:
> > In message <20030907112813.GQ14436@fs.tum.de> you write:
> > > - @Rusty:
> > >   what's your opinion on making MODULE_PROC_FAMILY in 
> > >   include/asm-i386/module.h some kind of bitmask?
> > 
> > The current one is readable, which is good, and Linus asked for it,
> > which makes it kinda moot.  And really, if you compile a module with
> > M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
> > for CPU seleciton, I want the poor user to have to use "modprobe -f".
> 
> I agree, my thoughts go in the direction
> 
> bit 0 CPU_386
> bit 1 CPU_486
> bit 2 CPU_586

We had a bitmask, which Linus said to replace with a string.  We have
21 architectures, and a string works well in practice.  We could have
a bitmask *and* a string, but why the complexity?

> And you should need a "modprobe -f" if the bitmask in the module differs 
> from the bitmask in the kernel.

All modprobe -f knows is that it should remove/rename various sections
from the elf object before handing it to the kernel.  The checking is
done in the kernel, as it should be (so we could change this whenever
we want, for example).

Hope that clarifies,
Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.

Re: RFC: [2.6 patch] better i386 CPU selection

[Adrian Bunk]

On Tue, Sep 09, 2003 at 11:11:21AM +1000, Rusty Russell wrote:
> In message <20030908142920.GB28062@fs.tum.de> you write:
> > On Mon, Sep 08, 2003 at 10:46:30AM +1000, Rusty Russell wrote:
> > > In message <20030907112813.GQ14436@fs.tum.de> you write:
> > > > - @Rusty:
> > > >   what's your opinion on making MODULE_PROC_FAMILY in 
> > > >   include/asm-i386/module.h some kind of bitmask?
> > > 
> > > The current one is readable, which is good, and Linus asked for it,
> > > which makes it kinda moot.  And really, if you compile a module with
> > > M686 and insert it in a kernel with M586, *WHATEVER* scheme you we use
> > > for CPU seleciton, I want the poor user to have to use "modprobe -f".
> > 
> > I agree, my thoughts go in the direction
> > 
> > bit 0 CPU_386
> > bit 1 CPU_486
> > bit 2 CPU_586
> 
> We had a bitmask, which Linus said to replace with a string.  We have
> 21 architectures, and a string works well in practice.  We could have
> a bitmask *and* a string, but why the complexity?
>...

My intention is that the user (= person compiling the kernel) selects 
all CPUs he wants to support and to move the answer to questions like 
"Which CPU type should I choose to support both an AMD Athlon and a
Pentium 4?" into the Kconfig/Makefile where it's automatically selected.

> Hope that clarifies,
> Rusty.

cu
Adrian

-- 

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed