[gem5-users] Re: Error only occurs with higher number of clusters and cpus

2020-08-11 Thread Ciro Santilli via gem5-users 
We have to understand the root cause to be sure, it often happens that memory 
errors are just hidden by random changes. Let's move all discussion to that 
ticket. I've started dumping some logs for it and linked to the ticket BTW.

From: Sebastian Block 
Sent: Tuesday, August 11, 2020 11:37 AM
To: gem5-users@gem5.org ; Ciro Santilli 

Cc: nd 
Subject: Re: [gem5-users] Error only occurs with higher number of clusters and 
cpus

The error seems to relate to the kernel used. I build a new kernel (gem5: 
Building ARM 
Kernel)
 and now I'm able to simulate even more cpus. The kernel i used is the v4.14 
version.


Am Freitag, 7. August 2020, 20:08:10 MESZ hat Sebastian Block 
 Folgendes geschrieben:



Thank you very much. I will give Ruby a try.
Am Freitag, 7. August 2020, 16:41:12 MESZ hat Ciro Santilli 
 Folgendes geschrieben:


It might be the same as: https://gem5.atlassian.net/browse/GEM5-711 I want to 
investigate that soon hopefully.

If you try Ruby and it fails, please open a separate bug, we want it to work as 
well 

From: Sebastian Block via gem5-users 
Sent: Friday, August 7, 2020 9:27 AM
To: gem5-users@gem5.org 
Cc: Sebastian Block 
Subject: [gem5-users] Error only occurs with higher number of clusters and cpus

Hi all,

My gem5 project consists of clusters and some cpus in the clusters, simulating 
them in fs mode.
Simulating in atomic mode always works.
While simulating less then 6 cpus works perfectly fine in timing mode, with 
more then 6 the simulation crashes with the error:

panic: panic condition (pkt->needsWritable() != pkt->isInvalidate()) && 
!pkt->req->isCacheMaintenance() occurred: global got snoop WriteReq 
[80a70800:80a70803] UC where needsWritable, does not match isInvalidate
Memory Usage: 9072952 KBytes
Program aborted at tick 175141645000
--- BEGIN LIBC BACKTRACE ---

At the moment the project uses classic caches. Private L1 and shared L2 caches. 
I didn't test it with L3 caches as the simulation crashes sometimes.
Is it possible that the error occurs because of the classic caches and cache 
coherence?
Might the error vanish when using Ruby?
An L3 cache should also be implemented. Is it difficult to do that in Ruby?

Thank you very much for your help.

Best regards
Sebastian

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

[gem5-users] Re: Error only occurs with higher number of clusters and cpus

2020-08-11 Thread Sebastian Block via gem5-users 
 The error seems to relate to the kernel used. I build a new kernel (gem5: 
Building ARM Kernel) and now I'm able to simulate even more cpus. The kernel i 
used is the v4.14 version.

Am Freitag, 7. August 2020, 20:08:10 MESZ hat Sebastian Block 
 Folgendes geschrieben:  
 
  
Thank you very much. I will give Ruby a try.Am Freitag, 7. August 2020, 
16:41:12 MESZ hat Ciro Santilli  Folgendes geschrieben:  
 
 #yiv4237158419 P {margin-top:0;margin-bottom:0;}It might be the same as: 
https://gem5.atlassian.net/browse/GEM5-711 I want to investigate that soon 
hopefully.
If you try Ruby and it fails, please open a separate bug, we want it to work as 
wellFrom: Sebastian Block via gem5-users 
Sent: Friday, August 7, 2020 9:27 AM
To: gem5-users@gem5.org 
Cc: Sebastian Block 
Subject: [gem5-users] Error only occurs with higher number of clusters and cpus 
Hi all,
My gem5 project consists of clusters and some cpus in the clusters, simulating 
them in fs mode.Simulating in atomic mode always works. While simulating less 
then 6 cpus works perfectly fine in timing mode, with more then 6 the 
simulation crashes with the error: 
panic: panic condition (pkt->needsWritable() != pkt->isInvalidate()) && 
!pkt->req->isCacheMaintenance() occurred: global got snoop WriteReq 
[80a70800:80a70803] UC where needsWritable, does not match isInvalidateMemory 
Usage: 9072952 KBytesProgram aborted at tick 175141645000--- BEGIN LIBC 
BACKTRACE ---At the moment the project uses classic caches. Private L1 and 
shared L2 caches. I didn't test it with L3 caches as the simulation crashes 
sometimes.Is it possible that the error occurs because of the classic caches 
and cache coherence?Might the error vanish when using Ruby? An L3 cache should 
also be implemented. Is it difficult to do that in Ruby?
Thank you very much for your help.
Best regardsSebastian
___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Error only occurs with higher number of clusters and cpus

2020-08-07 Thread Sebastian Block via gem5-users 
 
Thank you very much. I will give Ruby a try.Am Freitag, 7. August 2020, 
16:41:12 MESZ hat Ciro Santilli  Folgendes geschrieben:  
 
 #yiv9784044512 P {margin-top:0;margin-bottom:0;}It might be the same as: 
https://gem5.atlassian.net/browse/GEM5-711 I want to investigate that soon 
hopefully.
If you try Ruby and it fails, please open a separate bug, we want it to work as 
wellFrom: Sebastian Block via gem5-users 
Sent: Friday, August 7, 2020 9:27 AM
To: gem5-users@gem5.org 
Cc: Sebastian Block 
Subject: [gem5-users] Error only occurs with higher number of clusters and cpus 
Hi all,
My gem5 project consists of clusters and some cpus in the clusters, simulating 
them in fs mode.Simulating in atomic mode always works. While simulating less 
then 6 cpus works perfectly fine in timing mode, with more then 6 the 
simulation crashes with the error: 
panic: panic condition (pkt->needsWritable() != pkt->isInvalidate()) && 
!pkt->req->isCacheMaintenance() occurred: global got snoop WriteReq 
[80a70800:80a70803] UC where needsWritable, does not match isInvalidateMemory 
Usage: 9072952 KBytesProgram aborted at tick 175141645000--- BEGIN LIBC 
BACKTRACE ---At the moment the project uses classic caches. Private L1 and 
shared L2 caches. I didn't test it with L3 caches as the simulation crashes 
sometimes.Is it possible that the error occurs because of the classic caches 
and cache coherence?Might the error vanish when using Ruby? An L3 cache should 
also be implemented. Is it difficult to do that in Ruby?
Thank you very much for your help.
Best regardsSebastian
  ___
gem5-users mailing list -- gem5-users@gem5.org
To unsubscribe send an email to gem5-users-le...@gem5.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s

[gem5-users] Re: Error only occurs with higher number of clusters and cpus

2020-08-07 Thread Ciro Santilli via gem5-users 
It might be the same as: https://gem5.atlassian.net/browse/GEM5-711 I want to 
investigate that soon hopefully.

If you try Ruby and it fails, please open a separate bug, we want it to work as 
well 

From: Sebastian Block via gem5-users 
Sent: Friday, August 7, 2020 9:27 AM
To: gem5-users@gem5.org 
Cc: Sebastian Block 
Subject: [gem5-users] Error only occurs with higher number of clusters and cpus

Hi all,

My gem5 project consists of clusters and some cpus in the clusters, simulating 
them in fs mode.
Simulating in atomic mode always works.
While simulating less then 6 cpus works perfectly fine in timing mode, with 
more then 6 the simulation crashes with the error:

panic: panic condition (pkt->needsWritable() != pkt->isInvalidate()) && 
!pkt->req->isCacheMaintenance() occurred: global got snoop WriteReq 
[80a70800:80a70803] UC where needsWritable, does not match isInvalidate
Memory Usage: 9072952 KBytes
Program aborted at tick 175141645000
--- BEGIN LIBC BACKTRACE ---

At the moment the project uses classic caches. Private L1 and shared L2 caches. 
I didn't test it with L3 caches as the simulation crashes sometimes.
Is it possible that the error occurs because of the classic caches and cache 
coherence?
Might the error vanish when using Ruby?
An L3 cache should also be implemented. Is it difficult to do that in Ruby?

Thank you very much for your help.

Best regards
Sebastian

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