| 1 |
On 01/08/2014 11:39:21 PM, Stefan G. Weichinger wrote: |
| 2 |
> Am 08.01.2014 19:47, schrieb Grant Edwards: |
| 3 |
> > On 2014-01-08, Stefan G. Weichinger <lists@×××××.at> wrote: |
| 4 |
> > |
| 5 |
> >> Looking forward to some clever suggestions ;-) |
| 6 |
> > |
| 7 |
> > Well, I'd start by running memtest86 overnight just to eliminate the |
| 8 |
> > possibility of marginal memory. But, if memory serves, this is a |
| 9 |
> > remote server at a customer site -- so that may not be a viable |
| 10 |
> > option. |
| 11 |
> |
| 12 |
> Sure. Good suggestion. I would do that if I had physical access to the |
| 13 |
> server ... for now I don't. And I assume the box would behave much |
| 14 |
> more |
| 15 |
> problematic if the memory was faulty. |
| 16 |
|
| 17 |
You can use sys-apps/memtester without physical access to the machine. |
| 18 |
I had cases where memtester found errors which memtest86 didn't. |
| 19 |
One of these cases was a machine which probably had a cache coherence |
| 20 |
problem |
| 21 |
since the error showed up only when more than one process ran memtester. |
| 22 |
Replacing the CPU but not the memory fixed that problem. |
| 23 |
|
| 24 |
Did you try www.sysresccd.org/ version 3.8.1? I'm not sure if it is |
| 25 |
based on |
| 26 |
glibc-2.17, yet. |
| 27 |
|
| 28 |
Helmut. |
Archives