Hey Brad, Thanks for the suggestions. The Protocol Trace flag looks really promising. It'd be very nice to get everything in , but I'm just a little worried about tweaking that if these RubyCycle counts are used for anything other than annotation. I'll take a strong look at starting to get that implemented though.
As for the DMA problem, I haven't encountered the issue in the new round of patches you committed (so good job!). I have the issue that I had when I rolled back patches (which is the deadlock). On Wed, Mar 23, 2011 at 5:07 PM, Beckmann, Brad <[email protected]>wrote: > 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 > -- - Korey _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
