Hi Nilay,
Thanks for digging even further into this. Is Alpha the only one where
checkInterrupts and getInterrupts don't agree? Perhaps we can just fix the
Alpha implementation and that will solve the problem. It seems like in Alpha
the checkInterrupts() function is just there to speed up execution when there
isn't the possibility of an interrupt pending, but it doesn't handle all the
tests. Does that work for everyone?
Thanks,
Aii
On Mar 25, 2013, at 4:52 PM, Nilay <ni...@cs.wisc.edu> wrote:
> Ali, here is trace that shows the problem:
>
> ---------------------------------------------------------------------------
> 5103756467000: system.cpu.interrupts: Got Trigger Interrupt message with
> vector 0x30. // Here is the interrupt object receives the interrupt
> 5103756467000: system.cpu.interrupts: Interrupt is an LowestPriority.
> .
> .
> .
> 5103756496000: system.cpu.interrupts: Generated regular interrupt (48)
> fault object. // Interrupt object created for the CPU
> .
> .
> .
> 5103791689000: system.pc.south_bridge.ide.disks0: Posting Interrupt // IDE
> controller raises the interrupt line
> 5103791740000: system.cpu.interrupts: Got Trigger Interrupt message with
> vector 0x3e. // Interrupt object receives the interrupt from the IDE
> controller
> 5103791740000: system.cpu.interrupts: Interrupt is an LowestPriority.
> .
> .
> .
> 5103791744000: system.cpu.interrupts: Interrupt 62 sent to core. // CPU
> asks for interrupt information to be updated i.e. some interrupt is being
> handled.
>
> ---------------------------------------------------------------------------
>
> The problem lies in the o3 cpu itself. In the following piece code from
> cpu/o3/cpu.cc file, the cpu can possibly update the interrupt info for a
> different interrupt and invoke the interrupt handler for a different
> interrupt. This is what happened above. The interrupt object thinks that
> interrupt 62 is being handled, while the CPU actually handled interrupt
> 48. This results in IDE controller waiting for about 20 seconds, before it
> switches from DMA to PIO mode and redoes all the work.
>
> template <class Impl>
> void
> FullO3CPU<Impl>::processInterrupts(Fault interrupt)
> {
> // Check for interrupts here. For now can copy the code that
> // exists within isa_fullsys_traits.hh. Also assume that thread 0
> // is the one that handles the interrupts.
> // @todo: Possibly consolidate the interrupt checking code.
> // @todo: Allow other threads to handle interrupts.
>
> assert(interrupt != NoFault);
> this->interrupts->updateIntrInfo(this->threadContexts[0]);
>
> DPRINTF(O3CPU, "Interrupt %s being handled\n", interrupt->name());
> this->trap(interrupt, 0, NULL);
> }
>
>
> --
> Nilay
>
> _______________________________________________
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
_______________________________________________
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
