From: Gurudas Pai <gurudas.pai@xxxxxxxxxx> Date: Tue, 22 Oct 2013 18:18:18 -0700 > On 10/09/2013 12:18 PM, David Miller wrote: >> From: Gurudas Pai <gurudas.pai@xxxxxxxxxx> >> Date: Thu, 03 Oct 2013 19:07:11 -0700 >> >>> And run echo 1000000 > /proc/sys/vm/nr_hugepages couple of >>> times. >> You're running the machine out of memory and stressing the >> setup path of the hugepage subsystem a lot. >> >> This looks entirely different from the other crash/lockup, >> in that there it looked like a cpu died with interrupts >> disabled and thus wasn't responding even to cross calls. >> >> This really isn't in a format I can look into, sorry. > Following change fixes the issue for me, (this was removed by > 759496ba6407c6994d6a5ce3a5e74937d7816208), not very sure how. > > diff -Nrup arch/sparc/mm/fault_64.c /tmp/fault_64.c > --- arch/sparc/mm/fault_64.c 2013-10-22 20:10:04.302411223 -0400 > +++ /tmp/fault_64.c 2013-10-22 20:10:19.593410899 -0400 > @@ -427,6 +427,7 @@ good_area: > goto bad_area; > } > > + flags |= ((fault_code & FAULT_CODE_WRITE) ? FAULT_FLAG_WRITE : 0); > fault = handle_mm_fault(mm, vma, address, flags); > > if ((fault & VM_FAULT_RETRY) && fatal_signal_pending(current)) The code block right above that sets the write flag when necessary. I think you're just changing the timing and avoiding a race of some sort, it's the only thing that makes any sense. -- To unsubscribe from this list: send the line "unsubscribe sparclinux" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
