Is there an attached patch I should be running or did it get bounced by m5-dev? If so, can you send it directly to me rather through m5-dev?
On Wed, Mar 30, 2011 at 8:26 PM, Beckmann, Brad <[email protected]> wrote: > Hi Korey, > > For the first trace, it looks like the L2 cache is either miscounting the > number of valid L1 copies, or there is an error with the ack arithmetic. We > are going to need a bit more information to figure out where the exact > problem is. Could you apply the attached patch and reply with the new > protocol trace? Thanks. > > For the second trace, you should be able to get the offending address by > simply attaching GDB to the aborted process. Without knowing which address > to zero in on, it is the proverbial "finding a needle in a haystack". > > Thanks, > > Brad > > > >> -----Original Message----- >> From: [email protected] [mailto:[email protected]] >> On Behalf Of Korey Sewell >> Sent: Tuesday, March 29, 2011 10:15 AM >> To: M5 Developer List >> Subject: Re: [m5-dev] Running Ruby w/32 Cores >> >> Thanks for the response Brad. >> >> The 1st trace has 1 L2 and the 2nd has 1 L2 (i had a typo in the original >> email). >> >> For each trace, I attach the stdout/stderr (*.out) and then the protocol >> trace >> (*.prottrace). >> >> Also, in the 1st trace, the offending address is clear and I isolate that in >> the >> protocol trace file provided. However, in the 2nd trace, it's unclear >> (currently) >> which access caused it to fail so I took the whole protocol trace file and >> gzip'd >> it. >> >> My current lack of expertise in SLICC limits me a bit, but I'd like to be >> more >> helpful in debugging so if there is anything that I can look into (or run) >> on my >> end to expedite the process, please advise. In the interim, I'll try to >> locate >> the exact address that's breaking trace 2 and then hopefully repost that. >> >> Thanks! >> >> -Korey >> >> On Tue, Mar 29, 2011 at 12:02 PM, Beckmann, Brad >> <[email protected]> wrote: >> > Hi Korey, >> > >> > I believe both of these issues should be easy to solve once we have a >> protocol trace leading up to the error. If you could create such a trace and >> send it to the list, that would be great. Just zero in on the offending >> address. >> > >> > Thanks, >> > >> > Brad >> > >> > >> >> -----Original Message----- >> >> From: [email protected] [mailto:m5-dev- >> [email protected]] On >> >> Behalf Of Korey Sewell >> >> Sent: Tuesday, March 29, 2011 8:11 AM >> >> To: M5 Developer List >> >> Subject: [m5-dev] Running Ruby w/32 Cores >> >> >> >> Hi All, >> >> I'm still having a bit of trouble running Ruby with 32+ cores. I am >> >> experimenting w/configs varying the l2-caches. The runs seems to >> >> generate various errors in the SLICC. >> >> >> >> Has anybody seen these or have any insight to how to start solving >> >> these type of issues (posted below)? >> >> ========= >> >> The command line and errors are as follows: >> >> (1) 32 Cores and 32 L2s >> >> build/ALPHA_FS_MOESI_CMP_directory/m5.opt >> >> configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- >> >> l2caches=32 ... >> >> info: Entering event queue @ 0. Starting simulation... >> >> Runtime Error at MOESI_CMP_directory-dir.sm:155, Ruby Time: 38279: >> >> assert failure, PID: 5990 >> >> press return to continue. >> >> >> >> Program aborted at cycle 19139500 >> >> Aborted >> >> >> >> (2) 32 Cores and 1 L2 >> >> build/ALPHA_FS_MOESI_CMP_directory/m5.opt >> >> configs/example/ruby_fs.py -b FftBase32 -n 32 --num-dirs=32 --num- >> >> l2caches=32 ... >> >> fatal: Invalid transition >> >> system.l1_cntrl0 time: 349075 addr: [0x16180, line 0x16180] event: Ack >> state: >> >> MM @ cycle 174537500 >> >> >> [doTransitionWorker:build/ALPHA_FS_MOESI_CMP_directory/mem/protoc >> >> ol/L1Cache_Transitions.cc, >> >> line 477] >> >> Memory Usage: 2316756 KBytes >> >> For more information see: http://www.m5sim.org/fatal/23f196b2 >> >> ======== >> >> >> >> Please let me know if you do...Thanks! >> >> >> >> -- >> >> - 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 > > -- - Korey _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
