Hi Cano, I downloaded the x86 binaries and was able to reproduce the transition error. Sorry I forgot the wakeups in my original suggestion, but it seems like you figured out what I was trying to do anyway ☺.
After implementing the stalls and wakeups exactly as you did, it seems to work fine for me. I was able to replicate the overflow problem if I move the cur_state variable to the TBEs so that the protocol can support more than one outstanding DMA transaction. There is no backpressure being applied when you are doing streaming writes from the DMA controller; the directory just plops them in the packet queue to memory and allows the DMA controller to send more, which eventually triggers the assertion. However, if I leave cur_state alone and just fix the transition bug, it appears to work fine. Do you have any other modifications to the protocol besides what you show on the previous email? -Michael From: gem5-users [mailto:[email protected]] On Behalf Of Javier Cano Cano Sent: Wednesday, March 8, 2017 4:24 AM To: gem5 users mailing list <[email protected]> Subject: Re: [gem5-users] Outstanding DMA requests and MOESI_CMP_directory protocol Hi Michael, Thanks a lot for you response, I appreciate it. The error is reproducible even with the binaries provided by gem5's wiki: http://www.m5sim.org/dist/current/x86/x86-system.tar.bz2 I tried your propose but I getting this error: hda: ide_dma_sff_timer_expiry: DMA status (0x21) hda: DMA timeout error hda: dma timeout error: status=0x50 { DriveReady SeekComplete } hda: possibly failed opcode: 0xc8 hda: ide_dma_sff_timer_expiry: DMA status (0x21) hda: DMA timeout error hda: dma timeout error: status=0x50 { DriveReady SeekComplete } hda: possibly failed opcode: 0xc8 This is because stall_and_wait() function push the messages into dmaRequestQueue_in but the messages are never pulled out. The simulation boots up after a huge amount of time, but it doesn't looks to be correct. I took a look into another protocol files and I added this lines: action(zz_stallAndWaitRequestQueue, "zz", desc="...") { stall_and_wait(dmaRequestQueue_in, address); } action(wkad_wakeUpAllDependents, "wkad", desc="wake-up all dependents") { wakeUpAllBuffers(); } transition(BUSY_RD, Data, READY) { t_updateTBEData; d_dataCallbackFromTBE; w_deallocateTBE; //u_updateAckCount; //o_checkForCompletion; p_popResponseQueue; wkad_wakeUpAllDependents; } transition(BUSY_RD, All_Acks, READY) { d_dataCallbackFromTBE; //u_sendExclusiveUnblockToDir; w_deallocateTBE; p_popTriggerQueue; wkad_wakeUpAllDependents; } transition(BUSY_WR, All_Acks, READY) { a_ackCallback; u_sendExclusiveUnblockToDir; w_deallocateTBE; p_popTriggerQueue; wkad_wakeUpAllDependents; } transition({BUSY_RD,BUSY_WR}, {ReadRequest,WriteRequest}) { zz_stallAndWaitRequestQueue; } With this changes, the msgs are pulled from queues at some point. However, the queues still overflow and gem5 shows this error: panic: Packet queue system.ruby.dir_cntrl0.memory- has grown beyond 100 packets Memory Usage: 1287832 KBytes Program aborted at tick 5224739073500 I'm missing something, maybe a transition where the should be awaken as well, but I can't figure it out. Any suggestions? Thanks. Cano. 2017-03-02 23:08 GMT+01:00 Lebeane, Michael <[email protected]<mailto:[email protected]>>: Hi Cano, I can’t test this as I don’t have your binaries to reproduce the problem, but do adding these lines in MOESI_CMP_directory-dma.sm fix your problem? action(zz_stallAndWaitRequestQueue, "zz", desc="...") { stall_and_wait(dmaRequestQueue_in, address); } transition({BUSY_RD,BUSY_WR}, {ReadRequest,WriteRequest}) { zz_stallAndWaitRequestQueue; } Thanks, Michael From: gem5-users [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Javier Cano Cano Sent: Wednesday, March 1, 2017 10:23 AM To: [email protected]<mailto:[email protected]> Subject: [gem5-users] Outstanding DMA requests and MOESI_CMP_directory protocol Hi everybody, Some days ago, I updated my gem5 version in order to test Garnet2.0. But I found that MOESI_CMP_directory protocol wasn't working. As far as I know, the problem comes from the patch http://repo.gem5.org/gem5?cmd=changeset;node=0bf388858d1e This patch allows outstanding DMA requests. Some protocols had been updated to support this new feature but MOESI_CMP_directory, as well as others, doesn't. I'm using the following command to build Gem5: scons ./build/X86/gem5.opt PROTOCOL=MOESI_CMP_directory RUBY=True -j30 To run the simulation, the following instructions had been used: ./build/X86/gem5.opt configs/example/fs.py --ruby --kernel=/home/cano/gem5/system/binaries/x86_64-vmlinux-3.4.112.smp --disk-image=/home/cano/curgem5/canolab/system/disks/gentoo.img The error that gem5 shows when I try to run a simulation is: panic: Invalid transition system.ruby.dma_cntrl0 time: 9702290051<tel:%28970%29%20229-0051> addr: 504500288 event: WriteRequest state: BUSY_WR @ tick 4851145025500 [doTransitionWorker:build/X86/mem/protocol/DMA_Transitions.cc, line 135] The problem has something to do with file MOESI_CMP_directory-dma.sm which doesn't support the state changes introduced on patch 0bf388858d1e. Did someone have this problem? I tried to update the protocol, but no luck, I get a error saying that the queues have more than 100 messages stored on it. Does anyone have the MOESI_CMP_directory files modified to support this new feature? In order to temporally fix the problem, I rolled back the changes introduced on the mentioned patch. Thanks for your time. Cano. _______________________________________________ gem5-users mailing list [email protected]<mailto:[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
