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 [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
