linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* arm64: next-20170614 panics on boot
@ 2017-06-15 12:08 Yury Norov
  2017-06-15 12:33 ` Yury Norov
  0 siblings, 1 reply; 4+ messages in thread
From: Yury Norov @ 2017-06-15 12:08 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel

Hi all,

Today's linux next falls into panic in init_IRQ():
arch/arm64/kernel/irq.c:
 53 void __init init_IRQ(void)
 54 {
 55         irqchip_init();
 56         if (!handle_arch_irq)
 57                 panic("No interrupt controller found.");
 58 }


Bisecting points to the patch 6fedb069def034 ("of: Provide dummy
of_device_compatible_match() for compile-testing"), but reverting it
doesn't help. It seems like yesterday's linux-next also hangs.  Right
now I cannot continue with debugging, but if nothing will get clear,
I'll back to it at this evening.

Yury

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

* Re: arm64: next-20170614 panics on boot
  2017-06-15 12:08 arm64: next-20170614 panics on boot Yury Norov
@ 2017-06-15 12:33 ` Yury Norov
  2017-06-16  9:51   ` Yury Norov
  0 siblings, 1 reply; 4+ messages in thread
From: Yury Norov @ 2017-06-15 12:33 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]

On Thu, Jun 15, 2017 at 03:08:40PM +0300, Yury Norov wrote:
> Hi all,
> 
> Today's linux next falls into panic in init_IRQ():
> arch/arm64/kernel/irq.c:
>  53 void __init init_IRQ(void)
>  54 {
>  55         irqchip_init();
>  56         if (!handle_arch_irq)
>  57                 panic("No interrupt controller found.");
>  58 }
> 
> 
> Bisecting points to the patch 6fedb069def034 ("of: Provide dummy
> of_device_compatible_match() for compile-testing"), but reverting it
> doesn't help. It seems like yesterday's linux-next also hangs.  Right
> now I cannot continue with debugging, but if nothing will get clear,
> I'll back to it at this evening.

Sorry, forgot to attach the config. This is it. Also, I run arm64 on
qemu.

Yury

[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 35566 bytes --]

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

* Re: arm64: next-20170614 panics on boot
  2017-06-15 12:33 ` Yury Norov
@ 2017-06-16  9:51   ` Yury Norov
  2017-06-16 10:53     ` Marc Zyngier
  0 siblings, 1 reply; 4+ messages in thread
From: Yury Norov @ 2017-06-16  9:51 UTC (permalink / raw)
  To: linux-arm-kernel, linux-kernel
  Cc: Thomas Gleixner, Jason Cooper, Marc Zyngier

(CC irqchip maintainers)

On Thu, Jun 15, 2017 at 03:33:37PM +0300, Yury Norov wrote:
> On Thu, Jun 15, 2017 at 03:08:40PM +0300, Yury Norov wrote:
> > Hi all,
> > 
> > Today's linux next falls into panic in init_IRQ():
> > arch/arm64/kernel/irq.c:
> >  53 void __init init_IRQ(void)
> >  54 {
> >  55         irqchip_init();
> >  56         if (!handle_arch_irq)
> >  57                 panic("No interrupt controller found.");
> >  58 }
> > 
> > 
> > Bisecting points to the patch 6fedb069def034 ("of: Provide dummy
> > of_device_compatible_match() for compile-testing"), but reverting it
> > doesn't help. It seems like yesterday's linux-next also hangs.  Right
> > now I cannot continue with debugging, but if nothing will get clear,
> > I'll back to it at this evening.
> 
> Sorry, forgot to attach the config. This is it. Also, I run arm64 on
> qemu.

The next-20170616 boots well for me. I didn't manage to bisect the
source of problem - it points to different commmits, and reverting
them doesn't help. The source of the problem is that irqchip_init()
doesn't set the handle_arch_irq. It should be done in 
of_irq_init() at the line

drivers/of/irq.c:
542         while (!list_empty(&intc_desc_list)) {
        ...
561                         ret = desc->irq_init_cb(desc->dev,
562                                                 desc->interrupt_parent);
        ...
586         }

On next-20170614 and 15 intc_desc_list is empty at the point. It
should be populated earlier in the loop
510         for_each_matching_node_and_match(np, matches, &match)

But np becomes 0 at the 1st iteration, and so the program doesn't enter the
loop. At the first glance there's no recent changes in related code. Maybe it's dts
issue?..

Yury

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

* Re: arm64: next-20170614 panics on boot
  2017-06-16  9:51   ` Yury Norov
@ 2017-06-16 10:53     ` Marc Zyngier
  0 siblings, 0 replies; 4+ messages in thread
From: Marc Zyngier @ 2017-06-16 10:53 UTC (permalink / raw)
  To: Yury Norov, linux-arm-kernel, linux-kernel; +Cc: Thomas Gleixner, Jason Cooper

On 16/06/17 10:51, Yury Norov wrote:
> (CC irqchip maintainers)
> 
> On Thu, Jun 15, 2017 at 03:33:37PM +0300, Yury Norov wrote:
>> On Thu, Jun 15, 2017 at 03:08:40PM +0300, Yury Norov wrote:
>>> Hi all,
>>>
>>> Today's linux next falls into panic in init_IRQ():
>>> arch/arm64/kernel/irq.c:
>>>  53 void __init init_IRQ(void)
>>>  54 {
>>>  55         irqchip_init();
>>>  56         if (!handle_arch_irq)
>>>  57                 panic("No interrupt controller found.");
>>>  58 }
>>>
>>>
>>> Bisecting points to the patch 6fedb069def034 ("of: Provide dummy
>>> of_device_compatible_match() for compile-testing"), but reverting it
>>> doesn't help. It seems like yesterday's linux-next also hangs.  Right
>>> now I cannot continue with debugging, but if nothing will get clear,
>>> I'll back to it at this evening.
>>
>> Sorry, forgot to attach the config. This is it. Also, I run arm64 on
>> qemu.
> 
> The next-20170616 boots well for me. I didn't manage to bisect the
> source of problem - it points to different commmits, and reverting
> them doesn't help. The source of the problem is that irqchip_init()
> doesn't set the handle_arch_irq. It should be done in 
> of_irq_init() at the line
> 
> drivers/of/irq.c:
> 542         while (!list_empty(&intc_desc_list)) {
>         ...
> 561                         ret = desc->irq_init_cb(desc->dev,
> 562                                                 desc->interrupt_parent);
>         ...
> 586         }
> 
> On next-20170614 and 15 intc_desc_list is empty at the point. It
> should be populated earlier in the loop
> 510         for_each_matching_node_and_match(np, matches, &match)
> 
> But np becomes 0 at the 1st iteration, and so the program doesn't enter the
> loop. At the first glance there's no recent changes in related code. Maybe it's dts
> issue?..

Dunno. I'm booting -next as of today in various arm64 VMs, and
everything seems fine. Even 20170614 boots fine in the same
configuration. You'll have to investigate a bit more, I'm afraid.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

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

end of thread, other threads:[~2017-06-16 10:54 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-06-15 12:08 arm64: next-20170614 panics on boot Yury Norov
2017-06-15 12:33 ` Yury Norov
2017-06-16  9:51   ` Yury Norov
2017-06-16 10:53     ` Marc Zyngier

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).