Hi Korey, A few comments:
- The difference in time is because the sequencer prints out the RubyCycle count for the issue time while the tick count is the global curTick value. Now that Ruby uses DPRINTFs, I think it makes sense to move all those ruby print outs to ticks. I actually have that on my long todo list, but I'm sure I won't get to it soon. If you want to go ahead and make the conversion, please do. - I'm pretty sure that Invalid range error is completely unrelated. Instead that sort of error is caused when you try to print out a MachineType variable, but the value has not been set. Typically that happens to network messages where the enqueue operations don't fill in all the fields. - Overall, when tracking down a deadlock issue, start with the protocol trace and track down what is happening with the particular address in question. From there, you can typically get an idea of what to zero in on. - By the way, have you had a chance to confirm that my patches from this weekend fixed your previous dma problem? Brad > -----Original Message----- > From: [email protected] [mailto:[email protected]] > On Behalf Of Korey Sewell > Sent: Wednesday, March 23, 2011 12:43 PM > To: M5 Developer List > Subject: Re: [m5-dev] Debugging Ruby "Deadlocks"... > > This problem may be related to my earlier post i sent today about > "Debugging Ruby Deadlocks", but when adding the "RubyQueue" traceflag > for 32 cores you get this error: > "build/ALPHA_FS_MOESI_CMP_directory/m5.opt -d ruby_opt/ --trace- > flags=RubyQueue configs/example/ruby_fs.py -b fft_64t_base -n 1 ... > panic: Invalid range for type MachineType @ cycle 793500 > [MachineType_to_string:build/ALPHA_FS_MOESI_CMP_directory/mem/pro > tocol/MachineType.cc, > line 42] > Memory Usage: 2312860 KBytes > For more information see: http://www.m5sim.org/panic/f419fb7 > Program aborted at cycle 793500 > Aborted > " > > I thought this was solved a while ago by a previous patch but it seems to be > an issue again. Is it something in the SLICC that isnt being defined properly > when the core count is large? If anybody has any thoughts , please let me > know so we can patch it and push the changeset in the tree. > > Note: I dont get this problem when running for just 1 core. > -- > - Korey > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
