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

2023-01-09 Thread jenkins-no-reply--- via gem5-dev 
See 

Changes:

[drinkcat] scons: Clone env before modifying it in SharedLib

[drinkcat] systemc: Add facilities to add extra SystemC message handlers

[drinkcat] fastmodel: Add handler to catch DMI warnings

[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 921.93 KB...]
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size (1) does not 
divide range [1:1.6e+06] into equal-sized buckets. Rounding up.
build/GCN3_X86/base/stats/storage.hh:279: warn: Bucket size

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

2023-01-09 Thread Matt Sinclair via gem5-dev 
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] ARM/mem/ruby/protocol/RubyAccessMode.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/RubyRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SequencerMsg.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SequencerRequestType.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SequencerStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/SeriesRequestGeneratorStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/TesterStatus.cc -> .o
>  [ CXX] ARM/mem/ruby/protocol/TransitionResult.cc -> .o
>  [ CXX] ARM/mem/probes/BaseMemProbe.py.cc -> .o
>  [SO Param] m5.objects.BaseMemProbe, BaseMemProbe ->
>

[gem5-dev] [S] Change in gem5/gem5[develop]: gpu-compute : Fix incorrect TLB stats when FunctionalTLB is used

2023-01-09 Thread VISHNU RAMADAS (Gerrit) via gem5-dev 
VISHNU RAMADAS has submitted this change. (  
https://gem5-review.googlesource.com/c/public/gem5/+/67202?usp=email )


Change subject: gpu-compute : Fix incorrect TLB stats when FunctionalTLB is  
used

..

gpu-compute : Fix incorrect TLB stats when FunctionalTLB is used

When FunctionalTLB is used in SE mode, the stats tlbLatency and
tlbCycles report negative values. This patch fixes it by disabling the
updates that result in negative values when FunctionalTLB is set to true

Change-Id: I6962785fc1730b166b6d5b879e9c7618a8d6d4b3
Reviewed-on: https://gem5-review.googlesource.com/c/public/gem5/+/67202
Reviewed-by: Matt Sinclair 
Maintainer: Matt Sinclair 
Maintainer: Matthew Poremba 
Reviewed-by: Matthew Poremba 
Tested-by: kokoro 
---
M src/gpu-compute/compute_unit.cc
1 file changed, 22 insertions(+), 1 deletion(-)

Approvals:
  kokoro: Regressions pass
  Matt Sinclair: Looks good to me, approved
  Matthew Poremba: Looks good to me, approved; Looks good to me, approved
  Matt Sinclair: Looks good to me, approved




diff --git a/src/gpu-compute/compute_unit.cc  
b/src/gpu-compute/compute_unit.cc

index 62cfbf9..06fe28f 100644
--- a/src/gpu-compute/compute_unit.cc
+++ b/src/gpu-compute/compute_unit.cc
@@ -1078,7 +1078,9 @@
 fatal("pkt is not a read nor a write\n");
 }

-stats.tlbCycles -= curTick();
+if (!functionalTLB) {
+stats.tlbCycles -= curTick();
+}
 ++stats.tlbRequests;

 PortID tlbPort_index = perLaneTLB ? index : 0;

--
To view, visit  
https://gem5-review.googlesource.com/c/public/gem5/+/67202?usp=email
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I6962785fc1730b166b6d5b879e9c7618a8d6d4b3
Gerrit-Change-Number: 67202
Gerrit-PatchSet: 2
Gerrit-Owner: VISHNU RAMADAS 
Gerrit-Reviewer: Matt Sinclair 
Gerrit-Reviewer: Matt Sinclair 
Gerrit-Reviewer: Matthew Poremba 
Gerrit-Reviewer: VISHNU RAMADAS 
Gerrit-Reviewer: kokoro 
Gerrit-MessageType: merged
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org

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

2023-01-09 Thread jenkins-no-reply--- via gem5-dev 
See 

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] ARM/mem/ruby/protocol/RubyAccessMode.cc -> .o
 [ CXX] ARM/mem/ruby/protocol/RubyRequestType.cc -> .o
 [ CXX] ARM/mem/ruby/protocol/SequencerMsg.cc -> .o
 [ CXX] ARM/mem/ruby/protocol/SequencerRequestType.cc -> .o
 [ CXX] ARM/mem/ruby/protocol/SequencerStatus.cc -> .o
 [ CXX] ARM/mem/ruby/protocol/SeriesRequestGeneratorStatus.cc -> .o
 [ CXX] ARM/mem/ruby/protocol/TesterStatus.cc -> .o
 [ CXX] ARM/mem/ruby/protocol/TransitionResult.cc -> .o
 [ CXX] ARM/mem/probes/BaseMemProbe.py.cc -> .o
 [SO Param] m5.objects.BaseMemProbe, BaseMemProbe -> 
ARM/python/_m5/param_BaseMemProbe.cc
 [SO Param] m5.objects.BaseMemProbe, BaseMemProbe -> ARM/params/BaseMemProbe.hh
 [ CXX] ARM/mem/probes/StackDistProbe.py.cc -> .o
 [SO Param] m5.objects.StackDistProbe, StackDistProbe -> 
ARM/python/_m5/param_StackDistProbe.cc
 [SO Param] m5.objects.StackDistProbe, StackDistProbe -> 
ARM/params/StackDistProbe.hh
 [ CXX] ARM/mem/probes/MemFootprintProbe.py.cc -> .o
 [ CXX] ARM/mem/probes/base.cc -> .o
 [ CXX] ARM/python/_m5/param_BaseMemProbe.cc -> .o
 [SO Param]

[gem5-dev] [S] Change in gem5/gem5[develop]: gpu-compute : Fix incorrect TLB stats when FunctionalTLB is used

2023-01-09 Thread VISHNU RAMADAS (Gerrit) via gem5-dev 
VISHNU RAMADAS has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/67202?usp=email )



Change subject: gpu-compute : Fix incorrect TLB stats when FunctionalTLB is  
used

..

gpu-compute : Fix incorrect TLB stats when FunctionalTLB is used

When FunctionalTLB is used in SE mode, the stats tlbLatency and
tlbCycles report negative values. This patch fixes it by disabling the
updates that result in negative values when FunctionalTLB is set to true

Change-Id: I6962785fc1730b166b6d5b879e9c7618a8d6d4b3
---
M src/gpu-compute/compute_unit.cc
1 file changed, 16 insertions(+), 1 deletion(-)



diff --git a/src/gpu-compute/compute_unit.cc  
b/src/gpu-compute/compute_unit.cc

index 62cfbf9..06fe28f 100644
--- a/src/gpu-compute/compute_unit.cc
+++ b/src/gpu-compute/compute_unit.cc
@@ -1078,7 +1078,9 @@
 fatal("pkt is not a read nor a write\n");
 }

-stats.tlbCycles -= curTick();
+if (!functionalTLB) {
+stats.tlbCycles -= curTick();
+}
 ++stats.tlbRequests;

 PortID tlbPort_index = perLaneTLB ? index : 0;

--
To view, visit  
https://gem5-review.googlesource.com/c/public/gem5/+/67202?usp=email
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I6962785fc1730b166b6d5b879e9c7618a8d6d4b3
Gerrit-Change-Number: 67202
Gerrit-PatchSet: 1
Gerrit-Owner: VISHNU RAMADAS 
Gerrit-MessageType: newchange
___
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: weekly #99

2023-01-09 Thread Poremba, Matthew via gem5-dev 
[AMD Official Use Only - General]

I don't think I have tried pennant on Vega, but the current status (as of 
several months ago) is:

Two weekly tests have issues with Vega right now:  (1) heterosync with 
sleepMutex and (2) lulesh
Two weekly tests have issues running in full-system: (1) sssp and (2) sssp_ell

We can discuss the details in another thread though.


-Matt

From: Matt Sinclair 
Sent: Monday, January 9, 2023 9:41 AM
To: Poremba, Matthew 
Cc: Bobby Bruce ; Jason Lowe-Power ; 
The gem5 Developer List ; vrama...@wisc.edu
Subject: Re: [gem5-dev] Re: Build failed in Jenkins: weekly #99

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.

Thanks all.  I have validated all weekly and nightly GPU tests pass with my 
changes.

Matt P: we should probably figure out if all tests pass on Vega now, and if so 
move to Vega for nightly and weekly.  My recollection is some workloads 
(Pennant?) were failing with Vega last time we tried?

Matt

On Mon, Jan 9, 2023 at 10:46 AM Poremba, Matthew 
mailto:matthew.pore...@amd.com>> wrote:

[AMD Official Use Only - General]

Thanks all, it looks like everything was taken care of over the weekend.

To answer MattS' question: I've tested weekly on most of my changes and haven't 
found any issues.  I've been primarily making arch-vega changes and the weekly 
tester only tests gcn3 by default though.


-Matt

From: Bobby Bruce mailto:bbr...@ucdavis.edu>>
Sent: Monday, January 9, 2023 7:59 AM
To: The gem5 Developer List mailto:gem5-dev@gem5.org>>
Cc: Jason Lowe-Power mailto:ja...@lowepower.com>>; 
Poremba, Matthew mailto:matthew.pore...@amd.com>>; 
vrama...@wisc.edu; Matt Sinclair 
mailto:mattdsinclair.w...@gmail.com>>
Subject: Re: [gem5-dev] Re: Build failed in Jenkins: weekly #99

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.

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 
mailto: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 
mailto:ja...@lowepower.com>> wrote:
Thanks for quickly digging into this, Matt!

On Sat, Jan 7, 2023 at 1:41 PM Matt Sinclair via gem5-dev 
mailto: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 
mailto: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

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

2023-01-09 Thread Matt Sinclair via gem5-dev 
Thanks all.  I have validated all weekly and nightly GPU tests pass with my
changes.

Matt P: we should probably figure out if all tests pass on Vega now, and if
so move to Vega for nightly and weekly.  My recollection is some workloads
(Pennant?) were failing with Vega last time we tried?

Matt

On Mon, Jan 9, 2023 at 10:46 AM Poremba, Matthew 
wrote:

> [AMD Official Use Only - General]
>
>
>
> Thanks all, it looks like everything was taken care of over the weekend.
>
>
>
> To answer MattS’ question: I’ve tested weekly on most of my changes and
> haven’t found any issues.  I’ve been primarily making arch-vega changes and
> the weekly tester only tests gcn3 by default though.
>
>
>
>
>
> -Matt
>
>
>
> *From:* Bobby Bruce 
> *Sent:* Monday, January 9, 2023 7:59 AM
> *To:* The gem5 Developer List 
> *Cc:* Jason Lowe-Power ; Poremba, Matthew <
> matthew.pore...@amd.com>; vrama...@wisc.edu; Matt Sinclair <
> mattdsinclair.w...@gmail.com>
> *Subject:* Re: [gem5-dev] Re: Build failed in Jenkins: weekly #99
>
>
>
> *Caution:* This message originated from an External Source. Use proper
> caution when opening attachments, clicking links, or responding.
>
>
>
> 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

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

2023-01-09 Thread Poremba, Matthew via gem5-dev 
[AMD Official Use Only - General]

Thanks all, it looks like everything was taken care of over the weekend.

To answer MattS' question: I've tested weekly on most of my changes and haven't 
found any issues.  I've been primarily making arch-vega changes and the weekly 
tester only tests gcn3 by default though.


-Matt

From: Bobby Bruce 
Sent: Monday, January 9, 2023 7:59 AM
To: The gem5 Developer List 
Cc: Jason Lowe-Power ; Poremba, Matthew 
; vrama...@wisc.edu; Matt Sinclair 

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

Caution: This message originated from an External Source. Use proper caution 
when opening attachments, clicking links, or responding.

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 
mailto: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 
mailto:ja...@lowepower.com>> wrote:
Thanks for quickly digging into this, Matt!

On Sat, Jan 7, 2023 at 1:41 PM Matt Sinclair via gem5-dev 
mailto: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 
mailto: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 
mailto:gem5-dev@gem5.org>> wrote:
See 
>

Changes:

[Bobby R. Bruce] ext: Fix SST Documentation links

[Bobby R. Bruce] tests: Fix the download test

[Bobby

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

2023-01-09 Thread 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] [S] Change in gem5/gem5[develop]: arch-riscv: Check RISCV process run in matched CPU

2023-01-09 Thread Roger Chang (Gerrit) via gem5-dev 
Roger Chang has uploaded this change for review. (  
https://gem5-review.googlesource.com/c/public/gem5/+/67251?usp=email )



Change subject: arch-riscv: Check RISCV process run in matched CPU
..

arch-riscv: Check RISCV process run in matched CPU

The process should run correct CPU configuration instead of setting
RISCV flags by process

Change-Id: I00b0725f3eb4f29e45b8ec719317af79355dc728
---
M src/arch/riscv/process.cc
1 file changed, 20 insertions(+), 5 deletions(-)



diff --git a/src/arch/riscv/process.cc b/src/arch/riscv/process.cc
index dc7abae..e76933e 100644
--- a/src/arch/riscv/process.cc
+++ b/src/arch/riscv/process.cc
@@ -101,8 +101,12 @@
 Process::initState();

 argsInit(PageBytes);
-for (ContextID ctx: contextIds)
-system->threads[ctx]->setMiscRegNoEffect(MISCREG_PRV, PRV_U);
+for (ContextID ctx: contextIds) {
+auto *tc = system->threads[ctx];
+tc->setMiscRegNoEffect(MISCREG_PRV, PRV_U);
+auto isa = dynamic_cast(tc->getIsaPtr());
+panic_if(isa->rvType() != RV64, "RISC V CPU should run in 64 bits  
mode");

+}
 }

 void
@@ -114,9 +118,8 @@
 for (ContextID ctx: contextIds) {
 auto *tc = system->threads[ctx];
 tc->setMiscRegNoEffect(MISCREG_PRV, PRV_U);
-PCState pc = tc->pcState().as();
-pc.rvType(RV32);
-tc->pcState(pc);
+auto isa = dynamic_cast(tc->getIsaPtr());
+panic_if(isa->rvType() != RV32, "RISC V CPU should run in 32 bits  
mode");

 }
 }


--
To view, visit  
https://gem5-review.googlesource.com/c/public/gem5/+/67251?usp=email
To unsubscribe, or for help writing mail filters, visit  
https://gem5-review.googlesource.com/settings


Gerrit-Project: public/gem5
Gerrit-Branch: develop
Gerrit-Change-Id: I00b0725f3eb4f29e45b8ec719317af79355dc728
Gerrit-Change-Number: 67251
Gerrit-PatchSet: 1
Gerrit-Owner: Roger Chang 
Gerrit-MessageType: newchange
___
gem5-dev mailing list -- gem5-dev@gem5.org
To unsubscribe send an email to gem5-dev-le...@gem5.org