Sort of... what Lisa is recommending (and what we need to get into the code base) is an additional hasContextId() method that just returns the VALID_CONTEXT_ID flag. Then you would call that first and only call contextId() if it returns true, and can decide for yourself how to handle the requests with no valid context ID if hasContextId() returns false.
Steve On Mon, Dec 29, 2008 at 9:02 AM, Ryan Markley <[email protected]> wrote: > 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 > _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
