I bought a VIA PC2500 board a few days ago - this
new series of their mobos,
This beast looks nice - after replacing their cooling
system (that had a small fan on it) with larger but
fanless, -- it becomes a almost real PC (1500MHz CPU),
equipped with quite nice crypto and multimedia abilities,
but with very low power consumption and very quiet.
But the thing is - it doesn't quite work.
It works generally - it boots, I can run my usual apps
etc. But on a random (yet frequent) basis it segfaults
here and there. For example:
$ man man
Reformatting man(1), please wait...
$ man man
Segmentation fault
$ man man
Segmentation fault
$ man man
Segmentation fault
$ man man
Segmentation fault
$ man man
Reformatting man(1), please wait...
$ _
(this is 100% idle machine, just booted).
(There are other - simple and comples - applications which
inhibits this problem. For example, it 99% reliable segfaults
on compiling aic79xx_core.c file in kernel, while all the rest
(in my configuration anyway) compiles, at least after second
attempt).
It's definitely NOT memory issue - I tried several different
memory modules (and different combinations) - the same results;
I ran memtest86 for several days - no single error.
I've seen a thread here on LKML about C7 and C3 CPUs back in
March this year - tried with patch from Andi titled
"i386: Enable CX8/PGE CPUID bits early on VIA C3" - it didn't
change anything (this board does not lock up - not when booting
nor when doing something, -- just random applications are
crashing randomly, and the crash is always SIGSEGV; there's
_nothing_ in dmesg about that, too).
>From all the above it seems like something's broke on the
motherboard (I've no idea what it can be however - because
memory testing - which also tests for CPU cache for exampe -
shows no errors; testing disk controller/disk using md5 does
not show errors either, except of occasional SIGSEGVs)..
However, being very curious about this, I tried installing
'doze on this machine - winXP. And that one went just fine
without any error so far -- i tried stress-testing it as far
as I can imagine, running various applications and workloads, --
no errors.
So I'm kinda.. stuck about what to do next.
Any.. idea, anyone? :)
Thanks!
/mjt
Michael Tokarev wrote:
> I bought a VIA PC2500 board a few days ago - this
> new series of their mobos,
>
> This beast looks nice - after replacing their cooling
> system (that had a small fan on it) with larger but
> fanless, -- it becomes a almost real PC (1500MHz CPU),
> equipped with quite nice crypto and multimedia abilities,
> but with very low power consumption and very quiet.
>
> But the thing is - it doesn't quite work.
>
> It works generally - it boots, I can run my usual apps
> etc. But on a random (yet frequent) basis it segfaults
> here and there. For example:
>
> $ man man
> Reformatting man(1), please wait...
> $ man man
> Segmentation fault
> $ man man
> Segmentation fault
> $ man man
> Segmentation fault
> $ man man
> Segmentation fault
> $ man man
> Reformatting man(1), please wait...
> $ _
>
> (this is 100% idle machine, just booted).
>
> (There are other - simple and comples - applications which
> inhibits this problem. For example, it 99% reliable segfaults
> on compiling aic79xx_core.c file in kernel, while all the rest
> (in my configuration anyway) compiles, at least after second
> attempt).
>
> It's definitely NOT memory issue - I tried several different
> memory modules (and different combinations) - the same results;
> I ran memtest86 for several days - no single error.
>
> I've seen a thread here on LKML about C7 and C3 CPUs back in
> March this year - tried with patch from Andi titled
> "i386: Enable CX8/PGE CPUID bits early on VIA C3" - it didn't
> change anything (this board does not lock up - not when booting
> nor when doing something, -- just random applications are
> crashing randomly, and the crash is always SIGSEGV; there's
> _nothing_ in dmesg about that, too).
>
> From all the above it seems like something's broke on the
> motherboard (I've no idea what it can be however - because
> memory testing - which also tests for CPU cache for exampe -
> shows no errors; testing disk controller/disk using md5 does
> not show errors either, except of occasional SIGSEGVs)..
>
> However, being very curious about this, I tried installing
> 'doze on this machine - winXP. And that one went just fine
> without any error so far -- i tried stress-testing it as far
> as I can imagine, running various applications and workloads, --
> no errors.
>
> So I'm kinda.. stuck about what to do next.
>
> Any.. idea, anyone? :)
>
> Thanks!
>
> /mjt
To me it looks like a wrong choice of gcc switches to user-mode programs. What
distribution are you using? try compiling failing programs from source with
conservative command line switches to gcc. See if things change.
Boaz
On Tue, 12 Jun 2007 13:21:43 +0400
Michael Tokarev <[email protected]> wrote:
> I bought a VIA PC2500 board a few days ago - this
> new series of their mobos,
>
> This beast looks nice - after replacing their cooling
> system (that had a small fan on it) with larger but
> fanless, -- it becomes a almost real PC (1500MHz CPU),
> equipped with quite nice crypto and multimedia abilities,
> but with very low power consumption and very quiet.
>
> But the thing is - it doesn't quite work.
That is usually memory or motherboard timings. memtest86+ will miss a lot
of problems on these boards for some reason I don't really fathom
although its still a worthwhile test you did
I'd be interested to knowwhat the following do
Bad RAM check:
Boot with mem= to limit to the bottom 256MB of RAM
(Windows tends to use different areas of RAM to Linux the most so
your report fits that)
Stress testing:
Go into X in a high resoution, starting running a continuous
copy to or from disk and see if its suddenely much less stable
Disabling power management
On 6/12/07, Michael Tokarev <[email protected]> wrote:
> I bought a VIA PC2500 board a few days ago - this
> new series of their mobos,
>
> This beast looks nice - after replacing their cooling
> system (that had a small fan on it) with larger but
> fanless, -- it becomes a almost real PC (1500MHz CPU),
> equipped with quite nice crypto and multimedia abilities,
> but with very low power consumption and very quiet.
>
> But the thing is - it doesn't quite work.
Try disabling CPU frequency scaling, VIA CPU's often have problems
with changing their frequency.
Furthermore, did you do any testing of the board before you took the
fan off? Was it stable then?
Wander.
Alan Cox wrote:
> On Tue, 12 Jun 2007 13:21:43 +0400
> Michael Tokarev <[email protected]> wrote:
>
>> I bought a VIA PC2500 board a few days ago - this
>> new series of their mobos,
>>
>> This beast looks nice - after replacing their cooling
>> system (that had a small fan on it) with larger but
>> fanless, -- it becomes a almost real PC (1500MHz CPU),
>> equipped with quite nice crypto and multimedia abilities,
>> but with very low power consumption and very quiet.
>>
>> But the thing is - it doesn't quite work.
>
> That is usually memory or motherboard timings. memtest86+ will miss a lot
> of problems on these boards for some reason I don't really fathom
> although its still a worthwhile test you did
Hmm. Memory or motherboard timings. There are several options in BIOS
about this. I'll try to experiment. The only prob - it seems - is that
BIOS only allows INcreasing speeds (frequencies etc), not DEcreasing them.
More, the BIOS does not have CPU frequency control at all - only PCI bus
frequency and memory frequency. Memory DIMMs are 667 MHz (PC5300), while
the mobo accepts 533MHz (PC4200?), and are running at 533MHz (according to
BIOS).
But in any way, I'll try to experiment here.
> I'd be interested to knowwhat the following do
>
> Bad RAM check:
> Boot with mem= to limit to the bottom 256MB of RAM
> (Windows tends to use different areas of RAM to Linux the most so
> your report fits that)
>
> Stress testing:
> Go into X in a high resoution, starting running a continuous
> copy to or from disk and see if its suddenely much less stable
Okay, running with mem=128m now, copying linux kernel source and
removing it, 10 processes in parallel.
So far, I see the same random SIGSEGVs - not from cp and rm, but from
"usual" suspect - man(1) command segfaults pretty frequently as before ;)
> Disabling power management
Wonder how to disable it... :) I already turned off all power management
stuff in BIOS I was able to find.
Thanks!
/mjt
Linux-kernel wrote:
[]
> To me it looks like a wrong choice of gcc switches to user-mode programs. What
> distribution are you using? try compiling failing programs from source with
> conservative command line switches to gcc. See if things change.
Wrong choice of gcc switches tends to produce binaries wich are either works
or does not. Here, it sometimes works and sometimes does not. Also, if
it was wrong options, programs usually tends to fail with something like
SIGILL (Illegal Instruction), not SIGSEGV.
The system is running Debian Etch (4.0), with everything compiled for plain
i386 (default gcc -O2 without any fancy optimizations).
I tried installing libc6-i686 package (cmov-enabled glibc) - unlike with
VIA C3 (which indeed does not have this instruction), it worked on C7, but
installing libc6-i686 didn't change SIGSEGVs at all.
I just tried to recompile man(1) command (the one that gave SIGSEGVs most
often). The resulting binary fails MUCH less often, but still sometimes
fails.
Note that this is real i686 CPU. At least according to kernel - when one
chooses C7 CPU in kernel config, kernel uses -march=i686 switch - the only
CPU-specific switch it is. The difference between i686 and C7 in kernel
config is cache shift value.
Thanks.
/mjt
Wander Winkelhorst wrote:
> On 6/12/07, Michael Tokarev <[email protected]> wrote:
>> I bought a VIA PC2500 board a few days ago - this
>> new series of their mobos,
>>
>> This beast looks nice - after replacing their cooling
>> system (that had a small fan on it) with larger but
>> fanless, -- it becomes a almost real PC (1500MHz CPU),
>> equipped with quite nice crypto and multimedia abilities,
>> but with very low power consumption and very quiet.
>>
>> But the thing is - it doesn't quite work.
>
> Try disabling CPU frequency scaling, VIA CPU's often have problems
> with changing their frequency.
Hmm. I wonder how to *enable* it in the first place.. ;)
e_powersaver.ko and acpi_cpufreq gives "No such device"
> Furthermore, did you do any testing of the board before you took the
> fan off? Was it stable then?
The thing is that I didn't even try to test it WITHOUT the fan.
It makes no difference in themperature (lm_sensors shows 40
degrees celsius under continious run of `openssl speed' with
fan, and 39 degrees without fan but with larger headstick).
But all the testing are done with the original headstick+fan
as provided by VIA.
/mjt
Michael Tokarev wrote on LKML:
> Wander Winkelhorst wrote:
>
>> On 6/12/07, Michael Tokarev <[email protected]> wrote:
>>
>>> I bought a VIA PC2500 board a few days ago - this
>>> new series of their mobos,
>>>
>>> This beast looks nice - after replacing their cooling
>>> system (that had a small fan on it) with larger but
>>> fanless, -- it becomes a almost real PC (1500MHz CPU),
>>> equipped with quite nice crypto and multimedia abilities,
>>> but with very low power consumption and very quiet.
>>>
>>> But the thing is - it doesn't quite work.
>>>
>> Try disabling CPU frequency scaling, VIA CPU's often have problems
>> with changing their frequency.
>>
>
> Hmm. I wonder how to *enable* it in the first place.. ;)
> e_powersaver.ko and acpi_cpufreq gives "No such device"
>
>
cat /proc/cpuinfo and have a look at the flags. Does it support "eps"?
If not then e_powersaver is not possible. If cpufreq with acpi P-states
does not work either then your mainboard/CPU does not support
power saving.
You might get in contact with Rafal Bilinski who wrote e_powersaver.
claas
Claas Langbehn wrote:
>> Hmm. I wonder how to *enable* it in the first place.. ;)
>> e_powersaver.ko and acpi_cpufreq gives "No such device"
>>
> cat /proc/cpuinfo and have a look at the flags. Does it support "eps"?
I've looked at e_powersaver sources and noticied the second test in
init function (after checking for CPU model) - it fails on this very
test:
if (!cpu_has(c, X86_FEATURE_EST))
return -ENODEV;
(this is one of first things I did when turning the mobo on - tried
various options including CPU frequency scaling, observed it doesn't
work and tried to understand why, but didn't went much further here
because of the SIGSEGV problem which is much more serious... ;)
/proc/cpuinfo does not have "eps" (nor "est") flags:
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 10
model name : VIA Esther processor 1500MHz
stepping : 9
cpu MHz : 1496.321
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 cx8 apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en
bogomips : 3002.25
clflush size : 64
(most close is "sep" ;)
> If not then e_powersaver is not possible. If cpufreq with acpi P-states
> does not work either then your mainboard/CPU does not support
> power saving.
> You might get in contact with Rafal Bilinski who wrote e_powersaver.
Yeah, good idea.. thanks! ;)
/mjt
On Jun 12 2007 17:01, Michael Tokarev wrote:
>
>Claas Langbehn wrote:
>>> Hmm. I wonder how to *enable* it in the first place.. ;)
>>> e_powersaver.ko and acpi_cpufreq gives "No such device"
>>>
>> cat /proc/cpuinfo and have a look at the flags. Does it support "eps"?
>
>I've looked at e_powersaver sources and noticied the second test in
>init function (after checking for CPU model) - it fails on this very
>test:
Actually you may want to try longhaul.ko
Jan
--
On Tue, Jun 12, 2007 at 11:59:36PM +0200, Jan Engelhardt wrote:
>
> On Jun 12 2007 17:01, Michael Tokarev wrote:
> >
> >Claas Langbehn wrote:
> >>> Hmm. I wonder how to *enable* it in the first place.. ;)
> >>> e_powersaver.ko and acpi_cpufreq gives "No such device"
> >>>
> >> cat /proc/cpuinfo and have a look at the flags. Does it support "eps"?
> >
> >I've looked at e_powersaver sources and noticied the second test in
> >init function (after checking for CPU model) - it fails on this very
> >test:
>
> Actually you may want to try longhaul.ko
No, he doesn't. Esther doesn't have longhaul.
The lack of EST in the feature flags is probably something
being disabled in the BIOS (or a crap BIOS).
Dave
--
http://www.codemonkey.org.uk