Hi Malek,

I find this statement puzzling: "before the functional access completes". A 
functional access is purely a chain of function calls that complete in 0 time. 
How can anything happen before it completes?

Thanks,

Andreas

From: Malek Musleh <[email protected]<mailto:[email protected]>>
Reply-To: gem5 users mailing list 
<[email protected]<mailto:[email protected]>>
Date: Thursday, 1 August 2013 16:38
To: gem5 users mailing list <[email protected]<mailto:[email protected]>>
Subject: [gem5-users] Functional Accesses Failing in Ruby

Hi,

I am running into a problem with one of my simulations where a functional read 
accss is failing. It is failing in this case because as the RubySystem is 
handling the functional accesses, it checks all the controllers in the system 
to determine which controllers have the block with the necesary permissions 
(RW/RO) and which have unavailable (I/BUSY).

For this specific case, the block is only valid in one cache, and is at the tme 
in 'M' state which has RW permission. Then, a L1_Replacement event is triggered 
in between the LOAD on M, and before the functional access completes, such that 
when the ruby system checks, it only finds one copy of the block, that copy 
being in MI (BUSY) state as it is being written back.

Searching the list, it looks like this is a general (although rare) problem 
that can occur due to functional accesses coexisting with timing accesses:

http://www.mail-archive.com/[email protected]/msg02126.html

In solving that problem, the access permission of the WB state was changed to 
allow read permissions, but I am hesitant about doing that for the MI state in 
the MOESI_CMP_directory protocol, as it might have other negative effects.

I am not using the latest latest dev repo (about a couple of months old), and I 
have made changes to the code, not any of which affects this behavior, it just 
exposed the problem.

I have noticed a few others on the list have experienced similar problems, but 
no solution/response was ever posted.

Any body have a better/cleaner idea than to change the access permissions of 
the MI State?

Below is a snippet of the protocol trace/RubySystem flag:

  2499502566500   0    L1Cache                Load      M>M      [0x7510000, 
line 0x7510000]
  2499527076000   0    L1Cache      L1_Replacement      M>MI     [0x7510000, 
line 0x7510000]
  2499527078000   0    L2Cache             L1_PUTX    ILX>ILXW   [0x7510000, 
line 0x7510000]
  2499527082000   0    L1Cache  Writeback_Ack_Data     MI>I      [0x7510000, 
line 0x7510000]
  2499527084000   0    L2Cache      L1_WBDIRTYDATA   ILXW>M      [0x7510000, 
line 0x7510000]
  2499530130500   0        Seq               Begin       >       [0x7510000, 
line 0x7510000] LD
  2499530132000   0    L1Cache                Load      I>IS     [0x7510000, 
line 0x7510000]
  2499530134000   0    L2Cache             L1_GETS      M>OO     [0x7510000, 
line 0x7510000]
  2499530136000   0        Seq                Done       >       [0x7510000, 
line 0x7510000] 11 cycles
  2499530136000   0    L1Cache      Exclusive_Data     IS>M_W    [0x7510000, 
line 0x7510000]
  2499530138000   0    L2Cache   Exclusive_Unblock     OO>ILX    [0x7510000, 
line 0x7510000]
  2499530161000   0    L1Cache         Use_Timeout    M_W>M      [0x7510000, 
line 0x7510000]
  2499531935500   0        Seq               Begin       >       [0x7510000, 
line 0x7510000] LD
  2499531937000   0        Seq                Done       >       [0x7510000, 
line 0x7510000] 3 cycles
  2499531937000   0    L1Cache                Load      M>M      [0x7510000, 
line 0x7510000]
2499663708000: system.ruby: Functional Read request for [0x7510000, line 
0x7510000]
2499663888000: system.ruby: Functional Read request for [0x7510000, line 
0x7510000]
  2499664653000   0    L1Cache      L1_Replacement      M>MI     [0x7510000, 
line 0x7510000]
2499664661500: system.ruby: Functional Read request for [0x7510000, line 
0x7510000]
fatal: Ruby functional read failed for address 0x7510000


Malek

-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.
_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to