Hi Malek/Korey, The good news is that I've been able to dedicate a significant amount of time to this over the past day or so and I've got a good handle on what is going on here.
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. What is the current problem? - When the ChuckGenerator sees the block size of 64, the dma port splits the request into 64-byte packets, effectively doing the same thing the dma sequencer does. That in itself shouldn't break things...The DMA sequencer nacks all but the first 64-byte request of the dma transfer because it is designed to only handle one M5 packet at a time. Eventually the first 64-byte packet completes and the RubyPort tells the dma port to retry the second packet. The dma port does, but for some reason DMASequencer still nacks that second request. I'm not quite sure why that is, but I'm sure I'll figure it out soon. Once I do, I'll push a fix along with all the other fixes I've come across along this multi-day adventure. Brad > -----Original Message----- > From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] > On Behalf Of Korey Sewell > Sent: Thursday, March 17, 2011 3:10 PM > To: Malek Musleh > Cc: M5 Developer List > Subject: Re: [m5-dev] Ruby FS - DMA Controller problem? > > 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 <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 > > > > > > > > > -- > - 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
