Re: [gem5-dev] Ideas for sprint projects

[Cagdas Dirik (cdirik)]

Thank you for putting them together Jason!

One quick question - regarding "replacing scons...". Is there a specific reason 
for stepping over cmake and jumping to bazel? It feels to me "replacing scons 
with cmake" will be more beneficial (assuming cmake is more common for gem5 
developers than bazel).

Cagdas 

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Jason Lowe-Power
Sent: Thursday, January 26, 2017 12:41 PM
To: gem5 Developer List 
Subject: Re: [gem5-dev] Ideas for sprint projects

Thanks everyone who came up with some ideas!

I've compiled them on this page on the wiki: http://gem5.org/Sprint_Ideas.
Feel free to edit or add more ideas. I tried to expand on each idea with a few 
sentences, but I didn't get to all of them. I also included the person who 
suggested the idea with it.

Cheers,
Jason

On Wed, Jan 25, 2017 at 12:02 PM Andreas Hansson 
wrote:

> Hi all,
>
> A large-sized project for some crafty person out there: A 
> binary-translation CPU for fast-forwarding, much like the KVMCpu, but 
> more portable. It could, for example, be built on top of the Tiny Code 
> Generator (TCG), as it is BSD licensed.
>
> Quite a big task, but also a very big contribution to gem5.
>
> Andreas
>
> On 23/01/2017, 16:57, "gem5-dev on behalf of Andreas Hansson"
>  wrote:
>
> >Hi all,
> >
> >Another medium-sized idea: Embed the generated system SVG in a web 
> >page that can be used to interactively navigate the simulation 
> >results
> >
> >This should be fairly easy for anyone skilled in client-side 
> >scripting. It may even be used to view incremental results while the 
> >simulation is running.
> >
> >Andreas
> >
> >On 23/01/2017, 15:57, "gem5-dev on behalf of Andreas Sandberg"
> > wrote:
> >
> >>Hi Everyone,
> >>
> >>Thanks for organising this! See below for some of my ideas.
> >>
> >>Small projects:
> >>   * Clean up serialization code for better code reuse (particularly 
> >>container helpers)
> >>   * Create a separate test classification for CI smoke tests 
> >>(faster than quick)
> >>
> >>Medium-sized projects:
> >>   * New test binaries based on the LLVM test suite
> >>   * Mini-DSL for param overrides from the command line
> >>   * Config cleanups. E.g., move some of config/common/ to a 
> >>m5.config name space.
> >>   * Proper support for pthreads in SE mode
> >>   * Implement a fast mode in the HDLCD controller to support 
> >>graphical worklaods (e.g., Android) in KVM
> >>
> >>Large projects:
> >>   * Get scons to build basic components only once and share them 
> >>between architectures
> >>
> >>
> >>I'd like to throw cmake in to the build system mix as well. I 
> >>started hacking on a small prototype a while back, but it isn't able 
> >>to build
> >>gem5 yet.
> >>
> >>
> >>Cheers,
> >>Andreas
> >>
> >>
> >>On 17/01/17 16:12, Jason Lowe-Power wrote:
> >>> Hi gem5 Developers!
> >>>
> >>> As you're probably aware, I'm going to be running a gem5 coding 
> >>>sprint in  the afternoon after the Learning gem5 tutorial at HPCA 
> >>>on Sunday Feb 5.
> >>>
> >>> I'm looking for ideas for small projects that could be started (or 
> >>>even  better, completed) in a few hours. Do you have any small bugs 
> >>>that have  been bothering you? Any little features that would be 
> >>>nice, but you haven't  had the time to work on? Now's the time to 
> >>>get these things done!
> >>>
> >>> Also, if you have any bigger projects that you think it would be 
> >>>good for  people to chat about in the same room to come up with a 
> >>>plan of attack, we  may be able to fit one or two of those in, too.
> >>>
> >>> Some examples that I have so far:
> >>>
> >>> Little projects:
> >>> 1. Fix TLB warmup for x86. (See http://reviews.gem5.org/r/3474/) 
> >>> 2. Modify EventWrapper to understand C++11 lambdas so you can pass 
> >>> parameters to simple process() functions without creating a new class.
> >>> 3. Develop some ISA instruction tests to find out what is 
> >>> implemented correctly and possibly find some bugs. (See RISC-V 
> >>> insttest)
> >>>
> >>> Long-term things we may want to discuss:
> >>> 1. Revamping the test infrastructure 2. Replacing scons, possibly 
> >>> with Bazel (see https://bazel.build/)
> >>>
> >>> Please respond with any ideas you have! We definitely won't get to  
> >>>everything, but throwing ideas out there now will give us a large 
> >>>base of  options for the coding sprint.
> >>>
> >>> Thanks,
> >>> Jason
> >>
> >>IMPORTANT NOTICE: The contents of this email and any attachments are 
> >>confidential and may also be privileged. If you are not the intended 
> >>recipient, please notify the sender immediately and do not disclose 
> >>the contents to any other person, use it for any purpose, or store 
> >>or copy the information in any medium. Thank you.
> >>___
> >>gem5-dev mailing list
> >>gem5-dev@gem5.org
> >>http://m5sim.org/mailman/listinfo/gem5-dev
> >
> >IMPORTANT NOTICE: The contents of this e

Re: [gem5-dev] VNC server on X86 - crashes gem5 on attach/detach

[Cagdas Dirik (cdirik)]

Thank you Andreas! Greatly appreciate it, will go down the path you recommended.

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Sandberg
Sent: Friday, August 28, 2015 6:08 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] VNC server on X86 - crashes gem5 on attach/detach

Hi Cagdas,


As far as I know, there is no graphics support for x86 in gem5 at the moment. 
In addition to the VncServer, you¹ll need some form of graphics device. Gabe 
Black posted a simplified Cirrus-based device on RB some time ago (RB2511 [1]).

I suspect one of the reasons the VNC client can¹t connect is because the VNC 
server doesn¹t know about any framebuffer if you don¹t have any graphics 
adapter in your system. I think it will report a 0x0 framebuffer in RGBA.

//Andreas

[1] http://reviews.gem5.org/r/2511


On 20/08/2015 21:55, "Cagdas Dirik (cdirik)"  wrote:

>Hi all,
>
>We have been trying to setup tests with a debian 6 image with gnome, 
>and we need UI/desktop environment. Our image works fine with 
>VirtualBox and Qemu. However we cannot get it booting successfully in 
>gem5. Not sure if it hangs on boot, or it boots fine but we just cannot see 
>the output.
>
>To get it vnc working, we modified configs/common/FSConfig.py such as:
>def makeLinuxX86System(...
>...
>self.vncserver = VncServer()
>return self
>
>This modification is almost identical to this patch on review board:
>http://reviews.gem5.org/r/2517/diff/1/
>
>However, vncviewer is failing to connect. Moreover, when it detaches 
>gem5 crashes - trips on the following assert:
>...
>info: VNC client attached
>gem5.opt: build/X86/base/vnc/vncserver.cc:396: void
>VncServer::checkProtocolVersion(): Assertion `len ==12' failed.
>Program aborted at cycle...
>
>Having patch 2517 on review board for a long time and this assertion 
>make me think that there is more to be done to get VNC working on X86. 
>Is anyone running X86 on an image with desktop? If so, can you share 
>the details (image, kernel version, patches, etc.)?
>
>Any guidance will be appreciated!
>
>Thanks!
>
>Cagdas
>___
>gem5-dev mailing list
>gem5-dev@gem5.org
>http://m5sim.org/mailman/listinfo/gem5-dev


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590 ARM Holdings plc, Registered office 
110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company 
No:  2548782

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] VNC server on X86 - crashes gem5 on attach/detach

[Cagdas Dirik (cdirik)]

Hi all,

We have been trying to setup tests with a debian 6 image with gnome, and we 
need UI/desktop environment. Our image works fine with VirtualBox and Qemu. 
However we cannot get it booting successfully in gem5. Not sure if it hangs on 
boot, or it boots fine but we just cannot see the output.

To get it vnc working, we modified configs/common/FSConfig.py such as:
def makeLinuxX86System(...
...
self.vncserver = VncServer()
return self

This modification is almost identical to this patch on review board:
http://reviews.gem5.org/r/2517/diff/1/

However, vncviewer is failing to connect. Moreover, when it detaches gem5 
crashes - trips on the following assert:
...
info: VNC client attached
gem5.opt: build/X86/base/vnc/vncserver.cc:396: void 
VncServer::checkProtocolVersion(): Assertion `len ==12' failed.
Program aborted at cycle...

Having patch 2517 on review board for a long time and this assertion make me 
think that there is more to be done to get VNC working on X86. Is anyone 
running X86 on an image with desktop? If so, can you share the details (image, 
kernel version, patches, etc.)?

Any guidance will be appreciated!

Thanks!

Cagdas
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] X86 FS regression test fails on OSX with "Abort trap: 6" error

[Cagdas Dirik (cdirik)]

Thank you for reproducing the issue Andreas!

Any suggestions on how to get to the core of it? I have not gotten an attack 
plan yet, so open to any recommendations ;)

Cagdas

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Andreas Sandberg
Sent: Monday, July 06, 2015 6:41 AM
To: gem5 Developer List
Subject: Re: [gem5-dev] X86 FS regression test fails on OSX with "Abort trap: 
6" error

Cagdas,

I just tried to run the quick x86 regressions using a gem5 compiled with clang 
3.5 on Linux and ran into a similar problem. In my case, the tests segfault, 
but all the other symptoms seem identical. An interesting observation is that 
/all/ the other backends run their quick regressions just fine, so I'm inclined 
to say that this is an x86-specific issue that is triggered by clang (I'm 
assuming you're using clang since you're on MacOS).

//Andreas

On 30/06/2015 23:13, Cagdas Dirik (cdirik) wrote:
> Thank you for suggestions Nilay and Andreas!
>
> Andreas, I looked at the simerr and simout files, and there are no 
> indications of a missing file. All kernel images and disk images are under 
> $M5_PATH - I am basically using same set of files which pass regression tests 
> under Linux. As a reference I pasted the outputs from those files at the end.
>
> I did not find any "Initializing CPU#" messages from gem5, then I think I 
> need to pinpoint the erroring module in the kernel.
>
> I also tried kernel 2.6.26 and passing linux-x86.img file explicitly from 
> command line to gem5 and got the same error message.
>
> Cagdas
>
> $ cat 
> build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic/
> simerr
> warn: Sockets disabled, not accepting terminal connections
> warn: Sockets disabled, not accepting gdb connections
> warn: Reading current count from inactive timer.
> warn: Don't know what interrupt to clear for console.
>
> $ cat 
> build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic/
> simout
> gem5 Simulator System.  http://gem5.org
> gem5 is copyrighted software; use the --copyright option for details.
>
> gem5 compiled Jun 23 2015 13:44:27
> gem5 started Jun 26 2015 10:14:40
> gem5 executing on Cagdass-Mac-mini.local command line: 
> build/X86/gem5.opt -d 
> build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic 
> -re /Users/cdirik/Projects/gem5/tests/run.py 
> build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic
>
> Global frequency set at 1 ticks per second
> info: kernel located at: 
> /Users/cdirik/Projects/gem5-files/dist/m5/system/binaries/x86_64-vmlinux-2.6.22.9
>0: rtc: Real-time clock set to Sun Jan  1 00:00:00 2012
> info: Entering event queue @ 0.  Starting simulation...
>
> 
> From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Andreas 
> Sandberg [andreas.sandb...@arm.com]
> Sent: Tuesday, June 30, 2015 2:16 PM
> To: gem5 Developer List
> Subject: Re: [gem5-dev] X86 FS regression test fails on OSX with 
> "Abort trap: 6" error
>
> On 30/06/2015 20:05, "Cagdas Dirik (cdirik)"  wrote:
>
>> Hi all,
>>
>> After recent updates to fix build on OSX, I gave a try to set up my 
>> gem5 development environment on OSX.
>> However using latest gem5 from dev branch, and running X86 and ARM 
>> regression tests, X86 full system tests are failing with "Abort trap: 6"
>> right on/after "Initialization CPU#0".
>>
>> The tests I am referring are:
>> build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic
>> build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing
>>
>> I don't have any idea where to start debugging. Does anyone have any 
>> idea what might be incompatible? Is this (running gem5 on OSX) a futile 
>> effort?
> A SIGABRT typically means that gem5¹s internal checks failed. If you 
> look in the tests¹ build directories, you should find the output from 
> the simulator. Specifically, you¹re looking for simerr and simout. The 
> former should contain an error message that describes why the test case 
> failed.
>
> My guess is that you¹re missing one or more of the binaries to run the 
> tests.
>
> //Andreas
>
>
> -- IMPORTANT NOTICE: The contents of this email and any attachments are 
> confidential and may also be privileged. If you are not the intended 
> recipient, please notify the sender immediately and do not disclose the 
> contents to any other person, use it for any purpose, or store or copy the 
> information in any medium.  Thank you.
>
> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 

Re: [gem5-dev] X86 FS regression test fails on OSX with "Abort trap: 6" error

[Cagdas Dirik (cdirik)]

Thank you for suggestions Nilay and Andreas!

Andreas, I looked at the simerr and simout files, and there are no indications 
of a missing file. All kernel images and disk images are under $M5_PATH - I am 
basically using same set of files which pass regression tests under Linux. As a 
reference I pasted the outputs from those files at the end.

I did not find any "Initializing CPU#" messages from gem5, then I think I need 
to pinpoint the erroring module in the kernel.

I also tried kernel 2.6.26 and passing linux-x86.img file explicitly from 
command line to gem5 and got the same error message.

Cagdas

$ cat 
build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic/simerr
warn: Sockets disabled, not accepting terminal connections
warn: Sockets disabled, not accepting gdb connections
warn: Reading current count from inactive timer.
warn: Don't know what interrupt to clear for console.

$ cat 
build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic/simout
gem5 Simulator System.  http://gem5.org
gem5 is copyrighted software; use the --copyright option for details.

gem5 compiled Jun 23 2015 13:44:27
gem5 started Jun 26 2015 10:14:40
gem5 executing on Cagdass-Mac-mini.local
command line: build/X86/gem5.opt -d 
build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic -re 
/Users/cdirik/Projects/gem5/tests/run.py 
build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic

Global frequency set at 1 ticks per second
info: kernel located at: 
/Users/cdirik/Projects/gem5-files/dist/m5/system/binaries/x86_64-vmlinux-2.6.22.9
  0: rtc: Real-time clock set to Sun Jan  1 00:00:00 2012
info: Entering event queue @ 0.  Starting simulation...


From: gem5-dev [gem5-dev-boun...@gem5.org] on behalf of Andreas Sandberg 
[andreas.sandb...@arm.com]
Sent: Tuesday, June 30, 2015 2:16 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] X86 FS regression test fails on OSX with "Abort trap: 
6" error

On 30/06/2015 20:05, "Cagdas Dirik (cdirik)"  wrote:

>Hi all,
>
>After recent updates to fix build on OSX, I gave a try to set up my gem5
>development environment on OSX.
>However using latest gem5 from dev branch, and running X86 and ARM
>regression tests, X86 full system tests are failing with "Abort trap: 6"
>right on/after "Initialization CPU#0".
>
>The tests I am referring are:
>build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic
>build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing
>
>I don't have any idea where to start debugging. Does anyone have any idea
>what might be incompatible? Is this (running gem5 on OSX) a futile effort?

A SIGABRT typically means that gem5¹s internal checks failed. If you look
in the tests¹ build directories, you should find the output from the
simulator. Specifically, you¹re looking for simerr and simout. The former
should contain an error message that describes why the test case failed.

My guess is that you¹re missing one or more of the binaries to run the
tests.

//Andreas


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] X86 FS regression test fails on OSX with "Abort trap: 6" error

[Cagdas Dirik (cdirik)]

Hi all,

After recent updates to fix build on OSX, I gave a try to set up my gem5 
development environment on OSX.
However using latest gem5 from dev branch, and running X86 and ARM regression 
tests, X86 full system tests are failing with "Abort trap: 6" right on/after 
"Initialization CPU#0".

The tests I am referring are:
build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic
build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing

I don't have any idea where to start debugging. Does anyone have any idea what 
might be incompatible? Is this (running gem5 on OSX) a futile effort?

Thank you in advance!

Cagdas
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] dynamically linked executables in SE mode

[Cagdas Dirik (cdirik)]

Hi Steve,

We are interested to get dynamic linking in SE mode here at Micron. It is great 
news that patches for it exists. Would greatly appreciate if you can have them 
out.

Thank you!

Cagdas

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Steve Reinhardt
Sent: Thursday, March 19, 2015 2:41 PM
To: gem5 Developer List
Subject: Re: [gem5-dev] dynamically linked executables in SE mode

Hi Gabe,

We already have dynamic linking in SE mode working here at AMD and it's very 
useful.  It's just a big wad of various patches and we haven't had the time to 
get them posted.  So I'd say don't bother starting down this path, since it 
would be redundant; if you have interest, maybe that will motivate us to get 
them out.

Glad you asked...

Steve


On Thu, Mar 19, 2015 at 2:32 PM, Gabe Black  wrote:

> I've been toying with the idea of getting dynamically linked 
> executables to work in SE mode. I don't have a lot of time to invest 
> so it might be a long time before there's anything to show for it. Is that of 
> interest to folks?
>
> Gabe
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev
>
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] X86 regression failures

[Cagdas Dirik (cdirik) via gem5-dev]

Did you make sure you have all system files at dist/m5/system folder and 
M5_PATH environment variable set properly?

As Nilay suggested, if you look at simout and simerr files, you will very 
likely see that it is looking for disk image file, swap file, and kernel.

Cagdas

On Jan 16, 2015, at 11:59 AM, Nilay Vaish via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:

On Fri, 16 Jan 2015, mike upton via gem5-dev wrote:

I was trying to run a regression, I am still learning.

This is off of a clean build of the top of tree:
hg clone http://repo.gem5.org/gem5



I ran:

util/regress -j4 --builds X86


and I get a number of failures.

* build/X86/tests/opt/quick/se/00.hello/x86/linux/o3-timing passed

* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-atomic passed

* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing passed

* build/X86/tests/opt/quick/se/00.hello/x86/linux/simple-timing-ruby
passed

* build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-atomic
FAILED!

* build/X86/tests/opt/quick/fs/10.linux-boot/x86/linux/pc-simple-timing
FAILED!

The failures are both of the fs tests.

Am I doing something wrong?


Typically I look at the files simout and simerr in the directory for the test 
to get an idea about what went wrong.

--
Nilay
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2553: dev: Prevent intel 8254 timer events firing before startup

[Cagdas Dirik (cdirik) via gem5-dev]

Thank you for pointing out the ARM full-system files!

Regarding stats for X86 FS regression tests, how is “within reason” defined? 
For the sake of this CL, there should not be any change, but I also assume that 
there are random components to latencies and module interaction in FS mode. 
What is typical workflow for developers to tackle these stat changes?

Cagdas

On Jan 6, 2015, at 2:30 PM, Andreas Hansson 
mailto:andreas.hans...@arm.com>> wrote:

Hi Cagdas,

I merely wanted to point out that the ARM full-system files can be found and 
downloaded from http://gem5.org/Download

The stats for the X86 regressions will have to be updated once they are 
confirmed to be “within reason” with respect to the changeset.

Thanks again for getting the patch in shape.

Andreas

From: Cagdas Dirik mailto:cdi...@micron.com>>
Reply-To: Cagdas Dirik mailto:cdi...@micron.com>>
Date: Tuesday, 6 January 2015 22:13
To: Andrew Bardsley mailto:andrew.bards...@arm.com>>, 
Ali Saidi mailto:sa...@umich.edu>>, Andreas Hansson 
mailto:andreas.hans...@arm.com>>
Cc: Cagdas Dirik mailto:cdi...@micron.com>>, Nilay Vaish 
mailto:ni...@cs.wisc.edu>>, Default 
mailto:gem5-dev@gem5.org>>
Subject: Re: Review Request 2553: dev: Prevent intel 8254 timer events firing 
before startup

This is an automatically generated e-mail. To reply, visit: 
http://reviews.gem5.org/r/2553/

Review request for Default, Andrew Bardsley, Andreas Hansson, and Ali Saidi.
By Cagdas Dirik.

Updated Jan. 6, 2015, 10:13 p.m.

Changes

Updated to address regression issues with MIPS and Alpha.
Most of the regression tests pass. Some ARM tests are failing because 
vmlinux.aarch64.20140821 and vmlinux.aarch32.ll_20131205.0-gem5 are missing. 
And I cannot find these files anywhere in gem5.org. If someone 
can point me in their direction, I will greatly appreciate it.
Also some SPARC tests are failing because insttest files are missing. Again, 
where can I find these files?
X86 tests show changed timing. I am not sure if to waive this now, or it 
requires further update. Following the discussion on regression tests, this 
looks to be moving target.


Repository: gem5
Description

This change includes edits to Intel8254Timer to prevent counter events firing 
before startup to comply with SimObject initialization call sequence.


Diffs (updated)

  *   src/dev/alpha/tsunami_io.cc (9ac724889705)
  *   src/dev/intel_8254_timer.hh (9ac724889705)
  *   src/dev/intel_8254_timer.cc (9ac724889705)
  *   src/dev/mips/malta_io.cc (9ac724889705)
  *   src/dev/x86/i8254.hh (9ac724889705)
  *   src/dev/x86/i8254.cc (9ac724889705)

View Diff


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium. Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No: 2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No: 2548782

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] what is EioProcess SimObject and what is missing for regression tests?

[Cagdas Dirik (cdirik) via gem5-dev]

I am going through regression testing, and I see that some of my tests are 
skipped, but I cannot make anything out of the error message. For example some 
of my alpha tests are skipped because "Test requires the 'EioProcess' 
SimObject.". I see some very old posts on EioProcess, but does not really 
explain much to me. Can someone give me a short description? Is there a 
specific download to /dist/m5/system for these tests to run?

Thanks in advance!

Cagdas
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] how to post diff files on review board

[Cagdas Dirik (cdirik) via gem5-dev]

Thanks for the pointer Nilay, I will look into review board extension.

I think my last try worked, not quite sure what was different though.

On Dec 4, 2014, at 10:30 AM, Nilay Vaish via gem5-dev  wrote:

> I think the problem you are experiencing happens when reviewboard is unable 
> to figure out the version of the repo on which to apply your patch.
> 
> Initially I also used to use the web interface posting reviews.  But now I 
> use the reviewboard extension of mercurial.  I find it less error prone. For 
> a new review request, I use: hg postreview -o tip.  For updating a request, I 
> use: hg postreview -p -e  -u.
> 
> --
> Nilay
> 
> On Thu, 4 Dec 2014, Cagdas Dirik \(cdirik\) via gem5-dev wrote:
> 
>> I am having a problem uploading my diff files for a review request. I 
>> generated diff file using hg export but when I upload them to review board I 
>> keep getting hunk failed error messages, but no reason why. Diff file looks 
>> normal. Any ideas on what may be wrong? Or am I using wrong process to 
>> update a review request?
>> 
>> Case in question is r/2545: http://reviews.gem5.org/r/2545/
>> 
>> Thanks in advance.
>> 
>> Cagdas
>> ___
>> gem5-dev mailing list
>> gem5-dev@gem5.org
>> http://m5sim.org/mailman/listinfo/gem5-dev
>> 
> ___
> gem5-dev mailing list
> gem5-dev@gem5.org
> http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] how to post diff files on review board

[Cagdas Dirik (cdirik) via gem5-dev]

I am having a problem uploading my diff files for a review request. I generated 
diff file using hg export but when I upload them to review board I keep getting 
hunk failed error messages, but no reason why. Diff file looks normal. Any 
ideas on what may be wrong? Or am I using wrong process to update a review 
request?

Case in question is r/2545: http://reviews.gem5.org/r/2545/

Thanks in advance.

Cagdas
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2504: config: Fix to SystemC example's event handling

[Cagdas Dirik (cdirik) via gem5-dev]

I did not know about those (timely) systemc callbacks - reading about them now. 
Thank you for pointing them out!

Cagdas

On Nov 18, 2014, at 5:10 AM, Andrew Bardsley via gem5-dev 
mailto:gem5-dev@gem5.org>> wrote:

The member functions before_end_of_elaboration and end_of_elaboration are 
defined on sc_core::sc_module and the SystemC simulation kernel handles calling 
them at the appropriate times.

Try printing something in main.cc:SimControl::before_end_of_elaboration and you 
should see that print happening before the simulation starts running.

- Andrew

-Original Message-
From: gem5-dev [mailto:gem5-dev-boun...@gem5.org] On Behalf Of Cagdas Dirik via 
gem5-dev
Sent: 17 November 2014 23:45
To: Cagdas Dirik; Andreas Hansson; Default
Subject: Re: [gem5-dev] Review Request 2504: config: Fix to SystemC example's 
event handling


---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2504/#review5460
---


I think you are missing the call to SimControl::before_end_of_elaboration(). 
May be after sim_control is instantiated, but before sc_start is called?

int
sc_main(int argc, char **argv)
{
   SimControl sim_control("gem5", argc, argv);

==> sim_control.before_end_of_elaboration();

   sc_core::sc_start();

   return EXIT_SUCCESS;
}

- Cagdas Dirik


On Nov. 17, 2014, 6:19 a.m., Andreas Hansson wrote:

---
This is an automatically generated e-mail. To reply, visit:
http://reviews.gem5.org/r/2504/
---

(Updated Nov. 17, 2014, 6:19 a.m.)


Review request for Default.


Repository: gem5


Description
---

Changeset 10555:d1e51dc6cf86
---
config: Fix to SystemC example's event handling

This patch fixes checkpoint restore in the SystemC hosting example by handling
early PollEvent events correctly before any EventQueue events are posted.

The SystemC event queue handler (SCEventQueue) reports an error if the event
loop is entered with no Events posted.  It is possible for this to happen
after instantiate due to PollEvent events.  This patch separates out
`external' events into a different handler in sc_module.cc to prevent the
error from occurring.


Diffs
-

 util/systemc/Makefile 1a9e235cab09
 util/systemc/main.cc 1a9e235cab09
 util/systemc/sc_module.hh 1a9e235cab09
 util/systemc/sc_module.cc 1a9e235cab09

Diff: http://reviews.gem5.org/r/2504/diff/


Testing
---


Thanks,

Andreas Hansson



___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev


-- IMPORTANT NOTICE: The contents of this email and any attachments are 
confidential and may also be privileged. If you are not the intended recipient, 
please notify the sender immediately and do not disclose the contents to any 
other person, use it for any purpose, or store or copy the information in any 
medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered 
in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, 
Registered in England & Wales, Company No:  2548782

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

[gem5-dev] how do checkpoint save/restore, switch cpu options work in tandem?

[Cagdas Dirik (cdirik) via gem5-dev]

I have been looking at initialization and startup sequence for cxx_config and 
systemc variants, and I am a bit confused on checkpoint save, restore and 
switch cpu options (-s, -r, and -c) because code is a bit inconsistent and 
different that .py variant.

Can anyone provide some clarification please?

For cxx_config, you can NOT specify both -s and -r. However, this check is 
omitted in systemc variant. Is there a specific reason, or simply forgotten?

How do we envision -c flag to really work with -s and -r? Number of ticks 
provided with each of these options end up being relative time between 
checkpoint save/restore and switch cpu, but that is not clear from the usage 
definition (.py variant clearly marks ticks as relative or absolute). Should we 
explicitly mark these ticks as relative time?

Cagdas
___
gem5-dev mailing list
gem5-dev@gem5.org
http://m5sim.org/mailman/listinfo/gem5-dev

Re: [gem5-dev] Review Request 2430: config: Add the ability to read a config file using C++ and Python

[Cagdas Dirik (cdirik) via gem5-dev]

Thank you for the quick response! That solved all seg faults I have encountered 
so far - both X86 and ARM.

Cagdas

On Nov 6, 2014, at 4:06 PM, Andrew Bardsley  wrote:

> Cagdas, can you try adding the line:
> 
> config_manager->startup()
> 
> at line 268 in util/cxx_config/main.cc (after the loadState(checkpoint) line).
> 
> I've tried your ARM example (superficially, on my home machine) and it seems 
> to fix the problem there with running 'hello' with your setup instructions.
> The startup call corresponds to startup in simulate(...) in simulate.py which 
> is guarded by need_startup.  I've obviously forgotten to include that call.
> 
> The proximal error when switching to O3, BTW, was a lack of a call to 
> ROB<>::setActiveThreads because of the lack of a call to 
> Commit::startupStage() because of the lack of a call to O3::startup().
> 
> Let me know if that helps with all your failure cases.
> 
> Thanks for showing up the problem
> 
> - Andrew
> 
> From: gem5-dev [gem5-dev-boun...@gem5.org] On Behalf Of Cagdas Dirik via 
> gem5-dev [gem5-dev@gem5.org]
> Sent: 06 November 2014 23:01
> To: Cagdas Dirik; Andreas Hansson; Ali Saidi; Default
> Subject: Re: [gem5-dev] Review Request 2430: config: Add the ability to read 
> a config file using C++ and Python
> 
>> On Nov. 6, 2014, 7:48 p.m., Cagdas Dirik wrote:
>>> This patch seems to be broken for X86 when restoring from checkpoints. A 
>>> sample test crashes with segmentation fault. Here are the steps:
>>> 0. Sample test program does int array manipulation and creates a checkpoint 
>>> before computation.
>>> 1. Run in se mode with --cpu-type=atomic --mem-type=simple_mem to keep 
>>> things simple. This will create the checkpoint.
>>> 2. Run in se mode with --cpu-type=atomic --mem-type=simple_mem -r 1 and it 
>>> will run fine.
>>> 3. Now run
>>> 
>>> gem5.opt.cxx m5out/config.ini -r m5out/cpt.XYZ
>>> 
>>> and it will seg fault right away at:
>>> 
>>> Simulate:: Entering event queue @ 7088000. Starting simulation...
>>> EventQueue (MainEventQueue-0)::schedule event (Event_21) for 
>>> 18446744073709551615
>>> EventQueue (MainEventQueue-0)::serviceOne event named Event_8 at 7088500
>>> Program received signal SIGSEGV, Segmentation fault.
>>> getPage (addr=4195355, this=0x0) at build/X86/cpu/decode_cache.hh:86
>>> 86  if (recent[0] != pageMap.end()) {
>>> (gdb)
>>> 
>>> Trying it with other cpu-type and other mem-type results in similar seg 
>>> faults. It looks like this patch is missing some state initialization or 
>>> some other checkpoint restore functionality for X86.
>> 
>> Ali Saidi wrote:
>>I assume it's working for you without restoring from checkpoints?
>> 
>>The code looks like state is being restored, but we've only ever tested 
>> it with ARM although I'm not sure why there would be a difference.
>> 
>> Cagdas Dirik wrote:
>>Correct!
> 
> In addition to X86, ARM also seg faulted switching to arm_detailed cpu after 
> restoring from checkpoint. Here are the steps:
> 
> 0. Sample test program does int array manipulation and creates a checkpoint 
> before computation.
> 1. Run in se mode with --cpu-type=atomic --mem-type=simple_mem to keep things 
> simple. This will create the checkpoint
> 2. Run in se mode with --caches --l2cache --cpu-type=arm_detailed 
> --mem-type=simple_mem -r 1
> 3. Now run
> 
> gem5.opt.cxx m5out/config.ini -r m5out/cpt.XYZ -c system.cpu 
> system.switch_cpus 1
> 
> and it will seg fault soon (at about tick delta 48500) at:
> 
> EventQueue (MainEventQueue-0)::serviceOne event named Event_82 at 3837000
> EventQueue (MainEventQueue-0)::schedule event (Event_82) for 3837500
> EventQueue (MainEventQueue-0)::serviceOne event named Event_82 at 3837500
> EventQueue (MainEventQueue-0)::schedule event (Event_82) for 3838000
> EventQueue (MainEventQueue-0)::serviceOne event named Event_82 at 3838000
> Program received signal SIGSEGV, Segmentation fault.
> 0x2b3908e8 in ROB::updateHead (this=this@entry=0xa90438)
>at build/ARM/cpu/o3/rob_impl.hh:413
> 413 list::iterator threads = activeThreads->begin();
> (gdb)
> 
> 
> - Cagdas
> 
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://reviews.gem5.org/r/2430/#review5439
> ---
> 
> 
> On Oct. 9, 2014, 2:32 p.m., Andreas Hansson wrote:
>> 
>> ---
>> This is an automatically generated e-mail. To reply, visit:
>> http://reviews.gem5.org/r/2430/
>> ---
>> 
>> (Updated Oct. 9, 2014, 2:32 p.m.)
>> 
>> 
>> Review request for Default.
>> 
>> 
>> Repository: gem5
>> 
>> 
>> Description
>> ---
>> 
>> Changeset 10440:faea9dd0b3b1
>> ---
>> config: Add the ability to read a config file using C++ and Python
>> 
>> This patch adds the ab

Re: [gem5-dev] Review Request 2430: config: Add the ability to read a config file using C++ and Python

[Cagdas Dirik (cdirik) via gem5-dev]

Correct!

On Nov 6, 2014, at 12:57 PM, Ali Saidi 
mailto:sa...@umich.edu>> wrote:

This is an automatically generated e-mail. To reply, visit: 
http://reviews.gem5.org/r/2430/


On November 6th, 2014, 7:48 p.m. UTC, Cagdas Dirik wrote:

This patch seems to be broken for X86 when restoring from checkpoints. A sample 
test crashes with segmentation fault. Here are the steps:
0. Sample test program does int array manipulation and creates a checkpoint 
before computation.
1. Run in se mode with --cpu-type=atomic --mem-type=simple_mem to keep things 
simple. This will create the checkpoint.
2. Run in se mode with --cpu-type=atomic --mem-type=simple_mem -r 1 and it will 
run fine.
3. Now run

gem5.opt.cxx m5out/config.ini -r m5out/cpt.XYZ

and it will seg fault right away at:

Simulate:: Entering event queue @ 7088000. Starting simulation...
EventQueue (MainEventQueue-0)::schedule event (Event_21) for 
18446744073709551615
EventQueue (MainEventQueue-0)::serviceOne event named Event_8 at 7088500
Program received signal SIGSEGV, Segmentation fault.
getPage (addr=4195355, this=0x0) at build/X86/cpu/decode_cache.hh:86
86  if (recent[0] != pageMap.end()) {
(gdb)

Trying it with other cpu-type and other mem-type results in similar seg faults. 
It looks like this patch is missing some state initialization or some other 
checkpoint restore functionality for X86.

I assume it's working for you without restoring from checkpoints?

The code looks like state is being restored, but we've only ever tested it with 
ARM although I'm not sure why there would be a difference.


- Ali


On October 9th, 2014, 2:32 p.m. UTC, Andreas Hansson wrote:

Review request for Default.
By Andreas Hansson.

Updated Oct. 9, 2014, 2:32 p.m.

Repository: gem5
Description

Changeset 10440:faea9dd0b3b1
---
config: Add the ability to read a config file using C++ and Python

This patch adds the ability to load in config.ini files generated from
gem5 into another instance of gem5 built without Python configuration
support. The intended use case is for configuring gem5 when it is a
library embedded in another simulation system.

A parallel config file reader is also provided purely in Python to
demonstrate the approach taken and to provided similar functionality
for as-yet-unknown use models. The Python configuration file reader
can read both .ini and .json files.

C++ configuration file reading:

A command line option has been added for scons to enable C++ configuration
file reading: --with-cxx-config

There is an example in util/cxx_config that shows C++ configuration in action.
util/cxx_config/README explains how to build the example.

Configuration is achieved by the object CxxConfigManager. It handles
reading object descriptions from a CxxConfigFileBase object which
wraps a config file reader. The wrapper class CxxIniFile is provided
which wraps an IniFile for reading .ini files. Reading .json files
from C++ would be possible with a similar wrapper and a JSON parser.

After reading object descriptions, CxxConfigManager creates
SimObjectParam-derived objects from the classes in the (generated with this
patch) directory build/ARCH/cxx_config

CxxConfigManager can then build SimObjects from those SimObjectParams (in an
order dictated by the SimObject-value parameters on other objects) and bind
ports of the produced SimObjects.

A minimal set of instantiate-replacing member functions are provided by
CxxConfigManager and few of the member functions of SimObject (such as drain)
are extended onto CxxConfigManager.

Python configuration file reading (configs/example/read_config.py):

A Python version of the reader is also supplied with a similar interface to
CxxConfigFileBase (In Python: ConfigFile) to config file readers.

The Python config file reading will handle both .ini and .json files.

The object construction strategy is slightly different in Python from the C++
reader as you need to avoid objects prematurely becoming the children of other
objects when setting parameters.

Port binding also needs to be strictly in the same port-index order as the
original instantiation.



Diffs

  *   SConstruct (148b96b7bc77)
  *   configs/example/read_config.py (PRE-CREATION)
  *   src/SConscript (148b96b7bc77)
  *   src/python/m5/SimObject.py (148b96b7bc77)
  *   src/python/m5/params.py (148b96b7bc77)
  *   src/sim/SConscript (148b96b7bc77)
  *   src/sim/cxx_config.hh (PRE-CREATION)
  *   src/sim/cxx_config.cc (PRE-CREATION)
  *   src/sim/cxx_config_ini.hh (PRE-CREATION)
  *   src/sim/cxx_config_ini.cc (PRE-CREATION)
  *   src/sim/cxx_manager.hh (PRE-CREATION)
  *   src/sim/cxx_manager.cc (PRE-CREATION)
  *   util/cxx_config/Makefile (PRE-CREATION)
  *   util/cxx_config/README (PRE-CREATION)
  *   util/cxx_config/main.cc (PRE-CREATION)
  *   util/cxx_config/stats.hh (PRE-CREATION)
  *   util/cxx_config/stats.cc (PRE-CREATION)

View Diff