On Thu, 11 Mar 2010, John David Anglin wrote: > I am 95% certain that the bug has to do with the clone implementation > and scheduling. I have attached another version of the minifail test. > The loops after the fork and pthread_create calls are to isolate these > syscalls. Typically, I see something like: Here's another idea. In entry.S, there are some tricky tests to determine whether to do signals and reschedule. Based on testing, I'm not sure that cr30 is always valid (e.g., external interrupt at boot) when we get to intr_check_resched and intr_check_sig. 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. Thoughts? Dave -- J. David Anglin dave.anglin@xxxxxxxxxxxxxx National Research Council of Canada (613) 990-0752 (FAX: 952-6602) -- 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
