I used my backport of the print_eip patch to understand where the lock
happens and it happens always in the same place.
The kernel is started by a do_page_fault() that then run a do_no_page()
and continue with ret_from_sys_call. Then the kernel lock after the
RESTORE_ALL before signal_return: in entry.S.
Make sense to you? What' s trying to do the do_no_page()?
We tried memtest86.bin and it reported no ram hardware errors...
Andrea[s] Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu