Hi Stijn,

They are just snoop requests from the access filtering through the  
system. You might be able to stop them by having the CPU return  
snoop=false to getDeviceAddressRanges(), but I'm not sure that the  
caches have code to do that implemented (Steve?). In any case, it's  
certainly OK to ignore them in the atomic simple cpu since it doesn't  
have any sort of buffering for the requests. The other CPU models  
ignore them as well, although it's possible that the snoop order could  
be used to enforce a stronger ordering in the system (although no one  
has ever tried this).

Hope this helps,
Ali



On Mar 6, 2010, at 6:14 PM, Stijn Souffriau wrote:

> On Saturday 06 March 2010 11:53:55 pm Ali wrote:
>> If you provide us with a back trace of the call we could tell you for
>> sure, but I imagine it's either a response coming back from the  
>> cache,
>> or it could be one of the status change messages (I think the only  
>> one
>> we support is the range change) that happens at boot and when PCI
>> devices get their address ranges assigned by the kernel. If it's the
>> latter it should be harmless.
>
> I've pasted the trace of the thread trying to call CpuPort. Classes  
> like
> Thread and Resource are mine and they block the completion of the  
> calls. I've
> noticed that most of CpuPort recv*() functions are empty so I hope  
> they are in
> fact all harmless.
> If you need any more information, let me know, will reply tomorrow.  
> Going to
> bed now.
>
> Thread 1:
>
> (gdb) backtrace
> #0  0x00007ffff656c4e5 in raise () from /lib64/libc.so.6
> #1  0x00007ffff656d9b0 in abort () from /lib64/libc.so.6
> #2  0x00000000006fb0aa in __exit_message (prefix=0xa06d08 "panic",  
> code=-1,
> func=0xa06df0 "findBreakableCycle", file=0xa06c40
> "build/ALPHA_SE/pdes/deadlock_detection.cc", line=196,
>    fmt=0xa06ce0 "Unbreakable dealock cycle detected:\n %s", a01=...,  
> a02=...,
> a03=..., a04=..., a05=..., a06=..., a07=..., a08=..., a09=...,  
> a10=...,
> a11=..., a12=..., a13=..., a14=...,
>    a15=..., a16=...) at build/ALPHA_SE/base/misc.cc:90
> #3  0x000000000054e2ae in Thread::findBreakableCycle (this=0x13c5d68,
> awaited_resource=0x14eb568) at build/ALPHA_SE/pdes/ 
> deadlock_detection.cc:196
> #4  0x000000000054dccf in ExclusiveResource::lockOnce  
> (this=0x14eb568) at
> build/ALPHA_SE/pdes/deadlock_detection.cc:92
> #5  0x00000000007f1608 in Port::sendAtomic (this=0x1553bf0,  
> pkt=0x178ed90) at
> build/ALPHA_SE/mem/port.cc:184
> #6  0x00000000004d58bb in Cache<LRU>::handleSnoop (this=0x1500b10,
> pkt=0x178ed90, blk=0x0, is_timing=false, is_deferred=false,
> pending_inval=false)
>    at build/ALPHA_SE/mem/cache/cache_impl.hh:1083
> #7  0x00000000004de954 in Cache<LRU>::snoopAtomic (this=0x1500b10,
> pkt=0x178ed90) at build/ALPHA_SE/mem/cache/cache_impl.hh:1234
> #8  0x00000000004e12b8 in Cache<LRU>::MemSidePort::recvAtomic  
> (this=0x1553d00,
> pkt=0x178ed90) at build/ALPHA_SE/mem/cache/cache_impl.hh:1483
> #9  0x00000000007f163a in Port::sendAtomic (this=0x1697b00,  
> pkt=0x178ed90) at
> build/ALPHA_SE/mem/port.cc:186
> #10 0x00000000006ea2b2 in SyncPortProxy::recvAtomic (this=0x1697c38,
> pkt=0x178ed90) at build/ALPHA_SE/pdes/mem_port_sync.cc:117
> #11 0x00000000007f163a in Port::sendAtomic (this=0x1698ae0,  
> pkt=0x178ed90) at
> build/ALPHA_SE/mem/port.cc:186
> #12 0x00000000004a4bca in Bus::recvAtomic (this=0x14da500,  
> pkt=0x178ed90) at
> build/ALPHA_SE/mem/bus.cc:383
> #13 0x00000000004aa973 in Bus::BusPort::recvAtomic (this=0x1698da0,
> pkt=0x178ed90) at build/ALPHA_SE/mem/bus.hh:94
> #14 0x00000000007f163a in Port::sendAtomic (this=0x16983d8,  
> pkt=0x178ed90) at
> build/ALPHA_SE/mem/port.cc:186
> #15 0x00000000006ea2b2 in SyncPortProxy::recvAtomic (this=0x16982a0,
> pkt=0x178ed90) at build/ALPHA_SE/pdes/mem_port_sync.cc:117
> #16 0x00000000007f163a in Port::sendAtomic (this=0x1630920,  
> pkt=0x178ed90) at
> build/ALPHA_SE/mem/port.cc:186
> #17 0x00000000004d9e68 in Cache<LRU>::atomicAccess (this=0x15dd710,
> pkt=0x7fff71541160) at build/ALPHA_SE/mem/cache/cache_impl.hh:626
> #18 0x00000000004df833 in Cache<LRU>::CpuSidePort::recvAtomic  
> (this=0x1630810,
> pkt=0x7fff71541160) at build/ALPHA_SE/mem/cache/cache_impl.hh:1411
> #19 0x00000000007f163a in Port::sendAtomic (this=0x15c8d38,
> pkt=0x7fff71541160) at build/ALPHA_SE/mem/port.cc:186
> #20 0x000000000041d296 in AtomicSimpleCPU::tick (this=0x15c8ac0) at
> build/ALPHA_SE/cpu/simple/atomic.cc:652
> #21 0x000000000041849c in AtomicSimpleCPU::TickEvent::process  
> (this=0x15c8ce8)
> at build/ALPHA_SE/cpu/simple/atomic.cc:54
> #22 0x00000000005aee7c in EventQueue::serviceOne (this=0x139d430) at
> build/ALPHA_SE/sim/eventq.cc:200
> #23 0x000000000095cb7d in SynchronousSet::serviceOne  
> (this=0x13c5d30) at
> build/ALPHA_SE/pdes/synchronous_set.cc:502
> #24 0x00000000008e16cf in simulate (.omp_data_i=0x7fffffffc760) at
> build/ALPHA_SE/sim/simulate.cc:137
> #25 0x00007ffff6ab4872 in ?? () from /usr/lib64/libgomp.so.1
> #26 0x00007ffff7bca65d in start_thread () from /lib64/libpthread.so.0
> #27 0x00007ffff660ae1d in clone () from /lib64/libc.so.6
> #28 0x0000000000000000 in ?? ()
> _______________________________________________
> 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

Reply via email to