Mailing List Archive: Linux: Kernel

2.6.13-rc3-mm3

1 2 3 4

View All

Index | Next | Previous | View Threaded

mbligh at mbligh

Aug 2, 2005, 6:17 PM

Post #76 of 90 (638 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

--Andrew Morton <akpm [at] osdl> wrote (on Thursday, July 28, 2005 23:10:29 -0700):

> "Martin J. Bligh" <mbligh [at] mbligh> wrote:
>>
>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>> identified earlier with the sched patches ...
>>
>> http://test.kernel.org/9398/debug/console.log
>
> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
>
>> Works with mainline still (including -rc4) ... hopefully those patches
>> aren't on their way upstream anytime soon ;-)
>
> Well can you identify the offending patch(es)? If so, I'll exterminate them.
>
>
>

scheduler-cache-hot-autodetect.patch, I think.

will double-check.

M.

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

mbligh at mbligh

Aug 2, 2005, 9:21 PM

Post #77 of 90 (643 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

--"Martin J. Bligh" <mbligh [at] mbligh> wrote (on Tuesday, August 02, 2005 18:17:33 -0700):
> --Andrew Morton <akpm [at] osdl> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
>
>> "Martin J. Bligh" <mbligh [at] mbligh> wrote:
>>>
>>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>>> identified earlier with the sched patches ...
>>>
>>> http://test.kernel.org/9398/debug/console.log
>>
>> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
>>
>>> Works with mainline still (including -rc4) ... hopefully those patches
>>> aren't on their way upstream anytime soon ;-)
>>
>> Well can you identify the offending patch(es)? If so, I'll exterminate them.
>
> scheduler-cache-hot-autodetect.patch, I think.
>
> will double-check.

Yup, backing out that one patch definitely fixes it. There was an earlier
thread with Ingo about doing some possible debug on it, but to be honest,
I haven't had time to play much beyond the initial ideas we tried.

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

christoph at lameter

Aug 3, 2005, 5:19 PM

Post #78 of 90 (634 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

Could you try the following patch? I think the problem was that higher
addressses were not mappable via the page fault handler. This patch
inserts the pmd entry into the pgd as necessary if the pud level is
folded.

Signed-off-by: Christoph Lameter <christoph [at] lameter>

Index: linux-2.6.13-rc4/mm/memory.c
===================================================================
--- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:08:29.000000000 -0700
+++ linux-2.6.13-rc4/mm/memory.c 2005-08-03 17:15:22.000000000 -0700
@@ -2144,9 +2144,16 @@
*/
page_table_atomic_start(mm);
pgd = pgd_offset(mm, address);
-#ifndef __PAGETABLE_PUD_FOLDED
if (unlikely(pgd_none(*pgd))) {
+#ifdef __PAGETABLE_PUD_FOLDED
+ /* If the pud is folded then we need to insert a pmd entry into
+ * a pgd. pud_none(pgd) == 0 so the next if statement will never
+ * be taken
+ */
+ pmd_t *new;
+#else
pud_t *new;
+#endif

page_table_atomic_stop(mm);
new = pud_alloc_one(mm, address);
@@ -2158,7 +2165,6 @@
if (!pgd_test_and_populate(mm, pgd, new))
pud_free(new);
}
-#endif

pud = pud_offset(pgd, address);
if (unlikely(pud_none(*pud))) {
Index: linux-2.6.13-rc4/include/asm-generic/4level-fixup.h
===================================================================
--- linux-2.6.13-rc4.orig/include/asm-generic/4level-fixup.h 2005-08-03 17:06:01.000000000 -0700
+++ linux-2.6.13-rc4/include/asm-generic/4level-fixup.h 2005-08-03 17:09:38.000000000 -0700
@@ -27,6 +27,7 @@
#define pud_ERROR(pud) do { } while (0)
#define pud_clear(pud) pgd_clear(pud)
#define pud_populate pgd_populate
+#define pud_alloc_one pmd_alloc_one

#undef pud_free_tlb
#define pud_free_tlb(tlb, x) do { } while (0)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rpurdie at rpsys

Aug 4, 2005, 4:27 AM

Post #79 of 90 (644 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> Could you try the following patch? I think the problem was that higher
> addressses were not mappable via the page fault handler. This patch
> inserts the pmd entry into the pgd as necessary if the pud level is
> folded.

I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
still hung in memcpy as before and the cmpxchg_fail_flag_update just
increases...

Richard

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

christoph at lameter

Aug 4, 2005, 7:04 AM

Post #80 of 90 (654 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Thu, 4 Aug 2005, Richard Purdie wrote:

> On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> > Could you try the following patch? I think the problem was that higher
> > addressses were not mappable via the page fault handler. This patch
> > inserts the pmd entry into the pgd as necessary if the pud level is
> > folded.
>
> I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
> still hung in memcpy as before and the cmpxchg_fail_flag_update just
> increases...

Is there some way you can give us more information about the problem?
Something that would allow us to determine where the thing is looping?

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

rpurdie at rpsys

Aug 4, 2005, 7:37 AM

Post #81 of 90 (657 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Thu, 2005-08-04 at 07:04 -0700, Christoph Lameter wrote:
> On Thu, 4 Aug 2005, Richard Purdie wrote:
>
> > On Wed, 2005-08-03 at 17:19 -0700, Christoph Lameter wrote:
> > > Could you try the following patch? I think the problem was that higher
> > > addressses were not mappable via the page fault handler. This patch
> > > inserts the pmd entry into the pgd as necessary if the pud level is
> > > folded.
> >
> > I tried this patch against 2.6.13-rc4-mm1 and there was no change - X
> > still hung in memcpy as before and the cmpxchg_fail_flag_update just
> > increases...
>
> Is there some way you can give us more information about the problem?
> Something that would allow us to determine where the thing is looping?

I'm at a disadvantage here as the linux mm system is one area I've
avoided getting too deeply involved with so far. My knowledge is
therefore limited and I won't know what correct or incorrect behaviour
would look like.

We know the the failure case can be identified by the
cmpxchg_fail_flag_update condition being met. Can you provide me with a
patch to dump useful debugging information when that occurs?

Richard

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

christoph at lameter

Aug 5, 2005, 8:17 AM

Post #82 of 90 (633 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Thu, 4 Aug 2005, Richard Purdie wrote:

> I'm at a disadvantage here as the linux mm system is one area I've
> avoided getting too deeply involved with so far. My knowledge is
> therefore limited and I won't know what correct or incorrect behaviour
> would look like.
>
> We know the the failure case can be identified by the
> cmpxchg_fail_flag_update condition being met. Can you provide me with a
> patch to dump useful debugging information when that occurs?

Well yes simply print out the information available in that context.

Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-03 17:02:29.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-05 08:17:14.000000000 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT "cmpxchg fail mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx\n",
+ mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry));
inc_page_state(cmpxchg_fail_flag_update);
}

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

rpurdie at rpsys

Aug 7, 2005, 6:44 AM

Post #83 of 90 (634 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Fri, 2005-08-05 at 08:17 -0700, Christoph Lameter wrote:
> On Thu, 4 Aug 2005, Richard Purdie wrote:
> >
> > We know the the failure case can be identified by the
> > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > patch to dump useful debugging information when that occurs?
>
> Well yes simply print out the information available in that context.
>
> + printk(KERN_CRIT "cmpxchg fail mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx\n",
> + mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry));

Ok, this results in an infinite loop of one message with no change to
the numbers:

cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077

Richard

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

mbligh at mbligh

Aug 7, 2005, 4:23 PM

Post #84 of 90 (662 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

--"Martin J. Bligh" <mbligh [at] mbligh> wrote (on Tuesday, August 02, 2005 21:21:30 -0700):

> --"Martin J. Bligh" <mbligh [at] mbligh> wrote (on Tuesday, August 02, 2005 18:17:33 -0700):
>> --Andrew Morton <akpm [at] osdl> wrote (on Thursday, July 28, 2005 23:10:29 -0700):
>>
>>> "Martin J. Bligh" <mbligh [at] mbligh> wrote:
>>>>
>>>> NUMA-Q boxes are still crashing on boot with -mm BTW. Is the thing we
>>>> identified earlier with the sched patches ...
>>>>
>>>> http://test.kernel.org/9398/debug/console.log
>>>
>>> Oh, thanks. That's about 8,349 bugs ago and I'd forgotten.
>>>
>>>> Works with mainline still (including -rc4) ... hopefully those patches
>>>> aren't on their way upstream anytime soon ;-)
>>>
>>> Well can you identify the offending patch(es)? If so, I'll exterminate them.
>>
>> scheduler-cache-hot-autodetect.patch, I think.
>>
>> will double-check.
>
> Yup, backing out that one patch definitely fixes it. There was an earlier
> thread with Ingo about doing some possible debug on it, but to be honest,
> I haven't had time to play much beyond the initial ideas we tried.

Still broken in 2.6.13-rc5-mm1, any chance you could back this one out
until it gets fixed? that way I can still test with that platform (plus
it'll stop it from getting accidentally merged ;-))

Thanks,

M.

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

christoph at lameter

Aug 8, 2005, 9:48 AM

Post #85 of 90 (637 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Sun, 7 Aug 2005, Richard Purdie wrote:

> > > We know the the failure case can be identified by the
> > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > patch to dump useful debugging information when that occurs?
>
> Ok, this results in an infinite loop of one message with no change to
> the numbers:
>
> cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
> ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077

Ok. So we cannot set the dirty bit.

Here is a patch that also prints the pte status immediately before
ptep_cmpxchg. I guess this will show that dirty bit is already set.

Does the ARM have some hardware capability to set dirty bits?

Index: linux-2.6.13-rc4-mm1/mm/memory.c
===================================================================
--- linux-2.6.13-rc4-mm1.orig/mm/memory.c 2005-08-05 08:38:10.000000000 -0700
+++ linux-2.6.13-rc4-mm1/mm/memory.c 2005-08-08 09:46:12.000000000 -0700
@@ -2104,6 +2104,8 @@
update_mmu_cache(vma, address, entry);
lazy_mmu_prot_update(entry);
} else {
+ printk(KERN_CRIT "cmpxchg fail fault mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx current=%lx\n",
+ mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry), *pte);
inc_page_state(cmpxchg_fail_flag_update);
}

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

rmk+lkml at arm

Aug 8, 2005, 10:10 AM

Post #86 of 90 (630 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Mon, Aug 08, 2005 at 09:48:22AM -0700, Christoph Lameter wrote:
> On Sun, 7 Aug 2005, Richard Purdie wrote:
>
> > > > We know the the failure case can be identified by the
> > > > cmpxchg_fail_flag_update condition being met. Can you provide me with a
> > > > patch to dump useful debugging information when that occurs?
> >
> > Ok, this results in an infinite loop of one message with no change to
> > the numbers:
> >
> > cmpxchg fail mm=c3455ae0 vma=c355517c addr=4025f000 write=2048
> > ptep=c2f0597c pmd=c2b79008 entry=88000f7 new=8800077
>
> Ok. So we cannot set the dirty bit.
>
> Here is a patch that also prints the pte status immediately before
> ptep_cmpxchg. I guess this will show that dirty bit is already set.
>
> Does the ARM have some hardware capability to set dirty bits?

ARM doesn't have cmpxchg nor does it have hardware access nor dirty
bits. They're simulated in software.

What's the problem you're trying to solve?

--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 Serial core
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

christoph at lameter

Aug 8, 2005, 10:15 AM

Post #87 of 90 (632 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Mon, 8 Aug 2005, Russell King wrote:

> ARM doesn't have cmpxchg nor does it have hardware access nor dirty
> bits. They're simulated in software.

Even the cmpxchg is simulated.

> What's the problem you're trying to solve?

A hang when starting X on ARM with rc4-mm1 which contains the page fault
patches. But I have no access to the platform.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo [at] vger
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

rpurdie at rpsys

Aug 8, 2005, 1:40 PM

Post #88 of 90 (637 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Mon, 2005-08-08 at 09:48 -0700, Christoph Lameter wrote:
> Ok. So we cannot set the dirty bit.
>
> Here is a patch that also prints the pte status immediately before
> ptep_cmpxchg. I guess this will show that dirty bit is already set.
>
> Does the ARM have some hardware capability to set dirty bits?
>
> + printk(KERN_CRIT "cmpxchg fail fault mm=%p vma=%p addr=%lx write=%d ptep=%p pmd=%p entry=%lx new=%lx current=%lx\n",
> + mm, vma, address, write_access, pte, pmd, pte_val(entry), pte_val(new_entry), *pte);

Ok, this results in:

cmpxchg fail fault mm=c39fc4e0 vma=c2a37bcc addr=4025f000 write=2048
ptep=c2fc197c pmd=c2b91008 entry=88000f7 new=8800077 current=8800077

I'm beginning to understand this code a bit more so I'll see if I can
work out anything myself as well...

Richard

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

rpurdie at rpsys

Aug 8, 2005, 3:12 PM

Post #89 of 90 (635 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

I've done a bit of analysis:

cmpxchg fail fault mm=c3945b20 vma=c304ad84 addr=402cb000 write=2048
ptep=c2af5b2c pmd=c2bc5008 entry=886c0f7 new=886c077 current=886c077

Note the Dirty bit is set on entry and not new where it probably should
be...

ptep_cmpxchg(mm, address, pte, entry, new_entry)

This will compare "current"(886c077) with "entry"(886c0f7) which are not
equal and the whole thing therefore correctly fails leading to the loop.

The following patch (against -mm) cleared the problem up but I'm not
sure how correct it is:

Index: linux-2.6.12/mm/memory.c
===================================================================
--- linux-2.6.12.orig/mm/memory.c 2005-08-08 23:03:45.000000000 +0100
+++ linux-2.6.12/mm/memory.c 2005-08-08 23:04:02.000000000 +0100
@@ -2046,7 +2046,7 @@
return do_wp_page(mm, vma, address, pte, pmd, entry);
#endif
}
- entry = pte_mkdirty(entry);
+ new_entry = pte_mkdirty(entry);
}

/*

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

christoph at lameter

Aug 8, 2005, 5:57 PM

Post #90 of 90 (650 views)
Permalink

Re: 2.6.13-rc3-mm3 [In reply to]

On Mon, 8 Aug 2005, Richard Purdie wrote:

> The following patch (against -mm) cleared the problem up but I'm not
> sure how correct it is:

Almost. The new entry needs to be made dirty. new_entry is already made
young. entry is not.

---

Set dirty bit correctly in handle_pte_fault

new_entry is used for the new pte entry. handle_mm_fault must dirty
new_entry and not "entry". entry is only used for comparison. The current
version does not set the dirty bit.

Signed-off-by: Christoph Lameter <clameter [at] sgi>

Index: linux-2.6.13-rc4/mm/memory.c
===================================================================
--- linux-2.6.13-rc4.orig/mm/memory.c 2005-08-03 17:15:22.000000000 -0700
+++ linux-2.6.13-rc4/mm/memory.c 2005-08-08 17:54:53.000000000 -0700
@@ -2091,7 +2091,7 @@
return do_wp_page(mm, vma, address, pte, pmd, entry);
#endif
}
- entry = pte_mkdirty(entry);
+ new_entry = pte_mkdirty(new_entry);
}

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

1 2 3 4

View All

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads