LTP-Nightly bk test

LTP-Nightly bk test

[Paul Larson]

The 8/17 run of the nightly bk testing I'm doing turned up a lot of page
allocation failures in the dmesg and eventually an oops in swap.c:85
(uncaptured, will try to reproduce on current).  Unfortunatly this meant
the test did not run after that.  This morning I rebooted the machine
and ran it against the current bk tree and with a single test was able
to produce a LOT of these messages:

page allocation failure. order:0, mode:0x50

The test was: 'mtest01 -p80 -w' which will essentially allocate up to
80% of the memory and write to it.  I'll keep pounding on it with LTP to
see if I can reproduce the swap.c:80 oops.

Thanks,
Paul Larson
Linux Test Project

Re: [Lse-tech] LTP-Nightly bk test

[Paul Larson]

On Mon, 2002-08-19 at 11:50, Martin J. Bligh wrote:
> > page allocation failure. order:0, mode:0x50
> > 
> > The test was: 'mtest01 -p80 -w' which will essentially allocate up to
> > 80% of the memory and write to it.  I'll keep pounding on it with LTP to
> > see if I can reproduce the swap.c:80 oops.
> 
> I think akpm posted a patch for similar mem exhaustion a few days ago,
> but I can't find it at the moment. Would be interesting to see what 
> /proc/meminfo and /proc/slabinfo look like as you march to your death ;-)
Anyone know where to find that patch?  I'll look at doing this again
while grabbing those files periodically.  I ran this again though and
got a different error:

kernel BUG at page_alloc.c:97!
invalid operand: 0000
CPU:    1
EIP:    0060:[<c013252a>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010202
eax: 02000150   ebx: c232aa14   ecx: c232aa14   edx: c232aa14
esi: 000001fb   edi: 00000000   ebp: f713d8a0   esp: f7093eb4
ds: 0068   es: 0068   ss: 0068
Stack: c232aa14 000001fb 00114000 f713d8a0 c232aa14 00047ffb c232aa6c
c232aac4
       c19a001c c03b7b00 00000207 ffffffff 0003783b 0001bc1d c0131079
c232aa14
       000001fb c01337cf 000001d6 c012708d c232aa14 63c00000 80000000
c3c388f0
Call Trace: [<c0131079>] [<c01337cf>] [<c012708d>] [<c0127135>]
[<c012718d>]
   [<c012a2a6>] [<c011658d>] [<c011b448>] [<c011b68a>] [<c01073e3>]
Code: 0f 0b 61 00 0d c7 31 c0 8b 5c 24 10 8b 03 f6 c4 20 74 08 0f

>>EIP; c013252a <__free_pages_ok+8a/330>   <=====
Trace; c0131078 <__page_cache_release+c4/c8>
Trace; c01337ce <free_page_and_swap_cache+42/48>
Trace; c012708c <zap_pte_range+24c/2a8>
Trace; c0127134 <zap_pmd_range+4c/68>
Trace; c012718c <unmap_page_range+3c/5c>
Trace; c012a2a6 <exit_mmap+ea/208>
Trace; c011658c <mmput+48/60>
Trace; c011b448 <do_exit+d8/2f4>
Trace; c011b68a <sys_exit+e/10>
Trace; c01073e2 <syscall_call+6/a>
Code;  c013252a <__free_pages_ok+8a/330>
00000000 <_EIP>:
Code;  c013252a <__free_pages_ok+8a/330>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c013252c <__free_pages_ok+8c/330>
   2:   61                        popa
Code;  c013252c <__free_pages_ok+8c/330>
   3:   00 0d c7 31 c0 8b         add    %cl,0x8bc031c7
Code;  c0132532 <__free_pages_ok+92/330>
   9:   5c                        pop    %esp
Code;  c0132534 <__free_pages_ok+94/330>
   a:   24 10                     and    $0x10,%al
Code;  c0132536 <__free_pages_ok+96/330>
   c:   8b 03                     mov    (%ebx),%eax
Code;  c0132538 <__free_pages_ok+98/330>
   e:   f6 c4 20                  test   $0x20,%ah
Code;  c013253a <__free_pages_ok+9a/330>
  11:   74 08                     je     1b <_EIP+0x1b> c0132544
<__free_pages_ok+a4/330>
Code;  c013253c <__free_pages_ok+9c/330>
  13:   0f 00 00                  sldt   (%eax)

Re: [Lse-tech] LTP-Nightly bk test

[Andrew Morton]

Paul Larson wrote:
> 
> On Mon, 2002-08-19 at 11:50, Martin J. Bligh wrote:
> > > page allocation failure. order:0, mode:0x50
> > >
> > > The test was: 'mtest01 -p80 -w' which will essentially allocate up to
> > > 80% of the memory and write to it.  I'll keep pounding on it with LTP to
> > > see if I can reproduce the swap.c:80 oops.
> >
> > I think akpm posted a patch for similar mem exhaustion a few days ago,
> > but I can't find it at the moment. Would be interesting to see what
> > /proc/meminfo and /proc/slabinfo look like as you march to your death ;-)
> Anyone know where to find that patch?  I'll look at doing this again
> while grabbing those files periodically.  I ran this again though and
> got a different error:
> 
> kernel BUG at page_alloc.c:97!

It's hard to tell where this is coming from.  Please quote
line 97 of page_alloc.c?

For the page allocation failures you'll probably need this, which
makes block-highmem work again.


--- 2.5.31/drivers/scsi/scsi_scan.c~scsi_hack	Sat Aug 17 02:43:05 2002
+++ 2.5.31-akpm/drivers/scsi/scsi_scan.c	Sat Aug 17 02:43:07 2002
@@ -1379,6 +1379,12 @@ static int scsi_add_lun(Scsi_Device *sde
 		printk(KERN_INFO "scsi: unknown device type %d\n", sdev->type);
 	}
 
+	/*
+	 * scsi_alloc_sdev did this, but do it again because we can now set
+	 * the bounce limit because the device type is known
+	 */
+	scsi_initialize_merge_fn(sdev);
+
 	sdev->random = (sdev->type == TYPE_TAPE) ? 0 : 1;
 
 	print_inquiry(inq_result);

.

If your machine is uniprocessor (?) you'll need this:


--- 2.5.31/mm/vmscan.c~pte-chain-fix	Sun Aug 18 19:38:15 2002
+++ 2.5.31-akpm/mm/vmscan.c	Sun Aug 18 19:38:37 2002
@@ -398,10 +398,7 @@ static /* inline */ void refill_inactive
 		page = list_entry(l_hold.prev, struct page, lru);
 		list_del(&page->lru);
 		if (page->pte.chain) {
-			if (test_and_set_bit(PG_chainlock, &page->flags)) {
-				list_add(&page->lru, &l_active);
-				continue;
-			}
+			pte_chain_lock(page);
 			if (page->pte.chain && page_referenced(page)) {
 				pte_chain_unlock(page);
 				list_add(&page->lru, &l_active);

.

Re: [Lse-tech] LTP-Nightly bk test

[Paul Larson]

On Mon, 2002-08-19 at 13:06, Andrew Morton wrote:

> For the page allocation failures you'll probably need this, which
> makes block-highmem work again.
Yes, this is a 2-way PIII-550.  I tried the patch and didn't get the
page_alloc.c:97 error (although I didn't see the page_alloc one the
first time either, only the second).  However, I did get the original
oops that I was trying to reproduce.

kernel BUG at swap.c:85!
invalid operand: 0000
CPU:    0
EIP:    0060:[<c0130ff0>]    Not tainted
Using defaults from ksymoops -t elf32-i386 -a i386
EFLAGS: 00010046
eax: 00000000   ebx: c2517f44     ecx: c03b7d60       edx: c0445230
esi: 00000202   edi: 0001a000     ebp: c38210d0       esp: c390def0
ds: 0068   es: 0068   ss: 0068
Stack: c2517f44 000001fb c01337cf 00000065 c012708d c2517f44 5ca00000
80000000
       c398d728 c0445220 c0445230 7aa09047 00000000 00019000 c0127135
c0445220
       c398d728 5ca00000 00200000 40148000 f76bcba8 8054c000 c0445220
c012718d
Call Trace: [<c01337cf>] [<c012708d>] [<c0127135>] [<c012718d>]
[<c012a2a6>]
   [<c011658d>] [<c011b448>] [<c011b68a>] [<c01073e3>]
Code: 0f 0b 55 00 4f c4 31 c0 8b 03 a8 40 74 3a 8d 4b 18 8b 51 04


>>EIP; c0130ff0 <__page_cache_release+3c/c8>   <=====

>>ebx; c2517f44 <END_OF_CODE+207b628/????>
>>ecx; c03b7d60 <contig_page_data+180/340>
>>edx; c0445230 <mmu_gathers+10/ff80>
>>edi; 0001a000 Before first symbol
>>ebp; c38210d0 <END_OF_CODE+33847b4/????>
>>esp; c390def0 <END_OF_CODE+34715d4/????>

Trace; c01337cf <free_page_and_swap_cache+43/48>
Trace; c012708d <zap_pte_range+24d/2a8>
Trace; c0127135 <zap_pmd_range+4d/68>
Trace; c012718d <unmap_page_range+3d/5c>
Trace; c012a2a6 <exit_mmap+ea/208>
Trace; c011658d <mmput+49/60>
Trace; c011b448 <do_exit+d8/2f4>
Trace; c011b68a <sys_exit+e/10>
Trace; c01073e3 <syscall_call+7/b>

Code;  c0130ff0 <__page_cache_release+3c/c8>
00000000 <_EIP>:
Code;  c0130ff0 <__page_cache_release+3c/c8>   <=====
   0:   0f 0b                     ud2a      <=====
Code;  c0130ff2 <__page_cache_release+3e/c8>
   2:   55                        push   %ebp
Code;  c0130ff3 <__page_cache_release+3f/c8>
   3:   00 4f c4                  add    %cl,0xffffffc4(%edi)
Code;  c0130ff6 <__page_cache_release+42/c8>
   6:   31 c0                     xor    %eax,%eax
Code;  c0130ff8 <__page_cache_release+44/c8>
   8:   8b 03                     mov    (%ebx),%eax
Code;  c0130ffa <__page_cache_release+46/c8>
   a:   a8 40                     test   $0x40,%al
Code;  c0130ffc <__page_cache_release+48/c8>
   c:   74 3a                     je     48 <_EIP+0x48> c0131038
<__page_cache_release+84/c8>
Code;  c0130ffe <__page_cache_release+4a/c8>
   e:   8d 4b 18                  lea    0x18(%ebx),%ecx
Code;  c0131001 <__page_cache_release+4d/c8>
  11:   8b 51 04                  mov    0x4(%ecx),%edx