[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20060727.203859.74749067.davem@davemloft.net>
Date: Thu, 27 Jul 2006 20:38:59 -0700 (PDT)
From: David Miller <davem@...emloft.net>
To: mikpe@...uu.se
Cc: linux-kernel@...r.kernel.org, sparclinux@...r.kernel.org
Subject: Re: [BUG sparc64] 2.6.16-git6 broke X11 on Ultra5 with ATI Mach64
From: David Miller <davem@...emloft.net>
Date: Thu, 27 Jul 2006 18:13:56 -0700 (PDT)
> If the process actually tries to write to the mapping, the page fault
> path will set the two bits that actually enable writes, namely the
> HW-writable bit and the SW-dirty bit.
>
> This occurs when pte_mkdirty() is called on the PTE during the
> execution of mm/memory.c:handle_pte_fault(), right here:
>
> if (write_access) {
> if (!pte_write(entry))
> return do_wp_page(mm, vma, address,
> pte, pmd, ptl, entry);
> entry = pte_mkdirty(entry);
> }
>
> pte_write() will return true, since the SW-writable bit is set. So we
> don't should not invoke do_wp_page(), and we'll just set the dirty bit
> on the existing PTE.
I just confirmed that this is working properly with a debugging
patch included below.
Mikael, can you put this debugging patch into a kernel that exhibits
the problem and post all the "FAULT: " debugging messages that appear
in your kernel log when the problem happens?
Thanks a lot.
diff --git a/mm/memory.c b/mm/memory.c
index 109e986..b129ae4 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -2270,6 +2270,12 @@ static inline int handle_pte_fault(struc
spinlock_t *ptl;
old_entry = entry = *pte;
+#if 1
+ if (pte_val(old_entry) & _PAGE_E_4U) {
+ printk("FAULT: write(%d) old_entry[%016lx]\n",
+ write_access, pte_val(old_entry));
+ }
+#endif
if (!pte_present(entry)) {
if (pte_none(entry)) {
if (!vma->vm_ops || !vma->vm_ops->nopage)
@@ -2311,6 +2317,12 @@ static inline int handle_pte_fault(struc
flush_tlb_page(vma, address);
}
unlock:
+#if 1
+ if (pte_val(old_entry) & _PAGE_E_4U) {
+ printk("FAULT: After, entry[%016lx]\n",
+ pte_val(entry));
+ }
+#endif
pte_unmap_unlock(pte, ptl);
return VM_FAULT_MINOR;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists