Skip to contentSkip to conversation

2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64

RFC PATCH In review Christian 10 participants 44 messages May 17, 2007 – May 31, 2007

lore
Share & tools
lore

Christian

author
#0 lore raw

Hi,

my small VIA C3_2 box does not boot with 2.6.22-rc1. It even does not uncompress the kernel.

The configuration as M386 M486 works. But M586 + MVIAC3_2 does not work.

solution for me, cahnge arch/i386/Kconfig.cpu

i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200 renamed from i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200 +1 -1
@@ -299,5 +299,5 @@
 
 config X86_CMPXCHG64
        bool
-       depends on !M386 && !M486
+       depends on !M386 && !M486 && !MVIAC3_2
        default y

The related #ifdef is in ./include/asm-i386/cmpxchg.h May be cmpxchg8b is not supported by VIAC3_2 ?

May be some other non Intel/AMD need to be excluded from X86_CMPXCHG64 ? May be the generic option CONFIG_X86_GENERIC need to switch this off also ?

Just write an email to me if you want to send a patch to test on a C3_2.

Best regards,

Christian

#1 lore raw
Quoted 19 lines · Christian

my small VIA C3_2 box does not boot with 2.6.22-rc1. It even does not uncompress the kernel.

The configuration as M386 M486 works. But M586 + MVIAC3_2 does not work.

solution for me, cahnge arch/i386/Kconfig.cpu

i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200 renamed from i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200 +1 -1
@@ -299,5 +299,5 @@
 
 config X86_CMPXCHG64
        bool
-       depends on !M386 && !M486
+       depends on !M386 && !M486 && !MVIAC3_2
        default y
Quoted 5 lines

The related #ifdef is in ./include/asm-i386/cmpxchg.h May be cmpxchg8b is not supported by VIAC3_2 ?

May be some other non Intel/AMD need to be excluded from X86_CMPXCHG64 ? May be the generic option CONFIG_X86_GENERIC need to switch this off also ?

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

Did we add code that uses cmpxchg8b before identify_cpu() gets run ? I've not been paying attention to .22rc (busy trying to beat .21 into shape for F7) so I may have missed something obvious. Andi?

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#2 lore raw
Quoted 8 lines · Dave Jones

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

Did we add code that uses cmpxchg8b before identify_cpu() gets run ? I've not been paying attention to .22rc (busy trying to beat .21 into shape for F7) so I may have missed something obvious. Andi?

Andi added code to verify that we can actually execute on the processor before protected mode (so we can still get a message out through the BIOS.) That code presumably doesn't know of the MSR that needs to be touched.

That code is in assembly in Andi's version, my rewritten version has it in C. I should add this code.

-hpa

#3 lore raw
Quoted 9 lines · H. Peter Anvin

Andi added code to verify that we can actually execute on the processor before protected mode (so we can still get a message out through the BIOS.) That code presumably doesn't know of the MSR that needs to be touched.

That code is in assembly in Andi's version, my rewritten version has it in C. I should add this code.

The newsetup tree now has code to unmask features on VIA and Transmeta (as well as AMD, which was already in there):

http://git.kernel.org/?p=linux/kernel/git/hpa/linux-2.6-newsetup.git;a=commitdiff;h=c9cf55604433b386d0b499ed7bed654fd01c3be2

-hpa

author
#4 lore raw
In reply to Dave Jones
Quoted 9 lines · Dave Jones

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

Did we add code that uses cmpxchg8b before identify_cpu() gets run ? I've not been paying attention to .22rc (busy trying to beat .21 into shape for F7) so I may have missed something obvious. Andi?

Dave

May I brought up a wrong reason with the command cmpxchg64. But disabling CONFIG_X86_CMPXCHG64 helps.

The via C3 EBGA datasheet R1.9 tells me this command works always:

Quoted 3 lines

The CMPXCHG8B instruction is provided and always enabled, however, it appears disabled in the corresponding CPUID function bit 0 to avoid a bug in an early version of Windows NT. However, this default can be changed via a bit in the FCR MSR.

Hmm, I should be able to add a few small "here I am" to the my local boot code with a little hint.

Anyway I will try tomorrow to find this on my own. printfs for debugging are more friendly than assembler.

Quoted 4 lines · H. Peter Anvin

Andi added code to verify that we can actually execute on the processor before protected mode (so we can still get a message out through the BIOS.) That code presumably doesn't know of the MSR that needs to be touched.

Best regards,

Christian

author
#5 lore raw

Christian wrote:
Hmm, I really think so...:

Quoted 4 lines

May I brought up a wrong reason with the command cmpxchg64. But disabling CONFIG_X86_CMPXCHG64 helps.

Hi,

I found some time to investigate. My resume is:

- kernel/verify_cpu.S causes the stop at boot time Cause the required flag for CMPXCHG8B is not set.

- boot/setup.S did not print "PANIC: CPU too old for this kernel" ( not visible, also the message did not match )

- VIA C3_2: CMPXCHG8B should work always. Via C3 EBGA Datasheet R1.90 page 30 (3-4) But the bit is not set cause of some early Win NT bugs.

- X86_CMPXCHG64 can be set and used. Just verify_cpu.S requires a change to ignore the missing indicator at boot time.

My suggestion for the fix is:

- kernel/verify_cpu.S should be more tolerant if CONFIG_MVIAC3_2 is set ( see patch below )

- boot/setup.S should be fixed to print out a proper error message ( see below )

- X86_CMPXCHG64 patch(earlier mail in thread ) should not be used.

- Important: somebody to check other CPU types if the same behavior happens.

- middle term solution already planed: introduce arch/i386/boot/cpucheck.c

To be done by somebody with more detail knowledge than me: (never did x86 assembler before)

- I add "# missed before: set ds"
=> somebody should check if I am right with the way to set.
=> seems to be a generic error in setup.S not to set "ds" for error messages.

- other X86-CPU than AMD (?) or Intel
=> correct verify_cpu.S or set bits if required.

Best regards,

Christian

i386/kernel/verify_cpu.S 2007-05-17 23:14:18.266679323 +0200 renamed from i386/kernel/verify_cpu.S 2007-05-17 05:17:40.000000000 +0200 +6 -0
@@ -54,6 +54,12 @@
 
        andl    $REQUIRED_MASK1,%edx
        xorl    $REQUIRED_MASK1,%edx
+/* VIAC3 does not report the existing CMPXCHG64 by default. So do not go to bad for CMPXCHG64 for this */
+/* via C3 EBGA datasheet R1.9 tells the command works also without shown bit. */
+#if CONFIG_MVIAC3_2
+       andl    $~NEED_CMPXCHG64,%edx
+#endif
+
        jnz     bad
 #endif /* REQUIRED_MASK1 */
i386/boot/setup.S 2007-05-17 23:12:36.815989168 +0200 renamed from i386/boot/setup.S 2007-05-17 21:53:08.009226208 +0200 +4 -1
@@ -310,12 +310,15 @@
        call verify_cpu
        testl  %eax,%eax
        jz      cpu_ok
+       # missed before: set ds
+       movw    %cs, %ax                # aka SETUPSEG
+       movw    %ax, %ds
        lea     cpu_panic_mess,%si
        call    prtstr
 1:     jmp     1b
 
 cpu_panic_mess:
-       .asciz  "PANIC: CPU too old for this kernel."
+       .asciz  "PANIC: CPU too old for this kernel or CPUID function bits are wrong."
 
 #include "../kernel/verify_cpu.S"
#6 lore raw
Quoted 1 line · Christian Volkmann

- Important: somebody to check other CPU types if the same behavior happens.

arch/i386/kernel/cpu/rise.c

Though, I've *never* seen or even heard of someone with one of those CPUs, so whether we need to care is questionable. The mp6 did actually make it to manufacture aparently, but I don't think anyone actually bought one.
http://en.wikipedia.org/wiki/Rise_Technology for a pic of this mythical beast.

Dave

Signature · 1 line
http://www.codemonkey.org.uk
author
#7 lore raw
Quoted 6 lines · Dave Jones

On Thu, May 17, 2007 at 11:28:01PM +0200, Christian Volkmann wrote:
Though, I've *never* seen or even heard of someone with one of those CPUs, so whether we need to care is questionable. The mp6 did actually make it to manufacture aparently, but I don't think anyone actually bought one.
http://en.wikipedia.org/wiki/Rise_Technology for a pic of this mythical beast.

Quoted 7 lines

Dave

My VIA C7 has the same problem, boots on 486 but not on C3-2 or C7

--
Hans

I suppose VIA C7 is another candidate for verify_cpu.S

Maybe something like this in assembler might be useful:
if ( ! Intel && ! AMD )
{
andl $~NEED_CMPXCHG64,%edx
}

This would not really harm anything but avoid this problem. But I just don't know x86 to do this proper.

Christian

#8 lore raw

RFC PATCH 1/1 i386: remove support for the Rise CPU

In reply to Dave Jones
Quoted 10 lines · Dave Jones
Quoted 1 line · Christian Volkmann

- Important: somebody to check other CPU types if the same behavior happens.

arch/i386/kernel/cpu/rise.c

Though, I've *never* seen or even heard of someone with one of those CPUs, so whether we need to care is questionable. The mp6 did actually make it to manufacture aparently, but I don't think anyone actually bought one.
http://en.wikipedia.org/wiki/Rise_Technology for a pic of this mythical beast.

Considering that arch/i386/kernel/cpu/rise.o takes a few bytes in every i386 kernel image, what about removing it?

Quoted 1 line

Dave

cu
Adrian

<-- snip -->

The Rise CPUs were only very short-lived, and there are no reports of anyone both owning one and running Linux on it.

Googling for the printk string "CPU: Rise iDragon" didn't find any dmesg available online.

If it turns out that against all expectations there are actually users reverting this patch would be easy.

This patch will make the kernel images smaller by a few bytes for all i386 users.

Signed-off-by Adrian Bunk <[email protected]>

---

 arch/i386/kernel/cpu/Makefile  |    1 
 arch/i386/kernel/cpu/common.c  |    2 -
 arch/i386/kernel/cpu/rise.c    |   52 ---------------------------------
 include/asm-i386/processor.h   |    1 
 include/asm-x86_64/processor.h |    1 
 5 files changed, 57 deletions(-)
include/asm-i386/processor.h renamed from include/asm-i386/processor.h.old +0 -1
@@ -88,7 +88,6 @@
 #define X86_VENDOR_UMC 3
 #define X86_VENDOR_NEXGEN 4
 #define X86_VENDOR_CENTAUR 5
-#define X86_VENDOR_RISE 6
 #define X86_VENDOR_TRANSMETA 7
 #define X86_VENDOR_NSC 8
 #define X86_VENDOR_NUM 9
include/asm-x86_64/processor.h renamed from include/asm-x86_64/processor.h.old +0 -1
@@ -83,7 +83,6 @@
 #define X86_VENDOR_UMC 3
 #define X86_VENDOR_NEXGEN 4
 #define X86_VENDOR_CENTAUR 5
-#define X86_VENDOR_RISE 6
 #define X86_VENDOR_TRANSMETA 7
 #define X86_VENDOR_NUM 8
 #define X86_VENDOR_UNKNOWN 0xff
arch/i386/kernel/cpu/Makefile renamed from arch/i386/kernel/cpu/Makefile.old +0 -1
@@ -9,7 +9,6 @@
 obj-y	+=	centaur.o
 obj-y	+=	transmeta.o
 obj-y	+=	intel.o intel_cacheinfo.o
-obj-y	+=	rise.o
 obj-y	+=	nexgen.o
 obj-y	+=	umc.o
arch/i386/kernel/cpu/common.c renamed from arch/i386/kernel/cpu/common.c.old +0 -2
@@ -604,7 +604,6 @@
 extern int amd_init_cpu(void);
 extern int centaur_init_cpu(void);
 extern int transmeta_init_cpu(void);
-extern int rise_init_cpu(void);
 extern int nexgen_init_cpu(void);
 extern int umc_init_cpu(void);
 

@@ -616,7 +615,6 @@
 	amd_init_cpu();
 	centaur_init_cpu();
 	transmeta_init_cpu();
-	rise_init_cpu();
 	nexgen_init_cpu();
 	umc_init_cpu();
 	early_cpu_detect();
arch/i386/kernel/cpu/rise.c deleted +0 -52

52 lines not on this page · raw message

#9 lore raw

Re: [RFC: 2.6 patch] i386: remove support for the Rise CPU

Quoted 7 lines · Adrian Bunk
Quoted 6 lines · Dave Jones
Quoted 1 line · Christian Volkmann

- Important: somebody to check other CPU types if the same behavior happens.

arch/i386/kernel/cpu/rise.c

Quoted 7 lines
Quoted 4 lines

Though, I've *never* seen or even heard of someone with one of those CPUs, so whether we need to care is questionable. The mp6 did actually make it to manufacture aparently, but I don't think anyone actually bought one.
http://en.wikipedia.org/wiki/Rise_Technology for a pic of this mythical beast.

Considering that arch/i386/kernel/cpu/rise.o takes a few bytes in every i386 kernel image, what about removing it?

I'll be amazed if someone complains.
We'll still boot fine on those CPUs without that support code too, we just won't advertise cx8 to userspace, and /proc/cpuinfo won't prettyprint the name. whoopdy-do.

Should we actually find someone who a) has one and b) is crazy enough to still run it today, we could always add this stuff back.

Signed-off-by Dave Jones <[email protected]>

Dave

Signature · 1 line
http://www.codemonkey.org.uk
author
#10 lore raw

Re: [RFC: 2.6 patch] i386: remove support for the Rise CPU

The SIS550 chip uses the mP6 core according to http://en.wikipedia.org/wiki/MP6
May be this code can improve the capability of these SIS550 system on a chip ?

But this should be a different story.

Quoted 28 lines · Dave Jones
Quoted 7 lines · Adrian Bunk
Quoted 6 lines · Dave Jones
Quoted 1 line · Christian Volkmann

- Important: somebody to check other CPU types if the same behavior happens.

arch/i386/kernel/cpu/rise.c

Quoted 7 lines
Quoted 4 lines

Though, I've *never* seen or even heard of someone with one of those CPUs, so whether we need to care is questionable. The mp6 did actually make it to manufacture aparently, but I don't think anyone actually bought one.
http://en.wikipedia.org/wiki/Rise_Technology for a pic of this mythical beast.

Considering that arch/i386/kernel/cpu/rise.o takes a few bytes in every i386 kernel image, what about removing it?

I'll be amazed if someone complains.
We'll still boot fine on those CPUs without that support code too, we just won't advertise cx8 to userspace, and /proc/cpuinfo won't prettyprint the name. whoopdy-do.

Should we actually find someone who a) has one and b) is crazy enough to still run it today, we could always add this stuff back.

Signed-off-by Dave Jones <[email protected]>

Dave

#11 lore raw

Re: [RFC: 2.6 patch] i386: remove support for the Rise CPU

Quoted 6 lines · Christian Volkmann

The SIS550 chip uses the mP6 core according to http://en.wikipedia.org/wiki/MP6
May be this code can improve the capability of these SIS550 system on a chip ?

But this should be a different story.

From what I heard (I've seen nothing definitive) those chips identify

themselves differently. ISTR that their vendor string is "SIS SIS SIS "

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#12 lore raw
In reply to Christian Volkmann
Quoted 31 lines · Christian Volkmann

Christian wrote:
Hmm, I really think so...:

Quoted 3 lines

May I brought up a wrong reason with the command cmpxchg64. But disabling CONFIG_X86_CMPXCHG64 helps.

Hi,

I found some time to investigate. My resume is:

- kernel/verify_cpu.S causes the stop at boot time Cause the required flag for CMPXCHG8B is not set.

- boot/setup.S did not print "PANIC: CPU too old for this kernel" ( not visible, also the message did not match )

- VIA C3_2: CMPXCHG8B should work always. Via C3 EBGA Datasheet R1.90 page 30 (3-4) But the bit is not set cause of some early Win NT bugs.

- X86_CMPXCHG64 can be set and used. Just verify_cpu.S requires a change to ignore the missing indicator at boot time.

My suggestion for the fix is:

- kernel/verify_cpu.S should be more tolerant if CONFIG_MVIAC3_2 is set ( see patch below )

Quoted 7 lines

- boot/setup.S should be fixed to print out a proper error message ( see below )

- X86_CMPXCHG64 patch(earlier mail in thread ) should not be used.

- Important: somebody to check other CPU types if the same behavior happens.

I applied the patch on rc2, changed 'if CONFIG_MVIAC3_2' in if CONFIG_MVIAC7' and build a working VIA C7 kernel.

Signature · 1 line
Hans
#13 lore raw
In reply to Dave Jones
Quoted 5 lines
Quoted 2 lines

May be some other non Intel/AMD need to be excluded from X86_CMPXCHG64 ? May be the generic option CONFIG_X86_GENERIC need to switch this off also ?

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

And on the resume path from S2RAM...

#14 lore raw
In reply to Dave Jones
Quoted 23 lines · Dave Jones
Quoted 22 lines · Christian

my small VIA C3_2 box does not boot with 2.6.22-rc1. It even does not uncompress the kernel.

The configuration as M386 M486 works. But M586 + MVIAC3_2 does not work.

solution for me, cahnge arch/i386/Kconfig.cpu

i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200 renamed from i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200 +1 -1
@@ -299,5 +299,5 @@
 
 config X86_CMPXCHG64
        bool
-       depends on !M386 && !M486
+       depends on !M386 && !M486 && !MVIAC3_2
        default y

The related #ifdef is in ./include/asm-i386/cmpxchg.h May be cmpxchg8b is not supported by VIAC3_2 ?

Quoted 6 lines
Quoted 3 lines

May be some other non Intel/AMD need to be excluded from X86_CMPXCHG64 ? May be the generic option CONFIG_X86_GENERIC need to switch this off also ?

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

Sigh. I wonder what genius at VIA came up with that setup.

Quoted 3 lines

Did we add code that uses cmpxchg8b before identify_cpu() gets run ? I've not been paying attention to .22rc (busy trying to beat .21 into shape for F7) so I may have missed something obvious. Andi?

That would be a bit complicated in pure asm code.
It's probably best to just not require it as in Christian's patch above. Without SMP support it is not particularly needed anyways; a irq disabling emulation should work.

-Andi

#15 lore raw
Quoted 4 lines · Andi Kleen
Quoted 2 lines

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

Sigh. I wonder what genius at VIA came up with that setup.

It was due to some incompatibility with some older Windows variants iirc.

Quoted 8 lines
Quoted 3 lines

Did we add code that uses cmpxchg8b before identify_cpu() gets run ? I've not been paying attention to .22rc (busy trying to beat .21 into shape for F7) so I may have missed something obvious. Andi?

That would be a bit complicated in pure asm code.
It's probably best to just not require it as in Christian's patch above. Without SMP support it is not particularly needed anyways; a irq disabling emulation should work.

*nod*

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#16 lore raw
In reply to Andi Kleen
Quoted 6 lines · Andi Kleen
Quoted 3 lines

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

Sigh. I wonder what genius at VIA came up with that setup.

It's very simple, actually. We had to do something similar at Transmeta, because Windows NT 4 was very fond of assuming that certain features meant certain *other* features were enabled, or would just plain crash if it saw a combination that confused it.

-hpa

#17 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

In reply to Dave Jones
Quoted 30 lines · Dave Jones
Quoted 19 lines · Christian

my small VIA C3_2 box does not boot with 2.6.22-rc1. It even does not uncompress the kernel.

The configuration as M386 M486 works. But M586 + MVIAC3_2 does not work.

solution for me, cahnge arch/i386/Kconfig.cpu

i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200 renamed from i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200 +1 -1
@@ -299,5 +299,5 @@
 
 config X86_CMPXCHG64
        bool
-       depends on !M386 && !M486
+       depends on !M386 && !M486 && !MVIAC3_2
        default y
Quoted 6 lines

The related #ifdef is in ./include/asm-i386/cmpxchg.h May be cmpxchg8b is not supported by VIAC3_2 ?

May be some other non Intel/AMD need to be excluded from X86_CMPXCHG64 ? May be the generic option CONFIG_X86_GENERIC need to switch this off also ?

The C3s all have cx8, but it needs to be enabled in an MSR first. (See arch/i386/kernel/cpu/centaur.c , search for CX8)

Quoted 3 lines

Did we add code that uses cmpxchg8b before identify_cpu() gets run ? I've not been paying attention to .22rc (busy trying to beat .21 into shape for F7) so I may have missed something obvious. Andi?

Can someone please test if this patch works?

This preserves the 6 <= model <= 9 logic of the C code; this means if VIA ever brings out model >= 10 it hopefully sets this bit by default. Dave, do you have any information to the contrary?

-Andi

arch/i386/kernel/verify_cpu.S +23 -0
Index: linux/arch/i386/kernel/verify_cpu.S
===================================================================
@@ -2,6 +2,7 @@
    This runs in 16bit mode so that the caller can still use the BIOS
    to output errors on the screen */
 #include <asm/cpufeature.h>
+#include <asm/msr.h>
 
 verify_cpu:
 	pushfl				# Save caller passed flags

@@ -45,6 +46,28 @@ verify_cpu:
 	cmpl	$0x1,%eax
 	jb	bad			# no cpuid 1
 
+#if REQUIRED_MASK1 & NEED_CMPXCHG64
+	/* Some VIA C3s need magic MSRs to enable CX64. Do this here */ 
+	cmpl	$0x746e6543,%ebx	# Cent
+	jne	1f
+	cmpl 	$0x48727561,%edx	# aurH
+	jne	1f
+	cmpl	$0x736c7561,%ecx	# auls
+	jne	1f
+	movl	$1,%eax			# check model
+	cpuid	
+	shr	$4,%eax
+	andl	$0xf,%eax		# get model
+	cmpl	$6,%eax
+	jb	1f
+	cmpl	$9,%eax			# newer vias hopefully don't require
+	ja	1f			# this anymore
+	movl	$MSR_VIA_FCR,%ecx
+	rdmsr
+	orl	$(1|(1<<7)),%eax	# enable CMPXCHG64 and PGE
+	wrmsr	
+1:
+#endif
 	movl    $0x1,%eax		# Does the cpu have what it takes
 	cpuid

-Andi

#18 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

Quoted 3 lines · Andi Kleen

This preserves the 6 <= model <= 9 logic of the C code; this means if VIA ever brings out model >= 10 it hopefully sets this bit by default. Dave, do you have any information to the contrary?

Model 10 (Esther) has the same feature.

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#19 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

Quoted 6 lines · Dave Jones
Quoted 3 lines · Andi Kleen

This preserves the 6 <= model <= 9 logic of the C code; this means if VIA ever brings out model >= 10 it hopefully sets this bit by default. Dave, do you have any information to the contrary?

Model 10 (Esther) has the same feature.

Hmm nasty. Is it safe to assume that all VIA family == 6 will have that MSR with the bit doing the same?

Perhaps we need some Centaur contact for guidance on this. Do you have a current one?

-Andi (who failed even to find current datasheets on the VIA website)

#20 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

Quoted 10 lines · Andi Kleen
Quoted 6 lines · Dave Jones
Quoted 3 lines · Andi Kleen

This preserves the 6 <= model <= 9 logic of the C code; this means if VIA ever brings out model >= 10 it hopefully sets this bit by default. Dave, do you have any information to the contrary?

Model 10 (Esther) has the same feature.

Hmm nasty. Is it safe to assume that all VIA family == 6 will have that MSR with the bit doing the same?

I would think so yes.

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#21 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

In reply to Andi Kleen

Hello Andi!

Quoted 2 lines

Can someone please test if this patch works?

it applies cleanly to 2.6.22-rc1-mm1

Could you make it also enable C7 CMPXCHG8 (cx8)?
This is because I am getting this error (as written in a diffent posting on this mailinglist)

Quoted 2 lines

This kernel requires the following features not present on the CPU... 0:8

Is verify_cpu.S being executed before or after cpucheck.c?

claas

#22 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

Quoted 11 lines · Claas Langbehn

Hello Andi!

Quoted 1 line

Can someone please test if this patch works?

it applies cleanly to 2.6.22-rc1-mm1

Could you make it also enable C7 CMPXCHG8 (cx8)?
This is because I am getting this error (as written in a diffent posting on this mailinglist)

Quoted 2 lines

This kernel requires the following features not present on the CPU... 0:8

Is verify_cpu.S being executed before or after cpucheck.c?

Neither (on i386.) cpucheck.c *replaces* verify_cpu.S.

On x86-64, verify_cpu.S is still run after in some circumstances, because it's going to be harder to extricate some of the uses of verify_cpu.S. It's still the intention, however.

-hpa

author
#23 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

In reply to Andi Kleen
Quoted 8 lines · Andi Kleen

Can someone please test if this patch works?

This preserves the 6 <= model <= 9 logic of the C code; this means if VIA ever brings out model >= 10 it hopefully sets this bit by default. Dave, do you have any information to the contrary?

-Andi

Hi Andi,

your patch did not work. See the correction below. The mask should contain 1<<1 instead of 1.
Model 10 is now also included.

I add also a patch for setup.S. It does not print the CPUID message in case the CPUID is wrong, cause %ds was not set proper.

Best regards,

Christian

arch/i386/kernel/verify_cpu.S +23 -0
Index: linux/arch/i386/kernel/verify_cpu.S
===================================================================
@@ -2,6 +2,7 @@
    This runs in 16bit mode so that the caller can still use the BIOS
    to output errors on the screen */
 #include <asm/cpufeature.h>
+#include <asm/msr.h>
 
 verify_cpu:
        pushfl                          # Save caller passed flags

@@ -45,6 +46,28 @@
        cmpl    $0x1,%eax
        jb      bad                     # no cpuid 1
 
+#if REQUIRED_MASK1 & NEED_CMPXCHG64
+       /* Some VIA C3s need magic MSRs to enable CX64. Do this here */
+       cmpl    $0x746e6543,%ebx        # Cent
+       jne     1f
+       cmpl    $0x48727561,%edx        # aurH
+       jne     1f
+       cmpl    $0x736c7561,%ecx        # auls
+       jne     1f
+       movl    $1,%eax                 # check model
+       cpuid
+       shr     $4,%eax
+       andl    $0xf,%eax               # get model
+       cmpl    $6,%eax
+       jb      1f
+       cmpl    $10,%eax                 # newer vias hopefully don't require
+       ja      1f                      # this anymore
+       movl    $MSR_VIA_FCR,%ecx
+       rdmsr
+       orl     $((1<<1)|(1<<7)),%eax   # enable CMPXCHG64 and PGE
+       wrmsr
+1:
+#endif
        movl    $0x1,%eax               # Does the cpu have what it takes
        cpuid
arch/i386/boot/setup.S +4 -1
Index: linux/arch/i386/boot/verify_cpu.S
===================================================================
@@ -310,12 +310,15 @@
        call verify_cpu
        testl  %eax,%eax
        jz      cpu_ok
+        # missed before: set ds
+       pushw   %cs                             # CPU too old or CPUID function bits are wrong.
+       popw    %ds                             # die.
        lea     cpu_panic_mess,%si
        call    prtstr
 1:     jmp     1b
 
 cpu_panic_mess:
-       .asciz  "PANIC: CPU too old for this kernel."
+        .asciz  "PANIC: CPU too old for this kernel or CPUID function bits are wrong."
 
 #include "../kernel/verify_cpu.S"
#24 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

Quoted 7 lines · Christian Volkmann
Quoted 6 lines · Andi Kleen

Can someone please test if this patch works?

This preserves the 6 <= model <= 9 logic of the C code; this means if VIA ever brings out model >= 10 it hopefully sets this bit by default. Dave, do you have any information to the contrary?

Quoted 7 lines
Quoted 1 line

-Andi

Hi Andi,

your patch did not work. See the correction below. The mask should contain 1<<1 instead of 1.
Model 10 is now also included.

Ok thanks fixed.

Quoted 2 lines

I add also a patch for setup.S. It does not print the CPUID message in case the CPUID is wrong, cause %ds was not set proper.

I have this already as a separate patch with your name.

-Andi

#25 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

Quoted 7 lines · Andi Kleen
Quoted 4 lines

your patch did not work. See the correction below. The mask should contain 1<<1 instead of 1.
Model 10 is now also included.

Ok thanks fixed.

For newsetup, did we agree to just go with model >= 6 or (model >= 6 && model <= 10)? Note that newsetup only does the MSR writes if the flags are missing, so my inclination is to leave out model <= 10.

-hpa

#26 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

In reply to Christian Volkmann
Quoted 10 lines · Christian Volkmann

Hi Andi,

your patch did not work. See the correction below. The mask should contain 1<<1 instead of 1.
Model 10 is now also included.

I add also a patch for setup.S. It does not print the CPUID message in case the CPUID is wrong, cause %ds was not set proper.

Hello Christian,

do you know if and how it's possible to enable NX_bit too?

Claas

author
#27 lore raw

Via C3: other flags possible ?

Hi,

Claas asked for the NX flag for the Via C3 (?) processors in another thread.

I do not know another synonym for this?

Quoted 7 lines · Claas Langbehn

Hello Christian,

do you know if and how it's possible to enable NX_bit too?

Claas

The via C3 documentation is at:
http://www.via.com.tw/en/products/processors/c3/

I have seen in c3_ebga.zip that the processor might support 3DNow. But you have to check the registers about this.

Inside linux-2.6.22-rc1/arch/i386/kernel/cpu/centaur.c I just see a "fixed type" detection.

Does anybody have more information on this ?
Otherwise I would play around a little with my C3 Nehemiah and try to change the detection according the Via documentation.

Best regards,

Christian

PS @Andi, did you look for the page above for data sheets?
Please see the download section.

author
#28 lore raw

Re: Via C3: other flags possible ?

Quoted 16 lines · Christian Volkmann

Hi,

Claas asked for the NX flag for the Via C3 (?) processors in another thread.

I do not know another synonym for this?

Quoted 7 lines · Claas Langbehn

Hello Christian,

do you know if and how it's possible to enable NX_bit too?

Claas

C7 Esther:
Hmm, I expect the NX-Bit should be detected from linux during the boot. The NX function bit seems to be at the same place where it's located for other CPU.
Unfortunately I have no C7 hardware and I am too much a beginner in kernel programming to prepare this "dry".

May be a "senior kernel programmer" can easy check if the C7 runs through the regular NX-function detection?

Best regards,

Christian

#29 lore raw

Re: Via C3/C7: other flags possible ?

Quoted 3 lines · Christian Volkmann
Quoted 2 lines · Christian Volkmann

Claas asked for the NX flag for the Via C3 (?) processors in another thread.

If you read the other thread properly you'd see that the BIOS has an option to enable or disable it... when enabled it shows up.

Quoted 14 lines
Quoted 6 lines

I do not know another synonym for this?

Quoted 3 lines · Claas Langbehn

Hello Christian,

do you know if and how it's possible to enable NX_bit too?

C7 Esther:
Hmm, I expect the NX-Bit should be detected from linux during the boot. The NX function bit seems to be at the same place where it's located for other CPU.
Unfortunately I have no C7 hardware and I am too much a beginner in kernel programming to prepare this "dry".

Quoted 2 lines

May be a "senior kernel programmer" can easy check if the C7 runs through the regular NX-function detection?

NX is detected ok on the C7:

processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 10
model name : VIA Esther processor 1500MHz
stepping : 9
cpu MHz : 800.000
cache size : 128 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx pni est tm2 rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bogomips : 1601.18
clflush size : 64

I can't reboot that box just to test cx8 detection (which is missing).

Signature · 1 line
Simon Arlott
#30 lore raw

Re: Via C3/C7: other flags possible ?

Quoted 6 lines · Simon Arlott
Quoted 3 lines · Christian Volkmann
Quoted 2 lines · Christian Volkmann

Claas asked for the NX flag for the Via C3 (?) processors in another thread.

If you read the other thread properly you'd see that the BIOS has an option to enable or disable it... when enabled it shows up.

Right, but my bios disables this after each boot-time :( Therefore it would be great if the kernel would not care about the BIOS and enable it anyway.

This seems to be a severe bug in the BIOS, but VIA does not deliver a new BIOS since months. :(

Quoted 3 lines

I can't reboot that box just to test cx8 detection (which is missing).

It works here.

claas

author
#31 lore raw

Re: Via C3/C7: other flags possible ?

Bit 20 in edx is set if NX is available for C7:

eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00100000 ( from your posting "This kernel requires the following..." )

The official VIA Eden datasheet seems to be NDA. I have not found any official download link on the pages:
http://www.via.com.tw/en/products/processors/c7/
The /c3/ pages contain the documentation for the C3 family.

I do not think the NX feature can be switched on/off by regular registers.

May be it helps to play around with the bios ? Load "default settings" => see how the NX flag acts. Load "optimized settings" => see how the NX flags acts.

I suppose the bios developer had used one setting to test and work with the NX flag regular.

Christian

Quoted 1 line

If you read the other thread properly you'd see that the BIOS has an option to enable or disable it... when enabled it shows up.

PS: @Simon, sorry that I missed the other thread. Too much traffic and not enough time for me to read all. I suppose that's a fulltime job ;-)

Quoted 25 lines · Claas Langbehn
Quoted 7 lines · Simon Arlott
Quoted 3 lines · Christian Volkmann
Quoted 2 lines · Christian Volkmann

Claas asked for the NX flag for the Via C3 (?) processors in another thread.

If you read the other thread properly you'd see that the BIOS has an option to enable or disable it... when enabled it shows up.

Right, but my bios disables this after each boot-time :( Therefore it would be great if the kernel would not care about the BIOS and enable it anyway.

This seems to be a severe bug in the BIOS, but VIA does not deliver a new BIOS since months. :(

Quoted 3 lines

I can't reboot that box just to test cx8 detection (which is missing).

It works here.

claas

#32 lore raw

Re: Via C3: other flags possible ?

In reply to Christian Volkmann
Quoted 11 lines

C7 Esther:
Hmm, I expect the NX-Bit should be detected from linux during the boot. The NX function bit seems to be at the same place where it's located for other CPU.

Unfortunately I have no C7 hardware and I am too much a beginner in kernel programming to prepare this "dry".

May be a "senior kernel programmer" can easy check if the C7 runs through the regular NX-function detection?

If it's in CPUID (nx in /proc/cpuinfo flags) it should just work.

NX also doesn't need to be handled in the early CPUID bits detection because the kernel can handle it not being there fine. Only bits who when missing cause the kernel to panic early or crash need to be tested there.

-Andi

#33 lore raw

Re: 2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II

In reply to Christian Volkmann
Quoted 4 lines · Christian Volkmann

your patch did not work. See the correction below. The mask should contain 1<<1 instead of 1.
Model 10 is now also included.

I can confirm that it works now.

#34 lore raw
In reply to Christian
Quoted 6 lines · Christian

my small VIA C3_2 box does not boot with 2.6.22-rc1. It even does not uncompress the kernel.

The configuration as M386 M486 works. But M586 + MVIAC3_2 does not work.

Ahh, from the EPIA HOWTO:

13.2. Is the C3 Pentium compatible?

Yes. But Samuel 2, Ezra, Ezra T C3 processors have a problem with the cmpxchg8b (i.e. CMOV) opcode. Nehemiah and Antaur processors are not affected.

However, that would imply that you don't have a VIA C3-2 (Nehamiah) at all, but the older original CyrixIII/VIA C3.

Can you check? The Nehemian (C3-2) should be model 9 or greater.

So afaik, you should use MCYRIXIII, and make _that_ be the one that disables the use of the cmpxchg8b instruction.

Can you please verify?

Linus

author
#35 lore raw
Quoted 1 line · Linus Torvalds

Can you check? The Nehemian (C3-2) should be model 9 or greater.

Yes, it's a Nehemiah

lola:~ # cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 9
model name : VIA Nehemiah
stepping : 8
cpu MHz : 998.732
cache size : 64 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse rng rng_en ace ace_en
bogomips : 1999.51
clflush size : 32

#36 lore raw
Quoted 4 lines · Christian
Quoted 1 line · Linus Torvalds

Can you check? The Nehemian (C3-2) should be model 9 or greater.

Yes, it's a Nehemiah

Ok. If so, we should blacklist both MCYRIXIII and MVIAC3_2, I suspect.

Quoted 2 lines

lola:~ # cat /proc/cpuinfo
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse rng rng_en ace ace_en

However, it does seem to *claim* to support "cx8" aka cmpxchg8b. What's up with that?

Linus

#37 lore raw
Quoted 7 lines · Linus Torvalds
Quoted 3 lines · Christian
Quoted 1 line · Linus Torvalds

Can you check? The Nehemian (C3-2) should be model 9 or greater.

Yes, it's a Nehemiah

Quoted 7 lines

Ok. If so, we should blacklist both MCYRIXIII and MVIAC3_2, I suspect.

Quoted 2 lines

lola:~ # cat /proc/cpuinfo
flags : fpu vme de pse tsc msr cx8 sep mtrr pge cmov pat mmx fxsr sse rng rng_en ace ace_en

However, it does seem to *claim* to support "cx8" aka cmpxchg8b. What's up with that?

It gets turned on by the code in arch/i386/kernel/cpu. It's just that the new code that Andi added runs during setup, i.e. in real mode, so *way* earlier than that.

-hpa

#38 lore raw
Quoted 4 lines · H. Peter Anvin

It gets turned on by the code in arch/i386/kernel/cpu. It's just that the new code that Andi added runs during setup, i.e. in real mode, so *way* earlier than that.

Ahh. Do we really need it that early?

Now, it's easy enough to just turn off CONFIG_X86_CMPXCHG64 (it really should be "8B" instead of "64", but that's another issue) for those things, and nobody should really care, but still, maybe we could re-do the early bits to be more polite to those VIA CPU's?

I thought the cmpxchg8b stuff was just used to page table setup. Do those things even _support_ PAE?

What else uses it? Early setup in real mode? What am I missing? My grep powers are waning..

Linus

#39 lore raw
Quoted 7 lines · Linus Torvalds
Quoted 3 lines · H. Peter Anvin

It gets turned on by the code in arch/i386/kernel/cpu. It's just that the new code that Andi added runs during setup, i.e. in real mode, so *way* earlier than that.

Ahh. Do we really need it that early?

The reason to do it early is so that we can still get a message out if the CPU doesn't have the necessary features. This is generic code and not specific to CX8.

Since I'm rewriting the setup code in C, I have added code to enable features on VIA and Transmeta CPUs (there was already code in there to enable features on AMD; Intel isn't known to hide any features other than PAE on 400 MHz FSB Pentium-M.)

I think the early feature detection makes good sense. It's a heckuva lot nicer to get a message on your screen saying that you can't boot this kernel on this CPU than a crash, or an early_printk which may never actually get to you.

-hpa

#40 lore raw
Quoted 18 lines · H. Peter Anvin
Quoted 7 lines · Linus Torvalds
Quoted 3 lines · H. Peter Anvin

It gets turned on by the code in arch/i386/kernel/cpu. It's just that the new code that Andi added runs during setup, i.e. in real mode, so *way* earlier than that.

Ahh. Do we really need it that early?

The reason to do it early is so that we can still get a message out if the CPU doesn't have the necessary features. This is generic code and not specific to CX8.

Since I'm rewriting the setup code in C, I have added code to enable features on VIA and Transmeta CPUs (there was already code in there to enable features on AMD; Intel isn't known to hide any features other than PAE on 400 MHz FSB Pentium-M.)

Quoted 4 lines

I think the early feature detection makes good sense. It's a heckuva lot nicer to get a message on your screen saying that you can't boot this kernel on this CPU than a crash, or an early_printk which may never actually get to you.

agreed, though we'll still need something for .22 (I'm assuming your rework isn't intended for .22)

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#41 lore raw
Quoted 4 lines · Dave Jones

agreed, though we'll still need something for .22 (I'm assuming your rework isn't intended for .22)

My suggestion would be to take out the CPU verification code for .22 and merge the rewrite in .23.

-hpa

#42 lore raw
In reply to Linus Torvalds
Quoted 10 lines · Linus Torvalds
Quoted 4 lines · H. Peter Anvin

It gets turned on by the code in arch/i386/kernel/cpu. It's just that the new code that Andi added runs during setup, i.e. in real mode, so *way* earlier than that.

Ahh. Do we really need it that early?

Quoted 7 lines

Now, it's easy enough to just turn off CONFIG_X86_CMPXCHG64 (it really should be "8B" instead of "64", but that's another issue) for those things, and nobody should really care, but still, maybe we could re-do the early bits to be more polite to those VIA CPU's?

I thought the cmpxchg8b stuff was just used to page table setup. Do those things even _support_ PAE?

newer models do, yes. Even NX. In fact, primarily for NX. I've not heard of anyone running >4GB with a Nehemiah.

Dave

Signature · 1 line
http://www.codemonkey.org.uk
#43 lore raw
In reply to Christian
Quoted 7 lines · Christian

Hi,

my small VIA C3_2 box does not boot with 2.6.22-rc1. It even does not uncompress the kernel.

The configuration as M386 M486 works. But M586 + MVIAC3_2 does not work.

My VIA C7 has the same problem, boots on 486 but not on C3-2 or C7

Signature · 1 line
Hans