| 1 |
On Monday 28 August 2006 11:24, CapSel wrote: |
| 2 |
|
| 3 |
> Process kswapd0 (pid: 162, threadinfo=c2272000 task=c2201a50) |
| 4 |
> Stack: c014d48c f5064090 f5064098 00000000 0000002f c01604fb 0000002f |
| 5 |
> 00000080 c5e52248 c446cab8 00000000 00007080 00000081 c20fe520 c01605ce |
| 6 |
> c01394db 001c2000 00000000 00007080 00000003 00000000 00000000 0007172e |
| 7 |
> 000000d0 Call Trace: |
| 8 |
> <c014d48c> remove_inode_buffers+0x28/0x5b <c01604fb> |
| 9 |
> prune_icache+0xb8/0x177 <c01605ce> shrink_icache_memory+0x14/0x2b |
| 10 |
> <c01394db> shrink_slab+0x13c/0x194 <c013a651> balance_pgdat+0x219/0x335 |
| 11 |
> <c013a859> kswapd+0xec/0xee <c0128712> autoremove_wake_function+0x0/0x2d |
| 12 |
> <c0128712> |
| 13 |
|
| 14 |
This reminds me of a box I had with faulty memory - it would some times crash |
| 15 |
when it was about to start using swap. If the buffering was too aggressive |
| 16 |
the machine would crash. If not it would start swapping and carry on working |
| 17 |
without further problems. I changed the offending memory module and had no |
| 18 |
problems since. |
| 19 |
|
| 20 |
Somebody else may know more with respect to the particular data dump you |
| 21 |
provided, otherwise you could try troubleshooting it by using some more |
| 22 |
involved memory/swap tests (not just mem86+). |
| 23 |
|
| 24 |
HTH. |
| 25 |
-- |
| 26 |
Regards, |
| 27 |
Mick |
Archives