From: "Bernhard R. Link" <brlink@xxxxxxxxxx> Date: Sun, 14 Feb 2010 12:43:34 +0100 > * Bernhard R. Link <brlink@xxxxxxxxxx> [100213 18:31]: >> The process itself is shown as using the full cpu (i.e. 100% in top). >> Attaching gdb, strace or ltrace causes those to hang. >> The process cannot be killed, not even by kill -KILL. >> After this process is thus stuck, other processes seem to get then >> problems too and rebooting needs reboot -n -f to actually happen). >> >> What can I do to get narrow this down? Retry with a vanilla kernel? >> Find out at what operation the script (run by bash) starts to hang? > > Looking at some of the addresses and a disassembled kernel, that seems > to be in sparc64_realfault_common within sparc64_realfault_common > within for example a call in setup_frame32 (inlined in do_signal32), > so I guess this is related to the signal stack misalignment and will > retest once I have a kernel with those patches applied. It has nothing to do with that. For some reason the fault isn't being resolved by the fault handler, so we keep faulting forever on the same instruction. -- 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
