Brad/Korey, An Update of what I have seen.
I did notice that in the failing case, the DMASequencer would think that the request is completed (length of request == 64) when in fact it should be 8192. The 8192 reflects the byte sector size, but what is interesting is that a DPRINTF(IdeIDisk) in ide_disk.cc right before it fails indicates that the request length is 8192. So there is something wrong with the transfer in the RubyPorts. I have a feeling it might be also linked with the timing simpleCpu changes about handling split requests, although Alpha does not support split requests, that is independent of the DMA transfers. Also, comparing Ruby Traces (with and without failing changeset) the first PRD BaseAddr is consistent between them, but not consistent between Ruby/M5. So the fact that the PRD BaseAddr is 'wrong' in the one case does not prevent it from booting the Kernel. Not really sure if that helps anymore. Malek On Tue, Mar 15, 2011 at 6:50 PM, Korey Sewell <ksew...@umich.edu> wrote: > Sorry for the confusion, I definitely "garbled up" some terminology. > > I meant that the M5 ran with the atomic model to compare with the timing > Ruby model. > > M5-atomic maybe runs in 10-15 mins and then Ruby 20-30 mins. > > I am able to get the problem point in the Ruby simulation (bad DMA access) > in about 20 mins. > > I able to get to that same problem point in the M5-atomic mode in about 10 > mins so as to see what to compare against and what values are being > set/unset incorrectly. > > > > On Tue, Mar 15, 2011 at 6:22 PM, Beckmann, Brad <brad.beckm...@amd.com>wrote: > >> I'm confused. >> >> Korey, I thought this DMA problem only existed with Ruby? If so, how were >> you able to reproduce it using atomic mode? Ruby does not work with the >> atomic cpu model. >> >> Please clarify, thanks! >> >> Brad >> >> > -----Original Message----- >> > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] >> > On Behalf Of Korey Sewell >> > Sent: Tuesday, March 15, 2011 12:09 PM >> > To: M5 Developer List >> > Subject: Re: [m5-dev] Ruby FS - DMA Controller problem? >> > >> > Hi Brad/Malek, >> > I've been able to regenerate this error in about 20mins now (instead of >> > hours) by running things in atomic mode. Not sure if that helps or not... >> > >> > On Tue, Mar 15, 2011 at 3:03 PM, Beckmann, Brad >> > <brad.beckm...@amd.com>wrote: >> > >> > > > How is that you are able to run the memtester in FS Mode? >> > > > I see the ruby_mem_tester.py in /configs/example/ but it seems that >> > > > it is only configured for SE Mode as far as Ruby is concerned? >> > > >> > > I don't run it in FS mode. Since the DMA bug manifests only after >> > > hours of execution, I wanted to first verify that the DMA protocol >> > > support was solid using the mem tester. Somewhat surprisingly, I >> > > found several bugs in MOESI_CMP_directory's support of DMA. It turns >> > > out that the initial DMA support in that protocol wasn't very well >> > > thought out. Now I fixed those bugs, but since the DMA problem also >> > > arises with the MOESI_hammer protocol, I'm confident that my patches >> > don't fix the real problem. >> > > >> > > Brad >> > > >> > > _______________________________________________ >> > > m5-dev mailing list >> > > m5-dev@m5sim.org >> > > http://m5sim.org/mailman/listinfo/m5-dev >> > > >> > >> > >> > >> > -- >> > - 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 >> > > > > -- > - 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
