No, but I think I'm doing that right. I put the little bit of code that
sets up the request below, so please let me know if I'm not. Also, I
think I figured out the problem. I have a function to send a message
out, but it was always using timing mode. The -atomic- simple CPU was
apparently upset about getting a timing callback. Now that that's fixed
it seems to be working fine.
Gabe
PacketPtr
prepIntRequest(const uint8_t id, Addr offset, Addr size)
{
RequestPtr req = new Request(x86InterruptAddress(id, offset),
size, UNCACHEABLE);
PacketPtr pkt = new Packet(req, MemCmd::MessageReq,
Packet::Broadcast);
pkt->allocate();
return pkt;
}
Steve Reinhardt wrote:
> Any cacheable request will get snooped by any device that says it
> wants snoops (e.g., a cache or the cpu). Are you sure the request
> that's getting snooped is marked uncacheable?
>
> Steve
>
> On Sun, Sep 7, 2008 at 2:20 PM, Gabe Black <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> I'm still working on these interrupt packet stuff, and now I'm
> having a problem where a snoop is going to simple CPU through a
> recvTiming for an address which belongs to the interval of memory the
> APICs use for their messages. I don't know specifically where the
> snoop
> is coming from, but I was thinking it might have something to do with
> the snoop parameter of getDeviceAddrRanges which I set to false. Do I
> need to set that to true so I get the snoops and not the CPU? Is
> it just
> because the CPU and the APIC are on the same bus for the simple CPU?
>
> Gabe
> _______________________________________________
> m5-dev mailing list
> [email protected] <mailto:[email protected]>
> http://m5sim.org/mailman/listinfo/m5-dev
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> m5-dev mailing list
> [email protected]
> http://m5sim.org/mailman/listinfo/m5-dev
>
_______________________________________________
m5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/m5-dev