Hi Ali,

 

        The detailed attachment is larger than 128KB, which is forbidden by
the mail list. If you need it, I will send it to your mail directly.

 

         Thanks!

 

Best regards,

Yongbing Huang

 

From: huangyongbing [mailto:[email protected]] 
Sent: Tuesday, June 18, 2013 3:27 PM
To: 'gem5 users mailing list'
Subject: RE: [gem5-users] panic: Uncachable load

 

Hi Ali,

 

         I replayed the panic and found that the instruction is blocked from
the rename phase.  The panic instruction is "[sn:2f722bc] PC
(0xc016b5c0=>0xc016b5c4)". The serial number of this instruction is
49750716.  And a simple trace segment is show in the below. More detailed
debug traces are attached.

 

panic: Uncachable load [sn:2f722bc] PC (0xc016b5c0=>0xc016b5c4).(0=>1)

@ cycle 2378202929830

 

Debug trace:

2378200522460: system.cpu1.rename: [tid:0]: Removing [sn:49750716]
PC:(0xc016b5c0=>0xc016b5c4).(0=>1) from rename skidBuffer

2378200522460: system.cpu1.rename: [tid:0]: Processing instruction
[sn:49750716] with PC (0xc016b5c0=>0xc016b5c4).(0=>1).

2378200522460: system.cpu1.rename: Flattening index 0 to 0.

2378200522460: system.cpu1.rename: [tid:0]: Looking up arch reg 0, got
physical reg 124.

2378200522460: system.cpu1.rename: [tid:0]: Register 124 is ready.

2378200522460: global: [sn:49750716] has 1 ready out of 5 sources. RTI 0)

2378200522460: system.cpu1.rename: Adjusting reg index from 1416 to 114.

2378200522460: system.cpu1.rename: [tid:0]: Looking up arch reg 114, got
physical reg 256.

2378200522460: system.cpu1.rename: [tid:0]: Register 256 is ready.

2378200522460: global: [sn:49750716] has 2 ready out of 5 sources. RTI 0)

2378200522460: system.cpu1.rename: Flattening index 33 to 33.

2378200522460: system.cpu1.rename: [tid:0]: Looking up arch reg 33, got
physical reg 33.

2378200522460: system.cpu1.rename: [tid:0]: Register 33 is ready.

2378200522460: global: [sn:49750716] has 3 ready out of 5 sources. RTI 0)

2378200522460: system.cpu1.rename: Flattening index 33 to 33.

2378200522460: system.cpu1.rename: [tid:0]: Looking up arch reg 33, got
physical reg 33.

2378200522460: system.cpu1.rename: [tid:0]: Register 33 is ready.

2378200522460: global: [sn:49750716] has 4 ready out of 5 sources. RTI 0)

2378200522460: system.cpu1.rename: Flattening index 33 to 33.

2378200522460: system.cpu1.rename: [tid:0]: Looking up arch reg 33, got
physical reg 33.

2378200522460: system.cpu1.rename: [tid:0]: Register 33 is ready.

2378200522460: global: [sn:49750716] has 5 ready out of 5 sources. RTI 0)

2378200522460: system.cpu1.rename: Flattening index 12 to 12.

2378200522460: cpu.freelist: Trying to get free integer register.

2378200522460: global: Renamed reg 12 to physical reg 11 old mapping was 10

2378200522460: system.cpu1.rename: [tid:0]: Renaming arch reg 12 to physical
reg 11.

2378200522460: system.cpu1.rename: [tid:0]: Adding instruction to history
buffer (size=35), [sn:49750716].

 

 

         Hope that above information are useful.

 

         Thanks!

 

Best regards,

Yongbing Huang

 

From: [email protected] [mailto:[email protected]] On
Behalf Of Ali Saidi
Sent: Thursday, June 13, 2013 12:17 PM
To: gem5 users mailing list
Subject: Re: [gem5-users] panic: Uncachable load

 

Hi Yongbing,

 

You need to figure out what the serial number of the instruction that causes
this issue is and the get an debug trace with --debug-flags=O3CPUAll with
that serial number and see what happens in the execution to it.

 

Thanks,

Ali

 

On Jun 4, 2013, at 9:01 PM, huangyongbing <[email protected]> wrote:

 

Hi Ali,

 

         I can replay this panic now. So what kind of information do you
need in order to debug it.

 

         Thanks.

 

Best regards,

Yongbing Huang

 

From: [email protected] [mailto:[email protected]] On
Behalf Of Ali Saidi
Sent: Monday, June 03, 2013 3:06 AM
To: gem5 users mailing list
Subject: Re: [gem5-users] panic: Uncachable load

 

I've seen this bug pop up before, but it's been hard to track down. Some how
a load ends up getting executed that is uncachable and not at the head of
the ROB. Exactly what conditions lead to this isn't clear from the code and
I haven't found the behavior to be particularly repeatable to be able to
debug it. 

 

Ali

 

 

On May 29, 2013, at 3:06 AM, huangyongbing <
<mailto:[email protected]> [email protected]> wrote:

 

Hi Andreas,

 

         I am running map and office applications on a modified disk image.
I only modify the cache policy of gem5. The version of Linux kernel is
2.6.35 and I just modify the size of vncview.

 

         It is difficult to reproduce the panic. The panic may no longer
exist when I rerun the simulator using the same configuration.

 

         Thanks.

 

Best regards,

Yongbing Huang

 

 

From:  <mailto:[email protected]> [email protected]
[mailto:gem5- <mailto:[email protected]> [email protected]] On
Behalf Of Andreas Hansson
Sent: Wednesday, May 29, 2013 3:28 PM
To: gem5 users mailing list
Subject: Re: [gem5-users] panic: Uncachable load

 

Hi Yongbing,

 

Could you elaborate a bit on what you are running? For example, is this on
an unmodified trunk? If so, how to reproduce it?

 

Thanks,

 

Andreas

 

From: huangyongbing < <mailto:[email protected]>
[email protected]>
Reply-To: gem5 users mailing list < <mailto:[email protected]>
[email protected]>
Date: Wednesday, 29 May 2013 07:48
To: " <mailto:[email protected]> [email protected]" <
<mailto:[email protected]> [email protected]>
Subject: [gem5-users] panic: Uncachable load

 

Hi all,

 

         I run the simulator using the arm_detailed CPU model while
simulating the ARM platform. However, the bellowing panic will occur
sometimes:

 

panic: Uncachable load [sn:4af0382b] PC (0xc016b5c0=>0xc016b5c4).(0=>1)
(PC is different for different times, but PCs are often like 0xc016b5xx)

@ cycle 611133741299620

[invoke:build/ARM/arch/generic/debugfaults.hh, line 94]

 

         The source codes of above panic are contained in the file
cpu/o3/lsq_unit.hh:

                   LSQUnit::read()

                   {

             if (req->isUncacheable() && (load_idx != loadHead ||
!load_inst->isAtCommit())) {

                                     .

                                     Panic(.);

                   }

         }

 

The pc shows this is the instruction of Linux kernel. So are they any ideas
about the reason?

 

Thanks.

 

Best regards,

 

Yongbing Huang

 


-- 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-users mailing list
 <mailto:[email protected]> [email protected]
 <http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users>
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

 

_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

 

_______________________________________________
gem5-users mailing list
[email protected]
http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users

Reply via email to