On Sat, 10 Apr 2010, Helge Deller wrote: > Nevertheless, on my B2000 (32bit, SMP, 2.6.32.2 kernel) I still do see the minifail bug. > The only difference seems to be, that the minifail3 program doesn't get stuck any > more. It still crashes though from time to time... There are some issues with your minifail3.c testcase. The fork'd child shouldn't do any I/O and it should exit using _exit(0). Otherwise, it can corrupt the I/O structures of the parent. I'm not sure that this is the issue on your B2000, but it's worth a try. The testcase when modified as above doesn't crash on my c3750 (32bit, UP, 2.6.32.2 kernel). I found in debugging this testcase that the crash was always associated with the stack region for thread_run. I put a big loop in thread_run. The index for the loop when compiled at -O0 is constantly being saved and restored on the stack. I found that crashes occured after many iterations of the loop. Nothing else was going on. The COW discussion convinced me that cache flushing was the problem. The fork (clone) syscall causes the stack region used by thread_run to become COW'd. When thread_run is scheduled, the loop caused an instant COW break and stack corruption. The state of the stack region generally returned to its state before the fork. If the above doesn't fix the testcase on your B2000, there must be some difference and other PA8000 machines. 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
