Re: [Gems-users] Trouble with MOESI_CMP_NUCA

[Bradford Beckmann <beckmann@xxxxxxxxxxx>]

That's right I did put an assertion there.  Good so you have
COLLECTOR_HANDLES_OFF_CHIP_REQUESTS set to true.

Well on a second, closer look at your debug output, I'm afraid this may be
a more complicated problem.  The problem is that the L1_GETS and
PERSISTENT_GETS requests are not being received by all L2 Caches.  This
leads me to believe that the network is clogged or something really weird
is happening in the L2 cache mapping functions.  This is really confusing
because the protocol works fine when I run it.

I'm going to need more debugging information.  Please do the following:

- In the action "s_sendSecondPhaseRequest" in the file
MOESI_CMP_NUCA-col.sm add the following two lines:

        out_msg.Destination := in_msg.RequestDest;
        out_msg.RequestsPerRound := out_msg.Destination.count();
        DEBUG_EXPR(out_msg.Destination);       // <-add line
	DEBUG_EXPR(out_msg.RequestsPerRound);  // <-add line
        out_msg.RetryNum := in_msg.RetryNum;
        out_msg.MessageSize := in_msg.MessageSize;

- Then in simics run the following two commands before the 'c' command

ruby0.debug-verb high
ruby0.debug-filter l

- Send me the debug output for this transition:

314527   0   3  Collector        Issue_L2_Get  Col_P>Col_P
[0x30a840, line 0x30a840]

Brad



On Fri, 7 Apr 2006, Steve Barrus wrote:

> Actually, I have COLLECTOR_HANDLES_OFF_CHIP_REQUESTS set to true.
> I tried setting it to false, but there appears to be an assertion in
> config/RubyConfig.C (line 141) that requires it to be set to true.
>
> -Steve
>
> On Fri, Apr 07, 2006 at 04:10:15PM -0500, Bradford Beckmann wrote:
> >
> > Steve,
> >
> > It appears that you have the configuration variable
> > "COLLECTOR_HANDLES_OFF_CHIP_REQUESTS" set to false.  Is that correct?
> >
> > When running the MOESI_CMP_NUCA with the DNUCA cache block allocation
> > policy, i.e. "g_NUCA_PREDICTOR_CONFIG == DNUCA", the
> > "COLLECTOR_HANDLES_OFF_CHIP_REQUESTS" should be set to true as specified
> > by http://www.cs.wisc.edu/gems/doc/wiki/moin.cgi/CMP-NUCA
> >
> > However, the persistent requests mechanism should prevent the deadlock.
> > I'm curious to see what happens to "line 0x30a840" between cycle 314953
> > and 400001.
> >
> > Brad
> >
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>