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
next 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: linkBe 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.