Have you tried running with the O3CPUAll debug flag? That may shed some more light on whats happening. Steve's suggestion sounds like a possibility.
On Sat, Nov 22, 2014 at 12:24 PM, Steve Reinhardt via gem5-users < gem5-users@gem5.org> wrote: > I don't recall the details, but there's some issue with data accesses and > instruction fetches sharing the same port to memory with O3 that leads to a > livelock (or deadlock?) situation... something like you need to do an > ifetch to make forward progress, but every time the port is free you > re-issue a speculative data access instead, or maybe it's the other way > around. We have run into this before--I think the same problem occurs with > a unified L1--but since it goes away once you use split caches, and it's > unrealistic not to have split caches anyway, we never considered it worth > fixing. > > Steve > > > On Sat, Nov 22, 2014 at 9:27 AM, Thom Popovici via gem5-users < > gem5-users@gem5.org> wrote: > >> Hi, all! >> >> I want to remove the caches from the full system configuration. I want >> multiple processors that are directly connected to the membus and the >> memory. As far as I saw the O3CPU demands caches, why? I managed to modify >> the function request_caches from True to False. I managed to instantiate >> all the objects without errors but Gem5 freezes up at the very beginning: >> >> Entering event queue @ 0. Starting simulation... >> >> Any ideas. >> >> Thanks so much >> >> _______________________________________________ >> gem5-users mailing list >> gem5-users@gem5.org >> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >> > > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
