How did you do this? My current understanding is that we need to support MTRRs to mark the PCI address ranges as uncacheable.

--
Nilay


On Mon, 8 Sep 2014, Mohammad Alian via gem5-dev wrote:

Hi, For some reasons gem5 doesn't recognize that PCI device address ranges are uncacheable. I set UNCACHEABLE flag for all accesses in the PCI physical address range and it fixed the problem.

Thanks,
Mohammad



On Friday, September 5, 2014 10:48 AM, Steve Reinhardt via gem5-dev 
<[email protected]> wrote:



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
_______________________________________________
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

Reply via email to