well, since that's the case, then what you can do is figure out when does the 1st instruction PC for your SPEC benchmark get committed?
If you are running the same SPEC benchmark on both CPUs then the instruction trace commit list needs to be the same. Running the "Exec" trace flag, you should get the committed insts. A couple of ways to debug: (1) Compare the first 100 (? however long the fault handler insts are) instructions for CPU0 to CPU1. At what point does the commit for each diverge? (2) Run the benchmarks using the SimpleCPUs. The commit list for O3 should be the same as the SimpleCPU so you can figure out what's supposed to be committed versus what is happening. Once you track down the problem of "where", then how to fix it is another issue depending on if it's loading the wrong thing to start up or if there is a O3 bug. On 6/23/08, prannav shrestha <[EMAIL PROTECTED]> wrote: > Yes, both CPU0 and CPU1 has fault 0. > > This is what in the debug file > > 0: system.cpu1.fetch: [tid:0]: fault (itbmiss) detected @ PC 0x000000 > 0: system.cpu1.decode: Processing [tid:0]0: system.cpu0.fetch: [tid:0]: > fault (itbmiss) detected @ PC 0x000000 0: system.cpu0.decode: > Processing [tid:0] > > So, whats the story then? > > Prannav > > > On Mon, Jun 23, 2008 at 3:24 PM, Korey Sewell <[EMAIL PROTECTED]> wrote: > > If starting workloads at PC 0 is what we intend to do (when did that > > happen?), that would mean that the real starting PC would need to be > > loaded in the correct system register. > > > > For SE mode, are we making sure we load the system registers correctly > > so that the fault handler can pick it up and start at the right > > address? > > > > Last time I looked at the code (admittedly a while back), the AlphaTLB > > the fault handling code for ITLB miss loads from a system register > > right but then the problem I encountered was that in SE mode all the > > system stuff isnt loaded correctly so even though the fault is being > > taken correctly the registers to handle it at init. time werent set up > > correctly (Probably in the src/arch/alpha/process.cc) for SE and thus > > the trap handler didnt go through right. > > > > Again, if the code is updated to a diff. point I could be wrong. I > > dont even remember us intentionally starting workloads at PC 0 to get > > the ITLB Miss Fault so that's why I think that's a problem. > > > > prannav, > > is the CPU0 getting the same PC 0 fault to start off with or is it > > just CPU1? The answer to that question probably tells the story. > > > > > > > > > > On 6/23/08, Gabe Black <[EMAIL PROTECTED]> wrote: > > > Yes, it starts with PC 0, and yest there's an I TLB miss, but latter > > > there are actual instructions in the rest of the pipeline which wouldn't > > > happen if the process was bogus. There would also not be any > > > instructions to squash. Every time o3 starts up, it has to get itself > > > initialized and causes some bogus faults and such for the first few > > > ticks. After that, it gets it's act straightened out and goes to the > > > right place. I think he mentioned trying initializing the workload > > > outside of the loop the, so I'm pretty sure a bad process object isn't > > > it the culprit. > > > > > > To answer your question, yes there is a TLB object in SE mode. The TLB > > > itself doesn't handle the faults and is instead loaded by the faults, at > > > which point execution continues like it normally would. There is still > > > an abstracted page table structure the fault uses to look up the > > > official mapping of a virtual address to load the TLB, so if the address > > > is completely invalid, ie. not mapped in any way by the process, there > > > would still be a fail or panic just like before. I do think the TLB > > > could be to blame, though, since it's possible the fault is loading the > > > TLB in such a way as the TLB never matches with the entry. > > > > > > Prannav, if you could find the answers to those questions I mentioned, > > > it would really help clarify what's actually going on. If you run a gdb > > > targeted at Alpha on the benchmark binary and disassemble the > > > instruction at 0x12000dde8 that's what the instruction should be. In the > > > O3 output, I think it prints out what the instruction disassembles to > > > when it's fetched, so that will tell you what M5 is trying to execute. > > > > > > Gabe > > > > > > Korey Sewell wrote: > > > > but why would there be a TLB miss? > > > > > > > > It's because you are trying to execute PC "0x0" which is obviously not > valid. > > > > > > > > I'm pretty sure that's the culprit. That's happened to me a bunch of > > > > times in the past and it's always initializing the process wrong in > > > > some way. > > > > > > > > But Did we not add TLB code for SE mode and the like? So now, instead > > > > of a "unmapped" failure and die (like old M5) we are probably just > > > > repeatedly trying to handle a trap that we shouldnt be handling. > > > > > > > > > > > > On 6/23/08, Gabe Black <[EMAIL PROTECTED]> wrote: > > > > > > > >> I don't think that's actually the problem since later the cpu goes > > > >> through a lot of the motions of executing instructions. The line > > > >> > > > >> 13000: system.cpu1.commit: Inst [sn:3] PC 0x12000dde8 has a fault > > > >> > > > >> > > > >> suggests that the instructions are executing, they're just faulting > over > > > >> and over. What would be helpful is if you can figure out: > > > >> > > > >> 1. What the instruction actually is. > > > >> 2. What the fault it's throwing is. > > > >> 3. Why it's throwing that fault. > > > >> 4. Why it never successfully fixes that condition. > > > >> > > > >> What I'd guess is that there's some sort of data TLB miss that's > > > >> happening which is never successfully being fixed. Usually in glibc, > one > > > >> of if not the first instruction a process executes sets the frame > > > >> pointer to 0, so I'm not sure what fault this could be throwing. It's > > > >> also possible the instruction address is being mistranslated and > you're > > > >> executing the wrong memory. > > > >> > > > >> Gabe > > > >> > > > >> Korey Sewell wrote: > > > >> > > > >>> You need to look just a bit closer at this... The line(s) of > interest are: > > > >>> " 0: system.cpu1.fetch: [tid:0]: Attempting to translate and read > > > >>> instruction, starting at PC 0x000000." > > > >>> > > > >>> Thus, if CPU1 is starting at address 0x0, that probably means it is > > > >>> starting with no workload, and eventually experienced a trap because > > > >>> there is no code at that address. > > > >>> > > > >>> It probably would be the best thing to have some kind of check > > > >>> somewhere to WARN a user that a CPU has no valid process to start > from > > > >>> and then sleep the CPU rather than waste sim. cycles on that. > > > >>> > > > >>> Anyway, > > > >>> you have to figure out how to get the 2nd CPU to get a valid > process. > > > >>> On a first cut, I would just hardcode the CPU processes bindings > > > >>> instead of using the loop like in your example. If you can get that > to > > > >>> work, then you know something is going on with how the loop is > > > >>> setting up your system. > > > >>> > > > >>> I'm guessing that something like this would work (check syntax > though): > > > >>> " > > > >>> Process process1 = Benchmarks.SPECGCCEIO() > > > >>> Process process2 = Benchmarks.SPECGCCEIO() > > > >>> system.cpu[0].workload = process1 > > > >>> system.cpu[1].workload = process2 > > > >>> " > > > >>> > > > >>> I've done similar when i've needed something quick to work. I've > > > >>> noticed that you're using EIO so if you aren't able to hardcode it, > > > >>> then the EIO functionality could be the culprit as well. > > > >>> > > > >>> On Mon, Jun 23, 2008 at 12:15 AM, prannav shrestha > <[EMAIL PROTECTED]> wrote: > > > >>> > > > >>> > > > >>>> HI Sewell!! > > > >>>> I run the simulation with O3CPU flags, and looking at the > information > > > >>>> provided, i found that in my case, PC value for CPU remains same > forever, > > > >>>> whereas CPU0 is executing the workload. Also, the insructions > fetched by > > > >>>> CPU1, which is always the same, is squashed everytime. Some part of > the > > > >>>> debug output is as below: > > > >>>> > > > >>>> Global frequency set at 1000000000000 ticks per second > > > >>>> 0: global: BTB: Creating BTB object. > > > >>>> 0: system.cpu0.iew.lsq: LSQ sharing policy set to > Partitioned: 32 > > > >>>> entries per LQ | 32 entries per SQ 0: system.cpu0.commit: > Commit Policy > > > >>>> set to Round Robin. 0: system.cpu0.rob: ROB sharing policy set > to > > > >>>> Partitioned > > > >>>> 0: global: Creating AlphaO3CPU object. > > > >>>> > > > >>>> number of threads: 1 > > > >>>> 0: global: Workload[0] process is 0 0: global: BTB: > Creating BTB > > > >>>> object. > > > >>>> 0: system.cpu1.iew.lsq: LSQ sharing policy set to > Partitioned: 32 > > > >>>> entries per LQ | 32 entries per SQ 0: system.cpu1.commit: > Commit Policy > > > >>>> set to Round Robin. 0: system.cpu1.rob: ROB sharing policy set > to > > > >>>> Partitioned > > > >>>> 0: global: Creating AlphaO3CPU object. > > > >>>> > > > >>>> number of threads: 1 > > > >>>> 0: global: Workload[0] process is 0 0: global: Calling > activate > > > >>>> on Thread Context 0 > > > >>>> 0: system.cpu0: [tid:0]: Calling activate thread. > > > >>>> 0: system.cpu0: [tid:0]: Adding to active threads list > > > >>>> 0: system.cpu0.fetch: Waking up from quiesce > > > >>>> 0: system.cpu0.commit: Generating TC squash event for [tid:0] > > > >>>> 0: global: Calling activate on Thread Context 0 > > > >>>> 0: system.cpu1: [tid:0]: Calling activate thread. > > > >>>> 0: system.cpu1: [tid:0]: Adding to active threads list > > > >>>> 0: system.cpu1.fetch: Waking up from quiesce > > > >>>> 0: system.cpu1.commit: Generating TC squash event for [tid:0] > > > >>>> 0: system.cpu1: > > > >>>> > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 0: system.cpu1.fetch: Running stage. > > > >>>> 0: system.cpu1.fetch: Attempting to fetch from [tid:0] > > > >>>> 0: system.cpu1.fetch: [tid:0]: Attempting to translate and > read > > > >>>> instruction, starting at PC 0x000000. > > > >>>> 0: system.cpu1.fetch: [tid:0]: Blocked, need to handle the > trap. > > > >>>> 0: system.cpu1.fetch: [tid:0]: fault (itbmiss) detected @ PC > > > >>>> 0x000000 0: system.cpu1.decode: Processing [tid:0] > > > >>>> 0: system.cpu1.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 0: system.cpu1.decode: [tid:0] Nothing to do, breaking out > early. > > > >>>> ...................... > > > >>>> ........ > > > >>>> .... > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 6500: system.cpu0.fetch: Running stage. > > > >>>> 6500: system.cpu0.fetch: There are no more threads available to > fetch > > > >>>> from. > > > >>>> 6500: system.cpu0.decode: Processing [tid:0] > > > >>>> 6500: system.cpu0.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 6500: system.cpu0.decode: [tid:0] Nothing to do, breaking out > early. > > > >>>> 6500: system.cpu0.commit: Getting instructions from Rename > stage. > > > >>>> 6500: system.cpu0.commit: Trying to commit instructions in the > ROB. > > > >>>> 6500: system.cpu0.commit: [tid:0]: Instruction [sn:2] PC > 0x120140ce8 is > > > >>>> head of ROB and ready to commit > > > >>>> 6500: system.cpu0.commit: [tid:0]: ROB has 1 insts & 191 free > entries. > > > >>>> 6500: system.cpu0: Scheduling next tick! > > > >>>> 6500: system.cpu1: > > > >>>> > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 6500: system.cpu1.fetch: Running stage. > > > >>>> 6500: system.cpu1.fetch: There are no more threads available to > fetch > > > >>>> from. > > > >>>> 6500: system.cpu1.decode: Processing [tid:0] > > > >>>> 6500: system.cpu1.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 6500: system.cpu1.decode: [tid:0] Nothing to do, breaking out > early. > > > >>>> 6500: system.cpu1.commit: Getting instructions from Rename > stage. > > > >>>> 6500: system.cpu1.commit: Trying to commit instructions in the > ROB. > > > >>>> 6500: system.cpu1.commit: [tid:0]: Instruction [sn:2] PC > 0x12000dde8 is > > > >>>> head of ROB and ready to commit > > > >>>> 6500: system.cpu1.commit: [tid:0]: ROB has 1 insts & 191 free > entries. > > > >>>> 6500: system.cpu1: Scheduling next tick! > > > >>>> 7000: system.cpu1: > > > >>>> > > > >>>> ............. > > > >>>> .......... > > > >>>> .......... > > > >>>> > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 13000: system.cpu1.fetch: Running stage. > > > >>>> 13000: system.cpu1.fetch: There are no more threads available to > fetch > > > >>>> from. > > > >>>> 13000: system.cpu1.decode: Processing [tid:0] > > > >>>> 13000: system.cpu1.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 13000: system.cpu1.decode: [tid:0] Nothing to do, breaking out > early. > > > >>>> 13000: system.cpu1.commit: Getting instructions from Rename > stage. > > > >>>> 13000: system.cpu1.commit: Trying to commit instructions in the > ROB. > > > >>>> 13000: system.cpu1.commit: Trying to commit head instruction, > [sn:3] > > > >>>> [tid:0] > > > >>>> 13000: system.cpu1.commit: Inst [sn:3] PC 0x12000dde8 has a fault > > > >>>> 13000: system.cpu1.commit: Generating trap event for [tid:0] > > > >>>> 13000: system.cpu1.commit: Unable to commit head instruction > > > >>>> PC:0x12000dde8 [tid:0] [sn:3]. > > > >>>> 13000: system.cpu1.commit: [tid:0]: Instruction [sn:3] PC > 0x12000dde8 is > > > >>>> head of ROB and ready to commit > > > >>>> 13000: system.cpu1.commit: [tid:0]: ROB has 1 insts & 191 free > entries. > > > >>>> 13000: system.cpu1: Scheduling next tick! > > > >>>> 13000: system.cpu0: > > > >>>> > > > >>>> ..... > > > >>>> .... > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 32500: system.cpu0.fetch: Running stage. > > > >>>> 32500: system.cpu0.fetch: Attempting to fetch from [tid:0] > > > >>>> 32500: system.cpu0.fetch: [tid:0]: Attempting to translate and > read > > > >>>> instruction, starting at PC 0x120140cf0. > > > >>>> 32500: system.cpu0.fetch: Fetch: Doing instruction read. > > > >>>> 32500: system.cpu0.fetch: [tid:0]: Doing cache access. > > > >>>> 32500: system.cpu0.decode: Processing [tid:0] > > > >>>> 32500: system.cpu0.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 32500: system.cpu0.decode: [tid:0]: Sending instruction to > rename. > > > >>>> 32500: system.cpu0.decode: [tid:0]: Processing instruction [sn:3] > with PC > > > >>>> 0x120140ce8 > > > >>>> 32500: system.cpu0.decode: [tid:0]: Processing instruction [sn:4] > with PC > > > >>>> 0x120140cec > > > >>>> 32500: system.cpu0.commit: Getting instructions from Rename > stage. > > > >>>> 32500: system.cpu0.commit: Trying to commit instructions in the > ROB. > > > >>>> 32500: system.cpu0.commit: [tid:0]: ROB has 0 insts & 192 free > entries. > > > >>>> 32500: system.cpu0: Scheduling next tick! > > > >>>> 33000: system.cpu0: > > > >>>> > > > >>>> .............. > > > >>>> ......... > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 39500: system.cpu0.fetch: Running stage. > > > >>>> 39500: system.cpu0.fetch: Attempting to fetch from [tid:0] > > > >>>> 39500: system.cpu0.fetch: [tid:0]: Attempting to translate and > read > > > >>>> instruction, starting at PC 0x120140d00. > > > >>>> 39500: system.cpu0.fetch: Fetch: Doing instruction read. > > > >>>> 39500: system.cpu0.fetch: [tid:0]: Doing cache access. > > > >>>> 39500: system.cpu0.decode: Processing [tid:0] > > > >>>> 39500: system.cpu0.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 39500: system.cpu0.decode: [tid:0]: Sending instruction to > rename. > > > >>>> 39500: system.cpu0.decode: [tid:0]: Processing instruction [sn:5] > with PC > > > >>>> 0x120140cf0 > > > >>>> 39500: system.cpu0.decode: [tid:0]: Processing instruction [sn:6] > with PC > > > >>>> 0x120140cf4 > > > >>>> 39500: system.cpu0.decode: [tid:0]: Processing instruction [sn:7] > with PC > > > >>>> 0x120140cf8 > > > >>>> 39500: system.cpu0.decode: [tid:0]: Processing instruction [sn:8] > with PC > > > >>>> 0x120140cfc > > > >>>> 39500: system.cpu0.commit: Getting instructions from Rename > stage. > > > >>>> 39500: system.cpu0.commit: Trying to commit instructions in the > ROB. > > > >>>> 39500: system.cpu0.commit: [tid:0]: ROB has 0 insts & 192 free > entries. > > > >>>> 39500: system.cpu0: Scheduling next tick! > > > >>>> 40000: system.cpu0: > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 40000: system.cpu1.fetch: Running stage. > > > >>>> 40000: system.cpu1.fetch: There are no more threads available to > fetch > > > >>>> from. > > > >>>> 40000: system.cpu1.decode: Processing [tid:0] > > > >>>> 40000: system.cpu1.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 40000: system.cpu1.decode: [tid:0] Nothing to do, breaking out > early. > > > >>>> 40000: system.cpu1.commit: Squashing from trap, restarting at PC > > > >>>> 0x12000dde8 > > > >>>> 40000: system.cpu1.commit: [tid:0]: Instruction [sn:5] PC > 0x12000dde8 is > > > >>>> head of ROB and ready to commit > > > >>>> 40000: system.cpu1.commit: [tid:0]: ROB has 1 insts & 191 free > entries. > > > >>>> 40000: system.cpu1: Scheduling next tick! > > > >>>> 40500: system.cpu1.fetch-iport: Received timing > > > >>>> 40500: system.cpu1: > > > >>>> .................... > > > >>>> ................. > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 1243500: system.cpu0.fetch: Running stage. > > > >>>> 1243500: system.cpu0.fetch: There are no more threads available to > fetch > > > >>>> from. > > > >>>> 1243500: system.cpu0.decode: Processing [tid:0] > > > >>>> 1243500: system.cpu0.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 1243500: system.cpu0.decode: [tid:0] Nothing to do, breaking out > early. > > > >>>> 1243500: system.cpu0.commit: Getting instructions from Rename > stage. > > > >>>> 1243500: system.cpu0.commit: Trying to commit instructions in the > ROB. > > > >>>> 1243500: system.cpu0.commit: [tid:0]: Instruction [sn:369] PC > 0x120106160 is > > > >>>> head of ROB and ready to commit > > > >>>> 1243500: system.cpu0.commit: [tid:0]: ROB has 1 insts & 191 free > entries. > > > >>>> 1243500: system.cpu0: Scheduling next tick! > > > >>>> 1244000: system.cpu0: > > > >>>> > > > >>>> ......... > > > >>>> ........ > > > >>>> FullO3CPU: Ticking main, FullO3CPU. > > > >>>> 4001000: system.cpu1.fetch: [tid:0]: Done squashing, switching to > running. > > > >>>> 4001000: system.cpu1.fetch: Running stage. > > > >>>> 4001000: system.cpu1.fetch: Attempting to fetch from [tid:0] > > > >>>> 4001000: system.cpu1.fetch: [tid:0]: Attempting to translate and > read > > > >>>> instruction, starting at PC 0x12000dde8. > > > >>>> 4001000: system.cpu1.fetch: [tid:0]: Blocked, need to handle the > trap. > > > >>>> 4001000: system.cpu1.fetch: [tid:0]: fault (itbmiss) detected @ PC > > > >>>> 0x12000dde84001000: system.cpu1.decode: Processing [tid:0] > > > >>>> 4001000: system.cpu1.decode: [tid:0]: Done squashing, switching to > running. > > > >>>> 4001000: system.cpu1.decode: [tid:0]: Not blocked, so attempting to > run > > > >>>> stage. > > > >>>> 4001000: system.cpu1.decode: [tid:0] Nothing to do, breaking out > early. > > > >>>> 4001000: system.cpu1.commit: Getting instructions from Rename > stage. > > > >>>> 4001000: system.cpu1.commit: Trying to commit instructions in the > ROB. > > > >>>> 4001000: system.cpu1.commit: [tid:0]: ROB has 0 insts & 192 free > entries. > > > >>>> 4001000: system.cpu1: Scheduling next tick! > > > >>>> 4001500: system.cpu1: > > > >>>> ...... > > > >>>> > > > >>>> Exiting @ cycle 4002500 because all threads reached the max > instruction > > > >>>> count > > > >>>> > > > >>>> I am running two different benchmarks in those two cores. I have > included > > > >>>> the long list of the debug. The PC of CPU1 is always the same. Why > the > > > >>>> instruction at CPU1 is always being squashed? > > > >>>> > > > >>>> regards, > > > >>>> prannav > > > >>>> > > > >>>> > > > >>>> > > > >>>> On Sun, Jun 22, 2008 at 10:49 PM, Korey Sewell <[EMAIL PROTECTED]> > wrote: > > > >>>> > > > >>>> > > > >>>>> Turn on the trace flags for O3CPU and see what it says.... Inside > the > > > >>>>> "o3" folder there should be a *.py file that list the trace-flags. > > > >>>>> > > > >>>>> If you run the simulation with all the O3 trace-flags on you > should be > > > >>>>> able to see what's happening. I suggest only running for maybe 100 > > > >>>>> ticks so that you dont get overloaded with text. > > > >>>>> > > > >>>>> From the debug output, you should see each CPU get initialized, > fetch, > > > >>>>> and all that. I'm guessing what happens is that CPU1 starts up, > sees > > > >>>>> no process to latch onto, and then sleeps, but the debug output > should > > > >>>>> verify that for you. > > > >>>>> > > > >>>>> Simply looking at the instruction commits (Exec) wont help you in > this > > > >>>>> case since you're saying that there is no instructions commit. > You'll > > > >>>>> at least need to turn on "Fetch Decode Exec" and all that so you > can > > > >>>>> get a detailed view. > > > >>>>> > > > >>>>> > > > >>>>> -- > > > >>>>> ---------- > > > >>>>> Korey L Sewell > > > >>>>> Graduate Student - PhD Candidate > > > >>>>> Computer Science & Engineering > > > >>>>> University of Michigan > > > >>>>> _______________________________________________ > > > >>>>> 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 > > > >>>> > > > >>>> > > > >>>> > > > >>> > > > >>> > > > >>> > > > >> _______________________________________________ > > > >> 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 > > > > > > > > > -- > > > > > > > > ---------- > > Korey L Sewell > > Graduate Student - PhD Candidate > > Computer Science & Engineering > > University of Michigan > > _______________________________________________ > > 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 > -- ---------- Korey L Sewell Graduate Student - PhD Candidate Computer Science & Engineering University of Michigan _______________________________________________ m5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/m5-users
