[PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Benjamin Herrenschmidt
This patch reworks ptep_set_access_flags() and the callers so that the comparison to the old PTE is done inside that function, which then returns wether an update_mmu_cache() is needed. That allows fixing the sun4c situation where update_mmu_cache() needs to be forced, always. Signed-off-by:

[BUG sparc64] 2.6.22-rc broke X on Ultra5

2007-05-22 Thread Mikael Pettersson
Just a FYI: 2.6.21 works fine on my Ultra5, but with 2.6.22-rc the X server (from Aurora 2) fails to mmap() the PCI frame buffer (atyfb). I noticed a lot of PCI-related changes both in `dmesg' and /var/log/Xorg.0.log between 2.6.21 and 2.6.22-rc, so my guess is that PCI resources get broken

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Hugh Dickins
On Tue, 22 May 2007, Benjamin Herrenschmidt wrote: This patch reworks ptep_set_access_flags() and the callers so that the comparison to the old PTE is done inside that function, which then returns wether an update_mmu_cache() is needed. That allows fixing the sun4c situation where

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Mark Fortescue
Hi Benjamin, I have just tested this patch on my Sun4c Sparcstation 1 using my 2.6.20.9 test kernel without any problems. Thank you for the work. Regards Mark Fortescue. On Tue, 22 May 2007, Benjamin Herrenschmidt wrote: This patch reworks ptep_set_access_flags() and the callers

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Benjamin Herrenschmidt
Looks pretty good to me. There was a minor build error in x86 (see below), and ia64 is missing (again see below). I've now built and am running this on x86, x86_64 and powerpc64; but I'm very unlikely to be doing anything which actually tickles these changes, or Andrea's original

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Tom \spot\ Callaway
On Wed, 2007-05-23 at 08:59 +1000, Benjamin Herrenschmidt wrote: Well, I don't know which is why I'm waiting for Tom Callaway to test. Davem mentioned update_mmu_cache only though when we discussed the problem initially. Mark already tested it and said it worked for him. This is sufficient

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Benjamin Herrenschmidt
On Tue, 2007-05-22 at 22:52 +0100, Mark Fortescue wrote: Hi Benjamin, I have just tested this patch on my Sun4c Sparcstation 1 using my 2.6.20.9 test kernel without any problems. Thank you for the work. Wow, there is more than one user of these still ! :-) Cheers, Ben. - To

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Benjamin Herrenschmidt
On Tue, 2007-05-22 at 14:53 -0700, David Miller wrote: From: Mark Fortescue [EMAIL PROTECTED] Date: Tue, 22 May 2007 22:52:13 +0100 (BST) Hi Benjamin, I have just tested this patch on my Sun4c Sparcstation 1 using my 2.6.20.9 test kernel without any problems. Thank you for the

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Hugh Dickins
On Wed, 23 May 2007, Benjamin Herrenschmidt wrote: Would the __changed __dirty architectures (x86, x86_64, ia64) be better off saying __changed = __dirty pte_same? I doubt it's worth bothering about. I'd say let gcc figure it out :-) No, I wasn't meaning the optimization, but the

Re: [PATCH/RFC] Rework ptep_set_access_flags and fix sun4c

2007-05-22 Thread Benjamin Herrenschmidt
On Wed, 2007-05-23 at 05:03 +0100, Hugh Dickins wrote: No, I wasn't meaning the optimization, but the significance of the boolean __changed that's returned. If ptep_set_access_flags does not change the pte (because !dirty or !safely_writable or whatever that arch calls it), then ideally it