----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://reviews.gem5.org/r/2740/#review6073 -----------------------------------------------------------
In general this seems fine. Normally I’d consider it "user error" to use a m5 quiesce instruction with a 0 cycle delay parameter normally though. Is this x86 improperly using quiesce instructions? How did this case come up? Thanks. - Mitch Hayenga On April 16, 2015, 4:48 p.m., Emilio Castillo wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://reviews.gem5.org/r/2740/ > ----------------------------------------------------------- > > (Updated April 16, 2015, 4:48 p.m.) > > > Review request for Default. > > > Repository: gem5 > > > Description > ------- > > The O3CPU blocks the Fetch when it sees a quiesce instruction (IsQuiesce > flag). > When the inst. is executed, a quiesce event is created to reactivate the > context > and unblock the Fetch. > > If the quiesceNs or quiesceCycles are called with a value of 0, the > QuiesceEvent will not be created and the Fetch stage will remain blocked. > > > Diffs > ----- > > src/sim/pseudo_inst.cc 8a7285d6197e > > Diff: http://reviews.gem5.org/r/2740/diff/ > > > Testing > ------- > > Boot a Linux Kernel with X86, Out of Order & Ruby. > When the kernel boots and calls the shell, quiesce instructions with 0ns are > executed deadlocking the O3 cpu. > > > Thanks, > > Emilio Castillo > > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
