Re: test9-pre5+t9p2-vmpatch VM deadlock during write-intensive workload

2000-09-22 Thread André Dahlqvist

> I had to type the oops down by hand, but I will provide ksymoops
> output soon if you need it.

Let's hope I typed down the oops from the screen without misstakes. Here
is the ksymoops output:

ksymoops 2.3.4 on i586 2.4.0-test9.  Options used
 -V (default)
 -k 2922143001.ksyms (specified)
 -l 2922143001.modules (specified)
 -o /lib/modules/2.4.0-test9/ (default)
 -m /boot/System.map-2.4.0-test9 (default)

invalid operand: 
CPU:0
EIP:0010:[]
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010086
eax: 001c   ebx: c31779e0 ecx:    edx: 0082
esi: c11f6f80   edi: 0008 ebp: 0001   esp: c01f3eec
ds: 0018   es: 0018   ss: 0018
Process swapper (pid:0, stackpage=c01f3000)
Stack: c01bb465 c01bb79a 02da c0150d3f e31779e0 0001 c11f6480 0046
   c1168360 c0248460 c01684e3 c11f6f80 0001 c0248584  c11f6f80
   c02484a0 c016e563 0001 c1168360 c02484a0 c1168360 0286 c0169cc7
Call Trace: [] [] [] []
[] [] [] [] [] [] 
[]
[] [] [] []
  []
Code: 0f 0b 83 c4 0c c3 57 56 53 86 74 24 10 8b 54 24 14 85 d2 74

>>EIP; c012c1be<=
Trace; c01bb4b5 
Trace; c01bb79a 
Trace; c0150d3f 
Trace; c01684e3 
Trace; c016e563 
Trace; c0169cc7 
Trace; c016e500 
Trace; c010a02c 
Trace; c010a18e 
Trace; c0107120 
Trace; c0108de0 
Trace; c0107120 
Trace; c0107143 
Trace; c01071a7 
Trace; c0105000 
Trace; c0100192 
Code;  c012c1be 
 <_EIP>:
Code;  c012c1be<=
   0:   0f 0b ud2a  <=
Code;  c012c1c0 
   2:   83 c4 0c  add$0xc,%esp
Code;  c012c1c3 
   5:   c3ret
Code;  c012c1c4 
   6:   57push   %edi
Code;  c012c1c5 
   7:   56push   %esi
Code;  c012c1c6 
   8:   53push   %ebx
Code;  c012c1c7 
   9:   86 74 24 10   xchg   %dh,0x10(%esp,1)
Code;  c012c1cb 
   d:   8b 54 24 14   mov0x14(%esp,1),%edx
Code;  c012c1cf 
  11:   85 d2 test   %edx,%edx
Code;  c012c1d1 
  13:   74 00 je 15 <_EIP+0x15> c012c1d3 


Aiee, killing interrupt handler
Kernel panic: Attempted to kill the idle task!
-- 

// André
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



Re: test9-pre5+t9p2-vmpatch VM deadlock during write-intensive workload

2000-09-22 Thread André Dahlqvist

On Fri, Sep 22, 2000 at 07:27:30AM -0300, Rik van Riel wrote:

> Linus,
> 
> could you please include this patch in the next
> pre patch?

Rik,

I just had an oops with this patch applied. I ran into BUG at
buffer.c:730. The machine was not under load when the oops occured, I
was just reading e-mail in Mutt. I had to type the oops down by hand,
but I will provide ksymoops output soon if you need it.
-- 

// André
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/



test9-pre5+t9p2-vmpatch VM deadlock during write-intensive workload

2000-09-22 Thread Molnar Ingo


i'm still getting VM related lockups during heavy write load, in
test9-pre5 + your 2.4.0-t9p2-vmpatch (which i understand as being your
last VM related fix-patch, correct?). Here is a histogram of such a
lockup:

  1 Trace; 4010a720 <__switch_to+38/e8>
  5 Trace; 4010a74b <__switch_to+63/e8>
 13 Trace; 4010abc4 
819 Trace; 4010abca 
   1806 Trace; 4010abce 
  1 Trace; 4010abd0 
  2 Trace; 4011af51 
  1 Trace; 4011af77 
  1 Trace; 4011b010 
  3 Trace; 4011b018 
  1 Trace; 4011b02d 
  1 Trace; 4011b051 
  1 Trace; 4011b056 
  2 Trace; 4011b05c 
  3 Trace; 4011b06d 
  4 Trace; 4011b076 
537 Trace; 4011b2bb 
  2 Trace; 4011b2c6 
  1 Trace; 4011b2c9 
  4 Trace; 4011b2d5 
 31 Trace; 4011b31a 
  1 Trace; 4011b31d 
  1 Trace; 4011b32a 
  1 Trace; 4011b346 
 11 Trace; 4011b378 
  2 Trace; 4011b381 
  5 Trace; 4011b3f8 
 17 Trace; 4011b404 
  9 Trace; 4011b43f 
  1 Trace; 4011b450 
  1 Trace; 4011b457 
  2 Trace; 4011b48c 
  1 Trace; 4011b49c 
428 Trace; 4011b4cd 
  6 Trace; 4011b4f7 
  4 Trace; 4011b500 
  2 Trace; 4011b509 
  1 Trace; 4011b560 
  1 Trace; 4011b809 <__wake_up+79/3f0>
  1 Trace; 4011b81b <__wake_up+8b/3f0>
  8 Trace; 4011b81e <__wake_up+8e/3f0>
310 Trace; 4011ba90 <__wake_up+300/3f0>
  1 Trace; 4011bb7b <__wake_up+3eb/3f0>
  2 Trace; 4011c32b 
244 Trace; 4011d40e 
  1 Trace; 4011d411 
  1 Trace; 4011d56c 
618 Trace; 4011d62e 
  2 Trace; 40122f28 
  2 Trace; 40126c3c 
  1 Trace; 401377ab 
  1 Trace; 401377c8 
  5 Trace; 401377cc 
 15 Trace; 401377d4 
 11 Trace; 401377dc 
  2 Trace; 401377e0 
  6 Trace; 401377ee 
  8 Trace; 4013783c 
  1 Trace; 401378f8 
  3 Trace; 4013792d 
  2 Trace; 401379af 
  2 Trace; 401379f3 
  1 Trace; 40138524 <__alloc_pages+7c/4b8>
  1 Trace; 4013852b <__alloc_pages+83/4b8>

(first column is number of profiling hits, profiling hits taken on all
CPUs.)

unfortunately i havent captured which processes are running. This is an
8-CPU SMP box, 8 write-intensive processes are running, they create new
1k-1MB files in new directories - a total of many gigabytes.

this lockup happens both during vanilla test9-pre5 and with
2.4.0-t9p2-vmpatch. Your patch makes the lockup happen a bit later than
previous, but it still happens. During the lockup all dirty buffers are
written out to disk until it reaches such a state:

2162688 pages of RAM
1343488 pages of HIGHMEM
116116 reserved pages
652826 pages shared
0 pages swap cached
0 pages in page table cache
Buffer memory:52592kB
CLEAN: 664 buffers, 2302 kbyte, 5 used (last=93), 0 locked, 0 protected, 0 dirty
   LOCKED: 661752 buffers, 2646711 kbyte, 37 used (last=661397), 0 locked, 0 
protected, 0 dirty
DIRTY: 17 buffers, 26 kbyte, 1 used (last=1), 0 locked, 0 protected, 17 dirty

no disk IO happens anymore, but the lockup persists. The histogram was
taken after all disk IO has stopped.

Ingo

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/