The assert(dest != pkt->getSrc()) is the Bus object is there to
prevent infinite loops. If a device of some kind hands the Bus a
packet to send to some other port. Clearly this isn't happening, so
you should check that you're actually responding to the packet
properly in all cases (which could also explain the kernel panic you
saw).
Ali
On Oct 10, 2007, at 5:30 PM, Steve Reinhardt wrote:
Clearly something's going wrong, but it's impossible to tell what
from a high-level failure. If you use the Exec trace flag and
tracediff you can see if the instruction execution is diverging
somewhere relative to the non-reordered memory module.
Steve
On 10/10/07, Jun Pang <[EMAIL PROTECTED]> wrote:
Hi Steve,
Thank you very much again. I have already solved the problem of
sendTiming. The reason that I cannot correctly use sendTiming is
that I should not move sendTiming completely from
SimpleTimingPort::recvTiming, because other derived class such as
PioPort still need sendTiming in the SimpleTimingPort::recvTiming.
Now I have met new problems. I have buffered many packets in a
queue with a length of 100 from the recvTiming(pkt).Then I call
sendTiming to send them in completely reversed order. But when I
telnet the host using term, it printed out some wrong information,
as follows:
==== m5 slave console: Console 0 ====
M5 console: m5AlphaAccess @ 0xFFFFFD0200000000
Got Configuration 623
memsize 20000000 pages 10000
First free page after ROM 0xFFFFFC0000018000
………….
Console: colour dummy device 80x25
Unable to handle kernel paging request at virtual address
000000000000003c
CPU 0 swapper(0): Oops -1
pc = [<000000000000003c>] ra = [<000000000000003f>] ps = 0000
Not tainted
pc is at 0x3c
ra is at 0x3f
v0 = fffffc0000e8a000 t0 = 0000000000100000 t1 = fffffc000085a0f8
t2 = 0000000000000000 t3 = 0000000000000001 t4 = fffffc0000f8a000
t5 = fffffc0000f8a000 t6 = 00000000000007c5 t7 = fffffc000070c000
s0 = 0000000000000004 s1 = fffffc000065c504 s2 = 000000000000076c
s3 = 0000000000000000 s4 = 0000000000002000 s5 = 0000000000000008
s6 = fffffc0000809afc
a0 = fffffc0000e8a000 a1 = 0000000000000000 a2 = 0000000000000000
a3 = 0000000000000000 a4 = 000000000000003f a5 = 0000000000000080
t8 = 0000000000000740 t9 = fffffc000085a000 t10= 0000000000000001
t11= 0000000000010000 pv = fffffc00004c0720 at = 0000000000000000
gp = fffffc0000808200 sp = fffffc000070fe58
and a panic information 'M5 panic instruction called at
pc=0xfffffc000031d7a0'.
I think maybe the packets are not received correctly, what is wrong
with this? Can the instruction packets not be reordered?
Sometimes, when I change the out-of-order schedule method I get a
assert information, which is 'assert( dest != pkt->getSrc())' in
the Bus::recvTiming function. I am curious about why the 'dest' is
equal to the packet's 'src'. Is this because of this packet being
retried by Bus? Or, why does this happen?
Thank you very much !
Jun Pang
On 10/10/07, Steve Reinhardt < [EMAIL PROTECTED]> wrote:
Hi Jun,
What CPU model are you using? If you're using SimpleCPU, that's a
blocking CPU model, so you won't get any more accesses from that
CPU until you satisfy the current request. In order to see
multiple outstanding memory references you have to use multiple
CPUs and/or a non-blocking CPU such as O3.
I'm not sure about your second question... if you call the two-
argument version of sendTiming() (the one that takes a tick value
as the second argument) then all it does is schedule an event to
call the regular sendTiming() later at the specified tick.
(Actually it maintains a list of all the pending sendTiming() calls
and uses a single event that's timed to handle the first pending
call.) I don't see any reason why that wouldn't work when called
from MemoryPort.
FYI, in our current internal tree we've renamed the two-argument
version of sendTiming() to schedSendTiming() just to make the
distinction clearer. And we are supposedly getting closer to
resolving the issues that are keeping us from making that tree
public...
Steve
On 10/9/07, Jun Pang <[EMAIL PROTECTED]> wrote:
Hi Steve,
Thank you very much for your soon answer ！
I am still confused with the use of sendTiming in
SimpleTimingPort::recvTIming.
I don't want to send the packet from the recvTiming(pkt)
immediately, for example, I want to buffer a lot of packets,
schedule them, then select one of them to send to implement out-of-
order memory access. However, when I add some operation in
SimpleTimingPort:recvTiming() to control the execution of
sendTimng, I find that if sendTiming is not executed, then there is
no new packet coming from bus. If that is true, how to implement
the out-of-order scheduling?
Another question is that I find the sendTiming function can only be
called in the SimpleTimingPort::recvTiming other than a class
devrived from SimpleTimingPort, such as MemoryPort. If it is called
from a member function of MemoryPort, there is no new packet either
and the simulation stops. Could you also explain that?
Thank you very much!
Jun Pang
On 10/9/07, Steve Reinhardt < [EMAIL PROTECTED] > wrote:
Hi Jun,
Hard to know what's going wrong from your description. What
happens if you take your new code but keep the same fixed latency
as the old code? In that case the execution path should be
identical. Check out the util/tracediff script for a good way to
track down differences between two runs that should be doing the
same thing but aren't (see the comments at the top of the script
for usage info).
Also it might be easier to debug an SE-mode program first and make
sure that works before trying it under FS mode. You can use the
regression tests for example.
Steve
On 10/8/07, Jun Pang < [EMAIL PROTECTED] > wrote:
Hi,
I want to implement an out-of-order memory access scheduling with
M5 simulator 2.0.3 edition. First, I will put some packets in a
buffer and schedule it, then as soon as a latency of one packet is
obtained through my algorithm, it will be sent by calling
SimpleTimngPort::sendTiming. So, instead of called by
SimpleTimingPort::recvTiming in the tport.cc, the sendTiming is
called in my function and get a latency calculated by the function
as an argument of sendTiming However, when I recompile the source
and run the simulator in full system mode, the m5term cannot
connect the host and shows information as follows:
==== m5 slave console: Console 0 ====
What causes m5 to stop here? What's wrong with my implementation?
I wonder if I could put the sendTiming in somewhere else instead of
its original SimpleTimingPort::recvTiming. Thank you very much!
Jun Pang
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
_______________________________________________
m5-users mailing list
m5-users@m5sim.org
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
