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);
.
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