Korey, if you're deadlock is with running the MOESI_CMP_directory protocol, I'm not surprised. DMA support is pretty much broken in that protocol. I have that fixed and I also fixed the underlining DMA problem. I'll be pushing the fixes momentarily.
Korey and Malek, please pull these changes and confirm they fix your problem. Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] > On Behalf Of Korey Sewell > Sent: Friday, March 18, 2011 9:12 AM > To: M5 Developer List > Subject: Re: [m5-dev] Ruby FS - DMA Controller problem? > > <message below> > > Why did it work before the block size patch? > > - When the ChuckGenerator sees the block size is 0, it doesn't split > > up the request into multiple patches and sends the whole dma request > > at once. That is fine because the DMASequencer splits the request > > into multiple requests and only responds to the dma port when the entire > request is complete. > > > With regards to the old changeset that boots with the block size = 0, I was > not > able to boot a large scale CMP system (more than 16 cores) due to the > "deadlock threshold" being triggered. > > I'm assuming that Brad has a read on how to fix that problem so I'll probably > start working on what is causing that deadlock so hopefully we can kind of > pipeline the bug fixes. > > -- > - Korey > _______________________________________________ > m5-dev mailing list > m5-dev@m5sim.org > http://m5sim.org/mailman/listinfo/m5-dev _______________________________________________ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
