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]>: > 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]] *On Behalf Of *Javier > Cano Cano > *Sent:* Wednesday, March 1, 2017 10:23 AM > *To:* [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 <%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] > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
