On Sun, Mar 14, 2010 at 9:10 PM, John David Anglin <dave@xxxxxxxxxxxxxxxxxx> wrote: > On Fri, 12 Mar 2010, John David Anglin wrote: > >> The other issue is r16. I'm thinking we may need to reload r16 as the >> context may change if we schedule, etc. If this checking is broken, it >> would break the LWS assumptions. > > This theory is shotdown. The patch below possibly helps a bit but it > doesn't resolve the minifail bug. The intention of the last couple of > hunks is to return to the right place if cr30 changes as a result of > scheduling. Thanks for testing this out. > With more debugging, it seems that this is a clone mmap copy issue. > Normally, the forked child doesn't see any non-zero data in the > stack region allocated by pthread_create. However, if it does, > the thread invariably dies and the stack region is corrupt after > the fork. > > I guess I said this before ;( After some of my own testing I think this is all MMU related, but I can't prove it yet. I'm pouring through as much kernel code as I can right now to determine what is going wrong at the time of the clone, and I see at least one bug that I'm investigating regarding return addresses. Cheers, Carlos. -- To unsubscribe from this list: send the line "unsubscribe linux-parisc" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
