* [PATCH v2 2/2] microblaze/PCI: Add pcibios_device_change_notifier for microblaze
From: Hiroo Matsumoto @ 2012-05-23 2:34 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, jbarnes, Kenji Kaneshige
pcibios_setup_bus_devices which sets DMA and IRQs of PCI device is called
only when boot, so DMA and IRQs of PCI device will not set when hotplug.
This patch adds pcibios_device_change_notifier which sets DMA and IRQs of
PCI device when PCI device adds, so DMA and IRQs of PCI device will be set
when boot and hotplug.
Signed-off-by: Hiroo MATSUMOTO <matsumoto.hiroo@jp.fujitsu.com>
---
arch/microblaze/include/asm/pci.h | 2 +-
arch/microblaze/pci/pci-common.c | 67 +++++++++++++++++++++---------------
2 files changed, 40 insertions(+), 29 deletions(-)
diff --git a/arch/microblaze/include/asm/pci.h b/arch/microblaze/include/asm/pci.h
index 0331376..8d11277 100644
--- a/arch/microblaze/include/asm/pci.h
+++ b/arch/microblaze/include/asm/pci.h
@@ -149,8 +149,8 @@ extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
const struct resource *rsrc,
resource_size_t *start, resource_size_t *end);
-extern void pcibios_setup_bus_devices(struct pci_bus *bus);
extern void pcibios_setup_bus_self(struct pci_bus *bus);
+extern void pcibios_setup_bus_notifier(void);
/* This part of code was originally in xilinx-pci.h */
#ifdef CONFIG_PCI_XILINX
diff --git a/arch/microblaze/pci/pci-common.c b/arch/microblaze/pci/pci-common.c
index 85f2ac1..bb28ede 100644
--- a/arch/microblaze/pci/pci-common.c
+++ b/arch/microblaze/pci/pci-common.c
@@ -1063,31 +1063,6 @@ void __devinit pcibios_setup_bus_self(struct pci_bus *bus)
pcibios_fixup_bridge(bus);
}
-void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- pr_debug("PCI: Fixup bus devices %d (%s)\n",
- bus->number, bus->self ? pci_name(bus->self) : "PHB");
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- /* Setup OF node pointer in archdata */
- dev->dev.of_node = pci_device_to_OF_node(dev);
-
- /* Fixup NUMA node as it may not be setup yet by the generic
- * code and is needed by the DMA init
- */
- set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
-
- /* Hook up default DMA ops */
- set_dma_ops(&dev->dev, pci_dma_ops);
- dev->dev.archdata.dma_data = (void *)PCI_DRAM_OFFSET;
-
- /* Read default IRQs and fixup if necessary */
- pci_read_irq_line(dev);
- }
-}
-
void __devinit pcibios_fixup_bus(struct pci_bus *bus)
{
/* When called from the generic PCI probe, read PCI<->PCI bridge
@@ -1099,9 +1074,6 @@ void __devinit pcibios_fixup_bus(struct pci_bus *bus)
/* Now fixup the bus bus */
pcibios_setup_bus_self(bus);
-
- /* Now fixup devices on that bus */
- pcibios_setup_bus_devices(bus);
}
EXPORT_SYMBOL(pcibios_fixup_bus);
@@ -1604,6 +1576,43 @@ static void __devinit pcibios_scan_phb(struct pci_controller *hose)
hose->last_busno = bus->subordinate;
}
+static int pcibios_device_change_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct pci_dev *dev = to_pci_dev(data);
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ /* Setup OF node pointer in archdata */
+ dev->dev.of_node = pci_device_to_OF_node(dev);
+
+ /* Fixup NUMA node as it may not be setup yet by the generic
+ * code and is needed by the DMA init
+ */
+ set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
+
+ /* Hook up default DMA ops */
+ set_dma_ops(&dev->dev, pci_dma_ops);
+ dev->dev.archdata.dma_data = (void *)PCI_DRAM_OFFSET;
+
+ /* Read default IRQs and fixup if necessary */
+ pci_read_irq_line(dev);
+
+ break;
+ }
+
+ return 0;
+}
+
+static struct notifier_block device_nb = {
+ .notifier_call = pcibios_device_change_notifier,
+};
+
+void __devinit pcibios_setup_bus_notifier(void)
+{
+ bus_register_notifier(&pci_bus_type, &device_nb);
+}
+
static int __init pcibios_init(void)
{
struct pci_controller *hose, *tmp;
@@ -1611,6 +1620,8 @@ static int __init pcibios_init(void)
printk(KERN_INFO "PCI: Probing PCI hardware\n");
+ pcibios_setup_bus_notifier();
+
/* Scan all of the recorded PCI controllers. */
list_for_each_entry_safe(hose, tmp, &hose_list, list_node) {
hose->last_busno = 0xff;
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 1/2] powerpc/PCI: Add pcibios_device_change_notifier for powerpc
From: Hiroo Matsumoto @ 2012-05-23 2:33 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, jbarnes, Kenji Kaneshige
pcibios_setup_bus_devices which sets DMA and IRQs of PCI device is called
only when boot, so DMA and IRQs of PCI device will not set when hotplug.
This patch adds pcibios_device_change_notifier which sets DMA and IRQs of
PCI device when PCI device adds, so DMA and IRQs of PCI device will be set
when boot and hotplug.
* Not patched pciehp message on powerpc platform
# echo 1 > /sys/bus/pci/slots/1/power
<snip>
pcieport 0000:02:01.0: PCI bridge to [bus 03-03]
pcieport 0000:02:01.0: bridge window [io 0xff7ee000-0xff7eefff]
pcieport 0000:02:01.0: bridge window [mem 0xa0100000-0xa01fffff]
pcieport 0000:02:01.0: bridge window [mem 0xa0200000-0xa02fffff 64bit pref]
pci 0000:03:00.0: no hotplug settings from platform
e1000e 0000:03:00.0: Disabling ASPM L1
e1000e 0000:03:00.0: enabling device (0000 -> 0002)
e1000e 0000:03:00.0: No usable DMA configuration, aborting
e1000e: probe of 0000:03:00.0 failed with error -5
* Patched pciehp message on powerpc platform
# echo 1 > /sys/bus/pci/slots/1/power
<snip>
pcieport 0000:02:01.0: PCI bridge to [bus 03-03]
pcieport 0000:02:01.0: bridge window [io 0xff7ee000-0xff7eefff]
pcieport 0000:02:01.0: bridge window [mem 0xa0100000-0xa01fffff]
pcieport 0000:02:01.0: bridge window [mem 0xa0200000-0xa02fffff 64bit pref]
pci 0000:03:00.0: no hotplug settings from platform
e1000e 0000:03:00.0: Disabling ASPM L1
e1000e 0000:03:00.0: enabling device (0000 -> 0002)
irq: irq 6 on host /soc@ffe00000/msi@41600 mapped to virtual irq 27
e1000e 0000:03:00.0: eth0: (PCI Express:2.5GT/s:Width x1) 00:15:17:bf:c0:c9
e1000e 0000:03:00.0: eth0: Intel(R) PRO/1000 Network Connection
e1000e 0000:03:00.0: eth0: MAC: 1, PHY: 4, PBA No: D50861-003
Signed-off-by: Hiroo MATSUMOTO <matsumoto.hiroo@jp.fujitsu.com>
---
arch/powerpc/include/asm/pci.h | 2 +-
arch/powerpc/kernel/pci-common.c | 87 ++++++++++++++--------------
arch/powerpc/kernel/pci_32.c | 2 +
arch/powerpc/kernel/pci_64.c | 2 +
arch/powerpc/kernel/pci_of_scan.c | 1 -
arch/powerpc/platforms/pseries/pci_dlpar.c | 1 -
drivers/pci/pci.c | 5 --
drivers/pcmcia/cardbus.c | 3 +-
include/linux/pci.h | 3 -
9 files changed, 49 insertions(+), 57 deletions(-)
diff --git a/arch/powerpc/include/asm/pci.h b/arch/powerpc/include/asm/pci.h
index f54b3d2..7b4ca5a 100644
--- a/arch/powerpc/include/asm/pci.h
+++ b/arch/powerpc/include/asm/pci.h
@@ -190,10 +190,10 @@ extern void pci_resource_to_user(const struct pci_dev *dev, int bar,
const struct resource *rsrc,
resource_size_t *start, resource_size_t *end);
-extern void pcibios_setup_bus_devices(struct pci_bus *bus);
extern void pcibios_setup_bus_self(struct pci_bus *bus);
extern void pcibios_setup_phb_io_space(struct pci_controller *hose);
extern void pcibios_scan_phb(struct pci_controller *hose);
+extern void pcibios_setup_bus_notifier(void);
#endif /* __KERNEL__ */
#endif /* __ASM_POWERPC_PCI_H */
diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index cce98d7..42a00b5 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -1097,40 +1097,6 @@ void __devinit pcibios_setup_bus_self(struct pci_bus *bus)
ppc_md.pci_dma_bus_setup(bus);
}
-void __devinit pcibios_setup_bus_devices(struct pci_bus *bus)
-{
- struct pci_dev *dev;
-
- pr_debug("PCI: Fixup bus devices %d (%s)\n",
- bus->number, bus->self ? pci_name(bus->self) : "PHB");
-
- list_for_each_entry(dev, &bus->devices, bus_list) {
- /* Cardbus can call us to add new devices to a bus, so ignore
- * those who are already fully discovered
- */
- if (dev->is_added)
- continue;
-
- /* Fixup NUMA node as it may not be setup yet by the generic
- * code and is needed by the DMA init
- */
- set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
-
- /* Hook up default DMA ops */
- set_dma_ops(&dev->dev, pci_dma_ops);
- set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
-
- /* Additional platform DMA/iommu setup */
- if (ppc_md.pci_dma_dev_setup)
- ppc_md.pci_dma_dev_setup(dev);
-
- /* Read default IRQs and fixup if necessary */
- pci_read_irq_line(dev);
- if (ppc_md.pci_irq_fixup)
- ppc_md.pci_irq_fixup(dev);
- }
-}
-
void pcibios_set_master(struct pci_dev *dev)
{
/* No special bus mastering setup handling */
@@ -1147,19 +1113,9 @@ void __devinit pcibios_fixup_bus(struct pci_bus *bus)
/* Now fixup the bus bus */
pcibios_setup_bus_self(bus);
-
- /* Now fixup devices on that bus */
- pcibios_setup_bus_devices(bus);
}
EXPORT_SYMBOL(pcibios_fixup_bus);
-void __devinit pci_fixup_cardbus(struct pci_bus *bus)
-{
- /* Now fixup devices on that bus */
- pcibios_setup_bus_devices(bus);
-}
-
-
static int skip_isa_ioresource_align(struct pci_dev *dev)
{
if (pci_has_flag(PCI_CAN_SKIP_ISA_ALIGN) &&
@@ -1763,6 +1719,49 @@ void __devinit pcibios_scan_phb(struct pci_controller *hose)
}
}
+static int pcibios_device_change_notifier(struct notifier_block *nb,
+ unsigned long action, void *data)
+{
+ struct pci_dev *dev = to_pci_dev(data);
+
+ switch (action) {
+ case BUS_NOTIFY_ADD_DEVICE:
+ /* Setup OF node pointer in the device */
+ dev->dev.of_node = pci_device_to_OF_node(dev);
+
+ /* Fixup NUMA node as it may not be setup yet by the generic
+ * code and is needed by the DMA init
+ */
+ set_dev_node(&dev->dev, pcibus_to_node(dev->bus));
+
+ /* Hook up default DMA ops */
+ set_dma_ops(&dev->dev, pci_dma_ops);
+ set_dma_offset(&dev->dev, PCI_DRAM_OFFSET);
+
+ /* Additional platform DMA/iommu setup */
+ if (ppc_md.pci_dma_dev_setup)
+ ppc_md.pci_dma_dev_setup(dev);
+
+ /* Read default IRQs and fixup if necessary */
+ pci_read_irq_line(dev);
+ if (ppc_md.pci_irq_fixup)
+ ppc_md.pci_irq_fixup(dev);
+
+ break;
+ }
+
+ return 0;
+}
+
+static struct notifier_block device_nb = {
+ .notifier_call = pcibios_device_change_notifier,
+};
+
+void __devinit pcibios_setup_bus_notifier(void)
+{
+ bus_register_notifier(&pci_bus_type, &device_nb);
+}
+
static void fixup_hide_host_resource_fsl(struct pci_dev *dev)
{
int i, class = dev->class >> 8;
diff --git a/arch/powerpc/kernel/pci_32.c b/arch/powerpc/kernel/pci_32.c
index fdd1a3d..5a30cec 100644
--- a/arch/powerpc/kernel/pci_32.c
+++ b/arch/powerpc/kernel/pci_32.c
@@ -231,6 +231,8 @@ static int __init pcibios_init(void)
printk(KERN_INFO "PCI: Probing PCI hardware\n");
+ pcibios_setup_bus_notifier();
+
if (pci_has_flag(PCI_REASSIGN_ALL_BUS))
pci_assign_all_buses = 1;
diff --git a/arch/powerpc/kernel/pci_64.c b/arch/powerpc/kernel/pci_64.c
index 3318d39..d66c9dc 100644
--- a/arch/powerpc/kernel/pci_64.c
+++ b/arch/powerpc/kernel/pci_64.c
@@ -50,6 +50,8 @@ static int __init pcibios_init(void)
printk(KERN_INFO "PCI: Probing PCI hardware\n");
+ pcibios_setup_bus_notifier();
+
/* For now, override phys_mem_access_prot. If we need it,g
* later, we may move that initialization to each ppc_md
*/
diff --git a/arch/powerpc/kernel/pci_of_scan.c b/arch/powerpc/kernel/pci_of_scan.c
index b37d0b5..1e29642 100644
--- a/arch/powerpc/kernel/pci_of_scan.c
+++ b/arch/powerpc/kernel/pci_of_scan.c
@@ -329,7 +329,6 @@ static void __devinit __of_scan_bus(struct device_node *node,
*/
if (!rescan_existing)
pcibios_setup_bus_self(bus);
- pcibios_setup_bus_devices(bus);
/* Now scan child busses */
list_for_each_entry(dev, &bus->devices, bus_list) {
diff --git a/arch/powerpc/platforms/pseries/pci_dlpar.c b/arch/powerpc/platforms/pseries/pci_dlpar.c
index 55d4ec1..fdb8b64 100644
--- a/arch/powerpc/platforms/pseries/pci_dlpar.c
+++ b/arch/powerpc/platforms/pseries/pci_dlpar.c
@@ -120,7 +120,6 @@ void pcibios_add_pci_devices(struct pci_bus * bus)
num = pci_scan_slot(bus, PCI_DEVFN(slotno, 0));
if (!num)
return;
- pcibios_setup_bus_devices(bus);
max = bus->secondary;
for (pass=0; pass < 2; pass++)
list_for_each_entry(dev, &bus->devices, bus_list) {
diff --git a/drivers/pci/pci.c b/drivers/pci/pci.c
index af295bb..f363b5d 100644
--- a/drivers/pci/pci.c
+++ b/drivers/pci/pci.c
@@ -3698,11 +3698,6 @@ int __attribute__ ((weak)) pci_ext_cfg_avail(struct pci_dev *dev)
return 1;
}
-void __weak pci_fixup_cardbus(struct pci_bus *bus)
-{
-}
-EXPORT_SYMBOL(pci_fixup_cardbus);
-
static int __init pci_setup(char *str)
{
while (str) {
diff --git a/drivers/pcmcia/cardbus.c b/drivers/pcmcia/cardbus.c
index 9a58862..8f7baa6 100644
--- a/drivers/pcmcia/cardbus.c
+++ b/drivers/pcmcia/cardbus.c
@@ -71,7 +71,6 @@ int __ref cb_alloc(struct pcmcia_socket *s)
unsigned int max, pass;
s->functions = pci_scan_slot(bus, PCI_DEVFN(0, 0));
- pci_fixup_cardbus(bus);
max = bus->secondary;
for (pass = 0; pass < 2; pass++)
@@ -85,7 +84,6 @@ int __ref cb_alloc(struct pcmcia_socket *s)
*/
pci_bus_size_bridges(bus);
pci_bus_assign_resources(bus);
- cardbus_config_irq_and_cls(bus, s->pci_irq);
/* socket specific tune function */
if (s->tune_bridge)
@@ -93,6 +91,7 @@ int __ref cb_alloc(struct pcmcia_socket *s)
pci_enable_bridges(bus);
pci_bus_add_devices(bus);
+ cardbus_config_irq_and_cls(bus, s->pci_irq);
return 0;
}
diff --git a/include/linux/pci.h b/include/linux/pci.h
index a16b1df..56f50fd 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -651,9 +651,6 @@ resource_size_t pcibios_align_resource(void *, const struct resource *,
resource_size_t);
void pcibios_update_irq(struct pci_dev *, int irq);
-/* Weak but can be overriden by arch */
-void pci_fixup_cardbus(struct pci_bus *);
-
/* Generic PCI functions used internally */
void pcibios_scan_specific_bus(int busn);
--
1.7.3.4
^ permalink raw reply related
* [PATCH v2 0/2] Add pcibios_device_change_notifier
From: Hiroo Matsumoto @ 2012-05-23 2:33 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: linux-pci, linuxppc-dev, jbarnes, Kenji Kaneshige
This patchset is for PCI hotplug.
pcibios_setup_bus_devices which sets DMA and IRQs of PCI device is called
only when boot. DMA setting in probe for PCI driver, like dma_set_mask,
does not work on powerpc platform. So it is need to set DMA and IRQs of
PCI device when hotplug.
1. Moving pcibios_setup_bus_devices code to pcibios_device_change_notifier
which is registered to bus notifier in pcibios_init.
2. Removing caller and callee of pcibios_setup_bus_devices bus notifier
works instead of pcibios_setup_bus_devices.
3. Using this bus notifier for microblaze because microblaze/PCI is similer
with powerpc/PCI.
[PATCH v2 1/2] powerpc/PCI: Add pcibios_device_change_notifier for powerpc
[PATCH v2 2/2] microblaze/PCI: Add pcibios_device_change_notifier for microblaze
Regards.
Hiroo MATSUMOTO
^ permalink raw reply
* Re: [PATCH 1/3] of: Add prefix parameter to of_modalias_node().
From: Grant Likely @ 2012-05-22 23:01 UTC (permalink / raw)
To: David Daney
Cc: linux-mips@linux-mips.org, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, Takashi Iwai,
devicetree-discuss@lists.ozlabs.org, Mark Brown,
Tabi Timur-B04825, linux-kernel@vger.kernel.org, Rob Herring,
Jaroslav Kysela, spi-devel-general@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <4FBC1807.4050402@gmail.com>
Cool, thanks.
g.
On Tue, May 22, 2012 at 4:49 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> On 05/22/2012 01:09 PM, Grant Likely wrote:
>>
>> On Tue, May 22, 2012 at 1:45 PM, David Daney<ddaney.cavm@gmail.com>
>> =A0wrote:
>>>
>>> On 05/19/2012 11:08 PM, Grant Likely wrote:
>>>>
>>>>
>>>> On Sat, 19 May 2012 23:54:36 -0600, Grant
>>>> Likely<grant.likely@secretlab.ca> =A0 =A0wrote:
>>>>>
>>>>>
>>>>> On Fri, 11 May 2012 15:05:21 -0700, David Daney<ddaney.cavm@gmail.com=
>
>>>>> =A0wrote:
>>>>>>
>>>>>>
>>>>>> From: David Daney<david.daney@cavium.com>
>>>>>>
>>>>>> When generating MODALIASes, it is convenient to add things like "spi=
:"
>>>>>> or "i2c:" to the front of the strings. =A0This allows the standard
>>>>>> modprobe to find the right driver when automatically populating bus
>>>>>> children from the device tree structure.
>>>>>>
>>>>>> Add a prefix parameter, and adjust callers. =A0For
>>>>>> of_register_spi_devices() use the "spi:" prefix.
>>>>>>
>>>>>> Signed-off-by: David Daney<david.daney@cavium.com>
>>>>>
>>>>>
>>>>>
>>>>> Applied, thanks. =A0Some notes below...
>>>>
>>>>
>>>>
>>>> Wait... why is this necessary?
>>>
>>>
>>>
>>> Because in of_register_spi_devices() in of_spi.c, you do:
>>>
>>> =A0 =A0 =A0 =A0request_module(spi->modalias);
>>>
>>> The string passed to request_module() must have the "spi:" prefix.
>>
>>
>> How about modifying the call to request_module() to include the prefix
>> also? =A0I think that would be a simpler change overall. =A0Would that
>> work?
>
>
> It seems to. =A0I just sent such a patch in a new thread.
>
> David Daney
--=20
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
^ permalink raw reply
* Re: [PATCH 1/3] of: Add prefix parameter to of_modalias_node().
From: David Daney @ 2012-05-22 22:49 UTC (permalink / raw)
To: Grant Likely
Cc: linux-mips@linux-mips.org, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, Takashi Iwai,
devicetree-discuss@lists.ozlabs.org, Mark Brown,
Tabi Timur-B04825, linux-kernel@vger.kernel.org, Rob Herring,
Jaroslav Kysela, spi-devel-general@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <CACxGe6tYQVfPRtXxmYF2OPYcEFu+x4-_uzFta9f3mwu=xUrt=g@mail.gmail.com>
On 05/22/2012 01:09 PM, Grant Likely wrote:
> On Tue, May 22, 2012 at 1:45 PM, David Daney<ddaney.cavm@gmail.com> wrote:
>> On 05/19/2012 11:08 PM, Grant Likely wrote:
>>>
>>> On Sat, 19 May 2012 23:54:36 -0600, Grant
>>> Likely<grant.likely@secretlab.ca> wrote:
>>>>
>>>> On Fri, 11 May 2012 15:05:21 -0700, David Daney<ddaney.cavm@gmail.com>
>>>> wrote:
>>>>>
>>>>> From: David Daney<david.daney@cavium.com>
>>>>>
>>>>> When generating MODALIASes, it is convenient to add things like "spi:"
>>>>> or "i2c:" to the front of the strings. This allows the standard
>>>>> modprobe to find the right driver when automatically populating bus
>>>>> children from the device tree structure.
>>>>>
>>>>> Add a prefix parameter, and adjust callers. For
>>>>> of_register_spi_devices() use the "spi:" prefix.
>>>>>
>>>>> Signed-off-by: David Daney<david.daney@cavium.com>
>>>>
>>>>
>>>> Applied, thanks. Some notes below...
>>>
>>>
>>> Wait... why is this necessary?
>>
>>
>> Because in of_register_spi_devices() in of_spi.c, you do:
>>
>> request_module(spi->modalias);
>>
>> The string passed to request_module() must have the "spi:" prefix.
>
> How about modifying the call to request_module() to include the prefix
> also? I think that would be a simpler change overall. Would that
> work?
It seems to. I just sent such a patch in a new thread.
David Daney
^ permalink raw reply
* Re: [PATCH 1/3] of: Add prefix parameter to of_modalias_node().
From: Grant Likely @ 2012-05-22 20:09 UTC (permalink / raw)
To: David Daney
Cc: linux-mips@linux-mips.org, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, Takashi Iwai,
devicetree-discuss@lists.ozlabs.org, Mark Brown,
Tabi Timur-B04825, linux-kernel@vger.kernel.org, Rob Herring,
Jaroslav Kysela, spi-devel-general@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <4FBBECC2.10503@gmail.com>
On Tue, May 22, 2012 at 1:45 PM, David Daney <ddaney.cavm@gmail.com> wrote:
> On 05/19/2012 11:08 PM, Grant Likely wrote:
>>
>> On Sat, 19 May 2012 23:54:36 -0600, Grant
>> Likely<grant.likely@secretlab.ca> =A0wrote:
>>>
>>> On Fri, 11 May 2012 15:05:21 -0700, David Daney<ddaney.cavm@gmail.com>
>>> =A0wrote:
>>>>
>>>> From: David Daney<david.daney@cavium.com>
>>>>
>>>> When generating MODALIASes, it is convenient to add things like "spi:"
>>>> or "i2c:" to the front of the strings. =A0This allows the standard
>>>> modprobe to find the right driver when automatically populating bus
>>>> children from the device tree structure.
>>>>
>>>> Add a prefix parameter, and adjust callers. =A0For
>>>> of_register_spi_devices() use the "spi:" prefix.
>>>>
>>>> Signed-off-by: David Daney<david.daney@cavium.com>
>>>
>>>
>>> Applied, thanks. =A0Some notes below...
>>
>>
>> Wait... why is this necessary?
>
>
> Because in of_register_spi_devices() in of_spi.c, you do:
>
> =A0 =A0 =A0 =A0request_module(spi->modalias);
>
> The string passed to request_module() must have the "spi:" prefix.
How about modifying the call to request_module() to include the prefix
also? I think that would be a simpler change overall. Would that
work?
g.
^ permalink raw reply
* Re: [PATCH 1/3] of: Add prefix parameter to of_modalias_node().
From: David Daney @ 2012-05-22 19:45 UTC (permalink / raw)
To: Grant Likely
Cc: linux-mips@linux-mips.org, alsa-devel@alsa-project.org,
linux-doc@vger.kernel.org, Takashi Iwai,
devicetree-discuss@lists.ozlabs.org, Mark Brown,
Tabi Timur-B04825, linux-kernel@vger.kernel.org, Rob Herring,
Jaroslav Kysela, David Daney,
spi-devel-general@lists.sourceforge.net,
linuxppc-dev@lists.ozlabs.org, Liam Girdwood
In-Reply-To: <20120520060802.03CE73E03B8@localhost>
On 05/19/2012 11:08 PM, Grant Likely wrote:
> On Sat, 19 May 2012 23:54:36 -0600, Grant Likely<grant.likely@secretlab.ca> wrote:
>> On Fri, 11 May 2012 15:05:21 -0700, David Daney<ddaney.cavm@gmail.com> wrote:
>>> From: David Daney<david.daney@cavium.com>
>>>
>>> When generating MODALIASes, it is convenient to add things like "spi:"
>>> or "i2c:" to the front of the strings. This allows the standard
>>> modprobe to find the right driver when automatically populating bus
>>> children from the device tree structure.
>>>
>>> Add a prefix parameter, and adjust callers. For
>>> of_register_spi_devices() use the "spi:" prefix.
>>>
>>> Signed-off-by: David Daney<david.daney@cavium.com>
>>
>> Applied, thanks. Some notes below...
>
> Wait... why is this necessary?
Because in of_register_spi_devices() in of_spi.c, you do:
request_module(spi->modalias);
The string passed to request_module() must have the "spi:" prefix.
> The module type prefix isn't stored in
> the modalias value for any other bus type as far as I can see,
It is only useful with the prefix, so I though I would add it to the
stored value.
> and
> with this series it appears that the "spi:" prefix may or may not be
> present in the modalias. That doesn't look right.
Perhaps, but the with the combination of patches 1/3 and 2/3 I tried to
ensure that the prefix would always be present for SPI devices.
>
> Why isn't prefixing spi: at uevent time sufficient?
Because udev may not be loading the driver.
> IIUC, modprobe
> depends on either UEVENT or the modalias attribute to know which
> driver to probe. It does look like the attribute is missing the spi:
> prefix though. Does the following change work instead of these two
> patches?
>
No.
> diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
> index 3d8f662..da8aac7 100644
> --- a/drivers/spi/spi.c
> +++ b/drivers/spi/spi.c
> @@ -51,7 +51,7 @@ modalias_show(struct device *dev, struct device_attribute *a, char *buf)
> {
> const struct spi_device *spi = to_spi_device(dev);
>
> - return sprintf(buf, "%s\n", spi->modalias);
> + return sprintf(buf, "%s%s\n", SPI_MODULE_PREFIX, spi->modalias);
> }
>
> So, I've dropped this patch from my tree. If the change above works
> for you then I'll push it out.
>
> g.
>
^ permalink raw reply
* Re: [PATCH] gianfar:don't add FCB length to hard_header_len
From: David Miller @ 2012-05-22 19:18 UTC (permalink / raw)
To: b06378; +Cc: netdev, linuxppc-dev
In-Reply-To: <1337677248-27792-1-git-send-email-b06378@freescale.com>
From: Jiajun Wu <b06378@freescale.com>
Date: Tue, 22 May 2012 17:00:48 +0800
> FCB(Frame Control Block) isn't the part of netdev hard header.
> Add FCB to hard_header_len will make GRO fail at MAC comparision stage.
>
> Signed-off-by: Jiajun Wu <b06378@freescale.com>
Applied, thanks.
Someone needs to go through this driver when net-next opens up
and fix all of the indentation in this driver.
^ permalink raw reply
* Re: Handling spin table in kdump
From: McClintock Matthew-B29882 @ 2012-05-22 15:34 UTC (permalink / raw)
To: Suzuki K. Poulose
Cc: linuxppc-dev@lists.ozlabs.org, Sebastian Andrzej Siewior,
kexec@lists.infradead.org
In-Reply-To: <4FBB89A2.90709@in.ibm.com>
On Tue, May 22, 2012 at 7:42 AM, Suzuki K. Poulose <suzuki@in.ibm.com> wrot=
e:
> Hi
>
> I came across the following issue while testing Kdump on an SMP
> board(Currituck) running a non-SMP kernel. Even though the kernel is UP,
> the device-tree has the nodes for second CPU and the related details.
>
>
> The kexec tool adds the spin table area as a reserved section in the devi=
ce
> tree for the dump capture kernel. This value is read from the
> 'cpu-release-addr'.
>
> But now, if the spin table is not located within the 'Reserved region' fo=
r
> the crash kernel, the dump capture kernel would fail to boot, hitting a B=
UG
> in mm/bootmem.c as in [1].
>
> This is because we try to reserve a region which is not available to the
> kernel.
>
> So I am wondering how is this handled really on an SMP board (Fsl_bookE).
>
> There are two possible solutions :
> 1) Do not reserve the regions for the spin-table, as we will use
> only the crashing CPU in the second kernel(maxcpus=3D1).
>
>
> 2) Add the spin-table region to the available memory regions passed
> to the kernel by kexec-tools.
>
> I have tested (1) and it works fine for me. Yet to test (2).
>
>
> Thoughts ?
I would think option 1 is acceptable. The crash kernel will never
attempt to use the memory outside of the crash kernel region therefore
it does not need to be reserved.
However, I thought we were able to boot SMP into the crash kernel on
our parts... not sure how that effects things (although the maxcpus=3D1
here is a perfectly acceptable and safer thing to do anyways)
-M
>
>
> Thanks
> Suzuki
>
>
>
> [1] Kernel Bug
> ----------------
>
>
> Linux version 3.3.0-rc5 (root@suzukikp.in.ibm.com) (gcc version 4.3.4
> [gcc-4_3-branch revision 152973] (GCC) ) #12 Tue May 22 18:03:01 IST2
> Found legacy serial port 0 for /plb/opb/serial@10000000
> =A0mem=3D20010000000, taddr=3D20010000000, irq=3D0, clk=3D1851851, speed=
=3D115200
> ------------[ cut here ]------------
> kernel BUG at mm/bootmem.c:351!
> Vector: 700 (Program Check) at [c8a61e90]
> =A0 =A0pc: c847f91c: mark_bootmem+0xa0/0x14c
> =A0 =A0lr: c8472670: do_init_bootmem+0x1ac/0x218
> =A0 =A0sp: c8a61f40
> =A0 msr: 21000
> =A0current =3D 0xc8a4a500
> =A0 =A0pid =A0 =3D 0, comm =3D swapper
> kernel BUG at mm/bootmem.c:351!
> enter ? for help
> [c8a61f70] c8472670 do_init_bootmem+0x1ac/0x218
> [c8a61f90] c847025c setup_arch+0x1bc/0x234
> [c8a61fb0] c846b62c start_kernel+0x98/0x358
> [c8a61ff0] c80000b4 _start+0xb4/0xf8
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev=
^ permalink raw reply
* Handling spin table in kdump
From: Suzuki K. Poulose @ 2012-05-22 12:42 UTC (permalink / raw)
To: kexec, linuxppc-dev; +Cc: Matthew McClintock, Sebastian Andrzej Siewior
Hi
I came across the following issue while testing Kdump on an SMP
board(Currituck) running a non-SMP kernel. Even though the kernel is UP,
the device-tree has the nodes for second CPU and the related details.
The kexec tool adds the spin table area as a reserved section in the
device tree for the dump capture kernel. This value is read from the
'cpu-release-addr'.
But now, if the spin table is not located within the 'Reserved region'
for the crash kernel, the dump capture kernel would fail to boot,
hitting a BUG in mm/bootmem.c as in [1].
This is because we try to reserve a region which is not available to the
kernel.
So I am wondering how is this handled really on an SMP board (Fsl_bookE).
There are two possible solutions :
1) Do not reserve the regions for the spin-table, as we will use
only the crashing CPU in the second kernel(maxcpus=1).
2) Add the spin-table region to the available memory regions passed
to the kernel by kexec-tools.
I have tested (1) and it works fine for me. Yet to test (2).
Thoughts ?
Thanks
Suzuki
[1] Kernel Bug
----------------
Linux version 3.3.0-rc5 (root@suzukikp.in.ibm.com) (gcc version 4.3.4
[gcc-4_3-branch revision 152973] (GCC) ) #12 Tue May 22 18:03:01 IST2
Found legacy serial port 0 for /plb/opb/serial@10000000
mem=20010000000, taddr=20010000000, irq=0, clk=1851851, speed=115200
------------[ cut here ]------------
kernel BUG at mm/bootmem.c:351!
Vector: 700 (Program Check) at [c8a61e90]
pc: c847f91c: mark_bootmem+0xa0/0x14c
lr: c8472670: do_init_bootmem+0x1ac/0x218
sp: c8a61f40
msr: 21000
current = 0xc8a4a500
pid = 0, comm = swapper
kernel BUG at mm/bootmem.c:351!
enter ? for help
[c8a61f70] c8472670 do_init_bootmem+0x1ac/0x218
[c8a61f90] c847025c setup_arch+0x1bc/0x234
[c8a61fb0] c846b62c start_kernel+0x98/0x358
[c8a61ff0] c80000b4 _start+0xb4/0xf8
^ permalink raw reply
* Re: powerpc -next rebase WARNING
From: Josh Boyer @ 2012-05-22 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev, Linux Kernel list
In-Reply-To: <1337661655.2779.167.camel@pasglop>
On Tue, May 22, 2012 at 12:40 AM, Benjamin Herrenschmidt
<benh@kernel.crashing.org> wrote:
> On Tue, 2012-05-22 at 11:51 +1000, Benjamin Herrenschmidt wrote:
>> Folks, bad news ... my fault.
>>
>> I accidentally forgot a --signoff on a git am command last week, meaning
>> that a pair of patches are in -next and not signed off by me.
>>
>> For various (legal) reasons that cannot go into Linus tree as-is, so I
>> have to rebase the tree to fix it.
>>
>> Sorry about that ...
>
> Note that the rebase only affects the top 3 commits, so if your
> tree is based on something older you're fine (Kumar, you seem to
> be ok, I haven't checked Josh).
Should be fine. Even if not, all 4 of its users will manage to cope.
josh
^ permalink raw reply
* [PATCH] gianfar:don't add FCB length to hard_header_len
From: Jiajun Wu @ 2012-05-22 9:00 UTC (permalink / raw)
To: netdev, davem; +Cc: Jiajun Wu, linuxppc-dev
FCB(Frame Control Block) isn't the part of netdev hard header.
Add FCB to hard_header_len will make GRO fail at MAC comparision stage.
Signed-off-by: Jiajun Wu <b06378@freescale.com>
---
drivers/net/ethernet/freescale/gianfar.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/net/ethernet/freescale/gianfar.c b/drivers/net/ethernet/freescale/gianfar.c
index 1adb024..0741ade 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1082,7 +1082,7 @@ static int gfar_probe(struct platform_device *ofdev)
if (dev->features & NETIF_F_IP_CSUM ||
priv->device_flags & FSL_GIANFAR_DEV_HAS_TIMER)
- dev->hard_header_len += GMAC_FCB_LEN;
+ dev->needed_headroom = GMAC_FCB_LEN;
/* Program the isrg regs only if number of grps > 1 */
if (priv->num_grps > 1) {
--
1.5.6.5
^ permalink raw reply related
* Re: powerpc -next rebase WARNING
From: Benjamin Herrenschmidt @ 2012-05-22 4:40 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linux Kernel list
In-Reply-To: <1337651473.2779.140.camel@pasglop>
On Tue, 2012-05-22 at 11:51 +1000, Benjamin Herrenschmidt wrote:
> Folks, bad news ... my fault.
>
> I accidentally forgot a --signoff on a git am command last week, meaning
> that a pair of patches are in -next and not signed off by me.
>
> For various (legal) reasons that cannot go into Linus tree as-is, so I
> have to rebase the tree to fix it.
>
> Sorry about that ...
Note that the rebase only affects the top 3 commits, so if your
tree is based on something older you're fine (Kumar, you seem to
be ok, I haven't checked Josh).
Cheers,
Ben.
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Stephen Rothwell @ 2012-05-22 3:25 UTC (permalink / raw)
To: David Rientjes
Cc: Lee Schermerhorn, Peter Zijlstra, Linus, LKML, linux-next,
H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <20120522130354.fdb335eb294f4206b4b2fed5@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1285 bytes --]
On Tue, 22 May 2012 13:03:54 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Mon, 21 May 2012 18:53:37 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
> >
> > Yeah, it's sched/numa since that's what introduced numa_init(). It does
> > for_each_node() for each node and does a kmalloc_node() even though that
> > node may not be online. Slub ends up passing this node to the page
> > allocator through alloc_pages_exact_node(). CONFIG_DEBUG_VM would have
> > caught this and your config confirms its not enabled.
> >
> > sched/numa either needs a memory hotplug notifier or it needs to pass
> > NUMA_NO_NODE for nodes that aren't online. Until we get the former, the
> > following should fix it.
> >
> >
> > sched, numa: Allocate node_queue on any node for offline nodes
> >
> > struct node_queue must be allocated with NUMA_NO_NODE for nodes that are
> > not (yet) online, otherwise the page allocator has a bad zonelist.
> >
> > Signed-off-by: David Rientjes <rientjes@google.com>
>
> Thanks, that fixes it.
>
> Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
And I will put that patch in linux-next until it (or something better)
appears.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 3:12 UTC (permalink / raw)
To: David Rientjes
Cc: Lee Schermerhorn, Stephen Rothwell, Peter Zijlstra, Linus, LKML,
linux-next, H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <alpine.DEB.2.00.1205211954340.13522@chino.kir.corp.google.com>
David Rientjes <rientjes@google.com> wrote:
> On Tue, 22 May 2012, Michael Neuling wrote:
>
> > Sorry, got it... CONFIG_DEBUG_VM enabled below...
> >
> > pid_max: default: 32768 minimum: 301
> > Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
> > Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
> > Mount-cache hash table entries: 4096
> > Initializing cgroup subsys cpuacct
> > Initializing cgroup subsys devices
> > Initializing cgroup subsys freezer
> > POWER7 performance monitor hardware support registered
> > ------------[ cut here ]------------
> > kernel BUG at /scratch/mikey/src/linux-next/include/linux/gfp.h:318!
>
> Yeah, this is what I was expecting, it's tripping on
>
> VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
>
> and slub won't pass nid < 0. You're sure my patch is applied? :)
I did have your patch applied but at "b4cdf91 sched/numa: Implement numa
balancer" (where git bisect spotted the fail).
If I apply your patch on the full next-20120521 it does fix the problem.
Sorry for the confusion.
Thanks!
Mikey
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Stephen Rothwell @ 2012-05-22 3:03 UTC (permalink / raw)
To: David Rientjes
Cc: Lee Schermerhorn, Peter Zijlstra, Linus, LKML, linux-next,
H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <alpine.DEB.2.00.1205211846120.20916@chino.kir.corp.google.com>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
Hi David,
On Mon, 21 May 2012 18:53:37 -0700 (PDT) David Rientjes <rientjes@google.com> wrote:
>
> Yeah, it's sched/numa since that's what introduced numa_init(). It does
> for_each_node() for each node and does a kmalloc_node() even though that
> node may not be online. Slub ends up passing this node to the page
> allocator through alloc_pages_exact_node(). CONFIG_DEBUG_VM would have
> caught this and your config confirms its not enabled.
>
> sched/numa either needs a memory hotplug notifier or it needs to pass
> NUMA_NO_NODE for nodes that aren't online. Until we get the former, the
> following should fix it.
>
>
> sched, numa: Allocate node_queue on any node for offline nodes
>
> struct node_queue must be allocated with NUMA_NO_NODE for nodes that are
> not (yet) online, otherwise the page allocator has a bad zonelist.
>
> Signed-off-by: David Rientjes <rientjes@google.com>
Thanks, that fixes it.
Tested-by: Stephen Rothwell <sfr@canb.auug.org.au>
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 2:58 UTC (permalink / raw)
To: Michael Neuling
Cc: Lee Schermerhorn, Stephen Rothwell, Peter Zijlstra, Linus, LKML,
linux-next, H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <3120.1337655100@neuling.org>
On Tue, 22 May 2012, Michael Neuling wrote:
> Sorry, got it... CONFIG_DEBUG_VM enabled below...
>
> pid_max: default: 32768 minimum: 301
> Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
> Mount-cache hash table entries: 4096
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys devices
> Initializing cgroup subsys freezer
> POWER7 performance monitor hardware support registered
> ------------[ cut here ]------------
> kernel BUG at /scratch/mikey/src/linux-next/include/linux/gfp.h:318!
Yeah, this is what I was expecting, it's tripping on
VM_BUG_ON(nid < 0 || nid >= MAX_NUMNODES || !node_online(nid));
and slub won't pass nid < 0. You're sure my patch is applied? :)
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:51 UTC (permalink / raw)
To: David Rientjes
Cc: Lee Schermerhorn, Stephen Rothwell, Peter Zijlstra, Linus, LKML,
linux-next, H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <alpine.DEB.2.00.1205211942540.29814@chino.kir.corp.google.com>
David Rientjes <rientjes@google.com> wrote:
> On Tue, 22 May 2012, Michael Neuling wrote:
>
> > > > > Trying David's patch just posted doesn't fix it.
> > > > >
> > > >
> > > > Hmm, what does CONFIG_DEBUG_VM say?
> > >
> > > No set.
> >
> > Sorry, should have read "Not set"
> >
>
> I mean if it's set, what does it emit to the kernel log with my patch
> applied?
>
> I made CONFIG_DEBUG_VM catch !node_online(node) about six months ago, so I
> was thinking it would have caught this if either you or Stephen enable it.
Sorry, got it... CONFIG_DEBUG_VM enabled below...
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
POWER7 performance monitor hardware support registered
------------[ cut here ]------------
kernel BUG at /scratch/mikey/src/linux-next/include/linux/gfp.h:318!
Oops: Exception in kernel mode, sig: 5 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c000000000199164 LR: c0000000001993e0 CTR: c0000000000b6b70
REGS: c00000007e583830 TRAP: 0700 Tainted: G W (3.4.0-rc6-mikey)
MSR: 9000000000029032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004028 XER: 02000000
SOFTE: 1
CFAR: c0000000001993c4
TASK = c00000007e560000[1] 'swapper/0' THREAD: c00000007e580000 CPU: 0
GPR00: 0000000000000001 c00000007e583ab0 c000000000c035a0 00000000000012d0
GPR04: 0000000000000000 0000000000000001 c000000000e14900 0005055500000001
GPR08: 0000000000000001 00000000000012d0 c000000000c6f398 0000000000000001
GPR12: 0000000028004022 c00000000ff20000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000001380 0000000000000000
GPR20: 0000000000000001 c000000000e14900 c000000000e148f0 0000000000210d00
GPR24: 0000000000000001 00000000000000d0 00000000000002aa 0000000000000000
GPR28: 00000000000000d0 0000000000000001 c000000000b58fc8 c00000007e021200
NIP [c000000000199164] .new_slab+0xb4/0x440
LR [c0000000001993e0] .new_slab+0x330/0x440
Call Trace:
[c00000007e583ab0] [c0000000001993e0] .new_slab+0x330/0x440 (unreliable)
[c00000007e583b60] [c00000000072ce84] .__slab_alloc+0x3bc/0x52c
[c00000007e583ca0] [c000000000199b08] .kmem_cache_alloc_node_trace+0x98/0x280
[c00000007e583d60] [c000000000a5a440] .numa_init+0x9c/0x188
[c00000007e583e00] [c00000000000aa30] .do_one_initcall+0x60/0x1e0
[c00000007e583ec0] [c000000000a40b60] .kernel_init+0x128/0x294
[c00000007e583f90] [c000000000020788] .kernel_thread+0x54/0x70
Instruction dump:
7b5b8402 7f6407b4 7c1ce378 7d29e038 7b990020 61291200 79230020 419202b8
2b9d00ff 78840020 38000001 409d0240 <0b000000> e95e8140 792977e2 7bab1f24
---[ end trace 31fd0ba7d8756002 ]---
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 2:44 UTC (permalink / raw)
To: Michael Neuling
Cc: Lee Schermerhorn, Stephen Rothwell, Peter Zijlstra, Linus, LKML,
linux-next, H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <2246.1337654423@neuling.org>
On Tue, 22 May 2012, Michael Neuling wrote:
> > > > Trying David's patch just posted doesn't fix it.
> > > >
> > >
> > > Hmm, what does CONFIG_DEBUG_VM say?
> >
> > No set.
>
> Sorry, should have read "Not set"
>
I mean if it's set, what does it emit to the kernel log with my patch
applied?
I made CONFIG_DEBUG_VM catch !node_online(node) about six months ago, so I
was thinking it would have caught this if either you or Stephen enable it.
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:40 UTC (permalink / raw)
To: David Rientjes
Cc: Lee Schermerhorn, Stephen Rothwell, Peter Zijlstra, Linus, LKML,
linux-next, H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <2182.1337654352@neuling.org>
Michael Neuling <mikey@neuling.org> wrote:
> > > Trying David's patch just posted doesn't fix it.
> > >
> >
> > Hmm, what does CONFIG_DEBUG_VM say?
>
> No set.
Sorry, should have read "Not set"
mikey
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:39 UTC (permalink / raw)
To: David Rientjes
Cc: Lee Schermerhorn, Stephen Rothwell, Peter Zijlstra, Linus, LKML,
linux-next, H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <alpine.DEB.2.00.1205211924390.13682@chino.kir.corp.google.com>
> > Trying David's patch just posted doesn't fix it.
> >
>
> Hmm, what does CONFIG_DEBUG_VM say?
No set.
Mikey
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 2:25 UTC (permalink / raw)
To: Michael Neuling
Cc: Lee Schermerhorn, Stephen Rothwell, Peter Zijlstra, Linus, LKML,
linux-next, H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <328.1337652722@neuling.org>
On Tue, 22 May 2012, Michael Neuling wrote:
> console [tty0] enabled
> console [hvc0] enabled
> pid_max: default: 32768 minimum: 301
> Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
> Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
> Mount-cache hash table entries: 4096
> Initializing cgroup subsys cpuacct
> Initializing cgroup subsys devices
> Initializing cgroup subsys freezer
> POWER7 performance monitor hardware support registered
> Unable to handle kernel paging request for data at address 0x00001388
> Faulting instruction address: 0xc00000000014a070
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=1024 NUMA pSeries
> Modules linked in:
> NIP: c00000000014a070 LR: c0000000001978cc CTR: c0000000000b6870
> REGS: c00000007e5836b0 TRAP: 0300 Tainted: G W (3.4.0-rc6-mikey)
> MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004022 XER: 02000000
> SOFTE: 1
> CFAR: 00000000000050fc
> DAR: 0000000000001388, DSISR: 40000000
> TASK = c00000007e560000[1] 'swapper/0' THREAD: c00000007e580000 CPU: 0
> GPR00: 0000000000000000 c00000007e583930 c000000000c034d8 00000000000012d0
> GPR04: 0000000000000000 0000000000001380 0000000000000000 0000000000000001
> GPR08: c00000007e0dff60 0000000000000000 c000000000ca05a0 0000000000000000
> GPR12: 0000000028004024 c00000000ff20000 0000000000000000 0000000000000000
> GPR16: 0000000000000000 0000000000000000 0000000000000001 0000000000001380
> GPR20: 0000000000000001 c000000000e14900 c000000000e148f0 0000000000000001
> GPR24: c000000000c6f378 0000000000000000 0000000000001380 00000000000002aa
> GPR28: 0000000000000000 0000000000000000 c000000000b576b0 c00000007e021200
> NIP [c00000000014a070] .__alloc_pages_nodemask+0xd0/0x910
> LR [c0000000001978cc] .new_slab+0xcc/0x3d0
> Call Trace:
> [c00000007e583930] [c00000007e5839c0] 0xc00000007e5839c0 (unreliable)
> [c00000007e583ac0] [c0000000001978cc] .new_slab+0xcc/0x3d0
> [c00000007e583b70] [c00000000072ae98] .__slab_alloc+0x38c/0x4f8
> [c00000007e583cb0] [c000000000198190] .kmem_cache_alloc_node_trace+0x90/0x260
> [c00000007e583d60] [c000000000a5a404] .numa_init+0x9c/0x188
> [c00000007e583e00] [c00000000000aa30] .do_one_initcall+0x60/0x1e0
> [c00000007e583ec0] [c000000000a40b60] .kernel_init+0x128/0x294
> [c00000007e583f90] [c000000000020788] .kernel_thread+0x54/0x70
> Instruction dump:
> 0b000000 eb1e8000 3b800000 801800a8 2f800000 409e001c 7860efe3 38000000
> 41820008 38000002 787c6fe2 7f9c0378 <e93a0008> 801800a4 3b600000 2fa90000
> ---[ end trace 31fd0ba7d8756002 ]---
>
> Which seems to be this code in __alloc_pages_nodemask
> ---
> /*
> * Check the zones suitable for the gfp_mask contain at least one
> * valid zone. It's possible to have an empty zonelist as a result
> * of GFP_THISNODE and a memoryless node
> */
> if (unlikely(!zonelist->_zonerefs->zone))
> c00000000014a070: e9 3a 00 08 ld r9,8(r26)
> ---
>
> r26 is coming from r5 which is the struct zonelist *zonelist parameter
> to __alloc_pages_nodemask. Having 0000000000001380 in there is clearly
> a bogus pointer.
>
> Bisecting it points to b4cdf91668c27a5a6a5a3ed4234756c042dd8288
> b4cdf91 sched/numa: Implement numa balancer
>
> Trying David's patch just posted doesn't fix it.
>
Hmm, what does CONFIG_DEBUG_VM say?
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: Michael Neuling @ 2012-05-22 2:12 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Lee Schermerhorn, Peter Zijlstra, Linus, LKML, linux-next,
H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <20120522114051.0c9db9a7c2d660bc9e0e1be2@canb.auug.org.au>
> Hi all,
>
> Last nights boot tests on various PowerPC systems failed like this:
>
> calling .numa_group_init+0x0/0x3c @ 1
> initcall .numa_group_init+0x0/0x3c returned 0 after 0 usecs
> calling .numa_init+0x0/0x1dc @ 1
> Unable to handle kernel paging request for data at address 0x00001688
> Faulting instruction address: 0xc00000000016e154
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in:
> NIP: c00000000016e154 LR: c0000000001b9140 CTR: 0000000000000000
> REGS: c0000003fc8c76d0 TRAP: 0300 Not tainted (3.4.0-autokern1)
> MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24044022 XER: 00000003
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 0000000000001688, DSISR: 40000000
> TASK = c0000003fc8c8000[1] 'swapper/0' THREAD: c0000003fc8c4000 CPU: 0
> GPR00: 0000000000000000 c0000003fc8c7950 c000000000d05b30 00000000000012d0
> GPR04: 0000000000000000 0000000000001680 0000000000000000 c0000003fe032f60
> GPR08: 0004005400000001 0000000000000000 ffffffffffffc980 c000000000d24fe0
> GPR12: 0000000024044024 c00000000f33b000 0000000001a3fa78 00000000009bac00
> GPR16: 0000000000e1f338 0000000002d513f0 0000000000001680 0000000000000000
> GPR20: 0000000000000001 c0000003fc8c7c00 0000000000000000 0000000000000001
> GPR24: 0000000000000001 c000000000d1b490 0000000000000000 0000000000001680
> GPR28: 0000000000000000 0000000000000000 c000000000c7ce58 c0000003fe009200
> NIP [c00000000016e154] .__alloc_pages_nodemask+0xc4/0x8f0
> LR [c0000000001b9140] .new_slab+0xd0/0x3c0
> Call Trace:
> [c0000003fc8c7950] [2e6e756d615f696e] 0x2e6e756d615f696e (unreliable)
> [c0000003fc8c7ae0] [c0000000001b9140] .new_slab+0xd0/0x3c0
> [c0000003fc8c7b90] [c0000000001b9844] .__slab_alloc+0x254/0x5b0
> [c0000003fc8c7cd0] [c0000000001bb7a4] .kmem_cache_alloc_node_trace+0x94/0x260
> [c0000003fc8c7d80] [c000000000ba36d0] .numa_init+0x98/0x1dc
> [c0000003fc8c7e10] [c00000000000ace4] .do_one_initcall+0x1a4/0x1e0
> [c0000003fc8c7ed0] [c000000000b7b354] .kernel_init+0x124/0x2e0
> [c0000003fc8c7f90] [c0000000000211c8] .kernel_thread+0x54/0x70
> Instruction dump:
> 5400d97e 7b170020 0b000000 eb3e8000 3b800000 80190088 2f800000 40de0014
> 7860efe2 787c6fe2 78000fa4 7f9c0378 <e81b0008> 83f90000 2fa00000 7fff1838
> ---[ end trace 31fd0ba7d8756001 ]---
>
> swapper/0 (1) used greatest stack depth: 10864 bytes left
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> I may be completely wrong, but I guess the obvious target would be the
> sched/numa branch that came in via the tip tree.
>
> Config file attached. I haven't had a chance to try to bisect this yet.
>
> Anyone have any ideas?
I'm getting similar here:
console [tty0] enabled
console [hvc0] enabled
pid_max: default: 32768 minimum: 301
Dentry cache hash table entries: 262144 (order: 5, 2097152 bytes)
Inode-cache hash table entries: 131072 (order: 4, 1048576 bytes)
Mount-cache hash table entries: 4096
Initializing cgroup subsys cpuacct
Initializing cgroup subsys devices
Initializing cgroup subsys freezer
POWER7 performance monitor hardware support registered
Unable to handle kernel paging request for data at address 0x00001388
Faulting instruction address: 0xc00000000014a070
Oops: Kernel access of bad area, sig: 11 [#1]
SMP NR_CPUS=1024 NUMA pSeries
Modules linked in:
NIP: c00000000014a070 LR: c0000000001978cc CTR: c0000000000b6870
REGS: c00000007e5836b0 TRAP: 0300 Tainted: G W (3.4.0-rc6-mikey)
MSR: 9000000000009032 <SF,HV,EE,ME,IR,DR,RI> CR: 28004022 XER: 02000000
SOFTE: 1
CFAR: 00000000000050fc
DAR: 0000000000001388, DSISR: 40000000
TASK = c00000007e560000[1] 'swapper/0' THREAD: c00000007e580000 CPU: 0
GPR00: 0000000000000000 c00000007e583930 c000000000c034d8 00000000000012d0
GPR04: 0000000000000000 0000000000001380 0000000000000000 0000000000000001
GPR08: c00000007e0dff60 0000000000000000 c000000000ca05a0 0000000000000000
GPR12: 0000000028004024 c00000000ff20000 0000000000000000 0000000000000000
GPR16: 0000000000000000 0000000000000000 0000000000000001 0000000000001380
GPR20: 0000000000000001 c000000000e14900 c000000000e148f0 0000000000000001
GPR24: c000000000c6f378 0000000000000000 0000000000001380 00000000000002aa
GPR28: 0000000000000000 0000000000000000 c000000000b576b0 c00000007e021200
NIP [c00000000014a070] .__alloc_pages_nodemask+0xd0/0x910
LR [c0000000001978cc] .new_slab+0xcc/0x3d0
Call Trace:
[c00000007e583930] [c00000007e5839c0] 0xc00000007e5839c0 (unreliable)
[c00000007e583ac0] [c0000000001978cc] .new_slab+0xcc/0x3d0
[c00000007e583b70] [c00000000072ae98] .__slab_alloc+0x38c/0x4f8
[c00000007e583cb0] [c000000000198190] .kmem_cache_alloc_node_trace+0x90/0x260
[c00000007e583d60] [c000000000a5a404] .numa_init+0x9c/0x188
[c00000007e583e00] [c00000000000aa30] .do_one_initcall+0x60/0x1e0
[c00000007e583ec0] [c000000000a40b60] .kernel_init+0x128/0x294
[c00000007e583f90] [c000000000020788] .kernel_thread+0x54/0x70
Instruction dump:
0b000000 eb1e8000 3b800000 801800a8 2f800000 409e001c 7860efe3 38000000
41820008 38000002 787c6fe2 7f9c0378 <e93a0008> 801800a4 3b600000 2fa90000
---[ end trace 31fd0ba7d8756002 ]---
Which seems to be this code in __alloc_pages_nodemask
---
/*
* Check the zones suitable for the gfp_mask contain at least one
* valid zone. It's possible to have an empty zonelist as a result
* of GFP_THISNODE and a memoryless node
*/
if (unlikely(!zonelist->_zonerefs->zone))
c00000000014a070: e9 3a 00 08 ld r9,8(r26)
---
r26 is coming from r5 which is the struct zonelist *zonelist parameter
to __alloc_pages_nodemask. Having 0000000000001380 in there is clearly
a bogus pointer.
Bisecting it points to b4cdf91668c27a5a6a5a3ed4234756c042dd8288
b4cdf91 sched/numa: Implement numa balancer
Trying David's patch just posted doesn't fix it.
Mikey
^ permalink raw reply
* Re: linux-next: PowerPC boot failures in next-20120521
From: David Rientjes @ 2012-05-22 1:53 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Lee Schermerhorn, Peter Zijlstra, Linus, LKML, linux-next,
H. Peter Anvin, Thomas Gleixner, ppc-dev, Ingo Molnar
In-Reply-To: <20120522114051.0c9db9a7c2d660bc9e0e1be2@canb.auug.org.au>
On Tue, 22 May 2012, Stephen Rothwell wrote:
> Unable to handle kernel paging request for data at address 0x00001688
> Faulting instruction address: 0xc00000000016e154
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in:
> NIP: c00000000016e154 LR: c0000000001b9140 CTR: 0000000000000000
> REGS: c0000003fc8c76d0 TRAP: 0300 Not tainted (3.4.0-autokern1)
> MSR: 8000000000009032 <SF,EE,ME,IR,DR,RI> CR: 24044022 XER: 00000003
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 0000000000001688, DSISR: 40000000
> TASK = c0000003fc8c8000[1] 'swapper/0' THREAD: c0000003fc8c4000 CPU: 0
> GPR00: 0000000000000000 c0000003fc8c7950 c000000000d05b30 00000000000012d0
> GPR04: 0000000000000000 0000000000001680 0000000000000000 c0000003fe032f60
> GPR08: 0004005400000001 0000000000000000 ffffffffffffc980 c000000000d24fe0
> GPR12: 0000000024044024 c00000000f33b000 0000000001a3fa78 00000000009bac00
> GPR16: 0000000000e1f338 0000000002d513f0 0000000000001680 0000000000000000
> GPR20: 0000000000000001 c0000003fc8c7c00 0000000000000000 0000000000000001
> GPR24: 0000000000000001 c000000000d1b490 0000000000000000 0000000000001680
> GPR28: 0000000000000000 0000000000000000 c000000000c7ce58 c0000003fe009200
> NIP [c00000000016e154] .__alloc_pages_nodemask+0xc4/0x8f0
> LR [c0000000001b9140] .new_slab+0xd0/0x3c0
> Call Trace:
> [c0000003fc8c7950] [2e6e756d615f696e] 0x2e6e756d615f696e (unreliable)
> [c0000003fc8c7ae0] [c0000000001b9140] .new_slab+0xd0/0x3c0
> [c0000003fc8c7b90] [c0000000001b9844] .__slab_alloc+0x254/0x5b0
> [c0000003fc8c7cd0] [c0000000001bb7a4] .kmem_cache_alloc_node_trace+0x94/0x260
> [c0000003fc8c7d80] [c000000000ba36d0] .numa_init+0x98/0x1dc
> [c0000003fc8c7e10] [c00000000000ace4] .do_one_initcall+0x1a4/0x1e0
> [c0000003fc8c7ed0] [c000000000b7b354] .kernel_init+0x124/0x2e0
> [c0000003fc8c7f90] [c0000000000211c8] .kernel_thread+0x54/0x70
> Instruction dump:
> 5400d97e 7b170020 0b000000 eb3e8000 3b800000 80190088 2f800000 40de0014
> 7860efe2 787c6fe2 78000fa4 7f9c0378 <e81b0008> 83f90000 2fa00000 7fff1838
> ---[ end trace 31fd0ba7d8756001 ]---
>
> swapper/0 (1) used greatest stack depth: 10864 bytes left
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
>
> I may be completely wrong, but I guess the obvious target would be the
> sched/numa branch that came in via the tip tree.
>
> Config file attached. I haven't had a chance to try to bisect this yet.
>
> Anyone have any ideas?
Yeah, it's sched/numa since that's what introduced numa_init(). It does
for_each_node() for each node and does a kmalloc_node() even though that
node may not be online. Slub ends up passing this node to the page
allocator through alloc_pages_exact_node(). CONFIG_DEBUG_VM would have
caught this and your config confirms its not enabled.
sched/numa either needs a memory hotplug notifier or it needs to pass
NUMA_NO_NODE for nodes that aren't online. Until we get the former, the
following should fix it.
sched, numa: Allocate node_queue on any node for offline nodes
struct node_queue must be allocated with NUMA_NO_NODE for nodes that are
not (yet) online, otherwise the page allocator has a bad zonelist.
Signed-off-by: David Rientjes <rientjes@google.com>
---
diff --git a/kernel/sched/numa.c b/kernel/sched/numa.c
--- a/kernel/sched/numa.c
+++ b/kernel/sched/numa.c
@@ -885,7 +885,8 @@ static __init int numa_init(void)
for_each_node(node) {
struct node_queue *nq = kmalloc_node(sizeof(*nq),
- GFP_KERNEL | __GFP_ZERO, node);
+ GFP_KERNEL | __GFP_ZERO,
+ node_online(node) ? node : NUMA_NO_NODE);
BUG_ON(!nq);
spin_lock_init(&nq->lock);
^ permalink raw reply
* powerpc -next rebase WARNING
From: Benjamin Herrenschmidt @ 2012-05-22 1:51 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Linux Kernel list
Folks, bad news ... my fault.
I accidentally forgot a --signoff on a git am command last week, meaning
that a pair of patches are in -next and not signed off by me.
For various (legal) reasons that cannot go into Linus tree as-is, so I
have to rebase the tree to fix it.
Sorry about that ...
Cheers,
Ben.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox