There could be other replacements in progress, I suppose, that could raise this
problem. It might be OK to simply remove the assertion altogether, though I
cannot guarantee that will not break Ruby in strange and mysterious ways. The
other way would be to force the system (maybe just the local L1) to quiesce
before starting the flush.
Regards,
Dan
Mladen Nikitovic wrote:
> Hi,
>
> Flushing of both I- and D-cache seems to go fine at the moment (sets
> first then assoc). There was an error in the second loop where variable
> i was used instead of j.
>
> However, it looks like the actions triggered by the protocol causes
> problems. INVALIDATIONS are associated with the L1_Replacement Event and
> it seems to me that a deallocation action is triggered from there. But,
> as you can see from the output below, something had gone wrong between
> sending the messages through the mandatory queue and the replacement
> event that is calling the deallocation function. From the code it
> appears as the line address has been changed, but I haven't written any
> code that changes it. Any ideas?
>
> flushDL1caches: going through row 244
> flushDL1caches: going through row 245
> flushDL1caches: going through row 246
> flushDL1caches: going through row 247
> flushDL1caches: going through row 248
> flushDL1caches: going through row 249
> flushDL1caches: going through row 250
> flushDL1caches: going through row 251
> flushDL1caches: going through row 252
> flushDL1caches: going through row 253
> flushDL1caches: going through row 254
> flushDL1caches: going through row 255
> flushIL1caches: Dcache flush done
> failed assertion 'isTagPresent(address)' at fn void
> CacheMemory<ENTRY>::deallocate(const Address&) [with ENTRY =
> L1Cache_Entry] in system/CacheMemory.h:451
> failed assertion 'isTagPresent(address)' at fn void
> CacheMemory<ENTRY>::deallocate(const Address&) [with ENTRY =
> L1Cache_Entry] in system/CacheMemory.h:451
> At this point you might want to attach a debug to the running and get to the
> crash site; otherwise press enter to continue
> PID: 18157
>
> This is the implementation of isTagPresent:
>
> // tests to see if an address is present in the cache
> template<class ENTRY>
> inline
> bool CacheMemory<ENTRY>::isTagPresent(const Address& address) const
> {
> assert(address == line_address(address));
> Index cacheSet = addressToCacheSet(address);
> int location = findTagInSet(cacheSet, address);
>
> if (location == -1) {
> // We didn't find the tag
> DEBUG_EXPR(CACHE_COMP, LowPrio, address);
> DEBUG_MSG(CACHE_COMP, LowPrio, "No tag match");
> return false;
> }
> DEBUG_EXPR(CACHE_COMP, LowPrio, address);
> DEBUG_MSG(CACHE_COMP, LowPrio, "found");
> return true;
> }
>
> Is there a possibility that the cache contents can change between the
> flushing (sending the messages) and the actual replacement action
> performed by the protocol? I currently cannot see how that would be
> possible but maybe you can.
>
> /M
>
> Dan Gibson wrote:
>
>> It looks like how I would implement the same functionality, though I don't know
>> which dimension -- sets or assoc -- comes first in the m_cache member var --
>> maybe the indexes are backwards? (I haven't checked the definition)
>>
>> Regards,
>> Dan
>>
>> Mladen Nikitovic wrote:
>>
>>> Will do that. Thanks. Just wondered if there was anything semantically
>>> wrong with the code. I'm thinking about the way I've created the message
>>> and the way I've extracted the address from the cache. Does that seem as
>>> a reasonable approach?
>>>
>>> I implemented the functions to extract the number of sets and ways and
>>> the address myself, there could be an error there. This is what I added
>>> to CacheMemory.h
>>>
>>> template<class ENTRY>
>>> inline
>>> int CacheMemory<ENTRY>::getCacheNumSets()
>>> {
>>> return m_cache_num_sets;
>>> }
>>>
>>> template<class ENTRY>
>>> inline
>>> int CacheMemory<ENTRY>::getCacheAssoc()
>>> {
>>> return m_cache_assoc;
>>> }
>>>
>>> template<class ENTRY>
>>> inline
>>> Address CacheMemory<ENTRY>::getAddress(int i, int j)
>>> {
>>> return m_cache[i][j].m_Address;
>>> }
>>>
>>> /M
>>>
>>> Dan Gibson wrote:
>>>
>>>
>>>> This is a vector/array bounds assertion. Apparently some code in flush is
>>>> accessing a Vector<L1Cache_Entry> with an offset too large for the specified
>>>> size of the vector. As a first step, track down places were vectors are indexed
>>>> in your call stack -- or better yet, attach gdb when you get the assertion and
>>>> pop the call stack a few times to find the right spot.
>>>>
>>>> Regards,
>>>> Dan
>>>>
>>>> Mladen Nikitovic wrote:
>>>>
>>>>
>>>>> I have reproduced the error and this is the message I get from
>>>>> Simics/GEMS when I try to do the flush:
>>>>>
>>>>>
>>>>> simics> c
>>>>> before flush (8023)
>>>>> failed assertion 'index < m_size' at fn TYPE& Vector<TYPE>::ref(int)
>>>>> [with TYPE = L1Cache_Entry] in ../common/Vector.h:168
>>>>> failed assertion 'index < m_size' at fn TYPE& Vector<TYPE>::ref(int)
>>>>> [with TYPE = L1Cache_Entry] in ../common/Vector.h:168
>>>>> At this point you might want to attach a debug to the running and get to the
>>>>> crash site; otherwise press enter to continue
>>>>> PID: 3981
>>>>> Warning: Interrupt key pressed more than once.
>>>>> Pressing it again will force Simics back to the command prompt.
>>>>> This may corrupt the running simulation.
>>>>> Try waiting for Simics to stop first.
>>>>> USER INTERRUPT: Interrupt key pressed multiple times.
>>>>> Returning to prompt.
>>>>> simics>
>>>>>
>>>>>
>>>>> Hopefully this can help someone to shed some light on this matter.
>>>>>
>>>>> Best Regards,
>>>>> Mladen
>>>>>
>>>>> Mladen Nikitovic wrote:
>>>>>
>>>>>
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> I'm trying to implement a function that flushes the L1 caches. You can
>>>>>> see from my previous posts that I have arrived at a solution that
>>>>>> involves some augmentation of protocol code etc. But, the final thing is
>>>>>> actually implementing the flush in the Sequencer, which was supposed to
>>>>>> be done be walking the I and D-cache entries and sending invalidation
>>>>>> request via the mandatory queue. I have tried to do that but the
>>>>>> simulation crashes when I try call the flush at the point of shutting
>>>>>> down one of the processors.
>>>>>>
>>>>>> Implementation-wise, is there anything in the following function that
>>>>>> should change?
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> Regards,
>>>>>> Mladen
>>>>>>
>>>>>> void Sequencer::flushL1caches(int cpu)
>>>>>> {
>>>>>> Time latency = SEQUENCER_TO_CONTROLLER_LATENCY;
>>>>>> CacheMsg Imsg, Dmsg;
>>>>>> int i,j, Iassoc, Dassoc, Isets, Dsets;
>>>>>>
>>>>>> Imsg.setType(CacheRequestType_INVALIDATE);
>>>>>> Dmsg.setType(CacheRequestType_INVALIDATE);
>>>>>>
>>>>>> Isets =
>>>>>> m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getCacheNumSets();
>>>>>> Dsets =
>>>>>> m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getCacheNumSets();
>>>>>>
>>>>>> Iassoc =
>>>>>> m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getCacheAssoc();
>>>>>> Dassoc =
>>>>>> m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getCacheAssoc();
>>>>>>
>>>>>> for(i=0; i<Isets; i++) {
>>>>>> for(j=0; i<Iassoc; j++) {
>>>>>>
>>>>>> Imsg.setAddress(m_chip_ptr->m_L1Cache_L1IcacheMemory_vec[m_version]->getAddress(i,j));
>>>>>>
>>>>>> m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(Imsg,
>>>>>> latency);
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> for(i=0; i<Dsets; i++) {
>>>>>> for(j=0; i<Dassoc; j++) {
>>>>>>
>>>>>> Dmsg.setAddress(m_chip_ptr->m_L1Cache_L1DcacheMemory_vec[m_version]->getAddress(i,j));
>>>>>>
>>>>>> m_chip_ptr->m_L1Cache_mandatoryQueue_vec[m_version]->enqueue(Dmsg,
>>>>>> latency);
>>>>>> }
>>>>>> }
>>>>>> }
>>>>>>
>>>>>> _______________________________________________
>>>>>> Gems-users mailing list
>>>>>> Gems-users@xxxxxxxxxxx
>>>>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>>>>>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>> _______________________________________________
>>>>> Gems-users mailing list
>>>>> Gems-users@xxxxxxxxxxx
>>>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>>>>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>> --
>>>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>>>>
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>> _______________________________________________
>>>> Gems-users mailing list
>>>> Gems-users@xxxxxxxxxxx
>>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>>>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>>>>
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Gems-users mailing list
>>> Gems-users@xxxxxxxxxxx
>>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>>>
>>>
>>>
>>>
>> --
>> http://www.cs.wisc.edu/~gibson [esc]:wq!
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Gems-users mailing list
>> Gems-users@xxxxxxxxxxx
>> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
>> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>>
>>
>>
>
>
> _______________________________________________
> Gems-users mailing list
> Gems-users@xxxxxxxxxxx
> https://lists.cs.wisc.edu/mailman/listinfo/gems-users
> Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
>
>
>
--
http://www.cs.wisc.edu/~gibson [esc]:wq!
------------------------------------------------------------------------
_______________________________________________
Gems-users mailing list
Gems-users@xxxxxxxxxxx
https://lists.cs.wisc.edu/mailman/listinfo/gems-users
Use Google to search the GEMS Users mailing list by adding "site:https://lists.cs.wisc.edu/archive/gems-users/"; to your search.
![[Computer Systems Lab]](https://www-auth.cs.wisc.edu/pics/csl_logo.gif){kind=logo}