Hi Nilay,
I'm a little surprised at this issue. I could see that another higher priority interrupt comes along, but if that is the case it should be taken after the lower priority interrupt (nearly immediately). It could be considered a bug, but on the other hand the CPU has to decide what interrupt it is going to take at some point and act on it, so perhaps not. I'm guessing something like the following happens: assert(low_priority); interrupt = getInterrupt(); // low_priority assert(high_priority); handle_interrupt(); // just clears the highest priority interrupt set?? I suppose I don't have any issues with your fix, provided there is a nice comment describing what/why. I'd like to see if we are in fact doing the above. Thanks, Ali On 20.03.2013 23:54, Nilay wrote: > Hi > > While testing some patches for the x86 architecture, I came across a > problem in which the system does nothing for several seconds. This time is > the time of the target machine. This behavior is accompanied by the > following message on the console for target machine -- > > hda: dma_timer_expiry: dma status == 0x64 > hda: DMA interrupt recovery > hda: lost interrupt > > Joel Hestness, who had seen the problem before, provided me with a patch > that solves the problem. From my conversation with Joel and after looking > at the code my self, it appears that the problem is with the fact that the > commit stage of the pipeline keeps a local copy of the interrupt object. > Since the interrupt is usually handled several cycles after the commit > stage becomes aware of it, it is possible that the local copy of the > interrupt object may not be the correct interrupt when the interrupt is > actually handled. It is possible that another interrupt occurred in the > interval between interrupt detection and interrupt handling. I am > proposing the following solution (slightly different from Joel's proposal) > to handle this problem: > > diff --git a/src/cpu/o3/commit_impl.hh b/src/cpu/o3/commit_impl.hh > --- a/src/cpu/o3/commit_impl.hh > +++ b/src/cpu/o3/commit_impl.hh > @@ -753,7 +753,7 @@ > } > > // CPU will handle interrupt. > - cpu->processInterrupts(interrupt); > + cpu->processInterrupts(cpu->getInterrupts()); > > thread[0]->noSquashFromTC = false; > > The code above ignores the local copy of the interrupt object and fetches > a new one from the CPU object. > > There are several questions that need to be addressed here. Is there an > actual bug in the o3 cpu? Is the diagnosis correct? Is the solution > acceptable? > > Thanks > Nilay > > _______________________________________________ > gem5-dev mailing list > gem5-dev@gem5.org > http://m5sim.org/mailman/listinfo/gem5-dev [1] Links: ------ [1] http://m5sim.org/mailman/listinfo/gem5-dev _______________________________________________ gem5-dev mailing list gem5-dev@gem5.org http://m5sim.org/mailman/listinfo/gem5-dev
