Thanks, Avadh. I don't believe the process ever wakes up again. I left it running overnight and the 'time' field didn't increase by even a fraction of a second, so I think it never recovers.
I was trying to wait for some simulations to finish up, but it looks like they're taking way longer than is useful. I think I'll kill them and try out the patch and let you know what happens. On Wed, Aug 15, 2012 at 1:21 PM, avadh patel <[email protected]> wrote: > > On Wed, Aug 15, 2012 at 8:16 AM, Paul Rosenfeld <[email protected]>wrote: > >> Hello all, >> >> I'm getting some new and strange behavior and I was wondering if anyone >> else has experienced this. Typically, I run a bunch of simulations in >> parallel using run_bench.py and running from a checkpoint with the >> -snapshot option (i.e., no writebacks to the disk image). >> >> Up until recently, I haven't had any problems. But now that I'm trying to >> run a bunch of simulations, I'm getting into a state where some of the qemu >> processes will go into sleep mode (i.e., they show up as status 'S' in >> htop) and they never get back into the running state. They're using no CPU >> time and just kind of sitting around. >> >> Do they ever wake up even for fraction of a second? If they do then it > might have issue related to all CPUs in 'halted' mode. Try following patch > to see if this happens or not. > > - Avadh > > diff --git a/qemu/cpu-exec.c b/qemu/cpu-exec.c > index f10b207..70d4ec3 100644 > --- a/qemu/cpu-exec.c > +++ b/qemu/cpu-exec.c > @@ -238,16 +238,6 @@ int sim_cpu_exec(void) > /* #define DECLARE_HOST_REGS 1 */ > /* #include "hostregs_helper.h" */ > int ret, interrupt_request; > - CPUState *env1; > - > - uint8_t all_halted = 1; > - for(env1 = first_cpu; env1 != NULL; env1 = env1->next_cpu) > - if (cpu_halted(env1) != EXCP_HALTED) { > - all_halted = 0; > - break; > - } > - if(all_halted) > - return EXCP_HALTED; > > > /* first we save global registers */ > > Has anyone else had something like this happen? Is there a way to even >> debug such a problem? Is there a chance this behavior could somehow be >> caused by the -snapshot option? >> >> Thanks, >> Paul >> >> _______________________________________________ >> http://www.marss86.org >> Marss86-Devel mailing list >> [email protected] >> https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel >> >> >
_______________________________________________ http://www.marss86.org Marss86-Devel mailing list [email protected] https://www.cs.binghamton.edu/mailman/listinfo/marss86-devel
