Hello, do you mean this post http://thread.gmane.org/gmane.comp.emulators.m5.users/1523?, I have been trying to do the thing that says there, trying to add another CPU Id for those request when the request is created, but I have not come up with anything. The thing that I can do is comment the assert and after in my function when I am calling contextId() do a simple check and see if the CPU number is really a CPU.
Since I think that my solution is not the most elegant one, I'd like to ask you if you have time can you please give me more information about how to use a more elegant solution?, only if you have time, because I think that my solution will work anyway. Thank you. On Sun, Dec 28, 2008 at 10:19 PM, Lisa Hsu <[email protected]> wrote: > No, it is not safe. The contextId() is not always valid because a request > does not always come from a CPU - it could be a writeback or a device > request in which case the contextId would have no meaning. There's a post > from a while back to just make your own check function to make sure the > request is from a CPU before you call contextId(). I have something like > that in my patch queue but I don't think I've pushed it yet, but writing > your own would be simple. > > Lisa > > On Sun, Dec 28, 2008 at 5:43 PM, Ryan Markley <[email protected]> wrote: >> >> 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 >> > > > _______________________________________________ > 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
