On Mon, January 21, 2013 3:42 pm, Joel Hestness wrote: > Hey Nilay, > I've tried updating to the latest gem5, and I've found a bug, which > looks > to be related to this changeset. Specifically, in the case that not all > Ruby components are clocked at the same frequency, the assertion in > MessageBuffer::enqueue (src/mem/ruby/buffers/MessageBuffer.cc:213) can > fail > if the m_LastEnqueueTime of a message was previously set by a component > with a faster clock. Attached is the config file and debug output with > trace showing what happens in my simulation. Note that the Ruby network > components have clock=500 in the config.ini, while the directory has > clock=1000. > > Any ideas how to fix this? >
As I understand, the message's less enqueue time was set by some component that runs at Ruby's frequency. But in the assert some component, which runs slower, is checking whether last enqueue time is lesser than the current time, which can fail. You can try switching back to using g_system_ptr in that assert statement. The actual fix would be that we set the enqueue time in the message in terms of Ticks and not clock cycles. -- Nilay _______________________________________________ gem5-dev mailing list [email protected] http://m5sim.org/mailman/listinfo/gem5-dev
