Here is the diff that Ke Meng suggested in his bug report.
o3_fix.diff
Description: Binary data
On Jan 14, 2008, at 11:33 AM, Kevin Lim wrote:
You are correct with this bug fix. I had been having issues replicatingthe problem earlier, but after working with Rick this is indeed thecase. We will be sure to include the bug fix in the next release. Thanksfor your hard work, it would have been difficult to spot this bug without you! Kevin KE MENG wrote:Well, it seems this is most likely caused by a bug I reported for b3. The url ishttp://www.m5sim.org/flyspray/task/287 And it seems the problem is not corrected in b4. ----------------------------------------Date: Wed, 9 Jan 2008 15:25:28 -0800 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: [m5-users] ALPHA SE Something is wrong with sqrtt CC: m5-users@m5sim.org To clarify, I set opLat=24 and issueLat=12 for FloatSqrt in FuncUnitConfig.py in order to fix the problem. -Rick Rick Strong wrote:I think you may be right about the latency. I went intosrc/cpu/o3/FuncUnitConfig.py and set the latency of FloatSqrt to 12,and it appears to work. I hope that points someone in the right direction and towards a solution. -Rick Kevin Lim wrote:Hi Rick,There may be an issue with the CPU thinking there's no activity leftdue to the long latency of the instruction, and then not waking upproperly when the instruction completes. I'm not sure why it'd be on that instruction in particular though. I'm going to try your exampleand see if I can get some more information about why it might bedoing this. This may take me some time as I don't have a clean up to date tree at the moment. Could you send me your exact command line,as well as any diffs on any of the configuration files you made? In the meantime, try this: in your configuration file where youselect the O3CPU (most likely Simulation.py if you're just using ourdefault configs), try setting the parameter "activity" to 1. This should (hopefully) prevent the O3CPU from going to sleep if it's inactive. If the program runs properly as a result, then this is most likely the culprit. You may get very minor statistics differences if you set this to 1. Kevin Rick Strong wrote:Hi all,I have been tracking down a problem with resuming a few benchmarkswhich include (fma3d, ammp, apsi, mgrid, and others) at certaincheckpoints. The culprit appears to be a sqrtt (FloatSqrt) operationthat gets stuck at the head of the queue and stalls the detailedmodel (O3CPU). If I run the benchmark in AtomicSimpleCPU there is no problem. I have confirmed that sqrtt is at the head of the queue in four samples (two in ammp and two in apsi). The simulation ends with("Exiting @ cycle 9223372036854775807 because simulate() limit reached.") . The same symptoms are seen in other benchmarkssuffering a similar phenomena and I guess that sqrtt may also be the culprit. If anyone has some insight on what might be happening, itwould be appreciated. -Rick _______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users_______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users_________________________________________________________________Express yourself instantly with MSN Messenger! Download today it's FREE!http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users_______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________ m5-users mailing list m5-users@m5sim.org http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
