All of lore.kernel.org
 help / color / mirror / Atom feed
From: khalasa@piap.pl (Krzysztof Hałasa)
To: linux-arm-kernel@lists.infradead.org,
	lkml <linux-kernel@vger.kernel.org>,
	Anton Vorontsov <anton@enomsg.org>,
	Yinghai Lu <yinghai@kernel.org>,
	Russell King <linux@arm.linux.org.uk>
Subject: [ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+
Date: Fri, 28 Feb 2014 12:00:12 +0100	[thread overview]
Message-ID: <m3eh2nqz7n.fsf@t19.piap.pl> (raw)

Hello,

Linux version 3.14.0-rc4+ (current tip, no extra patches), CPU is Cavium
Econa CNS3420, board is Gateworks Laguna GW2388-4 (masqueraded as
CNS3420VB).


Issue #1 ###################################################

kernel BUG at mm/vmalloc.c:1132!
PC is at vm_area_add_early+0x20/0x84
LR is at add_static_vm_early+0xc/0x60

The problem is cns3xxx_pcie_init() (device_initcall) calls the "early"
iotable_init(). I'll attach the patch.


Issue #2 ###################################################

PCI hangs system completely while trying to access any PCI MMIO region
(plain IO not tested).

The guilty commit is 928bea964827d7824b548c1f8e06eccbbc4d0d7d:

    PCI: Delay enabling bridges until they're needed

    We currently enable PCI bridges after scanning a bus and assigning
    resources.  This is often done in arch code.

    This patch changes this so we don't enable a bridge until necessary, i.e.,
    until we enable a PCI device behind the bridge.  We do this in the generic
    pci_enable_device() path, so this also removes the arch-specific code to
    enable bridges.

Reverting changes in arch/arm/kernel/bios32.c, drivers/pci/bus.c and
include/linux/pci.h (= essentially adding pci_enable_bridges(bus) in
ARM's pci_common_init_dev()) makes it work again.

Options?


Issue #3 ###################################################

NR_IRQS:16 nr_irqs:96 96

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

I'm having problems understanding how is machine_desc->nr_irqs supposed
to work with CONFIG_ARM_GIC and CONFIG_SPARSE_IRQ set.

machine_desc->nr_irqs is set to NR_IRQS_CNS3XXX =
IRQ_TC11MP_GIC_START + 64 = 32 + 64 = 96.

At start, machine_desc->nr_irqs are pre-allocated via
start_kernel() -> early_irq_init().

Then, gic_init(0, 29, ...) ->  gic_init_bases(0, 29, ...) tries this
(and fails):

	/*
	 * For primary GICs, skip over SGIs.
	 * For secondary GICs, skip over PPIs, too.
	 */
	irq_start = (effectively) 16;

	irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
	if (IS_ERR_VALUE(irq_base)) {
		WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
		     irq_start);

Does this mean machine_desc->nr_irqs is to be kept at 16
(NR_IRQS_LEGACY) or less, so it doesn't conflict with gic_init()?

Or perhaps gic_init() shouldn't warn about this?

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

WARNING: multiple messages have this Message-ID (diff)
From: khalasa@piap.pl (Krzysztof Hałasa)
To: linux-arm-kernel@lists.infradead.org
Subject: [ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+
Date: Fri, 28 Feb 2014 12:00:12 +0100	[thread overview]
Message-ID: <m3eh2nqz7n.fsf@t19.piap.pl> (raw)

Hello,

Linux version 3.14.0-rc4+ (current tip, no extra patches), CPU is Cavium
Econa CNS3420, board is Gateworks Laguna GW2388-4 (masqueraded as
CNS3420VB).


Issue #1 ###################################################

kernel BUG at mm/vmalloc.c:1132!
PC is at vm_area_add_early+0x20/0x84
LR is at add_static_vm_early+0xc/0x60

The problem is cns3xxx_pcie_init() (device_initcall) calls the "early"
iotable_init(). I'll attach the patch.


Issue #2 ###################################################

PCI hangs system completely while trying to access any PCI MMIO region
(plain IO not tested).

The guilty commit is 928bea964827d7824b548c1f8e06eccbbc4d0d7d:

    PCI: Delay enabling bridges until they're needed

    We currently enable PCI bridges after scanning a bus and assigning
    resources.  This is often done in arch code.

    This patch changes this so we don't enable a bridge until necessary, i.e.,
    until we enable a PCI device behind the bridge.  We do this in the generic
    pci_enable_device() path, so this also removes the arch-specific code to
    enable bridges.

Reverting changes in arch/arm/kernel/bios32.c, drivers/pci/bus.c and
include/linux/pci.h (= essentially adding pci_enable_bridges(bus) in
ARM's pci_common_init_dev()) makes it work again.

Options?


Issue #3 ###################################################

NR_IRQS:16 nr_irqs:96 96

WARNING: at drivers/irqchip/irq-gic.c:952 gic_init_bases+0xe4/0x2b8()
Cannot allocate irq_descs @ IRQ16, assuming pre-allocated
Backtrace:
gic_init_bases    from cns3xxx_init_irq+0x24/0x34
cns3xxx_init_irq  from init_IRQ+0x24/0x2c
init_IRQ          from start_kernel+0x1a8/0x338
start_kernel      from 0x2000806c

I'm having problems understanding how is machine_desc->nr_irqs supposed
to work with CONFIG_ARM_GIC and CONFIG_SPARSE_IRQ set.

machine_desc->nr_irqs is set to NR_IRQS_CNS3XXX =
IRQ_TC11MP_GIC_START + 64 = 32 + 64 = 96.

At start, machine_desc->nr_irqs are pre-allocated via
start_kernel() -> early_irq_init().

Then, gic_init(0, 29, ...) ->  gic_init_bases(0, 29, ...) tries this
(and fails):

	/*
	 * For primary GICs, skip over SGIs.
	 * For secondary GICs, skip over PPIs, too.
	 */
	irq_start = (effectively) 16;

	irq_base = irq_alloc_descs(irq_start, 16, gic_irqs, numa_node_id());
	if (IS_ERR_VALUE(irq_base)) {
		WARN(1, "Cannot allocate irq_descs @ IRQ%d, assuming pre-allocated\n",
		     irq_start);

Does this mean machine_desc->nr_irqs is to be kept at 16
(NR_IRQS_LEGACY) or less, so it doesn't conflict with gic_init()?

Or perhaps gic_init() shouldn't warn about this?

-- 
Krzysztof Halasa

Research Institute for Automation and Measurements PIAP
Al. Jerozolimskie 202, 02-486 Warsaw, Poland

             reply	other threads:[~2014-02-28 11:08 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-28 11:00 Krzysztof Hałasa [this message]
2014-02-28 11:00 ` [ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+ Krzysztof Hałasa
2014-02-28 11:12 ` [PATCH] CNS3xxx: Fix PCIe early iotable_init() Krzysztof Hałasa
2014-02-28 11:12   ` Krzysztof Hałasa
2014-02-28 11:15   ` Arnd Bergmann
2014-02-28 11:15     ` Arnd Bergmann
2014-03-04  6:46     ` Krzysztof Hałasa
2014-03-04  6:46       ` Krzysztof Hałasa
2014-02-28 11:31 ` [ARM] CNS3xxx: 3 regressions identified in v3.14-rc4+ Arnd Bergmann
2014-02-28 11:31   ` Arnd Bergmann
2014-03-04  7:37 ` [PATCH v2] CNS3xxx: Fix PCIe early iotable_init() Krzysztof Hałasa
2014-03-04  7:37   ` Krzysztof Hałasa
2014-03-04  9:08   ` Krzysztof Hałasa
2014-03-04  9:08     ` Krzysztof Hałasa
2014-03-17 14:37     ` Arnd Bergmann
2014-03-17 14:37       ` Arnd Bergmann
2014-03-18  9:36       ` Krzysztof Hałasa
2014-03-18  9:36         ` Krzysztof Hałasa
2014-03-04 10:37 ` [PATCH2] CNS3xxx: Fix a WARN() related to IRQ allocation Krzysztof Hałasa
2014-03-04 10:37   ` Krzysztof Hałasa
2014-03-04 10:50 ` Krzysztof Hałasa
2014-03-04 10:50   ` Krzysztof Hałasa
2014-03-17 14:33   ` Arnd Bergmann
2014-03-17 14:33     ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3eh2nqz7n.fsf@t19.piap.pl \
    --to=khalasa@piap.pl \
    --cc=anton@enomsg.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@arm.linux.org.uk \
    --cc=yinghai@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.