Hello, I tried to track the bug more in depth but in the end I moved to the timing simple cpu.
I think the all 0s in the destination packet appears as a consequence of some error in the O3 cpu interface with the cache. It's not the bug itself. The O3 cpu with Ruby in x86 seems to be broken when restoring checkpoints in FS. with any Network model I get panics, even with the simple one. Changeset 9677:773aae0990ae seems to be working, but with some sporadic deadlocks in the garnet fixed conf. (flexible and simple network runs OK). I want to run some tests to see where the bug appeared if I get some spare time. Kind regards. ________________________________________ De: [email protected] [[email protected]] en nombre de Lang Zhang [[email protected]] Enviado: martes, 04 de marzo de 2014 13:45 Para: [email protected] Asunto: Re: [gem5-users] RV: Getting an invalidation request with no destination. Castillo Villar, Emilio <emilio.castillo <at> unican.es> writes: > > Good evening I ran the experiment also got the result as you post. NI:22 Injecting msg [RequestMsg: Addr = [0x98ad80, line 0x98ad80] Type = INV AccessMode = User Requestor = L1Cache-0 Destination = [NetDest (4) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 - ] MessageSize = Request_Control DataBlk = [ 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ] Len = 0 Dirty = 0 Prefetch = No Time = 3166840465750000 ] the NetDest(4)here whether it meas the packet should go to these 4 destinations? if i get Destination = [NetDest (4) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 ] "0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1"means which destination node? Why the last has only two zero? Thanks! > > > > > Good afternoon, > > > I am doing some experiments with the 9948 rev. (Though I have experienced the same bug with revisions of May). > > Currently I am taking a checkpoint inside a benchmark and restore it with Ruby + OoO CPU. > If I do it with the simple network model or garnet flexible it works fine. > However, when trying to restore it with the garnet fixed network, I am facing a deadlock. > > I am using the following parameters: > > > build/X86_MESI_CMP_directory/gem5.opt -d testing_ckpt/ configs/example/ruby_fs.py --kernel=x86_64-vmlinux-2.6.28.4-smp --disk- image=x86root.img -n 16 -r1 --num-l2cache=16 --num-dir=16 --topo=Mesh -- mesh-rows=4 --restore-with=detailed --cpu-type=detailed > --garnet=fixed > > > (I fixed a similar problem when restoring with the timing cpu, that fix is now in the gem5 dev repo.) > > I have been tracing the source of this problem, and in some point of the simulation, a packet like this appears in the NetworkInterface_d.cc object of the garnet fixed router. > > NI:22 Injecting msg [RequestMsg: Addr = [0x98ad80, line 0x98ad80] Type = INV AccessMode = User Requestor = L1Cache-0 Destination = [NetDest (4) 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 - 0 - > ] MessageSize = Request_Control DataBlk = [ 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 > 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 0x0 ] Len = 0 Dirty = 0 Prefetch = No Time = 3166840465750000 ] > > This message has all possible destinations set to 0, causing the flitisize method to do absolutely nothing. > It does a for loop for all the destinations and after the loop is done, returns true. The NI will remove the packet from the Message Queue. When there are no possible destinations, the loop for won't execute and the flitisize will return true removing > the packet from the queue. The problem comes when this mem request has been registered in the sequencer tables, so after quite some time, it will pop up with a deadlock panic. > > > Now I am trying to determine how did this packet get into the Network, does anyone know what may be happening in here? > > > Thanks a lot for your time, > > Kind regards, > > > > > > > > > > _______________________________________________ > gem5-users mailing list > gem5-users <at> gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users _______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
