Re: 2.6.13-rc3-mm3

[Richard Purdie <rpurdie@rpsys.net>]

On Mon, 2005-08-01 at 16:16 -0700, Christoph Lameter wrote:
> Hmmm. this should have returned the behavior to normal. Ah. Need to use 
> new_entry instead of entry. Try this (is there any way that I could get 
> access to the sytem? I am on IRC (freenode.net nick o-o) or on skype).
>  
> +#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, new_entry, write_access);
> +	update_mmu_cache(vma, address, new_entry);
> +	lazy_mmu_prot_update(new_entry);
> +#endif

With this applied, the system boots then X locks up in memcpy as before.
The cmpxchg_fail_flag_update remains at zero but given the above patch,
that's to be expected...

Sadly, remote access to the system isn't really much use as there is no
compiler on the device and flashing a new kernel is a manual procedure
involving pressing buttons.

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/