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
--- arch/i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200
+++ arch/i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200
@@ -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
On Thu, May 17, 2007 at 02:09:16AM +0200, Christian wrote:
> 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
>
> --- arch/i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200
> +++ arch/i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200
> @@ -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 ?
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
--
http://www.codemonkey.org.uk
On Thu, 17 May 2007, Christian wrote:
>
> 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
Dave Jones wrote:
>
> 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
Linus Torvalds wrote:
> 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
Dave Jones wrote:
> 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:
>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.
H. Peter Anvin wrote:
> 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
H. Peter Anvin wrote:
>
> 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
On Thu, 17 May 2007, Christian wrote:
> Linus Torvalds wrote:
> > 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.
> 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
Linus Torvalds wrote:
>
> On Thu, 17 May 2007, Christian wrote:
>
>> Linus Torvalds wrote:
>>> 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.
>
>> 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
On Wed, 16 May 2007, H. Peter Anvin wrote:
>
> 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
Linus Torvalds wrote:
>
> On Wed, 16 May 2007, H. Peter Anvin wrote:
>> 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
On Wed, May 16, 2007 at 08:16:11PM -0700, Linus Torvalds wrote:
>
>
> On Wed, 16 May 2007, H. Peter Anvin wrote:
> >
> > 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?
newer models do, yes. Even NX. In fact, primarily for NX. I've not heard
of anyone running >4GB with a Nehemiah.
Dave
--
http://www.codemonkey.org.uk
On Wed, May 16, 2007 at 09:51:36PM -0700, H. Peter Anvin wrote:
> Linus Torvalds wrote:
> >
> > On Wed, 16 May 2007, H. Peter Anvin wrote:
> >> 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.
agreed, though we'll still need something for .22 (I'm assuming your rework
isn't intended for .22)
Dave
--
http://www.codemonkey.org.uk
Dave Jones wrote:
>
> 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
> > 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...
Christian wrote:
> 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
--
Hans
On Thursday 17 May 2007 02:42, Dave Jones wrote:
> On Thu, May 17, 2007 at 02:09:16AM +0200, Christian wrote:
> > 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
> >
> > --- arch/i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200
> > +++ arch/i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200
> > @@ -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 ?
>
> 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.
> 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
On Thu, May 17, 2007 at 01:51:34PM +0200, Andi Kleen wrote:
> > 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.
> > 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
--
http://www.codemonkey.org.uk
Christian wrote:
Hmm, I really think so...:
>
> 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
--- arch/i386/kernel/verify_cpu.S 2007-05-17 05:17:40.000000000 +0200
+++ arch/i386/kernel/verify_cpu.S 2007-05-17 23:14:18.266679323 +0200
@@ -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 */
--- arch/i386/boot/setup.S 2007-05-17 21:53:08.009226208 +0200
+++ arch/i386/boot/setup.S 2007-05-17 23:12:36.815989168 +0200
@@ -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"
On Thu, May 17, 2007 at 11:28:01PM +0200, Christian Volkmann wrote:
> - 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
--
http://www.codemonkey.org.uk
Dave Jones wrote:
> 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.
>
> 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
Andi Kleen wrote:
>>
>> 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
On Thursday 17 May 2007 02:42, Dave Jones wrote:
> On Thu, May 17, 2007 at 02:09:16AM +0200, Christian wrote:
> > 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
> >
> > --- arch/i386/Kconfig.cpu.before 2007-05-17 01:38:26.000000000 +0200
> > +++ arch/i386/Kconfig.cpu 2007-05-17 00:54:52.000000000 +0200
> > @@ -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 ?
>
> 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?
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
Index: linux/arch/i386/kernel/verify_cpu.S
===================================================================
--- linux.orig/arch/i386/kernel/verify_cpu.S
+++ 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
On Sat, May 19, 2007 at 07:53:16AM +0200, Andi Kleen wrote:
> 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
--
http://www.codemonkey.org.uk
Hello Andi!
> 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)
> 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
Christian Volkmann wrote:
> Christian wrote:
> Hmm, I really think so...:
>> 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.
I applied the patch on rc2, changed 'if CONFIG_MVIAC3_2' in if
CONFIG_MVIAC7' and build a working VIA C7 kernel.
--
Hans
Andi Kleen wrote:
> 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
Index: linux/arch/i386/kernel/verify_cpu.S
===================================================================
--- linux.orig/arch/i386/kernel/verify_cpu.S
+++ 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
Index: linux/arch/i386/boot/verify_cpu.S
===================================================================
--- linux.orig/arch/i386/boot/setup.S
+++ linux/arch/i386/boot/setup.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"
On Saturday 19 May 2007 08:02, Dave Jones wrote:
> On Sat, May 19, 2007 at 07:53:16AM +0200, Andi Kleen wrote:
> > 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)
On Saturday 19 May 2007 13:42, Christian Volkmann wrote:
> Andi Kleen wrote:
> > 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.
Ok thanks fixed.
> 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
On Sat, May 19, 2007 at 01:47:44PM +0200, Andi Kleen wrote:
> On Saturday 19 May 2007 08:02, Dave Jones wrote:
> > On Sat, May 19, 2007 at 07:53:16AM +0200, Andi Kleen wrote:
> > > 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
--
http://www.codemonkey.org.uk
Christian Volkmann wrote:
> 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
Christian Volkmann wrote:
> 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.
Claas Langbehn wrote:
> Hello Andi!
>> 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)
>> 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
Hi,
Claas asked for the NX flag for the Via C3 (?) processors
in another thread.
I do not know another synonym for this?
Claas Langbehn wrote:
> 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.
Christian Volkmann wrote:
> Hi,
>
> Claas asked for the NX flag for the Via C3 (?) processors
> in another thread.
>
> I do not know another synonym for this?
>
> Claas Langbehn wrote:
>> 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
On 19/05/07 23:36, Christian Volkmann wrote:
> Christian Volkmann wrote:
>> 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.
>> I do not know another synonym for this?
>>
>> Claas Langbehn wrote:
>>> 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".
>
> 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).
--
Simon Arlott
Simon Arlott schrieb:
> On 19/05/07 23:36, Christian Volkmann wrote:
>> Christian Volkmann wrote:
>>> 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. :(
>
> I can't reboot that box just to test cx8 detection (which is missing).
>
It works here.
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?
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
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
> 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 ;-)
Claas Langbehn wrote:
> Simon Arlott schrieb:
>> On 19/05/07 23:36, Christian Volkmann wrote:
>>> Christian Volkmann wrote:
>>>> 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. :(
>
>>
>> I can't reboot that box just to test cx8 detection (which is missing).
>>
> It works here.
>
>
>
> claas
>
Andi Kleen wrote:
>>
>> 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
On Thu, May 17, 2007 at 05:47:54PM -0400, Dave Jones wrote:
> On Thu, May 17, 2007 at 11:28:01PM +0200, Christian Volkmann wrote:
>
> > - 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?
> 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(-)
--- linux-2.6.22-rc2-mm1/include/asm-i386/processor.h.old 2007-05-31 01:47:13.000000000 +0200
+++ linux-2.6.22-rc2-mm1/include/asm-i386/processor.h 2007-05-31 01:47:18.000000000 +0200
@@ -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
--- linux-2.6.22-rc2-mm1/include/asm-x86_64/processor.h.old 2007-05-31 01:47:28.000000000 +0200
+++ linux-2.6.22-rc2-mm1/include/asm-x86_64/processor.h 2007-05-31 01:47:32.000000000 +0200
@@ -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
--- linux-2.6.22-rc2-mm1/arch/i386/kernel/cpu/Makefile.old 2007-05-31 01:46:00.000000000 +0200
+++ linux-2.6.22-rc2-mm1/arch/i386/kernel/cpu/Makefile 2007-05-31 01:46:11.000000000 +0200
@@ -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
--- linux-2.6.22-rc2-mm1/arch/i386/kernel/cpu/common.c.old 2007-05-31 01:51:43.000000000 +0200
+++ linux-2.6.22-rc2-mm1/arch/i386/kernel/cpu/common.c 2007-05-31 01:51:48.000000000 +0200
@@ -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();
--- linux-2.6.22-rc2-mm1/arch/i386/kernel/cpu/rise.c 2007-05-26 21:20:11.000000000 +0200
+++ /dev/null 2006-09-19 00:45:31.000000000 +0200
@@ -1,52 +0,0 @@
-#include <linux/kernel.h>
-#include <linux/init.h>
-#include <linux/bitops.h>
-#include <asm/processor.h>
-
-#include "cpu.h"
-
-static void __cpuinit init_rise(struct cpuinfo_x86 *c)
-{
- printk("CPU: Rise iDragon");
- if (c->x86_model > 2)
- printk(" II");
- printk("\n");
-
- /* Unhide possibly hidden capability flags
- The mp6 iDragon family don't have MSRs.
- We switch on extra features with this cpuid weirdness: */
- __asm__ (
- "movl $0x6363452a, %%eax\n\t"
- "movl $0x3231206c, %%ecx\n\t"
- "movl $0x2a32313a, %%edx\n\t"
- "cpuid\n\t"
- "movl $0x63634523, %%eax\n\t"
- "movl $0x32315f6c, %%ecx\n\t"
- "movl $0x2333313a, %%edx\n\t"
- "cpuid\n\t" : : : "eax", "ebx", "ecx", "edx"
- );
- set_bit(X86_FEATURE_CX8, c->x86_capability);
-}
-
-static struct cpu_dev rise_cpu_dev __cpuinitdata = {
- .c_vendor = "Rise",
- .c_ident = { "RiseRiseRise" },
- .c_models = {
- { .vendor = X86_VENDOR_RISE, .family = 5, .model_names =
- {
- [0] = "iDragon",
- [2] = "iDragon",
- [8] = "iDragon II",
- [9] = "iDragon II"
- }
- },
- },
- .c_init = init_rise,
-};
-
-int __init rise_init_cpu(void)
-{
- cpu_devs[X86_VENDOR_RISE] = &rise_cpu_dev;
- return 0;
-}
-
On Thu, May 31, 2007 at 07:22:38AM +0200, Adrian Bunk wrote:
> On Thu, May 17, 2007 at 05:47:54PM -0400, Dave Jones wrote:
> > On Thu, May 17, 2007 at 11:28:01PM +0200, Christian Volkmann wrote:
> >
> > > - 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?
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
--
http://www.codemonkey.org.uk
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.
Dave Jones wrote:
> On Thu, May 31, 2007 at 07:22:38AM +0200, Adrian Bunk wrote:
> > On Thu, May 17, 2007 at 05:47:54PM -0400, Dave Jones wrote:
> > > On Thu, May 17, 2007 at 11:28:01PM +0200, Christian Volkmann wrote:
> > >
> > > > - 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?
>
> 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
>
On Thu, May 31, 2007 at 07:37:52PM +0200, Christian Volkmann wrote:
> 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
--
http://www.codemonkey.org.uk