000000 (gap: 3bf00000:a4100000)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 243571
Kernel command line: root=/dev/sda3 ro quiet
mapped APIC to ffffd000 (fee00000)
mapped IOAPIC to ffffc000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 1499.916 MHz processor.
Console: colour VGA+ 80x25
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 969928k/981952k available (1931k kernel code, 11472k reserved, 659k data, 192k init, 64448k highmem)
virtual kernel memory layout:
fixmap : 0xfffaa000 - 0xfffff000 ( 340 kB)
pkmap : 0xff800000 - 0xffc00000 (4096 kB)
vmalloc : 0xf8800000 - 0xff7fe000 ( 111 MB)
lowmem : 0xc0000000 - 0xf8000000 ( 896 MB)
.init : 0xc038a000 - 0xc03ba000 ( 192 kB)
.data : 0xc02e2c3b - 0xc03879d4 ( 659 kB)
.text : 0xc0100000 - 0xc02e2c3b (1931 kB)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 3002.19 BogoMIPS (lpj=5001917)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 87c9bbff 00100000 00000000 00000000 00000081 00000000 00000000
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 128K (64 bytes/line)
CPU: After all inits, caps: 07c9bbff 00100000 00000000 00000000 00000081 00003fcc 00000000
Compat vDSO mapped to ffffe000.
CPU: Centaur VIA Esther processor 1500MHz stepping 09
Checking 'hlt' instruction... OK.
> Concerning the crashes I already changed the memory module, but with no
> success. I'm not sure
> wether this is a hardware or software bug.
Testing with memtest86 should help tell you if the problem is a dodgy
DIMM specifically rather than another hardware or software fault.
Alan Cox wrote:
>> Concerning the crashes I already changed the memory module, but with no
>> success. I'm not sure
>> wether this is a hardware or software bug.
>>
>
> Testing with memtest86 should help tell you if the problem is a dodgy
> DIMM specifically rather than another hardware or software fault.
>
I already did this. I had a broken aeneon DIMM at first. I got a new
working one.
But the crashes were still there. Then I got a samsung DIMM instead and
it did
not get better. Therefore I think that the memory is not causing this.
Actually the system freezes when I click somewhere with my USB mouse, even
with no load at all. Unfortunately the system does not have a serial
port for
a serial console. Netconsole was not working with the via-rhine. I wanted to
try serial console over ttyUSB, but I did not have time for it, yet.
Claas
Claas Langbehn wrote:
>
> Now my question is:
>
> Would it be possible to override the BIOS settings of cx8 and nx and
> activate it with linux anyway?
> The CPU supports it and I don't see any reason to disable it.
>
Yes, that code is already in the git.newsetup tree.
-hpa
On 17/05/07 13:27, Claas Langbehn wrote:
> I have got a VIA EPIA EX15000G Mini-ITX mainboard with a C7 VIA Esther
> processor (1500MHz).
I have Jetway's J7F4K with the same CPU.
> C7 CMPXCHG8 - enable/disable (Disable to install windows NT 4.0) and
> C7 No Execute (NX) - enable/disable
Without those options in the BIOS setup.
> > This kernel requires the following features not present on the CPU:
> > 0:8
> I attached a cpuinfo.txt. When the two flags are disabled, cx8 and nx
> are not listed there.
I don't have cx8, but I do have nx (which is unused because I have PAE
disabled...).
On 17/05/07 19:33, H. Peter Anvin wrote:
>> Claas Langbehn wrote:
>> Would it be possible to override the BIOS settings of cx8 and nx and
>> > activate it with linux anyway?
>> > The CPU supports it and I don't see any reason to disable it.
>> >
>
> Yes, that code is already in the git.newsetup tree.
Is it automatic? I have CONFIG_X86_CMPXCHG=y without cx8 showing in
cpuinfo, and it appears to work fine.
Will your changes needlessly prevent the kernel running? Would I be
right in thinking that the kernel is successfully using cmpxchg even
though it's considered disabled? I realise people compile kernels
for the wrong CPU but preventing them working when it's been chosen
correctly seems wrong.
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 10
model name : VIA Esther processor 1500MHz
stepping : 9
cpu MHz : 800.000 (cpufreq)
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
--
Simon Arlott
On 17/05/07 13:27, Claas Langbehn wrote:
> Concerning the crashes I already changed the memory module, but with no
> success. I'm not sure
> wether this is a hardware or software bug.
Get a replacement motherboard+cpu. I've had one board with rx-only
ethernet, and one which would only POST if I pressed reset (a full
size power supply made it just turn off). The third one has been
working fine since I got it.
--
Simon Arlott
Simon Arlott wrote:
>
> Is it automatic? I have CONFIG_X86_CMPXCHG=y without cx8 showing in
> cpuinfo, and it appears to work fine.
>
> Will your changes needlessly prevent the kernel running? Would I be
> right in thinking that the kernel is successfully using cmpxchg even
> though it's considered disabled? I realise people compile kernels for
> the wrong CPU but preventing them working when it's been chosen
> correctly seems wrong.
>
CX8 isn't cmpxchg; it's cmpxchg8b.
-hpa
On 17/05/07 21:15, H. Peter Anvin wrote:
> Simon Arlott wrote:
>> Is it automatic? I have CONFIG_X86_CMPXCHG=y without cx8 showing in
>> cpuinfo, and it appears to work fine.
>>
>> Will your changes needlessly prevent the kernel running? Would I be
>> right in thinking that the kernel is successfully using cmpxchg even
>> though it's considered disabled? I realise people compile kernels for
>> the wrong CPU but preventing them working when it's been chosen
>> correctly seems wrong.
>>
>
> CX8 isn't cmpxchg; it's cmpxchg8b.
Ok, but I have CONFIG_X86_CMPXCHG64=y too.
--
Simon Arlott
Simon Arlott wrote:
> On 17/05/07 21:15, H. Peter Anvin wrote:
>> Simon Arlott wrote:
>>> Is it automatic? I have CONFIG_X86_CMPXCHG=y without cx8 showing in
>>> cpuinfo, and it appears to work fine.
>>>
>>> Will your changes needlessly prevent the kernel running? Would I be
>>> right in thinking that the kernel is successfully using cmpxchg even
>>> though it's considered disabled? I realise people compile kernels for
>>> the wrong CPU but preventing them working when it's been chosen
>>> correctly seems wrong.
>>>
>>
>> CX8 isn't cmpxchg; it's cmpxchg8b.
>
> Ok, but I have CONFIG_X86_CMPXCHG64=y too.
>
OK then, then VIA just masks the CPUID bit as opposed to the
instruction. Point still holds.
-hpa
Hi,
since VIA seems to be one of the quirkier CPUs...
On May 17 2007 21:12, Simon Arlott wrote:
> On 17/05/07 13:27, Claas Langbehn wrote:
>>> Claas Langbehn wrote:
>>>> Would it be possible to override the BIOS settings of cx8 and nx and
>>>> activate it with linux anyway?
>>>> The CPU supports it and I don't see any reason to disable it.
>>
>> Yes, that code is already in the git.newsetup tree.
>
> Is it automatic? I have CONFIG_X86_CMPXCHG=y without cx8 showing in cpuinfo,
> and it appears to work fine.
>
> Will your changes needlessly prevent the kernel running? Would I be right in
> thinking that the kernel is successfully using cmpxchg even though it's
> considered disabled? I realise people compile kernels for the wrong CPU but
> preventing them working when it's been chosen correctly seems wrong.
>
> processor : 0
> vendor_id : CentaurHauls
> cpu family : 6
> model : 10
> model name : VIA Esther processor 1500MHz
> stepping : 9
> cpu MHz : 800.000 (cpufreq)
> 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
http://lkml.org/lkml/2007/5/5/134 , shows a Family-6 Model-*9* which
*does* have CX8 (with CONFIG_M586=y, CONFIG_X86_CMPXCHG=y,
CONFIG_X86_CMPXCHG64=y). Just a hint that you do not inadvertently
disable CX there ;-)
Jan
--
x86info v1.18. Dave Jones 2001-2006
Feedback to <[email protected]>.
Found 1 CPU
MP Table:
# APIC ID Version State Family Model Step Flags
# 0 0x11 BSP, usable 6 10 9 0xfbff
--------------------------------------------------------------------------
eax in: 0x00000000, eax = 00000001 ebx = 746e6543 ecx = 736c7561 edx = 48727561
eax in: 0x00000001, eax = 000006a9 ebx = 00010800 ecx = 00000081 edx = 87c9bbff
eax in: 0x80000000, eax = 80000006 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0x80000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00100000
eax in: 0x80000002, eax = 20202020 ebx = 20202020 ecx = 20202020 edx = 20202020
eax in: 0x80000003, eax = 56202020 ebx = 45204149 ecx = 65687473 edx = 72702072
eax in: 0x80000004, eax = 7365636f ebx = 20726f73 ecx = 30303531 edx = 007a484d
eax in: 0x80000005, eax = 00000000 ebx = 08800880 ecx = 40040140 edx = 40040140
eax in: 0x80000006, eax = 00000000 ebx = 00000000 ecx = 0080a140 edx = 00000000
eax in: 0xc0000000, eax = c0000002 ebx = 00000000 ecx = 00000000 edx = 00000000
eax in: 0xc0000001, eax = 00000000 ebx = 00000000 ecx = 00000000 edx = 00003fcc
eax in: 0xc0000002, eax = 00000000 ebx = 08000810 ecx = 08100f13 edx = 42000000
Family: 6 Model: 10 Stepping: 9
CPU Model : VIA C3 (Esther) [C7-M]
Processor name string: VIA Esther processor 1500MHz
Feature flags:
Onboard FPU
Virtual Mode Extensions
Debugging Extensions
Page Size Extensions
Time Stamp Counter
Model-Specific Registers
Physical Address Extensions
Machine Check Architecture
CMPXCHG8 instruction
Onboard APIC
SYSENTER/SYSEXIT
Memory Type Range Registers
Page Global Enable
CMOV instruction
Page Attribute Table
CLFLUSH instruction
ACPI via MSR
MMX support
FXSAVE and FXRESTORE instructions
SSE support
SSE2 support
Pending Break Enable
Extended feature flags:
Instruction TLB: 8-way associative. 128 entries.
Data TLB: 8-way associative. 128 entries.
L1 Data cache:
Size: 64Kb 4-way associative.
lines per tag=1 line size=64 bytes.
L1 Instruction cache:
Size: 64Kb 4-way associative.
lines per tag=1 line size=64 bytes.
L2 (on CPU) cache:
Size: 128Kb 10-way associative.
lines per tag=1 line size=64 bytes.
FCR: MSR: 0x00001107=0x9f1f1ac6 : 10011111 00011111 00011010 11000110
Power management:
MTRR registers:
MTRRcap (0xfe): 0x0000000000000508
MTRRphysBase0 (0x200): 0x0000000000000006
MTRRphysMask0 (0x201): 0x0000000fc0000800
MTRRphysBase1 (0x202): 0x000000003c000000
MTRRphysMask1 (0x203): 0x0000000ffc000800
MTRRphysBase2 (0x204): 0x00000000d8000001
MTRRphysMask2 (0x205): 0x0000000ffc000800
MTRRphysBase3 (0x206): 0x000000003bf00000
MTRRphysMask3 (0x207): 0x0000000ffff00800
MTRRphysBase4 (0x208): 0x00000000a0000001
MTRRphysMask4 (0x209): 0x00000000fc000800
MTRRphysBase5 (0x20a): 0x0000000000000000
MTRRphysMask5 (0x20b): 0x0000000000000000
MTRRphysBase6 (0x20c): 0x0000000000000000
MTRRphysMask6 (0x20d): 0x0000000000000000
MTRRphysBase7 (0x20e): 0x0000000000000000
MTRRphysMask7 (0x20f): 0x0000000000000000
MTRRfix64K_00000 (0x250): 0x0606060606060606
MTRRfix16K_80000 (0x258): 0x0606060606060606
MTRRfix16K_A0000 (0x259): 0x0000000000000000
MTRRfix4K_C8000 (0x269): 0x0505050505050505
MTRRfix4K_D0000 0x26a: 0x0000000000000000
MTRRfix4K_D8000 0x26b: 0x0000000000000000
MTRRfix4K_E0000 0x26c: 0x0000000000000000
MTRRfix4K_E8000 0x26d: 0x0000000000000000
MTRRfix4K_F0000 0x26e: 0x0404040404040404
MTRRfix4K_F8000 0x26f: 0x0404040404040400
MTRRdefType (0x2ff): 0x0000000000000c00
800MHz processor (estimate).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I purchased C7 VIA Esther and I experience similar problem with
random crashes. There is also a thread on Via Arena about "J7F4K - Hard
Lockups" where people describe the same issue:
http://forums.viaarena.com/messageview.aspx?catid=28&threadid=77032
I've tried the following kernels:
2.6.21.1 - crashes pretty quick
2.6.21.1 with disabled CPU scaling - better mileage but still crashes
2.6.22-rc1 - hangs on boot
2.6.22-rc1-mm1 - doesn't compile
2.6.22-rc2 - hangs on boot
I've ran memtest86 and no memory problems were found.
Any ideas or suggestions?
Thank You.
=================================================================
Artur Kedzierski || [email protected]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
iD8DBQFGT6SdJzjfxpUNGawRAqPzAJ921Rk67oA+H28hilXkqqUTIcF60QCghI69
LLLVhIpwQjN5nTsriGfC2M0=
=rG40
-----END PGP SIGNATURE-----
Hello Artur,
> I purchased C7 VIA Esther and I experience similar problem with
> random crashes. There is also a thread on Via Arena about "J7F4K -
> Hard Lockups" where people describe the same issue:
> http://forums.viaarena.com/messageview.aspx?catid=28&threadid=77032
> I've tried the following kernels:
> 2.6.21.1 - crashes pretty quick
> 2.6.21.1 with disabled CPU scaling - better mileage but still crashes
> 2.6.22-rc1 - hangs on boot
> 2.6.22-rc1-mm1 - doesn't compile
> 2.6.22-rc2 - hangs on boot
here, too: crashes over crashes...
> I've ran memtest86 and no memory problems were found.
> Any ideas or suggestions?
> Thank You.
The same here.
I applied the patch mentioned by Christian Volkmann in the thread "Re:
2.6.22-rc1 does not boot on VIA C3_2 cause of X86_CMPXCHG64 II" on May
19th 2007. Since then I did not have a crash any more. Touch wood!
Could anyone explain to me what CMPXCHG64 / cx8 is and what happens if
the kernel has been compiled to use it but the CPU does not have it?
Especially if the CPU like the C7 supports it, but it's disabled? Would
random crashes be a plausible effect?
Regards,
claas
Claas Langbehn wrote:
> Could anyone explain to me what CMPXCHG64 / cx8 is and what happens if
> the kernel has been compiled to use it but the CPU does not have it?
>
> Regards,
> claas
>
Hi Claas,
the bug is at another place. But it's hidden if X86_CMPXCHG64 is
switched of.
There are 3 errors.
First: Via is capable of CMPXCHG64, but switch the related CPU bit off
to work with old Win NT versions. ( So the NT error is the fourth... but who cares
about that error. ;-) )
Second: verify_cpu.S
This checks during the boot the capability of the CPU. It expected
the related bit, but... see first.
This error is switched of if X86_CMPXCHG64 is disabled.
Third: setup.S "PANIC: CPU too old for this kernel." is not printed
cause of a missing set register in setup.S.
As I have learned the NX-bit of the C7 is a BIOS issue.
The only real required patch is below. It enables the right bits for the C3/C7.
The first error is out of scope, and the fix for the "CPU too old.." is for
me just a cosmetic print out in case of boot errors.
I suppose .rc3 should contain a fix for this bug.
Best regards,
Christian
--- 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