| Home | Register | Members | Search | Links |
 |
| Thread Tools | Display Modes |
|
Guest
Posts: n/a
|
|
|
|
||
|
Guest
Posts: n/a
|
On Sunday 28 December 2008 05:24, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardware:/ > 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 anyclues? ;-) -- *Aragorn* (registered GNU/Linux user #223157) |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
Aragorn wrote:
> On Sunday 28 December 2008 05:24, someone identifying as *General > Schvantzkoph* wrote in /comp.os.linux.hardware:/ > >> 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 |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
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.hardware:/ >> >>> 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. |
|
|
|
|
|||
|
Guest
Posts: n/a
|
On Sunday 28 December 2008 14:10, someone identifying as *General
Schvantzkoph* wrote in /comp.os.linux.hardware:/ > 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.hardware:/ >> >>> 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) |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
Guest
Posts: n/a
|
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  E=6o2@=]4@> [r4o7t] |
|
|
|
|
|||
|
Guest
Posts: n/a
|
|
|
|
|
||
|
| Thread Tools | |
| Display Modes | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Windows XP: A thread tried to release a resource it did not own | sawvufan | Gigabyte | 1 | 11-26-2008 03:31 AM |
| New release of sys_basher | General Schvantzkopf | Intel | 1 | 10-18-2007 07:53 AM |
| Intel e6750 release date? | Philip Procter | Gigabyte | 2 | 07-08-2007 05:01 AM |
| New release of sys_basher (Free system exerciser tool) | B. Joshua Rosen | Intel | 1 | 03-22-2007 11:35 AM |
| New release of sys_basher, Linux hardware stress test andbenchmarking tool | General Schvantzkoph | Intel | 1 | 01-08-2007 12:04 PM |
Linear Mode
