I don't know exactly what the problem is, but it's very suspicious that the device would receive a cache-block-sized access when it's in uncacheable memory space. My guess is that O3 is for some reason issuing a misspeculated cacheable access to the physical address where the device lives. Normally these would be suppressed when the TLB lookup indicates that the address is uncacheable, but if you're in kernel mode, you could end up with speculative accesses to the translation bypass range.
To be honest, I don't know off the top of my head how this is dealt with in actual x86 systems... it would certainly be safest to suppress all speculative accesses to bypassed addresses, but I suspect that we can be smarter than that using the MTRRs. I could dig into it but don't have time at the moment, so if someone else knows these details, please speak up. Steve On Thu, Sep 4, 2014 at 2:30 PM, Mohammad Alian via gem5-dev < [email protected]> wrote: > Hi all, > > Ethernet device work perfectly with atomic cpu in X86 ISA but I get an > error when I switch cpu to detailed O3 cpu. The error is: > > gem5.opt: build/X86/dev/i8254xGBe.cc:182: virtual Tick > IGbE::read(PacketPtr): Assertion `pkt->getSize() == 4' failed. > Program aborted at tick 131516086224500 > Aborted > > > I noticed that the size of packet that Ethenet device receive with O3 cpu > is same as cache line size(64Bytes) however the Ethernet device just > support 32bit accesses. > Any Idea how to fix this problem? > > Thank you, > Mohammad Alian > _______________________________________________ > gem5-dev mailing list > [email protected] > http://m5sim.org/mailman/listinfo/gem5-dev > _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
