* next-20170125 hangs on aarch64
@ 2017-01-29 10:12 Yury Norov
2017-01-29 12:21 ` Yury Norov
0 siblings, 1 reply; 5+ messages in thread
From: Yury Norov @ 2017-01-29 10:12 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel; +Cc: ynorov
Hi all,
I pulled next-20170125 kernel, and found it hanged on boot. The exact reason is
panic on dereferencing of the 0xffffffc8 address, which is most probably the
attempt to dereference the ENOSYS error code as the address. next-20170124 works
fine, at least it boots.
Does anyone have details on that?
Yury
#0 arch_counter_get_cntvct () at
./arch/arm64/include/asm/arch_timer.h:151
#1 __delay (cycles=1024) at arch/arm64/lib/delay.c:31
#2 0xffff00000838b430 in __const_udelay (xloops=<optimized out>) at
arch/arm64/lib/delay.c:41
#3 0xffff00000816a894 in panic (fmt=<optimized out>) at
kernel/panic.c:295
#4 0xffff0000080c1238 in do_exit (code=11) at kernel/exit.c:780
#5 0xffff0000080888f0 in die (str=<optimized out>,
regs=0xffff000008d63d30 <init_thread_union+15664>, err=<optimized out>)
at arch/arm64/kernel/traps.c:295
#6 0xffff0000080998c4 in __do_kernel_fault (mm=0x0, addr=4294967240, esr=2483027972,
regs=0xffff000008d63d30 <init_thread_union+15664>) at arch/arm64/mm/fault.c:185
#7 0xffff000008097244 in __do_kernel_fault (regs=<optimized out>, esr=<optimized out>,
addr=<optimized out>, mm=<optimized out>) at arch/arm64/mm/fault.c:419
#8 do_page_fault (addr=4294967240, esr=2483027972,
regs=0xffff000008d63d30 <init_thread_union+15664>) at arch/arm64/mm/fault.c:443
#9 0xffff000008097334 in do_translation_fault (addr=<optimized out>, esr=<optimized out>,
regs=<optimized out>) at arch/arm64/mm/fault.c:469
#10 0xffff000008081298 in do_mem_abort (addr=4294967240, esr=2483027972,
regs=0xffff000008d63d30 <init_thread_union+15664>) at arch/arm64/mm/fault.c:577
#11 0xffff000008082604 in el1_sync () at arch/arm64/kernel/entry.S:438
#12 0xffff000008082604 in el1_sync () at arch/arm64/kernel/entry.S:438
[...]
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: next-20170125 hangs on aarch64
2017-01-29 10:12 next-20170125 hangs on aarch64 Yury Norov
@ 2017-01-29 12:21 ` Yury Norov
2017-01-30 11:48 ` James Morse
0 siblings, 1 reply; 5+ messages in thread
From: Yury Norov @ 2017-01-29 12:21 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote:
> Hi all,
>
> I pulled next-20170125 kernel, and found it hanged on boot. The exact reason is
> panic on dereferencing of the 0xffffffc8 address, which is most probably the
> attempt to dereference the ENOSYS error code as the address. next-20170124 works
> fine, at least it boots.
>
> Does anyone have details on that?
>
> Yury
UPD:
I run qemu for testing.
The true failure backtrace is like below. The bad dereference happens for me in
arm_smccc_hvc() function in macro SMCCC.
Yury
Backtrace:
#0 0xffff00000808f7a8 in arm_smccc_hvc () at
arch/arm64/kernel/smccc-call.S:50
#1 0xffff000008745ea0 in __invoke_psci_fn_hvc (function_id=<optimized out>, arg0=<optimized out>,
arg1=<optimized out>, arg2=<optimized out>) at drivers/firmware/psci.c:119
#2 0xffff000008745d18 in psci_migrate_info_type () at drivers/firmware/psci.c:204
#3 0xffff000008ca150c in psci_init_migrate () at drivers/firmware/psci.c:465
#4 psci_probe () at drivers/firmware/psci.c:539
#5 0xffff000008ca1684 in psci_0_2_init (np=<optimized out>) at drivers/firmware/psci.c:571
#6 0xffff000008ca16d8 in psci_dt_init () at drivers/firmware/psci.c:637
#7 0xffff000008c62914 in setup_arch (cmdline_p=<optimized out>) at arch/arm64/kernel/setup.c:287
#8 0xffff000008c6082c in start_kernel () at init/main.c:509
#9 0xffff000008c601e0 in __primary_switched () at arch/arm64/kernel/head.S:452
Listing:
│0xffff00000808f790 <arm_smccc_hvc> hvc #0x0
│0xffff00000808f794 <arm_smccc_hvc+4> ldr x4, [sp]
│0xffff00000808f798 <arm_smccc_hvc+8> stp x0, x1, [x4]
│0xffff00000808f79c <arm_smccc_hvc+12> stp x2, x3, [x4,#16]
│0xffff00000808f7a0 <arm_smccc_hvc+16> ldr x4, [sp,#8]
│0xffff00000808f7a4 <arm_smccc_hvc+20> cbz x4, 0xffff00000808f7b8 <arm_smccc_hvc+40>
>│0xffff00000808f7a8 <arm_smccc_hvc+24 ldr x9, [x4]
│0xffff00000808f7ac <arm_smccc_hvc+28> cmp x9, #0x1
│0xffff00000808f7b0 <arm_smccc_hvc+32> b.ne 0xffff00000808f7b8 <arm_smccc_hvc+40>
│0xffff00000808f7b4 <arm_smccc_hvc+36> str x6, [x4,#8]
│0xffff00000808f7b8 <arm_smccc_hvc+40> ret
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: next-20170125 hangs on aarch64
2017-01-29 12:21 ` Yury Norov
@ 2017-01-30 11:48 ` James Morse
2017-01-30 12:51 ` Yury Norov
0 siblings, 1 reply; 5+ messages in thread
From: James Morse @ 2017-01-30 11:48 UTC (permalink / raw)
To: Yury Norov; +Cc: linux-kernel, linux-arm-kernel, Andy Gross
Hi Yury,
[CC: Andy Gross]
On 29/01/17 12:21, Yury Norov wrote:
> On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote:
>> Hi all,
>>
>> I pulled next-20170125 kernel, and found it hanged on boot. The exact reason is
>> panic on dereferencing of the 0xffffffc8 address, which is most probably the
>> attempt to dereference the ENOSYS error code as the address. next-20170124 works
>> fine, at least it boots.
>>
>> Does anyone have details on that?
I hit this with next-20170130 too, in /arch/arm64/kernel/smccc-call.S
aabde95fc543 changed the SMCCC macro to check for an optional quirk structure.
A previous patch provided:
> #define arm_smccc_smc(...) __arm_smccc_smc(__VA_ARGS__, NULL)
to handle the 'no quirk' case, but this missed HVC calls.
The following hunk fixes/hides it for me:
----------------------------%<----------------------------
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 72ecdca929b1..9e287a7d1822 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -15,18 +15,20 @@
#include <linux/arm-smccc.h>
#include <asm/asm-offsets.h>
- .macro SMCCC instr
+ .macro SMCCC instr, maybe_quirk = 0
.cfi_startproc
\instr #0
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
ldr x4, [sp, #8]
+ .if \maybe_quirk != 0
cbz x4, 1f /* no quirk structure */
ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
b.ne 1f
str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
+ .endif
1: ret
.cfi_endproc
.endm
@@ -38,7 +40,7 @@
* struct arm_smccc_quirk *quirk)
*/
ENTRY(__arm_smccc_smc)
- SMCCC smc
+ SMCCC smc, 1
ENDPROC(__arm_smccc_smc)
/*
----------------------------%<----------------------------
Thanks,
James
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: next-20170125 hangs on aarch64
2017-01-30 11:48 ` James Morse
@ 2017-01-30 12:51 ` Yury Norov
2017-01-31 7:18 ` Andy Gross
0 siblings, 1 reply; 5+ messages in thread
From: Yury Norov @ 2017-01-30 12:51 UTC (permalink / raw)
To: James Morse; +Cc: Andy Gross, linux-kernel, linux-arm-kernel
On Mon, Jan 30, 2017 at 11:48:01AM +0000, James Morse wrote:
> Hi Yury,
>
> [CC: Andy Gross]
>
> On 29/01/17 12:21, Yury Norov wrote:
> > On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote:
> >> Hi all,
> >>
> >> I pulled next-20170125 kernel, and found it hanged on boot. The exact reason is
> >> panic on dereferencing of the 0xffffffc8 address, which is most probably the
> >> attempt to dereference the ENOSYS error code as the address. next-20170124 works
> >> fine, at least it boots.
> >>
> >> Does anyone have details on that?
>
> I hit this with next-20170130 too, in /arch/arm64/kernel/smccc-call.S
> aabde95fc543 changed the SMCCC macro to check for an optional quirk structure.
>
> A previous patch provided:
> > #define arm_smccc_smc(...) __arm_smccc_smc(__VA_ARGS__, NULL)
>
> to handle the 'no quirk' case, but this missed HVC calls.
> The following hunk fixes/hides it for me:
It works for me too, but I think "ldr x4, [sp, #8]" should
also go under (.if \maybe_quirk != 0) condition - like below.
Yury
----------------------------%<----------------------------
diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
index 72ecdca929b1..9e287a7d1822 100644
--- a/arch/arm64/kernel/smccc-call.S
+++ b/arch/arm64/kernel/smccc-call.S
@@ -15,18 +15,20 @@
#include <linux/arm-smccc.h>
#include <asm/asm-offsets.h>
- .macro SMCCC instr
+ .macro SMCCC instr, maybe_quirk = 0
.cfi_startproc
\instr #0
ldr x4, [sp]
stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
+ .if \maybe_quirk != 0
ldr x4, [sp, #8]
cbz x4, 1f /* no quirk structure */
ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
b.ne 1f
str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
+ .endif
1: ret
.cfi_endproc
.endm
@@ -38,7 +40,7 @@
* struct arm_smccc_quirk *quirk)
*/
ENTRY(__arm_smccc_smc)
- SMCCC smc
+ SMCCC smc, 1
ENDPROC(__arm_smccc_smc)
/*
----------------------------%<----------------------------
^ permalink raw reply related [flat|nested] 5+ messages in thread
* Re: next-20170125 hangs on aarch64
2017-01-30 12:51 ` Yury Norov
@ 2017-01-31 7:18 ` Andy Gross
0 siblings, 0 replies; 5+ messages in thread
From: Andy Gross @ 2017-01-31 7:18 UTC (permalink / raw)
To: Yury Norov; +Cc: James Morse, linux-kernel, linux-arm-kernel
On Mon, Jan 30, 2017 at 06:21:25PM +0530, Yury Norov wrote:
> On Mon, Jan 30, 2017 at 11:48:01AM +0000, James Morse wrote:
> > Hi Yury,
> >
> > [CC: Andy Gross]
> >
> > On 29/01/17 12:21, Yury Norov wrote:
> > > On Sun, Jan 29, 2017 at 03:42:55PM +0530, Yury Norov wrote:
> > >> Hi all,
> > >>
> > >> I pulled next-20170125 kernel, and found it hanged on boot. The exact reason is
> > >> panic on dereferencing of the 0xffffffc8 address, which is most probably the
> > >> attempt to dereference the ENOSYS error code as the address. next-20170124 works
> > >> fine, at least it boots.
> > >>
> > >> Does anyone have details on that?
> >
> > I hit this with next-20170130 too, in /arch/arm64/kernel/smccc-call.S
> > aabde95fc543 changed the SMCCC macro to check for an optional quirk structure.
> >
> > A previous patch provided:
> > > #define arm_smccc_smc(...) __arm_smccc_smc(__VA_ARGS__, NULL)
> >
> > to handle the 'no quirk' case, but this missed HVC calls.
> > The following hunk fixes/hides it for me:
Wow, I botched this completely. I missed the hvc using the same macro. I'll
rework with the fixes below.
>
> It works for me too, but I think "ldr x4, [sp, #8]" should
> also go under (.if \maybe_quirk != 0) condition - like below.
Yes I believe so.
> ----------------------------%<----------------------------
> diff --git a/arch/arm64/kernel/smccc-call.S b/arch/arm64/kernel/smccc-call.S
> index 72ecdca929b1..9e287a7d1822 100644
> --- a/arch/arm64/kernel/smccc-call.S
> +++ b/arch/arm64/kernel/smccc-call.S
> @@ -15,18 +15,20 @@
> #include <linux/arm-smccc.h>
> #include <asm/asm-offsets.h>
>
> - .macro SMCCC instr
> + .macro SMCCC instr, maybe_quirk = 0
> .cfi_startproc
> \instr #0
> ldr x4, [sp]
> stp x0, x1, [x4, #ARM_SMCCC_RES_X0_OFFS]
> stp x2, x3, [x4, #ARM_SMCCC_RES_X2_OFFS]
> + .if \maybe_quirk != 0
> ldr x4, [sp, #8]
> cbz x4, 1f /* no quirk structure */
> ldr x9, [x4, #ARM_SMCCC_QUIRK_ID_OFFS]
> cmp x9, #ARM_SMCCC_QUIRK_QCOM_A6
> b.ne 1f
> str x6, [x4, ARM_SMCCC_QUIRK_STATE_OFFS]
> + .endif
> 1: ret
> .cfi_endproc
> .endm
> @@ -38,7 +40,7 @@
> * struct arm_smccc_quirk *quirk)
> */
> ENTRY(__arm_smccc_smc)
> - SMCCC smc
> + SMCCC smc, 1
> ENDPROC(__arm_smccc_smc)
>
> /*
> ----------------------------%<----------------------------
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2017-01-31 7:18 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-01-29 10:12 next-20170125 hangs on aarch64 Yury Norov
2017-01-29 12:21 ` Yury Norov
2017-01-30 11:48 ` James Morse
2017-01-30 12:51 ` Yury Norov
2017-01-31 7:18 ` Andy Gross
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).