> On June 24, 2015, 7:30 a.m., Andreas Hansson wrote:
> > src/mem/ruby/system/RubyPort.hh, line 191
> > <http://reviews.gem5.org/r/2911/diff/1/?file=46843#file46843line191>
> >
> > A port is not allowed to send a new request until it gets a retry, so
> > the assert is appropriate in this case.
OK. Either I'm missing something glaringly obvious, or there is a bug in the O3
model. Let me show you what I'm seeing.
Here is a very simple test that produces the problem:
build/X86_MESI_Two_Level/gem5.debug --debug-flags=LSQUnit,RubyPort
configs/example/se.py --cpu-type=detailed --ruby -c
tests/test-progs/hello/bin/x86/linux/hello
Here is a snippet of the debug output:
1> 480000: system.cpu.iew.lsq.thread0: Executing load PC
(0x415b57=>0x415b5b).(0=>1), [sn:171]
2> 480000: system.cpu.iew.lsq.thread0: Read called, load idx: 9, store
idx: 18, storeHead: 12 addr: 0x94e78
3> 480000: system.cpu.iew.lsq.thread0: Doing memory access for inst
[sn:171] PC (0x415b57=>0x415b5b).(0=>1)
4> 480000: system.ruby.l1_cntrl0.sequencer.slave1: Timing request for
address 0x94e78 on port 1
5> 480000: system.ruby.l1_cntrl0.sequencer.slave1: Request for address
0x94e78 did not issued because Aliased
6> 480000: system.cpu.iew.lsq.thread0: LQ size: 33, #loads occupied: 7
7> 480000: system.cpu.iew.lsq.thread0: SQ size: 33, #stores occupied: 7
8> 480500: system.cpu.iew.lsq.thread0: Inserting store PC
(0x415b77=>0x415b7e).(1=>2), idx:19 [sn:188]
9> 480500: system.cpu.iew.lsq.thread0: LQ size: 33, #loads occupied: 7
10> 480500: system.cpu.iew.lsq.thread0: SQ size: 33, #stores occupied: 8
11> 481000: system.cpu.iew.lsq.thread0: Executing load PC
(0x415b65=>0x415b68).(0=>1), [sn:176]
12> 481000: system.cpu.iew.lsq.thread0: Read called, load idx: 10, store
idx: 19, storeHead: 12 addr: 0x94e80
13> 481000: system.cpu.iew.lsq.thread0: Doing memory access for inst
[sn:176] PC (0x415b65=>0x415b68).(0=>1)
14> 481000: system.ruby.l1_cntrl0.sequencer.slave1: Timing request for
address 0x94e80 on port 1
15> 481000: system.ruby.l1_cntrl0.sequencer.slave1: Request ReadReq
0x94e80 issued
16> 481000: system.cpu.iew.lsq.thread0: Executing load PC
(0x415b6f=>0x415b73).(0=>1), [sn:184]
17> 481000: system.cpu.iew.lsq.thread0: Read called, load idx: 11, store
idx: 19, storeHead: 12 addr: 0x94e88
18> 481000: system.cpu.iew.lsq.thread0: Doing memory access for inst
[sn:184] PC (0x415b6f=>0x415b73).(0=>1)
19> 481000: system.ruby.l1_cntrl0.sequencer.slave1: Timing request for
address 0x94e88 on port 1
20> gem5.debug: build/X86_MESI_Two_Level/mem/ruby/system/RubyPort.hh:192:
void RubyPort::addToRetryList(RubyPort::MemSlavePort*): Assertion
`std::find(retryList.begin(), retryList.end(), port) == retryList.end()' failed.
21> Program aborted at cycle 481000
Annotations:
3> LSQ issues a load
5> Ruby finds the address aliases and returns false for sendTimingRequest (line
811: src/cpu/o3/lsq_unit.hh)
13> LSQ does another memory access (same function call) and it succeeds.
18> LSQ does another memory access (same function call) and it fails. This
causes Ruby to try to put the port on the retry list a second time and the
assert is triggered.
It seems to me that the O3CPU does not follow the invariant that "A port is not
allowed to send a new request until it gets a retry". Am I missing something
here?
- Jason
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2911/#review6580
-----------------------------------------------------------
On June 23, 2015, 9:52 p.m., Jason Power wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2911/
> -----------------------------------------------------------
>
> (Updated June 23, 2015, 9:52 p.m.)
>
>
> Review request for Default.
>
>
> Repository: gem5
>
>
> Description
> -------
>
> Changeset 10875:e15eea749253
> ---------------------------
> Ruby: Remove assert in RubyPort retry list logic
>
> Remove the assert when adding a port to the RubyPort retry list.
> Instead of asserting, just ignore the added port, since it's
> already on the list.
> Without this patch, Ruby+detailed fails for even the simplest tests
>
>
> Diffs
> -----
>
> src/mem/ruby/system/RubyPort.hh e4f63f1d502d
>
> Diff: http://reviews.gem5.org/r/2911/diff/
>
>
> Testing
> -------
>
> build/X86_MESI_Two_Level/gem5.debug configs/example/se.py --cpu-type=detailed
> --ruby -c tests/test-progs/hello/bin/x86/linux/hello now runs to completion.
>
> Note: this is compatible (and required) with http://reviews.gem5.org/r/2787/
> as well.
>
>
> Thanks,
>
> Jason Power
>
>
_______________________________________________
gem5-dev mailing list
[email protected]
http://m5sim.org/mailman/listinfo/gem5-dev