> On Aug. 1, 2012, 3:51 p.m., Ali Saidi wrote:
> >

does you comment about the kernel mean that the simulator is ok, but the kernel 
panics when you're switching?


> On Aug. 1, 2012, 3:51 p.m., Ali Saidi wrote:
> > src/arch/arm/table_walker.cc, line 89
> > <http://reviews.gem5.org/r/1221/diff/7/?file=28379#file28379line89>
> >
> >     you could do count + 1 here along with a comment that we're returning 
> > the count of the port + 1 because we still have stuff to do.
> 
> Anthony Gutierrez wrote:
>     Also, recently I was thinking should we do something like:
>     
>     else {
>         if (count) {
>             changeState(Draining);
>             return count;
>         }
>         changeState(Drained);
>         return 0;
>     }
>     
>     In the case the table walker itself is drained, but its ports aren't? 
> Should it be "drained" if its ports are not?

no it shouldn't be... if there is something in the port still, it's going to be 
getting a callback to deal with it.


- Ali


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/1221/#review3187
-----------------------------------------------------------


On Aug. 1, 2012, 4:10 p.m., Anthony Gutierrez wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/1221/
> -----------------------------------------------------------
> 
> (Updated Aug. 1, 2012, 4:10 p.m.)
> 
> 
> Review request for Default.
> 
> 
> Description
> -------
> 
> Changeset 9138:7cc411c4e44c
> ---------------------------
> O3,ARM: fix some problems with drain/switchout functionality and add Drain 
> DPRINTFs
> 
> This patch fixes some problems with the drain/switchout functionality
> for the O3 cpu and for the ARM ISA and adds some useful debug print
> statements.
> 
> This is an incremental fix as there are still a few bugs/mem leaks with the
> switchout code. Particularly when switching from an O3CPU to a
> TimingSimpleCPU. However, when switching from O3 to O3 cores with the ARM ISA
> I haven't encountered any more assertion failures; now the kernel will
> typically panic inside of simulation.
> 
> 
> Diffs
> -----
> 
>   src/arch/arm/table_walker.hh d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/arch/arm/table_walker.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/cpu/base.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/cpu/o3/commit_impl.hh d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/cpu/o3/cpu.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/cpu/o3/fetch_impl.hh d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/cpu/o3/lsq_unit.hh d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/cpu/simple/timing.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/dev/copy_engine.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/dev/dma_device.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/dev/i8254xGBe.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/mem/bus.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/mem/cache/base.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/mem/packet_queue.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/mem/port.hh d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/mem/port.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/mem/ruby/system/RubyPort.cc d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/python/m5/simulate.py d164268bc35c5f477b371a828ee4d47448bfb4b3 
>   src/sim/SConscript d164268bc35c5f477b371a828ee4d47448bfb4b3 
> 
> Diff: http://reviews.gem5.org/r/1221/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Anthony Gutierrez
> 
>

_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev

Reply via email to