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
