All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] xen: arm64: more useful logging on bad trap.
@ 2015-02-18 15:19 Ian Campbell
  2015-02-18 15:36 ` Julien Grall
  0 siblings, 1 reply; 8+ messages in thread
From: Ian Campbell @ 2015-02-18 15:19 UTC (permalink / raw)
  To: xen-devel; +Cc: jintack, julien.grall, tim, Ian Campbell, stefano.stabellini

Dump the register state before panicing so we have some clue where the
issue occurred. Also decode the ESR register a bit to save having to
grab a pen and paper.

ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
we already do correctly in the main trap handler.

While here notice that do_trap_serror is never called and remove it.

Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
Cc: jintack@cs.columbia.edu
---
Jintack, since you have a system which is exhibiting SError issues I
wonder if I could prevail on you to give this patch a try on your
system and report on the output. I've only compile tested this myself.
---
 xen/arch/arm/arm64/traps.c |   13 +++++--------
 1 file changed, 5 insertions(+), 8 deletions(-)

diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
index 1693b5d..89b8eb3 100644
--- a/xen/arch/arm/arm64/traps.c
+++ b/xen/arch/arm/arm64/traps.c
@@ -24,11 +24,6 @@
 
 #include <public/xen.h>
 
-asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
-{
-    panic("Unhandled serror trap");
-}
-
 static const char *handler[]= {
         "Synchronous Abort",
         "IRQ",
@@ -38,11 +33,13 @@ static const char *handler[]= {
 
 asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
 {
-    uint64_t esr = READ_SYSREG64(ESR_EL2);
-    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
-           handler[reason], esr);
+    union hsr hsr = { .bits = READ_SYSREG32(ESR_EL2) };
+    printk("Bad mode in %s handler detected, code 0x%08"PRIx32","
+           " EC=%"PRIx32", IL=%"PRIx32" ISS=%"PRIx32"\n",
+           handler[reason], hsr.bits, hsr.ec, hsr.len, hsr.iss);
 
     local_irq_disable();
+    show_execution_state(regs);
     panic("bad mode");
 }
 
-- 
1.7.10.4

^ permalink raw reply related	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen: arm64: more useful logging on bad trap.
  2015-02-18 15:19 [PATCH] xen: arm64: more useful logging on bad trap Ian Campbell
@ 2015-02-18 15:36 ` Julien Grall
  2015-02-18 15:47   ` Jintack Lim
  0 siblings, 1 reply; 8+ messages in thread
From: Julien Grall @ 2015-02-18 15:36 UTC (permalink / raw)
  To: Ian Campbell, xen-devel; +Cc: tim, jintack, stefano.stabellini

Hi Ian,

On 18/02/2015 15:19, Ian Campbell wrote:
> diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
> index 1693b5d..89b8eb3 100644
> --- a/xen/arch/arm/arm64/traps.c
> +++ b/xen/arch/arm/arm64/traps.c
> @@ -24,11 +24,6 @@
>
>   #include <public/xen.h>
>
> -asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
> -{
> -    panic("Unhandled serror trap");
> -}
> -
>   static const char *handler[]= {
>           "Synchronous Abort",
>           "IRQ",
> @@ -38,11 +33,13 @@ static const char *handler[]= {
>
>   asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
>   {
> -    uint64_t esr = READ_SYSREG64(ESR_EL2);
> -    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
> -           handler[reason], esr);

While you are modifying this function. Can you add a newline after the 
declarations?

Other than that:

Reviewed-by: Julien Grall <julien.grall@linaro.org>

Regards,

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen: arm64: more useful logging on bad trap.
  2015-02-18 15:36 ` Julien Grall
@ 2015-02-18 15:47   ` Jintack Lim
  2015-02-18 16:00     ` Julien Grall
  2015-02-18 16:01     ` Ian Campbell
  0 siblings, 2 replies; 8+ messages in thread
From: Jintack Lim @ 2015-02-18 15:47 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Stefano Stabellini, Julien Grall, Tim Deegan, xen-devel,
	Christoffer Dall, Shih-Wei Li

On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
> Dump the register state before panicing so we have some clue where the
> issue occurred. Also decode the ESR register a bit to save having to
> grab a pen and paper.
>
> ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
> we already do correctly in the main trap handler.
>
> While here notice that do_trap_serror is never called and remove it.
>
> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> Cc: jintack@cs.columbia.edu
> ---
> Jintack, since you have a system which is exhibiting SError issues I
> wonder if I could prevail on you to give this patch a try on your
> system and report on the output. I've only compile tested this myself.
> ---

Hi Ian,
this is the output I got from the machine.
Thanks!

Xen 4.5.0 (c/s Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty) EFI
loader
Using configuration file 'xen.cfg'
vmlinuz-3.18.0+: 0x00000083fbd8f000-0x00000083fc5195c0
 Xen 4.5.0
(XEN) Xen version 4.5.0 (jintack@) (gcc (Ubuntu/Linaro
4.8.2-19ubuntu1) 4.8.2) debug=n Wed Feb 18 5
(XEN) Latest ChangeSet: Mon Jan 12 11:30:05 2015 -0500
git:a8ac229-dirty
(XEN) Processor: 410fd070: "ARM Limited", variant: 0x0, part 0xd07,
rev 0x0
(XEN) 64-bit Execution:
(XEN)   Processor Features: 0000000000002222 0000000000000000
(XEN)     Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
(XEN)     Extensions: FloatingPoint AdvancedSIMD
(XEN)   Debug Features: 0000000010305106 0000000000000000
(XEN)   Auxiliary Features: 0000000000000000 0000000000000000
(XEN)   Memory Model Features: 0000000000001124 0000000000000000
(XEN)   ISA Features:  0000000000011120 0000000000000000
(XEN) 32-bit Execution:
(XEN)   Processor Features: 00000131:00011011
(XEN)     Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
(XEN)     Extensions: GenericTimer Security
(XEN)   Debug Features: 03010066
(XEN)   Auxiliary Features: 00000000
(XEN)   Memory Model Features: 10101105 40000000 01260000 02102211
(XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142
00011121
(XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
(XEN) Using generic timer at 187500 KHz
(XEN) GICv2 initialization:
(XEN)         gic_dist_addr=00000000e1110000
(XEN)         gic_cpu_addr=00000000e112f000
(XEN)         gic_hyp_addr=00000000e1140000
(XEN)         gic_vcpu_addr=00000000e1160000
(XEN)         gic_maintenance_irq=24
(XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b).
(XEN) Using scheduler: SMP Credit Scheduler (credit)
(XEN) Bad mode in Error handler detected, code 0xbf000000, EC=2f, IL=1
ISS=1000000
(XEN) ----[ Xen-4.5.0  arm64  debug=n  Not tainted ]----
(XEN) CPU:    0
(XEN) PC:     00000000002770f0 start_xen+0x920/0xc98
(XEN) LR:     00000000002770e8
(XEN) SP:     00000000002a7e10
(XEN) CPSR:   00000249 MODE:64-bit EL2h (Hypervisor, handler)
(XEN)      X0: 00008003fff87000  X1: 0000000000000000  X2:
0000800030001570
(XEN)      X3: 0000000000000000  X4: 00000000000009a1  X5:
0000000000000000
(XEN)      X6: 000080003000161e  X7: 6f74717164736d48  X8:
7f7f7f7f7f7f7f7f
(XEN)      X9: fefefefefeff7273 X10: 7f7f7f7f7f7f7f7f X11:
0101010101010101
(XEN)     X12: 0000000000000010 X13: 000000000026b000 X14:
00000000002183b0
(XEN)     X15: 0000000000000000 X16: 0000000000000000 X17:
0000000000000000
(XEN)     X18: 0000000000000000 X19: 000000000026b710 X20:
00000000002b0000
(XEN)     X21: 000000000026b000 X22: 000000000026b000 X23:
0000000000290860
(XEN)     X24: 0000000000000004 X25: 0000008400000000 X26:
0000008001000000
(XEN)     X27: 0000008400000000 X28: 00000000003fd977  FP:
0000000000000000
(XEN)
(XEN)   VTCR_EL2: 80000000
(XEN)  VTTBR_EL2: 0000000000000000
(XEN)
(XEN)  SCTLR_EL2: 30cd183d
(XEN)    HCR_EL2: 000000000038643f
(XEN)  TTBR0_EL2: 0000008027ee4000
(XEN)
(XEN)    ESR_EL2: bf000000
(XEN)  HPFAR_EL2: 0000000000000000
(XEN)    FAR_EL2: 0000000000000000
(XEN)
(XEN) Xen stack trace from sp=00000000002a7e10:
(XEN)    00000083fc520000 00000083fc320000 00000083fc51a000
0000000000000000
(XEN)    00000083fff70668 0000000000000000 0000000000000001
00000083fc58b000
(XEN)    0000000000000000 00000083fc5b0030 00000083fc5201d8
0000000000000000
(XEN)    0000000000000000 00000083ffe70000 0000000d00000000
00000003fd977000
(XEN)    000000000026b000 00000000002f2000 00000083fc51a000
0000000000004000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000 0000000000000000
0000000000000000
(XEN)    0000000000000000 0000000000000000
(XEN) Xen call trace:
(XEN)    [<00000000002770f0>] start_xen+0x920/0xc98 (PC)
(XEN)    [<00000000002770e8>] start_xen+0x918/0xc98 (LR)
(XEN)
(XEN)
(XEN) ****************************************
(XEN) Panic on CPU 0:
(XEN) bad mode
(XEN) ****************************************
(XEN)
(XEN) Reboot in five seconds...

On Wed, Feb 18, 2015 at 10:36 AM, Julien Grall <julien.grall@linaro.org> wrote:
> Hi Ian,
>
> On 18/02/2015 15:19, Ian Campbell wrote:
>>
>> diff --git a/xen/arch/arm/arm64/traps.c b/xen/arch/arm/arm64/traps.c
>> index 1693b5d..89b8eb3 100644
>> --- a/xen/arch/arm/arm64/traps.c
>> +++ b/xen/arch/arm/arm64/traps.c
>> @@ -24,11 +24,6 @@
>>
>>   #include <public/xen.h>
>>
>> -asmlinkage void do_trap_serror(struct cpu_user_regs *regs)
>> -{
>> -    panic("Unhandled serror trap");
>> -}
>> -
>>   static const char *handler[]= {
>>           "Synchronous Abort",
>>           "IRQ",
>> @@ -38,11 +33,13 @@ static const char *handler[]= {
>>
>>   asmlinkage void do_bad_mode(struct cpu_user_regs *regs, int reason)
>>   {
>> -    uint64_t esr = READ_SYSREG64(ESR_EL2);
>> -    printk("Bad mode in %s handler detected, code 0x%08"PRIx64"\n",
>> -           handler[reason], esr);
>
>
> While you are modifying this function. Can you add a newline after the
> declarations?
>
> Other than that:
>
> Reviewed-by: Julien Grall <julien.grall@linaro.org>
>
> Regards,
>
> --
> Julien Grall
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen: arm64: more useful logging on bad trap.
  2015-02-18 15:47   ` Jintack Lim
@ 2015-02-18 16:00     ` Julien Grall
  2015-02-18 16:04       ` Ian Campbell
  2015-02-18 16:29       ` Jintack Lim
  2015-02-18 16:01     ` Ian Campbell
  1 sibling, 2 replies; 8+ messages in thread
From: Julien Grall @ 2015-02-18 16:00 UTC (permalink / raw)
  To: Jintack Lim, Ian Campbell
  Cc: Christoffer Dall, Stefano Stabellini, Tim Deegan, Shih-Wei Li, xen-devel


On 18/02/2015 15:47, Jintack Lim wrote:
> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> Dump the register state before panicing so we have some clue where the
>> issue occurred. Also decode the ESR register a bit to save having to
>> grab a pen and paper.
>>
>> ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
>> we already do correctly in the main trap handler.
>>
>> While here notice that do_trap_serror is never called and remove it.
>>
>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> Cc: jintack@cs.columbia.edu
>> ---
>> Jintack, since you have a system which is exhibiting SError issues I
>> wonder if I could prevail on you to give this patch a try on your
>> system and report on the output. I've only compile tested this myself.
>> ---
>
> Hi Ian,

Hi Jintack,

> this is the output I got from the machine.

OOI, what is the machine?

>
> Xen 4.5.0 (c/s Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty) EFI
> loader
> Using configuration file 'xen.cfg'
> vmlinuz-3.18.0+: 0x00000083fbd8f000-0x00000083fc5195c0
>   Xen 4.5.0
> (XEN) Xen version 4.5.0 (jintack@) (gcc (Ubuntu/Linaro
> 4.8.2-19ubuntu1) 4.8.2) debug=n Wed Feb 18 5
> (XEN) Latest ChangeSet: Mon Jan 12 11:30:05 2015 -0500
> git:a8ac229-dirty

You tree is marked dirty, did you made other changes than this patch?

> (XEN) Processor: 410fd070: "ARM Limited", variant: 0x0, part 0xd07,
> rev 0x0
> (XEN) 64-bit Execution:
> (XEN)   Processor Features: 0000000000002222 0000000000000000
> (XEN)     Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
> (XEN)     Extensions: FloatingPoint AdvancedSIMD
> (XEN)   Debug Features: 0000000010305106 0000000000000000
> (XEN)   Auxiliary Features: 0000000000000000 0000000000000000
> (XEN)   Memory Model Features: 0000000000001124 0000000000000000
> (XEN)   ISA Features:  0000000000011120 0000000000000000
> (XEN) 32-bit Execution:
> (XEN)   Processor Features: 00000131:00011011
> (XEN)     Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
> (XEN)     Extensions: GenericTimer Security
> (XEN)   Debug Features: 03010066
> (XEN)   Auxiliary Features: 00000000
> (XEN)   Memory Model Features: 10101105 40000000 01260000 02102211
> (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142
> 00011121
> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
> (XEN) Using generic timer at 187500 KHz
> (XEN) GICv2 initialization:
> (XEN)         gic_dist_addr=00000000e1110000
> (XEN)         gic_cpu_addr=00000000e112f000
> (XEN)         gic_hyp_addr=00000000e1140000
> (XEN)         gic_vcpu_addr=00000000e1160000
> (XEN)         gic_maintenance_irq=24
> (XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b).
> (XEN) Using scheduler: SMP Credit Scheduler (credit)
> (XEN) Bad mode in Error handler detected, code 0xbf000000, EC=2f, IL=1
> ISS=1000000
> (XEN) ----[ Xen-4.5.0  arm64  debug=n  Not tainted ]----
> (XEN) CPU:    0
> (XEN) PC:     00000000002770f0 start_xen+0x920/0xc98

Can you try to get the line of code related to this PC? You could do it 
with addr2line.

[..]

> (XEN) Xen call trace:
> (XEN)    [<00000000002770f0>] start_xen+0x920/0xc98 (PC)
> (XEN)    [<00000000002770e8>] start_xen+0x918/0xc98 (LR)

It might be good to get those 2 too.

Regards,

-- 
Julien Grall

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen: arm64: more useful logging on bad trap.
  2015-02-18 15:47   ` Jintack Lim
  2015-02-18 16:00     ` Julien Grall
@ 2015-02-18 16:01     ` Ian Campbell
  2015-02-18 16:30       ` Jintack Lim
  1 sibling, 1 reply; 8+ messages in thread
From: Ian Campbell @ 2015-02-18 16:01 UTC (permalink / raw)
  To: Jintack Lim
  Cc: Stefano Stabellini, Julien Grall, Tim Deegan, xen-devel,
	Christoffer Dall, Shih-Wei Li

On Wed, 2015-02-18 at 10:47 -0500, Jintack Lim wrote:
> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
> > Dump the register state before panicing so we have some clue where the
> > issue occurred. Also decode the ESR register a bit to save having to
> > grab a pen and paper.
> >
> > ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
> > we already do correctly in the main trap handler.
> >
> > While here notice that do_trap_serror is never called and remove it.
> >
> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
> > Cc: jintack@cs.columbia.edu
> > ---
> > Jintack, since you have a system which is exhibiting SError issues I
> > wonder if I could prevail on you to give this patch a try on your
> > system and report on the output. I've only compile tested this myself.
> > ---
> 
> Hi Ian,
> this is the output I got from the machine.

Thanks, may I add a "Tested-by: Jintack Lim <jintack@cs.columbia.edu>"
please?


> (XEN) Bad mode in Error handler detected, code 0xbf000000, EC=2f, IL=1
> ISS=1000000

I notice I missed a "," here after "IL=1", which I'll fix for v2.

The line is also a bit long so I've split into two lines.

Ian.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen: arm64: more useful logging on bad trap.
  2015-02-18 16:00     ` Julien Grall
@ 2015-02-18 16:04       ` Ian Campbell
  2015-02-18 16:29       ` Jintack Lim
  1 sibling, 0 replies; 8+ messages in thread
From: Ian Campbell @ 2015-02-18 16:04 UTC (permalink / raw)
  To: Julien Grall
  Cc: Stefano Stabellini, Tim Deegan, xen-devel, Christoffer Dall,
	Jintack Lim, Shih-Wei Li

On Wed, 2015-02-18 at 16:00 +0000, Julien Grall wrote:
> Can you try to get the line of code related to this PC? You could do it 
> with addr2line.

>From private mail I know that this machine sees issues under native
Linux too, I suspect a h/w fault so I don't think it is worth diagnosing
further under Xen until that is sorted out.

Ian.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen: arm64: more useful logging on bad trap.
  2015-02-18 16:00     ` Julien Grall
  2015-02-18 16:04       ` Ian Campbell
@ 2015-02-18 16:29       ` Jintack Lim
  1 sibling, 0 replies; 8+ messages in thread
From: Jintack Lim @ 2015-02-18 16:29 UTC (permalink / raw)
  To: Julien Grall
  Cc: Ian Campbell, Stefano Stabellini, Tim Deegan, xen-devel,
	Christoffer Dall, Shih-Wei Li

On Wed, Feb 18, 2015 at 11:00 AM, Julien Grall <julien.grall@linaro.org> wrote:
>
> On 18/02/2015 15:47, Jintack Lim wrote:
>>
>> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell <ian.campbell@citrix.com>
>> wrote:
>>>
>>> Dump the register state before panicing so we have some clue where the
>>> issue occurred. Also decode the ESR register a bit to save having to
>>> grab a pen and paper.
>>>
>>> ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
>>> we already do correctly in the main trap handler.
>>>
>>> While here notice that do_trap_serror is never called and remove it.
>>>
>>> Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>>> Cc: jintack@cs.columbia.edu
>>> ---
>>> Jintack, since you have a system which is exhibiting SError issues I
>>> wonder if I could prevail on you to give this patch a try on your
>>> system and report on the output. I've only compile tested this myself.
>>> ---
>>
>>
>> Hi Ian,
>
>
> Hi Jintack,
>
Hi Julien,

>> this is the output I got from the machine.
>
>
> OOI, what is the machine?
It is a Seattle machine.

>
>>
>> Xen 4.5.0 (c/s Mon Jan 12 11:30:05 2015 -0500 git:a8ac229-dirty) EFI
>> loader
>> Using configuration file 'xen.cfg'
>> vmlinuz-3.18.0+: 0x00000083fbd8f000-0x00000083fc5195c0
>>   Xen 4.5.0
>> (XEN) Xen version 4.5.0 (jintack@) (gcc (Ubuntu/Linaro
>> 4.8.2-19ubuntu1) 4.8.2) debug=n Wed Feb 18 5
>> (XEN) Latest ChangeSet: Mon Jan 12 11:30:05 2015 -0500
>> git:a8ac229-dirty
>
>
> You tree is marked dirty, did you made other changes than this patch?
No. This patch is the only change.
Basically, I checked out to RELEASE-4.5.0, and applied the patch there.

>
>
>> (XEN) Processor: 410fd070: "ARM Limited", variant: 0x0, part 0xd07,
>> rev 0x0
>> (XEN) 64-bit Execution:
>> (XEN)   Processor Features: 0000000000002222 0000000000000000
>> (XEN)     Exception Levels: EL3:64+32 EL2:64+32 EL1:64+32 EL0:64+32
>> (XEN)     Extensions: FloatingPoint AdvancedSIMD
>> (XEN)   Debug Features: 0000000010305106 0000000000000000
>> (XEN)   Auxiliary Features: 0000000000000000 0000000000000000
>> (XEN)   Memory Model Features: 0000000000001124 0000000000000000
>> (XEN)   ISA Features:  0000000000011120 0000000000000000
>> (XEN) 32-bit Execution:
>> (XEN)   Processor Features: 00000131:00011011
>> (XEN)     Instruction Sets: AArch32 A32 Thumb Thumb-2 Jazelle
>> (XEN)     Extensions: GenericTimer Security
>> (XEN)   Debug Features: 03010066
>> (XEN)   Auxiliary Features: 00000000
>> (XEN)   Memory Model Features: 10101105 40000000 01260000 02102211
>> (XEN)  ISA Features: 02101110 13112111 21232042 01112131 00011142
>> 00011121
>> (XEN) Generic Timer IRQ: phys=30 hyp=26 virt=27
>> (XEN) Using generic timer at 187500 KHz
>> (XEN) GICv2 initialization:
>> (XEN)         gic_dist_addr=00000000e1110000
>> (XEN)         gic_cpu_addr=00000000e112f000
>> (XEN)         gic_hyp_addr=00000000e1140000
>> (XEN)         gic_vcpu_addr=00000000e1160000
>> (XEN)         gic_maintenance_irq=24
>> (XEN) GICv2: 448 lines, 8 cpus, secure (IID 0200143b).
>> (XEN) Using scheduler: SMP Credit Scheduler (credit)
>> (XEN) Bad mode in Error handler detected, code 0xbf000000, EC=2f, IL=1
>> ISS=1000000
>> (XEN) ----[ Xen-4.5.0  arm64  debug=n  Not tainted ]----
>> (XEN) CPU:    0
>> (XEN) PC:     00000000002770f0 start_xen+0x920/0xc98
>
>
> Can you try to get the line of code related to this PC? You could do it with
> addr2line.
Please see below comments.
>
> [..]
>
>> (XEN) Xen call trace:
>> (XEN)    [<00000000002770f0>] start_xen+0x920/0xc98 (PC)
>> (XEN)    [<00000000002770e8>] start_xen+0x918/0xc98 (LR)
>
>
> It might be good to get those 2 too.

[jintack@seattle_2 ~/xen_4.5]$addr2line -C -f -e xen/xen-syms 0x00000000002770f0
start_xen
/home/jintack/xen_4.5/xen/arch/arm/setup.c:786
--> PC is iommu_setup()

[jintack@seattle_2 ~/xen_4.5]$addr2line -C -f -e xen/xen-syms 0x00000000002770e8
start_xen
/home/jintack/xen_4.5/xen/arch/arm/setup.c:783
--> LR is local_irq_enable()

It's a bit weird that PC is ahead of LR.

Thanks,
Jintack

>
> Regards,
>
> --
> Julien Grall
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: [PATCH] xen: arm64: more useful logging on bad trap.
  2015-02-18 16:01     ` Ian Campbell
@ 2015-02-18 16:30       ` Jintack Lim
  0 siblings, 0 replies; 8+ messages in thread
From: Jintack Lim @ 2015-02-18 16:30 UTC (permalink / raw)
  To: Ian Campbell
  Cc: Stefano Stabellini, Julien Grall, Tim Deegan, xen-devel,
	Christoffer Dall, Shih-Wei Li

On Wed, Feb 18, 2015 at 11:01 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
> On Wed, 2015-02-18 at 10:47 -0500, Jintack Lim wrote:
>> On Wed, Feb 18, 2015 at 10:19 AM, Ian Campbell <ian.campbell@citrix.com> wrote:
>> > Dump the register state before panicing so we have some clue where the
>> > issue occurred. Also decode the ESR register a bit to save having to
>> > grab a pen and paper.
>> >
>> > ESR_EL2 is a 32-bit register, so use SYSREG_READ32 not ..._READ64, as
>> > we already do correctly in the main trap handler.
>> >
>> > While here notice that do_trap_serror is never called and remove it.
>> >
>> > Signed-off-by: Ian Campbell <ian.campbell@citrix.com>
>> > Cc: jintack@cs.columbia.edu
>> > ---
>> > Jintack, since you have a system which is exhibiting SError issues I
>> > wonder if I could prevail on you to give this patch a try on your
>> > system and report on the output. I've only compile tested this myself.
>> > ---
>>
>> Hi Ian,
>> this is the output I got from the machine.
>
> Thanks, may I add a "Tested-by: Jintack Lim <jintack@cs.columbia.edu>"
> please?

Yes!, Thanks.

>
>
>> (XEN) Bad mode in Error handler detected, code 0xbf000000, EC=2f, IL=1
>> ISS=1000000
>
> I notice I missed a "," here after "IL=1", which I'll fix for v2.
>
> The line is also a bit long so I've split into two lines.
>
> Ian.
>
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2015-02-18 16:30 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-02-18 15:19 [PATCH] xen: arm64: more useful logging on bad trap Ian Campbell
2015-02-18 15:36 ` Julien Grall
2015-02-18 15:47   ` Jintack Lim
2015-02-18 16:00     ` Julien Grall
2015-02-18 16:04       ` Ian Campbell
2015-02-18 16:29       ` Jintack Lim
2015-02-18 16:01     ` Ian Campbell
2015-02-18 16:30       ` Jintack Lim

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.