Re: 2.6.13-rc3-mm3

[Richard Purdie <rpurdie@rpsys.net>]

On Mon, 2005-08-01 at 15:19 -0700, Christoph Lameter wrote:
> On Mon, 1 Aug 2005, Richard Purdie wrote:
> > That number rapidly increases and so it looks like something is failing
> > and looping...
> 
> Maybe we better restore the pte flags changes the way they were if 
> CONFIG_ATOMIC_TABLE_OPS is not defined. Try this instead. If this works 
> then we need two different handle_pte_fault functions to get rid of the 
> macro mess:
>
> +#ifdef CONFIG_ATOMIC_TABLE_OPS
>  	/*
>  	 * If the cmpxchg fails then another processor may have done
>  	 * the changes for us. If not then another fault will bring
> @@ -2106,6 +2107,11 @@
>  	} else {
>  		inc_page_state(cmpxchg_fail_flag_update);
>  	}
> +#else
> +	ptep_set_access_flags(vma, address, pte, entry, write_access);
> +	update_mmu_cache(vma, address, entry);
> +	lazy_mmu_prot_update(entry);
> +#endif

This locks the system up after the "INIT: version 2.86 booting" message.
SysRq still responds but that's about it.

The system also feels/looks extremely sluggish after this change (more
looping?).

With your previously suggested change:

        } else {
                inc_page_state(cmpxchg_fail_flag_update);
+               set_pte_at(mm, address, pte, new_entry);
        }
 
the system proceeds past INIT and boots normally but X still locks up...

Richard

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