[lkml]   [2000]   [Sep]   [25]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: more testing on 2.4.0-t9p[456] VM deadlocks

On Mon, 25 Sep 2000, Martin Diehl wrote:

> PS: vmfixes-2.4.0-test9-B2 not yet tested - will do later.

Hi - done now:

using 2.4.0-t9p6 + vmfixes-2.4.0-test9-B2 I ended up with the box
deadlocked again! Was "make bzImage" on UP booted with mem=8M.
After about 4 hours at load 2-3 and almost continously paging the box
is apparently locked up. SysRq+t still shows several processes including
kswapd being scheduled "current" (one after the other of course).

Mem-Info (retyped from SysRq+m):
Active: 847 / inactive dirty: 67 / inactive clean: 0 / free: 64
2x16 + 1x32 + 1x64 + 1x128 = 256kB
Swap cache: add 3353996, delete 3353209, find 2300336/9605753
Free swap: 496144kB
2048 pages of RAM
0 pages of HIGHMEM
490 reserved pages
74 pages shared
787 pages cached
0 pages in page table cache
Buffer memory: 236kB

No change on this at all, despite the scheduling activity still observed.

I've looked up several EIP-values (given by SysRq+p) vs. to get
an idea what is still going on. The functions I've recorded (this # often):


The results of this very rudimentary "profiling the deadlock" are far from
statistical significance of course. The only ordering rule implied in this
list is the number of occurences - i.e., I don't see any pattern or call
chain there.

Finally, SysRq+e solved the problem: hanging processes term'ed, VM
deadlock released, box seems to be as useable as after it was booted.



To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 12:38    [W:0.060 / U:1.516 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site