A computer components & hardware forum. HardwareBanter

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » HardwareBanter forum » Processors » Overclocking
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

New release of sys_basher



 
 
Thread Tools Display Modes
  #1  
Old December 28th 08, 05:24 AM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
General Schvantzkoph
external usenet poster
 
Posts: 246
Default New release of sys_basher

I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.
  #2  
Old December 28th 08, 07:22 AM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
Aragorn
external usenet poster
 
Posts: 17
Default New release of sys_basher

On Sunday 28 December 2008 05:24, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardwa/

I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.


Does it also do diagnostics of other possibly failing hardware components
than memory? I'm just asking because I've got a machine sitting here idly
for quite some time now due to strange lockups and BIOS ECC error log
entries.

I had the machine checked by a tech but he couldn't find anything, and he
had run some benchmarking thing on it using an SQL database and had it
running like that for several days without - again, according to him - any
errors.

It was a rather expensive machine at the time, and I've only recently put in
a brandnew Adaptec 2130 SLP PCI-X U320 SCSI RAID controller and two even so
brandnew Hitachi 73 GB U320 SCSI disks. (The errors and crashes already
predate that "transplant", though.)

The motherboard is an Intel server board - I think a 7500CW - with two Intel
Xeon 2.2 GHz (400 Hz FSB) 32-bit processors with hyperthreading. The
memory is 4 GB (4x 1 GB) Transcend ECC registered DDR-266, running at 200
MHz. /memtest86/ shows no errors whatsoever, and the power supply is 350
Watts but doesn't pull more than 220 Watts during boot-up and appears to
check out fine. The BIOS is a Phoenix, but don't ask me what release. ;-)

One of the strange things is that often during the Linux kernel boot
process, only three of the four hyperthreaded virtual CPUs are found -
occasionally only two, even. This "failure" is noticeable in advance
before the kernel actually starts displaying its boot messages by the delay
in switching from standard VGA resolution to the higher resolution
framebuffer, and there is a higher chance of this oddness occurring when
you press the /Enter/ key in the GRUB or LILO boot menu before the timeout
has expired. It then also shows strange messages like "booting processor
3/7", suggesting that the kernel sees eight processors, while it's a
two-socket motherboard with two hyperthreaded Xeons.

The machine has had this flaw from the beginning, but at the time it was
still rather exceptional, while by now it's rather exceptional to still
have it recognize all four virtual CPUs. It also used to fully lock up
without anything serious running, but the rate at which this would happen
was unpredictable. One time it would run for a whole week, the other time
it would lock up after only a few hours, or even earlier.

The machine has had Mandrake 10.0 PowerPack on it with a custom-built
vanilla 2.6.x kernel - various releases, starting with 2.6.5 and ending
with 2.6.17 or something - for many years but since it has gotten the newer
SCSI disks I've installed it with CentOS 5.1, as it was intended to be used
for our still very preliminary webhosting, and our hosting software
(DirectAdmin) only works with CentOS (or is only supported by the
developers to work with CentOS, anyway).

I'm mentioning all this because quite obviously everyone appears to be
stumped with regard to what could be wrong with this machine, and you come
across like somewhat of an Intel /connoisseur./ So maybe you've got any
clues? ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)
  #3  
Old December 28th 08, 12:03 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
ShadowTek[_4_]
external usenet poster
 
Posts: 59
Default New release of sys_basher

On Sun, 28 Dec 2008 07:22:40 +0100, Aragorn wrote:

The motherboard is an Intel server board - I think a 7500CW - with two
Intel Xeon 2.2 GHz (400 Hz FSB) 32-bit processors with hyperthreading.
The memory is 4 GB (4x 1 GB) Transcend ECC registered DDR-266, running
at 200 MHz. /memtest86/ shows no errors whatsoever, and the power
supply is 350 Watts but doesn't pull more than 220 Watts during boot-up
and appears to check out fine.


Overall voltage potential of the power supply is effectively irrelevant.
Voltage draw per rail per device must be calculated.

  #4  
Old December 28th 08, 02:04 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
Paul
external usenet poster
 
Posts: 13,364
Default New release of sys_basher

Aragorn wrote:
On Sunday 28 December 2008 05:24, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardwa/

I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.


Does it also do diagnostics of other possibly failing hardware components
than memory? I'm just asking because I've got a machine sitting here idly
for quite some time now due to strange lockups and BIOS ECC error log
entries.

I had the machine checked by a tech but he couldn't find anything, and he
had run some benchmarking thing on it using an SQL database and had it
running like that for several days without - again, according to him - any
errors.

It was a rather expensive machine at the time, and I've only recently put in
a brandnew Adaptec 2130 SLP PCI-X U320 SCSI RAID controller and two even so
brandnew Hitachi 73 GB U320 SCSI disks. (The errors and crashes already
predate that "transplant", though.)

The motherboard is an Intel server board - I think a 7500CW - with two Intel
Xeon 2.2 GHz (400 Hz FSB) 32-bit processors with hyperthreading. The
memory is 4 GB (4x 1 GB) Transcend ECC registered DDR-266, running at 200
MHz. /memtest86/ shows no errors whatsoever, and the power supply is 350
Watts but doesn't pull more than 220 Watts during boot-up and appears to
check out fine. The BIOS is a Phoenix, but don't ask me what release. ;-)

One of the strange things is that often during the Linux kernel boot
process, only three of the four hyperthreaded virtual CPUs are found -
occasionally only two, even. This "failure" is noticeable in advance
before the kernel actually starts displaying its boot messages by the delay
in switching from standard VGA resolution to the higher resolution
framebuffer, and there is a higher chance of this oddness occurring when
you press the /Enter/ key in the GRUB or LILO boot menu before the timeout
has expired. It then also shows strange messages like "booting processor
3/7", suggesting that the kernel sees eight processors, while it's a
two-socket motherboard with two hyperthreaded Xeons.

The machine has had this flaw from the beginning, but at the time it was
still rather exceptional, while by now it's rather exceptional to still
have it recognize all four virtual CPUs. It also used to fully lock up
without anything serious running, but the rate at which this would happen
was unpredictable. One time it would run for a whole week, the other time
it would lock up after only a few hours, or even earlier.

The machine has had Mandrake 10.0 PowerPack on it with a custom-built
vanilla 2.6.x kernel - various releases, starting with 2.6.5 and ending
with 2.6.17 or something - for many years but since it has gotten the newer
SCSI disks I've installed it with CentOS 5.1, as it was intended to be used
for our still very preliminary webhosting, and our hosting software
(DirectAdmin) only works with CentOS (or is only supported by the
developers to work with CentOS, anyway).

I'm mentioning all this because quite obviously everyone appears to be
stumped with regard to what could be wrong with this machine, and you come
across like somewhat of an Intel /connoisseur./ So maybe you've got any
clues? ;-)


There is a manual for the SE7500CW2 here.

http://download.intel.com/support/mo...500cw2/tps.pdf

http://support.intel.com/support/mot...ver/se7500cw2/

(Picture)
http://www.xeonchassis.com/images/IntelCW-OH.jpg

The design uses a shared VRM for both processors. The Intel document says
the processors should be matched. And that is because they're both going
to be getting their Vcore from the same source. The VRM supports a total
load of 130W or the usage of two 65W processors. The motherboard checks
the VID from both processors, to make sure they're matched, so that
should provide some protection against a completely mismatched
set of processors from a voltage perspective.

You could concentrate on running a memory test. Or use multiple copies
of the Linux version of Prime95, as a means of doing an integrity test
on memory and processor. That should run the CPU at 100%, especially
if running four or more copies. (Prime95 is good, because it won't
be held back by disks or storage subsystems. A single math error and
it catches it.)

http://www.mersenne.org/freesoft/#newusers

In terms of strip-down procedures, you could try running with one
processor at a time, and see whether the symptoms are the same in
each case. (No terminator is needed in the empty second socket.)

With four sticks of RAM, you can also run just two sticks at a time,
and test them that way. (The board is dual channel, and the manual
claims a two stick minimum. If may run with just one stick,
but I don't immediately see that suggested in the manual.)

A 350W power supply, could be a dual redundant 350W with load
sharing, or it could be a $20 single supply from Quickie-Mart.
You'd need to have more of a look at it, to judge whether it
is adequate (the label has a bunch of limits printed on it).
In a quick web search, I see SE7500CW2 based machines shipping
with 450W supplies, to give you an idea what others use. But if
you have 20 disk drives in the box, obviously that requires
more beef.

If you want help with hardware, it helps to start your own thread
about your hardware problems, and not hijack the General's thread :-)

Paul
  #5  
Old December 28th 08, 02:10 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
General Schvantzkoph
external usenet poster
 
Posts: 246
Default New release of sys_basher

On Sun, 28 Dec 2008 07:22:40 +0100, Aragorn wrote:

On Sunday 28 December 2008 05:24, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardwa/

I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.


Does it also do diagnostics of other possibly failing hardware
components than memory? I'm just asking because I've got a machine
sitting here idly for quite some time now due to strange lockups and
BIOS ECC error log entries.


I use the term exerciser rather than diagnostic because it can't identify
the individual component that's failing, all it can do is tell you that
there is a problem with a CPU, RAM or disk. Sys_basher is an ordinary
user space program, and as far as I can tell there is no way to get Linux
to do a logical address to physical address translation or to determine
which physical core a thread is running on for a user space program. If
there is a way I'd appreciate someone telling me how to do it and I'd add
it to sys_basher so that it could give more precise error messages.

Sys_basher is designed to maximize the stress on the system. In addition
to memory tests, which operate at the maximum read and write bandwidth of
each level of the memory hierarchy, there are integer and floating point
arithmetic tests which are unrolled loops that can use up to eight
functional units (4 adders and 4 multipliers) per cycle which should push
the core temperatures to their maximum. All of the arithmetic tests are
done register to register, memory to register and memory to memory. I
step through array sizes from 1K, which fits entirely in the primary
cache, to 64M which operates almost entirely in DRAM. The RAM and disk
tests also step through a range of array sizes, from 1K to 64M for disk I/
O and from 1K to the full virtual memory size for the memory tests (there
is a switch to set the amount of RAM tested, I find that the physical
size - 300M is a good choice, more than that will cause the system to
swap which will kill the performance).

Sys_basher also reports memory bandwidth for each array size, disk
bandwidth for each of the supported I/O modes and file sizes, OPS and
MFLOPS for each array size.

Give it a try and see if it helps you identify your problem. I'd
appreciate any feedback and suggestions that you have.
  #6  
Old December 28th 08, 02:54 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
General Schvantzkoph
external usenet poster
 
Posts: 246
Default New release of sys_basher

On Sun, 28 Dec 2008 08:04:30 -0500, Paul wrote:

Aragorn wrote:
On Sunday 28 December 2008 05:24, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardwa/

I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.


Does it also do diagnostics of other possibly failing hardware
components than memory? I'm just asking because I've got a machine
sitting here idly for quite some time now due to strange lockups and
BIOS ECC error log entries.

I had the machine checked by a tech but he couldn't find anything, and
he had run some benchmarking thing on it using an SQL database and had
it running like that for several days without - again, according to him
- any errors.

It was a rather expensive machine at the time, and I've only recently
put in a brandnew Adaptec 2130 SLP PCI-X U320 SCSI RAID controller and
two even so brandnew Hitachi 73 GB U320 SCSI disks. (The errors and
crashes already predate that "transplant", though.)

The motherboard is an Intel server board - I think a 7500CW - with two
Intel Xeon 2.2 GHz (400 Hz FSB) 32-bit processors with hyperthreading.
The memory is 4 GB (4x 1 GB) Transcend ECC registered DDR-266, running
at 200 MHz. /memtest86/ shows no errors whatsoever, and the power
supply is 350 Watts but doesn't pull more than 220 Watts during boot-up
and appears to check out fine. The BIOS is a Phoenix, but don't ask me
what release. ;-)

One of the strange things is that often during the Linux kernel boot
process, only three of the four hyperthreaded virtual CPUs are found -
occasionally only two, even. This "failure" is noticeable in advance
before the kernel actually starts displaying its boot messages by the
delay in switching from standard VGA resolution to the higher
resolution framebuffer, and there is a higher chance of this oddness
occurring when you press the /Enter/ key in the GRUB or LILO boot menu
before the timeout has expired. It then also shows strange messages
like "booting processor 3/7", suggesting that the kernel sees eight
processors, while it's a two-socket motherboard with two hyperthreaded
Xeons.

The machine has had this flaw from the beginning, but at the time it
was still rather exceptional, while by now it's rather exceptional to
still have it recognize all four virtual CPUs. It also used to fully
lock up without anything serious running, but the rate at which this
would happen was unpredictable. One time it would run for a whole
week, the other time it would lock up after only a few hours, or even
earlier.

The machine has had Mandrake 10.0 PowerPack on it with a custom-built
vanilla 2.6.x kernel - various releases, starting with 2.6.5 and ending
with 2.6.17 or something - for many years but since it has gotten the
newer SCSI disks I've installed it with CentOS 5.1, as it was intended
to be used for our still very preliminary webhosting, and our hosting
software (DirectAdmin) only works with CentOS (or is only supported by
the developers to work with CentOS, anyway).

I'm mentioning all this because quite obviously everyone appears to be
stumped with regard to what could be wrong with this machine, and you
come across like somewhat of an Intel /connoisseur./ So maybe
you've got any clues? ;-)


There is a manual for the SE7500CW2 here.

http://download.intel.com/support/mo...500cw2/tps.pdf

http://support.intel.com/support/mot...ver/se7500cw2/

(Picture)
http://www.xeonchassis.com/images/IntelCW-OH.jpg

The design uses a shared VRM for both processors. The Intel document
says the processors should be matched. And that is because they're both
going to be getting their Vcore from the same source. The VRM supports a
total load of 130W or the usage of two 65W processors. The motherboard
checks the VID from both processors, to make sure they're matched, so
that should provide some protection against a completely mismatched set
of processors from a voltage perspective.

You could concentrate on running a memory test. Or use multiple copies
of the Linux version of Prime95, as a means of doing an integrity test
on memory and processor. That should run the CPU at 100%, especially if
running four or more copies. (Prime95 is good, because it won't be held
back by disks or storage subsystems. A single math error and it catches
it.)

http://www.mersenne.org/freesoft/#newusers

In terms of strip-down procedures, you could try running with one
processor at a time, and see whether the symptoms are the same in each
case. (No terminator is needed in the empty second socket.)

With four sticks of RAM, you can also run just two sticks at a time, and
test them that way. (The board is dual channel, and the manual claims a
two stick minimum. If may run with just one stick, but I don't
immediately see that suggested in the manual.)

A 350W power supply, could be a dual redundant 350W with load sharing,
or it could be a $20 single supply from Quickie-Mart. You'd need to have
more of a look at it, to judge whether it is adequate (the label has a
bunch of limits printed on it). In a quick web search, I see SE7500CW2
based machines shipping with 450W supplies, to give you an idea what
others use. But if you have 20 disk drives in the box, obviously that
requires more beef.

If you want help with hardware, it helps to start your own thread about
your hardware problems, and not hijack the General's thread :-)

Paul


I don't see this as hijacking my thread, in fact I'd appreciate it of
Aragorn were to give sys_basher a try and let me know if it catches his
problem. And I'd also appreciate any suggestions for tests that I could
add which would improve sys_basher's ability to find problems of this
sort.
  #7  
Old December 28th 08, 03:05 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
Aragorn
external usenet poster
 
Posts: 17
Default New release of sys_basher

On Sunday 28 December 2008 14:10, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardwa/

On Sun, 28 Dec 2008 07:22:40 +0100, Aragorn wrote:

On Sunday 28 December 2008 05:24, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardwa/

I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.


Does it also do diagnostics of other possibly failing hardware
components than memory? I'm just asking because I've got a machine
sitting here idly for quite some time now due to strange lockups and
BIOS ECC error log entries.


I use the term exerciser rather than diagnostic because it can't identify
the individual component that's failing, all it can do is tell you that
there is a problem with a CPU, RAM or disk. Sys_basher is an ordinary
user space program, and as far as I can tell there is no way to get Linux
to do a logical address to physical address translation or to determine
which physical core a thread is running on for a user space program. If
there is a way I'd appreciate someone telling me how to do it and I'd add
it to sys_basher so that it could give more precise error messages.

Sys_basher is designed to maximize the stress on the system. In addition
to memory tests, which operate at the maximum read and write bandwidth of
each level of the memory hierarchy, there are integer and floating point
arithmetic tests which are unrolled loops that can use up to eight
functional units (4 adders and 4 multipliers) per cycle which should push
the core temperatures to their maximum. All of the arithmetic tests are
done register to register, memory to register and memory to memory. I
step through array sizes from 1K, which fits entirely in the primary
cache, to 64M which operates almost entirely in DRAM. The RAM and disk
tests also step through a range of array sizes, from 1K to 64M for disk I/
O and from 1K to the full virtual memory size for the memory tests (there
is a switch to set the amount of RAM tested, I find that the physical
size - 300M is a good choice, more than that will cause the system to
swap which will kill the performance).

Sys_basher also reports memory bandwidth for each array size, disk
bandwidth for each of the supported I/O modes and file sizes, OPS and
MFLOPS for each array size.

Give it a try and see if it helps you identify your problem. I'd
appreciate any feedback and suggestions that you have.


I will, thank you. It'll be some time before I actually can, though. The
machine is currently sitting disassembled - i.e. monitor, powercord,
keyboard and mouse disconnected - in my living room as I needed and at the
moment still need the space for maintenance on my rather vast collection of
guitars...

Yet I will run the test and I will report back to you. ;-)

--
*Aragorn*
(registered GNU/Linux user #223157)
  #8  
Old December 28th 08, 03:13 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
Aragorn
external usenet poster
 
Posts: 17
Default New release of sys_basher

On Sunday 28 December 2008 14:04, someone identifying as *Paul* wrote
in /comp.os.linux.hardwa/

Aragorn wrote:

On Sunday 28 December 2008 05:24, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardwa/

I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.


Does it also do diagnostics of other possibly failing hardware components
than memory? I'm just asking because I've got a machine sitting here
idly for quite some time now due to strange lockups and BIOS ECC error
log entries.

[...]
There is a manual for the SE7500CW2 here.

http://download.intel.com/support/mo...500cw2/tps.pdf


Yes, I have that manual already, thank you. I have even printed it out
because the machine was assembled elsewhere and it did not come with any
documentation.

http://support.intel.com/support/mot...ver/se7500cw2/

(Picture)
http://www.xeonchassis.com/images/IntelCW-OH.jpg

The design uses a shared VRM for both processors. The Intel document says
the processors should be matched. And that is because they're both going
to be getting their Vcore from the same source. The VRM supports a total
load of 130W or the usage of two 65W processors. The motherboard checks
the VID from both processors, to make sure they're matched, so that
should provide some protection against a completely mismatched
set of processors from a voltage perspective.


The processors are matched, yes.

You could concentrate on running a memory test. Or use multiple copies
of the Linux version of Prime95, as a means of doing an integrity test
on memory and processor. That should run the CPU at 100%, especially
if running four or more copies. (Prime95 is good, because it won't
be held back by disks or storage subsystems. A single math error and
it catches it.)

http://www.mersenne.org/freesoft/#newusers


Interesting tip, thank you.

In terms of strip-down procedures, you could try running with one
processor at a time, and see whether the symptoms are the same in
each case. (No terminator is needed in the empty second socket.)

With four sticks of RAM, you can also run just two sticks at a time,
and test them that way. (The board is dual channel, and the manual
claims a two stick minimum. If may run with just one stick,
but I don't immediately see that suggested in the manual.)


I'm afraid this is out of my league. I am rather clumsy - it has to do with
certain motor skill impairments - and so I prefer leaving swapping
processors around and removing or swapping memory sticks to a
professional. :-/

A 350W power supply, could be a dual redundant 350W with load
sharing, or it could be a $20 single supply from Quickie-Mart.
You'd need to have more of a look at it, to judge whether it
is adequate (the label has a bunch of limits printed on it).
In a quick web search, I see SE7500CW2 based machines shipping
with 450W supplies, to give you an idea what others use. But if
you have 20 disk drives in the box, obviously that requires
more beef.


The power supply was Intel-certified, of this I am sure.

If you want help with hardware, it helps to start your own thread
about your hardware problems, and not hijack the General's thread :-)


I am sorry if it comes across as if I hijacked the thread. This was
certainly not my intention, and thus I apologize.

The problem in itself was not of an urgent nature and so I did not see any
need to start a thread about it yet, but the General's post made me wonder
whether I could use his tool to diagnose the illness of that particular
machine, and I know I tend to be rather verbose. :-/

--
*Aragorn*
(registered GNU/Linux user #223157)
  #9  
Old December 28th 08, 09:20 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
1PW
external usenet poster
 
Posts: 1
Default New release of sys_basher

On 12/27/2008 08:24 PM, General Schvantzkoph sent:
I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.



Hello:

I'm having trouble with the make sys-basher2. I run RHEL5.2 and my
installed versions of lm_sensors and lm_sensors-devel are at
2.10.6-55.el5 from rpm.bone.net, rather than the version 2.10.0-3.1.i386
from Red Hat or CentOS. The following is what I get during the make:

# make sys_basher2
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_main.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_utils.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_disk.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_kernel.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_fp.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_int.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_mem.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g lin_utils.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_sensors2.c
sys_sensors2.c: In function ‘getTemps’:
sys_sensors2.c:48: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or
‘__attribute__’ before ‘*’ token
sys_sensors2.c:48: error: ‘feature_data’ undeclared (first use in this
function)
sys_sensors2.c:48: error: (Each undeclared identifier is reported only once
sys_sensors2.c:48: error: for each function it appears in.)
sys_sensors2.c:72: warning: passing argument 1 of
‘sensors_get_detected_chips’ from incompatible pointer type
sys_sensors2.c:72: error: too few arguments to function
‘sensors_get_detected_chips’
sys_sensors2.c:83: error: incompatible type for argument 1 of
‘sensors_get_label’
sys_sensors2.c:83: error: too many arguments to function ‘sensors_get_label’
sys_sensors2.c:119: warning: passing argument 1 of
‘sensors_get_detected_chips’ from incompatible pointer type
sys_sensors2.c:119: error: too few arguments to function
‘sensors_get_detected_chips’
make: *** [sys_sensors2.o] Error 1

Do you have any ideas as to what could be wrong?

Thank you.

Pete
--
1PW @?6A62?FEH9E=6o2@=]4@ [r4o7t]
  #10  
Old December 28th 08, 09:34 PM posted to comp.os.linux.hardware,alt.comp.hardware.overclocking
General Schvantzkoph
external usenet poster
 
Posts: 246
Default New release of sys_basher

On Sun, 28 Dec 2008 12:20:02 -0800, 1PW wrote:

On 12/27/2008 08:24 PM, General Schvantzkoph sent:
I've put a new release of sys_basher on the web,

http://www.polybus.com/sys_basher_web/

sys_basher is a multi-threaded hardware exerciser, memory tester and
benchmarking tool. It will run on any Linux or Unix.



Hello:

I'm having trouble with the make sys-basher2. I run RHEL5.2 and my
installed versions of lm_sensors and lm_sensors-devel are at
2.10.6-55.el5 from rpm.bone.net, rather than the version 2.10.0-3.1.i386
from Red Hat or CentOS. The following is what I get during the make:

# make sys_basher2
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_main.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_utils.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_disk.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_kernel.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_fp.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_int.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_mem.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g lin_utils.c
gcc -c -O2 -Wuninitialized -Wformat -Wno-multichar -Wreturn-type
-Wswitch -g sys_sensors2.c
sys_sensors2.c: In function ‘getTemps’: sys_sensors2.c:48: error:
expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘*’ token
sys_sensors2.c:48: error: ‘feature_data’ undeclared (first use in this
function)
sys_sensors2.c:48: error: (Each undeclared identifier is reported only
once sys_sensors2.c:48: error: for each function it appears in.)
sys_sensors2.c:72: warning: passing argument 1 of
‘sensors_get_detected_chips’ from incompatible pointer type
sys_sensors2.c:72: error: too few arguments to function
‘sensors_get_detected_chips’
sys_sensors2.c:83: error: incompatible type for argument 1 of
‘sensors_get_label’
sys_sensors2.c:83: error: too many arguments to function
‘sensors_get_label’ sys_sensors2.c:119: warning: passing argument 1 of
‘sensors_get_detected_chips’ from incompatible pointer type
sys_sensors2.c:119: error: too few arguments to function
‘sensors_get_detected_chips’
make: *** [sys_sensors2.o] Error 1

Do you have any ideas as to what could be wrong?

Thank you.

Pete


Curious. All of my systems are 64 bit, I wonder if the 32 bit version of
lm_sensors has a different API then the 64 bit version. I'm using
CentOS5.2, Fedora 9 and Fedora 10 and it works fine on all of those. I
have a 32 bit CentOS 5.2 VM, I'll start it up and see if there is a
problem.
 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
New release of sys_basher General Schvantzkopf Intel 1 October 18th 07 07:53 AM
New release of sys_basher General Schvantzkopf AMD x86-64 Processors 1 October 18th 07 07:53 AM
New release of sys_basher, hardware exerciser B. Joshua Rosen Intel 0 May 1st 07 04:19 PM
New release of sys_basher, hardware exerciser B. Joshua Rosen AMD x86-64 Processors 0 May 1st 07 04:19 PM
New release of sys_basher (Free system exerciser tool) B. Joshua Rosen AMD x86-64 Processors 1 March 22nd 07 12:35 PM


All times are GMT +1. The time now is 01:32 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 HardwareBanter.
The comments are property of their posters.