[m5-dev] Cron m5test@zizzer /z/m5/regression/do-regression quick
scons: *** Found dependency cycle(s): * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_hammer passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-timing-mp passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/30.eio-mp/alpha/eio/simple-atomic-mp passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/20.eio-short/alpha/eio/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby passed. * build/ALPHA_SE/tests/fast/quick/01.hello-2T-smt/alpha/linux/o3-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-atomic passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/tru64/simple-timing passed. * build/ALPHA_SE/tests/fast/quick/60.rubytest/alpha/linux/rubytest-ruby passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/o3-timing passed. * build/ALPHA_SE/tests/fast/quick/00.hello/alpha/linux/inorder-timing passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic-dual passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-timing-dual passed. * build/ALPHA_FS/tests/fast/quick/10.linux-boot/alpha/linux/tsunami-simple-atomic passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_SE_MOESI_CMP_token/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_token passed. * build/ALPHA_FS/tests/fast/quick/80.netperf-stream/alpha/linux/twosys-tsunami-simple-atomic passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/tru64/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE_MOESI_CMP_directory/tests/fast/quick/00.hello/alpha/linux/simple-timing-ruby-MOESI_CMP_directory passed. * build/ALPHA_SE/tests/fast/quick/50.memtest/alpha/linux/memtest passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing-ruby passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-atomic passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/simple-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/o3-timing passed. * build/MIPS_SE/tests/fast/quick/00.hello/mips/linux/inorder-timing passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/simple-atomic passed. * build/POWER_SE/tests/fast/quick/00.hello/power/linux/o3-timing passed. * build/ALPHA_SE_MOESI_hammer/tests/fast/quick/50.memtest/alpha/linux/memtest-ruby-MOESI_hammer passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing-ruby passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-atomic passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/simple-timing passed. * build/ARM_SE/tests/fast/quick/00.hello/arm/linux/simple-timing passed. * build/ARM_SE/tests/fast/quick/00.hello/arm/linux/simple-atomic passed. * build/ARM_SE/tests/fast/quick/00.hello/arm/linux/o3-timing passed. * build/X86_SE/tests/fast/quick/00.hello/x86/linux/o3-timing passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-timing-mp passed. * build/SPARC_SE/tests/fast/quick/00.hello/sparc/linux/simple-timing passed. * build/SPARC_SE/tests/fast/quick/02.insttest/sparc/linux/simple-atomic passed. * build/SPARC_SE/tests/fast/quick/40.m5threads-test-atomic/sparc/linux/simple-atomic-mp passed. *
Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/328/#review839 --- Overall, this looks great. A pretty simple change that offers significant speedup. I just have one question about the parameters to storeEventInfo. src/mem/ruby/buffers/MessageBuffer.cc http://reviews.m5sim.org/r/328/#comment1196 Is there a reason why you want to pass the message pointer instead of just the vnet id? src/mem/ruby/network/simple/PerfectSwitch.cc http://reviews.m5sim.org/r/328/#comment1197 It seems that you could remove the safe_cast and message pointer dereference if you passed in the vnet id as the first parameter. Am I missing something? - Brad On 2011-02-05 12:47:34, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/328/ --- (Updated 2011-02-05 12:47:34) Review request for Default. Summary --- Currently the wakeup function for the PerfectSwitch contains three loops - loop on number of virtual networks loop on number of incoming links loop till all messages for this (link, network) have been routed With an 8 processor mesh network and Hammer protocol, about 11-12% of the was observed to have been spent in this function, which is the highest amongst all the functions. It was found that the innermost loop is executed about 45 times per invocation of the wakeup function, when each invocation of the wakeup function processes just about one message. The patch tries to do away with the redundant executions of the innermost loop. Counters have been added for each virtual network that record the number of messages that need to be routed for that virtual network. The inner loops are only executed when the number of messages for that particular virtual network 0. This does away with almost 80% of the executions of the innermost loop. The function now consumes about 5-6% of the total execution time. Diffs - src/mem/ruby/buffers/MessageBuffer.hh UNKNOWN src/mem/ruby/buffers/MessageBuffer.cc UNKNOWN src/mem/ruby/common/Consumer.hh UNKNOWN src/mem/ruby/network/simple/PerfectSwitch.hh UNKNOWN src/mem/ruby/network/simple/PerfectSwitch.cc UNKNOWN src/mem/ruby/slicc_interface/Message.hh UNKNOWN src/mem/ruby/slicc_interface/NetworkMessage.hh UNKNOWN Diff: http://reviews.m5sim.org/r/328/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Restricting W-W reordering in O3
Korey,
That idea of creating a fault was probably leading to a dead lock, as you
stated. Then, trying to stall the access as suggested, I added constraints
between stores in the Instruction Queue (actually inside MemDepUnit), where
only membar constraints were handled before. The simulator executed without
problems.
Code in MemDepUnitMemDepPred, Impl::insert(DynInstPtr inst)
...
} else {
producing_store = depPred.checkInst(inst-instAddr());
}
if (inst-isStore() store) { // Add new constraint
if(producing_store == 0) {
producing_store = storeSN;
} else {
producing_store = (storeSN producing_store ? storeSN : producing_store);
}
}
...
But I need to find the point to log order of completion of loads and stores
in the LSQ (between LSQ and L1 cache), to check the effect of that change.
I was observing inside LSQUnitImpl::completeDataAccess(PacketPtr pkt).
But the order observed doesn't look like the expected.
I wonder if I'm observing the right place...
Thank you,
--
Eberle.
On Tue, Feb 1, 2011 at 3:31 AM, Korey Sewell ksew...@umich.edu wrote:
Are your changes:
1) Causing the simulator to assert/panic/not function correctly.
or
2) Allowing the simulator to work but giving you unexpected results (bad
stats, etc.?)
If #2, it's a bigger picture issue and you'll need to add some debug
statements in the code to make sure that stores are only seen in order (e.g.
print out the sequence number for the instruction before a store is sent)
If #1, you'll need to place some code blocking the store from going to the
memory system. At some point, the instructions dependent on the store you
just set to not executed will need the values from that store, so unless
you are setting the store to executed at some point then a deadlock sounds
like a probable issue.
But also, you need to find where there is a sendTiming call in the o3
model or whatever function/code is executing the store and not execute it
unless it's at the head of the queue. I havent looked at that code in
awhile, so that's probably the best advice I could give for now, but judging
from your last snippet, why would you need to create a fault if your store
ordering is violated rather than just stall that access from
initiating/executing/etc?
I would think that the O3 has a choice of instructions to choose from in
each IEW cycle, so why not just make the choice from the LSQ unavailable if
something is out of order? What's the correct thing in HW to do there?
Anyway, hope that helps...
On Fri, Jan 28, 2011 at 12:12 PM, Eberle rambo.u...@gmail.com wrote:
Steve, what about adding dependencies between stores in the Memory
Dependency Unit, should it do the trick or needs other modifications?
I've added the restrictions but the result wasn't the expected. Maybe I
need to make more changes in other places?
As I'm using SPARC, I'd need the processor to implement the TSO model, or
at least for now, to not allow reordering between stores.
Thanks in advance,
--
Eberle.
On Tue, Jan 25, 2011 at 1:25 PM, Eberle rambo.u...@gmail.com wrote:
Right, what I need is to prevent the reordering of stores. The stores
should be executed in program order, the oldest store must be executed
before a younger store is allowed to execute.
Using O3 cpu and SPARC_SE.
When the following code is put before 'store_inst-initiateAcc();'
in LSQUnitImpl::executeStore(..) :
if (store_idx != storeHead) {
memDepViolator = storeQueue[storeHead].inst;
++lsqMemOrderViolation;
return genMachineCheckFault();
}
The following happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 12:47:37
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011 12:47:44
M5 executing on bellatrix
command line: ./build/SPARC_SE/m5.fast configs/teste.py -n 2 -b
Helloworld -d
Global frequency set at 1 ticks per second
0: system.remote_gdb.listener: listening for remote gdb on port 7000
0: system.remote_gdb.listener: listening for remote gdb on port 7001
info: Entering event queue @ 0. Starting simulation...
panic: Tried to access unmapped address 0x8.
@ cycle 9577000
[invoke:build/SPARC_SE/arch/sparc/faults.cc, line 654]
Memory Usage: 189360 KBytes
For more information see: http://www.m5sim.org/panic/5932f339
Program aborted at cycle 9577000
Aborted
In addition, I also tried not setting the store instruction as executed
when a reordering case is detected in DefaultIEWImpl::executeInsts() :
...
fault = ldstQueue.executeStore(inst);
if(ldstQueue.violation(inst-threadNumber)){
// Don't set as executed
activityThisCycle();
} else
And this happens:
M5 Simulator System
Copyright (c) 2001-2008
The Regents of The University of Michigan
All Rights Reserved
M5 compiled Jan 25 2011 13:21:18
M5 revision 4c0f7929ee33+ 7842+ default tip
M5 started Jan 25 2011
Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function
On 2011-02-09 09:44:20, Brad Beckmann wrote: src/mem/ruby/buffers/MessageBuffer.cc, line 234 http://reviews.m5sim.org/r/328/diff/2/?file=10257#file10257line234 Is there a reason why you want to pass the message pointer instead of just the vnet id? I would change that. It is a left over from the earlier approach that I was thinking of taking, the one in which all messages were queued in the Perfect Switch as well. - Nilay --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/328/#review839 --- On 2011-02-05 12:47:34, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/328/ --- (Updated 2011-02-05 12:47:34) Review request for Default. Summary --- Currently the wakeup function for the PerfectSwitch contains three loops - loop on number of virtual networks loop on number of incoming links loop till all messages for this (link, network) have been routed With an 8 processor mesh network and Hammer protocol, about 11-12% of the was observed to have been spent in this function, which is the highest amongst all the functions. It was found that the innermost loop is executed about 45 times per invocation of the wakeup function, when each invocation of the wakeup function processes just about one message. The patch tries to do away with the redundant executions of the innermost loop. Counters have been added for each virtual network that record the number of messages that need to be routed for that virtual network. The inner loops are only executed when the number of messages for that particular virtual network 0. This does away with almost 80% of the executions of the innermost loop. The function now consumes about 5-6% of the total execution time. Diffs - src/mem/ruby/buffers/MessageBuffer.hh UNKNOWN src/mem/ruby/buffers/MessageBuffer.cc UNKNOWN src/mem/ruby/common/Consumer.hh UNKNOWN src/mem/ruby/network/simple/PerfectSwitch.hh UNKNOWN src/mem/ruby/network/simple/PerfectSwitch.cc UNKNOWN src/mem/ruby/slicc_interface/Message.hh UNKNOWN src/mem/ruby/slicc_interface/NetworkMessage.hh UNKNOWN Diff: http://reviews.m5sim.org/r/328/diff Testing --- Thanks, Nilay ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function
One simple nitpick before you commit is to fix the commit message so you put a proper summary line. Nate On Sat, Feb 5, 2011 at 12:47 PM, Nilay Vaish ni...@cs.wisc.edu wrote: This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/328/ Review request for Default. By Nilay Vaish. Description Currently the wakeup function for the PerfectSwitch contains three loops - loop on number of virtual networks loop on number of incoming links loop till all messages for this (link, network) have been routed With an 8 processor mesh network and Hammer protocol, about 11-12% of the was observed to have been spent in this function, which is the highest amongst all the functions. It was found that the innermost loop is executed about 45 times per invocation of the wakeup function, when each invocation of the wakeup function processes just about one message. The patch tries to do away with the redundant executions of the innermost loop. Counters have been added for each virtual network that record the number of messages that need to be routed for that virtual network. The inner loops are only executed when the number of messages for that particular virtual network 0. This does away with almost 80% of the executions of the innermost loop. The function now consumes about 5-6% of the total execution time. Diffs - src/mem/ruby/buffers/MessageBuffer.hh (UNKNOWN) - src/mem/ruby/buffers/MessageBuffer.cc (UNKNOWN) - src/mem/ruby/common/Consumer.hh (UNKNOWN) - src/mem/ruby/network/simple/PerfectSwitch.hh (UNKNOWN) - src/mem/ruby/network/simple/PerfectSwitch.cc (UNKNOWN) - src/mem/ruby/slicc_interface/Message.hh (UNKNOWN) - src/mem/ruby/slicc_interface/NetworkMessage.hh (UNKNOWN) View Diff http://reviews.m5sim.org/r/328/diff/ ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function
On Wed, 9 Feb 2011, nathan binkert wrote: One simple nitpick before you commit is to fix the commit message so you put a proper summary line. Nate What would you like it to be? ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Ruby: Change PerfectSwitch's wakeup function
One simple nitpick before you commit is to fix the commit message so you put a proper summary line. Nate What would you like it to be? Whatever you want. Remember that it's supposed to be a single descriptive word followed by a single line summary describing the commit. It's described in the commit access guide. http://www.m5sim.org/wiki/index.php/Commit_Access Nate ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Review Request: Remove CacheMsg class from SLICC
--- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/#review841 --- Overall, this patch looks good to me as well. I just have a couple minor questions. Though your comment says this patch removes libruby, the diff seems to indicate that the file still remains. Am I reading that correctly? Also it seems that in several places you unecessarily generate the line address, even though the line address already exists in the ruby request (see comments below). src/mem/ruby/storebuffer/storebuffer.cc http://reviews.m5sim.org/r/327/#comment1201 Instead of masking the physical address, can we just use the m_LineAddress? src/mem/ruby/storebuffer/storebuffer.cc http://reviews.m5sim.org/r/327/#comment1202 Same here. Can we just use the m_LineAddress? src/mem/ruby/storebuffer/storebuffer.cc http://reviews.m5sim.org/r/327/#comment1203 And here src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/327/#comment1199 Why is this line address conversion necessary? Isn't m_LineAddress already set correctly in the constructor? src/mem/ruby/system/Sequencer.cc http://reviews.m5sim.org/r/327/#comment1200 Can you just use the m_LineAddress variable of ruby_request instead of converting the paddr to a line address. - Brad On 2011-01-25 09:15:23, Nilay Vaish wrote: --- This is an automatically generated e-mail. To reply, visit: http://reviews.m5sim.org/r/327/ --- (Updated 2011-01-25 09:15:23) Review request for Default. Summary --- Remove CacheMsg class from SLICC The goal of the patch is to do away with the CacheMsg class currently in use in coherence protocols. In place of CacheMsg, the RubyRequest class will used. This class is already present in libruby.hh. In fact, objects of class CacheMsg are generated by copying values from a RubyRequest object. The changes relating to removal of libruby have been moved to separate patch. Diffs - src/cpu/testers/rubytest/RubyTester.hh 31a04e5ac4be src/mem/protocol/MESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MI_example-cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_directory-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-L1cache.sm 31a04e5ac4be src/mem/protocol/MOESI_CMP_token-dir.sm 31a04e5ac4be src/mem/protocol/MOESI_hammer-cache.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Exports.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Profiler.sm 31a04e5ac4be src/mem/protocol/RubySlicc_Types.sm 31a04e5ac4be src/mem/ruby/SConscript 31a04e5ac4be src/mem/ruby/common/Address.hh 31a04e5ac4be src/mem/ruby/common/Address.cc 31a04e5ac4be src/mem/ruby/common/DataBlock.hh 31a04e5ac4be src/mem/ruby/common/DataBlock.cc 31a04e5ac4be src/mem/ruby/filters/BlockBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/BulkBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/LSB_CountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/MultiGrainBloomFilter.cc 31a04e5ac4be src/mem/ruby/filters/NonCountingBloomFilter.cc 31a04e5ac4be src/mem/ruby/libruby.hh 31a04e5ac4be src/mem/ruby/libruby.cc 31a04e5ac4be src/mem/ruby/libruby_internal.hh 31a04e5ac4be src/mem/ruby/profiler/AccessTraceForAddress.cc 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.hh 31a04e5ac4be src/mem/ruby/profiler/AddressProfiler.cc 31a04e5ac4be src/mem/ruby/profiler/Profiler.hh 31a04e5ac4be src/mem/ruby/profiler/Profiler.cc 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.hh 31a04e5ac4be src/mem/ruby/recorder/CacheRecorder.cc 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.hh 31a04e5ac4be src/mem/ruby/recorder/TraceRecord.cc 31a04e5ac4be src/mem/ruby/recorder/Tracer.hh 31a04e5ac4be src/mem/ruby/recorder/Tracer.cc 31a04e5ac4be src/mem/ruby/slicc_interface/RubyRequest.hh PRE-CREATION src/mem/ruby/slicc_interface/RubyRequest.cc PRE-CREATION src/mem/ruby/slicc_interface/RubySlicc_Profiler_interface.hh 31a04e5ac4be src/mem/ruby/slicc_interface/RubySlicc_Util.hh 31a04e5ac4be src/mem/ruby/slicc_interface/SConscript 31a04e5ac4be src/mem/ruby/storebuffer/stb_interface.cc 31a04e5ac4be src/mem/ruby/storebuffer/storebuffer.cc 31a04e5ac4be src/mem/ruby/system/CacheMemory.hh 31a04e5ac4be src/mem/ruby/system/CacheMemory.cc 31a04e5ac4be src/mem/ruby/system/DMASequencer.hh 31a04e5ac4be src/mem/ruby/system/DMASequencer.cc 31a04e5ac4be src/mem/ruby/system/PerfectCacheMemory.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.hh 31a04e5ac4be src/mem/ruby/system/RubyPort.cc 31a04e5ac4be src/mem/ruby/system/Sequencer.hh 31a04e5ac4be src/mem/ruby/system/Sequencer.cc 31a04e5ac4be
[m5-dev] Ruby FS Fails with recent Changesets
Hello, I first started using the Ruby Model in M5 about a week or so ago, and was able to boot in FS mode (up to 64 cores once applying the BigTsunami patches). In order to keep up with the changes in the Ruby code, I have started fetching recent updates from the devrepo. However, in fetching the updates to the recent changesets (from the last 2 days) Ruby FS does not boot. I tried both MESI_CMP_directory and MOESI_CMP_directory. If running 2 cores or less I get this at the terminal screen after letting it run for some time: 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 31 ide1 at 0x8418-0x841f,0x8426 on irq 31 ide_generic: please use probe_mask=0x3f module parameter for probing all legacy ISA IDE ports ide2 at 0x1f0-0x1f7,0x3f6 on irq 14 ide3 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 101808 sectors (52 MB), CHS=101/16/63 hda:4hda: dma_timer_expiry: dma status == 0x65 --- problem When running 3 or more cores, I get the following assertion failure: info: kernel located at: /home/musleh/M5/m5_system_2.0b3/binaries/vmlinux Listening for system connection on port 3456 0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 00:00:00 2009 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 0: system.remote_gdb.listener: listening for remote gdb #1 on port 7001 0: system.remote_gdb.listener: listening for remote gdb #2 on port 7002 0: system.remote_gdb.listener: listening for remote gdb #3 on port 7003 REAL SIMULATION info: Entering event queue @ 0. Starting simulation... info: Launching CPU 1 @ 834794000 info: Launching CPU 2 @ 845489000 info: Launching CPU 3 @ 856101000 m5.opt: build/ALPHA_FS_MESI_CMP_directory/mem/packet.hh:590: void Packet::makeResponse(): Assertion `needsResponse()' failed. Program aborted at cycle 97716 Aborted The top of the tree is this last changeset: changeset: 7939:215c8be67063 tag: tip user:Brad Beckmann brad.beckm...@amd.com date:Tue Feb 08 18:07:54 2011 -0800 summary: regess: protocol regression tester updates I am not sure if those whom it concern are aware of it or not, or if there will be a soon to be updated changeset already in the works for this or not, but I figured I would bring it to your attention. Malek ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Ruby FS Fails with recent Changesets
Thanks for letting us know. If it wouldn't be too much trouble, could you please try some other changesets near the one that isn't working and try to determine which one specifically broke things? A bunch of changes went in recently so it would be helpful to narrow things down. I'm not very involved with Ruby right now personally, but I assume that would be useful information for the people that are. Gabe On 02/09/11 14:51, Malek Musleh wrote: Hello, I first started using the Ruby Model in M5 about a week or so ago, and was able to boot in FS mode (up to 64 cores once applying the BigTsunami patches). In order to keep up with the changes in the Ruby code, I have started fetching recent updates from the devrepo. However, in fetching the updates to the recent changesets (from the last 2 days) Ruby FS does not boot. I tried both MESI_CMP_directory and MOESI_CMP_directory. If running 2 cores or less I get this at the terminal screen after letting it run for some time: 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 31 ide1 at 0x8418-0x841f,0x8426 on irq 31 ide_generic: please use probe_mask=0x3f module parameter for probing all legacy ISA IDE ports ide2 at 0x1f0-0x1f7,0x3f6 on irq 14 ide3 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 101808 sectors (52 MB), CHS=101/16/63 hda:4hda: dma_timer_expiry: dma status == 0x65 --- problem When running 3 or more cores, I get the following assertion failure: info: kernel located at: /home/musleh/M5/m5_system_2.0b3/binaries/vmlinux Listening for system connection on port 3456 0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 00:00:00 2009 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 0: system.remote_gdb.listener: listening for remote gdb #1 on port 7001 0: system.remote_gdb.listener: listening for remote gdb #2 on port 7002 0: system.remote_gdb.listener: listening for remote gdb #3 on port 7003 REAL SIMULATION info: Entering event queue @ 0. Starting simulation... info: Launching CPU 1 @ 834794000 info: Launching CPU 2 @ 845489000 info: Launching CPU 3 @ 856101000 m5.opt: build/ALPHA_FS_MESI_CMP_directory/mem/packet.hh:590: void Packet::makeResponse(): Assertion `needsResponse()' failed. Program aborted at cycle 97716 Aborted The top of the tree is this last changeset: changeset: 7939:215c8be67063 tag: tip user:Brad Beckmann brad.beckm...@amd.com date:Tue Feb 08 18:07:54 2011 -0800 summary: regess: protocol regression tester updates I am not sure if those whom it concern are aware of it or not, or if there will be a soon to be updated changeset already in the works for this or not, but I figured I would bring it to your attention. Malek ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
Re: [m5-dev] Ruby FS Fails with recent Changesets
Hi Malek, Yes, thanks for letting us know. I'm pretty sure I know what the problem is. Previously, if a SC operation failed, the RubyPort would convert the request packet to a response packet, bypassed writing the functional view of memory, and pass it back up to the CPU. In my most recent patches I generalized the mechanism that converts request packets to response packets and avoids writing functional memory. However, I forgot to remove the duplicate request to response conversion for failed SC requests. Therefore, I bet you are encounter that assertion error on that duplicate call. It should be a simple one line change that fixes your problem. I'll push it momentarily and it would be great if you could confirm that my change does indeed fix your problem. Brad -Original Message- From: m5-dev-boun...@m5sim.org [mailto:m5-dev-boun...@m5sim.org] On Behalf Of Gabe Black Sent: Wednesday, February 09, 2011 3:54 PM To: M5 Developer List Subject: Re: [m5-dev] Ruby FS Fails with recent Changesets Thanks for letting us know. If it wouldn't be too much trouble, could you please try some other changesets near the one that isn't working and try to determine which one specifically broke things? A bunch of changes went in recently so it would be helpful to narrow things down. I'm not very involved with Ruby right now personally, but I assume that would be useful information for the people that are. Gabe On 02/09/11 14:51, Malek Musleh wrote: Hello, I first started using the Ruby Model in M5 about a week or so ago, and was able to boot in FS mode (up to 64 cores once applying the BigTsunami patches). In order to keep up with the changes in the Ruby code, I have started fetching recent updates from the devrepo. However, in fetching the updates to the recent changesets (from the last 2 days) Ruby FS does not boot. I tried both MESI_CMP_directory and MOESI_CMP_directory. If running 2 cores or less I get this at the terminal screen after letting it run for some time: 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 31 ide1 at 0x8418-0x841f,0x8426 on irq 31 ide_generic: please use probe_mask=0x3f module parameter for probing all legacy ISA IDE ports ide2 at 0x1f0-0x1f7,0x3f6 on irq 14 ide3 at 0x170-0x177,0x376 on irq 15 hda: max request size: 128KiB hda: 101808 sectors (52 MB), CHS=101/16/63 hda:4hda: dma_timer_expiry: dma status == 0x65 --- problem When running 3 or more cores, I get the following assertion failure: info: kernel located at: /home/musleh/M5/m5_system_2.0b3/binaries/vmlinux Listening for system connection on port 3456 0: system.tsunami.io.rtc: Real-time clock set to Thu Jan 1 00:00:00 2009 0: system.remote_gdb.listener: listening for remote gdb #0 on port 7000 0: system.remote_gdb.listener: listening for remote gdb #1 on port 7001 0: system.remote_gdb.listener: listening for remote gdb #2 on port 7002 0: system.remote_gdb.listener: listening for remote gdb #3 on port 7003 REAL SIMULATION info: Entering event queue @ 0. Starting simulation... info: Launching CPU 1 @ 834794000 info: Launching CPU 2 @ 845489000 info: Launching CPU 3 @ 856101000 m5.opt: build/ALPHA_FS_MESI_CMP_directory/mem/packet.hh:590: void Packet::makeResponse(): Assertion `needsResponse()' failed. Program aborted at cycle 97716 Aborted The top of the tree is this last changeset: changeset: 7939:215c8be67063 tag: tip user:Brad Beckmann brad.beckm...@amd.com date:Tue Feb 08 18:07:54 2011 -0800 summary: regess: protocol regression tester updates I am not sure if those whom it concern are aware of it or not, or if there will be a soon to be updated changeset already in the works for this or not, but I figured I would bring it to your attention. Malek ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev ___ m5-dev mailing list m5-dev@m5sim.org http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: ruby: removed duplicate make response call
changeset d6294150a32e in /z/repo/m5
details: http://repo.m5sim.org/m5?cmd=changeset;node=d6294150a32e
description:
ruby: removed duplicate make response call
diffstat:
src/mem/ruby/system/RubyPort.cc | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diffs (11 lines):
diff -r 215c8be67063 -r d6294150a32e src/mem/ruby/system/RubyPort.cc
--- a/src/mem/ruby/system/RubyPort.cc Tue Feb 08 18:07:54 2011 -0800
+++ b/src/mem/ruby/system/RubyPort.cc Wed Feb 09 16:02:09 2011 -0800
@@ -342,7 +342,6 @@
// the RubyPort itself must convert it to a response.
//
accessPhysMem = false;
-pkt-makeAtomicResponse();
}
} else {
//
___
m5-dev mailing list
m5-dev@m5sim.org
http://m5sim.org/mailman/listinfo/m5-dev
[m5-dev] changeset in m5: Ext: Add X11 keysym header files to ext directory.
changeset 9aab11bcd84c in /z/repo/m5 details: http://repo.m5sim.org/m5?cmd=changeset;node=9aab11bcd84c description: Ext: Add X11 keysym header files to ext directory. diffstat: ext/x11keysym/keysym.h|76 + ext/x11keysym/keysymdef.h | 2358 + 2 files changed, 2434 insertions(+), 0 deletions(-) diffs (truncated from 2442 to 300 lines): diff -r d6294150a32e -r 9aab11bcd84c ext/x11keysym/keysym.h --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/ext/x11keysym/keysym.hWed Feb 09 22:27:37 2011 -0600 @@ -0,0 +1,76 @@ +/* $Xorg: keysym.h,v 1.4 2001/02/09 02:03:23 xorgcvs Exp $ */ + +/*** + +Copyright 1987, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included in +all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS OR +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE +OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN +AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN +CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall not be +used in advertising or otherwise to promote the sale, use or other dealings +in this Software without prior written authorization from The Open Group. + + +Copyright 1987 by Digital Equipment Corporation, Maynard, Massachusetts. + +All Rights Reserved + +Permission to use, copy, modify, and distribute this software and its +documentation for any purpose and without fee is hereby granted, +provided that the above copyright notice appear in all copies and that +both that copyright notice and this permission notice appear in +supporting documentation, and that the name of Digital not be +used in advertising or publicity pertaining to distribution of the +software without specific, written prior permission. + +DIGITAL DISCLAIMS ALL WARRANTIES WITH REGARD TO THIS SOFTWARE, INCLUDING +ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS, IN NO EVENT SHALL +DIGITAL BE LIABLE FOR ANY SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR +ANY DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, +WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, +ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS +SOFTWARE. + +**/ +/* $XFree86: xc/include/keysym.h,v 1.3 2001/01/17 17:53:12 dawes Exp $ */ + +/* default keysyms */ +#define XK_MISCELLANY +#define XK_XKB_KEYS +#define XK_LATIN1 +#define XK_LATIN2 +#define XK_LATIN3 +#define XK_LATIN4 +#define XK_LATIN8 +#define XK_LATIN9 +#define XK_CAUCASUS +#define XK_GREEK +#define XK_KATAKANA +#define XK_ARABIC +#define XK_CYRILLIC +#define XK_HEBREW +#define XK_THAI +#define XK_KOREAN +#define XK_ARMENIAN +#define XK_GEORGIAN +#define XK_VIETNAMESE +#define XK_CURRENCY +#define XK_MATHEMATICAL +#define XK_BRAILLE + +#include x11keysym/keysymdef.h + diff -r d6294150a32e -r 9aab11bcd84c ext/x11keysym/keysymdef.h --- /dev/null Thu Jan 01 00:00:00 1970 + +++ b/ext/x11keysym/keysymdef.h Wed Feb 09 22:27:37 2011 -0600 @@ -0,0 +1,2358 @@ +/* $Xorg: keysymdef.h,v 1.4 2001/02/09 02:03:23 $ */ + +/*** +Copyright 1987, 1994, 1998 The Open Group + +Permission to use, copy, modify, distribute, and sell this software and its +documentation for any purpose is hereby granted without fee, provided that +the above copyright notice appear in all copies and that both that +copyright notice and this permission notice appear in supporting +documentation. + +The above copyright notice and this permission notice shall be included +in all copies or substantial portions of the Software. + +THE SOFTWARE IS PROVIDED AS IS, WITHOUT WARRANTY OF ANY KIND, EXPRESS +OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF +MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. +IN NO EVENT SHALL THE OPEN GROUP BE LIABLE FOR ANY CLAIM, DAMAGES OR +OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, +ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR +OTHER DEALINGS IN THE SOFTWARE. + +Except as contained in this notice, the name of The Open Group shall +not be used in advertising or otherwise to promote the sale, use or +other dealings in this Software without prior written
