lkml.org 
[lkml]   [2005]   [Aug]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: 2.6.13-rc3-mm3
From
Date
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/

\
 
 \ /
  Last update: 2005-08-02 01:36    [W:0.414 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site