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 th
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 requir
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL
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.
Hell
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
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 ha
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 informati
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 p
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 re
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 prese
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 feat
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
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 Wi
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 actual
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. T
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 CMPXC
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 s
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
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
-
To unsubscribe from this l
> > 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 r
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
-
To unsubscribe from this list: send the line "unsubscri
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
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
>
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
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
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
>> f
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 ts
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 versio
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
> fo
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 :
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
>
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?
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
>
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.0 +0200
+++ ar
34 matches
Mail list logo
