If you search the entire trace, could you figure out what happens from fetch through the panic to instruction 49750716?
Ali On 18.06.2013 18:07, huangyongbing wrote: > 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:huangyongb...@ncic.ac.cn] > 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: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] 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 <huangyongb...@ncic.ac.cn> 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: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] 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 <huangyongb...@ncic.ac.cn> 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: gem5-users-boun...@gem5.org [mailto:gem5-users-boun...@gem5.org] 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 <huangyongb...@ncic.ac.cn> > REPLY-TO: gem5 users mailing list <gem5-users@gem5.org> > DATE: Wednesday, 29 May 2013 07:48 > TO: "gem5-users@gem5.org" <gem5-users@gem5.org> > 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 > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] > > _______________________________________________ > gem5-users mailing list > gem5-users@gem5.org > http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users [1] Links: ------ [1] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
_______________________________________________ gem5-users mailing list gem5-users@gem5.org http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
