| 1 |
On Mon, 2006-08-28 at 11:49 +0100, Mick wrote: |
| 2 |
> On Monday 28 August 2006 11:24, CapSel wrote: |
| 3 |
> |
| 4 |
> > Process kswapd0 (pid: 162, threadinfo=c2272000 task=c2201a50) |
| 5 |
> > Stack: c014d48c f5064090 f5064098 00000000 0000002f c01604fb 0000002f |
| 6 |
> > 00000080 c5e52248 c446cab8 00000000 00007080 00000081 c20fe520 c01605ce |
| 7 |
> > c01394db 001c2000 00000000 00007080 00000003 00000000 00000000 0007172e |
| 8 |
> > 000000d0 Call Trace: |
| 9 |
> > <c014d48c> remove_inode_buffers+0x28/0x5b <c01604fb> |
| 10 |
> > prune_icache+0xb8/0x177 <c01605ce> shrink_icache_memory+0x14/0x2b |
| 11 |
> > <c01394db> shrink_slab+0x13c/0x194 <c013a651> balance_pgdat+0x219/0x335 |
| 12 |
> > <c013a859> kswapd+0xec/0xee <c0128712> autoremove_wake_function+0x0/0x2d |
| 13 |
> > <c0128712> |
| 14 |
> |
| 15 |
> This reminds me of a box I had with faulty memory |
| 16 |
|
| 17 |
I agree, it sounds notoriously like faulty RAM, which often shows its |
| 18 |
symptoms at high load (don't ask me why). |
| 19 |
|
| 20 |
I find that re-seating the RAM may help, at least for a short period |
| 21 |
(expect that it might return). |
| 22 |
|
| 23 |
You can try memtest, but apparently it gets harder and harder to detect |
| 24 |
memory problems as new techniques are developed by hardware |
| 25 |
manufacturers to make memory faster. |
| 26 |
|
| 27 |
I suggest a trial and error - swap the RAM with one of the other |
| 28 |
machines, or with a fresh set of RAM if you can get some - if the |
| 29 |
symptoms follow the RAM from server to server then you know what the |
| 30 |
problem is :) |
| 31 |
|
| 32 |
HTH, |
| 33 |
-- |
| 34 |
Iain Buchanan <iaindb at netspace dot net dot au> |
| 35 |
|
| 36 |
The human race has one really effective weapon, and that is laughter. |
| 37 |
-- Mark Twain |
| 38 |
|
| 39 |
-- |
| 40 |
gentoo-user@g.o mailing list |
Archives