[gem5-dev] Re: gem5 Developers' Meeting: December 14th, 5pm (UTC)

[Bobby Bruce via gem5-dev]

This is a friendly reminder that the gem5 Developers meeting is scheduled for 
December 14th at 5pm (UTC). Anyone is free to attend. Zoom meetings and updates 
about this event can be found on the gem5 Discussions page: 
https://github.com/orgs/gem5/discussions/661


--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net

On Dec 7, 2023, at 3:54 PM, Bobby Bruce  wrote:

Dear all,

https://github.com/orgs/gem5/discussions/661

The gem5 Developers' Meeting is scheduled for December 14th at 5pm (UTC). Zoom 
link details and meeting agenda information can be found in the above link to 
the GitHub Discussions page. Anyone who wishes to attend may attend.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] gem5 Developers' Meeting: December 14th, 5pm (UTC)

[Bobby Bruce via gem5-dev]

Dear all,

https://github.com/orgs/gem5/discussions/661

The gem5 Developers' Meeting is scheduled for December 14th at 5pm (UTC). Zoom 
link details and meeting agenda information can be found in the above link to 
the GitHub Discussions page. Anyone who wishes to attend may attend.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Creation of gem5 v23.1.0.0 staging branch scheduled for December 1st

[Bobby Bruce via gem5-dev]

Hey all,

As discussed and agreed upon during our November Developer meeting 
(https://github.com/orgs/gem5/discussions/482), we have scheduled the creation 
of our staging branch from `develop` for December 1st. This means **gem5 
developers have until December 1st to have their contributions merged into 
`develop` for inclusion in version v23.1**. Contributions made after this 
deadline will have to wait for the v24.0 release.

Once created the staging branch will be tested rigorously and our release 
procedures 
https://www.gem5.org/documentation/general_docs/development/release_procedures/ 
followed. The branch shall exist for at least 2 weeks in order to run tests and 
give the community time to inspect the branch. Once the staging branch is found 
to be ready for release it shall be merged into the `stable` branch thus 
officially releasing gem5 v23.1. Assuming a typical 2-week staging branch 
period this to occur on December 15th.

Contributions to the staging branch via pull request are permitted but, in the 
interests of ensuring new bugs are not introduced, good justification should be 
given as to why the change cannot wait for the following release (v24.0). 
Usually contributions to the staging branch are bug fixes or contributions that 
have no chance of changing software functionality (e.g. documentation updates, 
format fixes, etc.). New features or significant enhancements to gem5 should 
continue to be made to the `develop` branch during this time. The staging 
branch will be periodically merged into the `develop` branch to ensure 
contributions made to the staging branch are reflecting in the `develop` branch,

Github Issue https://github.com/gem5/gem5/issues/558 will be used to keep track 
of changes which must be included in v23.1 and therefore should be merged into 
`develop` prior to the staging branch creation.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] GitHub Discussion about dropping Gerrit Change-ID requirement

[Bobby Bruce via gem5-dev]

https://github.com/orgs/gem5/discussions/324

(Note: I won't act on this  without good buy-in from the community. I'd like to 
know what works best for everyone).

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Make m5 internals available to Python interpreter (for syntax highlighting in vscode)

[Bobby Bruce via gem5-dev]

I've created a pull request here which should help: 
https://github.com/gem5/gem5/pull/307.

From playing around with this mypy.stubgen fix, it helps the Pylance 
IntelliSence but it isn't complete. What's notably lacking are doc-strings (so 
methods, classes, etc don't have documentation on arguments come up) and it 
still doesn't understand some imports. `from m5.objects` is still still coming 
up underlined but `System` and `SrcClockDomain` is being parsed correctly.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Sep 12, 2023, at 5:39 AM, Tiberiu Bucur via gem5-dev  
> wrote:
> 
> Hi!
> 
> I use VSCode as my day-to-day text editor and everything in the m5 package 
> (including the package itself) is underlined by the editor, as the underlying 
> Python interpreter cannot locate the package and classes within. Any idea how 
> I can solve this? (I am new to gem5, so explaining in as much detail as 
> possible would be appreciated).
> 
> Thanks,
> Tiberiu
> 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.  14-35-04.png>___
> gem5-dev mailing list -- gem5-dev@gem5.org 
> To unsubscribe send an email to gem5-dev-le...@gem5.org 
> 
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Join th discussion on gem5's PR Merge policy

[Bobby Bruce via gem5-dev]

I've started a discussion on GitHub Discussions regarding the gem5 PR Merge 
Policy and possible improvements: https://github.com/orgs/gem5/discussions/261

Please feel free to join and give input or feedback.
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Hotfix v23.0.0.1: To fix GCN3_X86 compilation

[Bobby Bruce via gem5-dev]

Thanks for this. The Hotfix was made this afternoon and is now on the stable 
branch.

Note: We have no officially moved to the GitHub repo: 
https://github.com/gem5/gem5.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Jul 10, 2023, at 1:58 PM, Bobby Bruce  wrote:
> 
> Dear all,
> 
> I’m planning a hot fix to the v23.0.0 release to address an error found.
> 
> The issue was highlighted here https://gem5.atlassian.net/browse/GEM5-1332. 
> In short, the v23.0.0.0 release can’t compile the “build/GCN3_X86/gem5.opt” 
> binary.
> 
> This came about as we cherry-picked some GPU patches onto the release staging 
> branch and while we ran our compiler checks on the release-staging, these did 
> not include checks for "GCN3_X86" or “VEGA_X86”. I am adding these to the 
> compiler tests here to ensure this does not happen again: 
> https://gem5-review.googlesource.com/c/public/gem5/+/7.
> 
> The relation-chain fixing the “GCN3_X86” and “VEGA_X86” compilations can be 
> found here: https://gem5-review.googlesource.com/c/public/gem5/+/72226. 
> 
> Kind regards,
> Bobby
> 
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
> 
> web: https://www.bobbybruce.net
> 

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Hotfix v23.0.0.1: To fix GCN3_X86 compilation

[Bobby Bruce via gem5-dev]

Dear all,

I’m planning a hot fix to the v23.0.0 release to address an error found.

The issue was highlighted here https://gem5.atlassian.net/browse/GEM5-1332. In 
short, the v23.0.0.0 release can’t compile the “build/GCN3_X86/gem5.opt” binary.

This came about as we cherry-picked some GPU patches onto the release staging 
branch and while we ran our compiler checks on the release-staging, these did 
not include checks for "GCN3_X86" or “VEGA_X86”. I am adding these to the 
compiler tests here to ensure this does not happen again: 
https://gem5-review.googlesource.com/c/public/gem5/+/7.

The relation-chain fixing the “GCN3_X86” and “VEGA_X86” compilations can be 
found here: https://gem5-review.googlesource.com/c/public/gem5/+/72226. 

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #659

[Bobby Bruce via gem5-dev]

This appears to be a Docker failure of some kind. Both the compiler and nightly 
tests dropped at the same time. I think the Docker daemon crashed for some 
reason

No tests failed here. The patches submitted yesterday don’t interact with any 
tests so they should all still pass.

I’ll re-run these now.

To answer you question directly Matt: these tests (Nightly #659) didn’t reach 
the GPU test stage so there’s nothing to see here, but yesterday’s passed and 
you can see the terminal output here: 
https://jenkins.gem5.org/job/nightly/658/consoleText. The GPU tests are still 
just bash scripts for now so the GPU tests fail based on gem5 exit codes and 
all we get is terminal output as a log. From looking at this, it looks like 
square is running as intended.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Jul 7, 2023, at 8:28 AM, Matt Sinclair  
> wrote:
> 
> Hi Bobby,
> 
> How do I read this output?  I wanted to check if Square was still passing, 
> because of the patch Matt P pushed yesterday, but I don't seem to see it.  I 
> realize we are replacing this setup shortly, but nonetheless want to make 
> sure bugs aren't slipping in.
> 
> Thanks,
> Matt
> 
> On Fri, Jul 7, 2023 at 9:14 AM jenkins-no-reply--- via gem5-dev 
> mailto:gem5-dev@gem5.org>> wrote:
>> See 
>> 
>> Changes:
>> 
>> [Bobby R. Bruce] util: Update GitHub Runners Vagrant to overcommit memory
>> 
>> [Bobby R. Bruce] util: '-eq' -> '-ge' for if in vm_manager.sh
>> 
>> [Bobby R. Bruce] util: Add 'shutdown' argument option to vm_manager.sh
>> 
>> [Bobby R. Bruce] util: Add 'swapspace' daemon to runner VM.
>> 
>> 
>> --
>> [...truncated 2.76 MB...]
>> Starting Test Suite: 
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>>  
>> Starting Test Case: 
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>> Test: 
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example
>>  Passed
>> Starting Test Case: 
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outfhfhbv7i/simout 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test1_ld
>> Test: 
>> test-replacement-policy-traces/second_chance_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>>  Passed
>> Logging call to command: 
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d 
>> /tmp/gem5outtvvim2dh -re --silent-redirect 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>>  traces/second_chance_test2_ld 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test2_ld.py
>> Starting Test Suite: 
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>>  
>> Starting Test Case: 
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>> Test: 
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example
>>  Passed
>> Starting Test Case: 
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outtvvim2dh/simout 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test2_ld
>> Test: 
>> test-replacement-policy-traces/second_chance_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>>  Passed
>> Logging call to command: 
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d 
>> /tmp/gem5outqn5wz59b -re --silent-redirect 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>>  traces/second_chance_test3_ld 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/second_chance_test3_ld.py
>> Starting Test Suite: 
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>>  
>> Starting Test Case: 
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>> Test: 
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example
>>  Passed
>> Starting Test Case: 
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outqn5wz59b/simout 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/second_chance_test3_ld
>> Test: 
>> test-replacement-policy-traces/second_chance_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>>  Passed
>> Logging call to command: 
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d 
>> /tmp/gem5out6it56ldp -re --silent-redirect 
>> 

[gem5-dev] Re: [Important Announcement] gem5 Migration from Gerrit to GitHub

[Bobby Bruce via gem5-dev]

Dear all,

We’re still working on ensuring a smooth migration from Gerrit to Github. We 
had originally planned to have migration occur yesterday, on the 15th, but 
found we still need to update documentation and do some further checks to 
ensure the GitHub testing infrastructure meet our requirements. As such, we 
wish to re-schedule the transfer to June 27th.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Jun 6, 2023, at 6:50 AM, Bobby Bruce  wrote:
> 
> Dear all,
> 
> We are excited to inform you that gem5 is migrating from Gerrit to GitHub for 
> code collaboration and version control. This migration is scheduled to take 
> place on June 15th. We believe that this move will provide a more streamlined 
> and efficient development process for our community.
> 
> The new gem5 repository will be hosted at the following URL: 
> https://github.com/gem5/gem5. We kindly request all contributors and 
> maintainers to update their references, links, and remote repo settings 
> accordingly. In order to complete this migration, on June 15th the Gerrit 
> Repository will be changed to a read-only state.
> 
> With this migration, we will be transitioning to a pull-request model for 
> code contributions. This means that contributors will need to undertake 
> following process:
> 
> 1. Fork the gem5 repository on GitHub.
> 2. Create a new branch in your forked repository for your feature or bug fix.
> 3. Commit your changes to the new branch.
> 4. Push the branch to your forked repository.
> 5. Open a pull request from your branch in your forked repository to the main 
> gem5 repository.
> 
> We will continue to use the “develop” branch for development, so please 
> ensure your pull requests are for the gem5 develop branch. Pull requests to 
> the stable branch will be blocked.
> 
> Each pull request will then be evaluated prior to being merged into develop. 
> The new process for merging code into gem5 requires that:
> 
> 1. Continuous Integration (CI) tests must pass. These will be run via GitHub 
> Actions when a PR is created or updated. They are equivalent to kokoro tests 
> today.
> 2. Each pull request must be reviewed and "approved" by at least one 
> reviewer. Like on Gerrit today, anyone can review any changeset.
> 3. A maintainer must merge the PR, which can only happen after the PR is 
> approved by a reviewer and the CI tests pass. We will give gem5 maintainers 
> these permissions over the next few days.
> 
> We understand that this transition may require some adjustments, but we 
> believe that it will provide a more collaborative and transparent environment 
> for our community. The GitHub platform offers robust features for code 
> reviews, discussions, and a familiar interface for many developers. The 
> https://github.com/gem5/gem5 repo is, at the time of writing, setup for 
> members of the community to play with and accustom themselves with the 
> process. We encourage developers to create dummy pull-requests and post 
> reviewers. Merging a pull to develop is currently blocked but will be enabled 
> in June 15th when Gerrit is turned read-only.
> 
> We encourage all community members to actively participate in the migration 
> process and provide feedback or suggestions to make this transition as smooth 
> as possible. As with all big changes we expect teething problems so encourage 
> you to highlight any issues, ask questions, or raise concerns regarding this 
> new model and setup.
> 
> In addition to the gem5 git repository will be making similar migrations for 
> our gem5-resources and gem5-website repositories. We are also enabling GitHub 
> Issues and GitHub Discussions. Please feel free to use these in place of 
> Jira, gem5-dev, gem5-users, and Slack. Depending on the community's 
> preferences, we may migrate to solely using these GitHub-based tools to 
> simplify the organization of the project.
> 
> Thank you for your continued support and dedication to the gem5 project. We 
> look forward to this new chapter in our development journey! We will keep 
> close eye on this thread for discussions about this move. We will work over 
> the coming week to update all the website and related documentation to 
> reflect this change and provide the documentation needed to the community.
> 
> Best regards,
> Bobby
> 
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
> 
> web: https://www.bobbybruce.net
> 
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: v23.0 staging branch to be created on May 24th

[Bobby Bruce via gem5-dev]

Dear all,

As you have probably noticed, we’re already over our original June 9th 
scheduled release of v23.0. The staging branch periods has been productive and 
allowed us to test and fix many parts of the project. We still require a little 
more time with this so are now aiming to have the release complete by the end 
of the month.

As always, you may push bug fixes and other minor improvements to the staging 
branch during this time.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On May 26, 2023, at 5:55 PM, Bobby Bruce  wrote:
> 
> Dear all,
> 
> As of this afternoon, the gem5 v23.0 staging branch has been created. This 
> branch will be intensely tested over the next couple of weeks to ensure it's 
> ready to be merged into the stable branch. The release of gem5 v23.0 (the 
> point at which the staging branch is merged into the stable branch) is now 
> scheduled for June 9th.
> 
> If you have any bug fixes you can submit them to the develop branch then 
> cherry-pick the changes onto the staging branch to ensure they make it into 
> the v23.0 release. 
> 
> More information on our release procedures can be found here: 
> https://www.gem5.org/documentation/general_docs/development/release_procedures/
>  
> 
> 
> 
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
> 
> web: https://www.bobbybruce.net 
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>  
> web: https://www.bobbybruce.net
> 
>> On May 9, 2023, at 2:09 PM, Bobby Bruce  wrote:
>> 
>> Dear all,
>> 
>> I am writing to inform the community that we are planning to create the 
>> staging branch for v23.0 on May 24th. This branch will be created from the 
>> develop branch and intensively tested prior to merging into the stable 
>> branch, thereby completing the release of v23.0. The staging branch will 
>> exist for no less than two weeks with the current goal to officially 
>> releasing on June 7th.  More information about this process can be found in 
>> our release procedures documentation: 
>> https://www.gem5.org/documentation/general_docs/development/release_procedures/
>> 
>> Any patches intended for v23.0 should be submitted over the next two weeks. 
>> We'll work hard to ensure those who have pushed patched to Gerrit are 
>> reviewed as soon as possible. If you feel your patch has been neglected 
>> please reach out. 
>> 
>> Please note that anything which doesn't make it into develop prior to 
>> creation of the staging branch can still make it to the gem5 v23.1 release 
>> later in the year. As always, bug fixes/stability improvements and minor, 
>> inoffensive changes will be permitted for submission to the staging branch 
>> for the time it exists prior to the release.
>> 
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>> 
>> web: https://www.bobbybruce.net
>> 
> 

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] [gem5 on GitHub] Explaining our new testing infrastructure: GitHub Actions, Runners, and current limitations

[Bobby Bruce via gem5-dev]

Dear all,

As you are likely aware, we will be migrating to GitHub, form Gerrit, soon. 
Some have reached out to me with questions about the testing infrastructure on 
GitHub and how it may be used and improved. I shall do so in this email.

GitHub allows for testing via its “Actions” infrastructure. GitHub Actions 
consists of “Workflows” specifies a set of jobs to be run that is executed on a 
specific event. 
GitHub Actions supports a wide range of these events from pull request 
creation, through to specific keywords appearing comments, simple scheduled 
runs and many more. The jobs the workflow specify run commands in a series 
steps and it is highly flexible for a large number of automation tasks. Some 
repos automatically moderate discussion threads, and others use it to build and 
deploy their service. Right now we are just using them to run tests. GitHub 
looks for GitHub Actions specified in a yaml format in “./github/workflows". 
Our current workload yaml file can be found here: 
https://github.com/gem5/gem5/blob/ad0a2d1beaa043c03c0e43406078b3a09a3861ac/.github/workflows/.
 There are many resources online explaining how to create yaml files to 
specific jobs and triggered on specific events so I won’t go into further 
details than this high-level description.

There is one small limitation with GitHub Actions which we will need to change 
procedures for. GitHub only reads the yaml files on the repository’s main 
branch. This means if we want to update which tests are run, or how they are 
run, we need to update the stable branch. After some discussion we believe the 
best policy will be to permit patches to be submitted to the stable branch 
between releases for  changes to these yaml files. Since these files do not 
affect the compilation or running of gem5, the stable branch is still “stable” 
with respect to the end user's interaction with gem5.

Jobs run on “runners". A runner is just a server which accepts GitHub jobs to 
run. They run one job at one time. Typically you would pay GitHub to use their 
runners as most actions complete in a matter of seconds so incur little cost. 
That won’t work for us as some of our tests take days to complete. Fortunately 
GitHub allows for “self-hosted runners”. With tooling provided by GitHub you 
can setup a runner on any machine you want and point it towards the git 
repository it is to accept job requests from. There is one big problem with 
this: A self-hosted runner is not secure. With the right job specification you 
can execute whatever you want on the host hardware. A smaller annoyance is 
GitHub makes it hard, but not impossible, to run more than one runner per 
machine, which is annoying when ideally you want several runners to be 
executing jobs in parallel on machines that can handle them.

Our solution to this is runners setup in virtual machines. We attempted to 
utilize Kubernetes for this for us but found it’s more tailored towards large 
cloud-based clusters where as we want to utilize a smaller number of servers at 
our disposal. After some trial and error we decided it wasn’t the right tool 
for the job. Moving on from this we opted to use Vagrant to create VMs to host 
the runners. I have documented all the scripts I used to do this here: 
https://gem5-review.googlesource.com/c/public/gem5/+/71098. You can consult the 
“README.md” on procedures to setup your own runners. Though I have created some 
scripts to semi-automated the process, it’s still quite manual. It would be 
nice if there was a more “push button” way to do deploy runners. In a similar 
vain, if they break we have to manually go in and restart them. There’s room 
for improvement here.

Right now we have two types of VM’s: “builders” and “runners”. Builders are 
4-core 16GB VMs with their primarily purpose being to build gem5. Runners are 
single-core 6GB VMs with their purpose being to run instances of gem5. Aiming 
for a rough 6 to 1 ratio we have  26 runners and 4 builders spread over 3 
machines though this is very lopsided as 1 of our machines hosts 20 runners. In 
the yaml file the jobs are distributed to either a runner or builder based on 
the “run-on” field.

Though this setup is currently functional, it does have some restrictions and 
pain-points. Of note:

- We do not have a runner which can run KVM tests. For the meantime these are 
skipped. We’re not sure how feasible putting a runner  in a VM which will allow 
KVM is.
- Due to the Weekly GPU tests needing a special docker container built in the 
tests, we need more time to figure out how to do this. At present we get errors 
but are working finding a solution.
- We do not have good tools to orchestrate these VMs. If they go down and they 
need restarted, or new VMs need created, it requires manual effort.
- 20 of our runners are on a single machine. It’d be much better to have a more 
distributed set of runners.
- All our machines are X86. It it may be of value to have some ARM hosts too. 
Particularly to 

[gem5-dev] [Important Announcement] gem5 Migration from Gerrit to GitHub

[Bobby Bruce via gem5-dev]

Dear all,

We are excited to inform you that gem5 is migrating from Gerrit to GitHub for 
code collaboration and version control. This migration is scheduled to take 
place on June 15th. We believe that this move will provide a more streamlined 
and efficient development process for our community.

The new gem5 repository will be hosted at the following URL: 
https://github.com/gem5/gem5. We kindly request all contributors and 
maintainers to update their references, links, and remote repo settings 
accordingly. In order to complete this migration, on June 15th the Gerrit 
Repository will be changed to a read-only state.

With this migration, we will be transitioning to a pull-request model for code 
contributions. This means that contributors will need to undertake following 
process:

1. Fork the gem5 repository on GitHub.
2. Create a new branch in your forked repository for your feature or bug fix.
3. Commit your changes to the new branch.
4. Push the branch to your forked repository.
5. Open a pull request from your branch in your forked repository to the main 
gem5 repository.

We will continue to use the “develop” branch for development, so please ensure 
your pull requests are for the gem5 develop branch. Pull requests to the stable 
branch will be blocked.

Each pull request will then be evaluated prior to being merged into develop. 
The new process for merging code into gem5 requires that:

1. Continuous Integration (CI) tests must pass. These will be run via GitHub 
Actions when a PR is created or updated. They are equivalent to kokoro tests 
today.
2. Each pull request must be reviewed and "approved" by at least one reviewer. 
Like on Gerrit today, anyone can review any changeset.
3. A maintainer must merge the PR, which can only happen after the PR is 
approved by a reviewer and the CI tests pass. We will give gem5 maintainers 
these permissions over the next few days.

We understand that this transition may require some adjustments, but we believe 
that it will provide a more collaborative and transparent environment for our 
community. The GitHub platform offers robust features for code reviews, 
discussions, and a familiar interface for many developers. The 
https://github.com/gem5/gem5 repo is, at the time of writing, setup for members 
of the community to play with and accustom themselves with the process. We 
encourage developers to create dummy pull-requests and post reviewers. Merging 
a pull to develop is currently blocked but will be enabled in June 15th when 
Gerrit is turned read-only.

We encourage all community members to actively participate in the migration 
process and provide feedback or suggestions to make this transition as smooth 
as possible. As with all big changes we expect teething problems so encourage 
you to highlight any issues, ask questions, or raise concerns regarding this 
new model and setup.

In addition to the gem5 git repository will be making similar migrations for 
our gem5-resources and gem5-website repositories. We are also enabling GitHub 
Issues and GitHub Discussions. Please feel free to use these in place of Jira, 
gem5-dev, gem5-users, and Slack. Depending on the community's preferences, we 
may migrate to solely using these GitHub-based tools to simplify the 
organization of the project.

Thank you for your continued support and dedication to the gem5 project. We 
look forward to this new chapter in our development journey! We will keep close 
eye on this thread for discussions about this move. We will work over the 
coming week to update all the website and related documentation to reflect this 
change and provide the documentation needed to the community.

Best regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #620

[Bobby Bruce via gem5-dev]

Ah! Thanks Matt P. I didn’t realize this was the fix! Thanks!

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On May 31, 2023, at 1:28 PM, Poremba, Matthew  wrote:
> 
> [AMD Official Use Only - General]
> 
> https://gem5-review.googlesource.com/c/public/gem5/+/71078
>  
> -Matt
>  
> From: Matt Sinclair  <mailto:mattdsinclair.w...@gmail.com>> 
> Sent: Wednesday, May 31, 2023 1:22 PM
> To: The gem5 Developer List mailto:gem5-dev@gem5.org>>
> Cc: Bobby Bruce mailto:bbr...@ucdavis.edu>>; Poremba, 
> Matthew mailto:matthew.pore...@amd.com>>
> Subject: Re: [gem5-dev] Re: Build failed in Jenkins: nightly #620
>  
> Caution: This message originated from an External Source. Use proper caution 
> when opening attachments, clicking links, or responding.
>  
> I’m confused, there weren’t any recent GPU commits, right?  So someone other 
> than Matt P or us must have broken things?
>  
> Matt
>  
> On Wed, May 31, 2023 at 3:19 PM Bobby Bruce via gem5-dev  <mailto:gem5-dev@gem5.org>> wrote:
> Hey Matt, 
>  
> At least one of the reason’s the Nightly tests are failing is a GPU test 
> failure. You can reproduce it using:
>  
> ```
> wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
>  
> docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) 
> gcr.io/gem5-test/gcn-gpu:latest <http://gcr.io/gem5-test/gcn-gpu:latest> 
> scons build/GCN3_X86/gem5.opt -j`nproc`
>  
> docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) 
> gcr.io/gem5-test/gcn-gpu:latest <http://gcr.io/gem5-test/gcn-gpu:latest> 
> build/GCN3_X86/gem5.opt configs/example/apu_se.py --reg-alloc-policy=dynamic 
> -n3 -c square
> ```
>  
> Could someone on your end look into this? It appears to encounter a 
> segmentation fault.
>  
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>  
> web: https://www.bobbybruce.net <https://www.bobbybruce.net/>
> 
> 
> On May 29, 2023, at 3:28 PM, jenkins-no-reply--- via gem5-dev 
> mailto:gem5-dev@gem5.org>> wrote:
>  
> See <https://jenkins.gem5.org/job/nightly/620/display/redirect>
> 
> Changes:
> 
> 
> --
> [...truncated 4.14 MB...]
> [ CXX] GCN3_X86/debug/VIOIface.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOConsole.cc
> [ CXX] GCN3_X86/debug/VIOConsole.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOBlock.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9P.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9PData.cc
> [ CXX] GCN3_X86/debug/VIOBlock.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9P.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9PData.cc -> .o
> [ CXX] GCN3_X86/python/m5/defines.py.cc <http://defines.py.cc/> -> .o
> [ CXX] GCN3_X86/python/m5/info.py.cc <http://info.py.cc/> -> .o
> [ CXX] src/base/date.cc -> GCN3_X86/base/date.o
> [LINK]  -> GCN3_X86/gem5.opt
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
> Please make sure to check the mailing list for deprecation
> announcements.
> + wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
> + mkdir -p tests/testing-results
> + docker run --rm -u 118: --volume 
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>  -w /nobackup/jenkins/workspace/nightly/tests/.. --memory=18g 
> gcr.io/gem5-test/gcn-gpu:latest 
> <http://gcr.io/gem5-test/gcn-gpu:latest>build/GCN3_X86/gem5.opt 
> configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
> Global frequency set at 1 ticks per second
> src/mem/dram_interface.cc:690: warn: DRAM device capacity (8192 Mbytes) does 
> not match the address range assigned (512 Mbytes)
> src/base/statistics.hh:279: warn: One of the stats is a legacy stat. Legacy 
> stat is a stat that does not belong to any statistics::Group. Legacy stat is 
> deprecated.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range 
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide 
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range 
> [1:75] into equal-sized buckets. Roun

[gem5-dev] Re: Build failed in Jenkins: nightly #620

[Bobby Bruce via gem5-dev]

Hey Matt,

At least one of the reason’s the Nightly tests are failing is a GPU test 
failure. You can reproduce it using:

```
wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square

docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) 
gcr.io/gem5-test/gcn-gpu:latest  scons 
build/GCN3_X86/gem5.opt -j`nproc`

docker run --rm -u $UID:$GID --volume $(pwd):$(pwd) -w $(pwd) 
gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt 
configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
```

Could someone on your end look into this? It appears to encounter a 
segmentation fault.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On May 29, 2023, at 3:28 PM, jenkins-no-reply--- via gem5-dev 
>  wrote:
> 
> See 
> 
> Changes:
> 
> 
> --
> [...truncated 4.14 MB...]
> [ CXX] GCN3_X86/debug/VIOIface.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOConsole.cc
> [ CXX] GCN3_X86/debug/VIOConsole.cc -> .o
> [ TRACING]  -> GCN3_X86/debug/VIOBlock.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9P.cc
> [ TRACING]  -> GCN3_X86/debug/VIO9PData.cc
> [ CXX] GCN3_X86/debug/VIOBlock.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9P.cc -> .o
> [ CXX] GCN3_X86/debug/VIO9PData.cc -> .o
> [ CXX] GCN3_X86/python/m5/defines.py.cc -> .o
> [ CXX] GCN3_X86/python/m5/info.py.cc -> .o
> [ CXX] src/base/date.cc -> GCN3_X86/base/date.o
> [LINK]  -> GCN3_X86/gem5.opt
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
> Please make sure to check the mailing list for deprecation
> announcements.
> + wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
> + mkdir -p tests/testing-results
> + docker run --rm -u 118: --volume 
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>  -w /nobackup/jenkins/workspace/nightly/tests/.. --memory=18g 
> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt 
> configs/example/apu_se.py --reg-alloc-policy=dynamic -n3 -c square
> Global frequency set at 1 ticks per second
> src/mem/dram_interface.cc:690: warn: DRAM device capacity (8192 Mbytes) does 
> not match the address range assigned (512 Mbytes)
> src/base/statistics.hh:279: warn: One of the stats is a legacy stat. Legacy 
> stat is a stat that does not belong to any statistics::Group. Legacy stat is 
> deprecated.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range 
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide 
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range 
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide 
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range 
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide 
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (5) does not divide range 
> [1:75] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:10] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (2) does not divide range 
> [1:64] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide 
> range [1:1e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide 
> range [1:1.6e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not divide 
> range [1:1.6e+06] into equal-sized buckets. Rounding up.
> src/base/stats/storage.hh:278: warn: Bucket size (1) does not 

[gem5-dev] Re: v23.0 staging branch to be created on May 24th

[Bobby Bruce via gem5-dev]

Dear all,

As of this afternoon, the gem5 v23.0 staging branch has been created. This 
branch will be intensely tested over the next couple of weeks to ensure it's 
ready to be merged into the stable branch. The release of gem5 v23.0 (the point 
at which the staging branch is merged into the stable branch) is now scheduled 
for June 9th.

If you have any bug fixes you can submit them to the develop branch then 
cherry-pick the changes onto the staging branch to ensure they make it into the 
v23.0 release. 

More information on our release procedures can be found here: 
https://www.gem5.org/documentation/general_docs/development/release_procedures/


Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net 
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On May 9, 2023, at 2:09 PM, Bobby Bruce  wrote:
> 
> Dear all,
> 
> I am writing to inform the community that we are planning to create the 
> staging branch for v23.0 on May 24th. This branch will be created from the 
> develop branch and intensively tested prior to merging into the stable 
> branch, thereby completing the release of v23.0. The staging branch will 
> exist for no less than two weeks with the current goal to officially 
> releasing on June 7th.  More information about this process can be found in 
> our release procedures documentation: 
> https://www.gem5.org/documentation/general_docs/development/release_procedures/
> 
> Any patches intended for v23.0 should be submitted over the next two weeks. 
> We'll work hard to ensure those who have pushed patched to Gerrit are 
> reviewed as soon as possible. If you feel your patch has been neglected 
> please reach out. 
> 
> Please note that anything which doesn't make it into develop prior to 
> creation of the staging branch can still make it to the gem5 v23.1 release 
> later in the year. As always, bug fixes/stability improvements and minor, 
> inoffensive changes will be permitted for submission to the staging branch 
> for the time it exists prior to the release.
> 
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
> 
> web: https://www.bobbybruce.net
> 

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #612

[Bobby Bruce via gem5-dev]

I’ve fixed the nightly failures with this patch: 
https://gem5-review.googlesource.com/c/public/gem5/+/70860

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On May 21, 2023, at 5:04 PM, jenkins-no-reply--- via gem5-dev 
>  wrote:
> 
> See 
> 
> Changes:
> 
> 
> --
> [...truncated 4.93 MB...]
> [   SHCXX] ARM/python/_m5/param_PerfectCompressor.cc -> .os
> [SO Param] m5.objects.BloomFilters, BloomFilterBase -> 
> ARM/python/_m5/param_BloomFilterBase.cc
> [SO Param] m5.objects.FuncUnit, FUDesc -> ARM/python/_m5/param_FUDesc.cc
> [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItemBytes -> 
> ARM/params/QemuFwCfgItemBytes.hh
> [CXXCPRCC] m5.objects.Device, PioDevice -> ARM/cxx_config/PioDevice.cc
> [SO Param] m5.objects.DRAMInterface, DRAMInterface -> 
> ARM/python/_m5/param_DRAMInterface.cc
> [SO Param] m5.objects.ClockedObject, ClockedObject -> 
> ARM/python/_m5/param_ClockedObject.cc
> [   SHCXX] ARM/python/_m5/param_QemuFwCfgItemFile.cc -> .os
> [   SHCXX] ARM/cxx_config/QemuFwCfg.cc -> .os
> [CXXCPRHH] m5.objects.Device, PioDevice -> ARM/cxx_config/PioDevice.hh
> [   SHCXX] src/dev/qemu/fw_cfg.cc -> ARM/dev/qemu/fw_cfg.os
> [   SHCXX] ARM/python/_m5/param_ClockedObject.cc -> .os
> [   SHCXX] ARM/cxx_config/QemuFwCfgItemBytes.cc -> .os
> [   SHCXX] ARM/cxx_config/PioDevice.cc -> .os
> [   SHCXX] ARM/python/_m5/param_QemuFwCfg.cc -> .os
> [   SHCXX] ARM/cxx_config/QemuFwCfgMmio.cc -> .os
> [   SHCXX] ARM/python/_m5/param_QemuFwCfgItemBytes.cc -> .os
> [   SHCXX] ARM/cxx_config/QemuFwCfgItemString.cc -> .os
> [   SHCXX] ARM/python/_m5/param_QemuFwCfgMmio.cc -> .os
> [   SHCXX] ARM/cxx_config/QemuFwCfgItem.cc -> .os
> [   SHCXX] ARM/python/_m5/param_QemuFwCfgItemString.cc -> .os
> [   SHCXX] ARM/cxx_config/QemuFwCfgIo.cc -> .os
> [   SHCXX] ARM/python/_m5/param_QemuFwCfgItem.cc -> .os
> [   SHCXX] ARM/cxx_config/QemuFwCfgItemFile.cc -> .os
> [   SHCXX] ARM/python/_m5/param_QemuFwCfgIo.cc -> .os
> [SO Param] m5.objects.TimingExpr, TimingExprRef -> 
> ARM/python/_m5/param_TimingExprRef.cc
> [CXXCPRCC] m5.objects.VirtIORng, VirtIORng -> ARM/cxx_config/VirtIORng.cc
> [SO Param] m5.objects.SerialLink, SerialLink -> ARM/params/SerialLink.hh
> [SO Param] m5.objects.ArmNativeTrace, ArmNativeTrace -> 
> ARM/params/ArmNativeTrace.hh
> [CXXCPRHH] m5.objects.VirtIORng, VirtIORng -> ARM/cxx_config/VirtIORng.hh
> [SO Param] m5.objects.FuncUnit, FUDesc -> ARM/params/FUDesc.hh
> [   SHCXX] src/mem/serial_link.cc -> ARM/mem/serial_link.os
> [   SHCXX] ARM/python/_m5/param_ArmNativeTrace.cc -> .os
> [   SHCXX] ARM/cxx_config/ArmNativeTrace.cc -> .os
> [   SHCXX] ARM/cxx_config/VirtIORng.cc -> .os
> [   SHCXX] src/arch/arm/nativetrace.cc -> ARM/arch/arm/nativetrace.os
> [   SHCXX] ARM/cxx_config/FUPool.cc -> .os
> [   SHCXX] src/cpu/o3/fetch.cc -> ARM/cpu/o3/fetch.os
> [   SHCXX] src/cpu/o3/rename_map.cc -> ARM/cpu/o3/rename_map.os
> [   SHCXX] ARM/python/_m5/param_OpDesc.cc -> .os
> [   SHCXX] src/cpu/o3/checker.cc -> ARM/cpu/o3/checker.os
> [   SHCXX] src/cpu/o3/iew.cc -> ARM/cpu/o3/iew.os
> [   SHCXX] src/cpu/o3/commit.cc -> ARM/cpu/o3/commit.os
> [   SHCXX] src/cpu/o3/lsq_unit.cc -> ARM/cpu/o3/lsq_unit.os
> [   SHCXX] ARM/python/_m5/param_FUPool.cc -> .os
> [   SHCXX] src/cpu/o3/dyn_inst.cc -> ARM/cpu/o3/dyn_inst.os
> [   SHCXX] src/cpu/o3/rename.cc -> ARM/cpu/o3/rename.os
> [   SHCXX] ARM/cxx_config/BaseO3Checker.cc -> .os
> [   SHCXX] src/cpu/o3/probe/simple_trace.cc -> 
> ARM/cpu/o3/probe/simple_trace.os
> [   SHCXX] ARM/cxx_config/BaseO3CPU.cc -> .os
> [   SHCXX] src/cpu/o3/fu_pool.cc -> ARM/cpu/o3/fu_pool.os
> [   SHCXX] ARM/python/_m5/param_FUDesc.cc -> .os
> [   SHCXX] src/cpu/o3/lsq.cc -> ARM/cpu/o3/lsq.os
> [   SHCXX] src/cpu/o3/thread_state.cc -> ARM/cpu/o3/thread_state.os
> [   SHCXX] src/cpu/o3/decode.cc -> ARM/cpu/o3/decode.os
> [   SHCXX] ARM/python/_m5/param_BaseO3Checker.cc -> .os
> [   SHCXX] ARM/python/_m5/param_BaseO3CPU.cc -> .os
> [   SHCXX] ARM/cxx_config/OpDesc.cc -> .os
> [   SHCXX] src/cpu/o3/rob.cc -> ARM/cpu/o3/rob.os
> [   SHCXX] src/cpu/func_unit.cc -> ARM/cpu/func_unit.os
> [   SHCXX] src/cpu/o3/inst_queue.cc -> ARM/cpu/o3/inst_queue.os
> [   SHCXX] src/cpu/o3/thread_context.cc -> ARM/cpu/o3/thread_context.os
> [   SHCXX] src/cpu/o3/cpu.cc -> ARM/cpu/o3/cpu.os
> [   SHCXX] src/cpu/o3/mem_dep_unit.cc -> ARM/cpu/o3/mem_dep_unit.os
> [   SHCXX] ARM/cxx_config/FUDesc.cc -> .os
> [   SHCXX] ARM/python/_m5/param_SerialLink.cc -> .os
> [   SHCXX] ARM/cxx_config/SerialLink.cc -> .os
> [SO Param] m5.objects.BranchPredictor, TournamentBP -> 
> ARM/python/_m5/param_TournamentBP.cc
> [SO Param] m5.objects.TimingExpr, TimingExprRef -> ARM/params/TimingExprRef.hh
> [SO Param] m5.objects.PcCountTracker, PcCountTrackerManager -> 
> ARM/params/PcCountTrackerManager.hh
> [   SHCXX] ARM/cxx_config/TimingExprSrcReg.cc -> .os
> [   SHCXX] 

[gem5-dev] v23.0 staging branch to be created on May 24th

[Bobby Bruce via gem5-dev]

Dear all,

I am writing to inform the community that we are planning to create the staging 
branch for v23.0 on May 24th. This branch will be created from the develop 
branch and intensively tested prior to merging into the stable branch, thereby 
completing the release of v23.0. The staging branch will exist for no less than 
two weeks with the current goal to officially releasing on June 7th.  More 
information about this process can be found in our release procedures 
documentation: 
https://www.gem5.org/documentation/general_docs/development/release_procedures/

Any patches intended for v23.0 should be submitted over the next two weeks. 
We'll work hard to ensure those who have pushed patched to Gerrit are reviewed 
as soon as possible. If you feel your patch has been neglected please reach 
out. 

Please note that anything which doesn't make it into develop prior to creation 
of the staging branch can still make it to the gem5 v23.1 release later in the 
year. As always, bug fixes/stability improvements and minor, inoffensive 
changes will be permitted for submission to the staging branch for the time it 
exists prior to the release.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #571

[Bobby Bruce via gem5-dev]

The following patch should fix this nightly bug: 
https://gem5-review.googlesource.com/c/public/gem5/+/69717

There was a small bug introduced where header files were not being added to the 
“build” directory. This broke the SST compilation as it uses the “build” 
directory as a include path.

In addition, this patch will also fix the SST Makefile to not use the headers 
in the “build” directory. I think this is bad practice:
https://gem5-review.googlesource.com/c/public/gem5/+/69718

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Apr 10, 2023, at 3:34 PM, jenkins-no-reply--- via gem5-dev 
>  wrote:
> 
> See 
> 
> Changes:
> 
> [gabe.black] base: Add support for unix domain sockets in ListenSocket.
> 
> 
> --
> [...truncated 4.44 MB...]
> [SO Param] m5.objects.QemuFwCfg, QemuFwCfgMmio -> 
> RISCV/python/_m5/param_QemuFwCfgMmio.cc
> [   SHCXX] RISCV/python/_m5/param_QemuFwCfgMmio.cc -> .os
> [ TRACING]  -> RISCV/debug/QemuFwCfg.hh
> [ TRACING]  -> RISCV/debug/QemuFwCfgVerbose.hh
> [ TRACING]  -> RISCV/debug/QemuFwCfg.cc
> [   SHCXX] src/dev/qemu/fw_cfg.cc -> RISCV/dev/qemu/fw_cfg.os
> [ TRACING]  -> RISCV/debug/QemuFwCfgVerbose.cc
> [   SHCXX] RISCV/debug/QemuFwCfg.cc -> .os
> [   SHCXX] RISCV/dev/serial/Serial.py.cc -> .os
> [   SHCXX] RISCV/debug/QemuFwCfgVerbose.cc -> .os
> [SO Param] m5.objects.Serial, SerialDevice -> 
> RISCV/python/_m5/param_SerialDevice.cc
> [SO Param] m5.objects.Serial, SerialNullDevice -> 
> RISCV/python/_m5/param_SerialNullDevice.cc
> [SO Param] m5.objects.Serial, SerialDevice -> RISCV/params/SerialDevice.hh
> [SO Param] m5.objects.Serial, SerialNullDevice -> 
> RISCV/params/SerialNullDevice.hh
> [   SHCXX] RISCV/dev/serial/Terminal.py.cc -> .os
> [SO Param] m5.objects.Terminal, Terminal -> RISCV/python/_m5/param_Terminal.cc
> [ENUM STR] m5.objects.Terminal, TerminalDump -> RISCV/enums/TerminalDump.cc
> [   SHCXX] RISCV/python/_m5/param_SerialDevice.cc -> .os
> [   SHCXX] RISCV/dev/serial/Uart.py.cc -> .os
> [   SHCXX] RISCV/python/_m5/param_SerialNullDevice.cc -> .os
> [ENUMDECL] m5.objects.Terminal, TerminalDump -> RISCV/enums/TerminalDump.hh
> [SO Param] m5.objects.Terminal, Terminal -> RISCV/params/Terminal.hh
> [   SHCXX] RISCV/enums/TerminalDump.cc -> .os
> [   SHCXX] RISCV/python/_m5/param_Terminal.cc -> .os
> [SO Param] m5.objects.Uart, Uart -> RISCV/python/_m5/param_Uart.cc
> [SO Param] m5.objects.Uart, Uart -> RISCV/params/Uart.hh
> [   SHCXX] RISCV/python/_m5/param_Uart.cc -> .os
> [SO Param] m5.objects.Uart, SimpleUart -> RISCV/python/_m5/param_SimpleUart.cc
> [SO Param] m5.objects.Uart, SimpleUart -> RISCV/params/SimpleUart.hh
> [   SHCXX] RISCV/python/_m5/param_SimpleUart.cc -> .os
> [SO Param] m5.objects.Uart, Uart8250 -> RISCV/python/_m5/param_Uart8250.cc
> [SO Param] m5.objects.Uart, Uart8250 -> RISCV/params/Uart8250.hh
> [   SHCXX] RISCV/python/_m5/param_Uart8250.cc -> .os
> [   SHCXX] src/dev/serial/serial.cc -> RISCV/dev/serial/serial.os
> [   SHCXX] src/dev/serial/simple.cc -> RISCV/dev/serial/simple.os
> [ TRACING]  -> RISCV/debug/Terminal.hh
> [ TRACING]  -> RISCV/debug/TerminalVerbose.hh
> [   SHCXX] src/dev/serial/terminal.cc -> RISCV/dev/serial/terminal.os
> [   SHCXX] src/dev/serial/uart.cc -> RISCV/dev/serial/uart.os
> [ TRACING]  -> RISCV/debug/Uart.hh
> [ TRACING]  -> RISCV/debug/Terminal.cc
> [   SHCXX] src/dev/serial/uart8250.cc -> RISCV/dev/serial/uart8250.os
> [   SHCXX] RISCV/debug/Terminal.cc -> .os
> [ TRACING]  -> RISCV/debug/TerminalVerbose.cc
> [   SHCXX] RISCV/debug/TerminalVerbose.cc -> .os
> [ TRACING]  -> RISCV/debug/Uart.cc
> [   SHCXX] RISCV/dev/i2c/I2C.py.cc -> .os
> [   SHCXX] RISCV/debug/Uart.cc -> .os
> [SO Param] m5.objects.I2C, I2CDevice -> RISCV/python/_m5/param_I2CDevice.cc
> [SO Param] m5.objects.I2C, I2CBus -> RISCV/python/_m5/param_I2CBus.cc
> [SO Param] m5.objects.I2C, I2CBus -> RISCV/params/I2CBus.hh
> [SO Param] m5.objects.I2C, I2CDevice -> RISCV/params/I2CDevice.hh
> [   SHCXX] RISCV/dev/pci/PciDevice.py.cc -> .os
> [SO Param] m5.objects.PciDevice, PciBar -> RISCV/python/_m5/param_PciBar.cc
> [SO Param] m5.objects.PciDevice, PciBarNone -> 
> RISCV/python/_m5/param_PciBarNone.cc
> [   SHCXX] RISCV/python/_m5/param_I2CBus.cc -> .os
> [   SHCXX] src/dev/i2c/bus.cc -> RISCV/dev/i2c/bus.os
> [   SHCXX] RISCV/python/_m5/param_PciBar.cc -> .os
> [   SHCXX] RISCV/python/_m5/param_PciBarNone.cc -> .os
> [   SHCXX] RISCV/python/_m5/param_I2CDevice.cc -> .os
> [SO Param] m5.objects.PciDevice, PciIoBar -> 
> RISCV/python/_m5/param_PciIoBar.cc
> [   SHCXX] RISCV/python/_m5/param_PciIoBar.cc -> .os
> [SO Param] m5.objects.PciDevice, PciLegacyIoBar -> 
> RISCV/python/_m5/param_PciLegacyIoBar.cc
> [   SHCXX] RISCV/python/_m5/param_PciLegacyIoBar.cc -> .os
> [SO Param] m5.objects.PciDevice, PciMemBar -> 
> RISCV/python/_m5/param_PciMemBar.cc
> [SO Param] 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #570

[Bobby Bruce via gem5-dev]

The two patches in this relation-chain should fix the compilation error: 
https://gem5-review.googlesource.com/c/public/gem5/+/69598

In short: the CPP Filesystem library needs a couple of work-arounds to compile 
successfully with GCC Versions 7 and 8.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Apr 10, 2023, at 11:53 AM, jenkins-no-reply--- via gem5-dev 
>  wrote:
> 
> See 
> 
> 
> Changes:
> 
> [gabe.black] base: Add support for unix domain sockets in ListenSocket.
> 
> 
> --
> [...truncated 1.03 KB...]
>> git checkout -f 7eff90acdcddb0288074815a3be689d2b111bf29 # timeout=10
> Commit message: "base: Add support for unix domain sockets in ListenSocket."
>> git rev-list --no-walk f15ddf82061ff2449f1f5eaedfa81f2f6d954753 # timeout=10
> [Checks API] No suitable checks publisher found.
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins7583387184887799746.sh
> + ./tests/compiler-tests.sh -j 16
> Starting build tests with 'gcc-version-12'...
> 'gcc-version-12' was found in the comprehensive tests. All ISAs will be built.
>  * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'MIPS.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'MIPS.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM_MESI_Three_Level_HTM.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'X86_MI_example.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'X86_MI_example.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'ALL.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'ALL.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'GCN3_X86.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'GCN3_X86.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'Garnet_standalone.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'Garnet_standalone.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'POWER.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'POWER.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'X86.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'X86.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'RISCV.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'RISCV.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL_MOESI_CMP_directory.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'SPARC.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'SPARC.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM.opt' with 'gcc-version-12'...
>Done.
>  * Building target 'ARM.fast' with 'gcc-version-12'...
>Done.
> Starting build tests with 'gcc-version-11'...
>  * Building target 'ARM.opt' with 'gcc-version-11'...
>Done.
>  * Building target 'ARM.fast' with 'gcc-version-11'...
>Done.
> Starting build tests with 'gcc-version-10'...
>  * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-10'...
>Done.
>  * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-10'...
>Done.
> Starting build tests with 'gcc-version-9'...
>  * Building target 'MIPS.opt' with 'gcc-version-9'...
>Done.
>  * Building target 'MIPS.fast' with 'gcc-version-9'...
>Done.
> Starting build tests with 'gcc-version-8'...
>  * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-8'...
>  ! Failed with exit code 2.
>  * Building target 'ARM_MESI_Three_Level_HTM.fast' with 'gcc-version-8'...
>  ! Failed with exit code 2.
> Starting build tests with 

[gem5-dev] Re: Build failed in Jenkins: nightly #566

[Bobby Bruce via gem5-dev]

I don’t know the exact cause of this problem but it’s a Docker failure of some 
kind and likely not due to any actual test failure. These just happen very so 
often on our Jenkin’s setup and they are impossible to recreate locally. It 
could be Docker running out of member (though it should have ample) or the 
service just being interrupted by something. I’ve never managed to figure out 
why or how to resolve it but they happen every so often. I suspect the Nightly 
tests will pass tonight.

I’m currently working on Migrating out tests to run via GitHub actions. I’m 
hoping this setup allows us to sidesteps all these funny little things that 
happen when running Docker in Jenkins.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Apr 5, 2023, at 7:55 AM, Matt Sinclair  
> wrote:
> 
> Hi Bobby,
> 
> I'm trying to interpret the console output here, as it seems like the 
> replacement policy tests are failing:
> 
> ...
> 03:41:45 Test: 
> test-replacement-policy-traces/tree_plru_test1_st-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>  Passed
> 04:02:55 time="2023-04-05T04:02:55-05:00" level=error msg="error waiting for 
> container: "
> 04:02:55 Build step 'Execute shell' marked build as failure
> ...
> 
> What does "Execute shell" refer to?  Is it just the next thing after the 
> replacement policy tests that is failing?
> 
> Thanks,
> Matt
> 
> On Wed, Apr 5, 2023 at 4:04 AM jenkins-no-reply--- via gem5-dev 
> mailto:gem5-dev@gem5.org>> wrote:
>> See 
>> 
>> Changes:
>> 
>> [humzajahangirikram] stdlib: Small fix in stdlib spec2006 script
>> 
>> [mattdsinclair] mem-ruby: fix whitespacing errors in RubySystem
>> 
>> [gabe.black] base: Abstract the AF_INET-ness out of ListenSocket.
>> 
>> 
>> --
>> [...truncated 2.46 MB...]
>> Test: 
>> test-replacement-policy-traces/lfu_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>>  Passed
>> Logging call to command: 
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d 
>> /tmp/gem5outxv9s3_65 -re --silent-redirect 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>>  traces/lfu_test2_ld 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lfu_test2_ld.py
>> Starting Test Suite: 
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example 
>> Starting Test Case: 
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example
>> Test: test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example 
>> Passed
>> Starting Test Case: 
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outxv9s3_65/simout 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/lfu_test2_ld
>> Test: 
>> test-replacement-policy-traces/lfu_test2_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>>  Passed
>> Logging call to command: 
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d 
>> /tmp/gem5out8el_uqrg -re --silent-redirect 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>>  traces/lfu_test3_ld 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lfu_test3_ld.py
>> Starting Test Suite: 
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example 
>> Starting Test Case: 
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example
>> Test: test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example 
>> Passed
>> Starting Test Case: 
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5out8el_uqrg/simout 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/ref/lfu_test3_ld
>> Test: 
>> test-replacement-policy-traces/lfu_test3_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>>  Passed
>> Logging call to command: 
>> /nobackup/jenkins/workspace/nightly/build/NULL_MI_example/gem5.opt -d 
>> /tmp/gem5outnoz1lhkk -re --silent-redirect 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/run_replacement_policy.py
>>  traces/lip_test1_ld 
>> /nobackup/jenkins/workspace/nightly/tests/gem5/replacement-policies/traces/lip_test1_ld.py
>> Starting Test Suite: 
>> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example 
>> Starting Test Case: 
>> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example
>> Test: test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example 
>> Passed
>> Starting Test Case: 
>> test-replacement-policy-traces/lip_test1_ld-NULL-x86_64-opt-MI_example-MatchStdoutNoPerf
>> Logging call to command: diff /tmp/gem5outnoz1lhkk/simout 
>> 

[gem5-dev] Re: Building on Apple Silicon / ARM docker

[Bobby Bruce via gem5-dev]

Also, I don’t fully understand the docker issues you are facing. Could you send 
us the actual docker commands you are running so I can try to reproduce the 
error? The images we provide should work (perhaps there is some incompatibility 
with running them on Mac, but if this is the case I’ve yet to be be made aware 
of it).

For #5, are you building and running in the same docker container?

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Apr 3, 2023, at 12:59 PM, Bobby Bruce  wrote:
> 
> Hey,
> 
> I believe I’ve run into this issue before on my Apple machine and have a 
> solution. I am running on the assumption here your Python installation is 
> 3.11. That’s the only reason I can see as to why you’d have this problem 
> (this email may be pretty pointless if this assumption isn’t true). In short: 
> Python 3.11 is incompatible with gem5 in a few ways in gem5 v22.1. Python 
> 3.11 just so happens to be the default installation via Homebrew for the 
> latest Mac hardware. So you should roll-back to an earlier version of Python 
> (Python 3.10 is known to work fine).
> 
> I’ve also found there’s a small bug if you try to compile anything needing 
> the SPARC ISA on Apple Silicon. If you want to do this, you’ll need to 
> incorporate this patch: 
> https://gem5-review.googlesource.com/c/public/gem5/+/68838.
> 
> 
> A more in-depth explanation (if anyone is interested):
> 
> There are three bugs in v22.1 which make it incompatible with Python 3.11. 
> Two are fixed but only exist on the develop branch. The other I’ve yet to 
> find a good solution to.
> 
> - Bug 1: ‘getargspec’ has been removed in Python 3.11. Fixed with: 
> https://gem5-review.googlesource.com/c/public/gem5/+/68817
> - Bug 2: gem5 v22.1 (and earlier) uses a version of Pybind which is 
> incompatible with Python 3.11. This can be fixed by updating “ext/pybind11” 
> to the latest Pybind11 version (Note: the error received with this bug is an 
> unhelpful “Can’t find a Working Python Installation” error, it took me a 
> while to diagnose). The specific patch that fixes this on our develop branch 
> is: https://gem5-review.googlesource.com/c/public/gem5/+/68818
> - Bug 3: This bug is explained, in detail, here 
> https://gem5.atlassian.net/browse/GEM5-1321. It relates to an incompatibility 
> with Ply (or, at least, how gem5 uses it) and Python 3.11’s stricter rules on 
> Regex Parsing. At present there is no fix for this bug.
> 
> Kind regards,
> Bobby
> 
> --
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>  
> web: https://www.bobbybruce.net
> 
>> On Apr 3, 2023, at 6:36 AM, chcarcher--- via gem5-dev  
>> wrote:
>> 
>> Dear all,
>> 
>> I am trying to build gem5 in an (arm) mac machine and I am encountering some 
>> problems. If anyone has managed to do so, I would be grateful if they could 
>> share some pointers.
>> 
>> Here are the various methods that I have tried so far:
>> 
>> Using the pre-built docker images (gcr.io/gem5-test/ubuntu*) I can 
>> successfully build and run gem5, but since the images are build for x86, 
>> recompilation takes really long time.
>> When trying to build natively on apple silicon, (python3 and python 
>> development headers/python3-config installed from brew), scons complains 
>> about not finding a working python installation. If could someone write 
>> where the log files of scons are, I might be able to dig deeper.
>> 
>> I have tried also re-building the docker images on mac (using the 
>> dockerfiles from repo) because this way the underline ubuntu image is an ARM 
>> one and emulation of x86 on docker won't be needed. Unfortunately:
>> On ubuntu 20 with gcc-10 and ubuntu 20 with all dependencies images, scons 
>> again reports not finding a working python installation
>> On ubuntu 22 with all dependencies, looks like there is an incompatibility 
>> among protobuf version and the version required by the headers, so 
>> compilation throws an error.
>> On ubuntu 20 with minimum dependencies image, gem builds successfully but 
>> throws an error on runtime since it tries to access the (dynamically linked? 
>> ) qemu-x86_64 (qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No 
>> such file or directory). Could this be recompiled from source too in order 
>> to be an arm executable, on par with the underlying arm ubuntu image?
>> I find the error where python is not found on the docker images really 
>> strange, since that should work out of the box due to docker. Am I missing 
>> something obvious here?
>> 
>> Again, if anyone has something to propose it would help a lot,
>> Regards.
>> 
>> 
>> 
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
> 

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to 

[gem5-dev] Re: Building on Apple Silicon / ARM docker

[Bobby Bruce via gem5-dev]

Hey,

I believe I’ve run into this issue before on my Apple machine and have a 
solution. I am running on the assumption here your Python installation is 3.11. 
That’s the only reason I can see as to why you’d have this problem (this email 
may be pretty pointless if this assumption isn’t true). In short: Python 3.11 
is incompatible with gem5 in a few ways in gem5 v22.1. Python 3.11 just so 
happens to be the default installation via Homebrew for the latest Mac 
hardware. So you should roll-back to an earlier version of Python (Python 3.10 
is known to work fine).

I’ve also found there’s a small bug if you try to compile anything needing the 
SPARC ISA on Apple Silicon. If you want to do this, you’ll need to incorporate 
this patch: https://gem5-review.googlesource.com/c/public/gem5/+/68838.


A more in-depth explanation (if anyone is interested):

There are three bugs in v22.1 which make it incompatible with Python 3.11. Two 
are fixed but only exist on the develop branch. The other I’ve yet to find a 
good solution to.

- Bug 1: ‘getargspec’ has been removed in Python 3.11. Fixed with: 
https://gem5-review.googlesource.com/c/public/gem5/+/68817
- Bug 2: gem5 v22.1 (and earlier) uses a version of Pybind which is 
incompatible with Python 3.11. This can be fixed by updating “ext/pybind11” to 
the latest Pybind11 version (Note: the error received with this bug is an 
unhelpful “Can’t find a Working Python Installation” error, it took me a while 
to diagnose). The specific patch that fixes this on our develop branch is: 
https://gem5-review.googlesource.com/c/public/gem5/+/68818
- Bug 3: This bug is explained, in detail, here 
https://gem5.atlassian.net/browse/GEM5-1321. It relates to an incompatibility 
with Ply (or, at least, how gem5 uses it) and Python 3.11’s stricter rules on 
Regex Parsing. At present there is no fix for this bug.

Kind regards,
Bobby

--
Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

> On Apr 3, 2023, at 6:36 AM, chcarcher--- via gem5-dev  
> wrote:
> 
> Dear all,
> 
> I am trying to build gem5 in an (arm) mac machine and I am encountering some 
> problems. If anyone has managed to do so, I would be grateful if they could 
> share some pointers.
> 
> Here are the various methods that I have tried so far:
> 
> Using the pre-built docker images (gcr.io/gem5-test/ubuntu*) I can 
> successfully build and run gem5, but since the images are build for x86, 
> recompilation takes really long time.
> When trying to build natively on apple silicon, (python3 and python 
> development headers/python3-config installed from brew), scons complains 
> about not finding a working python installation. If could someone write where 
> the log files of scons are, I might be able to dig deeper.
> 
> I have tried also re-building the docker images on mac (using the dockerfiles 
> from repo) because this way the underline ubuntu image is an ARM one and 
> emulation of x86 on docker won't be needed. Unfortunately:
> On ubuntu 20 with gcc-10 and ubuntu 20 with all dependencies images, scons 
> again reports not finding a working python installation
> On ubuntu 22 with all dependencies, looks like there is an incompatibility 
> among protobuf version and the version required by the headers, so 
> compilation throws an error.
> On ubuntu 20 with minimum dependencies image, gem builds successfully but 
> throws an error on runtime since it tries to access the (dynamically linked? 
> ) qemu-x86_64 (qemu-x86_64: Could not open '/lib64/ld-linux-x86-64.so.2': No 
> such file or directory). Could this be recompiled from source too in order to 
> be an arm executable, on par with the underlying arm ubuntu image?
> I find the error where python is not found on the docker images really 
> strange, since that should work out of the box due to docker. Am I missing 
> something obvious here?
> 
> Again, if anyone has something to propose it would help a lot,
> Regards.
> 
> 
> 
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Our use of Python Ply is incompatible with Python 11

[Bobby Bruce via gem5-dev]

Hey all,

In November 2022 Python 3.11 was release and is slowly being rolled out for 
usage. In January of this year I became aware of an issue which makes gem5 
incompatible with Python 3.11. I’ve outlined my findings, in detail, here: 
https://gem5.atlassian.net/browse/GEM5-1321.

In brief, Python 3.11 enforces a rule that Python Regex global flags must occur 
at the start of the regex expression which causes problems with Python Ply (our 
Python based lex and yacc tool, from here: https://github.com/dabeaz/ply). In 
gem5 we have code like this:

```
def t_STRLIT(self, t):
r'(?m)"([^"])*"'
# strip off quotes
t.value = t.value[1:-1]
t.lexer.lineno += t.value.count('\n')
return t
```

In Python Ply this regex is appended to the end of a regex expression and, 
therefore, the Python Regex global flag (`(?m)` in this case) is not at the 
start of the expression and the following error is returned:

```
ERROR:fm_proj_ply:/gem5/build/ALL/arch/arm/fastmodel/SConscript:220: Invalid 
regular expression for rule 't_STRLIT'. global flags not at the start of the 
expression at position 13
SyntaxError: Can't build lexer
```

I’ve tried hacking away at this but have yet to find a solution that works 
correctly (more details about this are outlined in the Jira ticket).

I’m reaching out to wonder if anyone has any nice solutions to this problem or, 
even better, if someone’s already found a work around on their end. This is a 
part of the code-base I don’t have much experience in and would appreciate some 
assistance if anyone has any ideas.
 

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616
 
web: https://www.bobbybruce.net

___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #509

[Bobby Bruce via gem5-dev]

Gabriel,

It looks like the nightly tests failed due to some of the ports not being
updated correctly. Do you have time to look into this and fix it?

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Feb 3, 2023 at 8:23 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/509/display/redirect?page=changes>
>
> Changes:
>
> [shunhsingou] dev: terminal: run pollevent in terminal eventq
>
> [gabriel.busnot] base: Strengthen safe_cast and make it work for reference
> types
>
> [gabriel.busnot] tests: Make the GTestException type accessible to unit
> tests
>
> [gabriel.busnot] mem: Deprecate RequestPort and ResponsePort owner ref
> member
>
> [gabriel.busnot] mem,arch-arm,mem-ruby,cpu: Remove use of deprecated base
> port owner
>
> [gabriel.busnot] sim: Suppress deleted operator= warn in
> Sys::Threads::const_it
>
> [gabriel.busnot] base: Enable non-copiable types in gem5_assert message
> formatting
>
> [gabriel.busnot] base: Turn all logging.hh macros into expression kind
>
> [gabe.black] arch-riscv: Get rid of redundant reset fault invocation.
>
> [gabe.black] arch: Add a virtual method to the BaseISA to reset its
> ThreadContext.
>
> [gabe.black] arch-riscv: Implement the resetThread method on the ISA
> object.
>
>
> --
> [...truncated 1.08 MB...]
>  [ TRACING]  -> VEGA_X86/debug/Ruby.cc
>  [ CXX] VEGA_X86/mem/ruby/common/Address.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/BoolVec.cc -> .o
>  [ TRACING]  -> VEGA_X86/debug/Ruby.hh
>  [ CXX] VEGA_X86/debug/Ruby.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/Consumer.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/DataBlock.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/Histogram.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/IntVec.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/NetDest.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/SubBlock.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/common/WriteMask.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/system/GPUCoalescer.py.cc -> .o
>  [SO Param] m5.objects.GPUCoalescer, RubyGPUCoalescer ->
> VEGA_X86/python/_m5/param_RubyGPUCoalescer.cc
>  [ CXX] VEGA_X86/mem/ruby/system/RubySystem.py.cc -> .o
>  [SO Param] m5.objects.RubySystem, RubySystem ->
> VEGA_X86/python/_m5/param_RubySystem.cc
>  [ CXX] VEGA_X86/mem/ruby/system/Sequencer.py.cc -> .o
>  [SO Param] m5.objects.GPUCoalescer, RubyGPUCoalescer ->
> VEGA_X86/params/RubyGPUCoalescer.hh
>  [MAKE INC] VEGA_X86/mem/ruby/slicc_interface/Message.hh ->
> protocol/Message.hh
>  [MAKE INC] VEGA_X86/mem/ruby/slicc_interface/RubyRequest.hh ->
> protocol/RubyRequest.hh
>  [SO Param] m5.objects.RubyCache, RubyCache -> VEGA_X86/params/RubyCache.hh
>  [ CXX] VEGA_X86/python/_m5/param_RubySystem.cc -> .o
>  [SO Param] m5.objects.Sequencer, RubySequencer ->
> VEGA_X86/params/RubySequencer.hh
>  [SO Param] m5.objects.DirectoryMemory, RubyDirectoryMemory ->
> VEGA_X86/params/RubyDirectoryMemory.hh
>  [SO Param] m5.objects.Sequencer, RubyPort ->
> VEGA_X86/python/_m5/param_RubyPort.cc
>  [SO Param] m5.objects.Sequencer, RubyPortProxy ->
> VEGA_X86/python/_m5/param_RubyPortProxy.cc
>  [SO Param] m5.objects.Sequencer, RubySequencer ->
> VEGA_X86/python/_m5/param_RubySequencer.cc
>  [SO Param] m5.objects.Sequencer, RubyHTMSequencer ->
> VEGA_X86/python/_m5/param_RubyHTMSequencer.cc
>  [SO Param] m5.objects.Sequencer, DMASequencer ->
> VEGA_X86/python/_m5/param_DMASequencer.cc
>  [ CXX] VEGA_X86/mem/ruby/system/VIPERCoalescer.py.cc -> .o
>  [ CXX] VEGA_X86/python/_m5/param_RubyGPUCoalescer.cc -> .o
>  [SO Param] m5.objects.VIPERCoalescer, VIPERCoalescer ->
> VEGA_X86/python/_m5/param_VIPERCoalescer.cc
>  [ CXX] VEGA_X86/python/_m5/param_RubyPort.cc -> .o
>  [ CXX] VEGA_X86/python/_m5/param_RubySequencer.cc -> .o
>  [SO Param] m5.objects.Sequencer, RubyHTMSequencer ->
> VEGA_X86/params/RubyHTMSequencer.hh
>  [SO Param] m5.objects.Sequencer, RubyPortProxy ->
> VEGA_X86/params/RubyPortProxy.hh
>  [SO Param] m5.objects.Sequencer, DMASequencer ->
> VEGA_X86/params/DMASequencer.hh
>  [SO Param] m5.objects.VIPERCoalescer, VIPERCoalescer ->
> VEGA_X86/params/VIPERCoalescer.hh
>  [ CXX] VEGA_X86/mem/ruby/system/CacheRecorder.cc -> .o
>  [MAKE INC] VEGA_X86/mem/ruby/common/DataBlock.hh -> protocol/DataBlock.hh
>  [MAKE INC] VEGA_X86/mem/ruby/common/WriteMask.hh -> protocol/WriteMask.hh
>  [ CXX] VEGA_X86/mem/ruby/system/GPUCoalescer.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/system/RubyPort.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/system/HTMSequencer.cc -> .o
>  [ CXX] VEGA_X86/python/_m5/param_RubyPortProxy.cc -> .o
>  [ CXX] VEGA_X86/python/_m5/param_RubyHTMSequencer.cc -> .o
>  [ CXX] VEGA_X86/mem/ruby/system/DMASequencer.cc -> .o
>  [ CXX] VEGA_X86/python/_m5/param_DMASequencer.cc -> .o
>  [ CXX] VEGA_X86/python/_m5/param_VIPERCoalescer.cc -> .o
>  

[gem5-dev] Re: Build failed in Jenkins: nightly #482

[Bobby Bruce via gem5-dev]

Sorry for the delay. Yesterday I cleared up some space on the server. We
shouldn't see space issue again.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Jan 12, 2023 at 7:04 PM Matt Sinclair 
wrote:

> Hi Bobby,
>
> Just checking on this again.
>
> Thanks,
> Matt
>
> On Mon, Jan 9, 2023 at 11:21 PM Matt Sinclair <
> mattdsinclair.w...@gmail.com> wrote:
>
>> Bobby do you need me to clean up the machine or open a ticket with IT at
>> UW:
>>
>> *19:22:13* {standard input}: Fatal error: can't write 97 bytes to section 
>> .text of build/ARM/python/_m5/param_TickedObject.o: 'No space left on device'
>>
>> Matt
>>
>> On Mon, Jan 9, 2023 at 7:23 PM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/nightly/482/display/redirect?page=changes>
>>>
>>> Changes:
>>>
>>> [mattdsinclair] mem-ruby, gpu-compute: fix TCP GLC cache bypassing
>>>
>>> [mattdsinclair] mem-ruby: fix TCP spacing/spelling
>>>
>>> [mattdsinclair] mem-ruby: add GPU cache bypass I->I transition
>>>
>>>
>>> --
>>> [...truncated 4.09 MB...]
>>>  [SO Param] m5.objects.Cache_Controller, Cache_Controller ->
>>> ARM/python/_m5/param_Cache_Controller.cc
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_DirEntry.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_Event.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_ReplacementMsg.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_RequestType.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_RetryQueueEntry.cc -> .o
>>>  [ CXX] ARM/python/_m5/param_Cache_Controller.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_RetryTriggerMsg.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_State.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_TBE.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_Transitions.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_TriggerMsg.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Cache_Wakeup.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/DMASequencerRequestType.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/DirectoryRequestType.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/HtmCallbackMode.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/HtmFailedInCacheReason.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/InvalidateGeneratorStatus.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/LinkDirection.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/LockStatus.cc -> .o
>>>  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
>>> ARM/params/Memory_Controller.hh
>>>  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
>>> ARM/params/MiscNode_Controller.hh
>>>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorIndex.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorTraining.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MaskPredictorType.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MemoryControlRequestType.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MemoryMsg.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MemoryRequestType.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MachineType.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_Controller.py.cc -> .o
>>>  [SO Param] m5.objects.Memory_Controller, Memory_Controller ->
>>> ARM/python/_m5/param_Memory_Controller.cc
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_Event.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_RetryQueueEntry.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_State.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_TBE.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_Transitions.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_TriggerMsg.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/Memory_Wakeup.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MessageSizeType.cc -> .o
>>>  [ CXX] ARM/python/_m5/param_Memory_Controller.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Controller.py.cc -> .o
>>>  [SO Param] m5.objects.MiscNode_Controller, MiscNode_Controller ->
>>> ARM/python/_m5/param_MiscNode_Controller.cc
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Event.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryQueueEntry.cc -> .o
>>>  [ CXX] ARM/python/_m5/param_MiscNode_Controller.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_RetryTriggerMsg.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_State.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_TBE.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Transitions.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_TriggerMsg.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/MiscNode_Wakeup.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/PrefetchBit.cc -> .o
>>>  [ CXX] ARM/mem/ruby/protocol/RequestStatus.cc -> .o
>>>  [ CXX] 

[gem5-dev] Re: Build failed in Jenkins: weekly #99

[Bobby Bruce via gem5-dev]

Thanks Matt!

I've restarted the Weeklys to ensure it's now working. Should be complete
over the next day or two.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Sun, Jan 8, 2023 at 12:48 AM Matt Sinclair via gem5-dev <
gem5-dev@gem5.org> wrote:

> The chain for the fixes for weekly is here:
> https://gem5-review.googlesource.com/c/public/gem5/+/67199/1
>
> I have tested that BC gets past the current failure with these 3 fixes
> (previously BC failed in an initialization kernel before the first
> iteration started, so far with the change it completes the first 107/128
> iterations ... hopefully the last few go smoothly as well).  Obviously I
> have not tested the entire weekly script yet though since that takes
> multiple days.  I will run that in parallel with these being reviewed.
>
> Matt
>
> On Sat, Jan 7, 2023 at 4:12 PM Jason Lowe-Power 
> wrote:
>
>> Thanks for quickly digging into this, Matt!
>>
>> On Sat, Jan 7, 2023 at 1:41 PM Matt Sinclair via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> I have confirmed that the Pannotia benchmarks (to my surprise) are using
>>> AMD's cache bypassing flags for some memory accesses, which Vishnu added
>>> support for this week.  Good thing the support is added now!  But that is
>>> why they are failing here -- they hit a corner case Vishnu and I had
>>> considered, but implemented incorrectly.  I have a fix I am testing now and
>>> will push later tonight assuming it solves the problem.
>>>
>>> Matt
>>>
>>> On Fri, Jan 6, 2023 at 10:07 PM Matt Sinclair <
>>> mattdsinclair.w...@gmail.com> wrote:
>>>
 Hi Matt P & Vishnu,

 It appears something with the GPU support must have broken between your
 changes this week -- as far as I can tell all of the nightly tests passed
 when you checked in your commits, but something in the more complex
 benchmarks (BC in this case) is breaking:

 gem5.opt: build/GCN3_X86/mem/ruby/system/VIPERCoalescer.cc:265: void 
 gem5::ruby::VIPERCoalescer::invTCPCallback(gem5::Addr): Assertion 
 `m_cache_inv_pkt && m_num_pending_invs > 0' failed.

 Vishnu, did you test your changes with the weekly tests at all?

 Matt P did you test your changes with the weekly tests at all?  And
 have you started bisecting yet to find the offending commit?

 If not, Vishnu I can show you how to do this.  I will be away next week
 (although with intermittent email access) so a fix relying on me may be
 delayed ... but hopefully between the three of us we can isolate and figure
 out which commit is causing/fixing.  My intuition says that it's probably
 one of Vishnu's commits, since Matt P's aren't changing the coherence
 protocol at all, but it's not obvious why Vishnu's commits would be
 affecting the invalidation calls at all ...

 Thanks,
 Matt S.

 On Fri, Jan 6, 2023 at 9:54 PM jenkins-no-reply--- via gem5-dev <
 gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/weekly/99/display/redirect?page=changes>
>
> Changes:
>
> [Bobby R. Bruce] ext: Fix SST Documentation links
>
> [Bobby R. Bruce] tests: Fix the download test
>
> [Bobby R. Bruce] stdlib: Removing incorrect requires.
>
> [Bobby R. Bruce] stdlib: se_binary_workload exits on work items by
> default
>
> [Bobby R. Bruce] configs: Fix unconnected PCI port in SST gem5 config
>
> [Bobby R. Bruce] mem: Add getAddrRanges in HBMCtrl
>
> [Bobby R. Bruce] system-arm: Fix FEAT_PAuth trapping in AArch64
> bootloader
>
> [Bobby R. Bruce] misc: Update version info to v22.0.0.2
>
> [Bobby R. Bruce] misc: Update RELEASE-NOTES.md for v22.0.0.2
>
> [Bobby R. Bruce] stdlib: Fix get_isa_from_str() exception behavior in
> isas.py
>
> [Bobby R. Bruce] dev-amdgpu: Handle ring buffer wrap for PM4 queue
>
> [Bobby R. Bruce] arch-vega: Fix SOPK instruction sign extends
>
> [Bobby R. Bruce] dev-amdgpu: Fix SDMA ring buffer wrap around
>
> [Bobby R. Bruce] arch-x86: X86ISA default vector_string to HygonGenuine
>
> [Bobby R. Bruce] arch-arm: Revert 'Setup TC/ISA at construction time..'
>
> [Bobby R. Bruce] stdlib,configs: Update riscvmatched-fs example
> docstring
>
> [Bobby R. Bruce] configs,stdlib: Fix import in riscvmatched-fs.py
>
> [Bobby R. Bruce] configs,stdlib,tests: Update riscvmatched-fs.py
> to-init
>
> [Bobby R. Bruce] tests: Update riscvmatched tests to use ALL/gem5.opt
>
> [Bobby R. Bruce] configs: Add missing `_pre_instantiate` call in
> "run_lupv.py"
>
> [Bobby R. Bruce] tests: Delete build directory before running KVM in
> nightly
>
> [Bobby R. Bruce] configs: Set CPU vendor to M5 Simulator in apu_se.py
>
> [Bobby R. Bruce] stdlib,python: Allow setting of to tick exits via m5
>
> 

[gem5-dev] v22.1 staging branch ready. RELEASE_NOTES.md requiring feedback

[Bobby Bruce via gem5-dev]

Dear all,

After rigorous testing, we've decided the v22.1 staging branch is of a good
enough state to be merged into the stable branch (The staging branch can be
obtained with `git clone -b release-staging-v22-1
https://gem5.googlesource.com/public/gem5`).

The only outstanding task is to update the RELEASE_NOTES.md. I've written a
first draft here: https://gem5-review.googlesource.com/c/public/gem5/+/66391.
I went through the `git log` and noted features/fixes/etc. which I thought
were noteworthy.

I'd appreciate it if those with an interest could go through this draft
 and ensure it highlights the key contributions of this release and that
they explained to the developers satisfaction. I hope I've done so in this
first draft, but there's still time to improve.

I'd like to get this incorporated into the release-staging branch by Friday
so I can release v22.1 before the new year.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #457

[Bobby Bruce via gem5-dev]

This one is my fault. This should fix the problem:
https://gem5-review.googlesource.com/c/public/gem5/+/66772

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Sat, Dec 17, 2022 at 4:53 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/457/display/redirect?page=changes
> >
>
> Changes:
>
> [gabe.black] dev: Introduce a reset() method on RegisterBank and Register
> classes.
>
> [gabe.black] dev: Implement a "Signal" port which has a templated State
> type.
>
> [gabe.black] fastmodel,dev: Rework the Int*Pin classes with Signal*Port.
>
> [gabe.black] fastmodel: Change the Signal proxies to use Signal*Port.
>
> [gabe.black] fastmodel,dev: Replace the reset port with a
> Signal*Port.
>
> [matthew.poremba] gpu-compute: Fix ABI init for DispatchId
>
>
> --
> [...truncated 1.03 KB...]
>  > git checkout -f af2cecf59e9cffbbc96bb88b9137da8ef6c74410 # timeout=10
> Commit message: "gpu-compute: Fix ABI init for DispatchId"
>  > git rev-list --no-walk f96513fd042c3a1843eb4a3131d08b0fe0aa947f #
> timeout=10
> [Checks API] No suitable checks publisher found.
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins10486267684618008562.sh
> + ./tests/compiler-tests.sh -j 16
> Starting build tests with 'gcc-version-12'...
> 'gcc-version-12' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'ARM.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86_MI_example.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86_MI_example.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'RISCV.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'RISCV.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'GCN3_X86.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'GCN3_X86.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'Garnet_standalone.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'Garnet_standalone.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'POWER.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'POWER.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ALL.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ALL.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'SPARC.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'SPARC.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'MIPS.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'MIPS.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_directory.fast' with
> 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
> 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 

[gem5-dev] Re: Build failed in Jenkins: nightly #446

[Bobby Bruce via gem5-dev]

I believe this patch should fix the nightly build:
https://gem5-review.googlesource.com/c/public/gem5/+/66512

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Sun, Dec 4, 2022 at 11:02 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> [...truncated 2.96 MB...]
>  [SHCC] X86_MI_example/ext/softfloat/f128_mul.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_rem.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_roundToInt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_sqrt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_sub.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_f16.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_f32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_f64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_i32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_i32_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_i64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_i64_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_ui32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_ui32_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_ui64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f128_to_ui64_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_add.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_classify.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_div.c -> .os
>  [  AR]  -> X86_MI_example/ext/drampower/libdrampower.a
>  [SHCC] X86_MI_example/ext/softfloat/f16_eq.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_eq_signaling.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_isSignalingNaN.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_le.c -> .os
>  [  RANLIB]  -> X86_MI_example/ext/drampower/libdrampower.a
>  [SHCC] X86_MI_example/ext/softfloat/f16_le_quiet.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_lt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_lt_quiet.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_mulAdd.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_mul.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_rem.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_roundToInt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_sqrt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_sub.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_f128.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_f32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_f64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_i32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_i32_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_i64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_i64_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_ui32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_ui32_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_ui64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f16_to_ui64_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_add.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_classify.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_div.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_eq.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_eq_signaling.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_isSignalingNaN.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_le.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_le_quiet.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_lt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_lt_quiet.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_mulAdd.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_mul.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_rem.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_roundToInt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_sqrt.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_sub.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_f128.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_f16.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_f64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_i32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_i32_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_i64.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_i64_r_minMag.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_ui32.c -> .os
>  [SHCC] X86_MI_example/ext/softfloat/f32_to_ui32_r_minMag.c -> .os
>  [

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #435

[Bobby Bruce via gem5-dev]

I don't know exactly what  patch triggered this bug, but gcc-12 was failing
to compile gem5 due to a missing virtual destructor in GlobalSyncEvent.
This patch should fix the problem:
https://gem5-review.googlesource.com/c/public/gem5/+/66152

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Sun, Nov 27, 2022 at 7:46 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> [...truncated 1.03 KB...]
>  > git checkout -f 4054565b853cb8b22ce30b9e0bbed944060d313b # timeout=10
> Commit message: "tests: Delete build directory before running KVM in
> nightly"
>  > git rev-list --no-walk 4054565b853cb8b22ce30b9e0bbed944060d313b #
> timeout=10
> [Checks API] No suitable checks publisher found.
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins15475498827313669860.sh
> + ./tests/compiler-tests.sh -j 16
> Starting build tests with 'gcc-version-12'...
> 'gcc-version-12' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'SPARC.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'SPARC.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86_MI_example.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86_MI_example.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'RISCV.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'RISCV.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ALL.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ALL.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'POWER.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'POWER.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'MIPS.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'MIPS.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
> 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MOESI_CMP_directory.fast' with
> 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'ARM.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'X86.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'Garnet_standalone.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'Garnet_standalone.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'GCN3_X86.opt' with 'gcc-version-12'...
>   ! Failed with exit code 2.
>   * Building target 'GCN3_X86.fast' with 'gcc-version-12'...
>   ! Failed with exit code 2.
> Starting build tests with 'gcc-version-11'...
>   * Building target 'X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.fast' 

[gem5-dev] Re: Build failed in Jenkins: nightly #429

[Bobby Bruce via gem5-dev]

Fixed with: https://gem5-review.googlesource.com/c/public/gem5/+/65871

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Nov 21, 2022 at 12:31 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
>
> --
> [...truncated 316.94 KB...]
> Starting Test Case: realview64-o3-dual-ALL-x86_64-opt
> Starting Test Suite: realview-simple-timing-ALL-x86_64-opt
> Starting Test Case: realview-simple-timing-ALL-x86_64-opt
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> /tmp/gem5outiconp_ye -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/fs/linux/arm/run.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/configs/realview-switcheroo-o3.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/resources/arm
> /nobackup/jenkins/workspace/nightly
> Starting Test Suite: realview64-minor-dual-ALL-x86_64-opt
> Starting Test Case: realview64-minor-dual-ALL-x86_64-opt
> Starting Test Suite: realview-switcheroo-timing-ALL-x86_64-opt
> Starting Test Case: realview-switcheroo-timing-ALL-x86_64-opt
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> /tmp/gem5out369yutvn -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/fs/linux/arm/run.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/configs/realview64-o3.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/resources/arm
> /nobackup/jenkins/workspace/nightly
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> /tmp/gem5out8lw1cjbq -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/fs/linux/arm/run.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/configs/realview-minor.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/resources/arm
> /nobackup/jenkins/workspace/nightly
> Starting Test Suite: realview-simple-atomic-ALL-x86_64-opt
> Starting Test Case: realview-simple-atomic-ALL-x86_64-opt
> Starting Test Suite: realview-switcheroo-o3-ALL-x86_64-opt
> Starting Test Case: realview-switcheroo-o3-ALL-x86_64-opt
> Starting Test Suite: realview64-o3-ALL-x86_64-opt
> Starting Test Case: realview64-o3-ALL-x86_64-opt
> Starting Test Suite: realview-minor-ALL-x86_64-opt
> Starting Test Case: realview-minor-ALL-x86_64-opt
> Test: realview-switcheroo-timing-ALL-x86_64-opt Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> /tmp/gem5outvdx8_j48 -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/fs/linux/arm/run.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/configs/realview-o3.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/resources/arm
> /nobackup/jenkins/workspace/nightly
> Starting Test Suite: realview-o3-ALL-x86_64-opt
> Starting Test Case: realview-o3-ALL-x86_64-opt
> Test: realview-simple-atomic-ALL-x86_64-opt Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> /tmp/gem5outhviubk6h -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/fs/linux/arm/run.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/configs/realview-simple-atomic-checkpoint.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/resources/arm
> /nobackup/jenkins/workspace/nightly
> Starting Test Suite: realview-simple-atomic-checkpoint-ALL-x86_64-opt
> Starting Test Case: realview-simple-atomic-checkpoint-ALL-x86_64-opt
> Test: realview-simple-timing-ALL-x86_64-opt Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> /tmp/gem5outmx92hmoz -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/fs/linux/arm/run.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/configs/realview-switcheroo-atomic.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/resources/arm
> /nobackup/jenkins/workspace/nightly
> Starting Test Suite: realview-switcheroo-atomic-ALL-x86_64-opt
> Starting Test Case: realview-switcheroo-atomic-ALL-x86_64-opt
> Test: realview64-minor-dual-ALL-x86_64-opt Passed
> Starting Test Case: realview64-minor-dual-ALL-x86_64-opt-MatchFileRegex
> Test: realview64-minor-dual-ALL-x86_64-opt-MatchFileRegex Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> /tmp/gem5outznpo_zmz -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/fs/linux/arm/run.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/configs/realview64-switcheroo-o3.py
> /nobackup/jenkins/workspace/nightly/tests/gem5/resources/arm
> /nobackup/jenkins/workspace/nightly
> Starting Test Suite: realview64-switcheroo-o3-ALL-x86_64-opt
> Starting Test Case: realview64-switcheroo-o3-ALL-x86_64-opt
> Test: realview-switcheroo-atomic-ALL-x86_64-opt Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/ALL/gem5.opt -d
> 

[gem5-dev] Re: Build failed in Jenkins: nightly #413

[Bobby Bruce via gem5-dev]

I've submitted this change which reverts the changes:
https://gem5-review.googlesource.com/c/public/gem5/+/65732.

I don't consider this a proper solution and i'm only submitting it so I can
continue to run the nightly tests (hopefully they start to pass again...).
So, in short, feel free to revert these reverts at some point.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Nov 17, 2022 at 4:13 PM Bobby Bruce  wrote:

> Hey all,
>
> So this patch worked but we ran into another bug which also triggered a
> timeout. This time it's due to a stalling when running the realview tests.
> I'm unsure right now if this affects other tests, but at least the
> `SuiteUID:tests/gem5/fs/linux/arm/test.py:realview-switcheroo-noncaching-timing-ALL-x86_64-opt`
> test reaches a point and stalls. This can be reproduced locally with:
>
> ```
> ./build/ALL/gem5.opt tests/gem5/fs/linux/arm/run.py
> tests/gem5/configs/realview-switcheroo-noncaching-timing.py
> tests/gem5/resources/arm “$(pwd)”
> ```
>
> The test outputs the following then halts indefinitely:
>
> ```
> Global frequency set at 1 ticks per second
> build/ALL/base/vnc/vncserver.cc:163: warn: Sockets disabled, not accepting
> vnc client connections
> build/ALL/dev/serial/terminal.cc:170: warn: Sockets disabled, not
> accepting terminal connections
> build/ALL/base/remote_gdb.cc:416: warn: Sockets disabled, not accepting
> gdb connections
> build/ALL/dev/arm/energy_ctrl.cc:252: warn: Existing EnergyCtrl, but no
> enabled DVFSHandler found.
> build/ALL/dev/arm/gic_v3_distributor.cc:884: warn:
> Gicv3Distributor::write(): setting ARE_NS to 0 is not supported!
> build/ALL/dev/arm/gic_v3_distributor.cc:889: warn:
> Gicv3Distributor::write(): setting ARE_S to 0 is not supported!
> build/ALL/dev/arm/rv_ctrl.cc:176: warn: SCReg: Access to unknown device
> dcc0:site0:pos0:fn7:dev0
> build/ALL/sim/power_state.cc:105: warn: PowerState: Already in the
> requested power state, request ignored
> build/ALL/dev/arm/gic_v3_distributor.cc:913: warn:
> Gicv3Distributor::write(): setting ARE_NS to 0 is not supported!
> ```
>
> I did a bisect and found the commit that breaks this test:
> https://gem5-review.googlesource.com/c/public/gem5/+/65291.
>
> If you revert this, with the following:
>
> ```
> git revert dd2f1fb2f8520849f10fc25fc5eab5beaa90a7d4 #
> https://gem5-review.googlesource.com/c/public/gem5/+/65174/7
>
> git revert 47bd56ee71ba1d684138365e7123aa779989ba1d #
> https://gem5-review.googlesource.com/c/public/gem5/+/65291
> ```
>
> the test passes again.
>
> @Giacomo : Do you have any good solutions for this bug? Above is pretty
> much all the information I have regarding this failure.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Tue, Nov 15, 2022 at 7:25 AM Jason Lowe-Power 
> wrote:
> >
> > Hi Matt,
> >
> > That might work for KVM, but it doesn't work for the timing CPUs as far
> as I know. The problem we ran into was not with KVM but with the timing
> CPUs.
> >
> > The underlying problem is that we are not modeling the system correctly.
> Either there's something wrong with our cpuid instruction (it's definitely
> not a "valid" result! but I'm not sure if it's the main problem here), or
> there's something wrong with our APIC implementation. Almost certainly both
> are true, but I don't know which one is the main culprit here.
> >
> > Cheers,
> > Jason
> >
> > On Mon, Nov 14, 2022 at 5:05 PM Poremba, Matthew via gem5-dev <
> gem5-dev@gem5.org> wrote:
> >>
> >> [AMD Official Use Only - General]
> >>
> >>
> >> Hi Bobby,
> >>
> >>
> >>
> >>
> >>
> >> I have seen this issue with do_boot_cpu as well. The short story is I
> had to use multiple event queues and set the “sim_quantum” of the Root
> object to 1e8:  https://gem5-review.googlesource.com/c/public/gem5/+/65131.
>   Note that 1e8 is different from the 1e9 value used elsewhere in gem5.
> Based on a test of doing 100 boots with 4 CPUs, 1e8 booted all four CPUs
> every time and 1e9 booted all four CPUs only twice.
> >>
> >>
> >>
> >>
> >>
> >> -Matt
> >>
> >>
> >>
> >> From: Bobby Bruce via gem5-dev 
> >> Sent: Monday, November 14, 2022 10:37 AM
> >> To: gem5-dev@gem5.org
> >> Cc: Bobby Bruce 
> >> Subject: [gem5-dev] Re: Build failed in Jenkins: nightly #413
> >>
>

[gem5-dev] Re: Build failed in Jenkins: nightly #413

[Bobby Bruce via gem5-dev]

Hey all,

So this patch worked but we ran into another bug which also triggered a
timeout. This time it's due to a stalling when running the realview tests.
I'm unsure right now if this affects other tests, but at least the
`SuiteUID:tests/gem5/fs/linux/arm/test.py:realview-switcheroo-noncaching-timing-ALL-x86_64-opt`
test reaches a point and stalls. This can be reproduced locally with:

```
./build/ALL/gem5.opt tests/gem5/fs/linux/arm/run.py
tests/gem5/configs/realview-switcheroo-noncaching-timing.py
tests/gem5/resources/arm “$(pwd)”
```

The test outputs the following then halts indefinitely:

```
Global frequency set at 1 ticks per second
build/ALL/base/vnc/vncserver.cc:163: warn: Sockets disabled, not accepting
vnc client connections
build/ALL/dev/serial/terminal.cc:170: warn: Sockets disabled, not accepting
terminal connections
build/ALL/base/remote_gdb.cc:416: warn: Sockets disabled, not accepting gdb
connections
build/ALL/dev/arm/energy_ctrl.cc:252: warn: Existing EnergyCtrl, but no
enabled DVFSHandler found.
build/ALL/dev/arm/gic_v3_distributor.cc:884: warn:
Gicv3Distributor::write(): setting ARE_NS to 0 is not supported!
build/ALL/dev/arm/gic_v3_distributor.cc:889: warn:
Gicv3Distributor::write(): setting ARE_S to 0 is not supported!
build/ALL/dev/arm/rv_ctrl.cc:176: warn: SCReg: Access to unknown device
dcc0:site0:pos0:fn7:dev0
build/ALL/sim/power_state.cc:105: warn: PowerState: Already in the
requested power state, request ignored
build/ALL/dev/arm/gic_v3_distributor.cc:913: warn:
Gicv3Distributor::write(): setting ARE_NS to 0 is not supported!
```

I did a bisect and found the commit that breaks this test:
https://gem5-review.googlesource.com/c/public/gem5/+/65291.

If you revert this, with the following:

```
git revert dd2f1fb2f8520849f10fc25fc5eab5beaa90a7d4 #
https://gem5-review.googlesource.com/c/public/gem5/+/65174/7

git revert 47bd56ee71ba1d684138365e7123aa779989ba1d #
https://gem5-review.googlesource.com/c/public/gem5/+/65291
```

the test passes again.

@Giacomo : Do you have any good solutions for this bug? Above is pretty
much all the information I have regarding this failure.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Nov 15, 2022 at 7:25 AM Jason Lowe-Power 
wrote:
>
> Hi Matt,
>
> That might work for KVM, but it doesn't work for the timing CPUs as far
as I know. The problem we ran into was not with KVM but with the timing
CPUs.
>
> The underlying problem is that we are not modeling the system correctly.
Either there's something wrong with our cpuid instruction (it's definitely
not a "valid" result! but I'm not sure if it's the main problem here), or
there's something wrong with our APIC implementation. Almost certainly both
are true, but I don't know which one is the main culprit here.
>
> Cheers,
> Jason
>
> On Mon, Nov 14, 2022 at 5:05 PM Poremba, Matthew via gem5-dev <
gem5-dev@gem5.org> wrote:
>>
>> [AMD Official Use Only - General]
>>
>>
>> Hi Bobby,
>>
>>
>>
>>
>>
>> I have seen this issue with do_boot_cpu as well. The short story is I
had to use multiple event queues and set the “sim_quantum” of the Root
object to 1e8:  https://gem5-review.googlesource.com/c/public/gem5/+/65131.
  Note that 1e8 is different from the 1e9 value used elsewhere in gem5.
Based on a test of doing 100 boots with 4 CPUs, 1e8 booted all four CPUs
every time and 1e9 booted all four CPUs only twice.
>>
>>
>>
>>
>>
>> -Matt
>>
>>
>>
>> From: Bobby Bruce via gem5-dev 
>> Sent: Monday, November 14, 2022 10:37 AM
>> To: gem5-dev@gem5.org
>> Cc: Bobby Bruce 
>> Subject: [gem5-dev] Re: Build failed in Jenkins: nightly #413
>>
>>
>>
>> Caution: This message originated from an External Source. Use proper
caution when opening attachments, clicking links, or responding.
>>
>>
>>
>> Hey all,
>>
>>
>>
>> I've submitted the following patch to Gerrit which should fix the
timeout issues we're seeing with the Jenkin's nightly build:
https://gem5-review.googlesource.com/c/public/gem5/+/65492.
>>
>>
>>
>> The high level summary of the problem is as follows:
>>
>>
>>
>> - Up until recently we were using "m5 Simulator" as the "vendor_string"
for each CPU in a gem5 simulation by default.
>>
>> - The latest versions of GLIB are now much stricter in checking system
capabilities. It does not recognize "m5 Simulator" as a legitimate vendor
and this causes problems. We became aware of this when trying to run SE
workloads in Ubuntu 22.04 or running FS Ubuntu 22.04 workloads.
>>
>> - Jason changed the default vendor string to "AuthenticAMD" via thi

[gem5-dev] Re: Build failed in Jenkins: nightly #413

[Bobby Bruce via gem5-dev]

Hey all,

I've submitted the following patch to Gerrit which should fix the timeout
issues we're seeing with the Jenkin's nightly build:
https://gem5-review.googlesource.com/c/public/gem5/+/65492.

The high level summary of the problem is as follows:

- Up until recently we were using "m5 Simulator" as the "vendor_string" for
each CPU in a gem5 simulation by default.
- The latest versions of GLIB are now much stricter in checking system
capabilities. It does not recognize "m5 Simulator" as a legitimate vendor
and this causes problems. We became aware of this when trying to run SE
workloads in Ubuntu 22.04 or running FS Ubuntu 22.04 workloads.
- Jason changed the default vendor string to "AuthenticAMD" via this
commit: https://gem5-review.googlesource.com/c/public/gem5/+/64831. This
fixed the above problems but due to a bug, highlighted here:
https://gem5.atlassian.net/browse/GEM5-1300, Linux boots were taking an
extremely long time. This caused our Nightly tests to reach timeout.
- Our solution is to change the default vector string "HygonGenuine". This
fixes all of the problems (GLIB problems and long boot times). However,
we'd prefer to use "AuthenticAMD" over "HygonGenuine" so would appreciate
it someone could find the time to look into the bug in GEM5-1300.

Thanks to everyone for your patience here. I know you've all been spammed
with failing Nightly errors for some time now. Hopefully after this patch
is submitted we'll be back to everything passing.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Nov 9, 2022 at 2:33 PM Bobby Bruce  wrote:

> It turns out this patch:
> https://gem5-review.googlesource.com/c/public/gem5/+/64831 is greatly
> increasing the Linux boot times and therefore causing the timeouts to
> occur. I'll try to find a solution for this. Unfortunately reverting the
> patch isn't an option, changing the CPUID is necessary to run SE mode on
> Ubuntu 22.04 and run Ubuntu 22.04 workloads in FS mode.
>
> We may have to scale back our tests a bit more and run fewer boot tests
> but I'll see if I can come up with some alternatives first.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Tue, Nov 8, 2022 at 11:03 PM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/413/display/redirect?page=changes>
>>
>> Changes:
>>
>> [hoanguyen] stdlib: Make the Matched board a package
>>
>>
>> --
>> [...truncated 1.93 MB...]
>>  [SHCC] NULL/ext/softfloat/f64_eq_signaling.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_isSignalingNaN.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_le.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_le_quiet.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_lt.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_lt_quiet.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_mulAdd.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_mul.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_rem.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_roundToInt.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_sqrt.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_sub.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_f128.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_f16.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_f32.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_i32.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_i32_r_minMag.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_i64.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_i64_r_minMag.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_ui32.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_ui32_r_minMag.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_ui64.c -> .os
>>  [SHCC] NULL/ext/softfloat/f64_to_ui64_r_minMag.c -> .os
>>  [SHCC] NULL/ext/softfloat/i32_to_f128.c -> .os
>>  [SHCC] NULL/ext/softfloat/i32_to_f16.c -> .os
>>  [SHCC] NULL/ext/softfloat/i32_to_f32.c -> .os
>>  [SHCC] NULL/ext/softfloat/i32_to_f64.c -> .os
>>  [SHCC] NULL/ext/softfloat/i64_to_f128.c -> .os
>>  [SHCC] NULL/ext/softfloat/i64_to_f16.c -> .os
>>  [SHCC] NULL/ext/softfloat/i64_to_f32.c -> .os
>>  [SHCC] NULL/ext/softfloat/i64_to_f64.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_add128.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_add256M.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_addCarryM.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_addComplCarryM.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_addMagsF128.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_addMagsF16.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_addMagsF32.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_addMagsF64.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_addM.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_approxRecip_1Ks.c -> .os
>>  [SHCC] NULL/ext/softfloat/s_approxRecip32_1.c -> .os
>>  [SHCC] 

[gem5-dev] Re: Build failed in Jenkins: nightly #413

[Bobby Bruce via gem5-dev]

It turns out this patch:
https://gem5-review.googlesource.com/c/public/gem5/+/64831 is greatly
increasing the Linux boot times and therefore causing the timeouts to
occur. I'll try to find a solution for this. Unfortunately reverting the
patch isn't an option, changing the CPUID is necessary to run SE mode on
Ubuntu 22.04 and run Ubuntu 22.04 workloads in FS mode.

We may have to scale back our tests a bit more and run fewer boot tests but
I'll see if I can come up with some alternatives first.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Nov 8, 2022 at 11:03 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/413/display/redirect?page=changes>
>
> Changes:
>
> [hoanguyen] stdlib: Make the Matched board a package
>
>
> --
> [...truncated 1.93 MB...]
>  [SHCC] NULL/ext/softfloat/f64_eq_signaling.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_isSignalingNaN.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_le.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_le_quiet.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_lt.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_lt_quiet.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_mulAdd.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_mul.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_rem.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_roundToInt.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_sqrt.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_sub.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_f128.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_f16.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_f32.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_i32.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_i32_r_minMag.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_i64.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_i64_r_minMag.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_ui32.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_ui32_r_minMag.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_ui64.c -> .os
>  [SHCC] NULL/ext/softfloat/f64_to_ui64_r_minMag.c -> .os
>  [SHCC] NULL/ext/softfloat/i32_to_f128.c -> .os
>  [SHCC] NULL/ext/softfloat/i32_to_f16.c -> .os
>  [SHCC] NULL/ext/softfloat/i32_to_f32.c -> .os
>  [SHCC] NULL/ext/softfloat/i32_to_f64.c -> .os
>  [SHCC] NULL/ext/softfloat/i64_to_f128.c -> .os
>  [SHCC] NULL/ext/softfloat/i64_to_f16.c -> .os
>  [SHCC] NULL/ext/softfloat/i64_to_f32.c -> .os
>  [SHCC] NULL/ext/softfloat/i64_to_f64.c -> .os
>  [SHCC] NULL/ext/softfloat/s_add128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_add256M.c -> .os
>  [SHCC] NULL/ext/softfloat/s_addCarryM.c -> .os
>  [SHCC] NULL/ext/softfloat/s_addComplCarryM.c -> .os
>  [SHCC] NULL/ext/softfloat/s_addMagsF128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_addMagsF16.c -> .os
>  [SHCC] NULL/ext/softfloat/s_addMagsF32.c -> .os
>  [SHCC] NULL/ext/softfloat/s_addMagsF64.c -> .os
>  [SHCC] NULL/ext/softfloat/s_addM.c -> .os
>  [SHCC] NULL/ext/softfloat/s_approxRecip_1Ks.c -> .os
>  [SHCC] NULL/ext/softfloat/s_approxRecip32_1.c -> .os
>  [SHCC] NULL/ext/softfloat/s_approxRecipSqrt_1Ks.c -> .os
>  [SHCC] NULL/ext/softfloat/s_approxRecipSqrt32_1.c -> .os
>  [SHCC] NULL/ext/softfloat/s_commonNaNToF128UI.c -> .os
>  [SHCC] NULL/ext/softfloat/s_commonNaNToF16UI.c -> .os
>  [SHCC] NULL/ext/softfloat/s_commonNaNToF32UI.c -> .os
>  [SHCC] NULL/ext/softfloat/s_commonNaNToF64UI.c -> .os
>  [SHCC] NULL/ext/softfloat/s_compare128M.c -> .os
>  [SHCC] NULL/ext/softfloat/s_compare96M.c -> .os
>  [SHCC] NULL/ext/softfloat/s_countLeadingZeros16.c -> .os
>  [SHCC] NULL/ext/softfloat/s_countLeadingZeros32.c -> .os
>  [SHCC] NULL/ext/softfloat/s_countLeadingZeros64.c -> .os
>  [SHCC] NULL/ext/softfloat/s_countLeadingZeros8.c -> .os
>  [SHCC] NULL/ext/softfloat/s_eq128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_f128UIToCommonNaN.c -> .os
>  [SHCC] NULL/ext/softfloat/s_f16UIToCommonNaN.c -> .os
>  [SHCC] NULL/ext/softfloat/s_f32UIToCommonNaN.c -> .os
>  [SHCC] NULL/ext/softfloat/s_f64UIToCommonNaN.c -> .os
>  [SHCC] NULL/ext/softfloat/s_le128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_lt128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mul128By32.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mul128MTo256M.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mul128To256M.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mul64ByShifted32To128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mul64To128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mul64To128M.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mulAddF128.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mulAddF16.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mulAddF32.c -> .os
>  [SHCC] NULL/ext/softfloat/s_mulAddF64.c -> .os
>  [SHCC] NULL/ext/softfloat/s_negXM.c -> .os
>  [SHCC] 

[gem5-dev] v22.1 Staging branch created

[Bobby Bruce via gem5-dev]

Dear all,

As of this afternoon, the gem5 v22.1 staging branch has been created. This
branch will be intensely tested over the next couple of weeks to ensure
it's ready to be merged into the stable branch.

If you have any bug fixes you can submit them to the develop branch then
cherry-pick the changes onto the staging branch to ensure they make it into
the v22.1 release.

More information on our release procedures can be found here:
https://www.gem5.org/documentation/general_docs/development/release_procedures/


Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] Re: Build failed in Jenkins: nightly #403

[Bobby Bruce via gem5-dev]

At least one problem here is the Nightly tests are failing due to it
reaching timeout. I've submitted some patches here to remove some of the
Boot tests (we have a lot of these, they take a while to run, and are
largely doing the same thing),  remove a couple of tests that require
compilation of SPARC, POWER, and MIPS (these tests were very small and I
didn't think they justify the additional compilation), and get rid of some
redundant compilations in the nightly.sh script :
https://gem5-review.googlesource.com/c/public/gem5/+/65175

As a general note, we should probably try to be more careful in how we
test. Particularly, we do full OS boots to test some rather minor features.
We should try to find ways to break these down into more unit-like tests.
Though that's probably on me :).

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Nov 1, 2022 at 1:11 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/403/display/redirect?page=changes>
>
> Changes:
>
> [matthew.poremba] arch-vega: Improve non-native page size support
>
> [matthew.poremba] dev-amdgpu: Chunkify SDMA copies that use device memory
>
> [matthew.poremba] dev-amdgpu: Fix GART PTE size
>
> [yuhsingw] mem: introduce bad command error to packet commands
>
> [yuhsingw] systemc: sync the response error between gem5 packet and tlm
> payload
>
>
> --
> [...truncated 1.29 MB...]
>  [ CXX] ALL_MSI/arch/power/insts/mem.cc -> .o
>  [ CXX] ALL_MSI/arch/power/insts/integer.cc -> .o
>  [ CXX] ALL_MSI/arch/power/insts/floating.cc -> .o
>  [ CXX] ALL_MSI/arch/power/insts/condition.cc -> .o
>  [ CXX] ALL_MSI/arch/power/insts/static_inst.cc -> .o
>  [ CXX] ALL_MSI/arch/power/linux/se_workload.cc -> .o
>  [ CXX] ALL_MSI/arch/power/isa.cc -> .o
>  [ CXX] ALL_MSI/arch/power/process.cc -> .o
>  [ CXX] ALL_MSI/arch/power/remote_gdb.cc -> .o
>  [ CXX] ALL_MSI/arch/power/se_workload.cc -> .o
>  [ CXX] ALL_MSI/arch/power/tlb.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_PowerISA.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_PowerSEWorkload.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_PowerEmuLinux.cc -> .o
>  [ CXX] ALL_MSI/arch/power/generated/decoder.cc -> .o
>  [ CXX] ALL_MSI/arch/power/generated/inst-constrs.cc -> .o
>  [ CXX] ALL_MSI/arch/power/generated/generic_cpu_exec.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/faults.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/isa.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/process.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/pagetable_walker.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/pma_checker.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/pmp.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/reg_abi.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/remote_gdb.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/tlb.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/linux/se_workload.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/linux/fs_workload.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/bare_metal/fs_workload.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_PMAChecker.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_PMP.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_RiscvInterrupts.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_RiscvISA.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_RiscvMMU.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_RiscvSEWorkload.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_RiscvEmuLinux.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_RiscvPagetableWalker.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_RiscvTLB.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/generated/decoder.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/generated/inst-constrs.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/generated/generic_cpu_exec.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/insts/amo.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/insts/compressed.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/insts/mem.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/insts/standard.cc -> .o
>  [ CXX] ALL_MSI/arch/riscv/insts/static_inst.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/faults.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/interrupts.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/isa.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/linux/se_workload.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/process.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/remote_gdb.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/se_workload.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/tlb.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/utility.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_MipsInterrupts.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_MipsISA.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_MipsSEWorkload.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_MipsEmuLinux.cc -> .o
>  [ CXX] ALL_MSI/python/_m5/param_MipsTLB.cc -> .o
>  [ CXX] ALL_MSI/arch/mips/generated/decoder.cc -> .o
>  [ CXX] 

[gem5-dev] Re: Build failed in Jenkins: weekly #46

[Bobby Bruce via gem5-dev]

This test actually failed with an error message:

```
FileExistsError: [Errno 17] File exists:
'/nobackup/jenkins/workspace/weekly/tests/gem5/resources'

At:
  /usr/lib/python3.8/os.py(228): makedirs
  build/GCN3_X86/python/gem5/resources/resource.py(156): __init__

/nobackup/jenkins/workspace/weekly/tests/gem5/configs/x86_boot_exit_run.py(192):

  build/GCN3_X86/python/m5/main.py(440): main
```

It seems like in cases where we have multiple gem5 threads running, there
can be a race condition in creating the resource directory if it does not
exist. I created a patch to fix this here:
https://gem5-review.googlesource.com/c/public/gem5/+/59090

I notice the
"timing-cpu_2-cores_mesi_two_level_DualChannelDDR4_2400_systemd_x86-boot-test-X86-x86_64-opt
"
test, which has been failing for a few weeks for no obvious reason, has
started working again. It could just be flakey. I'll try re-running the
weeklys when this fix is incorporated.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Apr 22, 2022 at 1:37 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
> [Bobby R. Bruce] tests: Fix 'valid_hosts' field for KVM tests
>
> [Bobby R. Bruce] stdlib: Update the stdlib resource's md5 utils
>
> [Bobby R. Bruce] util,stdlib: Add util/md5.py
>
> [Bobby R. Bruce] stdlib: Add tar unpacking to downloader
>
> [mytbk920423] util: fix the cxx_config example
>
> [ksungkeun84] mem-garnet: Packet Tracing of garnet network
>
> [zhongcy93] arch-riscv: RISCV call/ret instructions aren't decoded
> correctly
>
> [matthew.poremba] dev-amdgpu: Fix frame writes for <32-bit writes
>
> [Giacomo Travaglini] mem-ruby: Support for unaddressed mem requests in the
> Sequencer
>
>
> --
> [...truncated 536.48 KB...]
>  [SHCC] X86/ext/softfloat/s_normSubnormalF16Sig.c -> .os
>  [SHCC] X86/ext/softfloat/s_normSubnormalF32Sig.c -> .os
>  [SHCC] X86/ext/softfloat/s_normSubnormalF64Sig.c -> .os
>  [SHCC] X86/ext/softfloat/softfloat_raiseFlags.c -> .os
>  [SHCC] X86/ext/softfloat/softfloat_state.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF128UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF16UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF32UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_propagateNaNF64UI.c -> .os
>  [SHCC] X86/ext/softfloat/s_remStepMBy32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundMToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundMToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackMToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackMToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF128.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF16.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToF64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToUI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundPackToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToUI32.c -> .os
>  [SHCC] X86/ext/softfloat/s_roundToUI64.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam128Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam256M.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam32.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam64.c -> .os
>  [SHCC] X86/ext/softfloat/s_shiftRightJam64Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftLeft128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftLeft64To96M.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRight128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightExtendM.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam128Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam64.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightJam64Extra.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightM.c -> .os
>  [SHCC] X86/ext/softfloat/s_sub128.c -> .os
>  [SHCC] X86/ext/softfloat/s_sub1XM.c -> .os
>  [SHCC] X86/ext/softfloat/s_sub256M.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF128.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF16.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF32.c -> .os
>  [SHCC] X86/ext/softfloat/s_subMagsF64.c -> .os
>  [SHCC] X86/ext/softfloat/s_subM.c -> .os
>  [SHCC] X86/ext/softfloat/ui32_to_f128.c -> .os
>  [SHCC] X86/ext/softfloat/ui32_to_f16.c -> .os
>  [SHCC] X86/ext/softfloat/ui32_to_f32.c -> .os
>  [SHCC] 

[gem5-dev] Re: Upcoming gem5 events! Tutorial, Workshop, and Boot Camp!

[Bobby Bruce via gem5-dev]

Dear all,

This is a friendly reminder that the deadline for submitting a presentation
proposal to the gem5 users' workshop is April 26th. The presentation
proposal submission link is here: https://forms.gle/VZxXsWBniUPGBQdw5

The gem5 users' workshop will be co-located with ISCA '22 (New York City),
to be held on June 18th.

These presentations are an opportunity for users of gem5 to present
gem5-related work. Any work related to gem5 and/or is relevant to the gem5
community is within scope.

More info can be found on our event page: https://www.gem5.org/events
/isca-2022#the-4th-gem5-users-workshop

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Mar 29, 2022 at 6:30 PM Bobby Bruce  wrote:

> Dear all,
>
> We wish to make the computer architecture research community aware of
> several gem5 events occurring over the next 6 months. There will be two
> events co-located at ISCA 2022 (held in New York, June 18th) -- a 3 hour
> tutorial, and a 3 hour workshop. In July, there will be a "gem5 Boot Camp",
> 5 days, July 11 to July 15th, for junior computer architecture researchers
> to learn how to use gem5 in their projects.
>
> Specific event details are shown below. Please relay these details to
> anyone that may be interested.
>
> *ISCA 2022: The gem5 Tutorial*
>
> Date: June 18th 2022 (Morning session)
> Location: ISCA, New York City
> Webpage: https://www.gem5.org/events/isca-2022#the-4th-gem5-tutorial
> Registration: Please keep an eye on the ISCA website for registration
> information https://iscaconf.org/isca2022/
>
> The gem5 tutorial is designed to give computer architecture researchers a
> "crash course" in using gem5. No prior experience is required and the event
> is open to anyone wanting to attend.
>
> The tutorial will be carried out over the course of a 3 hour session with
> attendees working from their own laptops. A tentative schedule is shown
> here:
>
> - First hour: Getting started with gem5.
> This will cover the basics of building a simulation of gem5, from
> compilation to building full-system simulations using the gem5 standard
> library.
>
> - Second hour: Extending gem5
> This will cover how to create your own gem5 simobjects, add your own
> components to the library, and running simulations with the components you
> have created.
>
> - Third hour: Deeper topics
> The last hour will cover more advanced topics such as the gem5 memory
> system and ruby.
>
>
> *ISCA 2022: The gem5 Users' Workshop*
>
> Date: June 18th 2022 (Afternoon session)
> Location: ISCA, New York City
> Webpage: https://www.gem5.org/events/isca-2022#the-4th-gem5-users-workshop
> Registration: Please keep an eye on the ISCA website for registration
> information https://iscaconf.org/isca2022/
> Presentation proposal link: https://forms.gle/VZxXsWBniUPGBQdw5
> Presentation proposal deadline: April 26th (Notifications sent out by May
> 9th).
>
> The gem5 Users' Workshop will start with a 30 minute keynote presentation
> by Prof. Jason Lowe-Power titled "Recent Advancements in Mainline gem5
> v20.0 – v21.2". This will be followed by a series of 15 minutes
> presentations. These presentations are an opportunity for users of gem5 to
> present gem5-related work and foster discussion.
>
> Presentations are solicited on a broad range of topics related to gem5.
> Including, but not limited to:
>
> - New gem5 features and models.
> - Improved models.
> - Validation against real hardware.
> - Software Engineering related to gem5.
> - Experiences using gem5.
> - Tools, visualizations, data analysis tools, etc.
>
> If you wish to present at this year's gem5 Users' workshop, please provide
> a presentation proposal (a 1 page PDF) here:
> https://forms.gle/VZxXsWBniUPGBQdw5. The deadline for submitting a
> presentation proposal is April 26th with acceptance notifications sent out
> by May 9th.
>
> Note: this is an in-person event. Presenters must attend the workshop.
>
> *July 2022: The gem5 Boot Camp*
>
> Dates: July 11th to July 15th 2022
> Location: Davis, California
> Webpage: https://www.gem5.org/events/boot-camp-2022
> Application form: https://forms.gle/3wWPsMDfXyaChmQ68
> Application Deadline: May 18th (Notifications sent out by June 1st)
>
> The gem5 boot camp is for junior computer architecture researchers,
> particularly PhD. students, to learn how to use gem5 in their projects. The
> event will be held over 5 days and will take attendees through all aspects
> of using the gem5 simulation from setting up basic system simulations,
> creating components, learning to interpret gem5 stats, all the through to
> running and modifying simulations comparable to real world systems.
>
> This event is free for all accepted attendees. Registration, accommodation
> and meals will incur no cost. Travel grants will also be available.
>
> Those wishing to attend should register using the following form:
> https://forms.gle/AztSG3mD2BqQ4f967. The 

[gem5-dev] Re: gem5 v22.0 to be released in early May. Staging branch to be created by the end of April

[Bobby Bruce via gem5-dev]

Dear all,

We intend to create the staging branch on April 28th, with the intent of
releasing gem5 v22.0 in early May. This is a two week warning. Please
ensure all your patches you wish to be part of v22.0 are submitted to the
develop branch prior to April 28th.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Apr 4, 2022 at 10:28 AM Bobby Bruce  wrote:

> Dear all,
>
> In line with our policy of having three major releases a year, we're
> aiming to have v22.0 of gem5 released in early May.  This means we'll be
> creating a staging branch from the develop branch by the end of April. The
> staging branch will be intensely tested to ensure it is suitable for
> general community use before being merged into the stable branch.
>
> We understand there's a backlog of patches to be reviewed. We'll try to
> ensure everyone who puts in the effort to submit for this release, and
> responds promptly to feedback, makes it into the v22.0 release. If you feel
> your patches have been ignored, please ping us on the relevant Gerrit
> submission (if you have not already added reviewers, remember to add them).
> Help with reviewing over the next month would also be greatly appreciated.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #193

[Bobby Bruce via gem5-dev]

Hoa,

Looks like you broke the tests with this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/58790. You should've
removed the `root = Root(full_system=True, system=board)` line, this is set
when you execute simulator.run()

Can you push a quick fix (and run it to make sure it works)?

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Apr 14, 2022 at 6:24 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/193/display/redirect?page=changes>
>
> Changes:
>
> [Giacomo Travaglini] mem-ruby: CHI fix for WUs on local+upstream line
>
> [Bobby R. Bruce] tests: Disable failing MI_Example/Timing CPU X86 Boot
> Tests
>
> [Bobby R. Bruce] tests: Disable failing 8-core Boot Tests for Timing/Atomic
>
> [hoanguyen] stdlib, configs: Migrate riscv-ubuntu-run example to Simulator
>
> [Jason Lowe-Power] scons: Fix bug in error message
>
> [gabe.black] arch-x86: Override make(Read|Write) instead of
> (read|write)_code.
>
> [gabe.black] arch: Eliminate the now unused read_code and write_code args.
>
> [yuhsingw] scons: Fix script failed when default files not found
>
> [gabe.black] scons: Ensure the fast model license count is always at least
> 1.
>
> [yuhsingw] fastmodel: Export more CortexA76 reset pin
>
> [yuhsingw] fastmodel: Export more CortexR52 reset pin
>
> [joy] arch-riscv: Added the Zba and Zbb bitmanip instructions
>
> [joy] arch-riscv: Added the Zbc bitmanip instructions
>
> [joy] arch-riscv: Added the Zbs bitmanip instructions
>
>
> --
> [...truncated 1.74 MB...]
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5outissh55y8 -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> LinearGenerator 1 MESITwoLevel gem5.components.memory HBM2Stack 512MiB
> Starting Test Suite:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-HBM2Stack-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-HBM2Stack-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-HBM2Stack-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5outw4uy5g8f -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> RandomGenerator 1 MESITwoLevel gem5.components.memory
> SingleChannelDDR3_1600 512MiB
> Starting Test Suite:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5outhyxrz3n9 -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> RandomGenerator 1 MESITwoLevel gem5.components.memory
> SingleChannelDDR3_2133 512MiB
> Starting Test Suite:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5outd3eyei8w -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> RandomGenerator 1 MESITwoLevel gem5.components.memory
> SingleChannelDDR4_2400 512MiB
> Starting Test Suite:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
>
> Starting Test Case:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Test:
> test-memory-RandomGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
> Passed
> Logging call to command:
> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
> /tmp/gem5outm48qeir1 -re --silent-redirect
> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
> RandomGenerator 1 MESITwoLevel gem5.components.memory
> 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #189

[Bobby Bruce via gem5-dev]

I think we need to have a little discussion on this. The problem with
increasing the scons version is we support Ubuntu 18.04 (Official
end-of-support not until April 2023) which if you run `apt install scons`
will give you v3.0.1. So, increasing this the scons version requirements
will hurt these users.

I think our solutions here are either:

1) Drop support for Ubuntu 18.04 in the next release.
2) Have a work-around available for Ubuntu 18.04 users.
3) Maintain v3.01 as the minimum scons dependency and work around that.

Unfortunately, none of these are very appealing.

In the interests of not having the compiler tests fail for another night,
can we revert this commit until we figure out exactly what we want to do?

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Apr 5, 2022 at 1:34 PM Gabe Black  wrote:

> The bug in SCons was fixed in version 3.0.2. I have a CL which updates the
> required version here:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/58629
>
> I'm assuming some docker configuration something will need to be updated
> to use SCons version 3.0.2 instead of the 3.0.1 it seems to be using.
>
> Gabe
>
> On Tue, Apr 5, 2022 at 4:13 PM Gabe Black  wrote:
>
>> I think this is actually a bug in SCons. This docker image seems to be
>> using the minimum version of it we support, which I think is where the
>> problem is coming from and not the compiler versions. There is a
>> "fix"/workaround in this email thread which I haven't tried yet, and which
>> is a bit of a hack.
>>
>> https://pairlist2.pair.net/pipermail/scons-dev/2018-October/004766.html
>>
>> I'm not sure when this bug would have been fixed, or what the best way to
>> check if we need to monkey patch around it. If we can find the version of
>> SCons where it was fixed and it's not that much more recent, bumping up
>> past it may be the easiest.
>>
>> I think the reason this becomes visible with the change above is that
>> more SCons code is run unconditionally, and so the fast model code is now
>> being run in the test environment where it is disabled and just skipped
>> wholesale before.
>>
>> Gabe
>>
>> On Tue, Apr 5, 2022 at 3:06 AM Gabe Black  wrote:
>>
>>> Yes, I'll take a look.
>>>
>>> Gabe
>>>
>>> On Mon, Apr 4, 2022 at 3:02 PM Bobby Bruce  wrote:
>>>
 I don't fully understand the issue, but after doing a bisect, the
 commit causing these issues is
 https://gem5-review.googlesource.com/c/public/gem5/+/58356.

 To reproduce locally:

 ```
 docker run -u $UID:$GID --rm -v $(pwd):$(pwd) -w $(pwd)
 gcr.io/gem5-test/clang-version-9 python3 /usr/bin/scons
 build/NULL/gem5.opt -j`nproc`
 ```

 which will return:

 ```
 scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type:
 'Literal'' trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX,
 __env__)}'
 ```


 This only appears to affect older versions of clang and gcc, though we
 still support these so this needs to be fixed.


 Reverting the offending commit, `git revert
 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce`, does appear to fix this problem
 on the develop branch.


 @Gabe: Can you have a look into this and see if there's any better fix
 than just reverting this change?

 --
 Kind regards,
 Bobby
 --
 Dr. Bobby R. Bruce
 Room 3050,
 Kemper Hall, UC Davis
 Davis,
 CA, 95616

 web: https://www.bobbybruce.net


 On Fri, Apr 1, 2022 at 8:12 AM Jason Lowe-Power via gem5-dev <
 gem5-dev@gem5.org> wrote:
 >
 > Interesting errors. See
 https://jenkins.gem5.org/job/compiler-checks/189/artifact/compile-test-out/clang-version-9/
 for more info. I think this is a scons error, as it looks like python.
 >
 > scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type:
 'Literal'' trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX,
 __env__)}'
 >
 >
 >
 >
 > On Fri, Apr 1, 2022 at 5:21 AM jenkins-no-reply--- via gem5-dev <
 gem5-dev@gem5.org> wrote:
 >>
 >> See <
 https://jenkins.gem5.org/job/compiler-checks/189/display/redirect?page=changes
 >
 >>
 >> Changes:
 >>
 >> [gabe.black] scons: Remove an error check from the ProtoBuf
 declare-er.
 >>
 >> [yenlinlai] scons: Allow sources and libs called multiple times
 >>
 >> [gabe.black] scons: Add a priority field to the SourceLib construct.
 >>
 >> [gabe.black] scons: Get rid of an unused fast model variable.
 >>
 >> [gabe.black] scons: Tone down a fast model error into a warning.
 >>
 >> [gabe.black] scons: Stop the fast model project file parser from
 writing files.
 >>
 >> [gabe.black] scons: Rework the fastmodel extract_var helper.
 >>
 >> [gabe.black] scons: Only warn about not finding fast model libs if

[gem5-dev] Re: Build failed in Jenkins: nightly #183

[Bobby Bruce via gem5-dev]

My fault. Fixed here:
https://gem5-review.googlesource.com/c/public/gem5/+/58609

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Apr 5, 2022 at 2:05 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/183/display/redirect?page=changes>
>
> Changes:
>
> [Bobby R. Bruce] stdlib: Incorporating multi-isa work to the stdlib
>
> [Bobby R. Bruce] tests: Add the 'constants.all_compiled_tag'
>
> [Bobby R. Bruce] tests,testlib: Add tests for
> gem5.runtime.get_runtime_isa()
>
> [Bobby R. Bruce] stdlib: Add the MinorCPU type to the stdlib
>
> [Bobby R. Bruce] tests: Add MinorCPU tests to Hello World tests
>
> [Bobby R. Bruce] tests: Add MinorCPU tests to the RISCV Boot tests
>
> [Bobby R. Bruce] stdlib,tests: Add Str-to-CPUTypes helper functions
>
>
> --
> [...truncated 2.46 MB...]
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> send_bytes
> self._send_bytes(m[offset:offset + size])
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in
> _send_bytes
> self._send(header + buf)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in
> _send
> n = write(self._handle, buf)
> BrokenPipeError: [Errno 32] Broken pipe
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> send_bytes
> self._send_bytes(m[offset:offset + size])
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in
> _send_bytes
> self._send(header + buf)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in
> _send
> n = write(self._handle, buf)
> BrokenPipeError: [Errno 32] Broken pipe
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> send_bytes
> self._send_bytes(m[offset:offset + size])
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in
> _send_bytes
> self._send(header + buf)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in
> _send
> n = write(self._handle, buf)
> BrokenPipeError: [Errno 32] Broken pipe
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> send_bytes
> self._send_bytes(m[offset:offset + size])
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in
> _send_bytes
> self._send(header + buf)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in
> _send
> n = write(self._handle, buf)
> BrokenPipeError: [Errno 32] Broken pipe
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> send_bytes
> self._send_bytes(m[offset:offset + size])
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in
> _send_bytes
> self._send(header + buf)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in
> _send
> n = write(self._handle, buf)
> BrokenPipeError: [Errno 32] Broken pipe
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> send_bytes
> self._send_bytes(m[offset:offset + size])
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in
> _send_bytes
> self._send(header + buf)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in
> _send
> n = write(self._handle, buf)
> BrokenPipeError: [Errno 32] Broken pipe
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> send_bytes
> self._send_bytes(m[offset:offset + size])
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 411, in
> _send_bytes
> self._send(header + buf)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 368, in
> _send
> n = write(self._handle, buf)
> BrokenPipeError: [Errno 32] Broken pipe
> Traceback (most recent call last):
>   File "/usr/lib/python3.8/multiprocessing/queues.py", line 245, in _feed
> send_bytes(obj)
>   File "/usr/lib/python3.8/multiprocessing/connection.py", line 200, in
> 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #189

[Bobby Bruce via gem5-dev]

I don't fully understand the issue, but after doing a bisect, the commit
causing these issues is
https://gem5-review.googlesource.com/c/public/gem5/+/58356.

To reproduce locally:

```
docker run -u $UID:$GID --rm -v $(pwd):$(pwd) -w $(pwd)
gcr.io/gem5-test/clang-version-9 python3 /usr/bin/scons build/NULL/gem5.opt
-j`nproc`
```

which will return:

```
scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type: 'Literal''
trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX, __env__)}'
```


This only appears to affect older versions of clang and gcc, though we
still support these so this needs to be fixed.


Reverting the offending commit, `git revert
3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce`, does appear to fix this problem
on the develop branch.


@Gabe: Can you have a look into this and see if there's any better fix than
just reverting this change?

--
Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Apr 1, 2022 at 8:12 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:
>
> Interesting errors. See
https://jenkins.gem5.org/job/compiler-checks/189/artifact/compile-test-out/clang-version-9/
for more info. I think this is a scons error, as it looks like python.
>
> scons: *** [build/RISCV/gem5.opt] TypeError `unhashable type: 'Literal''
trying to evaluate `${_concat(RPATHPREFIX, RPATH, RPATHSUFFIX, __env__)}'
>
>
>
>
> On Fri, Apr 1, 2022 at 5:21 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:
>>
>> See <
https://jenkins.gem5.org/job/compiler-checks/189/display/redirect?page=changes
>
>>
>> Changes:
>>
>> [gabe.black] scons: Remove an error check from the ProtoBuf declare-er.
>>
>> [yenlinlai] scons: Allow sources and libs called multiple times
>>
>> [gabe.black] scons: Add a priority field to the SourceLib construct.
>>
>> [gabe.black] scons: Get rid of an unused fast model variable.
>>
>> [gabe.black] scons: Tone down a fast model error into a warning.
>>
>> [gabe.black] scons: Stop the fast model project file parser from writing
files.
>>
>> [gabe.black] scons: Rework the fastmodel extract_var helper.
>>
>> [gabe.black] scons: Only warn about not finding fast model libs if it's
enabled.
>>
>> [gabe.black] scons: Add a tag for arm fastmodel and use it.
>>
>>
>> --
>> Started by timer
>> Running as SYSTEM
>> Building in workspace 
>> The recommended git tool is: NONE
>> No credentials specified
>>  > git rev-parse --resolve-git-dir <
https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
>> Fetching changes from the remote Git repository
>>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
# timeout=10
>> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>>  > git --version # timeout=10
>>  > git --version # 'git version 2.25.1'
>>  > git fetch --tags --force --progress --
https://gem5.googlesource.com/public/gem5
+refs/heads/*:refs/remotes/origin/* # timeout=10
>>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
>> Checking out Revision 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce
(refs/remotes/origin/develop)
>>  > git config core.sparsecheckout # timeout=10
>>  > git checkout -f 3b6ea3dfa9055fcd7fb83738b11d00ac00f813ce # timeout=10
>> Commit message: "scons: Add a tag for arm fastmodel and use it."
>>  > git rev-list --no-walk 118b069d5d238c68afbe29d11878137746b3c375 #
timeout=10
>> [Checks API] No suitable checks publisher found.
>> [compiler-checks] $ /bin/sh -xe /tmp/jenkins10877671131247552434.sh
>> + ./tests/compiler-tests.sh -j 16
>> Starting build tests with 'gcc-version-11'...
>> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
built.
>>   * Building target 'X86_MI_example.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'X86_MI_example.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'POWER.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'POWER.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'RISCV.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'RISCV.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'Garnet_standalone.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'Garnet_standalone.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-11'...
>> Done.
>>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-11'...
>> Done.
>>   * Building target 

[gem5-dev] gem5 v22.0 to be released in early May. Staging branch to be created by the end of April

[Bobby Bruce via gem5-dev]

Dear all,

In line with our policy of having three major releases a year, we're aiming
to have v22.0 of gem5 released in early May.  This means we'll be creating
a staging branch from the develop branch by the end of April. The staging
branch will be intensely tested to ensure it is suitable for general
community use before being merged into the stable branch.

We understand there's a backlog of patches to be reviewed. We'll try to
ensure everyone who puts in the effort to submit for this release, and
responds promptly to feedback, makes it into the v22.0 release. If you feel
your patches have been ignored, please ping us on the relevant Gerrit
submission (if you have not already added reviewers, remember to add them).
Help with reviewing over the next month would also be greatly appreciated.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Upcoming gem5 events! Tutorial, Workshop, and Boot Camp!

[Bobby Bruce via gem5-dev]

Dear all,

We wish to make the computer architecture research community aware of
several gem5 events occurring over the next 6 months. There will be two
events co-located at ISCA 2022 (held in New York, June 18th) -- a 3 hour
tutorial, and a 3 hour workshop. In July, there will be a "gem5 Boot Camp",
5 days, July 11 to July 15th, for junior computer architecture researchers
to learn how to use gem5 in their projects.

Specific event details are shown below. Please relay these details to
anyone that may be interested.

*ISCA 2022: The gem5 Tutorial*

Date: June 18th 2022 (Morning session)
Location: ISCA, New York City
Webpage: https://www.gem5.org/events/isca-2022#the-4th-gem5-tutorial
Registration: Please keep an eye on the ISCA website for registration
information https://iscaconf.org/isca2022/

The gem5 tutorial is designed to give computer architecture researchers a
"crash course" in using gem5. No prior experience is required and the event
is open to anyone wanting to attend.

The tutorial will be carried out over the course of a 3 hour session with
attendees working from their own laptops. A tentative schedule is shown
here:

- First hour: Getting started with gem5.
This will cover the basics of building a simulation of gem5, from
compilation to building full-system simulations using the gem5 standard
library.

- Second hour: Extending gem5
This will cover how to create your own gem5 simobjects, add your own
components to the library, and running simulations with the components you
have created.

- Third hour: Deeper topics
The last hour will cover more advanced topics such as the gem5 memory
system and ruby.


*ISCA 2022: The gem5 Users' Workshop*

Date: June 18th 2022 (Afternoon session)
Location: ISCA, New York City
Webpage: https://www.gem5.org/events/isca-2022#the-4th-gem5-users-workshop
Registration: Please keep an eye on the ISCA website for registration
information https://iscaconf.org/isca2022/
Presentation proposal link: https://forms.gle/VZxXsWBniUPGBQdw5
Presentation proposal deadline: April 26th (Notifications sent out by May
9th).

The gem5 Users' Workshop will start with a 30 minute keynote presentation
by Prof. Jason Lowe-Power titled "Recent Advancements in Mainline gem5
v20.0 – v21.2". This will be followed by a series of 15 minutes
presentations. These presentations are an opportunity for users of gem5 to
present gem5-related work and foster discussion.

Presentations are solicited on a broad range of topics related to gem5.
Including, but not limited to:

- New gem5 features and models.
- Improved models.
- Validation against real hardware.
- Software Engineering related to gem5.
- Experiences using gem5.
- Tools, visualizations, data analysis tools, etc.

If you wish to present at this year's gem5 Users' workshop, please provide
a presentation proposal (a 1 page PDF) here:
https://forms.gle/VZxXsWBniUPGBQdw5. The deadline for submitting a
presentation proposal is April 26th with acceptance notifications sent out
by May 9th.

Note: this is an in-person event. Presenters must attend the workshop.

*July 2022: The gem5 Boot Camp*

Dates: July 11th to July 15th 2022
Location: Davis, California
Webpage: https://www.gem5.org/events/boot-camp-2022
Application form: https://forms.gle/3wWPsMDfXyaChmQ68
Application Deadline: May 18th (Notifications sent out by June 1st)

The gem5 boot camp is for junior computer architecture researchers,
particularly PhD. students, to learn how to use gem5 in their projects. The
event will be held over 5 days and will take attendees through all aspects
of using the gem5 simulation from setting up basic system simulations,
creating components, learning to interpret gem5 stats, all the through to
running and modifying simulations comparable to real world systems.

This event is free for all accepted attendees. Registration, accommodation
and meals will incur no cost. Travel grants will also be available.

Those wishing to attend should register using the following form:
https://forms.gle/AztSG3mD2BqQ4f967. The deadline for applying is May 18th.
Accepted applicants will be notified by June 1st.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #187

[Bobby Bruce via gem5-dev]

Gabe,

It seems like this patch:
https://gem5-review.googlesource.com/c/public/gem5/+/56892 is causing the
compilation failure. I've left a comment there. The TL;DR: when compiling
with our minimum dependencies (no optional packages), we get `Error: Got
protobuf to build, but lacks support!`. I assume this means this patch is
enforcing protobuf as a mandatory package for compilation?

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Mar 29, 2022 at 5:26 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/187/display/redirect?page=changes
> >
>
> Changes:
>
> [fcrh] mem: Add SharedMemoryServer
>
> [gabe.black] arch-arm: Override makeRead and makeWrite in the ISA
> description.
>
> [gabe.black] ext: Add a cont_choice keyword to kconfiglib.
>
> [gabe.black] scons: Put all config variables in an env['CONF'] sub-dict.
>
> [gabe.black] scons: Put internal build files in a gem5.build directory.
>
> [Bobby R. Bruce] tests: Remove accidentally included "exit 0" test code
>
> [matthew.poremba] configs,gpu-compute: Support fetch from system pages
>
> [matthew.poremba] dev-hsa: Properly mask HSA packet header bits
>
> [matthew.poremba] dev-hsa: Update QCntxt readIndex in HW scheduler write
>
> [gabe.black] arch: Split up src/dest register ID creation.
>
> [srikant.bharadwaj] configs: Update memory port name in Ruby
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> The recommended git tool is: NONE
> No credentials specified
>  > git rev-parse --resolve-git-dir <
> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> Checking out Revision 4c9084e318f5ae02af4b372e39bbb7fee3518b97
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 4c9084e318f5ae02af4b372e39bbb7fee3518b97 # timeout=10
> Commit message: "configs: Update memory port name in Ruby"
>  > git rev-list --no-walk 64d00f83c4beafbe10c2217b69ccf7212063b014 #
> timeout=10
> [Checks API] No suitable checks publisher found.
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins15341758373293734952.sh
> + ./tests/compiler-tests.sh -j 16
> Starting build tests with 'gcc-version-11'...
> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'SPARC.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'SPARC.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'RISCV.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'RISCV.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
> 'gcc-version-11'...
> Done.
>   * Building target 'ARM.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.fast' with
> 'gcc-version-11'...
> 

[gem5-dev] Re: Build failed in Jenkins: nightly #172

[Bobby Bruce via gem5-dev]

I'm frustrated that I don't know why this error is occurring and Google is
of little help. This appears to be nothing to do with the actual tests but
some fault with Docker.

My only guess is the Docker container, in this case, is running out of
memory, so I've increased it via this patch:
https://gem5-review.googlesource.com/c/public/gem5/+/58169. Let's see if
this fixes the problem.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Mar 24, 2022 at 4:58 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/172/display/redirect?page=changes>
>
> Changes:
>
> [mattdsinclair] tests,configs,mem-ruby: Handle num DMAs in GPU Ruby tester
>
> [gabe.black] arch-arm,base: Use SourceLib() in a few simple spots.
>
>
> --
> [...truncated 2.62 MB...]
>  [SO Param] m5.objects.Ethernet, NSGigE -> POWER/python/_m5/param_NSGigE.cc
>  [SO Param] m5.objects.Ethernet, Sinic -> POWER/python/_m5/param_Sinic.cc
>  [SO Param] m5.objects.Ethernet, NSGigE -> POWER/params/NSGigE.hh
>  [SO Param] m5.objects.Ethernet, Sinic -> POWER/params/Sinic.hh
>  [ CXX] POWER/python/_m5/param_NSGigE.cc -> .o
>  [ CXX] POWER/python/_m5/param_Sinic.cc -> .o
>  [SO Param] m5.objects.Ethernet, EtherTap ->
> POWER/python/_m5/param_EtherTap.cc
>  [ CXX] POWER/dev/net/etherbus.cc -> .o
>  [ CXX] POWER/dev/net/etherswitch.cc -> .o
>  [ CXX] POWER/python/_m5/param_EtherTap.cc -> .o
>  [ CXX] POWER/dev/net/etherdevice.cc -> .o
>  [ CXX] POWER/dev/net/etherdump.cc -> .o
>  [ CXX] POWER/dev/net/etherint.cc -> .o
>  [ CXX] POWER/dev/net/etherlink.cc -> .o
>  [ CXX] POWER/dev/net/etherpkt.cc -> .o
>  [ CXX] POWER/dev/net/ethertap.cc -> .o
>  [ CXX] POWER/dev/net/pktfifo.cc -> .o
>  [ CXX] POWER/debug/Ethernet.cc -> .o
>  [ CXX] POWER/debug/EthernetCksum.cc -> .o
>  [ CXX] POWER/debug/EthernetDMA.cc -> .o
>  [ CXX] POWER/debug/EthernetData.cc -> .o
>  [ CXX] POWER/debug/EthernetDesc.cc -> .o
>  [ CXX] POWER/debug/EthernetEEPROM.cc -> .o
>  [ CXX] POWER/debug/EthernetIntr.cc -> .o
>  [ CXX] POWER/debug/EthernetPIO.cc -> .o
>  [ CXX] POWER/debug/EthernetSM.cc -> .o
>  [ CXX] POWER/dev/net/dist_iface.cc -> .o
>  [ CXX] POWER/dev/net/dist_etherlink.cc -> .o
>  [ CXX] POWER/dev/net/tcp_iface.cc -> .o
>  [ CXX] POWER/debug/DistEthernet.cc -> .o
>  [ CXX] POWER/debug/DistEthernetPkt.cc -> .o
>  [ CXX] POWER/debug/DistEthernetCmd.cc -> .o
>  [ CXX] POWER/dev/net/i8254xGBe.cc -> .o
>  [ CXX] POWER/dev/net/ns_gige.cc -> .o
>  [ CXX] POWER/dev/net/sinic.cc -> .o
>  [ CXX] POWER/debug/EthernetAll.cc -> .o
>  [ CXX] POWER/debug/EthernetNoData.cc -> .o
>  [ CXX] POWER/dev/ps2/PS2.py.cc -> .o
>  [SO Param] m5.objects.PS2, PS2Device ->
> POWER/python/_m5/param_PS2Device.cc
>  [SO Param] m5.objects.PS2, PS2Device -> POWER/params/PS2Device.hh
>  [SO Param] m5.objects.PS2, PS2Keyboard ->
> POWER/python/_m5/param_PS2Keyboard.cc
>  [ CXX] POWER/python/_m5/param_PS2Device.cc -> .o
>  [SO Param] m5.objects.PS2, PS2Mouse -> POWER/python/_m5/param_PS2Mouse.cc
>  [SO Param] m5.objects.PS2, PS2Keyboard -> POWER/params/PS2Keyboard.hh
>  [SO Param] m5.objects.PS2, PS2Mouse -> POWER/params/PS2Mouse.hh
>  [ CXX] POWER/python/_m5/param_PS2Keyboard.cc -> .o
>  [ CXX] POWER/python/_m5/param_PS2Mouse.cc -> .o
>  [SO Param] m5.objects.PS2, PS2TouchKit ->
> POWER/python/_m5/param_PS2TouchKit.cc
>  [ CXX] POWER/dev/ps2/device.cc -> .o
>  [SO Param] m5.objects.PS2, PS2TouchKit -> POWER/params/PS2TouchKit.hh
>  [ CXX] POWER/dev/ps2/keyboard.cc -> .o
>  [ CXX] POWER/dev/ps2/mouse.cc -> .o
>  [ CXX] POWER/python/_m5/param_PS2TouchKit.cc -> .o
>  [ CXX] POWER/dev/ps2/touchkit.cc -> .o
>  [ CXX] POWER/dev/ps2/types.cc -> .o
>  [ CXX] POWER/debug/PS2.cc -> .o
>  [ CXX] POWER/dev/qemu/QemuFwCfg.py.cc -> .o
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItem ->
> POWER/python/_m5/param_QemuFwCfgItem.cc
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItemBytes ->
> POWER/python/_m5/param_QemuFwCfgItemBytes.cc
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItemFile ->
> POWER/python/_m5/param_QemuFwCfgItemFile.cc
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItem ->
> POWER/params/QemuFwCfgItem.hh
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItemBytes ->
> POWER/params/QemuFwCfgItemBytes.hh
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItemFile ->
> POWER/params/QemuFwCfgItemFile.hh
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfg -> POWER/params/QemuFwCfg.hh
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgIo ->
> POWER/params/QemuFwCfgIo.hh
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItemString ->
> POWER/params/QemuFwCfgItemString.hh
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgMmio ->
> POWER/params/QemuFwCfgMmio.hh
>  [SO Param] m5.objects.QemuFwCfg, QemuFwCfgItemString ->
> 

[gem5-dev] Re: Build failed in Jenkins: nightly #166

[Bobby Bruce via gem5-dev]

It seems like the tests were failing due to the Plots plugin running into
an error: https://jenkins.gem5.org/job/nightly/166/console. I have disabled
this and suspect the Nightly tests should pass now.

@Giacomo: Any idea what's going on here? Though I've turned this off, i've
taken note of the values you had for the plots plugin:

```
Plot group: All Regressions
Plot title: CPU execution time
Plot description: CPU execution time
Plot description: CPU execution time
Number of builds to include: 6
Plot style: Line
Data series file -> Load data from xml file using xpath -> XPath
Expression: //testsuite[@name='realview-simple-atomic-ARM-x86_64-opt']
```

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Sat, Mar 19, 2022 at 5:54 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/166/display/redirect?page=changes>
>
> Changes:
>
> [Bobby R. Bruce] tests: Add 'kvm' tag to tests
>
> [Bobby R. Bruce] tests,ext: Fix so ex/include regex are applied after
> defaults
>
> [Bobby R. Bruce] tests: Add KVM Tests to the nightly run
>
> [gabe.black] arch-vega: Replace deprecated Stats namespace recently
> reintroduced.
>
> [matthew.poremba] arch-vega: Mark global instructions executed as global
>
> [mattdsinclair] configs, gpu-compute: change default GPU reg allocator to
> dynamic
>
>
> --
> [...truncated 3.73 MB...]
>  [SHCC] RISCV/ext/softfloat/f64_le_quiet.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_lt.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_lt_quiet.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_mulAdd.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_mul.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_rem.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_roundToInt.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_sqrt.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_sub.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_f128.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_f16.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_f32.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_i32.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_i32_r_minMag.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_i64.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_i64_r_minMag.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_ui32.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_ui32_r_minMag.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_ui64.c -> .os
>  [SHCC] RISCV/ext/softfloat/f64_to_ui64_r_minMag.c -> .os
>  [SHCC] RISCV/ext/softfloat/i32_to_f128.c -> .os
>  [SHCC] RISCV/ext/softfloat/i32_to_f16.c -> .os
>  [SHCC] RISCV/ext/softfloat/i32_to_f32.c -> .os
>  [SHCC] RISCV/ext/softfloat/i32_to_f64.c -> .os
>  [SHCC] RISCV/ext/softfloat/i64_to_f128.c -> .os
>  [SHCC] RISCV/ext/softfloat/i64_to_f16.c -> .os
>  [SHCC] RISCV/ext/softfloat/i64_to_f32.c -> .os
>  [SHCC] RISCV/ext/softfloat/i64_to_f64.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_add128.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_add256M.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_addCarryM.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_addComplCarryM.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_addMagsF128.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_addMagsF16.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_addMagsF32.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_addMagsF64.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_addM.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_approxRecip_1Ks.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_approxRecip32_1.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_approxRecipSqrt_1Ks.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_approxRecipSqrt32_1.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_commonNaNToF128UI.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_commonNaNToF16UI.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_commonNaNToF32UI.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_commonNaNToF64UI.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_compare128M.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_compare96M.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_countLeadingZeros16.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_countLeadingZeros32.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_countLeadingZeros64.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_countLeadingZeros8.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_eq128.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_f128UIToCommonNaN.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_f16UIToCommonNaN.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_f32UIToCommonNaN.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_f64UIToCommonNaN.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_le128.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_lt128.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_mul128By32.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_mul128MTo256M.c -> .os
>  [SHCC] RISCV/ext/softfloat/s_mul128To256M.c -> .os
>  [SHCC] 

[gem5-dev] Re: Build failed in Jenkins: weekly #33

[Bobby Bruce via gem5-dev]

These two tests failed on jenkins with very similar errors:

```
JSONDecodeError: Unterminated string starting at: line 266 column 31 (char
12245)

At:
  /usr/lib/python3.8/json/decoder.py(355): raw_decode
  /usr/lib/python3.8/json/decoder.py(337): decode
  /usr/lib/python3.8/json/__init__.py(357): loads
  build/GCN3_X86/python/gem5/resources/downloader.py(104):
_get_resources_json_at_url
  build/GCN3_X86/python/gem5/resources/downloader.py(122):
_get_resources_json
  build/GCN3_X86/python/gem5/resources/downloader.py(287):
get_resources_json_obj
  build/GCN3_X86/python/gem5/resources/resource.py(162): __init__

/nobackup/jenkins/workspace/weekly/tests/gem5/configs/x86_boot_exit_run.py(205):

  build/GCN3_X86/python/m5/main.py(434): main
```

and

```
JSONDecodeError: Expecting value: line 1 column 1 (char 0)

At:
  /usr/lib/python3.8/json/decoder.py(355): raw_decode
  /usr/lib/python3.8/json/decoder.py(337): decode
  /usr/lib/python3.8/json/__init__.py(357): loads
  build/GCN3_X86/python/gem5/resources/downloader.py(104):
_get_resources_json_at_url
  build/GCN3_X86/python/gem5/resources/downloader.py(122):
_get_resources_json
  build/GCN3_X86/python/gem5/resources/downloader.py(287):
get_resources_json_obj
  build/GCN3_X86/python/gem5/resources/downloader.py(403): get_resource
  build/GCN3_X86/python/gem5/resources/resource.py(163): __init__

/nobackup/jenkins/workspace/weekly/tests/gem5/configs/x86_boot_exit_run.py(205):

  build/GCN3_X86/python/m5/main.py(434): main
```

I couldn't recreate these locally. One possible cause of this is my new
resources.json downloader functionality,
https://gem5-review.googlesource.com/c/public/gem5/+/57275, is causing a
situation where the resources.json file is being read while it's also being
downloaded by another instance of gem5. This would make sense as the weekly
tests run many gem5 threads and, as the tests take over an hour, the
resources.json file will be re-downloaded at times. I can't be sure this is
the problem, but I've created a fix here:
https://gem5-review.googlesource.com/c/public/gem5/+/57789.

Even if this doesn't fix things, it makes the code slightly less
error-prone.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Mar 15, 2022 at 4:11 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See 
>
> Changes:
>
> [gabe.black] dev,arch-x86: Create an x86 QEMU fw cfg, and an E820 entry
> type.
>
> [gabe.black] arch-x86: Get rid of the soft int Fault class.
>
> [gabe.black] arch-x86: Subtract the base from the PC when entering faults.
>
> [gabe.black] arch-x86: Use inline initializers for members of Interrupts.
>
> [gabe.black] scons: Move the build of ext/ into the variant dirs.
>
> [gabe.black] arch-x86,dev: Add an INTA like transaction for I8259.
>
> [gabe.black] arch-x86,dev: Use INTA to get the vector for the IO APIC.
>
> [gabe.black] arch-x86: Implement the LINT0 pin for the LAPIC.
>
> [gabe.black] arch-x86,dev: Use default initializers in the I8259.
>
> [gabe.black] arch-x86,dev: Make the I8259::getVector method protected.
>
> [matthew.poremba] mem-ruby: Remove DataBlk from MOESI_AMD DirectoryEntry
>
> [matthew.poremba] mem-ruby: Enhance MOESI_AMD DmaWrite
>
> [matthew.poremba] configs: Make VIPER memory MessageBuffers ordered
>
> [matthew.poremba] gpu-compute: Fix default MTYPE initialization
>
> [gabe.black] dev: Add a qemu fw config item for a byte array.
>
> [gabe.black] dev,arch-x86: Fix a panic in the i8042 device.
>
> [gabe.black] dev,arch-x86: Change the i8042 to a normal PioDevice.
>
> [gabe.black] arch-x86: Fix a bug in the protected mode IRET.
>
> [gabe.black] arch-x86: Fix writing back 32 bit PTEs in the walker.
>
> [gabe.black] arch-x86: Detect when entering virtual 8086 mode.
>
> [gabe.black] arch-x86: Tidy up the page table walker stepWalk method.
>
> [gabe.black] arch-x86: Use the right bits in the page table walker.
>
> [gabe.black] arch-x86: Make the flags microops handle reserved bits better.
>
> [matthew.poremba] sim-se: Initialize shared page table base upon clone
>
> [Bobby R. Bruce] util-docker: Adding docker-compose.yaml
>
> [Bobby R. Bruce] tests,util-docker: Add clang-12 to the compiler tests
>
> [Bobby R. Bruce] util: Remove util/cloudbuild
>
> [gabe.black] dev,arch-x86: Make the I8042 reset settings more realistic.
>
> [gabe.black] dev,arch-x86: Implement some self test 8042 commands.
>
> [gabe.black] scons: Process the SConsopts files for each variant.
>
> [gabe.black] scons: Turn a lot of compiler flag vars into env vars.
>
> [gabe.black] arch-x86: Fix the SAHF and LAHF instructions.
>
> [gabe.black] arch: Make the DummyVec... types the same size as RegVal.
>
>
> --
> [...truncated 820.16 KB...]
>  [SHCC] X86/ext/softfloat/s_shortShiftRight128.c -> .os
>  [SHCC] X86/ext/softfloat/s_shortShiftRightExtendM.c -> .os
>  [

[gem5-dev] Re: Build failed in Jenkins: nightly #157

[Bobby Bruce via gem5-dev]

Our compiler tests also failed with a docker error:
https://jenkins.gem5.org/job/compiler-checks/166/console

I'm guessing the Nightly tests momentarily killed the Docker service and
caused the compiler tests to fail?

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Mar 11, 2022 at 8:17 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:

> I spent some time looking into this I'm not sure what's going on. I
> don't *think* we're running out of memory (at least, dmesg doesn't say we
> ran out of memory).
>
> I'm trying to figure out if maybe docker is configured to kill processes
> when they use "too much" memory (for some definition of too much), but
> having trouble tracking that down.
>
> I'll keep digging...
>
> Jason
>
> On Fri, Mar 11, 2022 at 4:31 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/157/display/redirect?page=changes>
>>
>> Changes:
>>
>> [gabe.black] arch-x86: Use the new operand desc classes in the ISA
>> description.
>>
>> [gabe.black] arch: Create a new operand desc type which takes a class as
>> a parameter.
>>
>> [gabe.black] arch-riscv: Use the OperandDesc classes in the ISA
>> description.
>>
>> [gabe.black] arch-arm: Use the new OperandDesc classes in the ISA
>> description.
>>
>>
>> --
>> [...truncated 1.49 MB...]
>> Starting Test Case: build-POWER-opt
>> Starting Test Suite:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>>
>> Starting Test Case:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Test:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
>> /tmp/gem5out254odcqw -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
>> LinearGenerator 1 MESITwoLevel gem5.components.memory
>> SingleChannelDDR3_2133 512MiB
>> Starting Test Suite:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
>>
>> Starting Test Case:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Test:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR3_2133-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
>> /tmp/gem5outhken_zl9 -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
>> LinearGenerator 1 MESITwoLevel gem5.components.memory
>> SingleChannelDDR4_2400 512MiB
>> Starting Test Suite:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
>>
>> Starting Test Case:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Test:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelDDR4_2400-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
>> /tmp/gem5out5maaqx5u -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
>> LinearGenerator 1 MESITwoLevel gem5.components.memory
>> SingleChannelLPDDR3_1600 512MiB
>> Starting Test Suite:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelLPDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>>
>> Starting Test Case:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelLPDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Test:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelLPDDR3_1600-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Passed
>> Logging call to command:
>> /nobackup/jenkins/workspace/nightly/build/NULL_MESI_Two_Level/gem5.opt -d
>> /tmp/gem5out09n9ru6k -re --silent-redirect
>> /nobackup/jenkins/workspace/nightly/tests/gem5/traffic_gen/simple_traffic_run.py
>> LinearGenerator 1 MESITwoLevel gem5.components.memory SingleChannelHBM
>> 512MiB
>> Starting Test Suite:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelHBM-512MiB-NULL-x86_64-opt-MESI_Two_Level
>>
>> Starting Test Case:
>> test-memory-LinearGenerator-1-MESITwoLevel-gem5.components.memory-SingleChannelHBM-512MiB-NULL-x86_64-opt-MESI_Two_Level
>> Test:
>> 

[gem5-dev] Re: Build failed in Jenkins: nightly #156

[Bobby Bruce via gem5-dev]

I have no idea why this failed. This is building the GPU GCN3_x86 (in the
docker container), and it says it failed at the linking stage. I can't
recreate this locally. I'm going to run it again.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Mar 10, 2022 at 2:34 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/156/display/redirect?page=changes>
>
> Changes:
>
> [gabe.black] arch: Consolidate most of the RegVal based operands into a
> base class.
>
> [gabe.black] arch: Put operand properties into an object constructed with
> the list.
>
> [gabe.black] arch: Add desc subclasses for the various operand types.
>
> [Giacomo Travaglini] cpu: Rename initiateHtmCmd to be more generic
>
> [Giacomo Travaglini] cpu: Allow TLB shootdown requests in the timing cpu
>
> [Giacomo Travaglini] cpu: Allow TLB shootdown requests in the o3 cpu
>
> [Giacomo Travaglini] arch-arm: Add helper MISCREG to track a pending DVM
> operation
>
> [Giacomo Travaglini] arch-arm: Create a magic PendingDvm operand
>
> [Bobby R. Bruce] stdlib: Update the downloader to retry on failure
>
> [Bobby R. Bruce] stdlib: Cache the resources.json download
>
> [gabe.black] mem: Create a SysBridge object to bridge between Systems
> interconnect.
>
> [fcrh] mem: Fix phy mem with shm and multiple abstr mem
>
>
> --
> [...truncated 3.52 MB...]
>  [ CXX] GCN3_X86/dev/baddev.cc -> .o
>  [ CXX] GCN3_X86/dev/intel_8254_timer.cc -> .o
>  [ CXX] GCN3_X86/dev/mc146818.cc -> .o
>  [ CXX] GCN3_X86/dev/pixelpump.cc -> .o
>  [ CXX] GCN3_X86/debug/Intel8254Timer.cc -> .o
>  [ CXX] GCN3_X86/debug/MC146818.cc -> .o
>  [ CXX] GCN3_X86/dev/storage/Ide.py.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_IdeDisk.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_IdeController.cc -> .o
>  [ CXX] GCN3_X86/enums/IdeID.cc -> .o
>  [ CXX] GCN3_X86/dev/storage/ide_ctrl.cc -> .o
>  [ CXX] GCN3_X86/dev/storage/ide_disk.cc -> .o
>  [ CXX] GCN3_X86/debug/IdeCtrl.cc -> .o
>  [ CXX] GCN3_X86/debug/IdeDisk.cc -> .o
>  [ CXX] GCN3_X86/dev/storage/DiskImage.py.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_DiskImage.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_RawDiskImage.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_CowDiskImage.cc -> .o
>  [ CXX] GCN3_X86/dev/storage/SimpleDisk.py.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_SimpleDisk.cc -> .o
>  [ CXX] GCN3_X86/dev/storage/disk_image.cc -> .o
>  [ CXX] GCN3_X86/dev/storage/simple_disk.cc -> .o
>  [ CXX] GCN3_X86/debug/DiskImageRead.cc -> .o
>  [ CXX] GCN3_X86/debug/DiskImageWrite.cc -> .o
>  [ CXX] GCN3_X86/debug/SimpleDisk.cc -> .o
>  [ CXX] GCN3_X86/debug/SimpleDiskData.cc -> .o
>  [ CXX] GCN3_X86/debug/DiskImageAll.cc -> .o
>  [ CXX] GCN3_X86/debug/IdeAll.cc -> .o
>  [ CXX] GCN3_X86/dev/net/Ethernet.py.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherLink.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_DistEtherLink.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherBus.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherSwitch.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherTapBase.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherTapStub.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherDump.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherDevice.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_IGbE.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherDevBase.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_NSGigE.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_Sinic.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_EtherTap.cc -> .o
>  [ CXX] GCN3_X86/dev/net/etherbus.cc -> .o
>  [ CXX] GCN3_X86/dev/net/etherswitch.cc -> .o
>  [ CXX] GCN3_X86/dev/net/etherdevice.cc -> .o
>  [ CXX] GCN3_X86/dev/net/etherdump.cc -> .o
>  [ CXX] GCN3_X86/dev/net/etherint.cc -> .o
>  [ CXX] GCN3_X86/dev/net/etherlink.cc -> .o
>  [ CXX] GCN3_X86/dev/net/etherpkt.cc -> .o
>  [ CXX] GCN3_X86/dev/net/ethertap.cc -> .o
>  [ CXX] GCN3_X86/dev/net/pktfifo.cc -> .o
>  [ CXX] GCN3_X86/debug/Ethernet.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetCksum.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetDMA.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetData.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetDesc.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetEEPROM.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetIntr.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetPIO.cc -> .o
>  [ CXX] GCN3_X86/debug/EthernetSM.cc -> .o
>  [ CXX] GCN3_X86/dev/net/dist_iface.cc -> .o
>  [ CXX] GCN3_X86/dev/net/dist_etherlink.cc -> .o
>  [ CXX] GCN3_X86/dev/net/tcp_iface.cc -> .o
>  [ CXX] GCN3_X86/debug/DistEthernet.cc -> .o
>  [ CXX] GCN3_X86/debug/DistEthernetPkt.cc -> .o
>  [ CXX] GCN3_X86/debug/DistEthernetCmd.cc -> .o
> 

[gem5-dev] Re: All tests failing: Please don't commit anything!

[Bobby Bruce via gem5-dev]

Pretty sure the compiler tests are fixed, but they are re-running, so let's
see.

The nighty tests succeeded in the last couple of runs. Either what was
pushed before this submission freeze fixed the issue (I don't know exactly
how), or the test is flaky in some capacity. I'm letting it run again to
see if it triggers anything. It could have also just failed due to some
Jenkin's stutter.

The weekly tests failed with a docker error, "error waiting for container:
EOF". I couldn't reproduce this locally. From some Googling it happens when
you overwhelm the docker with too much CPU or memory utilization. I've
never seen it happen before with these tests. I'm running again to see if
it triggers again (I want to know if this is now something that will
consistently fail or some flakiness in our tests).

I'll wait until the weekly's finish again to see if we can unfreeze
submissions.
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Mar 7, 2022 at 8:26 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:
>
> Thanks, Giacomo!
>
> Now we just have to track down the others...
>
> Jason
>
> On Mon, Mar 7, 2022 at 2:02 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:
>>
>> Hi Jason,
>>
>>
>>
>> https://gem5-review.googlesource.com/c/public/gem5/+/57349 might fix the
compiler-check failure (gcc-version-7)
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Giacomo
>>
>>
>>
>> From: Jason Lowe-Power via gem5-dev 
>> Date: Saturday, 5 March 2022 at 17:27
>> To: gem5 Developer List 
>> Cc: Jason Lowe-Power 
>> Subject: [gem5-dev] All tests failing: Please don't commit anything!
>>
>> Hi gem5 developers!
>>
>>
>>
>> You may or may not have noticed that as of this morning (3/5) all of the
tests on our Jenkins server are failing. This includes the nightly tests,
weekly tests, and the compiler tests.
>>
>>
>>
>> I'd like to ask everyone to refrain from committing anything else to
develop until these tests are passing again. It's incredibly difficult to
track down the offending commit when the target is moving and new changes
may introduce new bugs.
>>
>>
>>
>> If you have some time to help track down these issues, we would also
greatly appreciate the help! You can find all of the logs from the failing
tests on the jenkins server: https://jenkins.gem5.org/. All of the build
artifacts are available for download.
>>
>>
>>
>> If you find any leads, please let us know! Given that today is a
Saturday, it will be Monday at the earliest that we will be able to dive in
ourselves.
>>
>>
>>
>> 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
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: resource downloader failure

[Bobby Bruce via gem5-dev]

I've added some code that should help here:
https://gem5-review.googlesource.com/c/public/gem5/+/57275

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Mar 1, 2022 at 10:41 AM Bobby Bruce  wrote:

> I'll change my answer slightly: It seems like this error is happening from
> trying to download the resources.json file (hosted in the resources repo)
> too much. I suspect there are similar restrictions here.  I think I can fix
> it too. I'll probably add a wait-and-retry for the resource downloader
> anyway as it'll make the downloader more stable.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Tue, Mar 1, 2022 at 10:28 AM Bobby Bruce  wrote:
>
>> Nice find Gabe. That would certainly explain a lot. Turns out there's a
>> 50Gbps quota that will return a 429 error if hit:
>> https://cloud.google.com/storage/quotas. I'll see if I can get this
>> increased and, either way, I'll implement a wait-and-retry strategy in the
>> downloader for when this error is received. I suspect this is hit when lots
>> of Kokoro instances are spun up at one time.
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Tue, Mar 1, 2022 at 2:08 AM Giacomo Travaglini via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Hi Gabe,
>>>
>>>
>>>
>>> A possible workaround could be to use the --bin-path option in testlib
>>>
>>>
>>>
>>> Kind Regards
>>>
>>>
>>>
>>> Giacomo
>>>
>>>
>>>
>>> *From: *Gabe Black via gem5-dev 
>>> *Date: *Tuesday, 1 March 2022 at 04:10
>>> *To: *gem5 Developer List 
>>> *Cc: *Gabe Black 
>>> *Subject: *[gem5-dev] resource downloader failure
>>>
>>> Hi folks. I've been trying to run tests locally, and I've been running
>>> into occasional flakiness due to a problem with the resource downloader.
>>> This reminds me somewhat of flakiness I was seeing in kokoro as well, so
>>> they are probably related. The error output is this:
>>>
>>>
>>>
>>> $ cat
>>> ./testing-results/SuiteUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/TestUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/simerr
>>> warn: .kvm_vm already has parent not resetting parent.
>>> Note: kvm_vm is not a parameter of X86Board
>>> warn: (Previously declared as .processor.kvm_vm
>>> HTTPError: HTTP Error 429: Too Many Requests
>>>
>>> At:
>>>   /usr/lib/python3.10/urllib/request.py(643): http_error_default
>>>   /usr/lib/python3.10/urllib/request.py(496): _call_chain
>>>   /usr/lib/python3.10/urllib/request.py(563): error
>>>   /usr/lib/python3.10/urllib/request.py(634): http_response
>>>   /usr/lib/python3.10/urllib/request.py(525): open
>>>   /usr/lib/python3.10/urllib/request.py(216): urlopen
>>>   build/GCN3_X86/python/gem5/resources/downloader.py(77):
>>> _get_resources_json
>>>   build/GCN3_X86/python/gem5/resources/downloader.py(207):
>>> get_resources_json_obj
>>>   build/GCN3_X86/python/gem5/resources/resource.py(162): __init__
>>>   /home/gblack/gem5/work/tests/gem5/configs/boot_kvm_fork_run.py(205):
>>> 
>>>   build/GCN3_X86/python/m5/main.py(434): main
>>>
>>>
>>>
>>>
>>>
>>> Is there a limit that needs to be bumped up? Some way to consolidate
>>> requests so we're not hitting the existing limit?
>>>
>>>
>>>
>>> Gabe
>>> 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
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: resource downloader failure

[Bobby Bruce via gem5-dev]

I'll change my answer slightly: It seems like this error is happening from
trying to download the resources.json file (hosted in the resources repo)
too much. I suspect there are similar restrictions here.  I think I can fix
it too. I'll probably add a wait-and-retry for the resource downloader
anyway as it'll make the downloader more stable.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Mar 1, 2022 at 10:28 AM Bobby Bruce  wrote:

> Nice find Gabe. That would certainly explain a lot. Turns out there's a
> 50Gbps quota that will return a 429 error if hit:
> https://cloud.google.com/storage/quotas. I'll see if I can get this
> increased and, either way, I'll implement a wait-and-retry strategy in the
> downloader for when this error is received. I suspect this is hit when lots
> of Kokoro instances are spun up at one time.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Tue, Mar 1, 2022 at 2:08 AM Giacomo Travaglini via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Hi Gabe,
>>
>>
>>
>> A possible workaround could be to use the --bin-path option in testlib
>>
>>
>>
>> Kind Regards
>>
>>
>>
>> Giacomo
>>
>>
>>
>> *From: *Gabe Black via gem5-dev 
>> *Date: *Tuesday, 1 March 2022 at 04:10
>> *To: *gem5 Developer List 
>> *Cc: *Gabe Black 
>> *Subject: *[gem5-dev] resource downloader failure
>>
>> Hi folks. I've been trying to run tests locally, and I've been running
>> into occasional flakiness due to a problem with the resource downloader.
>> This reminds me somewhat of flakiness I was seeing in kokoro as well, so
>> they are probably related. The error output is this:
>>
>>
>>
>> $ cat
>> ./testing-results/SuiteUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/TestUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/simerr
>> warn: .kvm_vm already has parent not resetting parent.
>> Note: kvm_vm is not a parameter of X86Board
>> warn: (Previously declared as .processor.kvm_vm
>> HTTPError: HTTP Error 429: Too Many Requests
>>
>> At:
>>   /usr/lib/python3.10/urllib/request.py(643): http_error_default
>>   /usr/lib/python3.10/urllib/request.py(496): _call_chain
>>   /usr/lib/python3.10/urllib/request.py(563): error
>>   /usr/lib/python3.10/urllib/request.py(634): http_response
>>   /usr/lib/python3.10/urllib/request.py(525): open
>>   /usr/lib/python3.10/urllib/request.py(216): urlopen
>>   build/GCN3_X86/python/gem5/resources/downloader.py(77):
>> _get_resources_json
>>   build/GCN3_X86/python/gem5/resources/downloader.py(207):
>> get_resources_json_obj
>>   build/GCN3_X86/python/gem5/resources/resource.py(162): __init__
>>   /home/gblack/gem5/work/tests/gem5/configs/boot_kvm_fork_run.py(205):
>> 
>>   build/GCN3_X86/python/m5/main.py(434): main
>>
>>
>>
>>
>>
>> Is there a limit that needs to be bumped up? Some way to consolidate
>> requests so we're not hitting the existing limit?
>>
>>
>>
>> Gabe
>> 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
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: resource downloader failure

[Bobby Bruce via gem5-dev]

Nice find Gabe. That would certainly explain a lot. Turns out there's a
50Gbps quota that will return a 429 error if hit:
https://cloud.google.com/storage/quotas. I'll see if I can get this
increased and, either way, I'll implement a wait-and-retry strategy in the
downloader for when this error is received. I suspect this is hit when lots
of Kokoro instances are spun up at one time.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Mar 1, 2022 at 2:08 AM Giacomo Travaglini via gem5-dev <
gem5-dev@gem5.org> wrote:

> Hi Gabe,
>
>
>
> A possible workaround could be to use the --bin-path option in testlib
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
>
>
> *From: *Gabe Black via gem5-dev 
> *Date: *Tuesday, 1 March 2022 at 04:10
> *To: *gem5 Developer List 
> *Cc: *Gabe Black 
> *Subject: *[gem5-dev] resource downloader failure
>
> Hi folks. I've been trying to run tests locally, and I've been running
> into occasional flakiness due to a problem with the resource downloader.
> This reminds me somewhat of flakiness I was seeing in kokoro as well, so
> they are probably related. The error output is this:
>
>
>
> $ cat
> ./testing-results/SuiteUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/TestUID:atomic-cpu_1-cores_classic_kvm-fork-run-test-GCN3_X86-x86_64-opt/simerr
> warn: .kvm_vm already has parent not resetting parent.
> Note: kvm_vm is not a parameter of X86Board
> warn: (Previously declared as .processor.kvm_vm
> HTTPError: HTTP Error 429: Too Many Requests
>
> At:
>   /usr/lib/python3.10/urllib/request.py(643): http_error_default
>   /usr/lib/python3.10/urllib/request.py(496): _call_chain
>   /usr/lib/python3.10/urllib/request.py(563): error
>   /usr/lib/python3.10/urllib/request.py(634): http_response
>   /usr/lib/python3.10/urllib/request.py(525): open
>   /usr/lib/python3.10/urllib/request.py(216): urlopen
>   build/GCN3_X86/python/gem5/resources/downloader.py(77):
> _get_resources_json
>   build/GCN3_X86/python/gem5/resources/downloader.py(207):
> get_resources_json_obj
>   build/GCN3_X86/python/gem5/resources/resource.py(162): __init__
>   /home/gblack/gem5/work/tests/gem5/configs/boot_kvm_fork_run.py(205):
> 
>   build/GCN3_X86/python/m5/main.py(434): main
>
>
>
>
>
> Is there a limit that needs to be bumped up? Some way to consolidate
> requests so we're not hitting the existing limit?
>
>
>
> Gabe
> 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
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #135

[Bobby Bruce via gem5-dev]

Hey Matt,

Did you get a chance to look into this?

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Feb 22, 2022 at 8:20 AM Poremba, Matthew via gem5-dev <
gem5-dev@gem5.org> wrote:

> [AMD Official Use Only]
>
> Yes, I will take a look soon.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Jason Lowe-Power 
> *Sent:* Sunday, February 20, 2022 9:18 AM
> *To:* gem5 Developer List ; Poremba, Matthew <
> matthew.pore...@amd.com>
> *Cc:* jenkins-no-re...@gem5.org
> *Subject:* Re: [gem5-dev] Build failed in Jenkins: nightly #135
>
>
>
> [CAUTION: External Email]
>
> Hey Matt,
>
>
>
> It looks like one of the Ruby changes you recently pushed is breaking the
> nightly tests. Can you take a look?
>
>
>
> Thanks!
>
> Jason
>
>
>
> On Sat, Feb 19, 2022 at 2:06 PM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
> See <
> https://jenkins.gem5.org/job/nightly/135/display/redirect?page=changes
> 
> >
>
> Changes:
>
> [tiago.muck] mem-ruby: Fix handling of stale CleanUnique
>
> [matthew.poremba] mem-ruby: Ensure MOESI_AMD_Base-dir has probe
> destinations
>
> [matthew.poremba] mem-ruby: Remove DirectoryMemory storage in
> MOESI_AMD_BASE-dir
>
> [matthew.poremba] mem-ruby: Add protocol prints to MOESI_AMD_BASE-dma
>
> [matthew.poremba] cpu: Only acquire needed tokens in PTL tester
>
> [matthew.poremba] configs: Allow for no DMAs in Ruby GPU tester
>
> [tiago.muck] cpu: fix issues with ruby's memtest
>
> [mattdsinclair] gpu-compute: Set scratch_base, lds_base for gfx902
>
> [mattdsinclair] gpu-compute: Fix register checking and allocation in dyn
> manager
>
> [gabe.black] ext-testlib: Import MutableSet properly.
>
>
> --
> [...truncated 1.65 MB...]
>  [ CXX] GCN3_X86/debug/VIOBlock.cc -> .o
>  [ CXX] GCN3_X86/debug/VIO9P.cc -> .o
>  [ CXX] GCN3_X86/debug/VIO9PData.cc -> .o
>  [ CXX] GCN3_X86/python/m5/defines.py.cc
> 
> -> .o
>  [ CXX] GCN3_X86/python/m5/info.py.cc
> 
> -> .o
>  [   SHCXX] iostream3/zfstream.cc -> .os
>  [   SHCXX] nomali/lib/gpu.cc -> .os
>  [   SHCXX] nomali/lib/gpublock.cc -> .os
>  [   SHCXX] nomali/lib/gpucontrol.cc -> .os
>  [   SHCXX] nomali/lib/jobcontrol.cc -> .os
>  [   SHCXX] nomali/lib/jobslot.cc -> .os
>  [   SHCXX] nomali/lib/mali_midgard.cc -> .os
>  [   SHCXX] nomali/lib/mali_t6xx.cc -> .os
>  [   SHCXX] nomali/lib/mali_t7xx.cc -> .os
>  [   SHCXX] nomali/lib/addrspace.cc -> .os
>  [   SHCXX] nomali/lib/mmu.cc -> .os
>  [   SHCXX] nomali/lib/nomali_api.cc -> .os
>  [   SHCXX] drampower/src/CommandAnalysis.cc -> .os
>  [   SHCXX] drampower/src/MemArchitectureSpec.cc -> .os
>  [   SHCXX] drampower/src/MemCommand.cc -> .os
>  [   SHCXX] drampower/src/MemPowerSpec.cc -> .os
>  [   SHCXX] drampower/src/MemTimingSpec.cc -> .os
>  [   SHCXX] drampower/src/MemoryPowerModel.cc -> .os
>  [   SHCXX] drampower/src/MemorySpecification.cc -> .os
>  [   SHCXX] drampower/src/Parameter.cc -> .os
>  [   SHCXX] drampower/src/Parametrisable.cc -> .os
>  [   SHCXX] drampower/src/libdrampower/LibDRAMPower.cc -> .os
>  [   SHCXX] drampower/src/CAHelpers.cc -> .os
>  [   SHCXX] drampower/src/CmdHandlers.cc -> .os
>  [   SHCXX] drampower/src/MemBankWiseParams.cc -> .os
>  [ CXX] GCN3_X86/base/date.cc -> .o
>  [LINK]  -> GCN3_X86/gem5.opt
> scons: done building targets.
> *** Summary of Warnings ***
> Warning: Deprecated namespaces are not supported by this compiler.
>  Please make sure to check the mailing list for deprecation
>  announcements.
> + wget -qN http://dist.gem5.org/dist/develop/test-progs/square/square
> 

[gem5-dev] gem5 v21.2.1 released!

[Bobby Bruce via gem5-dev]

Dear all,

A minor release, consisting of bug fixes and small improvements to v21.2 of
gem5, is now available. Users can obtain this release by pulling the latest
changes from the "stable" branch of the gem5 repository:
https://gem5.googlesource.com/public/gem5.

A short list outlining the changes in this release can be found in our
release notes:
https://gem5.googlesource.com/public/gem5/+/refs/tags/v21.2.1.0/RELEASE-NOTES.md
.

Thank you to everyone who made this release possible.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: microcode test system

[Bobby Bruce via gem5-dev]

Hey Gabe,

To answer your testing query, we do have some stuff setup to run python
test. We use Python's 'unittest' module for this (
https://docs.python.org/3.8/library/unittest.html).

In our setup "tests/run_pyunit.py" is run as part of our quick/kokoro tests
with NULL/gem5.opt (i.e., behind the scenes, `build/gem5/gem5.opt
tests/run_pyunit.py` is executed; you can run the tests directly this way).
If you look into this script you'll see it's looking for anything matching
"pyunit*.py" in the "tests/pyunit" directory. At present, there's only one
that matches, "tests/pyunit/util/pyunit_convert_check.py". This checks the
`m5.util.convert` utility works as intended. You can look into this file
and see how the unittests work, but, to explain it briefly, you create a
class which inherits from `unittest.TestCase` and the Python unittest
framework will execute any method in that class starting with "test_".

I'd be really happy if more Python-level unit tests were written, so please
feel free to play with this and add checks as you see fit.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Sun, Feb 6, 2022 at 4:21 AM Gabe Black via gem5-dev 
wrote:

> Hey testing folks (primarily Bobby probably?). I'm revamping the x86
> microcode to extract it from SCons itself, and also just to make it less
> painful and annoying to work with.
>
> Importantly, the microcode basically lists a sequence of microop mnemonics
> and a set of arguments. The mnemonic simply selects a python class, and the
> arguments are simply used verbatim to instantiate it. Once the assembler
> has turned a macroop definition into a sequence of instances of python
> microop classes, it goes through and turns those into essentially c++
> arrays (and some other stuff) which get compiled into gem5. The arguments
> passed to the microops are generally substituted into the code which
> instantiates the microop instances in c++. They often don't *look* like
> string constants, but that's because there are a bunch of python variables
> defined like t0, dsz, cs, etc, which all actually *hold* string constants.
>
> In any case, when we have a sequence of python objects which all represent
> a complete definition of what microop to use and all its parameters, we are
> just a small step away from being able to execute the *python* instances
> one by one, and being able to test the behavior of a macroop, assuming the
> python microops and the c++ microops do the same thing, and the macroop
> spits them into the CPU as expected.
>
> One key difference is that the arguments of the microops boil down to c++
> or are explicitly c++ string constants. When the arguments are symbolic, it
> would be relatively easy to substitute in a different set of variables
> which are really true python variables and not secretly c++. There aren't
> tons of places where there are raw string constants in the microcode, or at
> least not tons of different cases where that happens, so we could avoid the
> problem by just selectively defining what macroops to test, and/or by
> trying to convert the remaining string constants into variables which can
> have a python personality.
>
> What I'm hoping to accomplish with this email is to, first, just get this
> idea out there in case anybody has any feedback.
>
> Second, I want to find out what provisions we have for running python
> based tests. We have googletest to run c++ tests which I'm quite familiar
> with using, but I don't know what we have that's equivalent to that for
> python. Any pointers/docs?
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 Minor release v21.2.1: Candidate patches

[Bobby Bruce via gem5-dev]

Dear all,

Haven't heard much, or anything, from this. I'm going to take this as a
quiet thumbs up from the community.

I'm planning to release v21.1.2 on Tuesday, so there are still a few more
days to protest, ask questions, propose other patches, etc.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Jan 31, 2022 at 6:09 PM Bobby Bruce  wrote:

> Dear all,
>
> In the last month, since v21.2 has been released, gem5 contributors have
> fixed bugs and added improvements which I believe should be included as
> part of the v21.2 release. I've therefore decided to bundle these patches
> as part of a gem5 minor release; v21.2.1.
>
> I've been keeping track of patches I believe should be included in a minor
> release here: https://gem5.atlassian.net/browse/GEM5-1140 and have since
> cherry-picked them onto the minor release branch here:
> https://gem5-review.googlesource.com/c/public/gem5/+/56251.
>
> I'd appreciate it if the original authors of these commits could approve
> these patches being included in the minor release.
>
> If you believe there are other patches that belong as part of the minor
> release (bug fixes, stability improvements, that kind of thing), then
> please let me know.
>
> I'd like to release it at the beginning of next week but that's, of
> course, contingent on this all getting reviewed in time.
>
> Kind regards,
> Bobby
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Kokoro failures

[Bobby Bruce via gem5-dev]

Hey Giacomo,

For the first two patches I can't access the failing Kokoro due to re-runs
overwriting the log. In the last one,
https://gem5-review.googlesource.com/c/public/gem5/+/56303/1, I'm not
seeing a timeout issue. That appears to be my aforementioned issue, which
I've come to guess is due to a failure of Kokoro to download a needed
resource correctly (which has been known to happen from time-to-time,
unfortunately). Of the ones that pass I can see them completing in the 5 to
6 hour mark, which is what I've come to expect for a normal run. If
timeouts are happening, I suspect it's something to do with Kokoro running
slower or stalling? I'm not trying to shift the blame here but I can't see
any other explanation.

The Log4J checker code at the end is new to me:

```
[19:56:19] Loading Log4j Scanner Binary onto Build VM [19:56:21] Loading
Log4j Scanner Wrapper Script onto Build VM [19:56:22] Running Scanner on
VM. [ID: 5449648] Executing command via SSH: export
KOKORO_BUILD_NUMBER="11020" export
KOKORO_JOB_NAME="gem5/gcp_ubuntu/presubmit" source
"$HOME/.kokoro_python_vars" ; "$KOKORO_PYTHON_COMMAND"
/tmpfs/log4j_scanner.py Found no vulnerable JARs. [ID: 5449648] Build
finished after 2 secs, exit value: 0
```

I suspect Google has revamped this system at some point to, at least, add
this checker. Perhaps that is what's been causing problems? Perhaps we've
been pushing some patches while someone behind the scenes has been playing
with the server?

Kokoro is acting a bit odd elsewhere. In this chain
https://gem5-review.googlesource.com/c/public/gem5/+/56203, for example,
Kokoro just didn't start at all.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Feb 4, 2022 at 1:56 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:
>
> Thanks Bobby,
>
>
>
> Here are some examples:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/56426
>
> https://gem5-review.googlesource.com/c/public/gem5/+/55964/6
>
> https://gem5-review.googlesource.com/c/public/gem5/+/56303/1
>
>
>
> (If you check the verification history of the last patch you can see it
first failed due to timeout. This has become very common in the past days;
failing the first run, rebasing to re-trigger kokoro and hoping next time
It won’t timeout)
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
>
>
> From: Bobby Bruce 
> Date: Thursday, 3 February 2022 at 19:52
> To: Giacomo Travaglini 
> Cc: gem5-dev@gem5.org 
> Subject: Re: Kokoro failures
>
> Are there examples of this timeout happening recently? I can't see any
over the past week.
>
>
>
> There's a separate issue affecting one of Gabe's patches that I'm looking
into (here: https://gem5-review.googlesource.com/c/public/gem5/+/56303) but
these appear to be due to dynamic libraries not linking correctly.
>
>
>
> The only change in testing in the last month has been using clang-11
instead of clang-9 to do the clang compilation check. It's possible
clang-11 takes longer than clang-9 did? In December I increase the timeout
to 7 hours to give us more time to run tests as we were experiencing some
timeouts, I think due to the inclusion of some more tests.
>
>
>
> We could move some tests to the Nightly run fairly easily.
>
>
>
> --
>
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
>
>
> web: https://www.bobbybruce.net
>
>
>
>
>
> On Thu, Feb 3, 2022 at 7:00 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:
>
> Hi all,
>
>
>
> I am seeing a lot of failures on kokoro due to timeouts.
>
> Have we recently added some extra tests to the quick/pre-submit
regressions?
>
>
>
> Kind Regards
>
>
>
> Giacomo
>
> 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.
>
> 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
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Kokoro failures

[Bobby Bruce via gem5-dev]

Are there examples of this timeout happening recently? I can't see any over
the past week.

There's a separate issue affecting one of Gabe's patches that I'm looking
into (here: https://gem5-review.googlesource.com/c/public/gem5/+/56303) but
these appear to be due to dynamic libraries not linking correctly.

The only change in testing in the last month has been using clang-11
instead of clang-9 to do the clang compilation check. It's possible
clang-11 takes longer than clang-9 did? In December I increase the timeout
to 7 hours to give us more time to run tests as we were experiencing some
timeouts, I think due to the inclusion of some more tests.

We could move some tests to the Nightly run fairly easily.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Feb 3, 2022 at 7:00 AM Giacomo Travaglini <
giacomo.travagl...@arm.com> wrote:

> Hi all,
>
>
>
> I am seeing a lot of failures on kokoro due to timeouts.
>
> Have we recently added some extra tests to the quick/pre-submit
> regressions?
>
>
>
> Kind Regards
>
>
>
> Giacomo
> 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
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] gem5 Minor release v21.2.1: Candidate patches

[Bobby Bruce via gem5-dev]

Dear all,

In the last month, since v21.2 has been released, gem5 contributors have
fixed bugs and added improvements which I believe should be included as
part of the v21.2 release. I've therefore decided to bundle these patches
as part of a gem5 minor release; v21.2.1.

I've been keeping track of patches I believe should be included in a minor
release here: https://gem5.atlassian.net/browse/GEM5-1140 and have since
cherry-picked them onto the minor release branch here:
https://gem5-review.googlesource.com/c/public/gem5/+/56251.

I'd appreciate it if the original authors of these commits could approve
these patches being included in the minor release.

If you believe there are other patches that belong as part of the minor
release (bug fixes, stability improvements, that kind of thing), then
please let me know.

I'd like to release it at the beginning of next week but that's, of course,
contingent on this all getting reviewed in time.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] gem5 v21.2 released!

[Bobby Bruce via gem5-dev]

Dear all,

gem5 v21.2.0.0 has officially been released.

You can use  `git clone https://gem5.googlesource.com/public/gem5`
 to obtain the latest release
and consult the RELEASE-NOTES.md for a high-level overview of significant
changes:
https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/RELEASE-NOTES.md

A special thank you to all our contributors for making this possible. We
had 790 commits from 33 unique contributors over the past few months. We
look forward to your continued support in our v22.0 release!

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] v21.2 staging branch created; v21.2 release scheduled for Dec 21st

[Bobby Bruce via gem5-dev]

Dear all,

The v21.2 staging branch has been created. Thank you to everyone who worked
hard over the past week to get their changes into the develop branch.

We'll still be accepting bug-fix changes to the v21.2 staging branch.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Broken SST due to python changes

[Bobby Bruce via gem5-dev]

Hey gabe.

No idea if this is the _best_ solution to your problem, but my solution
would be to rebuild the image with this installed. Modify the
`util/dockerfiles/sst-11.1.0/Dockerfile` to the environment you want. Then
run `docker build -t  util/dockerfiles/sst-11.1.0` to build
an image with the name "".

Then you can execute `docker run -u $UID:$GID --volume $(pwd):$(pwd) -w
$(pwd) -it ` within the gem5 directory to spin up and enter
a container from the image you just built. I think you'll be able to do
what you want inside the container.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Dec 10, 2021 at 7:24 PM Gabe Black  wrote:
>
> Dumb question: I'm trying to run gdb inside this container on the sst
thing. How do I do that? It's not installed in the container now, and I
can't (easily) figure out how to get it installed. I can tell docker to
install it, but then it seems to throw that away as soon as the command
ends.
>
> Gabe
>
> On Fri, Dec 10, 2021 at 5:09 PM Bobby Bruce  wrote:
>>
>> Thanks Gabe,
>>
>> This is very much appreciated. I'm going to create the release staging
once a couple more things get in. Feel free to push any patches related to
these bugs to the release staging branch.
>>
>> If there is an order of priority I'd say the bug affecting SST is of
higher importance than that affecting the Weeklies (as far as I can see the
latter is hard to trigger). That being said, we'll apply both to the new
release one way or another.
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Fri, Dec 10, 2021 at 5:02 PM Gabe Black  wrote:
>>>
>>> Hi Bobby, not yet, I meant to look into this for the last couple days
but kept running out of time. I'm sitting down to work on it right now.
>>>
>>> Gabe
>>>
>>> On Fri, Dec 10, 2021 at 1:21 PM Bobby Bruce  wrote:

 Hey Gabe,

 Is there any update on this?

 Kind regards,
 Bobby
 --
 Dr. Bobby R. Bruce
 Room 3050,
 Kemper Hall, UC Davis
 Davis,
 CA, 95616

 web: https://www.bobbybruce.net


 On Wed, Dec 8, 2021 at 5:51 PM Hoa Nguyen via gem5-dev <
gem5-dev@gem5.org> wrote:
>
> Hi Gabe,
>
> I have more details about this. In this use case, SST initialized the
> Python environment before adding the "gem5 object". This gem5 object
> will add more Python stuff from gem5 to the environment.
>
> The function that does that is initPython()
>
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/ext/sst/gem5.cc#415
>
> The following commands will pull the docker image for SST testing
> purposes (note that host_gem5_root and guest_gem5_root must be
> specified),
>
> ```
> docker run -u $UID:$GID --volume
"${host_gem5_root}":"${guest_gem5_root}" -w \
>  "${guest_gem5_root}" --rm gcr.io/gem5-test/sst-env \
>  bash -c "\
> scons build/RISCV/libgem5_opt.so -j${nproc} --without-tcmalloc; \
> cd ext/sst; \
> make clean; make; \
> sst --add-lib-path=./ sst/example.py;
> ```
>
> We appreciate your help!
>
> Regards,
> Hoa Nguyen
>
> On 12/8/21, Jason Lowe-Power  wrote:
> > Hey Gabe,
> >
> > This change breaks the SST integration. In the SST integration
python is
> > initialized from the SST module, not from init.cc (this is because
SST has
> > their own python interpreter).
> >
> > We would appreciate some help in fixing this. Hoa and Giacomo can
give you
> > an example that's breaking to help you fix it, I believe.
> >
> > https://gem5-review.googlesource.com/c/public/gem5/+/49413
> >
> > There's strong interest in having the SST integration working in
this
> > current release. We've spent a lot of time figuring out all of the
> > intricacies and would appreciate any help you can provide in these
last few
> > days before the release!
> >
> > Thanks!
> >
> > Jason
> >
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Broken SST due to python changes

[Bobby Bruce via gem5-dev]

Thanks Gabe,

This is very much appreciated. I'm going to create the release staging once
a couple more things get in. Feel free to push any patches related to these
bugs to the release staging branch.

If there is an order of priority I'd say the bug affecting SST is of higher
importance than that affecting the Weeklies (as far as I can see the latter
is hard to trigger). That being said, we'll apply both to the new release
one way or another.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Dec 10, 2021 at 5:02 PM Gabe Black  wrote:

> Hi Bobby, not yet, I meant to look into this for the last couple days but
> kept running out of time. I'm sitting down to work on it right now.
>
> Gabe
>
> On Fri, Dec 10, 2021 at 1:21 PM Bobby Bruce  wrote:
>
>> Hey Gabe,
>>
>> Is there any update on this?
>>
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Wed, Dec 8, 2021 at 5:51 PM Hoa Nguyen via gem5-dev 
>> wrote:
>>
>>> Hi Gabe,
>>>
>>> I have more details about this. In this use case, SST initialized the
>>> Python environment before adding the "gem5 object". This gem5 object
>>> will add more Python stuff from gem5 to the environment.
>>>
>>> The function that does that is initPython()
>>>
>>> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/ext/sst/gem5.cc#415
>>>
>>> The following commands will pull the docker image for SST testing
>>> purposes (note that host_gem5_root and guest_gem5_root must be
>>> specified),
>>>
>>> ```
>>> docker run -u $UID:$GID --volume
>>> "${host_gem5_root}":"${guest_gem5_root}" -w \
>>>  "${guest_gem5_root}" --rm gcr.io/gem5-test/sst-env \
>>>  bash -c "\
>>> scons build/RISCV/libgem5_opt.so -j${nproc} --without-tcmalloc; \
>>> cd ext/sst; \
>>> make clean; make; \
>>> sst --add-lib-path=./ sst/example.py;
>>> ```
>>>
>>> We appreciate your help!
>>>
>>> Regards,
>>> Hoa Nguyen
>>>
>>> On 12/8/21, Jason Lowe-Power  wrote:
>>> > Hey Gabe,
>>> >
>>> > This change breaks the SST integration. In the SST integration python
>>> is
>>> > initialized from the SST module, not from init.cc (this is because SST
>>> has
>>> > their own python interpreter).
>>> >
>>> > We would appreciate some help in fixing this. Hoa and Giacomo can give
>>> you
>>> > an example that's breaking to help you fix it, I believe.
>>> >
>>> > https://gem5-review.googlesource.com/c/public/gem5/+/49413
>>> >
>>> > There's strong interest in having the SST integration working in this
>>> > current release. We've spent a lot of time figuring out all of the
>>> > intricacies and would appreciate any help you can provide in these
>>> last few
>>> > days before the release!
>>> >
>>> > Thanks!
>>> >
>>> > Jason
>>> >
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Broken SST due to python changes

[Bobby Bruce via gem5-dev]

Hey Gabe,

Is there any update on this?

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Dec 8, 2021 at 5:51 PM Hoa Nguyen via gem5-dev 
wrote:

> Hi Gabe,
>
> I have more details about this. In this use case, SST initialized the
> Python environment before adding the "gem5 object". This gem5 object
> will add more Python stuff from gem5 to the environment.
>
> The function that does that is initPython()
>
> https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/ext/sst/gem5.cc#415
>
> The following commands will pull the docker image for SST testing
> purposes (note that host_gem5_root and guest_gem5_root must be
> specified),
>
> ```
> docker run -u $UID:$GID --volume "${host_gem5_root}":"${guest_gem5_root}"
> -w \
>  "${guest_gem5_root}" --rm gcr.io/gem5-test/sst-env \
>  bash -c "\
> scons build/RISCV/libgem5_opt.so -j${nproc} --without-tcmalloc; \
> cd ext/sst; \
> make clean; make; \
> sst --add-lib-path=./ sst/example.py;
> ```
>
> We appreciate your help!
>
> Regards,
> Hoa Nguyen
>
> On 12/8/21, Jason Lowe-Power  wrote:
> > Hey Gabe,
> >
> > This change breaks the SST integration. In the SST integration python is
> > initialized from the SST module, not from init.cc (this is because SST
> has
> > their own python interpreter).
> >
> > We would appreciate some help in fixing this. Hoa and Giacomo can give
> you
> > an example that's breaking to help you fix it, I believe.
> >
> > https://gem5-review.googlesource.com/c/public/gem5/+/49413
> >
> > There's strong interest in having the SST integration working in this
> > current release. We've spent a lot of time figuring out all of the
> > intricacies and would appreciate any help you can provide in these last
> few
> > days before the release!
> >
> > Thanks!
> >
> > Jason
> >
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #71

[Bobby Bruce via gem5-dev]

Fix here: https://gem5-review.googlesource.com/c/public/gem5/+/53823
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Dec 8, 2021 at 12:42 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/71/display/redirect?page=changes
> >
>
> Changes:
>
> [melissakjost] dev: Added new LupIO-RTC device
>
> [melissakjost] dev: Introduced new LupV Platform
>
> [melissakjost] stdlib: Introduced new LupV Board
>
> [melissakjost] dev: Added new LupIO-RNG device
>
> [melissakjost] stdlib: Added LupioRNG to LupVBoard
>
> [melissakjost] dev: Added new LupIO-TTY device
>
> [melissakjost] stdlib: Added LupioTTY to LupVBoard
>
> [melissakjost] dev: Added new Lupio-BLK Device
>
> [melissakjost] stdlib: Added LupioBLK Device to LupVBoard
>
> [melissakjost] dev: Added new LupIO-TMR device
>
> [melissakjost] dev: Added new LupIO-PIC device
>
> [melissakjost] stdlib: Modified LupV Platform + Board to use LupioPIC + TMR
>
> [melissakjost] dev: Modified LupioBLK and LupioTTY to use LupioPIC
>
> [melissakjost] dev: Modify LupIO-TMR for SMP support
>
> [melissakjost] dev: Added new Lupio-IPI device
>
> [melissakjost] stdlib: Added LupIO-IPI to the LupV Board
>
> [melissakjost] dev: Added new Lupio-SYS device
>
> [melissakjost] stdlib: Added Lupio-SYS device to LupV Board
>
> [melissakjost] stdlib: Moved LupV Board to an experimental folder
>
> [melissakjost] stdlib: Update the LupvBoard to account for stdlib changes
>
> [melissakjost] stdlib: Update the LupvBoard to use 'requires'
>
> [melissakjost] stdlib: Update the LupvBoard to use KernelDiskWorkload
>
> [melissakjost] configs: Added LupV script to configs
>
> [gabe.black] sim-se: Handle empty paths when resolving an "at" path.
>
> [gabe.black] sim-se: Implement the newfstatat system call.
>
> [gabe.black] arch-x86: Hook up system calls for 64 bit processes.
>
> [gabe.black] arch-x86: Hook up the newfstatat system call for 64 bit Linux.
>
> [yuhsingw] fastmodel: add setResetAddr interface
>
> [yuhsingw] fastmodel: CortexA76 implements setResetAddr interface
>
> [yuhsingw] fastmodel: CortexR52 implements setResetAddr interface
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> The recommended git tool is: NONE
> No credentials specified
>  > git rev-parse --resolve-git-dir <
> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> Checking out Revision 60e55ecef8310fc861e1effb0b1776c732abeacc
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 60e55ecef8310fc861e1effb0b1776c732abeacc # timeout=10
> Commit message: "fastmodel: CortexR52 implements setResetAddr interface"
>  > git rev-list --no-walk df516127145505177de0f01fa6d8985cf061d6af #
> timeout=10
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins877689978860865276.sh
> + ./tests/compiler-tests.sh -j 40
> Starting build tests with 'gcc-version-11'...
> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.fast' with
> 'gcc-version-11'...
> Done.
>   * Building target 'RISCV.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'RISCV.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'GCN3_X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'GCN3_X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #65

[Bobby Bruce via gem5-dev]

Fix here: https://gem5-review.googlesource.com/c/public/gem5/+/53684

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Dec 7, 2021 at 12:31 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/65/display/redirect?page=changes
> >
>
> Changes:
>
> [Bobby R. Bruce] scons,misc: Update default X86 protocol to MESI_Two_Level
>
> [Bobby R. Bruce] stdlib: Add X86DemoBoard
>
> [Bobby R. Bruce] tests: Add a nightly test for SST integration.
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> The recommended git tool is: NONE
> No credentials specified
>  > git rev-parse --resolve-git-dir <
> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> Checking out Revision cf7ce21848ea4aeee28737823e6e768f9a14ceaf
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f cf7ce21848ea4aeee28737823e6e768f9a14ceaf # timeout=10
> Commit message: "tests: Add a nightly test for SST integration."
>  > git rev-list --no-walk 35362d15f5e0ff914ff3ed76d1a385e76d282610 #
> timeout=10
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins11657432297015308831.sh
> + ./tests/compiler-tests.sh -j 70
> Starting build tests with 'gcc-version-11'...
> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'POWER.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'Garnet_standalone.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'Garnet_standalone.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MI_example.opt' with 'gcc-version-11'...
>   ! Failed with exit code 2.
>   * Building target 'X86_MI_example.fast' with 'gcc-version-11'...
>   ! Failed with exit code 2.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
> 'gcc-version-11'...
> Done.
>   * Building target 'NULL.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'SPARC.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'SPARC.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'RISCV.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'RISCV.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.fast' with
> 'gcc-version-11'...
> Done.
>   * Building target 'ARM.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'GCN3_X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'GCN3_X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
> Starting build tests with 'gcc-version-10'...
>   * Building target 'ARM_MOESI_hammer.opt' with 

[gem5-dev] v21.2 staging branch to be created on Wednesday

[Bobby Bruce via gem5-dev]

Dear all,

We are planning on creating a staging branch for v21.2 on Wednesday. I'm
aware we've had a lot of changes submitted to Gerrit over the past few
months so I am writing to make sure I haven't missed anything important.
Please reach out to me directly if you feel a change has been sitting
abandoned on Gerrit and I'll try to find time to give it a review and
ensure it makes it to the next release.

Note, anything that doesn't make it to this release can still make it to
gem5 v22.0 next year. As always, bug/stability improvements and minor,
inoffensive changes will be permitted to the staging branch for the time it
exists prior to release. So missing this cutoff isn't necessarily the end
of the world :).

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: redundant builds in the long regressions

[Bobby Bruce via gem5-dev]

Hey Gabe,

That change is still in review:
https://gem5-review.googlesource.com/c/public/gem5/+/53503

I just wanted to get a few more eyes on it before submitting. You are
correct, after this is merged we'll no longer need to compile
X86_MESI_Two_Level and vanilla X86.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Dec 6, 2021 at 4:42 AM Gabe Black  wrote:

> And also GCN3_X86, which hadn't started yet.
>
> On Mon, Dec 6, 2021 at 4:27 AM Gabe Black  wrote:
>
>> Hi Bobby and other folks. While I'm waiting for reviews on my register
>> related multiISA patch series, I'm running long regressions on it to try to
>> preemptively track down any bugs that might be in it.
>>
>> I notice that the test framework is build both
>> build/X86_MESI_Two_Level/gem5.opt and build/X86/gem5.opt. I think I
>> remember Bobby changing the ruby protocol of X86 to default to
>> MESI_Two_Level (or similar? Not yet checked in?), so having both versions
>> of X86 seem particularly redundant.
>>
>> I think this is less of a problem for the long regressions, but it would
>> still be nice/more efficient to get rid of the redundancy.
>>
>> Gabe
>>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] LupIO: Friendly IO Devices for gem5 (reviews appreciated!)

[Bobby Bruce via gem5-dev]

Dear all,

Here at UC Davis two undergraduate students, Melissa Jost and Laura Hinman,
have been working on incorporating LupIO devices into gem5.

For those unaware, LupIO devices were developed by Prof. Joel
Porquet-Lupine as a set of open-source I/O devices to be used for teaching.
They were designed to model a complete set of I/O devices that are neither
too complex to teach in a classroom setting, or too simple to translate to
understanding real-world devices. Our collection consists of a real-time
clock, random number generator, terminal device, block device, system
controller, timer device, programmable interrupt controller, as well as an
inter-processor interrupt controller. A more detailed outline of LupIO can
be found here:
https://luplab.cs.ucdavis.edu/assets/lupio/wcae21-porquet-lupio-paper.pdf .
Within gem5, these devices offer the capability to run simulations with a
complete set of I/O devices that are both easy to understand and manipulate.

Prior to Melissa and Laura's work these devices were only available for use
with QEMU. They have worked diligently over the past term to incorporate
these into gem5 for the RISCV ISA. They have incrementally added each
device into gem5, and into a LupV gem5 Board (LupvBoard) which, when using
gem5 alongside the correct device drivers in Linux, provides the capability
of booting a RISC-V Linux system with SMP support.

At present this work exists as a relation-chain in Gerrit:
https://gem5-review.googlesource.com/c/public/gem5/+/53040. We would
appreciate feedback on this relation-chain by those interested in this
work. We hope we can get this chain submitted into the develop branch soon
so it can be part of the gem5 v21.2 release.

For those interested in setting up and running the LupvBoard, an example
configuration script has been included at the top of the relation chain:
https://gem5-review.googlesource.com/c/public/gem5/+/53046.

Kind regards,
Bobby

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #48

[Bobby Bruce via gem5-dev]

That doesn't look like a failure to me, but maybe? The log isn't very
helpful here. Either way, here's the potential fix:
https://gem5-review.googlesource.com/c/public/gem5/+/52983.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Nov 19, 2021 at 6:44 AM Gabe Black via gem5-dev 
wrote:

> I think this is the problem:
>
> scons: `build/NULL/unittests.perf' is up to date.
> scons: `build/NULL/unittests.prof' is up to date.
>
> The prof and perf suffixes are no more. Those probably shouldn't have been
> using prof or perf anyway, at least not exclusively, because we definitely
> want asserts, etc, turned on when running tests, and perf/prof used fast as
> a template.
>
> Gabe
>
> On Fri, Nov 19, 2021 at 4:39 AM jenkins-no-reply--- via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> See <
>> https://jenkins.gem5.org/job/nightly/48/display/redirect?page=changes>
>>
>> Changes:
>>
>> [gabe.black] sim: Remove some old transitional code in SEWorkload.
>>
>> [gabe.black] cpu: Get rid of the BaseCPU UnifiedTLB parameter.
>>
>> [gabe.black] cpu: Remove an architecture check in addPrivateSplitL1Caches.
>>
>> [gabe.black] cpu: Set up _*_ports values in BaseCPU in __init__.
>>
>> [Bobby R. Bruce] stdlib: Fix RISCVBoard when running O3 CPU with Ruby
>>
>>
>> --
>> [...truncated 705.02 KB...]
>> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
>> [ RUN  ] LoggingFixture.VariadicStringPrint
>> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
>> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
>> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
>> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
>> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
>> [ RUN  ] LoggingFixture.DisabledPrint
>> [   OK ] LoggingFixture.DisabledPrint (0 ms)
>> [ RUN  ] LoggingFixture.WarnLoggerPrint
>> [   OK ] LoggingFixture.WarnLoggerPrint (1 ms)
>> [ RUN  ] LoggingFixture.InfoLoggerPrint
>> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.HackLoggerPrint
>> [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.FatalLoggerPrint
>> [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.PanicLoggerPrint
>> [   OK ] LoggingFixture.PanicLoggerPrint (0 ms)
>> [ RUN  ] LoggingFixture.BaseMessage
>> [   OK ] LoggingFixture.BaseMessage (0 ms)
>> [ RUN  ] LoggingFixture.BaseMessageOnce
>> [   OK ] LoggingFixture.BaseMessageOnce (0 ms)
>> [ RUN  ] LoggingFixture.Warn
>> [   OK ] LoggingFixture.Warn (0 ms)
>> [ RUN  ] LoggingFixture.Inform
>> [   OK ] LoggingFixture.Inform (0 ms)
>> [ RUN  ] LoggingFixture.Hack
>> [   OK ] LoggingFixture.Hack (0 ms)
>> [ RUN  ] LoggingFixture.WarnOnce
>> [   OK ] LoggingFixture.WarnOnce (0 ms)
>> [ RUN  ] LoggingFixture.InformOnce
>> [   OK ] LoggingFixture.InformOnce (0 ms)
>> [ RUN  ] LoggingFixture.HackOnce
>> [   OK ] LoggingFixture.HackOnce (0 ms)
>> [ RUN  ] LoggingFixture.WarnIf
>> [   OK ] LoggingFixture.WarnIf (0 ms)
>> [ RUN  ] LoggingFixture.WarnIfOnce
>> [   OK ] LoggingFixture.WarnIfOnce (0 ms)
>> [--] 21 tests from LoggingFixture (1 ms total)
>>
>> [--] Global test environment tear-down
>> [==] 34 tests from 2 test suites ran. (1647 ms total)
>> [  PASSED  ] 34 tests.
>> scons: done building targets.
>> *** Summary of Warnings ***
>> Warning: Deprecated namespaces are not supported by this compiler.
>>  Please make sure to check the mailing list for deprecation
>>  announcements.
>> + unit_test perf
>> + build=perf
>> + docker run -u 118: --volume
>> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>> -w /nobackup/jenkins/workspace/nightly/tests/.. --rm
>> gcr.io/gem5-test/ubuntu-20.04_all-dependencies scons
>> build/NULL/unittests.perf -j16
>> scons: Reading SConscript files ...
>> Checking for linker -Wl,--as-needed support... (cached) yes
>> Checking for compiler -Wno-free-nonheap-object support... (cached) yes
>> Checking for compiler -gz support... (cached) yes
>> Checking for linker -gz support... (cached) yes
>> Info: Using Python config: python3-config
>> Checking for C header file Python.h... (cached) yes
>> Checking Python version... (cached) 3.8.10
>> Checking for accept(0,0,0) in C++ library None... (cached) yes
>> Checking for zlibVersion() in C++ library z... (cached) yes
>> Checking for C library tcmalloc... (cached) yes
>> Checking for C header file fenv.h... (cached) yes
>> Checking for C header file png.h... (cached) yes
>> Checking for clock_nanosleep(0,0,NULL,NULL) in C library None... (cached)
>> yes
>> Checking for C header file valgrind/valgrind.h... (cached) no
>> Warning: Deprecated namespaces are not supported by this compiler.
>>  Please make sure to check 

[gem5-dev] Re: failing kvm tests

[Bobby Bruce via gem5-dev]

Took me longer than expected to figure this out, but I eventually got it. A
fix is here: https://gem5-review.googlesource.com/c/public/gem5/+/52663.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Tue, Nov 9, 2021 at 4:14 AM Gabe Black  wrote:

> On this topic, I commented on the already merged CL, but this change
> breaks the quick KVM regressions:
>
> https://gem5-review.googlesource.com/c/public/gem5/+/52183
>
> On Mon, Nov 8, 2021 at 11:46 AM Bobby Bruce  wrote:
>
>> Yip, I accidentally added some X86 tests to the quick/Kokoro tests.
>> Thanks for pointing that out. The fix can be found here:
>> https://gem5-review.googlesource.com/c/public/gem5/+/52563
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Mon, Nov 8, 2021 at 5:03 AM Gabe Black  wrote:
>>
>>> Just a quick note, I noticed when running quick regressions now that it
>>> builds both GC_X86 and X86. I'm assuming that's because the KVM tests are
>>> still set up to use X86? It would be nice to fix that to avoid building for
>>> an additional target.
>>>
>>> Gabe
>>>
>>> On Wed, Nov 3, 2021 at 10:55 AM Bobby Bruce  wrote:
>>>
 Hey Gabe,

 At present our Jenkins doesn't have KVM enabled so I believe no tests
 that use KVM were being run regularly. I intend to get KVM enabled on the
 Jenkins server over the next few days. I also found the bugs you were
 referring to when running the long (nightly) and very-long (weekly) tests
 on my local machine (where I have KVM). The long tests are fixed with this
 patch: https://gem5-review.googlesource.com/c/public/gem5/+/52384, and
 I'm currently looking into the bugs in the very-long tests.

 Kind regards,
 Bobby
 --
 Dr. Bobby R. Bruce
 Room 3050,
 Kemper Hall, UC Davis
 Davis,
 CA, 95616

 web: https://www.bobbybruce.net


 On Wed, Nov 3, 2021 at 4:22 AM Gabe Black via gem5-dev <
 gem5-dev@gem5.org> wrote:

> Hey folks, I recently discovered KVM wasn't set up on my desktop,
> which I just corrected. Now that it's enabled, the KVM tests have started
> running, and they are also failing. This could be sort of weird issue on 
> my
> machine, and I'm currently looking into the failure itself.
>
> The thing I wanted to ask was, do we have any KVM tests that run
> anywhere? Do we have them in the quick regressions but not the long
> regressions? Do we have KVM enabled on the nightly server? I can imagine 
> it
> (KVM) not being enabled on kokoro, but hopefully we can run those on the
> nightlies?
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s


___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing kvm tests

[Bobby Bruce via gem5-dev]

Yip, I accidentally added some X86 tests to the quick/Kokoro tests. Thanks
for pointing that out. The fix can be found here:
https://gem5-review.googlesource.com/c/public/gem5/+/52563

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Nov 8, 2021 at 5:03 AM Gabe Black  wrote:

> Just a quick note, I noticed when running quick regressions now that it
> builds both GC_X86 and X86. I'm assuming that's because the KVM tests are
> still set up to use X86? It would be nice to fix that to avoid building for
> an additional target.
>
> Gabe
>
> On Wed, Nov 3, 2021 at 10:55 AM Bobby Bruce  wrote:
>
>> Hey Gabe,
>>
>> At present our Jenkins doesn't have KVM enabled so I believe no tests
>> that use KVM were being run regularly. I intend to get KVM enabled on the
>> Jenkins server over the next few days. I also found the bugs you were
>> referring to when running the long (nightly) and very-long (weekly) tests
>> on my local machine (where I have KVM). The long tests are fixed with this
>> patch: https://gem5-review.googlesource.com/c/public/gem5/+/52384, and
>> I'm currently looking into the bugs in the very-long tests.
>>
>> Kind regards,
>> Bobby
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Wed, Nov 3, 2021 at 4:22 AM Gabe Black via gem5-dev 
>> wrote:
>>
>>> Hey folks, I recently discovered KVM wasn't set up on my desktop, which
>>> I just corrected. Now that it's enabled, the KVM tests have started
>>> running, and they are also failing. This could be sort of weird issue on my
>>> machine, and I'm currently looking into the failure itself.
>>>
>>> The thing I wanted to ask was, do we have any KVM tests that run
>>> anywhere? Do we have them in the quick regressions but not the long
>>> regressions? Do we have KVM enabled on the nightly server? I can imagine it
>>> (KVM) not being enabled on kokoro, but hopefully we can run those on the
>>> nightlies?
>>>
>>> Gabe
>>> ___
>>> gem5-dev mailing list -- gem5-dev@gem5.org
>>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>>
>>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: multi-ISA gem5 proof of concept

[Bobby Bruce via gem5-dev]

Looks good to me.

Perhaps this is explained elsewhere, but what's the logic in coupling the
CPU Type (Timing, Atomic, o3) with the ISA? Why do we interact with this
like `--cpu-type=X86AtomicSimpleCPU` and not `--cpu-type AtomicSimpleCPU
--isa=X86`? Current CPU types are switchable during a simulation, so they
are a parameter that can change, but the simulation's ISA, I assume, will
always fixed for the entirety of a run.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Nov 8, 2021 at 8:40 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:

> This looks quite promising! Uploading a branch to gerrit is a good idea.
>
> A couple of notes:
> 1. We are going to have to be very careful with when/how we merge this and
> its effect on users. For instance, changing the CPU from "AtomicSimpleCPU"
> to "ArmAtomicSimpleCPU" will break many users' use cases.
> 2. I just noticed that there's something wrong with the Arm hello
> application: "Simulated exit code not 0! Exit code is 13" It looks like
> current develop also has this problem, but it's a bit worrying. I can't
> figure out why the hello application wouldn't exit with code 0...
>
> Cheers,
> Jason
>
> On Sun, Nov 7, 2021 at 5:38 PM Gabe Black via gem5-dev 
> wrote:
>
>> Build performance improvements:
>>
>>
>> Building all 6 ISAs separately.
>>
>> $ time scons build/ARM/gem5.opt build/MIPS/gem5.opt build/POWER/gem5.opt
>> build/RISCV/gem5.opt build/SPARC/gem5.opt build/X86/gem5.opt
>>
>> real37m0.210s
>> user764m20.963s
>> sys 46m18.113s
>>
>> $ du -sh build
>> 16G build
>>
>>
>> Building "ALL" which has all 6 ISAs enabled together.
>>
>> $ time scons build/ALL/gem5.opt
>>
>> real10m28.289s
>> user194m31.505s
>> sys 9m36.281s
>>
>> $ du -sh build
>> 4.2Gbuild
>>
>>
>> Which is a build time reduction of about 72% on my system, and a build
>> directory size reduction of about 73%.
>>
>> Gabe
>>
>> On Sat, Nov 6, 2021 at 12:29 AM Gabe Black  wrote:
>>
>>> As mentioned in the other thread, I can upload this hash as a branch on
>>> gerrit if people want to try it out.
>>>
>>> Gabe
>>>
>>> $ git log --oneline origin/develop..multiarch | wc -l
>>> 203
>>>
>>> $ build/ALL/gem5.opt configs/example/se.py --cpu-type=ArmAtomicSimpleCPU
>>> -c tests/test-progs/hello/bin/arm/linux/hello
>>> build/ALL/base/statistics.hh:280: warn: One of the stats is a legacy
>>> stat. Legacy stat is a stat that does not belong to any statistics::Group.
>>> Legacy stat is deprecated.
>>> gem5 Simulator System.  http://gem5.org
>>> gem5 is copyrighted software; use the --copyright option for details.
>>>
>>> gem5 version [DEVELOP-FOR-V21.2]
>>> gem5 compiled Nov  6 2021 00:23:55
>>> gem5 started Nov  6 2021 00:25:58
>>> gem5 executing on cake, pid 999191
>>> command line: build/ALL/gem5.opt configs/example/se.py
>>> --cpu-type=ArmAtomicSimpleCPU -c tests/test-progs/hello/bin/arm/linux/hello
>>>
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> Global frequency set at 1 ticks per second
>>> build/ALL/mem/mem_interface.cc:791: warn: DRAM device capacity (8192
>>> Mbytes) does not match the address range assigned (512 Mbytes)
>>> 0: system.remote_gdb: listening for remote gdb on port 7000
>>>  REAL SIMULATION 
>>> build/ALL/sim/simulate.cc:194: info: Entering event queue @ 0.  Starting
>>> simulation...
>>> Hello world!
>>> Exiting @ tick 2916500 because exiting with last active thread context
>>> Simulated exit code not 0! Exit code is 13
>>>
>>>
>>>
>>> [gblack@cake work]$ build/ALL/gem5.opt configs/example/se.py
>>> --cpu-type=X86AtomicSimpleCPU -c tests/test-progs/hello/bin/x86/linux/hello
>>> build/ALL/base/statistics.hh:280: warn: One of the stats is a legacy
>>> stat. Legacy stat is a stat that does not belong to any statistics::Group.
>>> Legacy stat is deprecated.
>>> gem5 Simulator System.  http://gem5.org
>>> gem5 is copyrighted software; use the --copyright option for details.
>>>
>>> gem5 version [DEVELOP-FOR-V21.2]
>>> gem5 compiled Nov  6 2021 00:23:55
>>> gem5 started Nov  6 2021 00:26:10
>>> gem5 executing on cake, pid 999224
>>> command line: build/ALL/gem5.opt configs/example/se.py
>>> --cpu-type=X86AtomicSimpleCPU -c tests/test-progs/hello/bin/x86/linux/hello
>>>
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is now called `cpu_side_ports`
>>> warn: membus.slave is deprecated. `slave` is 

[gem5-dev] Re: preview branch for mutli-ISA gem5?

[Bobby Bruce via gem5-dev]

I think it's a great idea and we should probably do it more often for this
big long changes we don't want to straddle a release.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Nov 4, 2021 at 7:42 AM Jason Lowe-Power via gem5-dev <
gem5-dev@gem5.org> wrote:

> Seems like a good idea to me! I like the idea of having more feature
> branches for long-lived relation chains.
>
> Given the timing, it seems like it would be a good idea to hold off
> integrating this until gem5 22.0. If we have a branch we can test for a
> while, it will be less likely to break our users use cases.
>
> Cheers,
> Jason
>
> On Wed, Nov 3, 2021 at 11:51 PM Gabe Black via gem5-dev 
> wrote:
>
>> Hey folks, I'm not quite ready for it yet, but I'm getting close to
>> having everything at least written for a multi-ISA version of gem5. What do
>> you think about having a preview branch on gerrit? I can create one pretty
>> easily, I just want to make sure that's appropriate and something other
>> people might be interested in before I do so. Like I said, I haven't gotten
>> *quite* to the point where I have something useable, but I think I'm down
>> to the last few things.
>>
>> Gabe
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing kvm tests

[Bobby Bruce via gem5-dev]

Hey Gabe,

At present our Jenkins doesn't have KVM enabled so I believe no tests
that use KVM were being run regularly. I intend to get KVM enabled on the
Jenkins server over the next few days. I also found the bugs you were
referring to when running the long (nightly) and very-long (weekly) tests
on my local machine (where I have KVM). The long tests are fixed with this
patch: https://gem5-review.googlesource.com/c/public/gem5/+/52384, and I'm
currently looking into the bugs in the very-long tests.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Nov 3, 2021 at 4:22 AM Gabe Black via gem5-dev 
wrote:

> Hey folks, I recently discovered KVM wasn't set up on my desktop, which I
> just corrected. Now that it's enabled, the KVM tests have started running,
> and they are also failing. This could be sort of weird issue on my machine,
> and I'm currently looking into the failure itself.
>
> The thing I wanted to ask was, do we have any KVM tests that run anywhere?
> Do we have them in the quick regressions but not the long regressions? Do
> we have KVM enabled on the nightly server? I can imagine it (KVM) not being
> enabled on kokoro, but hopefully we can run those on the nightlies?
>
> Gabe
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: gem5 gui tool?

[Bobby Bruce via gem5-dev]

Hey Gabe,

The gem5 GUI code is still around, it's on a separate branch in the repo,
`feature-gui`: `git clone -b feature-gui
https://gem5.googlesource.com/public/gem5`.

We at UC Davis tried to get some students to continue working on this, but
we were never able to. Hopefully we can get someone to jump in and clean it
up at some point.

Anyway, that's where the code lives if you want to look at it.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Mon, Oct 18, 2021 at 10:47 PM Gabe Black via gem5-dev 
wrote:

> If you want to try my script, or even improve it (probably not hard!),
> it's attached.
>
> You can run it by first collecting a log of timestamps, which I did with a
> clean build:
>
> scons --debug=action-timestamps -j48 build/ARM/gem5.opt | tee log.txt
>
> and then run the script:
>
> ./scons_timeline.py log.txt
>
> I would be curious how that looks on our big compile test machine!
>
> Gabe
>
> On Mon, Oct 18, 2021 at 10:20 PM Gabe Black  wrote:
>
>> Wow, now I remember why I don't like GUI programming :-/
>>
>> Well, I sort of got some results, and the upshot is that linking gem5
>> takes a long time :-P. And I am able to at least superficially have 48
>> things going during the build, although it is not necessarily 48 times
>> faster than doing things one at a time.
>>
>> Gabe
>>
>> On Mon, Oct 18, 2021 at 5:45 PM Gabe Black  wrote:
>>
>>> Hey folks, a while ago some students developed a GUI tool for gem5.
>>> While I think that was great and really hasn't gotten the attention (or
>>> adoption?) that a tool like that should, I was looking for it for a more
>>> practical reason but haven't been able to find it.
>>>
>>> Does anybody know where it ended up? And additionally/alternatively,
>>> does anybody know what guil toolkit that used? I want to write up a quick
>>> SCons build performance visualizer and (assuming it goes into util?) I
>>> wouldn't want to add a second gui toolkit dependency.
>>>
>>> Thanks!
>>> Gabe
>>>
>> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #9

[Bobby Bruce via gem5-dev]

Hey Gabe,

It seems like both the Nightly and Compiler tests are failing because SPARC
no longer compilers. This appears to be due to this change:
https://gem5-review.googlesource.com/c/public/gem5/+/48717. It looks like
you changed "checkFpEnableFault" to "checkFpEnabled" and didn't update this
everywhere in the codebase. Could you fix this?

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Oct 14, 2021 at 1:17 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/9/display/redirect?page=changes
> >
>
> Changes:
>
> [giacomo.travaglini] arch-arm: Add sendto and recvfrom implementations to
> the Syscall Table
>
> [giacomo.travaglini] arch-arm: Add ftruncate implementation to the Syscall
> Table
>
> [giacomo.travaglini] misc: Using OS::size_t in syscall signature
>
> [giacomo.travaglini] misc: Using OS::off_t in syscall signature
>
> [gabe.black] arch,sparc: Get rid of the unused checkVecEnableFault
> mechanism.
>
> [gabe.black] sparc: Stop special casing FP enable checks for full system.
>
> [gabe.black] sparc: Stop using fp_enable_check.
>
> [giacomo.travaglini] mem: Make ruby AbstractController compatible with XBar
>
> [gabe.black] scons: Add tag support to GdbXml.
>
> [gabe.black] scons: Add tag support to ISADesc.
>
> [gabe.black] scons,arch: Make the gem5 lib tag imply the current arch tag.
>
> [gabe.black] scons: Make the SimObject list from the 'gem5 lib' tag.
>
> [gabe.black] cpu: Stop excluding the protobuf tracer for x86.
>
> [gabe.black] mem: Stop using SlavePort as a base class.
>
> [gabe.black] base,arch-arm: Replace Stats namespace with statistics.
>
> [gabe.black] arch-power: Replace the Loader namespace with loader.
>
> [mattdsinclair] tests: fix LULESH weekly regression command
>
> [mattdsinclair] tests: add additional space in weekly DNNMark tests
>
> [msamani] cpu: Adding GUPSGen ClockedObject.
>
> [Bobby R. Bruce] tests: Fix the nightly GPU tests
>
> [gabe.black] mem: Replace SatCounter with SatCounter8 in the SHiP
> replacement policy.
>
> [mattdsinclair] tests: convert all nightly GPU tests from GUID to GID
>
> [gabe.black] scons: Don't explicitly list include dependencies for the cxx
> config.
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> The recommended git tool is: NONE
> No credentials specified
>  > git rev-parse --resolve-git-dir <
> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> Checking out Revision bad6fa679d8d6e22872b69e6008c0d14474e8d13
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f bad6fa679d8d6e22872b69e6008c0d14474e8d13 # timeout=10
> Commit message: "scons: Don't explicitly list include dependencies for the
> cxx config."
>  > git rev-list --no-walk 058e4699d8bf4ae78b94de245e3cefe72e7bc702 #
> timeout=10
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins17961737912055094198.sh
> + ./tests/compiler-tests.sh -j 24
> Starting build tests with 'gcc-version-11'...
> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'POWER.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'Garnet_standalone.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'Garnet_standalone.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'GCN3_X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'GCN3_X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'SPARC.opt' with 'gcc-version-11'...
>   ! Failed with exit code 2.
>   * Building target 'SPARC.fast' with 'gcc-version-11'...
>   ! Failed with exit code 2.
>   * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.fast' with 

[gem5-dev] Re: Build failed in Jenkins: nightly #10

[Bobby Bruce via gem5-dev]

In fairness, I think the tests should ideally pass regardless as to where
they are executed from, but that's not a priority right now :).

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Oct 13, 2021 at 11:19 AM Matt Sinclair 
wrote:

> Thanks Bobby!  Good to know for future reference.  I suspect I need to
> update the weekly tests accordingly too.
>
> Matt
>
> On Wed, Oct 13, 2021 at 1:15 PM Bobby Bruce  wrote:
>
>> Fix for the nightly tests here:
>> https://gem5-review.googlesource.com/c/public/gem5/+/51607
>>
>> I've verified this fixes the issue.
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Wed, Oct 13, 2021 at 10:50 AM Bobby Bruce  wrote:
>>
>>> Ah, yeah, that's probably the problem. For clarity, all the nightly
>>> tests do is run `./tests/nightly.sh 16` from the gem5 root. Likewise, all
>>> the weekly tests do is run `./tests/weekly.sh 16` from the gem5 root. If
>>> you can update the tests with this assumption in mind, they should pass.
>>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Wed, Oct 13, 2021 at 10:36 AM Matt Sinclair via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 (Resending as my prior email bounced)

 Matt

 On Wed, Oct 13, 2021 at 10:21 AM Matt Sinclair 
 wrote:

> I believe the weekly tests will fail until this is merged in:
> https://gem5-review.googlesource.com/c/public/gem5/+/51207
>
> Jason, I will follow-up with Kyle today about the additional change
> you requested last night on 51207.
>
> Regarding the nightly tests, where is the test being run from?  I
> tested that everything works correctly on my machine, but I'm running from
> the GEM5_ROOT/tests/ folder.  Looking at the error:
>
> *06:03:29* + wget -qN 
> http://dist.gem5.org/dist/develop/test-progs/square/square*06:03:31* + 
> mkdir -p tests/testing-results*06:03:31* + docker run --rm -u 118: 
> --volume 
> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>  -w /nobackup/jenkins/workspace/nightly/tests/.. 
> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt 
> configs/example/apu_se.py -n3 
> --benchmark-root=/nobackup/jenkins/workspace/nightly/tests/../tests -c 
> square*06:03:31* *fatal: square not found in 
> ['/nobackup/jenkins/workspace/nightly/tests/../tests']*
>
> It seems like you must be assuming a different folder?  I can
> definitely update the nightly tests to fix this, but need to understand
> where the test is being run from first, since things are working for me
> locally with the aforementioned assumption.
>
> Matt
>
> On Wed, Oct 13, 2021 at 9:30 AM Jason Lowe-Power via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> Looks like the failure is in the GPU tests (note: the weekly tests
>> are also failing due to GPU errors).
>>
>> https://jenkins.gem5.org/job/nightly/10/console
>>
>> On Wed, Oct 13, 2021 at 4:03 AM jenkins-no-reply--- via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> See <
>>> https://jenkins.gem5.org/job/nightly/10/display/redirect?page=changes
>>> >
>>>
>>> Changes:
>>>
>>> [quentin.forcioli] dev-arm: Added trusted DRAM to vexpress Realview
>>>
>>> [giacomo.travaglini] sim-se: Rewrite some syscalls to use a
>>> syscallImpl function
>>>
>>> [giacomo.travaglini] sim-se: Implement at suffixed syscalls
>>>
>>> [giacomo.travaglini] arch-arm: Add existing at impl to ArmLinux32
>>> Syscall Table
>>>
>>> [giacomo.travaglini] sim-se: Implemnt fchownat syscall
>>>
>>> [giacomo.travaglini] arch-arm: Add fchown implementation to the
>>> Syscall Table
>>>
>>> [giacomo.travaglini] arch-arm: Add fchownat implementation to the
>>> Syscall Table
>>>
>>> [mattdsinclair] dev-hsa,gpu-compute: fix bug with gfx8 VAs for HSA
>>> Queues
>>>
>>> [mattdsinclair] tests: fix square and HeteroSync nightly regression
>>> command
>>>
>>> [giacomo.travaglini] mem-ruby: HTMSequencer stats initialized twice
>>>
>>> [gabe.black] scons: Pull the code which generates debug/flags.cc
>>> into a helper script.
>>>
>>> [gabe.black] scons: Rearrange functions to be next to the code that
>>> uses them.
>>>
>>> [Bobby R. Bruce] tests: Fix argparse description in
>>> simple_binary_run.py
>>>
>>> [mail] python: Fix L1 data cache size in cache components
>>>
>>>
>>> --
>>> [...truncated 847.41 KB...]
>>>  [ CXX] GCN3_X86/python/_m5/param_PciMemBar.cc -> .o
>>>  [ CXX] 

[gem5-dev] Re: Build failed in Jenkins: nightly #10

[Bobby Bruce via gem5-dev]

Fix for the nightly tests here:
https://gem5-review.googlesource.com/c/public/gem5/+/51607

I've verified this fixes the issue.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Oct 13, 2021 at 10:50 AM Bobby Bruce  wrote:

> Ah, yeah, that's probably the problem. For clarity, all the nightly tests
> do is run `./tests/nightly.sh 16` from the gem5 root. Likewise, all the
> weekly tests do is run `./tests/weekly.sh 16` from the gem5 root. If you
> can update the tests with this assumption in mind, they should pass.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Oct 13, 2021 at 10:36 AM Matt Sinclair via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> (Resending as my prior email bounced)
>>
>> Matt
>>
>> On Wed, Oct 13, 2021 at 10:21 AM Matt Sinclair 
>> wrote:
>>
>>> I believe the weekly tests will fail until this is merged in:
>>> https://gem5-review.googlesource.com/c/public/gem5/+/51207
>>>
>>> Jason, I will follow-up with Kyle today about the additional change you
>>> requested last night on 51207.
>>>
>>> Regarding the nightly tests, where is the test being run from?  I tested
>>> that everything works correctly on my machine, but I'm running from the
>>> GEM5_ROOT/tests/ folder.  Looking at the error:
>>>
>>> *06:03:29* + wget -qN 
>>> http://dist.gem5.org/dist/develop/test-progs/square/square*06:03:31* + 
>>> mkdir -p tests/testing-results*06:03:31* + docker run --rm -u 118: --volume 
>>> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>>>  -w /nobackup/jenkins/workspace/nightly/tests/.. 
>>> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt 
>>> configs/example/apu_se.py -n3 
>>> --benchmark-root=/nobackup/jenkins/workspace/nightly/tests/../tests -c 
>>> square*06:03:31* *fatal: square not found in 
>>> ['/nobackup/jenkins/workspace/nightly/tests/../tests']*
>>>
>>> It seems like you must be assuming a different folder?  I can definitely
>>> update the nightly tests to fix this, but need to understand where the test
>>> is being run from first, since things are working for me locally with the
>>> aforementioned assumption.
>>>
>>> Matt
>>>
>>> On Wed, Oct 13, 2021 at 9:30 AM Jason Lowe-Power via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 Looks like the failure is in the GPU tests (note: the weekly tests are
 also failing due to GPU errors).

 https://jenkins.gem5.org/job/nightly/10/console

 On Wed, Oct 13, 2021 at 4:03 AM jenkins-no-reply--- via gem5-dev <
 gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/10/display/redirect?page=changes>
>
> Changes:
>
> [quentin.forcioli] dev-arm: Added trusted DRAM to vexpress Realview
>
> [giacomo.travaglini] sim-se: Rewrite some syscalls to use a
> syscallImpl function
>
> [giacomo.travaglini] sim-se: Implement at suffixed syscalls
>
> [giacomo.travaglini] arch-arm: Add existing at impl to ArmLinux32
> Syscall Table
>
> [giacomo.travaglini] sim-se: Implemnt fchownat syscall
>
> [giacomo.travaglini] arch-arm: Add fchown implementation to the
> Syscall Table
>
> [giacomo.travaglini] arch-arm: Add fchownat implementation to the
> Syscall Table
>
> [mattdsinclair] dev-hsa,gpu-compute: fix bug with gfx8 VAs for HSA
> Queues
>
> [mattdsinclair] tests: fix square and HeteroSync nightly regression
> command
>
> [giacomo.travaglini] mem-ruby: HTMSequencer stats initialized twice
>
> [gabe.black] scons: Pull the code which generates debug/flags.cc into
> a helper script.
>
> [gabe.black] scons: Rearrange functions to be next to the code that
> uses them.
>
> [Bobby R. Bruce] tests: Fix argparse description in
> simple_binary_run.py
>
> [mail] python: Fix L1 data cache size in cache components
>
>
> --
> [...truncated 847.41 KB...]
>  [ CXX] GCN3_X86/python/_m5/param_PciMemBar.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PciMemUpperBar.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PciVirtIO.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PerfectCompressor.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PioDevice.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_Platform.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PoolManager.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerDomain.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerModel.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerModelState.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_PowerState.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_ProbeListenerObject.cc -> .o
>  [ CXX] GCN3_X86/python/_m5/param_Process.cc -> .o
>  [ CXX] 

[gem5-dev] Re: Build failed in Jenkins: nightly #10

[Bobby Bruce via gem5-dev]

Ah, yeah, that's probably the problem. For clarity, all the nightly tests
do is run `./tests/nightly.sh 16` from the gem5 root. Likewise, all the
weekly tests do is run `./tests/weekly.sh 16` from the gem5 root. If you
can update the tests with this assumption in mind, they should pass.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Oct 13, 2021 at 10:36 AM Matt Sinclair via gem5-dev <
gem5-dev@gem5.org> wrote:

> (Resending as my prior email bounced)
>
> Matt
>
> On Wed, Oct 13, 2021 at 10:21 AM Matt Sinclair 
> wrote:
>
>> I believe the weekly tests will fail until this is merged in:
>> https://gem5-review.googlesource.com/c/public/gem5/+/51207
>>
>> Jason, I will follow-up with Kyle today about the additional change you
>> requested last night on 51207.
>>
>> Regarding the nightly tests, where is the test being run from?  I tested
>> that everything works correctly on my machine, but I'm running from the
>> GEM5_ROOT/tests/ folder.  Looking at the error:
>>
>> *06:03:29* + wget -qN 
>> http://dist.gem5.org/dist/develop/test-progs/square/square*06:03:31* + mkdir 
>> -p tests/testing-results*06:03:31* + docker run --rm -u 118: --volume 
>> /nobackup/jenkins/workspace/nightly/tests/..:/nobackup/jenkins/workspace/nightly/tests/..
>>  -w /nobackup/jenkins/workspace/nightly/tests/.. 
>> gcr.io/gem5-test/gcn-gpu:latest build/GCN3_X86/gem5.opt 
>> configs/example/apu_se.py -n3 
>> --benchmark-root=/nobackup/jenkins/workspace/nightly/tests/../tests -c 
>> square*06:03:31* *fatal: square not found in 
>> ['/nobackup/jenkins/workspace/nightly/tests/../tests']*
>>
>> It seems like you must be assuming a different folder?  I can definitely
>> update the nightly tests to fix this, but need to understand where the test
>> is being run from first, since things are working for me locally with the
>> aforementioned assumption.
>>
>> Matt
>>
>> On Wed, Oct 13, 2021 at 9:30 AM Jason Lowe-Power via gem5-dev <
>> gem5-dev@gem5.org> wrote:
>>
>>> Looks like the failure is in the GPU tests (note: the weekly tests are
>>> also failing due to GPU errors).
>>>
>>> https://jenkins.gem5.org/job/nightly/10/console
>>>
>>> On Wed, Oct 13, 2021 at 4:03 AM jenkins-no-reply--- via gem5-dev <
>>> gem5-dev@gem5.org> wrote:
>>>
 See <
 https://jenkins.gem5.org/job/nightly/10/display/redirect?page=changes>

 Changes:

 [quentin.forcioli] dev-arm: Added trusted DRAM to vexpress Realview

 [giacomo.travaglini] sim-se: Rewrite some syscalls to use a syscallImpl
 function

 [giacomo.travaglini] sim-se: Implement at suffixed syscalls

 [giacomo.travaglini] arch-arm: Add existing at impl to ArmLinux32
 Syscall Table

 [giacomo.travaglini] sim-se: Implemnt fchownat syscall

 [giacomo.travaglini] arch-arm: Add fchown implementation to the Syscall
 Table

 [giacomo.travaglini] arch-arm: Add fchownat implementation to the
 Syscall Table

 [mattdsinclair] dev-hsa,gpu-compute: fix bug with gfx8 VAs for HSA
 Queues

 [mattdsinclair] tests: fix square and HeteroSync nightly regression
 command

 [giacomo.travaglini] mem-ruby: HTMSequencer stats initialized twice

 [gabe.black] scons: Pull the code which generates debug/flags.cc into a
 helper script.

 [gabe.black] scons: Rearrange functions to be next to the code that
 uses them.

 [Bobby R. Bruce] tests: Fix argparse description in simple_binary_run.py

 [mail] python: Fix L1 data cache size in cache components


 --
 [...truncated 847.41 KB...]
  [ CXX] GCN3_X86/python/_m5/param_PciMemBar.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PciMemUpperBar.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PciVirtIO.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PerfectCompressor.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PioDevice.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_Platform.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PoolManager.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PowerDomain.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PowerModel.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PowerModelState.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PowerState.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_ProbeListenerObject.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_Process.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_ProtocolTester.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_PyTrafficGen.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_QoSFixedPriorityPolicy.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_QoSMemCtrl.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_QoSMemSinkCtrl.cc -> .o
  [ CXX] GCN3_X86/python/_m5/param_QoSMemSinkInterface.cc -> .o
  [ CXX] 

[gem5-dev] Jenkins' server moved; https://jenkins.gem5.org now live

[Bobby Bruce via gem5-dev]

Dear all,

Our gem5 Jenkins' server has finally found a permanent home at the
University of Wisconsin. Prior to this we were hosting here at UC Davis,
but this came with restrictions on what we could expose to the wider world
(i.e., no website).

As such, the https://jenkins.gem5.org/ web portal is now live. You can now
jump in and see the status of the gem5 tests and other jobs we run. Emails
to the gem5 dev mailing list will continue to be sent if the compiler,
nightly, or weekly tests fail.

A special thank you to those at the University of Wisconsin for helping us
set up this service.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #211

[Bobby Bruce via gem5-dev]

I can't recreate this error locally. It seems like it's just a hiccup with
our Jenkins server. I suspect it'll run correctly tonight.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Oct 6, 2021 at 12:00 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/211/display/redirect?page=changes
> >
>
> Changes:
>
> [matthew.poremba] arch-vega: Rework flat instructions to support global
>
> [matthew.poremba] misc: Add VEGA_X86 build_opt
>
> [matthew.poremba] arch-gcn3,gpu-compute: Move GCN3 specific TLB to arch
>
> [gabe.black] scons: Pull makeDebugFlagHH into build_tools.
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> Selected Git installation does not exist. Using Default
> The recommended git tool is: NONE
> No credentials specified
>  > git rev-parse --resolve-git-dir <
> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> Checking out Revision 74c629745315022dbebb08db260b057a6d14bc5f
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f 74c629745315022dbebb08db260b057a6d14bc5f # timeout=10
> Commit message: "scons: Pull makeDebugFlagHH into build_tools."
>  > git rev-list --no-walk 2b86278a86d9451b67b76833e1137d5ae90739aa #
> timeout=10
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins3117333448856628.sh
> + ./tests/compiler-tests.sh -j 12
> Starting build tests with 'gcc-version-11'...
> 'gcc-version-11' was found in the comprehensive tests. All ISAs will be
> built.
>   * Building target 'GCN3_X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'GCN3_X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'MIPS.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MESI_Two_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MESI_Two_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MESI_Two_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level_HTM.fast' with
> 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'ARM_MESI_Three_Level.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'POWER.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'X86_MOESI_AMD_Base.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_directory.fast' with
> 'gcc-version-11'...
> Done.
>   * Building target 'Garnet_standalone.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'Garnet_standalone.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'SPARC.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'SPARC.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_token.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_CMP_token.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.opt' with 'gcc-version-11'...
> Done.
>   * Building target 'NULL_MOESI_hammer.fast' with 'gcc-version-11'...
> Done.
>   * Building target 'RISCV.opt' with 'gcc-version-11'...
> Done.
>   * 

[gem5-dev] Re: replacement for x86-boot-tests/run_exit.py?

[Bobby Bruce via gem5-dev]

Hey Gabe:

Try `tests/gem5/configs/x86_boot_exit_run.py`:
https://gem5.googlesource.com/public/gem5/+/refs/heads/develop/tests/gem5/configs/x86_boot_exit_run.py.


It should function similarly to the old `run_exit.py` but you don't need to
specify the disk and the kernel.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Sep 30, 2021 at 6:15 PM Gabe Black via gem5-dev 
wrote:

> Hi folks, particularly Bobby. I was using the x86-boot-tests/run_exit.py
> configuration to run a fairly quick and easy x86 boot to measure gem5
> performance, but that script seems to have gone away in the last week or
> two.
>
> What is the replacement for it? I need something I can use to do a
> reasonably representative task in gem5 which I can time to measure
> simulator performance. I used to be able to do that with this command:
>
> time ./build/X86/gem5.opt ./tests/gem5/x86-boot-tests/run_exit.py --kernel
> ../boot-test/vmlinux-4.19.83 --disk ../boot-test/base.img --cpu-type atomic
> --num-cpus 1 --boot-type init
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: failing ARM dual CPU tests?

[Bobby Bruce via gem5-dev]

Hey Gabe,

This is very strange and I can't say I've seen this issue before. The
problem shouldn't be docker, none of these tests spin up an instance. I was
going to suggest deleting the resources (`tests/gem5/resources`) and trying
again, but it seems like you've tried that. My only sensible guess at this
point is your not downloading the resources needed (network issues?), as,
unfortunately, the TestLib downloader fails silently (e.g. if the download
fails it tends to continue to try to run the test). Though if this is the
case. it'd be weird to just see these tests failing as we download quite a
few things to get testing working.

Have you looked into the output under `tests/testing-results` to see what's
printing to stdout/stderr for these tests? Do you notice anything unusual
there?

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Sep 22, 2021 at 5:23 PM Gabe Black  wrote:

> Thanks Giacomo, I *think* since these are running as part of the testing
> infrastructure that they are downloading the files they need, and I hope
> they are downloading current ones. Clearly *something* is out of whack, but
> since this should all be handled automatically I don't know where or what
> to look at to try to find what's out of date. I know once upon a time I had
> an out of date docker that was causing problems, but I'm not using a docker
> for this and so I don't think that's the problem(?).
>
> Do you have any ideas Bobby? I've tried deleting the resources directory
> it downloads under tests, but that didn't seem to fix it.
>
> Gabe
>
> On Wed, Sep 22, 2021 at 9:17 AM Giacomo Travaglini <
> giacomo.travagl...@arm.com> wrote:
>
>> Hi Gabe,
>>
>> From an Arm perspective, could you make sure you are using the latest
>> bootloader?
>> I remember there was a change some time ago which required the bootloader
>> to be rebuilt
>>
>> You could either download latest tarball from
>> https://www.gem5.org/documentation/general_docs/fullsystem/guest_binaries
>>
>> Or rebuild the bootloader yourself
>>
>> Kind Regards
>>
>> Giacomo
>>
>>
>> > -Original Message-
>> > From: Jason Lowe-Power via gem5-dev 
>> > Sent: 22 September 2021 17:12
>> > To: gem5 Developer List 
>> > Cc: Gabe Black ; Jason Lowe-Power
>> > 
>> > Subject: [gem5-dev] Re: failing ARM dual CPU tests?
>> >
>> > Hey Gabe,
>> >
>> >
>> > To solve this and the x86 test issue you've been having, I think there
>> are a
>> > couple of possibilities:
>> >
>> > 1. Can you use the docker images that kokoro uses? This will guarantee
>> that
>> > you are using the *exact* same "host" setup when running gem5. I think
>> this
>> > is the only way to have a consistent set of tests without something like
>> > Bazel's reproducible build and test.
>> > 2. We're open to modifying and improving the tests. If the tests don't
>> work
>> > for you, they probably don't work for others as well. Improving the
>> > documentation so it's more clear how to use the tests or improving the
>> > testing infrastructure or modifying the tests so that they work more
>> easily for
>> > more people would be a *very* welcome contribution.
>> >
>> > Cheers,
>> > Jason
>> >
>> > On Tue, Sep 21, 2021 at 6:22 PM Gabe Black via gem5-dev > > d...@gem5.org  > wrote:
>> >
>> >
>> >   Hi folks. When I run the test script main.py locally on an
>> otherwise
>> > passing tree, I get 8 test failures. 6 of those are from x86 dynamic
>> linking tests
>> > which use a host library which uses a system call gem5 doesn't
>> implement.
>> > That is annoying, but I understand that problem.
>> >
>> >   The other 2 are from ARM dual CPU tests (like realview64-simple-
>> > timing-dual-ARM-x86_64-opt-MatchFileRegex) which fail because the
>> > second CPU doesn't come up, and the check doesn't see the message it
>> > expects.
>> >
>> >   This is very surprising to me, since I don't think these tests
>> would
>> > have any host dependence, and I'm *pretty* sure that the files they use
>> > would come from the resources thing and should be up to date, etc. The
>> > system in the test seems to otherwise boot up, it's just that the
>> second CPU
>> > never comes online and linux prints an error message about it instead
>> of the
>> > normal one.
>> >
>> >   Does anybody know of something else I can try to update, etc,
>> which
>> > might fix these tests? Could there be stale system files it's using
>> floating
>> > around somewhere?
>> >
>> >   I would really like to get that sorted out, since that could
>> affect
>> > whether I can successfully test my locked memory helper function change,
>> > since the earlier version of that had caused problems with O3 multi-CPU
>> tests
>> > for ARM, sort of right in line with this false positive on these tests.
>> >
>> >   Thanks!
>> >   Gabe
>> >   ___
>> >   gem5-dev mailing list -- 

[gem5-dev] Re: Build failed in Jenkins: compiler-checks #197

[Bobby Bruce via gem5-dev]

My bad, fix here: https://gem5-review.googlesource.com/c/public/gem5/+/50829
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Sep 22, 2021 at 3:21 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/compiler-checks/197/display/redirect?page=changes
> >
>
> Changes:
>
> [Bobby R. Bruce] util-docker: Add a GCC-11 Dockerfile
>
> [Bobby R. Bruce] tests: Add GCC-11 to the compiler tests
>
> [mail] tests: Fix gem5 resources import in parsec test
>
> [odanrc] arch-arm: Fix memory leak of PMU events
>
> [odanrc] sim,tests: Add unit test for sim/serialize_handlers
>
> [odanrc] sim,tests: Add unit test for sim/serialize.hh
>
> [Giacomo Travaglini] arch-arm: Remove SPSR write mask
>
> [Giacomo Travaglini] arch-arm: Implement Armv8.2 FEAT_UAO
>
> [Giacomo Travaglini] arch-arm: SCTLR.WXN not used in S2AP
>
> [odanrc] base,tests: Add unit test for SymbolTable
>
> [Bobby R. Bruce] tests: Add KVM CPU switch tests
>
> [Bobby R. Bruce] tests: Update x86 boot tests to use x86-ubuntu-img
>
>
> --
> Started by timer
> Running as SYSTEM
> Building in workspace 
> Selected Git installation does not exist. Using Default
> The recommended git tool is: NONE
> No credentials specified
>  > git rev-parse --resolve-git-dir <
> https://jenkins.gem5.org/job/compiler-checks/ws/.git> # timeout=10
> Fetching changes from the remote Git repository
>  > git config remote.origin.url https://gem5.googlesource.com/public/gem5
> # timeout=10
> Fetching upstream changes from https://gem5.googlesource.com/public/gem5
>  > git --version # timeout=10
>  > git --version # 'git version 2.25.1'
>  > git fetch --tags --force --progress --
> https://gem5.googlesource.com/public/gem5
> +refs/heads/*:refs/remotes/origin/* # timeout=10
>  > git rev-parse refs/remotes/origin/develop^{commit} # timeout=10
> Checking out Revision c10982e4419491e303a52451cc38597ec36cbe54
> (refs/remotes/origin/develop)
>  > git config core.sparsecheckout # timeout=10
>  > git checkout -f c10982e4419491e303a52451cc38597ec36cbe54 # timeout=10
> Commit message: "tests: Update x86 boot tests to use x86-ubuntu-img"
>  > git rev-list --no-walk 6e23be069378439cf0531fcbed918f9bd1650115 #
> timeout=10
> [compiler-checks] $ /bin/sh -xe /tmp/jenkins18068570140143768162.sh
> + ./tests/compiler-tests.sh -j 12
> ./tests/compiler-tests.sh: line 34: syntax error near unexpected token `)'
> ./tests/compiler-tests.sh: line 34: `   "clang-version-11")'
> Build step 'Execute shell' marked build as failure
> Archiving artifacts
> ___
> gem5-dev mailing list -- gem5-dev@gem5.org
> To unsubscribe send an email to gem5-dev-le...@gem5.org
> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] gem5 v21.1.0.2 hotfix release: Fix Vector statistics

[Bobby Bruce via gem5-dev]

Dear all,

The stable branch of the gem5 repository now contains the v21.1.0.2 hotfix
release. This release fixes a bug which was causing some vector statistics
in gem5 to break. We encourage gem5 users to pull the latest version of
gem5 from the repo's stable branch.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #440

[Bobby Bruce via gem5-dev]

Fix here: https://gem5-review.googlesource.com/c/public/gem5/+/50128

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Wed, Sep 8, 2021 at 4:52 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/440/display/redirect?page=changes>
>
> Changes:
>
> [Bobby R. Bruce] python: Add MI_Example cache hierarchy to the components
> lib
>
> [Bobby R. Bruce] python,configs: Add Resource class to gem5 components
>
> [Bobby R. Bruce] python: Add a PrivateL1CacheHierarchy to the gem5
> components
>
> [Bobby R. Bruce] python: Add optional 'kernel_args' to x86's `set_workload`
>
> [Bobby R. Bruce] python: Update boot_exit_disk_run.py for testing
>
> [Bobby R. Bruce] python: Run Black on configs/example/components-library
>
> [Bobby R. Bruce] python: Add `requires` to gem5 components lib
>
> [Bobby R. Bruce] ext,tests: Add 'very-long' tag for test length
>
> [Bobby R. Bruce] configs,python: Update components library to support KVM
>
> [Bobby R. Bruce] tests: Update the x86-boot-tests to use
> boot_exit_disk_run.py
>
> [Bobby R. Bruce] configs: Update the parsec_disk_run.py for testing
>
> [Bobby R. Bruce] configs: Fix AbstractGeneratorCore connect_interrupt sig
>
> [Bobby R. Bruce] configs: Fix SimpleCore for connect_interrupt() case
>
> [Bobby R. Bruce] tests: Add PARSEC tests
>
> [Bobby R. Bruce] learning-gem5,tests: Move Learning gem5 Part 3 to run
> nightly
>
>
> --
> [...truncated 684.86 KB...]
>   | ^
> In file included from build/GCN3_X86/sim/init.hh:44,
>  from build/GCN3_X86/sim/init.cc:44:
> ext/pybind11/include/pybind11/pybind11.h:947:14: note: declared here
>   947 | explicit module_(const char *name, const char *doc = nullptr) {
>   |  ^~~
> MESI_Two_Level-L1cache.sm:246: Warning: Non-void return ignored, return
> type is 'bool'
> MESI_Two_Level-L1cache.sm:248: Warning: Non-void return ignored, return
> type is 'bool'
> MESI_Two_Level-L1cache.sm:887: Warning: Non-void return ignored, return
> type is 'Tick'
> MESI_Two_Level-L1cache.sm:999: Warning: Non-void return ignored, return
> type is 'Tick'
> MESI_Two_Level-L1cache.sm:740: Warning: Unused action:
> e_sendAckToRequestor, send invalidate ack to requestor (could be L2 or L1)
> MESI_Two_Level-L2cache.sm:235: Warning: Non-void return ignored, return
> type is 'bool'
> MESI_Two_Level-L2cache.sm:237: Warning: Non-void return ignored, return
> type is 'bool'
> MESI_Two_Level-L2cache.sm:594: Warning: Unused action:
> fw_sendFwdInvToSharers, invalidate sharers for request
> MESI_Two_Level-L2cache.sm:764: Warning: Unused action:
> kk_removeRequestSharer, Remove L1 Request sharer from list
> MESI_Two_Level-L2cache.sm:780: Warning: Unused action: mm_markExclusive,
> set the exclusive owner
> Running the new gem5 testing script.
> For more information see TESTING.md.
> To see details as the testing scripts are running, use the option -v, -vv,
> or -vvv
>
> 
> Loading Tests
> Discovered 2856 tests and 2856 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/asmtest/tests.py>
> Discovered 264 tests and 132 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/cpu_tests/test.py>
> Discovered 24 tests and 12 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/dram-lowp/test_dram_lowp.py
> >
> Discovered 192 tests and 162 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/fs/linux/arm/test.py>
> Discovered 270 tests and 135 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/hello_se/test_hello_se.py
> >
> Discovered 24 tests and 12 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/insttest_se/test.py>
> Discovered 36 tests and 36 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/learning_gem5/part1_test.py
> >
> Discovered 48 tests and 24 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/learning_gem5/part2_test.py
> >
> Discovered 18 tests and 9 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/learning_gem5/part3_test.py
> >
> Discovered 12 tests and 6 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/m5_util/test_exit.py>
> Discovered 0 tests and 0 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/m5threads_test_atomic/test.py
> >
> Discovered 72 tests and 72 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/memory/test.py>
> Discovered 0 tests and 0 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/parsec-benchmarks/test_parsec.py
> >
> Discovered 18 tests and 6 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/stats/test_hdf5.py>
> Discovered 21 tests and 21 suites in <
> https://jenkins.gem5.org/job/nightly/ws/tests/gem5/test_build/test_build.py
> >
> 

[gem5-dev] gem5 v21.1.0.1 hotfix release: Fix for 'deprecated attribute' warning

[Bobby Bruce via gem5-dev]

Dear all,

The stable branch of the gem5 repository now contains the v21.1.0.1 hotfix
release. This release fixes a bug where the build output was being flooded
with "'deprecated' attribute directive ignored" warnings, as reported here:
https://gem5.atlassian.net/browse/GEM5-1063. While this bug never broke the
gem5 build, it was making reading the build output hard and was causing
confusion.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] v21.1.0.1 hotfix: Fix for 'deprecated attribute' warning

[Bobby Bruce via gem5-dev]

Dear all,

As some you building on the stable branch may have noticed, there's an
annoying bug where the build output is flooded with " 'deprecated'
attribute directive ignored" warnings (Jira ticket here:
https://gem5.atlassian.net/browse/GEM5-1063). While this doesn't break the
build, it is annoying and I've received a few complaints about it since our
v21.1 release. As such I'm going to push a hotfix to rectify this.

The hotfix relation chain can be found here:
https://gem5-review.googlesource.com/c/public/gem5/+/50031

I think this is pretty uncontroversial, so I hope to get it in ASAP, but
I'll wait a day for a proper review.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-dev] Re: Build failed in Jenkins: nightly #434

[Bobby Bruce via gem5-dev]

Hey all,

The nightly builds are failing because of this commit:
https://gem5-review.googlesource.com/c/public/gem5/+/48384. It's causing
simulations to stall when running the O3 CPU on ARM. I've reverted this
commit here: https://gem5-review.googlesource.com/c/public/gem5/+/49927. It
seems like I'm not the only person to notice this bug given the ongoing
discussions in the patch comments.

It'd be good if a "proper fix" for this bug could be made, but I don't know
exactly how to do this. I think fixing the build is a higher priority for
me right now. I'll wait until Monday to submit the revert.

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Sep 2, 2021 at 11:59 PM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/434/display/redirect?page=changes>
>
> Changes:
>
> [yuhsingw] arch-arm: add size check for AdvSIMD copy
>
>
> --
> [...truncated 673.73 KB...]
> [ RUN  ] ProxyPtr.Clean
> [   OK ] ProxyPtr.Clean (0 ms)
> [ RUN  ] ProxyPtr.Dirty
> [   OK ] ProxyPtr.Dirty (0 ms)
> [ RUN  ] ProxyPtr.LoadAndFlush
> [   OK ] ProxyPtr.LoadAndFlush (0 ms)
> [ RUN  ] ProxyPtr.ConstOperators
> [   OK ] ProxyPtr.ConstOperators (1 ms)
> [ RUN  ] ProxyPtr.NonConstOperators
> [   OK ] ProxyPtr.NonConstOperators (0 ms)
> [--] 5 tests from ProxyPtr (1 ms total)
>
> [--] 1 test from ProxyPtrTest
> [ RUN  ] ProxyPtrTest.GuestABI
> [   OK ] ProxyPtrTest.GuestABI (0 ms)
> [--] 1 test from ProxyPtrTest (0 ms total)
>
> [--] Global test environment tear-down
> [==] 6 tests from 2 test suites ran. (1 ms total)
> [  PASSED  ] 6 tests.
> [   OK ] LoggingDeathTest.InfoLoggerExitHelper (136 ms)
> [ RUN  ] LoggingDeathTest.HackLoggerExitHelper
> [   OK ] UncontendedMutex.Lock (200 ms)
> [ RUN  ] UncontendedMutex.HeavyContention
> [   OK ] UncontendedMutex.HeavyContention (35 ms)
> [--] 2 tests from UncontendedMutex (235 ms total)
>
> [--] Global test environment tear-down
> [==] 2 tests from 1 test suite ran. (235 ms total)
> [  PASSED  ] 2 tests.
> [   OK ] LoggingDeathTest.HackLoggerExitHelper (139 ms)
> [ RUN  ] LoggingDeathTest.FatalLoggerExitHelper
> [   OK ] LoggingDeathTest.FatalLoggerExitHelper (1 ms)
> [ RUN  ] LoggingDeathTest.PanicLoggerExitHelper
> [   OK ] LoggingDeathTest.PanicLoggerExitHelper (133 ms)
> [ RUN  ] LoggingDeathTest.ExitMessage
> [   OK ] LoggingDeathTest.ExitMessage (134 ms)
> [ RUN  ] LoggingDeathTest.Panic
> [   OK ] LoggingDeathTest.Panic (134 ms)
> [ RUN  ] LoggingDeathTest.Fatal
> [   OK ] LoggingDeathTest.Fatal (1 ms)
> [ RUN  ] LoggingDeathTest.PanicIf
> [   OK ] LoggingDeathTest.PanicIf (136 ms)
> [ RUN  ] LoggingDeathTest.FatalIf
> [   OK ] LoggingDeathTest.FatalIf (1 ms)
> [ RUN  ] LoggingDeathTest.gem5Assert
> [  SKIPPED ] LoggingDeathTest.gem5Assert (0 ms)
> [--] 13 tests from LoggingDeathTest (1093 ms total)
>
> [--] 21 tests from LoggingFixture
> [ RUN  ] LoggingFixture.BasicPrint
> [   OK ] LoggingFixture.BasicPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharPrint
> [   OK ] LoggingFixture.VariadicCharPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringPrint
> [   OK ] LoggingFixture.VariadicStringPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicCharMissingPrint
> [   OK ] LoggingFixture.VariadicCharMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.VariadicStringMissingPrint
> [   OK ] LoggingFixture.VariadicStringMissingPrint (0 ms)
> [ RUN  ] LoggingFixture.DisabledPrint
> [   OK ] LoggingFixture.DisabledPrint (0 ms)
> [ RUN  ] LoggingFixture.WarnLoggerPrint
> [   OK ] LoggingFixture.WarnLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.InfoLoggerPrint
> [   OK ] LoggingFixture.InfoLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.HackLoggerPrint
> [   OK ] LoggingFixture.HackLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.FatalLoggerPrint
> [   OK ] LoggingFixture.FatalLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.PanicLoggerPrint
> [   OK ] LoggingFixture.PanicLoggerPrint (0 ms)
> [ RUN  ] LoggingFixture.BaseMessage
> [   OK ] LoggingFixture.BaseMessage (0 ms)
> [ RUN  ] LoggingFixture.BaseMessageOnce
> [   OK ] LoggingFixture.BaseMessageOnce (0 ms)
> [ RUN  ] LoggingFixture.Warn
> [   OK ] LoggingFixture.Warn (0 ms)
> [ RUN  ] LoggingFixture.Inform
> [   OK ] LoggingFixture.Inform (0 ms)
> [ RUN  ] LoggingFixture.Hack
> [   OK ] LoggingFixture.Hack (0 ms)
> [ RUN  ] LoggingFixture.WarnOnce
> [   OK ] LoggingFixture.WarnOnce (0 ms)
> [ RUN  ] LoggingFixture.InformOnce
> [   OK ] LoggingFixture.InformOnce (0 ms)
> [ RUN  ] LoggingFixture.HackOnce
> [   OK ] 

[gem5-dev] Re: Build failed in Jenkins: nightly #407

[Bobby Bruce via gem5-dev]

Fix for this can be found here:
https://gem5-review.googlesource.com/c/public/gem5/+/49065
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Aug 6, 2021 at 12:39 AM jenkins-no-reply--- via gem5-dev <
gem5-dev@gem5.org> wrote:

> See <
> https://jenkins.gem5.org/job/nightly/407/display/redirect?page=changes>
>
> Changes:
>
> [Giacomo Travaglini] arch: Implement operator& for TypeTLB
>
> [Giacomo Travaglini] arch-arm: Distinguish Instruction from Data TLB
> entries
>
> [Giacomo Travaglini] arch-arm: Explicitly implement I/DTLBI Ops in TLB
>
> [Giacomo Travaglini] arch-arm: Provide support for a multilevel-TLB in the
> ArmMMU
>
> [Giacomo Travaglini] arch-arm: Add a shared L2 TLB to the default ArmMMU
>
> [jan.vrany] base: Extract GDB command processing into separate function
>
> [jan.vrany] base: handle initial communication with GDB in `attach()`
>
> [gabe.black] arch,cpu: Rename RegClass to RegClassType.
>
> [gabe.black] scons: Make all Executables strip-able, and de-special case
> .fast.
>
> [gabe.black] scons: Get rid of the unused "dirname" property of SourceFile.
>
> [gabe.black] scons: Replace the extname property with os.path.splitext().
>
> [gabe.black] scons: Replace the SourceFile.filename property with
> attribute.
>
> [gabe.black] scons: Eliminate the SourceFile.basename property.
>
> [gabe.black] scons: Delete the comparison operators from SourceFile.
>
> [gabe.black] scons: Use the os.path prefix when using components of that
> module.
>
>
> --
> [...truncated 349.00 KB...]
> [==] 13 tests from 1 test suite ran. (0 ms total)
> [  PASSED  ] 13 tests.
> build/NULL/base/addr_range_map.test.perf
> --gtest_output=xml:build/NULL/unittests.perf/base/addr_range_map.test.xml
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 13 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 13 tests from AmoTest
> [ RUN  ] AmoTest.AtomicOpMin
> [   OK ] AmoTest.AtomicOpMin (0 ms)
> [ RUN  ] AmoTest.AtomicOpMax
> [   OK ] AmoTest.AtomicOpMax (0 ms)
> [ RUN  ] AmoTest.AtomicOpDec
> [   OK ] AmoTest.AtomicOpDec (0 ms)
> [ RUN  ] AmoTest.AtomicOpInc
> [   OK ] AmoTest.AtomicOpInc (0 ms)
> [ RUN  ] AmoTest.AtomicOpSub
> [   OK ] AmoTest.AtomicOpSub (0 ms)
> [ RUN  ] AmoTest.AtomicOpAdd
> [   OK ] AmoTest.AtomicOpAdd (0 ms)
> [ RUN  ] AmoTest.AtomicOpExch
> [   OK ] AmoTest.AtomicOpExch (0 ms)
> [ RUN  ] AmoTest.AtomicOpXor
> [   OK ] AmoTest.AtomicOpXor (0 ms)
> [ RUN  ] AmoTest.AtomicOpOr
> [   OK ] AmoTest.AtomicOpOr (0 ms)
> [ RUN  ] AmoTest.AtomicOpAnd
> [   OK ] AmoTest.AtomicOpAnd (0 ms)
> [ RUN  ] AmoTest.AtomicGeneric2Op
> [   OK ] AmoTest.AtomicGeneric2Op (0 ms)
> [ RUN  ] AmoTest.AtomicGeneric3Op
> [   OK ] AmoTest.AtomicGeneric3Op (0 ms)
> [ RUN  ] AmoTest.AtomicGenericPair3Op
> [   OK ] AmoTest.AtomicGenericPair3Op (0 ms)
> [--] 13 tests from AmoTest (0 ms total)
>
> [--] Global test environment tear-down
> [==] 13 tests from 1 test suite ran. (0 ms total)
> [  PASSED  ] 13 tests.
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 3 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 3 tests from AtomicioTest
> [ RUN  ] AtomicioTest.AtomicReadBigBuffer
> [   OK ] AtomicioTest.AtomicReadBigBuffer (0 ms)
> [ RUN  ] AtomicioTest.AtomicReadSmallBuffer
> [   OK ] AtomicioTest.AtomicReadSmallBuffer (0 ms)
> [ RUN  ] AtomicioTest.AtomicWrite
> [   OK ] AtomicioTest.AtomicWrite (0 ms)
> [--] 3 tests from AtomicioTest (0 ms total)
>
> [--] Global test environment tear-down
> [==] 3 tests from 1 test suite ran. (0 ms total)
> [  PASSED  ] 3 tests.
> build/NULL/base/addr_range.test.perf
> --gtest_output=xml:build/NULL/unittests.perf/base/addr_range.test.xml
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 3 tests from 1 test suite.
> [--] Global test environment set-up.
> [--] 3 tests from AddrRangeMapTest
> [ RUN  ] AddrRangeMapTest.LegacyTests
> [   OK ] AddrRangeMapTest.LegacyTests (0 ms)
> [ RUN  ] AddrRangeMapTest.InterleavedTest1
> [   OK ] AddrRangeMapTest.InterleavedTest1 (0 ms)
> [ RUN  ] AddrRangeMapTest.InterleavedTest2
> [   OK ] AddrRangeMapTest.InterleavedTest2 (0 ms)
> [--] 3 tests from AddrRangeMapTest (0 ms total)
>
> [--] Global test environment tear-down
> [==] 3 tests from 1 test suite ran. (0 ms total)
> [  PASSED  ] 3 tests.
> Running main() from build/googletest/googletest/src/gtest_main.cc
> [==] Running 66 tests from 2 test suites.
> [--] Global test environment set-up.
> [--] 1 test from AddrRangeDeathTest
> [ RUN  ] 

[gem5-dev] Re: kokoro failures due to bug in gem5-art?

[Bobby Bruce via gem5-dev]

The gem5art test fix has just been submitted. For problematic patchsets try
rebasing to the HEAD of develop. Let me know if you observe similar
failures when with fix is included.

--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Aug 5, 2021 at 10:27 PM Gabe Black via gem5-dev 
wrote:

> One more:
>
>
> https://source.cloud.google.com/results/invocations/8f6a185e-0258-4f9c-b573-e79d1a86a5a1/targets/gem5%2Fgcp_ubuntu%2Fpresubmit/log
>
> On Thu, Aug 5, 2021 at 3:02 PM Gabe Black  wrote:
>
>> Yeah, I wouldn't be surprised if it was specific to kokoro, or something
>> about how its networking is set up. Those failures seem to have stopped
>> happening now, or at least are happening much less. I don't remember seeing
>> one for a while at least. Hopefully we can avoid making our timeout any
>> longer! Thanks for looking into it, Bobby.
>>
>> Gabe
>>
>> On Thu, Aug 5, 2021 at 1:16 PM Bobby Bruce  wrote:
>>
>>> That theory could be true, and I certainly don't have any better ideas,
>>> though I've never observed any hang on my local machine when recreating
>>> this issue. It could be something specific to Kokoro.
>>>
>>> I've fixed the gem5art error here:
>>> https://gem5-review.googlesource.com/c/public/gem5/+/49044. We can see
>>> if this fixes the timeout issue. If the timeout error persists  we can
>>> consider increasing the timeout:
>>> https://gem5-review.googlesource.com/c/public/gem5/+/48443
>>>
>>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Thu, Jul 22, 2021 at 8:33 PM Gabe Black  wrote:
>>>
 Another possibility is that while the gem5-art error may not actually
 kill the run, it may, for instance, have failed trying to download
 something with a generous timeout, and waiting for that timeout pushed the
 rest of the run out enough to trip the timeout? Just a thought. I haven't
 checked exhaustively, but it feels like the timeout always goes along with
 the gem5-art error message.

 Gabe

 On Thu, Jul 22, 2021 at 5:27 PM Gabe Black 
 wrote:

> Ok, thanks. I don't know if you saw the CL I put up recently where the
> src/base/cprintftime.cc executable (the one built from that source) was
> broken, which made kokoro fail. The breakage was real and worth fixing, 
> but
> I'm not sure why kokoro was trying to build it in the first place? Maybe
> sometimes kokoro tries building things that we didn't really want it to.
>
> In my recent scons hacking, I ran into that accidentally when
> build/X86/${BLAHBLAH} expanded into build/X86/ because that variable 
> didn't
> exist, so scons went of and started building EVERYTHING it knew about 
> below
> build/X86/. Hypothetically, that could explain the long build times and 
> the
> building of that random other binary? Maybe we have some sort of race
> condition where a target expands to an empty string?
>
> Gabe
>
> On Thu, Jul 22, 2021 at 3:04 PM Bobby Bruce 
> wrote:
>
>> Ok, so I did look into this today and didn't find anything. On my
>> desktop machine the difference in running the pre-submit tests from the
>> stable branch and develop branch (including building the binaries) was 
>> only
>> 10 minutes so we've really not done anything to increase the build/test
>> times to a significant extent. My running theory is Kokoro was running
>> slower (??? I have no idea what Kokoro is actually doing or running on
>> behind the scenes so I don't know whether that makes sense, but I cannot
>> think of any other explanation). I don't like the solution, but I've
>> submitted a patch to increase the timeout to 7 hours which should stop 
>> this
>> timeout event from happening:
>> https://gem5-review.googlesource.com/c/public/gem5/+/48443
>>
>> I still haven't looked into the gem5 error yet but I'm pretty
>> confident this shouldn't interfere with the presubmit validation.
>>
>> --
>> Dr. Bobby R. Bruce
>> Room 3050,
>> Kemper Hall, UC Davis
>> Davis,
>> CA, 95616
>>
>> web: https://www.bobbybruce.net
>>
>>
>> On Wed, Jul 21, 2021 at 5:37 PM Gabe Black 
>> wrote:
>>
>>> Ok thanks, Bobby. Please let me know if you find
>>> anything, especially if it looks like it's a bug in kokoro itself 
>>> somehow.
>>>
>>> Gabe
>>>
>>> On Wed, Jul 21, 2021 at 3:52 PM Bobby Bruce 
>>> wrote:
>>>
 There's definitely something funny going on with the gem5art tests
 there but I believe that error is happening without triggering a 
 non-zero
 exit code. The gem5art test script is set to `set -e`, which means the
 script should exit immediately after a failure, yet it doesn't. The 
 testing

[gem5-dev] Re: python versions used by SCons and gem5

[Bobby Bruce via gem5-dev]

Hey Gabe,

Just so we're on the same page, I'd like to take a moment to outline how I
understand this problem/solution. Please let me know if I've understood
correctly:

We essentially have three components of the project which interpret gem5
Python code: The gem5 binary, the Marshal binary, and the Scons build
system. The gem5 and Marshal binaries both link to the Python library, so
we have no problems there; they should interpret things identically. The
problematic entity is Scons which will use the host python executable when
processing Simobjects et al. at compile time. Your solution is to offload
the relevant Scons gem5 Python interpretations/auto-generations to the
Marshal binary where they'll use the Python library. Is this correct?

If so, I support this move as it makes things considerably easier to work
with. While there is the small `--without-python` drawback, I don't
personally see this being a big problem for the vast majority of users.

I do have a few of questions (I'm not sure if you an answer them, but may
be something to think about):

1) Will this make it easier to embed configuration scripts (such as those
found in the `configs` directory) into the gem5 binary?
2) Will this change the way we add new SimObjects or will it be
more-or-less identical as before?
3) One of our goals moving forward is to enforce more Python type
annotations so we can use tools such as MyPy. We've had some problems
running this with this due to embedding (i.e., we can't just point MyPy at
a SimObject Python file). Do you have any idea if this could be made easier?

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Fri, Jul 30, 2021 at 11:05 PM Gabe Black via gem5-dev 
wrote:

> Hi folks, particularly Bobby who made a change related to this fairly
> recently. Please offer some feedback, or I'll be forced to assume your
> silence is tacit agreement.
>
> Gabe
>
> On Wed, Jul 28, 2021 at 8:30 PM Gabe Black  wrote:
>
>> Bump...
>>
>> On Sat, Jul 24, 2021 at 1:16 AM Gabe Black  wrote:
>>
>>> Hi folks.
>>>
>>> I think often when we think of how python is used by gem5, many people
>>> (myself included) tend to think of it as a monolithic entity, or in other
>>> words that there is just *the* python that gets used by everything. The
>>> real situation is a little more complicated than that.
>>>
>>> On the one hand, we have "the" version of the python interpreter itself,
>>> which is used to directly run python scripts. This is again an
>>> approximation because we could, for instance, have one version of python
>>> running SCons itself, and another version running scripts gem5 provides,
>>> but for simplicity let's assume that's not the case, or at least that it
>>> doesn't matter.
>>>
>>> Then, we have the python libraries which get built into gem5 and provide
>>> it's embedded interpreter. This may not exist at all on the target system,
>>> or it could exist but be a different version than the one which you'd get
>>> by running the command line "python foo.py".
>>>
>>>
>>> **Marshal binary**
>>>
>>> The first place this has caused complication is where gem5's python code
>>> is packaged up by the build system so that it can be embedded into gem5 in
>>> either library form or executable form. Through digging around in the
>>> repository, I've found that a long, long time ago, gem5 was only a binary,
>>> and the python code was embedded into it by tacking a zip archive onto the
>>> end where gem5 could find it. Apparently this doesn't work for libraries,
>>> and so the python code needed to be bundled up and more formally injected
>>> into the binary as data. Today done by turning the python code into a
>>> binary representation, compressing it into a zip file, and then building
>>> the resulting file into a byte array declared in c++.
>>>
>>> There are, to the first order, two main ways to serialize python "stuff"
>>> into a string/byte array, pickling or marshalling. Both have their
>>> advantages and disadvantages, partially covered here:
>>>
>>> https://docs.python.org/3/library/pickle.html#module-pickle
>>>
>>> The main deal breaker disadvantage of the pickle module is that it does
>>> *not* handle code, and so all the code inside our python modules would be
>>> lost, leaving only the data. The main disadvantage of marshal is that there
>>> is *no* guarantee that it will be compatible between different versions of
>>> python, since it's intended as a mostly internal representation, for, for
>>> instance ".pyc" files.
>>>
>>> To solve this problem, Andreas added a "marshal" binary which is written
>>> in c++, and includes the python interpreter like gem5 itself would. It runs
>>> a small embedded script to use the appropriate version of the marshal
>>> module to serialize the code we want. Since the code runs under the same
>>> version of the interpreter as gem5 itself would use, when gem5 tries to use
>>> the data it will be 

[gem5-dev] Re: kokoro failures due to bug in gem5-art?

[Bobby Bruce via gem5-dev]

That theory could be true, and I certainly don't have any better ideas,
though I've never observed any hang on my local machine when recreating
this issue. It could be something specific to Kokoro.

I've fixed the gem5art error here:
https://gem5-review.googlesource.com/c/public/gem5/+/49044. We can see if
this fixes the timeout issue. If the timeout error persists  we can
consider increasing the timeout:
https://gem5-review.googlesource.com/c/public/gem5/+/48443


--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net


On Thu, Jul 22, 2021 at 8:33 PM Gabe Black  wrote:

> Another possibility is that while the gem5-art error may not actually kill
> the run, it may, for instance, have failed trying to download something
> with a generous timeout, and waiting for that timeout pushed the rest of
> the run out enough to trip the timeout? Just a thought. I haven't checked
> exhaustively, but it feels like the timeout always goes along with the
> gem5-art error message.
>
> Gabe
>
> On Thu, Jul 22, 2021 at 5:27 PM Gabe Black  wrote:
>
>> Ok, thanks. I don't know if you saw the CL I put up recently where the
>> src/base/cprintftime.cc executable (the one built from that source) was
>> broken, which made kokoro fail. The breakage was real and worth fixing, but
>> I'm not sure why kokoro was trying to build it in the first place? Maybe
>> sometimes kokoro tries building things that we didn't really want it to.
>>
>> In my recent scons hacking, I ran into that accidentally when
>> build/X86/${BLAHBLAH} expanded into build/X86/ because that variable didn't
>> exist, so scons went of and started building EVERYTHING it knew about below
>> build/X86/. Hypothetically, that could explain the long build times and the
>> building of that random other binary? Maybe we have some sort of race
>> condition where a target expands to an empty string?
>>
>> Gabe
>>
>> On Thu, Jul 22, 2021 at 3:04 PM Bobby Bruce  wrote:
>>
>>> Ok, so I did look into this today and didn't find anything. On my
>>> desktop machine the difference in running the pre-submit tests from the
>>> stable branch and develop branch (including building the binaries) was only
>>> 10 minutes so we've really not done anything to increase the build/test
>>> times to a significant extent. My running theory is Kokoro was running
>>> slower (??? I have no idea what Kokoro is actually doing or running on
>>> behind the scenes so I don't know whether that makes sense, but I cannot
>>> think of any other explanation). I don't like the solution, but I've
>>> submitted a patch to increase the timeout to 7 hours which should stop this
>>> timeout event from happening:
>>> https://gem5-review.googlesource.com/c/public/gem5/+/48443
>>>
>>> I still haven't looked into the gem5 error yet but I'm pretty confident
>>> this shouldn't interfere with the presubmit validation.
>>>
>>> --
>>> Dr. Bobby R. Bruce
>>> Room 3050,
>>> Kemper Hall, UC Davis
>>> Davis,
>>> CA, 95616
>>>
>>> web: https://www.bobbybruce.net
>>>
>>>
>>> On Wed, Jul 21, 2021 at 5:37 PM Gabe Black  wrote:
>>>
 Ok thanks, Bobby. Please let me know if you find anything, especially
 if it looks like it's a bug in kokoro itself somehow.

 Gabe

 On Wed, Jul 21, 2021 at 3:52 PM Bobby Bruce  wrote:

> There's definitely something funny going on with the gem5art tests
> there but I believe that error is happening without triggering a non-zero
> exit code. The gem5art test script is set to `set -e`, which means the
> script should exit immediately after a failure, yet it doesn't. The 
> testing
> also continues onto the other tests. I'll look into this.
>
> In the example you linked, the issue appears to be because it has
> reached the 6 hour timeout. We could increase the timeout to fix this, but
> I'd like to know why our build/test times have increased enough to push us
> over the 6 hour line.  I'll see if I can figure it out as well.
>
> --
> Dr. Bobby R. Bruce
> Room 3050,
> Kemper Hall, UC Davis
> Davis,
> CA, 95616
>
> web: https://www.bobbybruce.net
>
>
> On Wed, Jul 21, 2021 at 2:51 PM Gabe Black via gem5-dev <
> gem5-dev@gem5.org> wrote:
>
>> I've seen many kokoro failures lately, including this one which seems
>> to be from a problem in gem5-art? Any idea what's going on?
>>
>>
>> https://source.cloud.google.com/results/invocations/caae5aad-91a6-4c6e-9fbe-20962f9c5519/targets/gem5%2Fgcp_ubuntu%2Fpresubmit/log
>> ___
>> gem5-dev mailing list -- gem5-dev@gem5.org
>> To unsubscribe send an email to gem5-dev-le...@gem5.org
>> %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
>
>
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

[gem5-dev] gem5 v21.1 released!

[Bobby Bruce via gem5-dev]

Dear all,

gem5 v21.1.0.0 has officially been released.

You can use  `git clone https://gem5.googlesource.com/public/gem5`
 to obtain the latest release
and consult the RELEASE-NOTES.md for a high-level overview of significant
changes:
https://gem5.googlesource.com/public/gem5/+/refs/heads/stable/RELEASE-NOTES.md

A special thank you to all our contributors for making this possible. We
had 780 commits from 48 unique contributors over the past few months. It's
quite an achievement. We look forward to your continued support in our
v21.2 release!

Kind regards,
Bobby
--
Dr. Bobby R. Bruce
Room 3050,
Kemper Hall, UC Davis
Davis,
CA, 95616

web: https://www.bobbybruce.net
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s