This should now be fixed.

Gabe

On 02/03/12 22:38, Steve Reinhardt wrote:
> More motivation for trying to incorporate the config scripts in the
> regressions somehow...
>
> On Fri, Feb 3, 2012 at 4:04 PM, Ali Saidi <[email protected]
> <mailto:[email protected]>> wrote:
>
>     The regressions pass, so it still works, it's simply a
>     configuration issue with the generic scripts. The bridges used to
>     be bi-directional and now they're uni-directional. Previously,
>     when an i/o cache was added to a configuration filtering ranges
>     had to be setup on the bridge to only allow traffic from one
>     direction to flow through it (thus the requests would flow through
>     the I/O cache). With the new changes the bridges are
>     un-directional so in the no-caches case another bridge is required
>     to allow requests to flow both directions in the case that no
>     caches are present in the system. The issue with x86 is that it's
>     not simply that uncached I/O flows into the i/o bus and the i/o
>     devices dma to main memory. There is a third class, interrupt
>     messages. To handle this x86 inserts a bridge makex86LinuxSystem()
>     that allows the messages to flow out of the i/o bus, however the
>     other ISAs need a bridge now too, which happens to be named the
>     same thing. I'm pretty sure just changing the name of the bridge
>     in makex86LinuxSystem will do it (it appears to work for me).
>
>      
>
>     diff -r 223945df5510 configs/common/FSConfig.py
>     --- a/configs/common/FSConfig.py    Fri Feb 03 09:48:10 2012 -0800
>     +++ b/configs/common/FSConfig.py    Fri Feb 03 18:03:27 2012 -0600
>     @@ -385,10 +385,10 @@
>
>
>          # Create a bridge from the IO bus to the memory bus to allow access 
> to
>          # the local APIC (two pages)
>     -    x86_sys.iobridge = Bridge(delay='50ns', nack_delay='4ns')
>     -    x86_sys.iobridge.slave = x86_sys.iobus.port
>
>     -    x86_sys.iobridge.master = x86_sys.membus.port
>     -    x86_sys.iobridge.ranges = [AddrRange(interrupts_address_space_base,
>     +    x86_sys.apicbridge = Bridge(delay='50ns', nack_delay='4ns')
>     +    x86_sys.apicbridge.slave = x86_sys.iobus.port
>
>     +    x86_sys.apicbridge.master = x86_sys.membus.port
>     +    x86_sys.apicbridge.ranges = [AddrRange(interrupts_address_space_base,
>                                               interrupts_address_space_base +
>                                               APIC_range_size - 1)]
>
>
>                                                                               
>
>      
>
>     Ali
>
>      
>
>      
>
>      
>
>     On 03.02.2012 15:17, Gabriel Michael Black wrote:
>
>>     So, my question is/questions are, what was this code doing before that  
>>     was working? What's it doing now that's different that makes it not  
>>     work? Why is it doing it that way instead of the way that worked before?
>>
>>     Gabe
>>
>>     Quoting Ali Saidi <[email protected] <mailto:[email protected]>>:
>>>     Hmm.. I'm very surprised this works. The correct solution is to
>>>     do something like: if test_sys.iobridge:
>>>     test_sys.iobridge.ranges.append(AddrRange(mem_size)) else:
>>>     #instaniate a bridge A third option may be to just all the x86
>>>     bridge something else ioapic_bridge and have two bridges (one
>>>     handling each range). Ali On 03.02.2012 01:43, Joel Hestness wrote:
>>>>     Hey guys,
>>>>     Just ran into this myself. The IO bridge is being instantiated
>>>>     twice,
>>>     once in FSConfig.py and again in the fs.py file. I was able to
>>>     fix it for X86_FS simply by adding an if clause in the fs.py
>>>     file (line 166) where it is instantiated the second time:
>>>>     if not test_sys.iobridge:
>>>>     test_sys.iobridge = Bridge(delay='50ns', nack_delay='4ns',
>>>     ranges = [AddrRange(mem_size)])
>>>>     test_sys.iobridge.slave =
>>>     test_sys.iobus.port
>>>>     test_sys.iobridge.master = test_sys.membus.port
>>>>     I'm not sure if this would upset other architectures though. Joel
>>>>     On Fri, Feb 3, 2012 at 12:48 AM, Gabe Black
>>>>     <[email protected] <mailto:[email protected]>
>>>     [7]> wrote:
>>>>>     I got this error too just now. It looks like it may
>>>     have something to do
>>>>>     with the port/bus/bridge changes that have gone
>>>     in recently.
>>>>>     On 02/02/12 21:54, Trang Le wrote:
>>>>>>     Hi,
>>>>     I just updated to the latest version of gem5 and noticed the
>>>>     merge of
>>>     SE and FS mode. I attempted to compile and run x86 FS mode using
>>>     the following commands:
>>>>>>     scons build/X86/gem5.opt
>>>     build/X86/gem5.opt configs/example/fs.py
>>>>>>     When i tried to run,
>>>     i encountered the following error
>>>     message:=============================================================
>>>
>>>>>>     gem5
>>>     Simulator System. http://gem5.org[1]
>>>>>>     gem5 is copyrighted software;
>>>     use the --copyright option for details.
>>>>>>     gem5 compiled Feb 1
>>>     2012 21:57:18
>>>>>>     gem5 started Feb 2 2012 23:18:06 gem5 executing
>>>     on camsin6
>>>>>>     command line: build/X86/gem5.opt
>>>     configs/example/fs.py
>>>>>>     warning: add_child('terminal'): child
>>>     'terminal' already has parent
>>>>>>     Global frequency set at 1000000000000
>>>     ticks per second
>>>>>>     0: rtc: Real-time clock set to Sun Jan 1 00:00:00
>>>     2012
>>>>>>     Listening for com_1 connection on port 3456 Error
>>>     connecting port system.membus.port to .master
>>>>>>     Traceback (most
>>>     recent call last):
>>>>>>     File "", line 1, in File
>>>     "/home/tkl245/gem5/src/python/m5/main.py", line 357, in main
>>>>>>     exec
>>>     filecode in scope
>>>>>>     File "configs/example/fs.py", line 215, in
>>>     Simulation.run(options, root, test_sys, FutureClass)
>>>>>>     File
>>>     "/home/tkl245/gem5/configs/common/Simulation.py", line 245, in
>>>     runm5.instantiate(checkpoint_dir)
>>>>>>     File
>>>     "/home/tkl245/gem5/src/python/m5/simulate.py", line 91, in
>>>     instantiate
>>>>>>     for obj in root.descendants(): obj.connectPorts()
>>>     File "/home/tkl245/gem5/src/python/m5/SimObject.py", line 1003,
>>>     in connectPorts
>>>>>>     portRef.ccConnect() File
>>>     "/home/tkl245/gem5/src/python/m5/params.py", line 1485, in
>>>     ccConnect
>>>>     [el.ccConnect() for el in self.elements]
>>>>>>     File
>>>     "/home/tkl245/gem5/src/python/m5/params.py", line 1407, in
>>>     ccConnect
>>>>     peer.simobj.getCCObject(), peer.name <http://peer.name> [2],
>>>>     peer.index)
>>>>>>     File
>>>     "/home/tkl245/gem5/src/python/m5/SimObject.py", line 974, in
>>>     getCCObject
>>>>>>     raise RuntimeError, "Attempt to instantiate orphan
>>>     node"
>>>>>>     RuntimeError: Attempt to instantiate orphan node
>>>     =================================================================
>>>>>>     Do you have any idea what this error might be?
>>>     Thanks,
>>>>>>     -Trang
>>>     _______________________________________________
>>>>>>     gem5-users mailing
>>>     list
>>>>>>     [email protected] <mailto:[email protected]> [3]
>>>     
>>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users[4]_______________________________________________
>>>
>>>>>     gem5-users mailing
>>>     list
>>>>>     [email protected] <mailto:[email protected]> [5]
>>>     http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users[6]
>>>>     -- Joel
>>>     Hestness
>>>>     PhD Student, Computer Architecture Dept. of Computer
>>>     Science, University of Texas -
>>>     Austinhttp://www.cs.utexas.edu/~hestness
>>>     <http://www.cs.utexas.edu/%7Ehestness> [8] Links: ------ [1]
>>>     http://gem5.org [2] http://peer.name [3]
>>>     mailto:[email protected] <mailto:[email protected]> [4]
>>>     http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [5]
>>>     mailto:[email protected] <mailto:[email protected]> [6]
>>>     http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [7]
>>>     mailto:[email protected] <mailto:[email protected]> [8]
>>>     http://www.cs.utexas.edu/~hestness
>>>     <http://www.cs.utexas.edu/%7Ehestness>
>>     _______________________________________________
>>     gem5-users mailing list
>>     [email protected] <mailto:[email protected]>
>>     http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>>
>      
>
>      
>
>     _______________________________________________
>     gem5-users mailing list
>     [email protected] <mailto:[email protected]>
>     http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
>
>
>
> _______________________________________________
> gem5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to