Hello,
This is related to the bug reported in
http://www.mail-archive.com/m5-us...@m5sim.org/msg03669.html.
According to Gabriel's response a possible fix would be using the copyRegs()
function defined in the ISA for the same task, and it actually seems to work.
Is there any reason that O3
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/68/
---
Review request for Default.
Summary
---
This is a patch fixing the
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/68/
---
(Updated 2010-07-29 13:01:13.137646)
Review request for Default.
Summary
---
---
On 2010-07-29 13:01:13, Ioannis Ilkos wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/68/
---
(Updated
---
On 2010-07-29 13:01:13, Ioannis Ilkos wrote:
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/68/
---
(Updated 2010-07-29 13:01:13
---
This is an automatically generated e-mail. To reply, visit:
http://reviews.m5sim.org/r/73/
---
Review request for Default.
Summary
---
Implemented what the comment said: do
Hello,
Here is the patch that fixes the aforementioned problem and implements the
nanosleep syscall (albeit without the signal-relevant parts) for AlphaLinux.
Changelog for O3:
1. activateThread() now schedules its own ticks and keeps the pipeline running
2. suspendContext() and haltContext()
Hello,
I've already hacked a quick workaround for my work but is no proper patch. I
will write up a proper one sometime within next week and post it (+ the
nanosleep syscall patch)
-Ioannis
On 22 Jul 2010, at 19:17, Steve Reinhardt wrote:
On Thu, Jul 22, 2010 at 10:03 AM, Korey Sewell
Hello,
I have been playing with time in m5 syscall emulation mode and had a couple of
issues:
First of all I believe there is a bug in the times() syscall implementation
(sim/syscall_emul.hh). The current clocks value passed to the userland is:
int64_t clocks = curTick *
what's going on. Assuming glibc is just setting up some
facility that your benchmark(s) never happen to use, it would be locally
safe to ignore that trap number. In a more global context we'd want to
at least warn().
Gabe
Ioannis Ilkos wrote:
Hello,
I have been using the m5-stable from
Hello,
I have been using the m5-stable from the repository the last few days. In order
to compile sparc64-linux binaries for SE mode I built a cross compiler
toolchain which linked against newer glibc versions. It turned out the newer
glibc (my test programs were linked with glibc-2.8 with
11 matches
Mail list logo
