Ok, I've had a chance to look at this. The reason completeDataAccess is called twice is that the first instance is for the previous instruction. It's data access comes back, allowing it to finish, and because it finished it fires off the next instruction. I'm assuming this is a subsequent microop of the same macroop since no fetch actually happens. Because there's no trip to memory and we don't wait for a call back, the next instruction is started in place without collapsing the existing stack frames. This can (and has) actually lead to problems where the subsequent instruction may change things unexpectedly out from under the previous instruction or earlier parts of the same instruction, and it also means the stack could theoretically grow without bound and, in the worst case, run out of space. This doesn't have anything to do with the assert, but it does explain completeDataAccess showing up twice.
The assert is, as you said, from NO_ACCESS skipping the call out to the memory system and going right to the code that finishes off execution of that instruction, surprising that code by never having left the Running state. Under any other circumstance, though, the CPU shouldn't be in the Running state, and if we just added that to the assert we wouldn't catch those bugs. What I think would be a better fix is to move the assert (but not the assignment to _status) up above the code that aggregates the components of a split packet and add pkt->req->getFlags().isSet(Request::NO_ACCESS) or something similar to the or. This isn't perfect because it asserts every time the function is called and not just once all the fragments (should be only two) are gathered, but it's safer and the overhead should be minimal. I think the reason this doesn't cause a problem for any other ISA is that, according to grep, no other ISA uses the NO_ACCESS flag. Gabe Gabe Black wrote: > Hi. I've done a little work enabling X86_FS with the timing CPU, but > there was a problem where a pointer to a packet was corrupted somehow > (if I remember correctly) and it died not very far in. As far as I know > that problem was never fixed, and it's quite likely you'll run into > silly issues I didn't since I couldn't get all that far. I haven't > looked at the Timing CPU's code again yet, but I have to imagine in > other ISAs other reads/writes have NO_ACCESS set and don't get held up > by the TLB. There may be some mechanism in place to handle this case > already that isn't being triggered or is being circumvented somehow. > I'll look at it when I get a chance and get back to you. What > kernel/configuration script/command line are you using? > > Gabe > > Joel Hestness wrote: > >> Hi, >> I am currently experimenting with the timing CPU in X86_FS, and I >> have encountered an assertion failure while booting Linux (using Linux >> boot as a test): >> m5.debug: build/X86_FS/cpu/simple/timing.cc:900: void >> TimingSimpleCPU::completeDataAccess(Packet*): Assertion `_status == >> DcacheWaitResponse || _status == DTBWaitResponse' failed. >> I have attached a stack trace (note that completeDataAccess is >> called twice in the trace). The current macro-instruction is a POP_M, >> and the current uop is the Cda. >> In timing mode since the Cda doesn't access memory >> (the Request::NO_ACCESS flag is set by Cda), it doesn't wait on a >> memory access or TLB, so the status of the CPU before the assertion is >> _status = Running. I've tried adding "|| _status == Running" to the >> conditional in the assertion, and the simulation gets past that point, >> but crashes later. I'm not sure if this is a sound fix, or if there >> is a better way to handle this. >> While browsing the code, I noticed that further up in the call >> stack, TimingSimpleCPU::write is called, and when executing this same >> test using the atomic CPU, AtomicSimpleCPU::write is called. In the >> AtomicSimpleCPU::write code, there is a special case test for >> when the Request::NO_ACCESS flag is set. I wonder if the same should >> occur in TimingSimpleCPU::write? >> Thanks, >> Joel >> >> -- >> Joel Hestness >> PhD Student, Computer Architecture >> Dept. of Computer Science, University of Texas - Austin >> http://www.cs.utexas.edu/~hestness >> <http://www.cs.utexas.edu/%7Ehestness> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> m5-dev mailing list >> [email protected] >> http://m5sim.org/mailman/listinfo/m5-dev >> > > _______________________________________________ > m5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/m5-dev > _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
