Did this diff ever make it into the tree? Was it correct? Nate
On Wed, May 13, 2009 at 9:06 PM, Rick Strong <[email protected]> wrote: > Starring at code and traces, it appears that a fetch attempt occurs > after waiting for a long latency icache block. The rest of the cpu > has nothing to do because a jump instruction executed that caused the > rob to have multiple instructions flushed. The L1 cache unblocks > because it satisfied an icache request for the cpu for one of the > squashed instructions. The fetch unit now fetches to new PC of the > target of > the last jump instruction. An itbmiss occurs and fetchStatus[tid] == > TrapPending. Fetch now deactivates itself but the rest of the core's stages > are deactivated. The trap is never handled. Now I see the note: > > "// Send the fault to commit. This thread will not do anything > // until commit handles the fault. The only other way it can > // wake up is if a squash comes along and changes the PC. > " > > What happens if commit currently is not an activated stage? Would the > result be the forever sleeping CPU I see here? The following change > fixes the problem. Ignore the first diff set as it relates to mesh > patch. The second part reschedules the Commit Stage that the fault will > be handled. I hope this helps someone. > > --- a/src/cpu/o3/fetch_impl.hh > +++ b/src/cpu/o3/fetch_impl.hh > @@ -627,7 +627,7 @@ > PacketPtr data_pkt = new Packet(mem_req, > MemCmd::ReadReq, > Packet::Broadcast); > data_pkt->dataDynamicArray(new uint8_t[cacheBlkSize]); > - > + data_pkt->setSrc(cpu->cpuId()); > cacheDataPC[tid] = block_PC; > cacheDataValid[tid] = false; > > @@ -1266,6 +1266,7 @@ > DPRINTF(Fetch, "[tid:%i]: Blocked, need to handle the > trap.\n",tid); > > fetchStatus[tid] = TrapPending; > + cpu->activateStage(O3CPU::CommitIdx); > status_change = true; > > DPRINTF(Fetch, "[tid:%i]: fault (%s) detected @ PC %08p", > > > Korey Sewell wrote: >> Hi Rick, >> looks like the activity count went to 0. In the O3, if the activity >> count is 0 it will sleep the CPU until something wakes it up. >> >> I'm thinking that usually what happens is that if the CPU is waiting >> for a long cache miss, it will just sleep the CPU and then when the >> cache event completes it will update the activity count. >> >> Maybe what's happening is the ITB miss happens, but then it never gets >> to the code in fetch where the activity count is updated, thus >> sleeping the CPU indefinitely...??? >> >> > > _______________________________________________ > m5-users mailing list > [email protected] > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users > > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
