* Re: [PATCH v1 4/4] mmc: sdhci-of-esdhc: add erratum A011334 support in ls1028a 1.0 SoC
From: Adrian Hunter @ 2019-08-15 11:48 UTC (permalink / raw)
To: Yinbo Zhu, Rob Herring, Mark Rutland, Catalin Marinas,
Will Deacon, Ulf Hansson, Li Yang, Claudiu Manoil, Amit Jain,
Yangbo Lu, Vabhav Sharma, Rajesh Bhagat, Ashish Kumar, devicetree,
linux-arm-kernel, linux-kernel, linux-mmc
Cc: Alison Wang, Alex Marginean, xiaobo.xie, Catalin Horghidan,
Rajat Srivastava, jiafei.pan, linuxppc-dev
In-Reply-To: <20190814072649.8237-4-yinbo.zhu@nxp.com>
On 14/08/19 10:26 AM, Yinbo Zhu wrote:
> This patch is to add erratum A011334 support in ls1028a 1.0 SoC
>
> Signed-off-by: Yinbo Zhu <yinbo.zhu@nxp.com>
Acked-by: Adrian Hunter <adrian.hunter@intel.com>
> ---
> drivers/mmc/host/sdhci-of-esdhc.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/mmc/host/sdhci-of-esdhc.c b/drivers/mmc/host/sdhci-of-esdhc.c
> index b16f7d440f78..eb2b290447fc 100644
> --- a/drivers/mmc/host/sdhci-of-esdhc.c
> +++ b/drivers/mmc/host/sdhci-of-esdhc.c
> @@ -1006,6 +1006,7 @@ static struct soc_device_attribute soc_incorrect_hostver[] = {
> static struct soc_device_attribute soc_fixup_sdhc_clkdivs[] = {
> { .family = "QorIQ LX2160A", .revision = "1.0", },
> { .family = "QorIQ LX2160A", .revision = "2.0", },
> + { .family = "QorIQ LS1028A", .revision = "1.0", },
> { },
> };
>
>
^ permalink raw reply
* Re: [PATCH 02/10] PCI: designware-ep: Add the doorbell mode of MSI-X in EP mode
From: Andrew Murray @ 2019-08-15 11:53 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, gregkh,
jingoohan1, linuxppc-dev, linux-pci, linux-kernel, leoyang.li,
minghuan.Lian, devicetree, robh+dt, linux-arm-kernel,
gustavo.pimentel, bhelgaas, kishon, shawnguo, mingkai.hu
In-Reply-To: <20190815083716.4715-2-xiaowei.bao@nxp.com>
On Thu, Aug 15, 2019 at 04:37:08PM +0800, Xiaowei Bao wrote:
> Add the doorbell mode of MSI-X in EP mode.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> drivers/pci/controller/dwc/pcie-designware-ep.c | 14 ++++++++++++++
> drivers/pci/controller/dwc/pcie-designware.h | 14 ++++++++++++++
> 2 files changed, 28 insertions(+)
>
> diff --git a/drivers/pci/controller/dwc/pcie-designware-ep.c b/drivers/pci/controller/dwc/pcie-designware-ep.c
> index 75e2955..e3a7cdf 100644
> --- a/drivers/pci/controller/dwc/pcie-designware-ep.c
> +++ b/drivers/pci/controller/dwc/pcie-designware-ep.c
> @@ -454,6 +454,20 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
> return 0;
> }
>
> +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
> + u16 interrupt_num)
> +{
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + u32 msg_data;
> +
> + msg_data = (func_no << PCIE_MSIX_DOORBELL_PF_SHIFT) |
> + (interrupt_num - 1);
> +
> + dw_pcie_writel_dbi(pci, PCIE_MSIX_DOORBELL, msg_data);
> +
> + return 0;
> +}
> +
> int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> u16 interrupt_num)
Have I understood correctly that the hardware provides an alternative mechanism
that allows for raising MSI-X interrupts without the bother of reading the
capabilities registers?
If so is there any good reason to keep dw_pcie_ep_raise_msix_irq? (And thus use
it in dw_plat_pcie_ep_raise_irq also)?
> {
> diff --git a/drivers/pci/controller/dwc/pcie-designware.h b/drivers/pci/controller/dwc/pcie-designware.h
> index 2b291e8..cd903e9 100644
> --- a/drivers/pci/controller/dwc/pcie-designware.h
> +++ b/drivers/pci/controller/dwc/pcie-designware.h
> @@ -88,6 +88,11 @@
> #define PCIE_MISC_CONTROL_1_OFF 0x8BC
> #define PCIE_DBI_RO_WR_EN BIT(0)
>
> +#define PCIE_MSIX_DOORBELL 0x948
> +#define PCIE_MSIX_DOORBELL_PF_SHIFT 24
> +#define PCIE_MSIX_DOORBELL_VF_SHIFT 16
> +#define PCIE_MSIX_DOORBELL_VF_ACTIVE BIT(15)
The _VF defines are not used, I'd suggest removing them.
Thanks,
Andrew Murray
> +
> /*
> * iATU Unroll-specific register definitions
> * From 4.80 core version the address translation will be made by unroll
> @@ -399,6 +404,8 @@ int dw_pcie_ep_raise_msi_irq(struct dw_pcie_ep *ep, u8 func_no,
> u8 interrupt_num);
> int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> u16 interrupt_num);
> +int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep, u8 func_no,
> + u16 interrupt_num);
> void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar);
> #else
> static inline void dw_pcie_ep_linkup(struct dw_pcie_ep *ep)
> @@ -431,6 +438,13 @@ static inline int dw_pcie_ep_raise_msix_irq(struct dw_pcie_ep *ep, u8 func_no,
> return 0;
> }
>
> +static inline int dw_pcie_ep_raise_msix_irq_doorbell(struct dw_pcie_ep *ep,
> + u8 func_no,
> + u16 interrupt_num)
> +{
> + return 0;
> +}
> +
> static inline void dw_pcie_ep_reset_bar(struct dw_pcie *pci, enum pci_barno bar)
> {
> }
> --
> 2.9.5
>
>
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH 05/10] PCI: layerscape: Modify the way of getting capability with different PEX
From: Andrew Murray @ 2019-08-15 12:51 UTC (permalink / raw)
To: Xiaowei Bao
Cc: mark.rutland, roy.zang, lorenzo.pieralisi, arnd, gregkh,
jingoohan1, linuxppc-dev, linux-pci, linux-kernel, leoyang.li,
minghuan.Lian, devicetree, robh+dt, linux-arm-kernel,
gustavo.pimentel, bhelgaas, kishon, shawnguo, mingkai.hu
In-Reply-To: <20190815083716.4715-5-xiaowei.bao@nxp.com>
On Thu, Aug 15, 2019 at 04:37:11PM +0800, Xiaowei Bao wrote:
> The different PCIe controller in one board may be have different
> capability of MSI or MSIX, so change the way of getting the MSI
> capability, make it more flexible.
>
> Signed-off-by: Xiaowei Bao <xiaowei.bao@nxp.com>
> ---
> drivers/pci/controller/dwc/pci-layerscape-ep.c | 28 +++++++++++++++++++-------
> 1 file changed, 21 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/pci/controller/dwc/pci-layerscape-ep.c b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> index be61d96..9404ca0 100644
> --- a/drivers/pci/controller/dwc/pci-layerscape-ep.c
> +++ b/drivers/pci/controller/dwc/pci-layerscape-ep.c
> @@ -22,6 +22,7 @@
>
> struct ls_pcie_ep {
> struct dw_pcie *pci;
> + struct pci_epc_features *ls_epc;
> };
>
> #define to_ls_pcie_ep(x) dev_get_drvdata((x)->dev)
> @@ -40,25 +41,26 @@ static const struct of_device_id ls_pcie_ep_of_match[] = {
> { },
> };
>
> -static const struct pci_epc_features ls_pcie_epc_features = {
> - .linkup_notifier = false,
> - .msi_capable = true,
> - .msix_capable = false,
> -};
> -
> static const struct pci_epc_features*
> ls_pcie_ep_get_features(struct dw_pcie_ep *ep)
> {
> - return &ls_pcie_epc_features;
> + struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> +
> + return pcie->ls_epc;
> }
>
> static void ls_pcie_ep_init(struct dw_pcie_ep *ep)
> {
> struct dw_pcie *pci = to_dw_pcie_from_ep(ep);
> + struct ls_pcie_ep *pcie = to_ls_pcie_ep(pci);
> enum pci_barno bar;
>
> for (bar = BAR_0; bar <= BAR_5; bar++)
> dw_pcie_ep_reset_bar(pci, bar);
> +
> + pcie->ls_epc->msi_capable = ep->msi_cap ? true : false;
> + pcie->ls_epc->msix_capable = ep->msix_cap ? true : false;
> }
>
> static int ls_pcie_ep_raise_irq(struct dw_pcie_ep *ep, u8 func_no,
> @@ -118,6 +120,7 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> struct device *dev = &pdev->dev;
> struct dw_pcie *pci;
> struct ls_pcie_ep *pcie;
> + struct pci_epc_features *ls_epc;
> struct resource *dbi_base;
> int ret;
>
> @@ -129,6 +132,10 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> if (!pci)
> return -ENOMEM;
>
> + ls_epc = devm_kzalloc(dev, sizeof(*ls_epc), GFP_KERNEL);
> + if (!ls_epc)
> + return -ENOMEM;
> +
> dbi_base = platform_get_resource_byname(pdev, IORESOURCE_MEM, "regs");
> pci->dbi_base = devm_pci_remap_cfg_resource(dev, dbi_base);
> if (IS_ERR(pci->dbi_base))
> @@ -139,6 +146,13 @@ static int __init ls_pcie_ep_probe(struct platform_device *pdev)
> pci->ops = &ls_pcie_ep_ops;
> pcie->pci = pci;
>
> + ls_epc->linkup_notifier = false,
> + ls_epc->msi_capable = true,
> + ls_epc->msix_capable = true,
As [msi,msix]_capable is shortly set from ls_pcie_ep_init - is there any
reason to set them here (to potentially incorrect values)?
Thanks,
Andrew Murray
> + ls_epc->bar_fixed_64bit = (1 << BAR_2) | (1 << BAR_4),
> +
> + pcie->ls_epc = ls_epc;
> +
> platform_set_drvdata(pdev, pcie);
>
> ret = ls_add_pcie_ep(pcie, pdev);
> --
> 2.9.5
>
^ permalink raw reply
* ppc64le kernel panic on 5.2.9-rc1
From: Major Hayden @ 2019-08-15 12:29 UTC (permalink / raw)
To: linuxppc-dev
Hello there,
The CKI Project just found a kernel panic while running the blktests test suite on stable 5.2.9-rc1[0]. Michael Ellerman requested for this list to be copied on these ppc64le failures.
We have some logs[1] for these failures and they start with "ppc64le_host_2_Storage_blktests*". We hope this helps!
[0] https://lore.kernel.org/stable/255f9af4-6087-7f56-5860-5aa0397a7631@redhat.com/T/#t
[1] https://artifacts.cki-project.org/pipelines/100875/logs/
--
Major Hayden
^ permalink raw reply
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Greg Kroah-Hartman @ 2019-08-15 13:03 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190811080520.21712-7-hch@lst.de>
On Sun, Aug 11, 2019 at 10:05:20AM +0200, Christoph Hellwig wrote:
> We still treat devices without a DMA mask as defaulting to 32-bits for
> both mask, but a few releases ago we've started warning about such
> cases, as they require special cases to work around this sloppyness.
> Add a dma_mask field to struct platform_object so that we can initialize
> the dma_mask pointer in struct device and initialize both masks to
> 32-bits by default. Architectures can still override this in
> arch_setup_pdev_archdata if needed.
>
> Note that the code looks a little odd with the various conditionals
> because we have to support platform_device structures that are
> statically allocated.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> ---
> drivers/base/platform.c | 15 +++++++++++++--
> include/linux/platform_device.h | 1 +
> 2 files changed, 14 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/base/platform.c b/drivers/base/platform.c
> index ec974ba9c0c4..b216fcb0a8af 100644
> --- a/drivers/base/platform.c
> +++ b/drivers/base/platform.c
> @@ -264,6 +264,17 @@ struct platform_object {
> char name[];
> };
>
> +static void setup_pdev_archdata(struct platform_device *pdev)
> +{
> + if (!pdev->dev.coherent_dma_mask)
> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dma_mask)
> + pdev->dma_mask = DMA_BIT_MASK(32);
> + if (!pdev->dev.dma_mask)
> + pdev->dev.dma_mask = &pdev->dma_mask;
> + arch_setup_pdev_archdata(pdev);
> +};
> +
> /**
> * platform_device_put - destroy a platform device
> * @pdev: platform device to free
> @@ -310,7 +321,7 @@ struct platform_device *platform_device_alloc(const char *name, int id)
> pa->pdev.id = id;
> device_initialize(&pa->pdev.dev);
> pa->pdev.dev.release = platform_device_release;
> - arch_setup_pdev_archdata(&pa->pdev);
> + setup_pdev_archdata(&pa->pdev);
> }
>
> return pa ? &pa->pdev : NULL;
> @@ -512,7 +523,7 @@ EXPORT_SYMBOL_GPL(platform_device_del);
> int platform_device_register(struct platform_device *pdev)
> {
> device_initialize(&pdev->dev);
> - arch_setup_pdev_archdata(pdev);
> + setup_pdev_archdata(pdev);
> return platform_device_add(pdev);
> }
> EXPORT_SYMBOL_GPL(platform_device_register);
> diff --git a/include/linux/platform_device.h b/include/linux/platform_device.h
> index 9bc36b589827..a2abde2aef25 100644
> --- a/include/linux/platform_device.h
> +++ b/include/linux/platform_device.h
> @@ -24,6 +24,7 @@ struct platform_device {
> int id;
> bool id_auto;
> struct device dev;
> + u64 dma_mask;
Why is the dma_mask in 'struct device' which is part of this structure,
not sufficient here? Shouldn't the "platform" be setting that up
correctly already in the "archdata" type callback?
confused,
greg k-h
^ permalink raw reply
* Re: [PATCH 3/3] papr/scm: Add bad memory ranges to nvdimm bad ranges
From: Oliver O'Halloran @ 2019-08-15 13:11 UTC (permalink / raw)
To: Santosh Sivaraj
Cc: Reza Arbab, Aneesh Kumar K.V, Chandan Rajendra, linuxppc-dev,
Mahesh J Salgaonkar
In-Reply-To: <20190814082452.28013-4-santosh@fossix.org>
On Wed, Aug 14, 2019 at 6:25 PM Santosh Sivaraj <santosh@fossix.org> wrote:
>
> Subscribe to the MCE notification and add the physical address which
> generated a memory error to nvdimm bad range.
>
> Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
> ---
> arch/powerpc/platforms/pseries/papr_scm.c | 65 +++++++++++++++++++++++
> 1 file changed, 65 insertions(+)
>
> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
> index a5ac371a3f06..4d25c98a9835 100644
> --- a/arch/powerpc/platforms/pseries/papr_scm.c
> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
> @@ -12,6 +12,8 @@
> #include <linux/libnvdimm.h>
> #include <linux/platform_device.h>
> #include <linux/delay.h>
> +#include <linux/nd.h>
> +#include <asm/mce.h>
>
> #include <asm/plpar_wrappers.h>
>
> @@ -39,8 +41,12 @@ struct papr_scm_priv {
> struct resource res;
> struct nd_region *region;
> struct nd_interleave_set nd_set;
> + struct list_head list;
list is not a meaningful name. call it something more descriptive.
> };
>
> +LIST_HEAD(papr_nd_regions);
> +DEFINE_MUTEX(papr_ndr_lock);
Should this be a mutex or a spinlock? I don't know what context the
mce notifier is called from, but if it's not sleepable then a mutex
will cause problems. Did you test this with lockdep enabled?
> +
> static int drc_pmem_bind(struct papr_scm_priv *p)
> {
> unsigned long ret[PLPAR_HCALL_BUFSIZE];
> @@ -364,6 +370,10 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
> dev_info(dev, "Region registered with target node %d and online node %d",
> target_nid, online_nid);
>
> + mutex_lock(&papr_ndr_lock);
> + list_add_tail(&p->list, &papr_nd_regions);
> + mutex_unlock(&papr_ndr_lock);
> +
Where's the matching remove when we unbind the driver?
> return 0;
>
> err: nvdimm_bus_unregister(p->bus);
> @@ -371,6 +381,60 @@ err: nvdimm_bus_unregister(p->bus);
> return -ENXIO;
> }
>
> +static int handle_mce_ue(struct notifier_block *nb, unsigned long val,
> + void *data)
> +{
> + struct machine_check_event *evt = data;
> + struct papr_scm_priv *p;
> + u64 phys_addr;
> +
> + if (evt->error_type != MCE_ERROR_TYPE_UE)
> + return NOTIFY_DONE;
> +
> + if (list_empty(&papr_nd_regions))
> + return NOTIFY_DONE;
> +
> + phys_addr = evt->u.ue_error.physical_address +
> + (evt->u.ue_error.effective_address & ~PAGE_MASK);
Wait what? Why is physical_address page aligned, but effective_address
not? Not a problem with this patch, but still, what the hell?
> + if (!evt->u.ue_error.physical_address_provided ||
> + !is_zone_device_page(pfn_to_page(phys_addr >> PAGE_SHIFT)))
> + return NOTIFY_DONE;
> +
> + mutex_lock(&papr_ndr_lock);
> + list_for_each_entry(p, &papr_nd_regions, list) {
> + struct resource res = p->res;
> + u64 aligned_addr;
> +
> + if (res.start > phys_addr)
> + continue;
> +
> + if (res.end < phys_addr)
> + continue;
surely there's a helper for this
> +
> + aligned_addr = ALIGN_DOWN(phys_addr, L1_CACHE_BYTES);
> + pr_debug("Add memory range (0x%llx -- 0x%llx) as bad range\n",
> + aligned_addr, aligned_addr + L1_CACHE_BYTES);
> +
> + if (nvdimm_bus_add_badrange(p->bus,
> + aligned_addr, L1_CACHE_BYTES))
> + pr_warn("Failed to add bad range (0x%llx -- 0x%llx)\n",
> + aligned_addr, aligned_addr + L1_CACHE_BYTES);
> +
> + nvdimm_region_notify(p->region,
> + NVDIMM_REVALIDATE_POISON);
> +
> + break;
nit: you can avoid stacking indetation levels by breaking out of the
loop as soon as you've found the region you're looking for.
> + }
> + mutex_unlock(&papr_ndr_lock);
> +
> + return NOTIFY_OK;
> +}
> +
> +static struct notifier_block mce_ue_nb = {
> + .notifier_call = handle_mce_ue
> +};
> +
> static int papr_scm_probe(struct platform_device *pdev)
> {
> struct device_node *dn = pdev->dev.of_node;
> @@ -456,6 +520,7 @@ static int papr_scm_probe(struct platform_device *pdev)
> goto err2;
>
> platform_set_drvdata(pdev, p);
> + mce_register_notifier(&mce_ue_nb);
Either get rid of the global region list and have a notifier block in
each device's driver private data, or keep the global list and
register the notifier in module_init(). Re-registering the notifier
each time a seperate device is probed seems very sketchy.
> return 0;
>
> --
> 2.21.0
>
^ permalink raw reply
* Re: next take at setting up a dma mask by default for platform devices
From: Greg Kroah-Hartman @ 2019-08-15 13:23 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190811080520.21712-1-hch@lst.de>
On Sun, Aug 11, 2019 at 10:05:14AM +0200, Christoph Hellwig wrote:
> Hi all,
>
> this is another attempt to make sure the dma_mask pointer is always
> initialized for platform devices. Not doing so lead to lots of
> boilerplate code, and makes platform devices different from all our
> major busses like PCI where we always set up a dma_mask. In the long
> run this should also help to eventually make dma_mask a scalar value
> instead of a pointer and remove even more cruft.
>
> The bigger blocker for this last time was the fact that the usb
> subsystem uses the presence or lack of a dma_mask to check if the core
> should do dma mapping for the driver, which is highly unusual. So we
> fix this first. Note that this has some overlap with the pending
> desire to use the proper dma_mmap_coherent helper for mapping usb
> buffers. The first two patches from this series should probably
> go into 5.3 and then uses as the basis for the decision to use
> dma_mmap_coherent.
I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
to be fixed, I'll wait for a respin of these before considering them.
thanks,
greg k-h
^ permalink raw reply
* Re: next take at setting up a dma mask by default for platform devices
From: Christoph Hellwig @ 2019-08-15 13:25 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Gavin Li, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Laurentiu Tudor, Geoff Levand,
Shawn Guo, linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815132318.GA27208@kroah.com>
On Thu, Aug 15, 2019 at 03:23:18PM +0200, Greg Kroah-Hartman wrote:
> I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
> to be fixed, I'll wait for a respin of these before considering them.
I have a respun version ready, but I'd really like to hear some
comments from usb developers about the approach before spamming
everyone again..
^ permalink raw reply
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Christoph Hellwig @ 2019-08-15 13:32 UTC (permalink / raw)
To: Robin Murphy
Cc: Gavin Li, Shawn Guo, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Geoff Levand, Greg Kroah-Hartman,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <fbea6e6d-7721-b51d-0501-582e8446e9c9@arm.com>
On Wed, Aug 14, 2019 at 04:49:13PM +0100, Robin Murphy wrote:
>> because we have to support platform_device structures that are
>> statically allocated.
>
> This would be a good point to also get rid of the long-standing bodge in
> platform_device_register_full().
platform_device_register_full looks odd to start with, especially
as the coumentation is rather lacking..
>> +static void setup_pdev_archdata(struct platform_device *pdev)
>
> Bikeshed: painting the generic DMA API properties as "archdata" feels a bit
> off-target :/
>
>> +{
>> + if (!pdev->dev.coherent_dma_mask)
>> + pdev->dev.coherent_dma_mask = DMA_BIT_MASK(32);
>> + if (!pdev->dma_mask)
>> + pdev->dma_mask = DMA_BIT_MASK(32);
>> + if (!pdev->dev.dma_mask)
>> + pdev->dev.dma_mask = &pdev->dma_mask;
>> + arch_setup_pdev_archdata(pdev);
>
> AFAICS m68k's implementation of that arch hook becomes entirely redundant
> after this change, so may as well go. That would just leave powerpc's
> actual archdata, which at a glance looks like it could probably be cleaned
> up with not *too* much trouble.
Actually I think we can just kill both off. At the point archdata
is indeed entirely misnamed.
^ permalink raw reply
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Christoph Hellwig @ 2019-08-15 13:38 UTC (permalink / raw)
To: Greg Kroah-Hartman
Cc: Gavin Li, Fabio Estevam, Christoph Hellwig, linux-arch,
Michal Simek, Maxime Chevallier, Alan Stern, NXP Linux Team,
Mathias Nyman, Sascha Hauer, Minas Harutyunyan, Olav Kongas,
Bin Liu, linux-arm-kernel, Laurentiu Tudor, Geoff Levand,
Shawn Guo, linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815130325.GB17065@kroah.com>
On Thu, Aug 15, 2019 at 03:03:25PM +0200, Greg Kroah-Hartman wrote:
> > --- a/include/linux/platform_device.h
> > +++ b/include/linux/platform_device.h
> > @@ -24,6 +24,7 @@ struct platform_device {
> > int id;
> > bool id_auto;
> > struct device dev;
> > + u64 dma_mask;
>
> Why is the dma_mask in 'struct device' which is part of this structure,
> not sufficient here? Shouldn't the "platform" be setting that up
> correctly already in the "archdata" type callback?
Becaus the dma_mask in struct device is a pointer that needs to point
to something, and this is the best space we can allocate for 'something'.
m68k and powerpc currently do something roughly equivalent at the moment,
while everyone else just has horrible, horrible hacks. As mentioned in
the changelog the intent of this patch is that we treat platform devices
like any other bus, where the bus allocates the space for the dma_mask.
The long term plan is to eventually kill that weird pointer indirection
that doesn't help anyone, but for that we need to sort out the basics
first.
^ permalink raw reply
* Re: [PATCH v10 2/7] powerpc/mce: Fix MCE handling for huge pages
From: Sasha Levin @ 2019-08-15 13:56 UTC (permalink / raw)
To: Sasha Levin, Santosh Sivaraj, Balbir Singh, linuxppc-dev
Cc: Aneesh Kumar K.V, stable
In-Reply-To: <20190815003941.18655-3-santosh@fossix.org>
Hi,
[This is an automated email]
This commit has been processed because it contains a "Fixes:" tag,
fixing commit: ba41e1e1ccb9 powerpc/mce: Hookup derror (load/store) UE errors.
The bot has tested the following trees: v5.2.8, v4.19.66.
v5.2.8: Build OK!
v4.19.66: Failed to apply! Possible dependencies:
360cae313702 ("KVM: PPC: Book3S HV: Nested guest entry via hypercall")
41f4e631daf8 ("KVM: PPC: Book3S HV: Extract PMU save/restore operations as C-callable functions")
884dfb722db8 ("KVM: PPC: Book3S HV: Simplify machine check handling")
89329c0be8bd ("KVM: PPC: Book3S HV: Clear partition table entry on vm teardown")
8e3f5fc1045d ("KVM: PPC: Book3S HV: Framework and hcall stubs for nested virtualization")
95a6432ce903 ("KVM: PPC: Book3S HV: Streamlined guest entry/exit path on P9 for radix guests")
a43c1590426c ("powerpc/pseries: Flush SLB contents on SLB MCE errors.")
c05772018491 ("powerpc/64s: Better printing of machine check info for guest MCEs")
d24ea8a7336a ("KVM: PPC: Book3S: Simplify external interrupt handling")
df709a296ef7 ("KVM: PPC: Book3S HV: Simplify real-mode interrupt handling")
f7035ce9f1df ("KVM: PPC: Book3S HV: Move interrupt delivery on guest entry to C code")
NOTE: The patch will not be queued to stable trees until it is upstream.
How should we proceed with this patch?
--
Thanks,
Sasha
^ permalink raw reply
* Re: [PATCH 3/3] papr/scm: Add bad memory ranges to nvdimm bad ranges
From: Santosh Sivaraj @ 2019-08-15 14:00 UTC (permalink / raw)
To: Oliver O'Halloran
Cc: Reza Arbab, Aneesh Kumar K.V, Chandan Rajendra, linuxppc-dev,
Mahesh J Salgaonkar
In-Reply-To: <CAOSf1CFqFHqCKQ7tf1CZjucdH5UnZ_DiuqEkppwZZLc0qYY-ZQ@mail.gmail.com>
"Oliver O'Halloran" <oohall@gmail.com> writes:
> On Wed, Aug 14, 2019 at 6:25 PM Santosh Sivaraj <santosh@fossix.org> wrote:
>>
>> Subscribe to the MCE notification and add the physical address which
>> generated a memory error to nvdimm bad range.
>>
>> Signed-off-by: Santosh Sivaraj <santosh@fossix.org>
>> ---
>> arch/powerpc/platforms/pseries/papr_scm.c | 65 +++++++++++++++++++++++
>> 1 file changed, 65 insertions(+)
>>
>> diff --git a/arch/powerpc/platforms/pseries/papr_scm.c b/arch/powerpc/platforms/pseries/papr_scm.c
>> index a5ac371a3f06..4d25c98a9835 100644
>> --- a/arch/powerpc/platforms/pseries/papr_scm.c
>> +++ b/arch/powerpc/platforms/pseries/papr_scm.c
>> @@ -12,6 +12,8 @@
>> #include <linux/libnvdimm.h>
>> #include <linux/platform_device.h>
>> #include <linux/delay.h>
>> +#include <linux/nd.h>
>> +#include <asm/mce.h>
>>
>> #include <asm/plpar_wrappers.h>
>>
>> @@ -39,8 +41,12 @@ struct papr_scm_priv {
>> struct resource res;
>> struct nd_region *region;
>> struct nd_interleave_set nd_set;
>> + struct list_head list;
>
> list is not a meaningful name. call it something more descriptive.
>
>> };
>>
>> +LIST_HEAD(papr_nd_regions);
>> +DEFINE_MUTEX(papr_ndr_lock);
>
> Should this be a mutex or a spinlock? I don't know what context the
> mce notifier is called from, but if it's not sleepable then a mutex
> will cause problems. Did you test this with lockdep enabled?
This would be a mutex, we are called from a blocking notifier.
>
>> +
>> static int drc_pmem_bind(struct papr_scm_priv *p)
>> {
>> unsigned long ret[PLPAR_HCALL_BUFSIZE];
>> @@ -364,6 +370,10 @@ static int papr_scm_nvdimm_init(struct papr_scm_priv *p)
>> dev_info(dev, "Region registered with target node %d and online node %d",
>> target_nid, online_nid);
>>
>> + mutex_lock(&papr_ndr_lock);
>> + list_add_tail(&p->list, &papr_nd_regions);
>> + mutex_unlock(&papr_ndr_lock);
>> +
>
> Where's the matching remove when we unbind the driver?
Missed it completely. Will fix it.
>
>> return 0;
>>pp
>> err: nvdimm_bus_unregister(p->bus);
>> @@ -371,6 +381,60 @@ err: nvdimm_bus_unregister(p->bus);
>> return -ENXIO;
>> }
>>
>> +static int handle_mce_ue(struct notifier_block *nb, unsigned long val,
>> + void *data)
>> +{
>> + struct machine_check_event *evt = data;
>> + struct papr_scm_priv *p;
>> + u64 phys_addr;
>> +
>> + if (evt->error_type != MCE_ERROR_TYPE_UE)
>> + return NOTIFY_DONE;
>> +
>> + if (list_empty(&papr_nd_regions))
>> + return NOTIFY_DONE;
>> +
>> + phys_addr = evt->u.ue_error.physical_address +
>> + (evt->u.ue_error.effective_address & ~PAGE_MASK);
>
> Wait what? Why is physical_address page aligned, but effective_address
> not? Not a problem with this patch, but still, what the hell?
Not sure why, but its the way now. I can see if I can update it if it makes
sense in a later patch.
>
>> + if (!evt->u.ue_error.physical_address_provided ||
>> + !is_zone_device_page(pfn_to_page(phys_addr >> PAGE_SHIFT)))
>> + return NOTIFY_DONE;
>> +
>> + mutex_lock(&papr_ndr_lock);
>> + list_for_each_entry(p, &papr_nd_regions, list) {
>> + struct resource res = p->res;
>> + u64 aligned_addr;
>> +
>
>> + if (res.start > phys_addr)
>> + continue;
>> +
>> + if (res.end < phys_addr)
>> + continue;
>
> surely there's a helper for this
>
>> +
>> + aligned_addr = ALIGN_DOWN(phys_addr, L1_CACHE_BYTES);
>> + pr_debug("Add memory range (0x%llx -- 0x%llx) as bad range\n",
>> + aligned_addr, aligned_addr + L1_CACHE_BYTES);
>> +
>> + if (nvdimm_bus_add_badrange(p->bus,
>> + aligned_addr, L1_CACHE_BYTES))
>> + pr_warn("Failed to add bad range (0x%llx -- 0x%llx)\n",
>> + aligned_addr, aligned_addr + L1_CACHE_BYTES);
>> +
>> + nvdimm_region_notify(p->region,
>> + NVDIMM_REVALIDATE_POISON);
>> +
>> + break;
>
> nit: you can avoid stacking indetation levels by breaking out of the
> loop as soon as you've found the region you're looking for.
True.
>
>> + }
>> + mutex_unlock(&papr_ndr_lock);
>> +
>> + return NOTIFY_OK;
>> +}
>> +
>> +static struct notifier_block mce_ue_nb = {
>> + .notifier_call = handle_mce_ue
>> +};
>> +
>> static int papr_scm_probe(struct platform_device *pdev)
>> {
>> struct device_node *dn = pdev->dev.of_node;
>> @@ -456,6 +520,7 @@ static int papr_scm_probe(struct platform_device *pdev)
>> goto err2;
>>
>> platform_set_drvdata(pdev, p);
>> + mce_register_notifier(&mce_ue_nb);
>
> Either get rid of the global region list and have a notifier block in
> each device's driver private data, or keep the global list and
> register the notifier in module_init(). Re-registering the notifier
> each time a seperate device is probed seems very sketchy.
Registering the notifier in the init is simpler. I will change it.
>
>> return 0;
>>
>> --
>> 2.21.0
p>>
^ permalink raw reply
* Re: [PATCH 6/6] driver core: initialize a default DMA mask for platform device
From: Greg Kroah-Hartman @ 2019-08-15 14:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815133812.GF12036@lst.de>
On Thu, Aug 15, 2019 at 03:38:12PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 15, 2019 at 03:03:25PM +0200, Greg Kroah-Hartman wrote:
> > > --- a/include/linux/platform_device.h
> > > +++ b/include/linux/platform_device.h
> > > @@ -24,6 +24,7 @@ struct platform_device {
> > > int id;
> > > bool id_auto;
> > > struct device dev;
> > > + u64 dma_mask;
> >
> > Why is the dma_mask in 'struct device' which is part of this structure,
> > not sufficient here? Shouldn't the "platform" be setting that up
> > correctly already in the "archdata" type callback?
>
> Becaus the dma_mask in struct device is a pointer that needs to point
> to something, and this is the best space we can allocate for 'something'.
> m68k and powerpc currently do something roughly equivalent at the moment,
> while everyone else just has horrible, horrible hacks. As mentioned in
> the changelog the intent of this patch is that we treat platform devices
> like any other bus, where the bus allocates the space for the dma_mask.
> The long term plan is to eventually kill that weird pointer indirection
> that doesn't help anyone, but for that we need to sort out the basics
> first.
Ah, missed that, sorry. Ok, no objection from me. Might as well respin
this series and I can queue it up after 5.3-rc5 is out (which will have
your first 2 patches in it.)
thanks,
greg k-h
^ permalink raw reply
* Re: next take at setting up a dma mask by default for platform devices
From: Greg Kroah-Hartman @ 2019-08-15 14:05 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Gavin Li, Fabio Estevam, linux-arch, Michal Simek,
Maxime Chevallier, Alan Stern, NXP Linux Team, Mathias Nyman,
Sascha Hauer, Minas Harutyunyan, Olav Kongas, Bin Liu,
linux-arm-kernel, Laurentiu Tudor, Geoff Levand, Shawn Guo,
linux-usb, linux-kernel, Tony Prisk, iommu,
Pengutronix Kernel Team, linuxppc-dev
In-Reply-To: <20190815132531.GA12036@lst.de>
On Thu, Aug 15, 2019 at 03:25:31PM +0200, Christoph Hellwig wrote:
> On Thu, Aug 15, 2019 at 03:23:18PM +0200, Greg Kroah-Hartman wrote:
> > I've taken the first 2 patches for 5.3-final. Given that patch 3 needs
> > to be fixed, I'll wait for a respin of these before considering them.
>
> I have a respun version ready, but I'd really like to hear some
> comments from usb developers about the approach before spamming
> everyone again..
Spam away, we can take it :)
^ permalink raw reply
* Re: [PATCH 7/8] parisc: don't set ARCH_NO_COHERENT_DMA_MMAP
From: James Bottomley @ 2019-08-15 9:25 UTC (permalink / raw)
To: Christoph Hellwig, iommu, Marek Szyprowski
Cc: linux-xtensa, Michal Simek, Vladimir Murzin, linux-parisc,
linux-sh, Takashi Iwai, linuxppc-dev, Helge Deller, x86,
linux-kernel, linux-m68k, Robin Murphy, linux-arm-kernel
In-Reply-To: <20190808160005.10325-8-hch@lst.de>
On Thu, 2019-08-08 at 19:00 +0300, Christoph Hellwig wrote:
> parisc is the only architecture that sets ARCH_NO_COHERENT_DMA_MMAP
> when an MMU is enabled. AFAIK this is because parisc CPUs use VIVT
> caches,
We're actually VIPT but the same principle applies.
> which means exporting normally cachable memory to userspace is
> relatively dangrous due to cache aliasing.
>
> But normally cachable memory is only allocated by dma_alloc_coherent
> on parisc when using the sba_iommu or ccio_iommu drivers, so just
> remove the .mmap implementation for them so that we don't have to set
> ARCH_NO_COHERENT_DMA_MMAP, which I plan to get rid of.
So I don't think this is quite right. We have three architectural
variants essentially (hidden behind about 12 cpu types):
1. pa70xx: These can't turn off page caching, so they were the non
coherent problem case
2. pa71xx: These can manufacture coherent memory simply by turning off
the cache on a per page basis
3. pa8xxx: these have a full cache flush coherence mechanism.
(I might have this slightly wrong: I vaguely remember the pa71xxlc
variants have some weird cache quirks for DMA as well)
So I think pa70xx we can't mmap. pa71xx we can provided we mark the
page as uncached ... which should already have happened in the allocate
and pa8xxx which can always mmap dma memory without any special tricks.
James
^ permalink raw reply
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-15 14:38 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #26 from Erhard F. (erhard_f@mailbox.org) ---
On Wed, 14 Aug 2019 20:33:51 +0000
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
>--- Comment #24 from Christophe Leroy (christophe.leroy@c-s.fr) ---
>It confirms what I suspected: due to some debug options, kzalloc() doesn't
>provide aligned areas.
>
>In __load_free_space_cache() can you replace
>e->bitmap = kzalloc(PAGE_SIZE, GFP_NOFS);
>By
>e->bitmap = (void *)__get_free_page(GFP_NOFS | __GFP_ZERO);
>
>And same in insert_into_bitmap()
>
>Then replace the three kfree() which free bitmaps by something like
>free_page((unsigned long)entry->bitmap)
>
> --- Comment #25 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> You can use get_zeroed_page(GFP_NOFS) instead of __get_free_page(GFP_NOFS |
> __GFP_ZERO)
Think I got everything right after a bit of searching...
Now I get this nice compact output:
[..]
[ 46.579181] ------------[ cut here ]------------
[ 46.579378] kernel BUG at mm/slub.c:3952!
[ 46.579513] Oops: Exception in kernel mode, sig: 5 [#1]
[ 46.579699] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
[ 46.579898] Modules linked in: b43legacy led_class mac80211 cfg80211
snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa rfkill libarc4 evdev btrfs
therm_windtunnel ohci_pci xor zstd_decompress zstd_compress zlib_deflate
raid6_pq zlib_inflate radeon sr_mod firewire_ohci sungem hwmon snd_aoa_i2sbus
i2c_algo_bit backlight cdrom firewire_core sungem_phy crc_itu_t
snd_aoa_soundbus snd_pcm drm_kms_helper ohci_hcd syscopyarea ehci_pci snd_timer
sysfillrect snd sysimgblt fb_sys_fops ttm ehci_hcd soundcore drm
drm_panel_orientation_quirks usbcore uninorth_agp usb_common agpgart ssb lzo
lzo_compress lzo_decompress zram zsmalloc
[ 46.582252] CPU: 0 PID: 261 Comm: umount Tainted: G W
5.3.0-rc4+ #2
[ 46.582533] NIP: c0198228 LR: c0198204 CTR: c01981a4
[ 46.582708] REGS: dbbc1c10 TRAP: 0700 Tainted: G W
(5.3.0-rc4+)
[ 46.582990] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 22008824 XER: 00000000
[ 46.583243]
GPR00: f110b444 dbbc1cc8 ec2944a0 ef4329f4 c07fe5f8 8950b76e
00001032 00000000
GPR08: 2854c000 00000001 00000000 dbbc1d18 c01981a4 008f5ff4
00000000 00000000
GPR16: 00000000 00000000 bff5d9dc bff5d9c4 00000001 00000000
00000000 00000000
GPR24: 00000000 f110b444 00000100 dba800b8 f11b0000 c07fe5f8
ed3d5000 ef4329f4
[ 46.584505] NIP [c0198228] kfree+0x84/0x29c
[ 46.584642] LR [c0198204] kfree+0x60/0x29c
[ 46.584774] Call Trace:
[ 46.585254] [dbbc1cc8] [f110b4e0]
__btrfs_remove_free_space_cache_locked+0x58/0x6c [btrfs] (unreliable)
[ 46.585717] [dbbc1d18] [f110b444] free_bitmap+0x24/0x68 [btrfs]
[ 46.586008] [dbbc1d38] [f110b4f0]
__btrfs_remove_free_space_cache_locked+0x68/0x6c [btrfs]
[ 46.586388] [dbbc1d58] [f110e6ac] btrfs_remove_free_space_cache+0x38/0x84
[btrfs]
[ 46.586732] [dbbc1d78] [f10a77a4] btrfs_free_block_groups+0x164/0x24c
[btrfs]
[ 46.587073] [dbbc1db8] [f10b993c] close_ctree+0x230/0x2c4 [btrfs]
[ 46.587303] [dbbc1df8] [c01ab508] generic_shutdown_super+0x80/0x110
[ 46.587531] [dbbc1e18] [c01ab718] kill_anon_super+0x18/0x30
[ 46.587802] [dbbc1e38] [f10908b4] btrfs_kill_super+0x18/0x30 [btrfs]
[ 46.588039] [dbbc1e58] [c01abdbc] deactivate_locked_super+0x54/0xa4
[ 46.588269] [dbbc1e78] [c01cbcb4] cleanup_mnt+0x6c/0xe4
[ 46.588456] [dbbc1ea8] [c0054f50] task_work_run+0xa0/0xc0
[ 46.588645] [dbbc1ed8] [c000bc44] do_notify_resume+0x160/0x2c8
[ 46.588857] [dbbc1f38] [c0014800] do_user_signal+0x2c/0x34
[ 46.589052] --- interrupt: c00 at 0x7593d4
LR = 0x7593b8
[ 46.589252] Instruction dump:
[ 46.589340] 4bffade1 7c7f1b78 4bffadbd 81230000 71290200 40a200f8 813f0000
552987ff
[ 46.589644] 4082000c 813f0004 552907fe 69290001 <0f090000> 7fe3fb78 4bffadcd
7c641b78
[ 46.589961] ---[ end trace 0164244520bfd23a ]---
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-15 16:45 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #27 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Can you post the changes you did ?
Did you replace the two kzalloc() by get_zeroed_page() as suggested ?
If so, it looks like you missed one kfree() (in free_bitmap()) to be replaced
by free_page().
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: [PATCH 1/3] powerpc/xmon: Check for HV mode when dumping XIVE info from OPAL
From: Cédric Le Goater @ 2019-08-15 16:44 UTC (permalink / raw)
To: Jordan Niethe, Michael Ellerman
Cc: Paul Mackerras, linuxppc-dev, Nicholas Piggin
In-Reply-To: <294237fc-13eb-a0eb-3c28-db4141140e8d@kaod.org>
On 15/08/2019 10:15, Cédric Le Goater wrote:
> On 15/08/2019 09:30, Jordan Niethe wrote:
>> On Wed, 2019-08-14 at 17:47 +0200, Cédric Le Goater wrote:
>>> Currently, the xmon 'dx' command calls OPAL to dump the XIVE state in
>>> the OPAL logs and also outputs some of the fields of the internal
>>> XIVE
>>> structures in Linux. The OPAL calls can only be done on baremetal
>>> (PowerNV) and they crash a pseries machine. Fix by checking the
>>> hypervisor feature of the CPU.
>>>
>>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>>> ---
>>> arch/powerpc/xmon/xmon.c | 17 ++++++++++-------
>>> 1 file changed, 10 insertions(+), 7 deletions(-)
>>>
>>> diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
>>> index 14e56c25879f..25d4adccf750 100644
>>> --- a/arch/powerpc/xmon/xmon.c
>>> +++ b/arch/powerpc/xmon/xmon.c
>>> @@ -2534,13 +2534,16 @@ static void dump_pacas(void)
>>> static void dump_one_xive(int cpu)
>>> {
>>> unsigned int hwid = get_hard_smp_processor_id(cpu);
>>> -
>>> - opal_xive_dump(XIVE_DUMP_TM_HYP, hwid);
>>> - opal_xive_dump(XIVE_DUMP_TM_POOL, hwid);
>>> - opal_xive_dump(XIVE_DUMP_TM_OS, hwid);
>>> - opal_xive_dump(XIVE_DUMP_TM_USER, hwid);
>>> - opal_xive_dump(XIVE_DUMP_VP, hwid);
>>> - opal_xive_dump(XIVE_DUMP_EMU_STATE, hwid);
>>> + bool hv = cpu_has_feature(CPU_FTR_HVMODE);
>>> +
>>> + if (hv) {
>>> + opal_xive_dump(XIVE_DUMP_TM_HYP, hwid);
>>> + opal_xive_dump(XIVE_DUMP_TM_POOL, hwid);
>>> + opal_xive_dump(XIVE_DUMP_TM_OS, hwid);
>>> + opal_xive_dump(XIVE_DUMP_TM_USER, hwid);
>>> + opal_xive_dump(XIVE_DUMP_VP, hwid);
>>> + opal_xive_dump(XIVE_DUMP_EMU_STATE, hwid);
>>> + }
>>>
>>> if (setjmp(bus_error_jmp) != 0) {
>>> catch_memory_errors = 0;
>> dump_one_xive() / other xive functions are guarded by #ifdef
>> CONFIG_PPC_POWERNV in xmon.c aren't they? With this series would it be
>> that these guards can be removed?
>
> One could compile without CONFIG_PPC_POWERNV but we would still want
> these commands to be available for pseries. I missed that.
The changes below should be enough to activate support for the xive
commands on pseries and powernv. The patch can come as a follow up.
Cheers,
C.
--- linux.git.orig/arch/powerpc/xmon/xmon.c
+++ linux.git/arch/powerpc/xmon/xmon.c
@@ -238,7 +238,7 @@ Commands:\n\
dt dump the tracing buffers (uses printk)\n\
dtc dump the tracing buffers for current CPU (uses printk)\n\
"
-#ifdef CONFIG_PPC_POWERNV
+#ifdef CONFIG_PPC_BOOK3S_64
" dx# dump xive on CPU #\n\
dxi# dump xive irq state #\n\
dxa dump xive on all CPUs\n"
@@ -2530,7 +2530,7 @@ static void dump_pacas(void)
}
#endif
-#ifdef CONFIG_PPC_POWERNV
+#ifdef CONFIG_PPC_BOOK3S_64
static void dump_one_xive(int cpu)
{
unsigned int hwid = get_hard_smp_processor_id(cpu);
@@ -2632,7 +2632,7 @@ static void dump_xives(void)
else
dump_one_xive(xmon_owner);
}
-#endif /* CONFIG_PPC_POWERNV */
+#endif /* CONFIG_PPC_BOOK3S_64 */
static void dump_by_size(unsigned long addr, long count, int size)
{
@@ -2682,7 +2682,7 @@ dump(void)
return;
}
#endif
-#ifdef CONFIG_PPC_POWERNV
+#ifdef CONFIG_PPC_BOOK3S_64
if (c == 'x') {
xmon_start_pagination();
dump_xives();
^ permalink raw reply
* 5.2.7 kernel doesn't boot on G5
From: Mathieu Malaterre @ 2019-08-15 17:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: marillat
In-Reply-To: <87mugdtf08.fsf@christian.marillat.net>
Does that ring a bell to anyone here ? Thanks
---------- Forwarded message ---------
To: <debian-powerpc@lists.debian.org>
Hi,
No log only a photo :
https://www.deb-multimedia.org/tests/20190812_143628.jpg
Christian
^ permalink raw reply
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-15 17:07 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #28 from Erhard F. (erhard_f@mailbox.org) ---
On Thu, 15 Aug 2019 16:45:11 +0000
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #27 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> Can you post the changes you did ?
>
> Did you replace the two kzalloc() by get_zeroed_page() as suggested ?
> If so, it looks like you missed one kfree() (in free_bitmap()) to be replaced
> by free_page().
Ah yes, I added the (unsigned long) part but forgot to replace kfree() with
free_page(). Now looks like this:
diff --git a/fs/btrfs/free-space-cache.c b/fs/btrfs/free-space-cache.c
index 062be9dde4c6..c3eed8c3d3fe 100644
--- a/fs/btrfs/free-space-cache.c
+++ b/fs/btrfs/free-space-cache.c
@@ -764,7 +764,7 @@ static int __load_free_space_cache(struct btrfs_root *root,
struct inode *inode,
} else {
ASSERT(num_bitmaps);
num_bitmaps--;
- e->bitmap = kzalloc(PAGE_SIZE, GFP_NOFS);
+ e->bitmap = (void *)get_zeroed_page(GFP_NOFS);
if (!e->bitmap) {
kmem_cache_free(
btrfs_free_space_cachep, e);
@@ -1881,7 +1881,7 @@ static void free_bitmap(struct btrfs_free_space_ctl *ctl,
struct btrfs_free_space *bitmap_info)
{
unlink_free_space(ctl, bitmap_info);
- kfree(bitmap_info->bitmap);
+ free_page((unsigned long)bitmap_info->bitmap);
kmem_cache_free(btrfs_free_space_cachep, bitmap_info);
ctl->total_bitmaps--;
ctl->op->recalc_thresholds(ctl);
@@ -2135,7 +2135,7 @@ static int insert_into_bitmap(struct btrfs_free_space_ctl
*ctl,
}
/* allocate the bitmap */
- info->bitmap = kzalloc(PAGE_SIZE, GFP_NOFS);
+ info->bitmap = (void *)get_zeroed_page(GFP_NOFS);
spin_lock(&ctl->tree_lock);
if (!info->bitmap) {
ret = -ENOMEM;
@@ -2146,7 +2146,7 @@ static int insert_into_bitmap(struct btrfs_free_space_ctl
*ctl,
out:
if (info) {
- kfree(info->bitmap);
+ free_page((unsigned long)info->bitmap);
kmem_cache_free(btrfs_free_space_cachep, info);
}
@@ -2802,7 +2802,7 @@ u64 btrfs_alloc_from_cluster(struct
btrfs_block_group_cache *block_group,
if (entry->bytes == 0) {
ctl->free_extents--;
if (entry->bitmap) {
- kfree(entry->bitmap);
+ free_page((unsigned long)entry->bitmap);
ctl->total_bitmaps--;
ctl->op->recalc_thresholds(ctl);
}
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply related
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-15 17:11 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #29 from Christophe Leroy (christophe.leroy@c-s.fr) ---
Looks good. Does it work better ?
--
You are receiving this mail because:
You are on the CC list for the bug.
^ permalink raw reply
* Re: 5.2.7 kernel doesn't boot on G5
From: christophe leroy @ 2019-08-15 17:29 UTC (permalink / raw)
To: Mathieu Malaterre, linuxppc-dev; +Cc: marillat
In-Reply-To: <CA+7wUsw5eTdwJG3UytWr9CajVhpUkyOGufmvUvqQJoEWq4nWhQ@mail.gmail.com>
Le 15/08/2019 à 19:05, Mathieu Malaterre a écrit :
> Does that ring a bell to anyone here ? Thanks
Apparently that's 5.2.0, not 5.2.7
Christophe
>
> ---------- Forwarded message ---------
> To: <debian-powerpc@lists.debian.org>
>
>
> Hi,
>
> No log only a photo :
>
> https://www.deb-multimedia.org/tests/20190812_143628.jpg
>
> Christian
>
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: 5.2.7 kernel doesn't boot on G5
From: christophe leroy @ 2019-08-15 17:50 UTC (permalink / raw)
To: Christian Marillat; +Cc: Mathieu Malaterre, linuxppc-dev
In-Reply-To: <87a7cal3pd.fsf@christian.marillat.net>
Le 15/08/2019 à 19:48, Christian Marillat a écrit :
> On 15 août 2019 19:29, christophe leroy <christophe.leroy@c-s.fr> wrote:
>
>> Le 15/08/2019 à 19:05, Mathieu Malaterre a écrit :
>>> Does that ring a bell to anyone here ? Thanks
>>
>> Apparently that's 5.2.0, not 5.2.7
>
> Yes, 5.2.7 is the Debian package version. Sorry for the mistake.
>
Can you test with latest stable version, ie 5.2.8 ?
Christophe
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
^ permalink raw reply
* Re: [PATCH 0/6] drm+dma: cache support for arm, etc
From: Christoph Hellwig @ 2019-08-15 17:53 UTC (permalink / raw)
To: Rob Clark
Cc: Kate Stewart, Masayoshi Mizuma, Maciej W. Rozycki, Eric Biggers,
Catalin Marinas, Imre Deak, dri-devel, Chris Wilson,
Masahiro Yamada, Benjamin Gaignard, Mauro Carvalho Chehab,
Will Deacon, Christoph Hellwig, Emil Velikov, Deepak Sharma,
Paul Burton, Mike Rapoport, Geert Uytterhoeven,
moderated list:ARM64 PORT (AARCH64 ARCHITECTURE), Daniel Vetter,
open list:MIPS, Linus Walleij, Robin Murphy,
open list:DRM DRIVER FOR MSM ADRENO GPU, Joerg Roedel,
Arnd Bergmann, Anshuman Khandual, Hauke Mehrtens,
Jesper Dangaard Brouer, Wolfram Sang (Renesas),
open list:LINUX FOR POWERPC (32-BIT AND 64-BIT), Alexios Zavras,
Russell King, Doug Anderson, Thomas Gleixner, Sean Paul,
Allison Randal, Enrico Weigelt, Ard Biesheuvel,
Greg Kroah-Hartman, open list, Rob Clark, Souptick Joarder,
Andrew Morton, open list:DRM DRIVER FOR MSM ADRENO GPU,
christian.koenig
In-Reply-To: <CAJs_Fx4bS64s7+xQqsead3N80ZQpofqegFQu+tT=b3wcGd_2pA@mail.gmail.com>
On Thu, Aug 15, 2019 at 06:54:39AM -0700, Rob Clark wrote:
> On Wed, Aug 14, 2019 at 11:51 PM Christoph Hellwig <hch@lst.de> wrote:
> >
> > As said before I don't think these low-level helpers are the
> > right API to export, but even if they did you'd just cover a tiny
> > subset of the architectures.
>
> Are you thinking instead something like:
>
> void dma_sync_sg_for_{cpu,device}(struct device *dev, struct scatterlist *sgl,
> int nents, enum dma_data_direction dir)
> {
> for_each_sg(sgl, sg, nents, i) {
> arch_sync_dma_for_..(dev, sg_phys(sg), sg->length, dir);
> }
> }
> EXPORT_SYMBOL_GPL(dma_sync_sg_for_..)
>
> or did you have something else in mind?
No. We really need an interface thay says please give me uncached
memory (for some definition of uncached that includes that grapics
drivers call write combine), and then let the architecture do the right
thing. Basically dma_alloc_coherent with DMA_ATTR_NO_KERNEL_MAPPING
is superficially close to what you want, except that the way the drm
drivers work you can't actually use it.
The reason for that is if we can we really need to not create another
uncachable alias, but instead change the page attributes in place.
On x86 we can and must do that for example, and based on the
conversation with Will arm64 could do that fairly easily. arm32 can
right now only do that for CMA, though.
The big question is what API do we want. I had a pretty similar
discussion with Christian on doing such an allocation for amdgpu,
where the device normally is cache coherent, but they actually want
to turn it into non-coherent by using PCIe unsnooped transactions.
Here is my high level plan, which still has a few lose end:
(1) provide a new API:
struct page *dma_alloc_pages(struct device *dev, unsigned nr_pages,
gfp_t gfp, unsigned long flags);
void dma_free_pages(struct device *dev, unsigned nr_pages,
unsigned long flags);
These give you back page backed memory that is guaranteed to be
addressable by the device (no swiotlb or similar). The memory can
then be mapped using dma_map*, including unmap and dma_sync to
bounce ownership around. This is the replacement for the current
dma_alloc_attrs with DMA_ATTR_NON_CONSISTENT API, that is rather
badly defined.
(2) Add support for DMA_ATTR_NO_KERNEL_MAPPING to this new API instead
of dma_alloc_attrs. The initial difference with that flag is just
that we allow highmem, but in the future we could also unmap this
memory from the kernel linear mapping entirely on architectures
where we can easily do that.
(3) Add a dma_pages_map/dma_pages_unmap or similar API that allows you
to get a kernel mapping for parts or all of a
DMA_ATTR_NO_KERNEL_MAPPING allocation. This is to replace things
like your open-coded vmap in msm (or similarly elsewhere in dma-buf
providers).
(4) Add support for a DMA_ATTR_UNCACHABLE flags (or similar) to the new
API, that maps the pages as uncachable iff they have a kernel
mapping, including invalidating the caches at time of this page
attribute change (or creation of a new mapping). This API will fail
if the architecture does not allow in-place remapping. Note that for
arm32 we could always dip into the CMA pool if one is present to not
fail. We'll also need some helper to map from the DMA_ATTR_* flags
to a pgprot for mapping the page to userspace. There is also a few
other weird bits here, e.g. on architectures like mips that use an
uncached segment we'll have to fail use with the plain
DMA_ATTR_UNCACHABLE flag, but it could be supported with
DMA_ATTR_UNCACHABLE | DMA_ATTR_NO_KERNEL_MAPPING.
I was hoping to get most of this done for this merge window, but I'm
probably lucky if I get at least parts done. Too much distraction.
> Hmm, not entirely sure why.. you should be on the cc list for each
> individual patch.
They finally made it, although even with the delay they only ended up
in the spam mailbox. I still can't see them on the various mailing
lists.
^ permalink raw reply
* [Bug 204371] BUG kmalloc-4k (Tainted: G W ): Object padding overwritten
From: bugzilla-daemon @ 2019-08-15 17:56 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-204371-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=204371
--- Comment #30 from Erhard F. (erhard_f@mailbox.org) ---
On Thu, 15 Aug 2019 17:11:36 +0000
bugzilla-daemon@bugzilla.kernel.org wrote:
> https://bugzilla.kernel.org/show_bug.cgi?id=204371
>
> --- Comment #29 from Christophe Leroy (christophe.leroy@c-s.fr) ---
> Looks good. Does it work better ?
Had some trouble getting the dmesg. With these modifications the btrfs module
hiccups as soon as it gets loaded, during btrfs selftests:
[...]
[ 167.258266] Btrfs loaded, crc32c=crc32c-generic, debug=on
[ 167.259388] BTRFS: selftest: sectorsize: 4096 nodesize: 4096
[ 167.259602] BTRFS: selftest: running btrfs free space cache tests
[ 167.259943] BTRFS: selftest: running extent only tests
[ 167.260201] BTRFS: selftest: running bitmap only tests
[ 167.260501] BTRFS: selftest: running bitmap and extent tests
[ 167.260963] WARNING: CPU: 0 PID: 266 at mm/slub.c:1846
___slab_alloc.constprop.75+0x2ac/0x380
[ 167.261277] Modules linked in: btrfs(+) auth_rpcgss nfsv4 dns_resolver nfs
lockd grace sunrpc input_leds joydev b43legacy led_class hid_generic mac80211
usbhid hid snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa cfg80211 rfkill
libarc4 evdev ohci_pci xor zstd_decompress zstd_compress zlib_deflate radeon
raid6_pq zlib_inflate therm_windtunnel ehci_pci ohci_hcd hwmon i2c_algo_bit
ehci_hcd backlight drm_kms_helper sungem firewire_ohci syscopyarea sungem_phy
sysfillrect sr_mod firewire_core sysimgblt fb_sys_fops cdrom crc_itu_t
snd_aoa_i2sbus snd_aoa_soundbus ttm snd_pcm usbcore snd_timer drm usb_common
snd soundcore ssb uninorth_agp drm_panel_orientation_quirks agpgart lzo
lzo_compress lzo_decompress zram zsmalloc
[ 167.263795] CPU: 0 PID: 266 Comm: modprobe Tainted: G W
5.3.0-rc4+ #3
[ 167.264074] NIP: c0196ddc LR: c0196dd4 CTR: c019711c
[ 167.264236] REGS: ecde9a70 TRAP: 0700 Tainted: G W
(5.3.0-rc4+)
[ 167.264488] MSR: 00021032 <ME,IR,DR,RI> CR: 28224222 XER: 00000000
[ 167.264709]
GPR00: c0196dd4 ecde9b28 eb353380 00000000 ef3d3600 0003000e
00000000 0007000f
GPR08: 00000001 00000001 ef42488c ecde9b28 48244222 00a9eff4
00a64e74 00000004
GPR16: 00000000 ee800810 00000000 c0800000 00000000 ee800824
f203de58 c07fea34
GPR24: 00210d00 ef424888 00000d40 ee800800 ef3d3600 ee8032e0
00000000 eedb1af8
[ 167.265857] NIP [c0196ddc] ___slab_alloc.constprop.75+0x2ac/0x380
[ 167.266052] LR [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
[ 167.266248] Call Trace:
[ 167.266308] [ecde9b28] [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
(unreliable)
[ 167.266567] [ecde9bb8] [c0196ef0] __slab_alloc.constprop.74+0x40/0x6c
[ 167.266776] [ecde9be8] [c0197198] kmem_cache_alloc_trace+0x7c/0x1a0
[ 167.267321] [ecde9c28] [f203de58] test_add_free_space_entry+0xf0/0x214
[btrfs]
[ 167.267672] [ecde9c78] [f207e238] btrfs_test_free_space_cache+0x918/0x1308
[btrfs]
[ 167.268012] [ecde9cd8] [f207ad3c] btrfs_run_sanity_tests+0x8c/0x144 [btrfs]
[ 167.268327] [ecde9d08] [f1678cd0] init_btrfs_fs+0xd4/0x12c [btrfs]
[ 167.268536] [ecde9d28] [c00052cc] do_one_initcall+0x54/0x288
[ 167.282204] [ecde9d98] [c00bebf8] do_init_module+0x60/0x1dc
[ 167.295710] [ecde9dc8] [c00c0ad4] load_module+0x1ca4/0x1e18
[ 167.308943] [ecde9ea8] [c00c0df4] sys_finit_module+0x98/0xb8
[ 167.322086] [ecde9f38] [c0014274] ret_from_syscall+0x0/0x34
[ 167.335151] --- interrupt: c01 at 0x8ed2c4
LR = 0xa757c4
[ 167.361356] Instruction dump:
[ 167.374279] 7e048378 7f83e378 60e70001 90e10030 4bffda0d 2f830000 41beff20
7f84e378
[ 167.387497] 7f63db78 4bffdd35 7e090034 5529d97e <0f090000> 2f900000 41beff00
7e527a14
[ 167.400820] irq event stamp: 0
[ 167.414008] hardirqs last enabled at (0): [<00000000>] 0x0
[ 167.427196] hardirqs last disabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 167.440311] softirqs last enabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 167.453198] softirqs last disabled at (0): [<00000000>] 0x0
[ 167.465906] ---[ end trace 74450a6aa18e595d ]---
[ 167.481091] BTRFS: selftest: running space stealing from bitmap to extent
tests
[ 167.496220] BTRFS: selftest: running extent buffer operation tests
[ 167.510905] BTRFS: selftest: running btrfs_split_item tests
[ 167.525961] BTRFS: selftest: running extent I/O tests
[ 167.540569] BTRFS: selftest: running find delalloc tests
[ 168.104731] BTRFS: selftest: running find_first_clear_extent_bit test
[ 168.119119] BTRFS: selftest: running extent buffer bitmap tests
[ 168.463591] BTRFS: selftest: running inode tests
[ 168.477316] BTRFS: selftest: running btrfs_get_extent tests
[ 168.491784] BTRFS: selftest: running hole first btrfs_get_extent test
[ 168.506234] BTRFS: selftest: running outstanding_extents tests
[ 168.520925] BTRFS: selftest: running qgroup tests
[ 168.535039] BTRFS: selftest: running qgroup add/remove tests
[ 168.549344] BTRFS: selftest: running qgroup multiple refs test
[ 168.563713] BTRFS: selftest: running free space tree tests
[ 168.706099] BTRFS: selftest: sectorsize: 4096 nodesize: 8192
[ 168.718674] BTRFS: selftest: running btrfs free space cache tests
[ 168.731349] BTRFS: selftest: running extent only tests
[ 168.744380] BTRFS: selftest: running bitmap only tests
[ 168.757505] BTRFS: selftest: running bitmap and extent tests
[ 168.770615] WARNING: CPU: 0 PID: 266 at mm/slub.c:1846
___slab_alloc.constprop.75+0x2ac/0x380
[ 168.783738] Modules linked in: btrfs(+) auth_rpcgss nfsv4 dns_resolver nfs
lockd grace sunrpc input_leds joydev b43legacy led_class hid_generic mac80211
usbhid hid snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa cfg80211 rfkill
libarc4 evdev ohci_pci xor zstd_decompress zstd_compress zlib_deflate radeon
raid6_pq zlib_inflate therm_windtunnel ehci_pci ohci_hcd hwmon i2c_algo_bit
ehci_hcd backlight drm_kms_helper sungem firewire_ohci syscopyarea sungem_phy
sysfillrect sr_mod firewire_core sysimgblt fb_sys_fops cdrom crc_itu_t
snd_aoa_i2sbus snd_aoa_soundbus ttm snd_pcm usbcore snd_timer drm usb_common
snd soundcore ssb uninorth_agp drm_panel_orientation_quirks agpgart lzo
lzo_compress lzo_decompress zram zsmalloc
[ 168.828086] CPU: 0 PID: 266 Comm: modprobe Tainted: G W
5.3.0-rc4+ #3
[ 168.843577] NIP: c0196ddc LR: c0196dd4 CTR: c019711c
[ 168.859054] REGS: ecde9a70 TRAP: 0700 Tainted: G W
(5.3.0-rc4+)
[ 168.874772] MSR: 00021032 <ME,IR,DR,RI> CR: 28224242 XER: 00000000
[ 168.890402]
GPR00: c0196dd4 ecde9b28 eb353380 00000000 ef3d3960 0001000e
00000000 0007000f
GPR08: 00000001 00000001 ef432578 ecde9b28 48244242 00a9eff4
00a64e74 00000006
GPR16: 00000000 ee800810 00000000 c0800000 00000000 ee800824
f203de58 c07fea34
GPR24: 00210d00 ef432574 00000d40 ee800800 ef3d3960 ee8032e0
00000000 eedb1af8
[ 168.960711] NIP [c0196ddc] ___slab_alloc.constprop.75+0x2ac/0x380
[ 168.974148] LR [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
[ 168.987536] Call Trace:
[ 169.000772] [ecde9b28] [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
(unreliable)
[ 169.014236] [ecde9bb8] [c0196ef0] __slab_alloc.constprop.74+0x40/0x6c
[ 169.027634] [ecde9be8] [c0197198] kmem_cache_alloc_trace+0x7c/0x1a0
[ 169.041326] [ecde9c28] [f203de58] test_add_free_space_entry+0xf0/0x214
[btrfs]
[ 169.054891] [ecde9c78] [f207dee4] btrfs_test_free_space_cache+0x5c4/0x1308
[btrfs]
[ 169.068328] [ecde9cd8] [f207ad3c] btrfs_run_sanity_tests+0x8c/0x144 [btrfs]
[ 169.081776] [ecde9d08] [f1678cd0] init_btrfs_fs+0xd4/0x12c [btrfs]
[ 169.095039] [ecde9d28] [c00052cc] do_one_initcall+0x54/0x288
[ 169.108161] [ecde9d98] [c00bebf8] do_init_module+0x60/0x1dc
[ 169.121179] [ecde9dc8] [c00c0ad4] load_module+0x1ca4/0x1e18
[ 169.134179] [ecde9ea8] [c00c0df4] sys_finit_module+0x98/0xb8
[ 169.147133] [ecde9f38] [c0014274] ret_from_syscall+0x0/0x34
[ 169.159933] --- interrupt: c01 at 0x8ed2c4
LR = 0xa757c4
[ 169.185350] Instruction dump:
[ 169.197936] 7e048378 7f83e378 60e70001 90e10030 4bffda0d 2f830000 41beff20
7f84e378
[ 169.210814] 7f63db78 4bffdd35 7e090034 5529d97e <0f090000> 2f900000 41beff00
7e527a14
[ 169.223824] irq event stamp: 0
[ 169.236770] hardirqs last enabled at (0): [<00000000>] 0x0
[ 169.249906] hardirqs last disabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 169.263077] softirqs last enabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 169.276147] softirqs last disabled at (0): [<00000000>] 0x0
[ 169.289173] ---[ end trace 74450a6aa18e595e ]---
[ 169.305352] WARNING: CPU: 0 PID: 266 at mm/slub.c:1846
___slab_alloc.constprop.75+0x2ac/0x380
[ 169.318278] Modules linked in: btrfs(+) auth_rpcgss nfsv4 dns_resolver nfs
lockd grace sunrpc input_leds joydev b43legacy led_class hid_generic mac80211
usbhid hid snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa cfg80211 rfkill
libarc4 evdev ohci_pci xor zstd_decompress zstd_compress zlib_deflate radeon
raid6_pq zlib_inflate therm_windtunnel ehci_pci ohci_hcd hwmon i2c_algo_bit
ehci_hcd backlight drm_kms_helper sungem firewire_ohci syscopyarea sungem_phy
sysfillrect sr_mod firewire_core sysimgblt fb_sys_fops cdrom crc_itu_t
snd_aoa_i2sbus snd_aoa_soundbus ttm snd_pcm usbcore snd_timer drm usb_common
snd soundcore ssb uninorth_agp drm_panel_orientation_quirks agpgart lzo
lzo_compress lzo_decompress zram zsmalloc
[ 169.363085] CPU: 0 PID: 266 Comm: modprobe Tainted: G W
5.3.0-rc4+ #3
[ 169.378753] NIP: c0196ddc LR: c0196dd4 CTR: c019711c
[ 169.394382] REGS: ecde9a70 TRAP: 0700 Tainted: G W
(5.3.0-rc4+)
[ 169.410156] MSR: 00021032 <ME,IR,DR,RI> CR: 28224222 XER: 00000000
[ 169.425900]
GPR00: c0196dd4 ecde9b28 eb353380 00000000 ef3d3ba0 0001000e
00000000 0007000f
GPR08: 00000001 00000001 ef188f3c ecde9b28 48244222 00a9eff4
00a64e74 00000006
GPR16: 00000000 ee800810 00000000 c0800000 00000000 ee800824
f203de58 c07fea34
GPR24: 00210d00 ef188f38 00000d40 ee800800 ef3d3ba0 ee8032e0
00000000 eedb1af8
[ 169.506070] NIP [c0196ddc] ___slab_alloc.constprop.75+0x2ac/0x380
[ 169.522457] LR [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
[ 169.538919] Call Trace:
[ 169.555301] [ecde9b28] [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
(unreliable)
[ 169.572079] [ecde9bb8] [c0196ef0] __slab_alloc.constprop.74+0x40/0x6c
[ 169.588847] [ecde9be8] [c0197198] kmem_cache_alloc_trace+0x7c/0x1a0
[ 169.605861] [ecde9c28] [f203de58] test_add_free_space_entry+0xf0/0x214
[btrfs]
[ 169.623013] [ecde9c78] [f207e08c] btrfs_test_free_space_cache+0x76c/0x1308
[btrfs]
[ 169.640288] [ecde9cd8] [f207ad3c] btrfs_run_sanity_tests+0x8c/0x144 [btrfs]
[ 169.657589] [ecde9d08] [f1678cd0] init_btrfs_fs+0xd4/0x12c [btrfs]
[ 169.674812] [ecde9d28] [c00052cc] do_one_initcall+0x54/0x288
[ 169.692019] [ecde9d98] [c00bebf8] do_init_module+0x60/0x1dc
[ 169.709242] [ecde9dc8] [c00c0ad4] load_module+0x1ca4/0x1e18
[ 169.726533] [ecde9ea8] [c00c0df4] sys_finit_module+0x98/0xb8
[ 169.743904] [ecde9f38] [c0014274] ret_from_syscall+0x0/0x34
[ 169.761110] --- interrupt: c01 at 0x8ed2c4
LR = 0xa757c4
[ 169.793422] Instruction dump:
[ 169.808483] 7e048378 7f83e378 60e70001 90e10030 4bffda0d 2f830000 41beff20
7f84e378
[ 169.823241] 7f63db78 4bffdd35 7e090034 5529d97e <0f090000> 2f900000 41beff00
7e527a14
[ 169.838004] irq event stamp: 0
[ 169.852643] hardirqs last enabled at (0): [<00000000>] 0x0
[ 169.867316] hardirqs last disabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 169.882061] softirqs last enabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 169.896525] softirqs last disabled at (0): [<00000000>] 0x0
[ 169.910840] ---[ end trace 74450a6aa18e595f ]---
[ 169.928722] BTRFS: selftest: running space stealing from bitmap to extent
tests
[ 169.943052] WARNING: CPU: 1 PID: 266 at mm/slub.c:1846
___slab_alloc.constprop.75+0x2ac/0x380
[ 169.957190] Modules linked in: btrfs(+) auth_rpcgss nfsv4 dns_resolver nfs
lockd grace sunrpc input_leds joydev b43legacy led_class hid_generic mac80211
usbhid hid snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa cfg80211 rfkill
libarc4 evdev ohci_pci xor zstd_decompress zstd_compress zlib_deflate radeon
raid6_pq zlib_inflate therm_windtunnel ehci_pci ohci_hcd hwmon i2c_algo_bit
ehci_hcd backlight drm_kms_helper sungem firewire_ohci syscopyarea sungem_phy
sysfillrect sr_mod firewire_core sysimgblt fb_sys_fops cdrom crc_itu_t
snd_aoa_i2sbus snd_aoa_soundbus ttm snd_pcm usbcore snd_timer drm usb_common
snd soundcore ssb uninorth_agp drm_panel_orientation_quirks agpgart lzo
lzo_compress lzo_decompress zram zsmalloc
[ 170.003934] CPU: 1 PID: 266 Comm: modprobe Tainted: G W
5.3.0-rc4+ #3
[ 170.019968] NIP: c0196ddc LR: c0196dd4 CTR: c019711c
[ 170.035984] REGS: ecde9a70 TRAP: 0700 Tainted: G W
(5.3.0-rc4+)
[ 170.052020] MSR: 00021032 <ME,IR,DR,RI> CR: 28224242 XER: 00000000
[ 170.068087]
GPR00: c0196dd4 ecde9b28 eb353380 00000000 ef3d3cc0 0004000e
00000000 0007000f
GPR08: 00000001 00000001 ef188eac ecde9b28 48244242 00a9eff4
00a64e74 00000003
GPR16: 00000000 ee800810 00000000 c0800000 00000000 ee800824
f203de58 c07fea34
GPR24: 00210d00 ef188ea8 00000d40 ee800800 ef3d3cc0 ee8032e0
00000000 eedceaf8
[ 170.149103] NIP [c0196ddc] ___slab_alloc.constprop.75+0x2ac/0x380
[ 170.165571] LR [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
[ 170.182082] Call Trace:
[ 170.198482] [ecde9b28] [c0196dd4] ___slab_alloc.constprop.75+0x2a4/0x380
(unreliable)
[ 170.215245] [ecde9bb8] [c0196ef0] __slab_alloc.constprop.74+0x40/0x6c
[ 170.232091] [ecde9be8] [c0197198] kmem_cache_alloc_trace+0x7c/0x1a0
[ 170.249175] [ecde9c28] [f203de58] test_add_free_space_entry+0xf0/0x214
[btrfs]
[ 170.266059] [ecde9c78] [f207e44c] btrfs_test_free_space_cache+0xb2c/0x1308
[btrfs]
[ 170.282918] [ecde9cd8] [f207ad3c] btrfs_run_sanity_tests+0x8c/0x144 [btrfs]
[ 170.299700] [ecde9d08] [f1678cd0] init_btrfs_fs+0xd4/0x12c [btrfs]
[ 170.316388] [ecde9d28] [c00052cc] do_one_initcall+0x54/0x288
[ 170.333159] [ecde9d98] [c00bebf8] do_init_module+0x60/0x1dc
[ 170.349916] [ecde9dc8] [c00c0ad4] load_module+0x1ca4/0x1e18
[ 170.366610] [ecde9ea8] [c00c0df4] sys_finit_module+0x98/0xb8
[ 170.383179] [ecde9f38] [c0014274] ret_from_syscall+0x0/0x34
[ 170.399101] --- interrupt: c01 at 0x8ed2c4
LR = 0xa757c4
[ 170.428916] Instruction dump:
[ 170.442826] 7e048378 7f83e378 60e70001 90e10030 4bffda0d 2f830000 41beff20
7f84e378
[ 170.456986] 7f63db78 4bffdd35 7e090034 5529d97e <0f090000> 2f900000 41beff00
7e527a14
[ 170.471190] irq event stamp: 0
[ 170.485188] hardirqs last enabled at (0): [<00000000>] 0x0
[ 170.499283] hardirqs last disabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 170.513322] softirqs last enabled at (0): [<c0032f0c>]
copy_process+0x474/0x1368
[ 170.527207] softirqs last disabled at (0): [<00000000>] 0x0
[ 170.540920] ---[ end trace 74450a6aa18e5960 ]---
[ 170.558438] ------------[ cut here ]------------
[ 170.572459] kernel BUG at mm/slub.c:3952!
[ 170.586496] Oops: Exception in kernel mode, sig: 5 [#1]
[ 170.600564] BE PAGE_SIZE=4K MMU=Hash SMP NR_CPUS=2 PowerMac
[ 170.614556] Modules linked in: btrfs(+) auth_rpcgss nfsv4 dns_resolver nfs
lockd grace sunrpc input_leds joydev b43legacy led_class hid_generic mac80211
usbhid hid snd_aoa_codec_tas snd_aoa_fabric_layout snd_aoa cfg80211 rfkill
libarc4 evdev ohci_pci xor zstd_decompress zstd_compress zlib_deflate radeon
raid6_pq zlib_inflate therm_windtunnel ehci_pci ohci_hcd hwmon i2c_algo_bit
ehci_hcd backlight drm_kms_helper sungem firewire_ohci syscopyarea sungem_phy
sysfillrect sr_mod firewire_core sysimgblt fb_sys_fops cdrom crc_itu_t
snd_aoa_i2sbus snd_aoa_soundbus ttm snd_pcm usbcore snd_timer drm usb_common
snd soundcore ssb uninorth_agp drm_panel_orientation_quirks agpgart lzo
lzo_compress lzo_decompress zram zsmalloc
[ 170.662386] CPU: 0 PID: 266 Comm: modprobe Tainted: G W
5.3.0-rc4+ #3
[ 170.678893] NIP: c0198228 LR: c0198204 CTR: c01981a4
[ 170.695309] REGS: ecde9b10 TRAP: 0700 Tainted: G W
(5.3.0-rc4+)
[ 170.711791] MSR: 00029032 <EE,ME,IR,DR,RI> CR: 28242424 XER: 00000000
[ 170.728343]
GPR00: f207aa60 ecde9bc8 eb353380 ef3d3a80 c07fe5f8 c01600dc
00003c40 00000000
GPR08: 00001032 00000001 00000000 ecde9c18 c01981a4 00a9eff4
00a64e74 c0710cd4
GPR16: f16a1fac 000011ad 00000001 00000124 c00bbeac c0e7e55c
00000001 ea8ed15c
GPR24: ea8ed16c f207aa60 f209a370 f209a343 00002000 c07fe5f8
ea9a6458 ef3d3a80
[ 170.812601] NIP [c0198228] kfree+0x84/0x29c
[ 170.829631] LR [c0198204] kfree+0x60/0x29c
[ 170.846753] Call Trace:
[ 170.863878] [ecde9bc8] [f20d0000] test_error+0xd44/0xfffba69c [btrfs]
(unreliable)
[ 170.881178] [ecde9c18] [f207aa60] btrfs_free_dummy_fs_info+0x168/0x1e0
[btrfs]
[ 170.898408] [ecde9c78] [f207da3c] btrfs_test_free_space_cache+0x11c/0x1308
[btrfs]
[ 170.915026] [ecde9cd8] [f207ad3c] btrfs_run_sanity_tests+0x8c/0x144 [btrfs]
[ 170.931323] [ecde9d08] [f1678cd0] init_btrfs_fs+0xd4/0x12c [btrfs]
[ 170.948575] [ecde9d28] [c00052cc] do_one_initcall+0x54/0x288
[ 170.965784] [ecde9d98] [c00bebf8] do_init_module+0x60/0x1dc
[ 170.982897] [ecde9dc8] [c00c0ad4] load_module+0x1ca4/0x1e18
[ 170.999911] [ecde9ea8] [c00c0df4] sys_finit_module+0x98/0xb8
[ 171.016767] [ecde9f38] [c0014274] ret_from_syscall+0x0/0x34
[ 171.032967] --- interrupt: c01 at 0x8ed2c4
LR = 0xa757c4
[ 171.063206] Instruction dump:
[ 171.077290] 4bffade1 7c7f1b78 4bffadbd 81230000 71290200 40a200f8 813f0000
552987ff
[ 171.091622] 4082000c 813f0004 552907fe 69290001 <0f090000> 7fe3fb78 4bffadcd
7c641b78
[ 171.106020] ---[ end trace 74450a6aa18e5961 ]---
--
You are receiving this mail because:
You are on the CC list for the bug.
^ 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