|
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. |
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./ :p So maybe you've got any clues? ;-) -- *Aragorn* (registered GNU/Linux user #223157) |
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. |
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./ :p 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 |
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. |
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./ :p 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. |
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... :p Yet I will run the test and I will report back to you. ;-) -- *Aragorn* (registered GNU/Linux user #223157) |
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) |
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?FEH9:DE=6o2@=]4@ [r4o7t] |
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. |
All times are GMT +1. The time now is 05:47 PM. |
|
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
HardwareBanter.com