|
From: David C. <dav...@sb...> - 2009-12-03 02:02:24
|
I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther processor-based machine running a brand new installation of Slackware 13.0. valgrind-3.1.0 ran just fine on the machine before the upgrade. This is a fresh installation; I wiped the hard disk prior to the upgrade. I have not yet rebuilt the kernel - I'm using the default SMP kernel from the Slackware 13.0 installation DVD. I could build a custom kernel for the Via CPU if that would help, but I'm guessing that the problem comes from uname. Snippets from the two config.log files follow. Under Slackware 13.0: ## --------- ## ## Platform. ## ## --------- ## hostname = sojourner uname -m = i686 uname -r = 2.6.29.6-smp uname -s = Linux uname -v = #2 SMP Mon Aug 17 00:52:54 CDT 2009 /usr/bin/uname -p = VIA Esther processor 1200MHz /bin/uname -X = unknown /bin/arch = i686 Under Slackware 11.0: ## --------- ## ## Platform. ## ## --------- ## hostname = sojourner uname -m = i686 uname -r = 2.6.17.13 uname -s = Linux uname -v = #1 Thu Feb 1 10:50:30 PST 2007 /usr/bin/uname -p = i686 /bin/uname -X = unknown /bin/arch = i686 (end of snippets) "uname --all" under Slackware 11.0 returns: Linux mariner 2.6.17.13 #5 Fri Dec 29 19:31:36 PST 2006 i686 i686 i386 GNU/Linux "uname --all" under Slackware 13.0 returns this mouthful: Linux sojourner 2.6.29.6-smp #2 SMP Mon Aug 17 00:52:54 CDT 2009 i686 VIA Esther processor 1200MHz CentaurHauls GNU/Linux sojourner is the guinea pig for the production machine (mariner), which is still running Slackware 11.0 and valgrind 3.1.0. I could try installing 3.5.0 on the production machine (which doesn't see all that much development work anyway), but I'd like to see if anyone has any ideas first. (FWIW, I built 3.5.0 under Slackware 11.0 without installing but can't get ./coregrind/valgrind to tell me anything - it can't find memcheck.) I'm a new subscriber, so initially it might be best to reply both to my E-mail address and the list. Thanks in advance. |
|
From: Julian S. <js...@ac...> - 2009-12-03 09:17:53
|
> I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther > processor-based machine running a brand new installation of Slackware > 13.0. valgrind-3.1.0 ran just fine on the machine before the upgrade. Really? The minimum requirements haven't changed. I have a very ancient VIA cpu here which it runs fine on: $ cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 7 model name : VIA Samuel 2 stepping : 3 cpu MHz : 533.349 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 de tsc msr cx8 mtrr pge mmx 3dnow up bogomips : 1066.69 clflush size : 32 power management: > installing but can't get ./coregrind/valgrind to tell me anything - it > can't find memcheck.) Sounds like your build is broken. Anyway, you shouldn't be running random bits of the build. Either run vg-in-place or do make install and run $prefix/bin/valgrind. On the above machine, a run "valgrind -d date" produces lots of debug output, including --15887:1:main Get hardware capabilities ... --15887:1:main ... arch = X86, hwcaps = x86-sse0 What happens on your machine? J |
|
From: David C. <dav...@sb...> - 2009-12-03 18:59:34
|
Julian Seward wrote: >> I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther >> processor-based machine running a brand new installation of Slackware >> 13.0. valgrind-3.1.0 ran just fine on the machine before the upgrade. >> > > Really? The minimum requirements haven't changed. I have a very > ancient VIA cpu here which it runs fine on: > > $ cat /proc/cpuinfo > processor : 0 > vendor_id : CentaurHauls > cpu family : 6 > model : 7 > model name : VIA Samuel 2 > stepping : 3 > cpu MHz : 533.349 > 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 de tsc msr cx8 mtrr pge mmx 3dnow up > bogomips : 1066.69 > clflush size : 32 > power management: > > >> installing but can't get ./coregrind/valgrind to tell me anything - it >> can't find memcheck.) >> > > Sounds like your build is broken. Anyway, you shouldn't be running > random bits of the build. Either run vg-in-place or do make install > and run $prefix/bin/valgrind. > > On the above machine, a run "valgrind -d date" produces lots of > debug output, including > > --15887:1:main Get hardware capabilities ... > --15887:1:main ... arch = X86, hwcaps = x86-sse0 > > What happens on your machine? > > J > > Last time I built valgrind, it worked just fine "out of the box", so I didn't need to learn how to debug it (and I see now that "vg-in-place" didn't exist). Thanks for the information. That's very useful. Under Slackware 11.0, using the machine that still runs valgrind 3.1.0, I get the following with valgrind 3.5.0: # ./vg-in-place -d date --2299:1:debuglog DebugLog system started by Stage 1, level 1 logging requested --2299:1:launcher no tool requested, defaulting to 'memcheck' --2299:1:launcher selected platform 'x86-linux' --2299:1:launcher launching /usr/local/src/valgrind/valgrind-3.5.0/./.in_place/memcheck-x86-linux --2299:1:debuglog DebugLog system started by Stage 2 (main), level 1 logging requested --2299:1:main Welcome to Valgrind version 3.5.0 debug logging --2299:1:main Checking current stack is plausible --2299:1:main Checking initial stack was noted --2299:1:main Starting the address space manager --2299:1:main Address space manager is running --2299:1:main Starting the dynamic memory manager --2299:1:mallocfr newSuperblock at 0x61DC0000 (pszB 4194288) owner VALGRIND/tool --2299:1:main Dynamic memory manager is running --2299:1:main Initialise m_debuginfo --2299:1:main VG_(libdir) = /usr/local/src/valgrind/valgrind-3.5.0/./.in_place --2299:1:main Getting launcher's name ... --2299:1:main ... /usr/local/src/valgrind/valgrind-3.5.0/coregrind/valgrind --2299:1:main Get hardware capabilities ... valgrind: fatal error: unsupported CPU. Supported CPUs are: * x86 (practically any; Pentium-I or above), AMD Athlon or above) * AMD Athlon64/Opteron * PowerPC (most; ppc405 and above) /proc/cpuinfo on this machine yields: # cat /proc/cpuinfo processor : 0 vendor_id : CentaurHauls cpu family : 6 model : 10 model name : VIA Esther processor 1200MHz stepping : 9 cpu MHz : 1201.143 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 up pni est tm2 rng rng_en ace ace_en bogomips : 2408.44 The /proc/cpuinfo output on the Slackware 13.0 machine differs slightly, in particular the flags: flags : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace ace_en ace2 ace2_en phe phe_en pmm pmm_en Finally, a snippet from a 3.1.0 "valgrind -d date" run on the Slackware 11.0 machine: --2301:1:main Get hardware capabilities ... --2301:1:main ... arch = X86, subarch = x86-sse2 Oddly, this does *not* appear when I installed valgrind 3.1.0 on the Slackware 13.0 machine (even after "make uninstall" in the 3.5.0 installation). Instead I get some hundreds of: --5811-- DWARF2 CFI reader: unhandled CFI instruction 0:22 But version 3.1.0 "valgrind -d date" does run on the Slackware 13.0 box. So something has clearly changed in the way that hardware capabilities are retrieved in valgrind, such that Slackware builds on Via CPUs don't return the proper information. I can apply patches or insert debug printf() statements if someone can tell me where to look. I'm swamped right now, so I don't have time to learn a whole lot about the source code. :-( |
|
From: David C. <dav...@sb...> - 2009-12-05 01:53:15
|
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
David Chapman wrote:
<blockquote cite="mid:4B1...@sb..." type="cite">
<pre wrap="">Julian Seward wrote:
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap="">I'm getting a "fatal error: unsupported CPU" on my Via C7 Esther
processor-based machine running a brand new installation of Slackware
13.0. valgrind-3.1.0 ran just fine on the machine before the upgrade.
</pre>
</blockquote>
<pre wrap="">Really? The minimum requirements haven't changed. I have a very
ancient VIA cpu here which it runs fine on:
$ cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 7
model name : VIA Samuel 2
stepping : 3
cpu MHz : 533.349
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 de tsc msr cx8 mtrr pge mmx 3dnow up
bogomips : 1066.69
clflush size : 32
power management:
</pre>
<blockquote type="cite">
<pre wrap="">installing but can't get ./coregrind/valgrind to tell me anything - it
can't find memcheck.)
</pre>
</blockquote>
<pre wrap="">Sounds like your build is broken. Anyway, you shouldn't be running
random bits of the build. Either run vg-in-place or do make install
and run $prefix/bin/valgrind.
On the above machine, a run "valgrind -d date" produces lots of
debug output, including
--15887:1:main Get hardware capabilities ...
--15887:1:main ... arch = X86, hwcaps = x86-sse0
What happens on your machine?
J
</pre>
</blockquote>
<pre wrap=""><!---->
Last time I built valgrind, it worked just fine "out of the box", so I
didn't need to learn how to debug it (and I see now that "vg-in-place"
didn't exist). Thanks for the information. That's very useful.
Under Slackware 11.0, using the machine that still runs valgrind 3.1.0,
I get the following with valgrind 3.5.0:
# ./vg-in-place -d date
--2299:1:debuglog DebugLog system started by Stage 1, level 1 logging
requested
--2299:1:launcher no tool requested, defaulting to 'memcheck'
--2299:1:launcher selected platform 'x86-linux'
--2299:1:launcher launching
/usr/local/src/valgrind/valgrind-3.5.0/./.in_place/memcheck-x86-linux
--2299:1:debuglog DebugLog system started by Stage 2 (main), level 1
logging requested
--2299:1:main Welcome to Valgrind version 3.5.0 debug logging
--2299:1:main Checking current stack is plausible
--2299:1:main Checking initial stack was noted
--2299:1:main Starting the address space manager
--2299:1:main Address space manager is running
--2299:1:main Starting the dynamic memory manager
--2299:1:mallocfr newSuperblock at 0x61DC0000 (pszB 4194288) owner
VALGRIND/tool
--2299:1:main Dynamic memory manager is running
--2299:1:main Initialise m_debuginfo
--2299:1:main VG_(libdir) =
/usr/local/src/valgrind/valgrind-3.5.0/./.in_place
--2299:1:main Getting launcher's name ...
--2299:1:main ...
/usr/local/src/valgrind/valgrind-3.5.0/coregrind/valgrind
--2299:1:main Get hardware capabilities ...
valgrind: fatal error: unsupported CPU.
Supported CPUs are:
* x86 (practically any; Pentium-I or above), AMD Athlon or above)
* AMD Athlon64/Opteron
* PowerPC (most; ppc405 and above)
/proc/cpuinfo on this machine yields:
# cat /proc/cpuinfo
processor : 0
vendor_id : CentaurHauls
cpu family : 6
model : 10
model name : VIA Esther processor 1200MHz
stepping : 9
cpu MHz : 1201.143
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 up pni est tm2 rng rng_en ace
ace_en
bogomips : 2408.44
The /proc/cpuinfo output on the Slackware 13.0 machine differs slightly,
in particular the flags:
flags : fpu vme de pse tsc msr pae mce apic sep mtrr pge cmov
pat clflush acpi mmx fxsr sse sse2 tm nx up pni est tm2 rng rng_en ace
ace_en ace2 ace2_en phe phe_en pmm pmm_en
Finally, a snippet from a 3.1.0 "valgrind -d date" run on the Slackware
11.0 machine:
--2301:1:main Get hardware capabilities ...
--2301:1:main ... arch = X86, subarch = x86-sse2
Oddly, this does *not* appear when I installed valgrind 3.1.0 on the
Slackware 13.0 machine (even after "make uninstall" in the 3.5.0
installation). Instead I get some hundreds of:
--5811-- DWARF2 CFI reader: unhandled CFI instruction 0:22
But version 3.1.0 "valgrind -d date" does run on the Slackware 13.0 box.
So something has clearly changed in the way that hardware capabilities
are retrieved in valgrind, such that Slackware builds on Via CPUs don't
return the proper information.
I can apply patches or insert debug printf() statements if someone can
tell me where to look. I'm swamped right now, so I don't have time to
learn a whole lot about the source code. :-(
</pre>
</blockquote>
<br>
Trying to avoid doing real work, I searched for "unsupported CPU" and
found it in coregrind/m_main.c. I then found VG_(machine_get_hwcaps)()
in m_machine.c. Putting a few VG_(printf)() calls into this routine, I
found that it fails this test:<br>
<br>
/* cmpxchg8b is a minimum requirement now; if we don't have it we<br>
must simply give up. But all CPUs since Pentium-I have it, so<br>
that doesn't seem like much of a restriction. */<br>
have_cx8 = (edx & (1<<8)) != 0; /* True => have
cmpxchg8b */<br>
if (!have_cx8)<br>
return False;<br>
<br>
Interestingly, /proc/cpuinfo does not show "cx8" on my machines, while
it does on yours. I didn't think my CPU was that old, since it runs at
1.2 GHz (I bought the machines in late 2006). Looks like I am out of
luck on these two machines. Given the comment in the source code here,
I doubt very much that provisions would be made to support this CPU.
:-)<br>
<br>
At least I have dual-core and quad-core Athlons that I can also do
development on...<br>
</body>
</html>
|
|
From: Julian S. <js...@ac...> - 2009-12-05 09:42:24
|
> Trying to avoid doing real work, I searched for "unsupported CPU" and > found it in coregrind/m_main.c. I then found VG_(machine_get_hwcaps)() in > m_machine.c. Putting a few VG_(printf)() calls into this routine, I found > that it fails this test: > > /* cmpxchg8b is a minimum requirement now; if we don't have it we > must simply give up. But all CPUs since Pentium-I have it, so > that doesn't seem like much of a restriction. */ > have_cx8 = (edx & (1<<8)) != 0; /* True => have cmpxchg8b */ > if (!have_cx8) > return False; > > Interestingly, /proc/cpuinfo does not show "cx8" on my machines, while it > does on yours. I didn't think my CPU was that old, since it runs at 1.2 > GHz (I bought the machines in late 2006). Looks like I am out of luck on > these two machines. Given the comment in the source code here, I doubt > very much that provisions would be made to support this CPU. :-) It may be that the CPU does support cmpxchg8b but doesn't say it does. Try compiling and running the program none/tests/x86/cmpxchg8b.c in the 3.5.0 tree, and see if it runs natively OK (without SIGILL). If yes then comment out the relevant test in VG_(machine_get_hwcaps)(). J |
|
From: David C. <dav...@sb...> - 2009-12-05 10:55:08
|
Julian Seward wrote: >> Trying to avoid doing real work, I searched for "unsupported CPU" and >> found it in coregrind/m_main.c. I then found VG_(machine_get_hwcaps)() in >> m_machine.c. Putting a few VG_(printf)() calls into this routine, I found >> that it fails this test: >> >> /* cmpxchg8b is a minimum requirement now; if we don't have it we >> must simply give up. But all CPUs since Pentium-I have it, so >> that doesn't seem like much of a restriction. */ >> have_cx8 = (edx & (1<<8)) != 0; /* True => have cmpxchg8b */ >> if (!have_cx8) >> return False; >> >> Interestingly, /proc/cpuinfo does not show "cx8" on my machines, while it >> does on yours. I didn't think my CPU was that old, since it runs at 1.2 >> GHz (I bought the machines in late 2006). Looks like I am out of luck on >> these two machines. Given the comment in the source code here, I doubt >> very much that provisions would be made to support this CPU. :-) >> > > It may be that the CPU does support cmpxchg8b but doesn't say it does. > Try compiling and running the program none/tests/x86/cmpxchg8b.c in the > 3.5.0 tree, and see if it runs natively OK (without SIGILL). If yes > then comment out the relevant test in VG_(machine_get_hwcaps)(). > > J > > I got the following output from the program, which looks correct if my understanding of CMPXCHG8B is correct (last time I wrote ASM, the 386 was still very new!): 0x22222222 0x44444444 0x33333333 0x11111111 0x246 0x3333333344444444 0x22222223 0x44444444 0x33333333 0x11111111 0x206 0x1111111122222223 0x22222222 0x44444444 0x33333333 0x11111112 0x206 0x1111111222222222 0x77777777 0x44444444 0x33333333 0x66666666 0x206 0x6666666677777777 It didn't core dump, anyway, and "./vg-in-place date" runs to completion after I comment out those lines in VG_(machine_get_hwcaps)(). So I guess that's a good thing. But it's nearly 3 A.M. here in California and I could be wrong. ;-) It is a little surprising that the C7 Esther core doesn't report that instruction, but the Linux kernel has special compilation flags for this CPU because it claims to be a 686 compatible processor yet doesn't implement all of the instructions of a real Pentium II. Maybe this is a similar issue (though harmless for most software packages because they work around it). Thanks for your help. |