Hi Malek, Can you send your most recent trace showing what you described (if it isnt too big)? I havent observed the different request size errors, but I think I have observed the different PRD addresses on the first access (in the most recent changeset). I'll double check.
I was planning to post sometime soon what was the latest on my debugging efforts but a quick summary is that the PRD address gets set from a "BMI.DTP" register that eventually gets propagate through. I havent been able to verify if that is loaded from the kernel or some configuration parameter quite yet. 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. > Are you sure it's a split request problem and not an uncacheable address thing? Or maybe it's some combo of both? > > 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. > That's an interesting observation. It would be nice to figure out why that address may or may not matter though. > > Not really sure if that helps anymore. > > Malek > > On Tue, Mar 15, 2011 at 6:50 PM, Korey Sewell <[email protected]> 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 <[email protected] > >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: [email protected] [mailto:[email protected]] > >> > 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 > >> > <[email protected]>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 > >> > > [email protected] > >> > > http://m5sim.org/mailman/listinfo/m5-dev > >> > > > >> > > >> > > >> > > >> > -- > >> > - Korey > >> > _______________________________________________ > >> > m5-dev mailing list > >> > [email protected] > >> > http://m5sim.org/mailman/listinfo/m5-dev > >> > >> > >> _______________________________________________ > >> m5-dev mailing list > >> [email protected] > >> http://m5sim.org/mailman/listinfo/m5-dev > >> > > > > > > > > -- > > - Korey > > _______________________________________________ > > m5-dev mailing list > > [email protected] > > http://m5sim.org/mailman/listinfo/m5-dev > > > -- - Korey _______________________________________________ m5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/m5-dev
