Hello, As I said before I am using contextId() to get the CPU number, but I am getting this error at some moment of the simulation:
Add: 1405001: system.tol2bus: recvTiming: src 8 dst 3 ReadResp 0x110180 BUSY 1405001: system.l2-cpu_side_port: Send failed, waiting on retry m5.opt: build/ALPHA_SE/mem/request.hh:416: int Request::contextId() const: Assertion `flags.any(VALID_CONTEXT_ID)' failed. Program aborted at cycle 1407000 Aborted I have not done any changes in the contextId() fuction, is it safe to comment the assert, that is causing the error. I have been trying to trace the error, butI have no idea where the problem can be, Thanks. On Sat, Dec 20, 2008 at 5:52 AM, Lisa Hsu <[email protected]> wrote: > Hi Ryan, > > You're right that that packet has to do with the membus and the physmem, but > the contextID means it *originated* from cpu3. For the lifetime of a > request as it travels from the cpus to its destination in memory and back, > it has the same contextId(). However, as it travels, it will have > intermediate bus port sources as it will be traveling from cpu to DL1 cache > to the tol2bus to the L2 cache to the membus to physmem (if it goes that > far). I believe at each intermediate point the pkt->src is overwritten by > the latest src as it forward the packet down the line. > > A contextId of -1 indicates either a writeback or a device access. > > Lisa > > On Fri, Dec 19, 2008 at 7:57 PM, Ryan Markley <[email protected]> wrote: >> >> Hello Lisa thanks for your answer, that Flag was very helpful. >> >> I have a question I am printg all the time the cpu origin, and I >> always get a cpu origin with pkt->req->contextId(), but reviewing the >> ports some packets does not seem to be related with the cpu, for >> example: >> >> CPU: 3 <-> src_port: 0, SRC: 0 DEST: 1 >> 550000: system.membus: recvTiming: src 0 dst 1 ReadResp 0x8e240 >> 550000: system.membus: The bus is now occupied from tick 550000 to >> 552000 >> >> I think that this packet has nothing to do with the cpu 3 and it is >> only related with membus and physical memory, this is also confirmed >> with the output of the Config flag:, that says that the connection >> between the physical memory and the membus, is doing with a port with >> id 0. >> >> 0: system.membus-p0: setting peer to system.physmem-port0 >> 0: system.physmem-port0: setting peer to system.membus-p0 >> >> So my question is, is there any way to know when a packet is really >> coming from a cpu and it is not a mistake of the contextId() function >> that I believe that is giving sometimes worngly information saying >> that a packet is from a cpu when is not. I just want to know when the >> packet is coming from a CPU and when is coming from other thing. >> >> And another question which one is the destination -1?, I do not see >> any port with -1 id in the output generated by the config file. I >> believe is the L2 cache but is this right?. Thanks so much for your >> help. >> >> >> On Fri, Dec 19, 2008 at 2:31 PM, Lisa Hsu <[email protected]> wrote: >> > Hi Ryan, >> > >> > The CPU is indeed connected to several ports, like for example the >> > icache >> > port and a dcache port. >> > >> > if you turn on the trace flag "Config" you will be able to see who is >> > connecting to which ports and which port numbers. >> > >> > As of now, (I think) there is no way to easily connect a port to the >> > specific SimObject it is connected to except perhaps by printing out its >> > name. Someone correct me if I'm wrong here. >> > >> > Lisa >> > >> > On Fri, Dec 19, 2008 at 4:42 PM, Ryan Markley <[email protected]> wrote: >> >> >> >> Hello, >> >> >> >> I am exploring the circulation of packages along the bus using the Bus >> >> flag and some information that I am printing, and I have several >> >> questions, I am using the detailed cpu and the configuration that >> >> comes with the se.py file, with --caches and --l2cache options. >> >> >> >> I am printing the origin of the cpu with pkt->req->contextId(), and I >> >> get outputs likes this: >> >> >> >> CPU: 1 <-> src_port: 1, SRC: 1 DEST: -1, here we see the cpu number, >> >> the src_port ( pkt->getSrc() ) and the destination ( pkt->getDest() ) >> >> 70000: system.membus: recvTiming: src 1 dst -1 ReadReq 0x1aa180 >> >> 70000: system.membus: The bus is now occupied from tick 70000 to 71000 >> >> >> >> CPU: 1 <-> src_port: 0, SRC: 0 DEST: 1 >> >> 100000: system.membus: recvTiming: src 0 dst 1 ReadResp 0x1aa180 >> >> 100000: system.membus: The bus is now occupied from tick 100000 to >> >> 102000 >> >> >> >> CPU: 1 <-> src_port: 8, SRC: 8 DEST: 6 >> >> 162500: system.tol2bus: recvTiming: src 8 dst 6 ReadResp 0x1aa180 >> >> 162500: system.tol2bus: The bus is now occupied from tick 162500 to >> >> 175000 >> >> 162500: system.tol2bus: Remove retry from list 8 >> >> >> >> >> >> Can anyone tell me why for the same cpu there are several different >> >> origin ports?, I guess is because the cpu is connected to several >> >> buses with different ports, maybe one for the cache and another one >> >> for the main memory, but can anyone confirm this?. but if this is >> >> right I do not understand why if the port 1 is for the membus why I >> >> see after port 0 also for the membus, can anyone please clarify this?. >> >> >> >> And also is there anyway to identificate the ports?, if one is for the >> >> cache and another one for the memory is there any way to tell wich one >> >> is for the cache and one for the memory?. >> >> Regarding the destination I have a similar question, is there any way >> >> to identify id's (pkt->getDest() ) with high level information such >> >> as, main memory, L2 cache..., thank you. >> >> >> >> Thanks in advance. >> >> _______________________________________________ >> >> 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 >> > >> _______________________________________________ >> 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 > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
