Not sure how the simpoints work but for things like
"max_insts_all_threads" you can really just test them out to make sure
you get what you expect.
Use the default Hello World example and test out those type
configurations such as:
"m5.opt configs/example/se.py"
(assuming your script already has the max_insts set to a #")
Set it to a low # like 100, and see if you get what you expect.
Also, it's a script so feel free to just add your own command line
option by borrowing from the example code above in the
script...Something like:
"parser.add_option("....")" [follow example]
can add a "maxinstsall" option for you on the command line so you can say:
"m5.opt configs/example/se.py --maxinstsall=100"
And to answer your question directly, yes, setting the value there
should work or you could also set it via the CPUClass variable in the
script similar to how the clock is set by "CPUClass.clock = ____".
Hopefully that helps (but it might be a big ramble),
Korey
On Wed, May 6, 2009 at 12:28 PM, Javier Jose <[email protected]> wrote:
> Hi Ali,
>
> Thanks! That was the problem! Also, two quick questions:
>
> system.cpu[i].max_insts_all_threads = 100000000 <-- Is this the correct way
> of using max_insts_all_threads?
>
> Is process.simpoint = [simpoint] the correct way of inserting simpoints when
> setting multiple processes? I know you can enter it through the command line
> when calling build/ALPHA_SE/m5.debug as per:
> http://www.m5sim.org/dist/tutorials/asplos_pres.pdf, but the examples there
> assume one benchmark (one thread).
>
>
> NEW CMD LINE examples (For Reference):
> smt_process2 = LiveProcess()
> smt_process2.executable = 'cpu2000/binaries/galgel00.peak.ev6'
> smt_process2.cmd =
> ['cpu2000/binaries/galgel00.peak.ev6','cpu2000/data/galgel/input/galgel.in']
> smt_process2.input = 'cpu2000/data/galgel/input/galgel.in'
> smt_process2.simpoint = 2491*100E6
> process += [smt_process2, ]
>
> smt_process2 = LiveProcess()
> smt_process2.executable = 'cpu2000/binaries/equake00.peak.ev6'
> smt_process2.cmd =
> ['cpu2000/binaries/equake00.peak.ev6','cpu2000/data/equake/input/inp.in']
> smt_process2.input = 'cpu2000/data/equake/input/inp.in'
> smt_process2.simpoint = 812*100E6
> process += [smt_process2, ]
>
>
> Javier
>
>
> On Wed, May 6, 2009 at 10:06 AM, <[email protected]> wrote:
>>
>> Send m5-users mailing list submissions to
>> [email protected]
>>
>> To subscribe or unsubscribe via the World Wide Web, visit
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> or, via email, send a message with subject or body 'help' to
>> [email protected]
>>
>> You can reach the person managing the list at
>> [email protected]
>>
>> When replying, please edit your Subject line so it is more specific
>> than "Re: Contents of m5-users digest..."
>>
>>
>> Today's Topics:
>>
>> 1. Re: problem with newly compiled 2.6.27 kernel (Steve Reinhardt)
>> 2. Command Line Errors running SPEC CPU2000 benchmarks (Javier Jose)
>> 3. Re: Command Line Errors running SPEC CPU2000 benchmarks
>> (Ali Saidi)
>> 4. Re: problem with newly compiled 2.6.27 kernel (Ali Saidi)
>> 5. Re: Range Error (Geoffrey Blake)
>> 6. Re: Range Error (nathan binkert)
>>
>>
>> ----------------------------------------------------------------------
>>
>> Message: 1
>> Date: Tue, 5 May 2009 08:54:48 -0700
>> From: Steve Reinhardt <[email protected]>
>> Subject: Re: [m5-users] problem with newly compiled 2.6.27 kernel
>> To: M5 users mailing list <[email protected]>
>> Message-ID:
>> <[email protected]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> BTW, this is using ts_osfpal, not tsb_osfpal, which is why I didn't expect
>> BIG_TSUNAMI to be needed.
>>
>> On Tue, May 5, 2009 at 8:53 AM, Steve Reinhardt <[email protected]> wrote:
>>
>> > Thanks, that helps a lot... I must have missed that email. It works
>> > now,
>> > but only if I set CONFIG_BIG_TSUNAMI=y. (The .config.m5 in the patch
>> > queue
>> > doesn't set this either way, so you have to pick one when you build.)
>> > If I
>> > don't set it, the console output ends like this:
>> >
>> > hda: M5 IDE Disk, ATA DISK drive
>> > hdb: M5 IDE Disk, ATA DISK drive
>> > hda: UDMA/33 mode selected
>> > hdb: UDMA/33 mode selected
>> > ide0 at 0x8410-0x8417,0x8422 on irq 15
>> > ide1 at 0x8418-0x841f,0x8426 on irq 15
>> > ide_generic: please use "probe_mask=0x3f" module parameter for probing
>> > all
>> > legacy ISA IDE ports
>> > ide2: probed IRQ 14 and default IRQ 14 failed
>> > ide2: failed to initialize IDE interface
>> > ide3: potential IRQ problem with ide1 and ide0
>> > ide3 at 0x170-0x177,0x376 on irq 15 (shared with ide0)
>> > hda: max request size: 128KiB
>> > hda: 101808 sectors (52 MB), CHS=101/16/63
>> > hda:<4>hda: lost interrupt
>> > hda: lost interrupt
>> > hda: lost interrupt
>> > hda: dma_timer_expiry: dma status == 0x64
>> > hda: DMA interrupt recovery
>> > hda: lost interrupt
>> > hda1
>> > hdb: max request size: 128KiB
>> > hdb: 4177920 sectors (2139 MB), CHS=4144/16/63
>> > hdb:<4>hdb: lost interrupt
>> > hdb: lost interrupt
>> >
>> >
>> > Steve
>> >
>> >
>> > On Tue, May 5, 2009 at 5:56 AM, Ali Saidi <[email protected]> wrote:
>> >
>> >> GCC 4.1 generates invalid code. You need to use 4.3. I have a post on
>> >> the
>> >> m5 mailing list a few months ago where I discussed the particular issue
>> >> in
>> >> detail, but it has to do with dependence analysis across call pal's
>> >> being
>> >> completely broken with gcc 4.0-4.2.
>> >>
>> >> Ali
>> >>
>> >>
>> >
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://m5sim.org/cgi-bin/mailman/private/m5-users/attachments/20090505/50daba5d/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 2
>> Date: Tue, 5 May 2009 15:09:41 -0500
>> From: Javier Jose <[email protected]>
>> Subject: [m5-users] Command Line Errors running SPEC CPU2000
>> benchmarks
>> To: [email protected]
>> Message-ID:
>> <[email protected]>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Hi everyone,
>>
>> I am running SPEC CPU2000 benchmarks with O3. However, some benchmarks:
>> crafty, equake and swim, ammp, applu don't run correctly. Except for
>> crafty
>> which actually gives an error message the rest seem to just stop running
>> becuase when I run "top" I see the m5.debug process get's killed and the
>> terminal freezes.
>>
>> This is how I am setting up the processes ( I have run them individually
>> and
>> in SMT mode and the result is the same):
>>
>> smt_process2 = LiveProcess()
>> smt_process2.executable = 'cpu2000/binaries/crafty00.peak.ev6'
>> smt_process2.cmd =
>> ['cpu2000/binaries/crafty00.peak.ev6','<','cpu2000/data/crafty/input/
>>
>> crafty.in','>','cpu2000/data/crafty/output/crafty.out','2>','cpu2000/data/crafty/output/crafty.err'
>> ]
>> smt_process2.simpoint = 774 * 100E6
>> process += [smt_process2, ]
>>
>> smt_process2 = LiveProcess()
>> smt_process2.executable = 'cpu2000/binaries/equake00.peak.ev6'
>> smt_process2.cmd =
>>
>> ['cpu2000/binaries/equake00.peak.ev6','<','cpu2000/data/equake/input/inp.in',
>> '>', 'cpu2000/data/output/inp.out', '2>',
>> 'cpu2000/data/equake/output/inp.err']
>> smt_process2.simpoint = 812*100E6
>> process += [smt_process2, ]
>>
>> smt_process2 = LiveProcess()
>> smt_process2.executable = 'cpu2000/binaries/swim00.peak.ev6'
>> smt_process2.cmd =
>>
>> ['cpu2000/binaries/swim00.peak.ev6','<','cpu2000/data/swim/input/swim.in','>','cpu2000/data/swim/output/swim.out','2>','cpu2000/data/swim/output/swim.err'
>> ]
>> smt_process2.simpoint = 2079*100E6
>> process += [smt_process2, ]
>>
>> smt_process2 = LiveProcess()
>> smt_process2.executable = 'cpu2000/binaries/ammp00.peak.ev6'
>> smt_process2.cmd =
>>
>> ['cpu2000/binaries/ammp00.peak.ev6','<','cpu2000/data/ammp/input/ammp.in','>','cpu2000/data/ammp/output/ammp.out','2>','cpu2000/data/ammp/output/ammp.err'
>> ]
>> smt_process2.simpoint = 108*100E6
>> process += [smt_process2, ]
>>
>> smt_process2 = LiveProcess()
>> smt_process2.executable = 'cpu2000/binaries/applu00.peak.ev6'
>> smt_process2.cmd =
>>
>> ['cpu2000/binaries/applu00.peak.ev6','<','cpu2000/data/applu/input/applu.in','>','cpu2000/data/applu/output/applu.out','2>','cpu2000/data/applu/output/applu.err'
>> ]
>> smt_process2.simpoint = 2179*100E6
>> process += [smt_process2, ]
>>
>>
>> I am sure the problem is on how it is interpreting the 'cmd', since they
>> run
>> fine in simplescalar and I've had similar problems with ALPBench and other
>> benchmarks, but I can't really get around these.
>>
>> The error message from Crafty is the following:
>>
>> **** REAL SIMULATION ****
>> info: Entering event queue @ 0. Starting simulation...
>> info: Increasing stack size by one page.
>>
>> Crafty v14.3
>>
>> ERROR "<" is unknown command-line option
>> ERROR "crafty.in" is unknown command-line option
>> ERROR ">" is unknown command-line option
>> ERROR "crafty.out" is unknown command-line option
>> ERROR "crafty.err" is unknown command-line option
>> White(1):
>>
>> I'd appreciate the help.
>>
>> Another quick question: system.cpu[i].max_insts_all_threads = 100000000
>> <--
>> Is this the correct way of using max_insts_all_threads?
>>
>> Thanks,
>>
>> Javier
>> Texas A&M University
>> Computer Science and Engineering Department
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> http://m5sim.org/cgi-bin/mailman/private/m5-users/attachments/20090505/9829ef64/attachment-0001.htm
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Tue, 5 May 2009 19:13:41 -0500
>> From: Ali Saidi <[email protected]>
>> Subject: Re: [m5-users] Command Line Errors running SPEC CPU2000
>> benchmarks
>> To: M5 users mailing list <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> You shouldn't use pipes (<, >) for the input, output and err output.
>> You should set the processes input, output, errout properties instead.
>>
>> Ali
>>
>> On May 5, 2009, at 3:09 PM, Javier Jose wrote:
>>
>> > Hi everyone,
>> >
>> > I am running SPEC CPU2000 benchmarks with O3. However, some
>> > benchmarks: crafty, equake and swim, ammp, applu don't run
>> > correctly. Except for crafty which actually gives an error message
>> > the rest seem to just stop running becuase when I run "top" I see
>> > the m5.debug process get's killed and the terminal freezes.
>> >
>> > This is how I am setting up the processes ( I have run them
>> > individually and in SMT mode and the result is the same):
>> >
>> > smt_process2 = LiveProcess()
>> > smt_process2.executable = 'cpu2000/binaries/crafty00.peak.ev6'
>> > smt_process2.cmd = ['cpu2000/binaries/
>> > crafty00.peak.ev6','<','cpu2000/data/crafty/input/
>> > crafty.in','>','cpu2000/data/crafty/output/crafty.out','2>','cpu2000/
>> > data/crafty/output/crafty.err' ]
>> > smt_process2.simpoint = 774 * 100E6
>> > process += [smt_process2, ]
>> >
>> > smt_process2 = LiveProcess()
>> > smt_process2.executable = 'cpu2000/binaries/equake00.peak.ev6'
>> > smt_process2.cmd = ['cpu2000/binaries/
>> > equake00.peak.ev6','<','cpu2000/data/equake/input/inp.in', '>',
>> > 'cpu2000/data/output/inp.out', '2>', 'cpu2000/data/equake/output/
>> > inp.err']
>> > smt_process2.simpoint = 812*100E6
>> > process += [smt_process2, ]
>> >
>> > smt_process2 = LiveProcess()
>> > smt_process2.executable = 'cpu2000/binaries/swim00.peak.ev6'
>> > smt_process2.cmd = ['cpu2000/binaries/swim00.peak.ev6','<','cpu2000/
>> > data/swim/input/swim.in','>','cpu2000/data/swim/output/
>> > swim.out','2>','cpu2000/data/swim/output/swim.err' ]
>> > smt_process2.simpoint = 2079*100E6
>> > process += [smt_process2, ]
>> >
>> > smt_process2 = LiveProcess()
>> > smt_process2.executable = 'cpu2000/binaries/ammp00.peak.ev6'
>> > smt_process2.cmd = ['cpu2000/binaries/ammp00.peak.ev6','<','cpu2000/
>> > data/ammp/input/ammp.in','>','cpu2000/data/ammp/output/
>> > ammp.out','2>','cpu2000/data/ammp/output/ammp.err' ]
>> > smt_process2.simpoint = 108*100E6
>> > process += [smt_process2, ]
>> >
>> > smt_process2 = LiveProcess()
>> > smt_process2.executable = 'cpu2000/binaries/applu00.peak.ev6'
>> > smt_process2.cmd = ['cpu2000/binaries/applu00.peak.ev6','<','cpu2000/
>> > data/applu/input/applu.in','>','cpu2000/data/applu/output/
>> > applu.out','2>','cpu2000/data/applu/output/applu.err' ]
>> > smt_process2.simpoint = 2179*100E6
>> > process += [smt_process2, ]
>> >
>> >
>> > I am sure the problem is on how it is interpreting the 'cmd', since
>> > they run fine in simplescalar and I've had similar problems with
>> > ALPBench and other benchmarks, but I can't really get around these.
>> >
>> > The error message from Crafty is the following:
>> >
>> > **** REAL SIMULATION ****
>> > info: Entering event queue @ 0. Starting simulation...
>> > info: Increasing stack size by one page.
>> >
>> > Crafty v14.3
>> >
>> > ERROR "<" is unknown command-line option
>> > ERROR "crafty.in" is unknown command-line option
>> > ERROR ">" is unknown command-line option
>> > ERROR "crafty.out" is unknown command-line option
>> > ERROR "crafty.err" is unknown command-line option
>> > White(1):
>> >
>> > I'd appreciate the help.
>> >
>> > Another quick question: system.cpu[i].max_insts_all_threads =
>> > 100000000 <-- Is this the correct way of using max_insts_all_threads?
>> >
>> > Thanks,
>> >
>> > Javier
>> > Texas A&M University
>> > Computer Science and Engineering Department
>> > _______________________________________________
>> > m5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Wed, 6 May 2009 08:38:19 -0500
>> From: Ali Saidi <[email protected]>
>> Subject: Re: [m5-users] problem with newly compiled 2.6.27 kernel
>> To: M5 users mailing list <[email protected]>
>> Message-ID: <[email protected]>
>> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
>>
>> I've never seen that, although I always use big_tsunami. The primary
>> difference between the two is how interrupts are handled. It's
>> possible that there is another compiler issue with that code.
>>
>> Ali
>>
>>
>>
>> On May 5, 2009, at 10:53 AM, Steve Reinhardt wrote:
>>
>> > Thanks, that helps a lot... I must have missed that email. It works
>> > now, but only if I set CONFIG_BIG_TSUNAMI=y. (The .config.m5 in the
>> > patch queue doesn't set this either way, so you have to pick one
>> > when you build.) If I don't set it, the console output ends like
>> > this:
>> >
>> > hda: M5 IDE Disk, ATA DISK drive
>> > hdb: M5 IDE Disk, ATA DISK drive
>> > hda: UDMA/33 mode selected
>> > hdb: UDMA/33 mode selected
>> > ide0 at 0x8410-0x8417,0x8422 on irq 15
>> > ide1 at 0x8418-0x841f,0x8426 on irq 15
>> > ide_generic: please use "probe_mask=0x3f" module parameter for
>> > probing all legacy ISA IDE ports
>> > ide2: probed IRQ 14 and default IRQ 14 failed
>> > ide2: failed to initialize IDE interface
>> > ide3: potential IRQ problem with ide1 and ide0
>> > ide3 at 0x170-0x177,0x376 on irq 15 (shared with ide0)
>> > hda: max request size: 128KiB
>> > hda: 101808 sectors (52 MB), CHS=101/16/63
>> > hda:<4>hda: lost interrupt
>> > hda: lost interrupt
>> > hda: lost interrupt
>> > hda: dma_timer_expiry: dma status == 0x64
>> > hda: DMA interrupt recovery
>> > hda: lost interrupt
>> > hda1
>> > hdb: max request size: 128KiB
>> > hdb: 4177920 sectors (2139 MB), CHS=4144/16/63
>> > hdb:<4>hdb: lost interrupt
>> > hdb: lost interrupt
>> >
>> >
>> > Steve
>> >
>> > On Tue, May 5, 2009 at 5:56 AM, Ali Saidi <[email protected]> wrote:
>> > GCC 4.1 generates invalid code. You need to use 4.3. I have a post
>> > on the m5 mailing list a few months ago where I discussed the
>> > particular issue in detail, but it has to do with dependence
>> > analysis across call pal's being completely broken with gcc 4.0-4.2.
>> >
>> > Ali
>> >
>> >
>> > _______________________________________________
>> > m5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>>
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Wed, 6 May 2009 10:23:22 -0400
>> From: "Geoffrey Blake" <[email protected]>
>> Subject: Re: [m5-users] Range Error
>> To: "'M5 users mailing list'" <[email protected]>
>> Message-ID: <001801c9ce56$36149e40$a23dda...@edu>
>> Content-Type: text/plain; charset="us-ascii"
>>
>> Yes, that extra bridge is the cause. What is happening is that the bridge
>> is
>> being probed by l3bus which then probes l3bus2 for address ranges, l3bus2
>> probes the L3 cache for ranges as will l3bus a some point, both probes to
>> the bridge and the L3 cache will return the same address range at some
>> point
>> causing the error. The way address range propagation is handled currently
>> disallows more than 1 path to a device that responds to memory address
>> ranges, which is what that extra bridge is causing (2 possible paths to
>> get
>> to the L3 cache and underlying physmem). You will either have to just
>> limit
>> your experimentation to not doing this, or muck with the address range
>> propagation code in bus.cc to allow multiple paths.
>>
>> Geoff
>>
>> -----Original Message-----
>> From: [email protected] [mailto:[email protected]] On
>> Behalf Of Shoaib Akram
>> Sent: Monday, May 04, 2009 3:54 PM
>> To: M5 users mailing list
>> Subject: Re: [m5-users] Range Error
>>
>> I have attached a diagram(pdf file) of configuration and fs2.py. Please
>> note
>> that the problem occurs because of l3Bridge (commented in fs2.py).
>>
>> Ofcourse, I have a solution to maintain coherence at the back end.
>>
>> ---- Original message ----
>> >Date: Mon, 4 May 2009 15:04:57 -0400
>> >From: "Geoffrey Blake" <[email protected]>
>> >Subject: Re: [m5-users] Range Error
>> >To: "'M5 users mailing list'" <[email protected]>
>> >
>> >If you haven't modified any code, it is most likely with how your fs.py
>> >configures the devices. You have to make sure no device can pass its
>> >address range back through multiple paths (ie. devices cannot be
>> >connected to multiple bridges that connect to one bus), and no two
>> >devices have the same address ranges set. The best way is to post your
>> >fs.py file so some here can help if they are able.
>> >
>> >Geoff
>> >
>> >-----Original Message-----
>> >From: [email protected] [mailto:[email protected]] On
>> >Behalf Of Shoaib Akram
>> >Sent: Monday, May 04, 2009 2:40 PM
>> >To: [email protected]
>> >Subject: [m5-users] Range Error
>> >
>> >I am getting a "Two devices with same range" error. I have never been
>> >involved with the Range business. Can some one give hints as to where
>> >to look for the problem. I am running fs.py with a few extra bridges.
>> >Is this problem need to be resolved at the front-end or tweaking bus.cc?
>> >_______________________________________________
>> >m5-users mailing list
>> >[email protected]
>> >http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >
>> >
>> >
>> >No virus found in this incoming message.
>> >Checked by AVG - www.avg.com
>> >Version: 8.5.287 / Virus Database: 270.12.16/2094 - Release Date:
>> >05/03/09 16:51:00
>> >
>> >_______________________________________________
>> >m5-users mailing list
>> >[email protected]
>> >http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>> No virus found in this incoming message.
>> Checked by AVG - www.avg.com
>> Version: 8.5.287 / Virus Database: 270.12.19/2099 - Release Date: 05/05/09
>> 13:07:00
>>
>>
>>
>> ------------------------------
>>
>> Message: 6
>> Date: Wed, 6 May 2009 08:00:39 -0700
>> From: nathan binkert <[email protected]>
>> Subject: Re: [m5-users] Range Error
>> To: M5 users mailing list <[email protected]>
>> Message-ID:
>> <[email protected]>
>> Content-Type: text/plain; charset=ISO-8859-1
>>
>> The bus bridge code has the "filter_ranges_a" and "filter_ranges_b"
>> parameters. These were intended for this sort of case and can be used
>> to disallow bridges from propagating certain addresses. I'm not sure
>> if this can fix the exact problem since I haven't followed this thread
>> closely, but it's certainly a place to start.
>>
>> Nate
>>
>> On Wed, May 6, 2009 at 7:23 AM, Geoffrey Blake <[email protected]> wrote:
>> > Yes, that extra bridge is the cause. What is happening is that the
>> > bridge is
>> > being probed by l3bus which then probes l3bus2 for address ranges,
>> > l3bus2
>> > probes the L3 cache for ranges as will l3bus a some point, both probes
>> > to
>> > the bridge and the L3 cache will return the same address range at some
>> > point
>> > causing the error. ?The way address range propagation is handled
>> > currently
>> > disallows more than 1 path to a device that responds to memory address
>> > ranges, which is what that extra bridge is causing (2 possible paths to
>> > get
>> > to the L3 cache and underlying physmem). You will either have to just
>> > limit
>> > your experimentation to not doing this, or muck with the address range
>> > propagation code in bus.cc to allow multiple paths.
>> >
>> > Geoff
>> >
>> > -----Original Message-----
>> > From: [email protected] [mailto:[email protected]] On
>> > Behalf Of Shoaib Akram
>> > Sent: Monday, May 04, 2009 3:54 PM
>> > To: M5 users mailing list
>> > Subject: Re: [m5-users] Range Error
>> >
>> > I have attached a diagram(pdf file) of configuration and fs2.py. Please
>> > note
>> > that the problem occurs because of l3Bridge (commented in fs2.py).
>> >
>> > Ofcourse, I have a solution to maintain coherence at the back end.
>> >
>> > ---- Original message ----
>> >>Date: Mon, 4 May 2009 15:04:57 -0400
>> >>From: "Geoffrey Blake" <[email protected]>
>> >>Subject: Re: [m5-users] Range Error
>> >>To: "'M5 users mailing list'" <[email protected]>
>> >>
>> >>If you haven't modified any code, it is most likely with how your fs.py
>> >>configures the devices. ?You have to make sure no device can pass its
>> >>address range back through multiple paths (ie. devices cannot be
>> >>connected to multiple bridges that connect to one bus), and no two
>> >>devices have the same address ranges set. The best way is to post your
>> >>fs.py file so some here can help if they are able.
>> >>
>> >>Geoff
>> >>
>> >>-----Original Message-----
>> >>From: [email protected] [mailto:[email protected]] On
>> >>Behalf Of Shoaib Akram
>> >>Sent: Monday, May 04, 2009 2:40 PM
>> >>To: [email protected]
>> >>Subject: [m5-users] Range Error
>> >>
>> >>I am getting a "Two devices with same range" error. I have never been
>> >>involved with the Range business. Can some one give hints as to where
>> >>to look for the problem. I am running fs.py with a few extra bridges.
>> >>Is this problem need to be resolved at the front-end or tweaking bus.cc?
>> >>_______________________________________________
>> >>m5-users mailing list
>> >>[email protected]
>> >>http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >>
>> >>
>> >>
>> >>No virus found in this incoming message.
>> >>Checked by AVG - www.avg.com
>> >>Version: 8.5.287 / Virus Database: 270.12.16/2094 - Release Date:
>> >>05/03/09 16:51:00
>> >>
>> >>_______________________________________________
>> >>m5-users mailing list
>> >>[email protected]
>> >>http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >
>> > No virus found in this incoming message.
>> > Checked by AVG - www.avg.com
>> > Version: 8.5.287 / Virus Database: 270.12.19/2099 - Release Date:
>> > 05/05/09
>> > 13:07:00
>> >
>> > _______________________________________________
>> > m5-users mailing list
>> > [email protected]
>> > http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>> >
>> >
>>
>>
>> ------------------------------
>>
>> _______________________________________________
>> m5-users mailing list
>> [email protected]
>> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>>
>> End of m5-users Digest, Vol 34, Issue 8
>> ***************************************
>
>
> _______________________________________________
> m5-users mailing list
> [email protected]
> http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
>
--
===========
Korey L Sewell
PhD Candidate
Computer Science & Engineering
University of Michigan
_______________________________________________
m5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
