Re: memcpy regression
Hi Michael Le 07/09/2015 03:14, Michael Ellerman a écrit : Hi Michal, Thanks for finding the problem. On Sun, 2015-09-06 at 23:01 +0200, Michal Sojka wrote: I found the problem. The compiler replaces an assignment with a call to memcpy. The following patch fixes the problem for me. However, I'm not sure whether this is the real solution. I guess the compiler is free to generate a call to memcpy wherever it wants so other compilers or other optimization levels may need fixes at other places. What do others think? I think you're right that it's not a good solution, the compiler could generate other calls to memcpy depending on various factors, and people will add new code that causes memcpy to get called and it will break your platform. Christophe, am I right that the problem here is that your new memcpy() doesn't work until later in boot when caches are enabled? That's right, memset() and memcpy() are for setting/copying data into cacheable RAM. They are using dczb instruction in order to avoid wasting time loading the cacheline with data that will be overwritten. memset_io() and memcpy_toio() are the functions to use when using not cacheable memory. The issue identified by Michal is in function setup_cpu_spec() which is called by identify_cpu(). identify_cpu() is called from early_init(). In the begining of early_init(), there is (code from Paul in 2005) /* First zero the BSS -- use memset_io, some platforms don't have * caches on yet */ memset_io((void __iomem *)PTRRELOC(&__bss_start), 0, __bss_stop - __bss_start); It shows that it is already expected that the cache is not active yet and standard memset() shall not be used yet. That's the same with memcpy(). I think GCC uses memcpy() in well known situations like initialising structures or copying structures. Shouldn't we just avoid this kind of actions in the very few early init functions ? Christophe ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc/mm: Disable hugepd for 64K page size.
After commit e2b3d202d1dba8f3546ed28224ce485bc50010be
("powerpc: Switch 16GB and 16MB explicit hugepages to a
different page table format"), we don't need to support
is_hugepd() for 64K page size.
Signed-off-by: Aneesh Kumar K.V
---
arch/powerpc/include/asm/page.h | 15 +++
arch/powerpc/mm/hugetlbpage.c | 19 +++
2 files changed, 34 insertions(+)
diff --git a/arch/powerpc/include/asm/page.h b/arch/powerpc/include/asm/page.h
index 71294a6e976e..d90247b017b3 100644
--- a/arch/powerpc/include/asm/page.h
+++ b/arch/powerpc/include/asm/page.h
@@ -362,6 +362,20 @@ typedef struct { signed long pd; } hugepd_t;
#ifdef CONFIG_HUGETLB_PAGE
#ifdef CONFIG_PPC_BOOK3S_64
+#ifdef CONFIG_PPC_64K_PAGES
+/*
+ * With 64k page size, we have hugepage ptes in the pgd and pmd entries. We
don't
+ * need to setup hugepage directory for them. Our pte and page directory format
+ * enable us to have this enabled. But to avoid errors when implementing new
+ * features disable hugepd for 64K. We enable a debug version here, So we catch
+ * wrong usage.
+ */
+#ifdef CONFIG_DEBUG_VM
+extern int hugepd_ok(hugepd_t hpd);
+#else
+#define hugepd_ok(x) (0)
+#endif
+#else
static inline int hugepd_ok(hugepd_t hpd)
{
/*
@@ -370,6 +384,7 @@ static inline int hugepd_ok(hugepd_t hpd)
*/
return (((hpd.pd & 0x3) == 0x0) && ((hpd.pd & HUGEPD_SHIFT_MASK) != 0));
}
+#endif
#else
static inline int hugepd_ok(hugepd_t hpd)
{
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index bb0bd7025cb8..8f4936e6a3db 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -89,6 +89,25 @@ int pgd_huge(pgd_t pgd)
*/
return ((pgd_val(pgd) & 0x3) != 0x0);
}
+
+#if defined(CONFIG_PPC_64K_PAGES) && defined(CONFIG_DEBUG_VM)
+/*
+ * This enables us to catch the wrong page directory format
+ * Moved here so that we can use WARN() in the call.
+ */
+int hugepd_ok(hugepd_t hpd)
+{
+ bool is_hugepd;
+
+ /*
+* We should not find this format in page directory, warn otherwise.
+*/
+ is_hugepd = (((hpd.pd & 0x3) == 0x0) && ((hpd.pd & HUGEPD_SHIFT_MASK)
!= 0));
+ WARN(is_hugepd, "Found wrong page directory format\n");
+ return 0;
+}
+#endif
+
#else
int pmd_huge(pmd_t pmd)
{
--
2.5.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] agp/uninorth: fix a memleak in create_gatt_table
On 6/19/15, Benjamin Herrenschmidt wrote:
> On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote:
>> On 6/12/15, Denis Kirjanov wrote:
>> > Fix the memory leak in create_gatt_table:
>> > we've lost a kfree on the exit path for the pages array allocated
>> > in uninorth_create_gatt_table
>> >
>> > Signed-off-by: Denis Kirjanov
>>
>> Hi Ben, Michael
>>
>> Will you take the patch through your trees or do I need to send it to
>> Dave Airlie?
>
> I haven't had a chance to review yet...
Ping...
>
> Ben.
>
>> Thanks
>> > ---
>> > drivers/char/agp/uninorth-agp.c | 16 ++--
>> > 1 file changed, 10 insertions(+), 6 deletions(-)
>> >
>> > diff --git a/drivers/char/agp/uninorth-agp.c
>> > b/drivers/char/agp/uninorth-agp.c
>> > index a56ee9b..0575544 100644
>> > --- a/drivers/char/agp/uninorth-agp.c
>> > +++ b/drivers/char/agp/uninorth-agp.c
>> > @@ -361,6 +361,10 @@ static int agp_uninorth_resume(struct pci_dev
>> > *pdev)
>> > }
>> > #endif /* CONFIG_PM */
>> >
>> > +static struct {
>> > + struct page **pages_arr;
>> > +} uninorth_priv;
>> > +
>> > static int uninorth_create_gatt_table(struct agp_bridge_data *bridge)
>> > {
>> >char *table;
>> > @@ -371,7 +375,6 @@ static int uninorth_create_gatt_table(struct
>> > agp_bridge_data *bridge)
>> >int i;
>> >void *temp;
>> >struct page *page;
>> > - struct page **pages;
>> >
>> >/* We can't handle 2 level gatt's */
>> >if (bridge->driver->size_type == LVL2_APER_SIZE)
>> > @@ -400,8 +403,8 @@ static int uninorth_create_gatt_table(struct
>> > agp_bridge_data *bridge)
>> >if (table == NULL)
>> >return -ENOMEM;
>> >
>> > - pages = kmalloc((1 << page_order) * sizeof(struct page*),
>> > GFP_KERNEL);
>> > - if (pages == NULL)
>> > + uninorth_priv.pages_arr = kmalloc((1 << page_order) * sizeof(struct
>> > page*), GFP_KERNEL);
>> > + if (uninorth_priv.pages_arr == NULL)
>> >goto enomem;
>> >
>> >table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);
>> > @@ -409,14 +412,14 @@ static int uninorth_create_gatt_table(struct
>> > agp_bridge_data *bridge)
>> >for (page = virt_to_page(table), i = 0; page <=
>> > virt_to_page(table_end);
>> > page++, i++) {
>> >SetPageReserved(page);
>> > - pages[i] = page;
>> > + uninorth_priv.pages_arr[i] = page;
>> >}
>> >
>> >bridge->gatt_table_real = (u32 *) table;
>> >/* Need to clear out any dirty data still sitting in caches */
>> >flush_dcache_range((unsigned long)table,
>> > (unsigned long)table_end + 1);
>> > - bridge->gatt_table = vmap(pages, (1 << page_order), 0,
>> > PAGE_KERNEL_NCG);
>> > + bridge->gatt_table = vmap(uninorth_priv.pages_arr, (1 << page_order),
>> > 0,
>> > PAGE_KERNEL_NCG);
>> >
>> >if (bridge->gatt_table == NULL)
>> >goto enomem;
>> > @@ -434,7 +437,7 @@ static int uninorth_create_gatt_table(struct
>> > agp_bridge_data *bridge)
>> >return 0;
>> >
>> > enomem:
>> > - kfree(pages);
>> > + kfree(uninorth_priv.pages_arr);
>> >if (table)
>> >free_pages((unsigned long)table, page_order);
>> >return -ENOMEM;
>> > @@ -456,6 +459,7 @@ static int uninorth_free_gatt_table(struct
>> > agp_bridge_data *bridge)
>> > */
>> >
>> >vunmap(bridge->gatt_table);
>> > + kfree(uninorth_priv.pages_arr);
>> >table = (char *) bridge->gatt_table_real;
>> >table_end = table + ((PAGE_SIZE * (1 << page_order)) - 1);
>> >
>> > --
>> > 2.4.0
>> >
>> >
>
>
>
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: memcpy regression
On Mon, 2015-09-07 at 09:08 +0200, Christophe LEROY wrote: > Hi Michael > > Le 07/09/2015 03:14, Michael Ellerman a écrit : > > On Sun, 2015-09-06 at 23:01 +0200, Michal Sojka wrote: > >> I found the problem. The compiler replaces an assignment with a call to > >> memcpy. The following patch fixes the problem for me. However, I'm not > >> sure whether this is the real solution. I guess the compiler is free to > >> generate a call to memcpy wherever it wants so other compilers or other > >> optimization levels may need fixes at other places. What do others > >> think? > > I think you're right that it's not a good solution, the compiler could > > generate > > other calls to memcpy depending on various factors, and people will add new > > code that causes memcpy to get called and it will break your platform. > > > > Christophe, am I right that the problem here is that your new memcpy() > > doesn't > > work until later in boot when caches are enabled? > > That's right, memset() and memcpy() are for setting/copying data into > cacheable RAM. > They are using dczb instruction in order to avoid wasting time loading > the cacheline with data that will be overwritten. > > memset_io() and memcpy_toio() are the functions to use when using not > cacheable memory. > > The issue identified by Michal is in function setup_cpu_spec() which is > called by identify_cpu(). identify_cpu() is called from early_init(). > In the begining of early_init(), there is (code from Paul in 2005) > > /* First zero the BSS -- use memset_io, some platforms don't have >* caches on yet */ > memset_io((void __iomem *)PTRRELOC(&__bss_start), 0, > __bss_stop - __bss_start); > > It shows that it is already expected that the cache is not active yet > and standard memset() shall not be used yet. That's the same with memcpy(). Thanks for the explanation. > I think GCC uses memcpy() in well known situations like initialising > structures or copying structures. > Shouldn't we just avoid this kind of actions in the very few early init > functions ? Which are the "very few" early init functions? Can you make a list, for 32-bit and 64-bit? And can we keep it updated over time and not introduce regressions? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] cxl: abort cxl_pci_enable_device_hook() if PCI channel is offline
On Mon, 2015-09-07 at 16:33 +1000, Ian Munsie wrote: > No worries. I've been caught out by something similar in the past when I > assumed that something like this: > > if (foo) > /* >* A big long >* multiline >* block comment! >*/ >do_something() > > would surely already have curly brackets around it ;-) You guys can do whatever you like for the cxl code. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 3/4] powerpc: PCI: Fix lookup of linux,pci-probe-only property
On Fri, 2015-09-04 at 17:50 +0100, Marc Zyngier wrote: > When find_and_init_phbs() looks for the probe-only property, it seems > to trust the firmware to be correctly written, and assumes that there > is a parameter to the property. > > It is conceivable that the firmware could not be that perfect, and it > could expose this property naked (at least one arm64 platform seems to > exhibit this exact behaviour). The setup code the ends up making > a decision based on whatever the property pointer points to, which > is likely to be junk. > > Instead, switch to the common of_pci.c implementation that doesn't > suffer from this problem and ignore the property if the firmware > couldn't make up its mind. > > Signed-off-by: Marc Zyngier > --- > arch/powerpc/platforms/pseries/setup.c | 14 ++ Thanks. I can't find any powerpc machine that is currently using this, or much info on what ever did use it, so I think it's pretty low impact, and the change looks sane. Acked-by: Michael Ellerman cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v4 2/4] PCI: pci-host-generic: Fix lookup of linux,pci-probe-only property
On Fri, Sep 04, 2015 at 05:50:09PM +0100, Marc Zyngier wrote:
> When pci-host-generic looks for the probe-only property, it seems
> to trust the DT to be correctly written, and assumes that there
> is a parameter to the property.
>
> Unfortunately, this is not always the case, and some firmware expose
> this property naked. The driver ends up making a decision based on
> whatever the property pointer points to, which is likely to be junk.
>
> Switch to the common of_pci.c implementation that doesn't suffer
> from this problem.
>
> Signed-off-by: Marc Zyngier
> ---
> drivers/pci/host/pci-host-generic.c | 9 +
> 1 file changed, 1 insertion(+), 8 deletions(-)
>
> diff --git a/drivers/pci/host/pci-host-generic.c
> b/drivers/pci/host/pci-host-generic.c
> index 265dd25..224303d 100644
> --- a/drivers/pci/host/pci-host-generic.c
> +++ b/drivers/pci/host/pci-host-generic.c
> @@ -210,7 +210,6 @@ static int gen_pci_probe(struct platform_device *pdev)
> int err;
> const char *type;
> const struct of_device_id *of_id;
> - const int *prop;
> struct device *dev = &pdev->dev;
> struct device_node *np = dev->of_node;
> struct gen_pci *pci = devm_kzalloc(dev, sizeof(*pci), GFP_KERNEL);
> @@ -225,13 +224,7 @@ static int gen_pci_probe(struct platform_device *pdev)
> return -EINVAL;
> }
>
> - prop = of_get_property(of_chosen, "linux,pci-probe-only", NULL);
> - if (prop) {
> - if (*prop)
> - pci_add_flags(PCI_PROBE_ONLY);
> - else
> - pci_clear_flags(PCI_PROBE_ONLY);
> - }
> + of_pci_check_probe_only();
Looks good to me:
Acked-by: Will Deacon
Thanks, Marc.
Will
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/powernv/pci-ioda: fix kdump with non-power-of-2 crashkernel=
On Fri, 2015-09-04 at 11:22 -0700, Nishanth Aravamudan wrote:
> The 32-bit TCE table initialization relies on the DMA window having a
> size equal to a power of 2 (and checks for it explicitly). But
> crashkernel= has no constraint that requires a power-of-2 be specified.
> This causes the kdump kernel to fail to boot as none of the PCI devices
> (including the disk controller) are successfully initialized.
>
> After this change, the PCI devices successfully set up the 32-bit TCE
> table and kdump succeeds.
>
> Fixes: aca6913f5551 ("powerpc/powernv/ioda2: Introduce helpers to allocate
> TCE pages")
> Signed-off-by: Nishanth Aravamudan
> Cc: sta...@vger.kernel.org # 4.2
>
> Michael, I kept this as a follow-on patch to my previous one. If you'd
> rather I made a v3 of that patch with the two fixes combined, I can
> resend.
No that's fine. I guess they could have been a single fix, but it's not a big
deal.
> Also, I fixed up the context on my end to be u64, but not sure
> if that will match your tree (next doesn't have my prior patch applied
> yet, that I can see).
next isn't open yet, because we're still in the merge window, ie. rc1 hasn't
come out yet.
This is a fix so it'll go to my fixes branch. Whether I send that to Linus
before or after rc1 depends on how urgent the fixes people send me are. Sounds
like you'd like these two to go in asap?
cheers
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FIX] powerpc/pseries: Release DRC when configure_connector fails
On Fri, 2015-04-09 at 10:04:12 UTC, Bharata B Rao wrote: > From: Bharata B Rao > > dlpar_cpu_probe() should release the acquired DRC if configure_connector > call fails. > > Signed-off-by: Bharata B Rao > Cc: Nathan Fontenot > Reviewed-by: Nathan Fontenot Which commit caused this to be a bug? Or has it always been there? What is the symptom, is it catastrophic, or just cosmetic? Should the fix go to stable? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2,3/6] powerpc: kill mfvtb()
On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote: > This function is only used by get_vtb(). They are almost the same > except the reading from the real register. Move the mfspr() to > get_vtb() and kill the function mfvtb(). With this, we can eliminate > the use of cpu_has_feature() in very core header file like reg.h. > This is a preparation for the use of jump label for cpu_has_feature(). I don't mind this change. But can you elaborate a bit on the issue with using cpu_has_feature() in reg.h? Just so I can understand the problem. I assume you ended up in a big mess of includes when you tried to include jump_label.h from reg.h? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: memcpy regression
On 7.9.2015 10:40, Michael Ellerman wrote: On Mon, 2015-09-07 at 09:08 +0200, Christophe LEROY wrote: Hi Michael Le 07/09/2015 03:14, Michael Ellerman a écrit : On Sun, 2015-09-06 at 23:01 +0200, Michal Sojka wrote: I found the problem. The compiler replaces an assignment with a call to memcpy. The following patch fixes the problem for me. However, I'm not sure whether this is the real solution. I guess the compiler is free to generate a call to memcpy wherever it wants so other compilers or other optimization levels may need fixes at other places. What do others think? I think you're right that it's not a good solution, the compiler could generate other calls to memcpy depending on various factors, and people will add new code that causes memcpy to get called and it will break your platform. Christophe, am I right that the problem here is that your new memcpy() doesn't work until later in boot when caches are enabled? That's right, memset() and memcpy() are for setting/copying data into cacheable RAM. They are using dczb instruction in order to avoid wasting time loading the cacheline with data that will be overwritten. memset_io() and memcpy_toio() are the functions to use when using not cacheable memory. The issue identified by Michal is in function setup_cpu_spec() which is called by identify_cpu(). identify_cpu() is called from early_init(). In the begining of early_init(), there is (code from Paul in 2005) /* First zero the BSS -- use memset_io, some platforms don't have * caches on yet */ memset_io((void __iomem *)PTRRELOC(&__bss_start), 0, __bss_stop - __bss_start); It shows that it is already expected that the cache is not active yet and standard memset() shall not be used yet. That's the same with memcpy(). Thanks for the explanation. I think GCC uses memcpy() in well known situations like initialising structures or copying structures. Shouldn't we just avoid this kind of actions in the very few early init functions ? Which are the "very few" early init functions? Can you make a list, for 32-bit and 64-bit? And can we keep it updated over time and not introduce regressions? If the code that runs without caches is concentrated in few files, we may either modify the buildsystem to check whether there is a call to memcpy from these files (e.g. by using nm) or these files can be "prelinked" with special version of memcpy that doesn't require caches. Would any of these be acceptable? -Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[FIX PATCH v1] powerpc/pseries: Release DRC when configure_connector fails
From: Bharata B Rao
Commit f32393c943e2 ("powerpc/pseries: Correct cpu affinity for
dlpar added cpus") moved dlpar_acquire_drc() call to before
dlpar_configure_connector() call in dlpar_cpu_probe(), but missed
to release the DRC if dlpar_configure_connector() failed.
During CPU hotplug, if configure-connector fails for any reason,
then this will result in subsequent CPU hotplug attempts to fail.
Release the acquired DRC if dlpar_configure_connector() call fails
so that the DRC is left in right isolation and allocation state
for the subsequent hotplug operation to succeed.
Signed-off-by: Bharata B Rao
Reviewed-by: Nathan Fontenot
---
Changes in v1: Improved patch description.
v0: https://patchwork.ozlabs.org/patch/514370/
This fix should probably go to stable too.
arch/powerpc/platforms/pseries/dlpar.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/platforms/pseries/dlpar.c
b/arch/powerpc/platforms/pseries/dlpar.c
index 47d9cebe..db17827 100644
--- a/arch/powerpc/platforms/pseries/dlpar.c
+++ b/arch/powerpc/platforms/pseries/dlpar.c
@@ -422,8 +422,10 @@ static ssize_t dlpar_cpu_probe(const char *buf, size_t
count)
dn = dlpar_configure_connector(cpu_to_be32(drc_index), parent);
of_node_put(parent);
- if (!dn)
+ if (!dn) {
+ dlpar_release_drc(drc_index);
return -EINVAL;
+ }
rc = dlpar_attach_node(dn);
if (rc) {
--
1.8.3.1
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [FIX] powerpc/pseries: Release DRC when configure_connector fails
On Mon, Sep 07, 2015 at 07:22:04PM +1000, Michael Ellerman wrote: > On Fri, 2015-04-09 at 10:04:12 UTC, Bharata B Rao wrote: > > From: Bharata B Rao > > > > dlpar_cpu_probe() should release the acquired DRC if configure_connector > > call fails. > > > > Signed-off-by: Bharata B Rao > > Cc: Nathan Fontenot > > Reviewed-by: Nathan Fontenot > > Which commit caused this to be a bug? Or has it always been there? > > What is the symptom, is it catastrophic, or just cosmetic? > > Should the fix go to stable? Posted v1 with the above questions answered appropriately. Regards, Bharata. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] agp/uninorth: fix a memleak in create_gatt_table
On Mon, 2015-09-07 at 10:30 +0300, Denis Kirjanov wrote: > On 6/19/15, Benjamin Herrenschmidt wrote: > > On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote: > >> On 6/12/15, Denis Kirjanov wrote: > >> > Fix the memory leak in create_gatt_table: > >> > we've lost a kfree on the exit path for the pages array allocated > >> > in uninorth_create_gatt_table > >> > > >> > Signed-off-by: Denis Kirjanov > >> > >> Hi Ben, Michael > >> > >> Will you take the patch through your trees or do I need to send it to > >> Dave Airlie? > > > > I haven't had a chance to review yet... > > Ping... Hi Denis, Have you built and/or boot tested this? cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] agp/uninorth: fix a memleak in create_gatt_table
On 9/7/15, Michael Ellerman wrote: > On Mon, 2015-09-07 at 10:30 +0300, Denis Kirjanov wrote: >> On 6/19/15, Benjamin Herrenschmidt wrote: >> > On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote: >> >> On 6/12/15, Denis Kirjanov wrote: >> >> > Fix the memory leak in create_gatt_table: >> >> > we've lost a kfree on the exit path for the pages array allocated >> >> > in uninorth_create_gatt_table >> >> > >> >> > Signed-off-by: Denis Kirjanov >> >> >> >> Hi Ben, Michael >> >> >> >> Will you take the patch through your trees or do I need to send it to >> >> Dave Airlie? >> > >> > I haven't had a chance to review yet... >> >> Ping... > > Hi Denis, > > Have you built and/or boot tested this? > Hi, yes, sure. Actually I've spotted this through the kmemleak. With the patch applied scanner is happy :) > cheers > > > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: memcpy regression
From: Michal Sojka > >> I think GCC uses memcpy() in well known situations like initialising > >> structures or copying structures. > >> Shouldn't we just avoid this kind of actions in the very few early init > >> functions ? > > Which are the "very few" early init functions? Can you make a list, for > > 32-bit > > and 64-bit? And can we keep it updated over time and not introduce > > regressions? > > > If the code that runs without caches is concentrated in few files, we > may either modify the buildsystem to check whether there is a call to > memcpy from these files (e.g. by using nm) or these files can be > "prelinked" with special version of memcpy that doesn't require caches. > Would any of these be acceptable? What about run-time patching memcpy() after the caches are initialised? David ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
memcpy regression
Dear Christophe, my MPC5200-based system stopped booting recently. I bisected the problem to your commit below. If I revert that commit (on top of 807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my system boots again. commit 0b05e2d671c40cfb57e66e4e402320d6e056b2f8 Author: LEROY Christophe Date: Tue May 19 12:07:55 2015 +0200 powerpc/32: cacheable_memcpy becomes memcpy cacheable_memcpy uses dcbz instruction and is more efficient than memcpy when the destination is in RAM. If the destination is in an io area, memcpy_toio() is normally used, not memcpy This patch renames memcpy as generic_memcpy, and renames cacheable_memcpy as memcpy On MPC885, we get approximatly 7% increase of the transfer rate on an FTP reception Signed-off-by: Christophe Leroy Signed-off-by: Scott Wood Best regards, -Michal Sojka ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: memcpy regression
On Fri, Sep 04 2015, Christophe LEROY wrote: > Le 04/09/2015 15:33, Michal Sojka a écrit : >> Dear Christophe, >> >> my MPC5200-based system stopped booting recently. I bisected the problem >> to your commit below. If I revert that commit (on top of >> 807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my >> system boots again. >> >> > > Do you use mainline code only, or do you have home-made code ? I use mainline only sources with non-mainline device-tree. > memcpy() is not supposed to be used on non-cacheable memory. > memcpy_toio() is the function to use when copying to non-cacheble area. > > When I submitted the patch, I looked for erroneous use of memcpy() and > memset(). > I found one wrong use of memset() that I changed to memset_io() but I > didn't find any misuse of memcpy(). > But I may have missed one. I attach my .config, if it helps. I have there CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y so arch/powerpc/platforms/52xx is probably the directory to look. Do you see any mempcy misuse there? Thanks, -Michal .config Description: Binary data ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: memcpy regression
On 4.9.2015 20:10, christophe leroy wrote: Le 04/09/2015 16:35, Michal Sojka a écrit : On Fri, Sep 04 2015, Christophe LEROY wrote: Le 04/09/2015 15:33, Michal Sojka a écrit : Dear Christophe, my MPC5200-based system stopped booting recently. I bisected the problem to your commit below. If I revert that commit (on top of 807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my system boots again. Do you use mainline code only, or do you have home-made code ? I use mainline only sources with non-mainline device-tree. memcpy() is not supposed to be used on non-cacheable memory. memcpy_toio() is the function to use when copying to non-cacheble area. When I submitted the patch, I looked for erroneous use of memcpy() and memset(). I found one wrong use of memset() that I changed to memset_io() but I didn't find any misuse of memcpy(). But I may have missed one. I attach my .config, if it helps. I have there CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y so arch/powerpc/platforms/52xx is probably the directory to look. Do you see any mempcy misuse there? I only found one suspect use of memcpy() in arch/powerpc/platforms/52xx/ It is in mpc52xx_pm.c but it's linked to CONFIG_PM which is not selected by your .config I'll check in the drivers selected by your .config In parallele, are you able to try with CONFIG_PPC_EARLY_DEBUG in order to try and locate the blocking point ? I don't get any output from the system even with CONFIG_PPC_EARLY_DEBUG. -Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case
One other thing.
The way to present all the people who submitted, such that each one got some
amount of exposure, was a dynamic thing that just occurred to me as we were
setting up.
Sort of like you first starting to select the judging panels, by ‘guessing’ a
number… which didn’t work very well, but then counting out groups did. (even if
there were groups that had some extras because the group was an odd number…).
Next time, we will have this in mind and it will be very straightforward…
1,2,3… for both how to select the panels, and how to present the submissions.
Love,
John.
On Sep 4, 2015, at 3:46 PM, Guilherme G. Piccoli [via linuxppc]
wrote:
> Hello Bjorn,
>
> > of_create_pci_dev() already has a lot of code that duplicates
> > pci_setup_device(), and it's a shame to add more. There's also a sparc
> > version of of_create_pci_dev() that presumably has the same problem you're
> > fixing for powerpc.
>
> Thanks for the information!
>
> > Michael originally called pci_msi_setup_pci_dev() from
> > pci_init_capabilities() [1]. A subsequent patch moved the call
> > to pci_setup_device() [2] because an early quirk (called from
> > pci_setup_device()) used pci_msi_off(), which depended on
> > pci_msi_setup_pci_dev().
> >
> > But we later removed pci_msi_off() completely, so I think we probably
> > *could* call pci_msi_setup_pci_dev() from pci_init_capabilities().
> >
> > That would be much nicer because it makes more sense there, and it
> > would do the right thing for powerpc and sparc because they both
> > already use that path.
> >
> > Can you look into moving the call?
>
> I might have misunderstood something here (sorry if it's the case), but
> moving the call to pci_init_capabilities() has the same practical
> implications than reverting my 2 commmits [1] [2] and Michael Tsirkin's
> commit [3], except when CONFIG_PCI_MSI is not set - in this case, moving
> the call would initialize MSI capabilities anyway, since
> pci_init_capabilities() executes even if CONFIG_PCI_MSI isn't set.
>
> My question is: is necessary to initialize MSI capabilities even with
> CONFIG_PCI_MSI not set? In negative case, would be "cleaner" revert the
> 3 commits, right?
>
> On the other hand, if it's necessary to initialize MSI capabilities on
> devices anyway, we can change the call place.
>
> Let me know your opinion, and I'm sorry if I misunderstood something here.
>
> Cheers,
>
>
> Guilherme Piccoli
>
>
>
> [1] commit 22b6839b914b ("PCI: Make pci_msi_setup_pci_dev() non-static
> for use by arch code")
>
> [2] commit 4d9aac397a5d ("powerpc/PCI: Disable MSI/MSI-X interrupts at
> PCI probe time in OF case")
>
> [3] commit 1851617cd2da ("PCI/MSI: Disable MSI at enumeration even if
> kernel doesn't support MSI")
>
> ___
> Linuxppc-dev mailing list
> [hidden email]
> https://lists.ozlabs.org/listinfo/linuxppc-dev
>
> If you reply to this email, your message will be added to the discussion
> below:
> http://linuxppc.10917.n7.nabble.com/PATCH-0-2-Disable-MSI-MSI-X-interrupts-manually-at-PCI-probe-time-in-PowerPC-architecture-tp97680p98194.html
> To start a new topic under linuxppc-dev, email
> ml-node+s10917n3...@n7.nabble.com
> To unsubscribe from linuxppc, click here.
> NAML
--
View this message in context:
http://linuxppc.10917.n7.nabble.com/PATCH-0-2-Disable-MSI-MSI-X-interrupts-manually-at-PCI-probe-time-in-PowerPC-architecture-tp97680p98195.html
Sent from the linuxppc-dev mailing list archive at Nabble.com.___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: memcpy regression
On 4.9.2015 21:49, Michal Sojka wrote: On 4.9.2015 20:10, christophe leroy wrote: Le 04/09/2015 16:35, Michal Sojka a écrit : On Fri, Sep 04 2015, Christophe LEROY wrote: Le 04/09/2015 15:33, Michal Sojka a écrit : Dear Christophe, my MPC5200-based system stopped booting recently. I bisected the problem to your commit below. If I revert that commit (on top of 807249d3ada1ff28a47c4054ca4edd479421b671 = v4.2-6663-g807249d), my system boots again. Do you use mainline code only, or do you have home-made code ? I use mainline only sources with non-mainline device-tree. memcpy() is not supposed to be used on non-cacheable memory. memcpy_toio() is the function to use when copying to non-cacheble area. When I submitted the patch, I looked for erroneous use of memcpy() and memset(). I found one wrong use of memset() that I changed to memset_io() but I didn't find any misuse of memcpy(). But I may have missed one. I attach my .config, if it helps. I have there CONFIG_PPC_MPC52xx=y CONFIG_PPC_MPC5200_SIMPLE=y so arch/powerpc/platforms/52xx is probably the directory to look. Do you see any mempcy misuse there? I only found one suspect use of memcpy() in arch/powerpc/platforms/52xx/ It is in mpc52xx_pm.c but it's linked to CONFIG_PM which is not selected by your .config I'll check in the drivers selected by your .config In parallele, are you able to try with CONFIG_PPC_EARLY_DEBUG in order to try and locate the blocking point ? I don't get any output from the system even with CONFIG_PPC_EARLY_DEBUG. Hmm, there is no udbg console for MPC5200. I hacked something up and the earliest place I was able to initialize it is after early_init_devtree() in setup_32.c. Even with this console, I got no output when the problematic patch was applied. So the problem is somewhere earlier. -Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
FYI: iceweasel 40.X.X PowerPC isn't available for Debian PPC32
FYI: On 07 September 2015 at 11:07 AM, Boris Reinhard [debian-powe...@lists.debian.org] wrote: Off-list reply, please don't quote/ forward Hi, wrong list, please use this one if you want to reach ppl that do active work on ppc: https://lists.ozlabs.org/listinfo/linuxppc-dev Come to think of it, it might be interesting/ helpful contacting Cameron Kaiser (tenfourfox) and Tobias Netzel (webkit for leopard) additionally, asking about how or if their ppc osx work could potentially/ at all benefit linux ppc!? Grüße Boris Reinhard Hi All, Iceweasel was updated to version 40.0.3-3 for the unofficial Debian PPC64 port. I installed it inside my Debian PPC64 chroot. Unfortunately it doesn't start either. Note: Iceweasel and Firefox 40.X.X PowerPC aren't available for all Ubuntu flavours and for Debian with 32-bit userland currently. Cheers, Christian On 02 September 2015 at 07:38 AM, Christian Zigotzky wrote: Hi Lennart, Thank you for your answer. Unfortunately the increasing of the stack spaces wasn't successfully. I tried the following stack sizes: ulimit -s 16384 ulimit -s 32768 ulimit -s 65536 ulimit -s 131072 iceweasel Debian PPC64 in a chroot: too much recursion Segmentation fault Rgds, Christian On 01 September 2015 at 8:02 PM, Lennart Sorensen [debian-powe...@lists.debian.org] wrote: On Tue, Sep 01, 2015 at 07:24:48PM +0200, Christian Zigotzky wrote: Hi All, Iceweasel and Firefox 40.X.X PowerPC aren't available for all Ubuntu flavours and for Debian with 32-bit userland currently. There are build problems: Iceweasel 40 build status: https://packages.debian.org/de/experimental/iceweasel Firefox 40 build status: https://launchpad.net/ubuntu/+source/firefox/ But iceweasel 40.0.3-1 was released for the unofficial Debian PPC64 port. I installed it inside my Debian PPC64 chroot. Unfortunately it doesn't start. Error messages: too much recursion Segmentation fault Is anyone working on resolving this issue? Could you try what happens if you change the stack size limit? ulimit -s 16384 (I believe the current default that you can check with ulimit -a is 8192). Could even try something even bigger like 65536. Then run firefox from that terminal where you changed the limit temporarily. Certainly with 64 bit pointers and 64 bit registers, ppc64 could be using quite a bit of stack space in the javascript engine, which appears to be the thing that always causes this error in firefox (seems to happen everytime they change the engine in a major way, and then things get tweaked until it works again, then it gets broken again). ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc32: memcpy: only use dcbz once cache is enabled
memcpy() uses instruction dcbz to speed up copy by not wasting time
loading cache line with data that will be overwritten.
Some platform like mpc52xx do no have cache active at startup and
can therefore not use memcpy(). Allthough no part of the code
explicitly uses memcpy(), GCC makes calls to it.
This patch modifies memcpy() such that at startup, the 'dcbz'
instruction is replaced by 'dcbt' which is harmless if cache is not
enabled, and which helps a bit (allthough not as much as dcbz) if
cache is already enabled.
Once the initial MMU is setup, in machine_init() we patch memcpy()
by replacing the temporary 'dcbt' by 'dcbz'
Reported-by: Michal Sojka
Signed-off-by: Christophe Leroy
---
@Michal, can you please test it ?
arch/powerpc/kernel/setup_32.c | 12
arch/powerpc/lib/copy_32.S | 11 ++-
2 files changed, 22 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup_32.c b/arch/powerpc/kernel/setup_32.c
index 07831ed..93715f3 100644
--- a/arch/powerpc/kernel/setup_32.c
+++ b/arch/powerpc/kernel/setup_32.c
@@ -39,6 +39,7 @@
#include
#include
#include
+#include
#define DBG(fmt...)
@@ -108,6 +109,15 @@ notrace unsigned long __init early_init(unsigned long
dt_ptr)
return KERNELBASE + offset;
}
+extern unsigned int ppc32_memcpy_dcbz;
+notrace void __init patch_memcpy(void)
+{
+ unsigned int instr = ppc32_memcpy_dcbz;
+
+ instr &= 0x001ff800; /* keep only RA and RB */
+ instr |= 0x7c0007ec; /* dcbz */
+ patch_instruction(&ppc32_memcpy_dcbz, instr);
+}
/*
* Find out what kind of machine we're on and save any data we need
@@ -122,6 +132,8 @@ notrace void __init machine_init(u64 dt_ptr)
/* Enable early debugging if any specified (see udbg.h) */
udbg_early_init();
+ patch_memcpy();
+
/* Do some early initialization based on the flat device tree */
early_init_devtree(__va(dt_ptr));
diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S
index 2ef50c6..05b3096 100644
--- a/arch/powerpc/lib/copy_32.S
+++ b/arch/powerpc/lib/copy_32.S
@@ -172,7 +172,16 @@ _GLOBAL(memcpy)
mtctr r0
beq 63f
53:
- dcbzr11,r6
+ /*
+* During early init, cache might not be active yet, so dcbz cannot be
+* used. We put dcbt instead of dcbz. If cache is not active, it's just
+* like a not. If cache is active, at least it prefetchs the line to be
+* overwritten.
+* Will be replaced by dcbz in machine_init()
+*/
+_GLOBAL(ppc32_memcpy_dcbz)
+ dcbtr11,r6
+
COPY_16_BYTES
#if L1_CACHE_BYTES >= 32
COPY_16_BYTES
--
2.1.0
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc32: memcpy: only use dcbz once cache is enabled
On Mon, Sep 07 2015, Christophe Leroy wrote: > memcpy() uses instruction dcbz to speed up copy by not wasting time > loading cache line with data that will be overwritten. > Some platform like mpc52xx do no have cache active at startup and > can therefore not use memcpy(). Allthough no part of the code > explicitly uses memcpy(), GCC makes calls to it. > > This patch modifies memcpy() such that at startup, the 'dcbz' > instruction is replaced by 'dcbt' which is harmless if cache is not > enabled, and which helps a bit (allthough not as much as dcbz) if > cache is already enabled. > > Once the initial MMU is setup, in machine_init() we patch memcpy() > by replacing the temporary 'dcbt' by 'dcbz' > > Reported-by: Michal Sojka > Signed-off-by: Christophe Leroy > --- > @Michal, can you please test it ? Yes, it works. Tested-by: Michal Sojka -Michal ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: [PATCH] powerpc32: memcpy: only use dcbz once cache is enabled
From: Christophe Leroy > Sent: 07 September 2015 15:25 ... > diff --git a/arch/powerpc/lib/copy_32.S b/arch/powerpc/lib/copy_32.S > index 2ef50c6..05b3096 100644 > --- a/arch/powerpc/lib/copy_32.S > +++ b/arch/powerpc/lib/copy_32.S > @@ -172,7 +172,16 @@ _GLOBAL(memcpy) > mtctr r0 > beq 63f > 53: > - dcbzr11,r6 > + /* > + * During early init, cache might not be active yet, so dcbz cannot be > + * used. We put dcbt instead of dcbz. If cache is not active, it's just > + * like a not. If cache is active, at least it prefetchs the line to be ^^^ nop ?? David > + * overwritten. > + * Will be replaced by dcbz in machine_init() > + */ > +_GLOBAL(ppc32_memcpy_dcbz) > + dcbtr11,r6 > + > COPY_16_BYTES > #if L1_CACHE_BYTES >= 32 > COPY_16_BYTES > -- > 2.1.0 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v4 11/20] tty/hvc: xen: Use xen page definition
The console ring is always based on the page granularity of Xen. Signed-off-by: Julien Grall Reviewed-by: Stefano Stabellini --- Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: David Vrabel Cc: Boris Ostrovsky Cc: linuxppc-dev@lists.ozlabs.org Changes in v4: - The ring is always 4K (i.e XEN_PAGE_SIZE), so no need to map with PAGE_SIZE. This was correctly done in v2 but lost with the rebase to the "s/mfn/gfn/" series Changes in v3: - Some changes has been moved in the series "Use correctly the Xen memory terminologies in Linux". - Add Stefano's reviewed-by --- drivers/tty/hvc/hvc_xen.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/tty/hvc/hvc_xen.c b/drivers/tty/hvc/hvc_xen.c index 10beb15..fa816b7 100644 --- a/drivers/tty/hvc/hvc_xen.c +++ b/drivers/tty/hvc/hvc_xen.c @@ -230,7 +230,7 @@ static int xen_hvm_console_init(void) if (r < 0 || v == 0) goto err; gfn = v; - info->intf = xen_remap(gfn << PAGE_SHIFT, PAGE_SIZE); + info->intf = xen_remap(gfn << XEN_PAGE_SHIFT, XEN_PAGE_SIZE); if (info->intf == NULL) goto err; info->vtermno = HVC_COOKIE; @@ -472,7 +472,7 @@ static int xencons_resume(struct xenbus_device *dev) struct xencons_info *info = dev_get_drvdata(&dev->dev); xencons_disconnect_backend(info); - memset(info->intf, 0, PAGE_SIZE); + memset(info->intf, 0, XEN_PAGE_SIZE); return xencons_connect_backend(dev, info); } -- 2.1.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v2 1/9] [picked] powerpc: allocate sys_membarrier system call number
Allow it to be used from SPU, since it should not have unwanted side-effects. [ Picked-by: Michael Ellerman ] Signed-off-by: Mathieu Desnoyers CC: Andrew Morton CC: linux-...@vger.kernel.org CC: Benjamin Herrenschmidt CC: Paul Mackerras CC: Michael Ellerman CC: linuxppc-dev@lists.ozlabs.org --- arch/powerpc/include/asm/systbl.h | 1 + arch/powerpc/include/asm/unistd.h | 2 +- arch/powerpc/include/uapi/asm/unistd.h | 1 + 3 files changed, 3 insertions(+), 1 deletion(-) diff --git a/arch/powerpc/include/asm/systbl.h b/arch/powerpc/include/asm/systbl.h index 4d65499..126d0c4 100644 --- a/arch/powerpc/include/asm/systbl.h +++ b/arch/powerpc/include/asm/systbl.h @@ -369,3 +369,4 @@ SYSCALL_SPU(bpf) COMPAT_SYS(execveat) PPC64ONLY(switch_endian) SYSCALL_SPU(userfaultfd) +SYSCALL_SPU(membarrier) diff --git a/arch/powerpc/include/asm/unistd.h b/arch/powerpc/include/asm/unistd.h index 4a055b6..13411be 100644 --- a/arch/powerpc/include/asm/unistd.h +++ b/arch/powerpc/include/asm/unistd.h @@ -12,7 +12,7 @@ #include -#define __NR_syscalls 365 +#define __NR_syscalls 366 #define __NR__exit __NR_exit #define NR_syscalls__NR_syscalls diff --git a/arch/powerpc/include/uapi/asm/unistd.h b/arch/powerpc/include/uapi/asm/unistd.h index 6ad58d4..6337738 100644 --- a/arch/powerpc/include/uapi/asm/unistd.h +++ b/arch/powerpc/include/uapi/asm/unistd.h @@ -387,5 +387,6 @@ #define __NR_execveat 362 #define __NR_switch_endian 363 #define __NR_userfaultfd 364 +#define __NR_membarrier365 #endif /* _UAPI_ASM_POWERPC_UNISTD_H_ */ -- 1.9.1 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [RESEND,v3] powerpc/pseries: Limit EPOW reset event warnings
On 07/17/2015 01:47 PM, Kamalesh Babulal wrote:
* Michael Ellerman [2015-07-16 14:05:52]:
[..]
Why are we even getting these reset events when nothing has happened?
Thanks for the review. It was seen only on one machine, couldn't
get hold of the machine any more. I am guessing here, that it might be
the firmware.
Checking with PFW guys as to under what circumstances one would see
so many reset events being reported ? Will post out findings as soon as i
hear things back from PFW guys on this.
Also, merged adjacent pr_err/pr_emerg into single one to reduce
the number of lines printed per warning.
[..]
+/* Flag to limit EPOW RESET warning. */
+static bool epow_state;
This name is terrible, it doesn't give me any hint to what it means.
But really it should be a counter, not a boolean.
We could have multiple EPOW events come in and then later get the reset events
for them, couldn't we?
So what about:
static unsigned epow_event_depth;
--->8
From 0d27916fd09a9f0912a217432a41e2b579dc2952 Mon Sep 17 00:00:00 2001
From: Kamalesh Babulal
Date: Fri, 17 Jul 2015 13:19:31 +0530
Subject: [PATCH v4] powerpc/pseries: Limit EPOW reset event warnings
Kernel prints respective warnings about various EPOW events for
user information/action after parsing EPOW interrupts. At times
EPOW reset event warning, such as below could flood kernel log,
over a period of time.
May 25 03:46:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:46:52 alp kernel: Non critical power or cooling issue cleared
May 25 03:53:48 alp kernel: Non critical power or cooling issue cleared
May 25 03:55:46 alp kernel: Non critical power or cooling issue cleared
May 25 03:56:34 alp kernel: Non critical power or cooling issue cleared
May 25 03:59:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:02:01 alp kernel: Non critical power or cooling issue cleared
May 25 04:04:24 alp kernel: Non critical power or cooling issue cleared
May 25 04:07:18 alp kernel: Non critical power or cooling issue cleared
May 25 04:13:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:04 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:26 alp kernel: Non critical power or cooling issue cleared
May 25 04:22:36 alp kernel: Non critical power or cooling issue cleared
This patch avoids these multiple EPOW reset warnings by using epow_depth
counter. Which is incremented every time EPOW event is reported and
decremented on EPOW_RESET event. With this approach number EPOW RESET
warning matches the number of EPOW events.
Also, merged adjacent pr_info/pr_err/pr_emerg into single one to reduce
the number of lines printed per warning across the file and converted
non-critical errors to pr_info from pr_error, including grammar
correction in the warnings printed.
Suggested-by: Michael Ellerman
Cc: Anshuman Khandual
Cc: Anton Blanchard
Cc: Vipin K Parashar
Signed-off-by: Kamalesh Babulal
---
V4: Changes:
- Changed the approach to depth counter to match the EPOW events and
EPOW reset.
- Converted pr_err() ot pr_info() for non-critical errors.
- Merged adjacent warnings into single line across the file.
- Fixed grammar in the warnings to make is short.
v3 Changes:
- Limit warning printed by EPOW RESET event, by guarding it with bool flag.
Instead of rate limiting all the EPOW events.
v2 Changes:
- Merged multiple adjacent pr_err/pr_emerg into single line to reduce
multi-line
warnings, based on Michael's comments.
arch/powerpc/platforms/pseries/ras.c | 53
1 file changed, 29 insertions(+), 24 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/ras.c
b/arch/powerpc/platforms/pseries/ras.c
index 02e4a17..995cab8 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -40,6 +40,8 @@ static int ras_check_exception_token;
#define EPOW_SENSOR_TOKEN 9
#define EPOW_SENSOR_INDEX 0
+static unsigned epow_event_depth;
+
static irqreturn_t ras_epow_interrupt(int irq, void *dev_id);
static irqreturn_t ras_error_interrupt(int irq, void *dev_id);
@@ -82,32 +84,30 @@ static void handle_system_shutdown(char event_modifier)
{
switch (event_modifier) {
case EPOW_SHUTDOWN_NORMAL:
- pr_emerg("Firmware initiated power off");
+ pr_emerg("Firmware initiated power off\n");
orderly_poweroff(true);
break;
case EPOW_SHUTDOWN_ON_UPS:
- pr_emerg("Loss of power reported by firmware, system is "
- "running on UPS/battery");
- pr_emerg("Check RTAS error log for details");
+ pr_emerg("Loss of power reported, system is running on"
+" UPS/battery. Check RTAS error log for details\n");
orderly_poweroff(true);
break;
case EPOW_SHUTDOWN_LOSS_OF_CRITICAL_FUNCTIONS:
Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case
On Sun, 2015-09-06 at 17:44 +0300, Michael S. Tsirkin wrote: My question is: is necessary to initialize MSI capabilities even with CONFIG_PCI_MSI not set? In negative case, would be "cleaner" revert the 3 commits, right? I think the reason why it's necessary is explained in commit log for commit 1851617cd2da9cc53cdc1738f4148f4f042c0e56 (that's [3] below). Thanks very much Michael. I re-read the text of your commit, and makes sense then to initialize the MSI capabilities even with CONFIG_PCI_MSI not set. On 09/07/2015 12:17 AM, Michael Ellerman wrote: Well yes and no. What we want to do when CONFIG_PCI_MSI=n is disable MSI on the device. In order to do that the code first initialises dev->msi[x]_cap. But arguably that's wrong, ie. when CONFIG_PCI_MSI=n dev->msi[x]_cap *should* be zero so that any code which erroneously tries to use them will fail. But perhaps that's being too pedantic :) I thought exactly this - that was the reason of my questioning. Thanks for your opinion Michael - I'd call the argument logical, not pedantic hehehe Cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2 2/2] powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case
On 09/07/2015 12:10 AM, Michael Ellerman wrote: But we later removed pci_msi_off() completely, so I think we probably *could* call pci_msi_setup_pci_dev() from pci_init_capabilities(). That would be much nicer because it makes more sense there, and it would do the right thing for powerpc and sparc because they both already use that path. Sounds reasonable to me. Guilherme can you please try this and let us know. Sure Michael. I tested in pSeries and PowerNV and both worked. Couldn't test on SPARC. Cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v2,3/6] powerpc: kill mfvtb()
On Mon, Sep 07, 2015 at 07:29:42PM +1000, Michael Ellerman wrote: > On Mon, 2015-24-08 at 11:20:25 UTC, Kevin Hao wrote: > > This function is only used by get_vtb(). They are almost the same > > except the reading from the real register. Move the mfspr() to > > get_vtb() and kill the function mfvtb(). With this, we can eliminate > > the use of cpu_has_feature() in very core header file like reg.h. > > This is a preparation for the use of jump label for cpu_has_feature(). > > I don't mind this change. But can you elaborate a bit on the issue with using > cpu_has_feature() in reg.h? Just so I can understand the problem. > > I assume you ended up in a big mess of includes when you tried to include > jump_label.h from reg.h? Yes, the "jump_leabel.h" already include "reg.h" implicitly. from arch/powerpc/include/asm/cache.h:6:0, from include/linux/cache.h:5, from include/linux/printk.h:8, from include/linux/kernel.h:14, from include/asm-generic/bug.h:13, from arch/powerpc/include/asm/bug.h:127, from include/linux/bug.h:4, from include/linux/jump_label.h:81, So including "jump_label.h" from "reg.h" will cause a recursive header inclusion problem. Thanks, Kevin pgpzaIgfq7PY_.pgp Description: PGP signature ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v2] powerpc/powernv/pci-ioda: fix kdump with non-power-of-2 crashkernel=
On 07.09.2015 [19:19:09 +1000], Michael Ellerman wrote:
> On Fri, 2015-09-04 at 11:22 -0700, Nishanth Aravamudan wrote:
> > The 32-bit TCE table initialization relies on the DMA window having a
> > size equal to a power of 2 (and checks for it explicitly). But
> > crashkernel= has no constraint that requires a power-of-2 be specified.
> > This causes the kdump kernel to fail to boot as none of the PCI devices
> > (including the disk controller) are successfully initialized.
> >
> > After this change, the PCI devices successfully set up the 32-bit TCE
> > table and kdump succeeds.
> >
> > Fixes: aca6913f5551 ("powerpc/powernv/ioda2: Introduce helpers to allocate
> > TCE pages")
> > Signed-off-by: Nishanth Aravamudan
> > Cc: sta...@vger.kernel.org # 4.2
> >
> > Michael, I kept this as a follow-on patch to my previous one. If you'd
> > rather I made a v3 of that patch with the two fixes combined, I can
> > resend.
>
> No that's fine. I guess they could have been a single fix, but it's
> not a big deal.
Ok, thanks for understanding.
> > Also, I fixed up the context on my end to be u64, but not sure
> > if that will match your tree (next doesn't have my prior patch applied
> > yet, that I can see).
>
> next isn't open yet, because we're still in the merge window, ie. rc1
> hasn't come out yet.
Ah got it. I did mean your next branch, not linux-next itself, fwiw.
> This is a fix so it'll go to my fixes branch. Whether I send that to
> Linus before or after rc1 depends on how urgent the fixes people send
> me are. Sounds like you'd like these two to go in asap?
If at all possible, yes please.
-Nish
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] agp/uninorth: fix a memleak in create_gatt_table
On Mon, 2015-09-07 at 13:39 +0300, Denis Kirjanov wrote: > On 9/7/15, Michael Ellerman wrote: > > On Mon, 2015-09-07 at 10:30 +0300, Denis Kirjanov wrote: > >> On 6/19/15, Benjamin Herrenschmidt wrote: > >> > On Thu, 2015-06-18 at 17:34 +0300, Denis Kirjanov wrote: > >> >> On 6/12/15, Denis Kirjanov wrote: > >> >> > Fix the memory leak in create_gatt_table: > >> >> > we've lost a kfree on the exit path for the pages array allocated > >> >> > in uninorth_create_gatt_table > >> >> > > >> >> > Signed-off-by: Denis Kirjanov > >> >> > >> >> Hi Ben, Michael > >> >> > >> >> Will you take the patch through your trees or do I need to send it to > >> >> Dave Airlie? > >> > > >> > I haven't had a chance to review yet... > >> > >> Ping... > > > > Hi Denis, > > > > Have you built and/or boot tested this? > > Hi, > > yes, sure. Actually I've spotted this through the kmemleak. With the > patch applied scanner is happy :) OK thanks. I'll merge it then, and if Ben ever reviews it and dislikes your changes he can send patches to fix it :) cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: memcpy regression
On Mon, 2015-09-07 at 10:59 +, David Laight wrote: > From: Michal Sojka > > >> I think GCC uses memcpy() in well known situations like initialising > > >> structures or copying structures. > > >> Shouldn't we just avoid this kind of actions in the very few early init > > >> functions ? > > > Which are the "very few" early init functions? Can you make a list, for > > > 32-bit > > > and 64-bit? And can we keep it updated over time and not introduce > > > regressions? > > > > > If the code that runs without caches is concentrated in few files, we > > may either modify the buildsystem to check whether there is a call to > > memcpy from these files (e.g. by using nm) or these files can be > > "prelinked" with special version of memcpy that doesn't require caches. > > Would any of these be acceptable? > > What about run-time patching memcpy() after the caches are initialised? Yeah, that's the solution we use on 64-bit. It also means you can have cpu specific optimisations, which can be patched in or out using the cpu feature patching. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH] powerpc32: memcpy: only use dcbz once cache is enabled
On Mon, 2015-09-07 at 16:24 +0200, Christophe Leroy wrote: > memcpy() uses instruction dcbz to speed up copy by not wasting time > loading cache line with data that will be overwritten. > Some platform like mpc52xx do no have cache active at startup and > can therefore not use memcpy(). Allthough no part of the code > explicitly uses memcpy(), GCC makes calls to it. > > This patch modifies memcpy() such that at startup, the 'dcbz' > instruction is replaced by 'dcbt' which is harmless if cache is not > enabled, and which helps a bit (allthough not as much as dcbz) if > cache is already enabled. > > Once the initial MMU is setup, in machine_init() we patch memcpy() > by replacing the temporary 'dcbt' by 'dcbz' > > Reported-by: Michal Sojka > Signed-off-by: Christophe Leroy Is there some reason you can't use the normal cpu feature sections? See arch/powerpc/lib/memcpy_64.S for an example of what I mean. cheers ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v6 1/2] perf,kvm/powerpc: Add kvm_perf.h for powerpc
On 09/07/2015 10:40 AM, Michael Ellerman wrote:
On Fri, 2015-09-04 at 17:51 -0300, Arnaldo Carvalho de Melo wrote:
Em Tue, Sep 01, 2015 at 12:18:47PM +0530, Hemant Kumar escreveu:
Should I try to process the 5 together, applying thest two first?
Yes, this patchset needs to be applied before applying the other patchset,
since there is a direct dependency on these two for the tooling part to
work.
I see there are no acks from powerpc arch maintainers, how should we
proceed here? If there are no problems with the arch bits, and if it is
just to enable the tooling part, again, should I process the 5 as just
one series?
The reason to split the earlier patchset into two was to separate the
tooling/perf/ and arch/powerpc/ side patches, as asked by Michael..
Here is the link to that discussion :
http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg86916.html
If Michael is ok with the patches, you can process all the 5 patches
together. Michael?
Michael?
I'm not particularly happy with it.
Can we at least remove this hunk from the uapi header:
+/* This is to shut the compiler up */
+#define KVM_ENTRY_TRACE ""
+#define KVM_EXIT_TRACE ""
+#define KVM_EXIT_REASON ""
Agreed, I didn't like this too, but I kept this because of the generic
perf userspace code that looks for KVM_{ENTRY,EXIT}_TRACE and
KVM_EXIT_REASON. We can remove this and put this hunk in the
userspace side.
Arnaldo,
Can we remove the dependency on uapi altogether (also suggested
by Scott) because it doesn't seem to fulfill much purpose? Rather,
hardcode the events in the userspace completely (since, tracepoint
event names are unlikely to change) ? Some of what is being done
by x86 already in kvm-stat.c where its defining kvm_events_tp[] and
its not using the macros, rather, the tracepoints directly. Macros are
only being used in builtin-kvm.c where the tracepoint names are
matched with KVM_{ENTRY,EXIT}_TRACE and when we are looking
for the key KVM_EXIT_REASON.
--
Thanks,
Hemant Kumar
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
i2c i2c-2: I2C write to 0x2d failed, err -27 on Xserve G5
Hi all, I'm running this kernel: [ +0.00] Linux version 3.16.0-4-powerpc64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) on my Xserve G5, and it works great except these messages keep coming in dmesg: [Sep 4 19:11] i2c i2c-2: I2C write to 0x2d failed, err -27 [Sep 4 19:29] i2c i2c-2: I2C write to 0x2d failed, err -27 [Sep 4 20:04] i2c i2c-2: I2C write to 0x2d failed, err -27 [Sep 4 20:29] i2c i2c-2: I2C write to 0x2d failed, err -27 Is this a known problem, or has been fixed in a newer version since this branch in Debian? I see in the mailing list, there are some i2c related fixes. I can run a kernel.org kernel + apply patches if that should help. See attached full dmesg and lspci for more details. Thanks! -Nick [Aug31 20:54] Allocated 131072 bytes for 32 pacas at cffe [ +0.00] DART table allocated at: c0007f00 [ +0.00] Using PowerMac machine description [ +0.00] Page orders: linear mapping = 24, virtual = 12, io = 12, vmemmap = 24 [ +0.00] kvm_cma: CMA: reserved 256 MiB [ +0.00] Found initrd at 0xc1a0:0xc2c04c00 [ +0.00] Found U3 memory controller & host bridge @ 0xf800 revision: 0x35 [ +0.00] Mapped at 0xd8008000 [ +0.00] Found a K2 mac-io controller, rev: 96, mapped at 0xd8008005 [ +0.00] PowerMac motherboard: XServe G5 [ +0.00] boot stdout isn't a display ! [ +0.00] DART IOMMU initialized for U3 type chipset [ +0.00] bootconsole [udbg0] enabled [ +0.00] CPU maps initialized for 1 thread per core [ +0.00] (thread shift is 0) [ +0.00] Freed 65536 bytes for unused pacas [ +0.00] Starting Linux PPC64 #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) [ +0.00] - [ +0.00] ppc64_pft_size= 0x0 [ +0.00] physicalMemorySize= 0x1 [ +0.00] htab_address = 0xc0017c00 [ +0.00] htab_hash_mask= 0x7 [ +0.00] - [ +0.00] Initializing cgroup subsys cpuset [ +0.00] Initializing cgroup subsys cpu [ +0.00] Initializing cgroup subsys cpuacct [ +0.00] Linux version 3.16.0-4-powerpc64 (debian-ker...@lists.debian.org) (gcc version 4.8.4 (Debian 4.8.4-1) ) #1 SMP Debian 3.16.7-ckt11-1+deb8u3 (2015-08-04) [ +0.00] [boot]0012 Setup Arch [ +0.00] Top of RAM: 0x18000, Total RAM: 0x1 [ +0.00] Memory hole size: 2048MB [ +0.00] Found U3-AGP PCI host bridge. Firmware bus number: 240->255 [ +0.00] PCI host bridge /pci@0,f000 ranges: [ +0.00] MEM 0xf100..0xf1ff -> 0xf100 [ +0.00] IO 0xf000..0xf07f -> 0x [ +0.00] MEM 0xa000..0xafff -> 0xa000 [ +0.00] Can't get bus-range for /ht@0,f200, assume bus 0 [ +0.00] Found U3-HT PCI host bridge. Firmware bus number: 0->239 [ +0.00] PCI host bridge /ht@0,f200 (primary) ranges: [ +0.00] via-pmu: Server Mode is enabled [ +0.00] PMU driver v2 initialized for Core99, firmware: 0c [ +0.00] nvram: Checking bank 0... [ +0.00] nvram: gen0=58, gen1=59 [ +0.00] nvram: Active bank is: 1 [ +0.00] nvram: OF partition at 0x410 [ +0.00] nvram: XP partition at 0x1020 [ +0.00] nvram: NR partition at 0x1120 [ +0.00] Zone ranges: [ +0.00] DMA [mem 0x-0x17fff] [ +0.00] Normal empty [ +0.00] Movable zone start for each node [ +0.00] Early memory node ranges [ +0.00] node 0: [mem 0x-0x7fff] [ +0.00] node 0: [mem 0x1-0x17fff] [ +0.00] On node 0 totalpages: 65536 [ +0.00] DMA zone: 56 pages used for memmap [ +0.00] DMA zone: 0 pages reserved [ +0.00] DMA zone: 65536 pages, LIFO batch:1 [ +0.00] [boot]0015 Setup Done [ +0.00] PERCPU: Embedded 2 pages/cpu @c2e0 s101120 r0 d29952 u524288 [ +0.00] pcpu-alloc: s101120 r0 d29952 u524288 alloc=1*1048576 [ +0.00] pcpu-alloc: [0] 0 1 [ +0.00] Built 1 zonelists in Node order, mobility grouping on. Total pages: 65480 [ +0.00] Policy zone: DMA [ +0.00] Kernel command line: root=/dev/mapper/edi_volumes-edi_root ro console=ttyPZ0,57600n8 [ +0.00] PID hash table entries: 4096 (order: -1, 32768 bytes) [ +0.00] Sorting __ex_table... [ +0.00] Memory: 3799296K/4194304K available (7360K kernel code, 1792K rwdata, 1840K rodata, 960K init, 2071K bss, 395008K reserved) [ +0.00] Hierarchical RCU implementation. [ +0.00] CONFIG_RCU_FANOUT set to non-default value of 32 [ +0.00] RCU dyntick-idle grace-period acceleration is enabled. [ +0.00] RCU restricting CPUs from NR_CPUS=32 to nr_cpu_ids=2. [ +0.
Re: [Qemu-devel] [PATCH 19/23] userfaultfd: activate syscall
On Wed, 2015-08-12 at 10:53 +0530, Bharata B Rao wrote: > On Tue, Aug 11, 2015 at 03:48:26PM +0200, Andrea Arcangeli wrote: > > Hello Bharata, > > > > On Tue, Aug 11, 2015 at 03:37:29PM +0530, Bharata B Rao wrote: > > > May be it is a bit late to bring this up, but I needed the following fix > > > to userfault21 branch of your git tree to compile on powerpc. > > > > Not late, just in time. I increased the number of syscalls in earlier > > versions, it must have gotten lost during a rejecting rebase, sorry. > > > > I applied it to my tree and it can be applied to -mm and linux-next, > > thanks! > > > > The syscall for arm32 are also ready and on their way to the arm tree, > > the testsuite worked fine there. ppc also should work fine if you > > could confirm it'd be interesting, just beware that I got a typo in > > the testcase: > > The testsuite passes on powerpc. > > > running userfaultfd > > nr_pages: 2040, nr_pages_per_cpu: 170 > bounces: 31, mode: rnd racing ver poll, userfaults: 80 43 23 23 15 16 12 1 2 > 96 13 128 > bounces: 30, mode: racing ver poll, userfaults: 35 54 62 49 47 48 2 8 0 78 1 0 > bounces: 29, mode: rnd ver poll, userfaults: 114 153 70 106 78 57 143 92 114 > 96 1 0 > bounces: 28, mode: ver poll, userfaults: 96 81 5 45 83 19 98 28 1 145 23 2 > bounces: 27, mode: rnd racing poll, userfaults: 54 65 60 54 45 49 1 2 1 2 71 > 20 > bounces: 26, mode: racing poll, userfaults: 90 83 35 29 37 35 30 42 3 4 49 6 > bounces: 25, mode: rnd poll, userfaults: 52 50 178 112 51 41 23 42 18 99 59 0 > bounces: 24, mode: poll, userfaults: 136 101 83 260 84 29 16 88 1 6 160 57 > bounces: 23, mode: rnd racing ver, userfaults: 141 197 158 183 39 49 3 52 8 3 > 6 0 > bounces: 22, mode: racing ver, userfaults: 242 266 244 180 162 32 87 43 31 40 > 34 0 > bounces: 21, mode: rnd ver, userfaults: 636 158 175 24 253 104 48 8 0 0 0 0 > bounces: 20, mode: ver, userfaults: 531 204 225 117 129 107 11 143 76 31 1 0 > bounces: 19, mode: rnd racing, userfaults: 303 169 225 145 59 219 37 0 0 0 0 0 > bounces: 18, mode: racing, userfaults: 374 372 37 144 126 90 25 12 15 17 0 0 > bounces: 17, mode: rnd, userfaults: 313 412 134 108 80 99 7 56 85 0 0 0 > bounces: 16, mode:, userfaults: 431 58 87 167 120 113 98 60 14 8 48 0 > bounces: 15, mode: rnd racing ver poll, userfaults: 41 40 25 28 37 24 0 0 0 0 > 180 75 > bounces: 14, mode: racing ver poll, userfaults: 43 53 30 28 25 15 19 0 0 0 0 > 30 > bounces: 13, mode: rnd ver poll, userfaults: 136 91 114 91 92 79 114 77 75 68 > 1 2 > bounces: 12, mode: ver poll, userfaults: 92 120 114 76 153 75 132 157 83 81 > 10 1 > bounces: 11, mode: rnd racing poll, userfaults: 50 72 69 52 53 48 46 59 57 51 > 37 1 > bounces: 10, mode: racing poll, userfaults: 33 49 38 68 35 63 57 49 49 47 25 > 10 > bounces: 9, mode: rnd poll, userfaults: 167 150 67 123 39 75 1 2 9 125 1 1 > bounces: 8, mode: poll, userfaults: 147 102 20 87 5 27 118 14 104 40 21 28 > bounces: 7, mode: rnd racing ver, userfaults: 305 254 208 74 59 96 36 14 11 7 > 4 5 > bounces: 6, mode: racing ver, userfaults: 290 114 191 94 162 114 34 6 6 32 23 > 2 > bounces: 5, mode: rnd ver, userfaults: 370 381 22 273 21 106 17 55 0 0 0 0 > bounces: 4, mode: ver, userfaults: 328 279 179 191 74 86 95 15 13 10 0 0 > bounces: 3, mode: rnd racing, userfaults: 222 215 164 70 5 20 179 0 34 3 0 0 > bounces: 2, mode: racing, userfaults: 316 385 112 160 225 5 30 49 42 2 4 0 > bounces: 1, mode: rnd, userfaults: 273 139 253 176 163 71 85 2 0 0 0 0 > bounces: 0, mode:, userfaults: 165 212 633 13 24 66 24 27 15 0 10 1 > [PASS] Hmm, not for me. See below. What setup were you testing on Bharata? Mine is: $ uname -a Linux lebuntu 4.2.0-09705-g3a166acc1432 #2 SMP Tue Sep 8 15:18:00 AEST 2015 ppc64le ppc64le ppc64le GNU/Linux Which is 7d9071a09502 plus a couple of powerpc patches. $ zgrep USERFAULTFD /proc/config.gz CONFIG_USERFAULTFD=y $ sudo ./userfaultfd 128 32 nr_pages: 2048, nr_pages_per_cpu: 128 bounces: 31, mode: rnd racing ver poll, error mutex 2 2 error mutex 2 10 error mutex 2 15 error mutex 2 21 error mutex 2 22 error mutex 2 27 error mutex 2 36 error mutex 2 39 error mutex 2 40 error mutex 2 41 error mutex 2 43 error mutex 2 75 error mutex 2 79 error mutex 2 83 error mutex 2 100 error mutex 2 108 error mutex 2 110 error mutex 2 114 error mutex 2 119 error mutex 2 120 error mutex 2 135 error mutex 2 137 error mutex 2 141 error mutex 2 142 error mutex 2 144 error mutex 2 145 error mutex 2 150 error mutex 2 151 error mutex 2 159 error mutex 2 161 error mutex 2 169 error mutex 2 172 error mutex 2 174 error mutex 2 175 error mutex 2 176 error mutex 2 178 error mutex 2 188 error mutex 2 194 error mutex 2 208 error mutex 2 210 error mutex 2 212 error mutex 2 220 error mutex 2 223 error mutex 2 224 error mutex 2 226 error mutex 2 236 error mutex 2 249 error mutex 2 252 error mutex 2 255 error mutex 2 256 error mutex 2 267 error mutex 2 277 error mutex 2 284 error mutex 2 295 error mutex 2 302 e
Re: [Qemu-devel] [PATCH 19/23] userfaultfd: activate syscall
On Tue, Sep 08, 2015 at 04:08:06PM +1000, Michael Ellerman wrote: > On Wed, 2015-08-12 at 10:53 +0530, Bharata B Rao wrote: > > On Tue, Aug 11, 2015 at 03:48:26PM +0200, Andrea Arcangeli wrote: > > > Hello Bharata, > > > > > > On Tue, Aug 11, 2015 at 03:37:29PM +0530, Bharata B Rao wrote: > > > > May be it is a bit late to bring this up, but I needed the following fix > > > > to userfault21 branch of your git tree to compile on powerpc. > > > > > > Not late, just in time. I increased the number of syscalls in earlier > > > versions, it must have gotten lost during a rejecting rebase, sorry. > > > > > > I applied it to my tree and it can be applied to -mm and linux-next, > > > thanks! > > > > > > The syscall for arm32 are also ready and on their way to the arm tree, > > > the testsuite worked fine there. ppc also should work fine if you > > > could confirm it'd be interesting, just beware that I got a typo in > > > the testcase: > > > > The testsuite passes on powerpc. > > > > > > running userfaultfd > > > > nr_pages: 2040, nr_pages_per_cpu: 170 > > bounces: 31, mode: rnd racing ver poll, userfaults: 80 43 23 23 15 16 12 1 > > 2 96 13 128 > > bounces: 30, mode: racing ver poll, userfaults: 35 54 62 49 47 48 2 8 0 78 > > 1 0 > > bounces: 29, mode: rnd ver poll, userfaults: 114 153 70 106 78 57 143 92 > > 114 96 1 0 > > bounces: 28, mode: ver poll, userfaults: 96 81 5 45 83 19 98 28 1 145 23 2 > > bounces: 27, mode: rnd racing poll, userfaults: 54 65 60 54 45 49 1 2 1 2 > > 71 20 > > bounces: 26, mode: racing poll, userfaults: 90 83 35 29 37 35 30 42 3 4 49 6 > > bounces: 25, mode: rnd poll, userfaults: 52 50 178 112 51 41 23 42 18 99 59 > > 0 > > bounces: 24, mode: poll, userfaults: 136 101 83 260 84 29 16 88 1 6 160 57 > > bounces: 23, mode: rnd racing ver, userfaults: 141 197 158 183 39 49 3 52 8 > > 3 6 0 > > bounces: 22, mode: racing ver, userfaults: 242 266 244 180 162 32 87 43 31 > > 40 34 0 > > bounces: 21, mode: rnd ver, userfaults: 636 158 175 24 253 104 48 8 0 0 0 0 > > bounces: 20, mode: ver, userfaults: 531 204 225 117 129 107 11 143 76 31 1 0 > > bounces: 19, mode: rnd racing, userfaults: 303 169 225 145 59 219 37 0 0 0 > > 0 0 > > bounces: 18, mode: racing, userfaults: 374 372 37 144 126 90 25 12 15 17 0 0 > > bounces: 17, mode: rnd, userfaults: 313 412 134 108 80 99 7 56 85 0 0 0 > > bounces: 16, mode:, userfaults: 431 58 87 167 120 113 98 60 14 8 48 0 > > bounces: 15, mode: rnd racing ver poll, userfaults: 41 40 25 28 37 24 0 0 0 > > 0 180 75 > > bounces: 14, mode: racing ver poll, userfaults: 43 53 30 28 25 15 19 0 0 0 > > 0 30 > > bounces: 13, mode: rnd ver poll, userfaults: 136 91 114 91 92 79 114 77 75 > > 68 1 2 > > bounces: 12, mode: ver poll, userfaults: 92 120 114 76 153 75 132 157 83 81 > > 10 1 > > bounces: 11, mode: rnd racing poll, userfaults: 50 72 69 52 53 48 46 59 57 > > 51 37 1 > > bounces: 10, mode: racing poll, userfaults: 33 49 38 68 35 63 57 49 49 47 > > 25 10 > > bounces: 9, mode: rnd poll, userfaults: 167 150 67 123 39 75 1 2 9 125 1 1 > > bounces: 8, mode: poll, userfaults: 147 102 20 87 5 27 118 14 104 40 21 28 > > bounces: 7, mode: rnd racing ver, userfaults: 305 254 208 74 59 96 36 14 11 > > 7 4 5 > > bounces: 6, mode: racing ver, userfaults: 290 114 191 94 162 114 34 6 6 32 > > 23 2 > > bounces: 5, mode: rnd ver, userfaults: 370 381 22 273 21 106 17 55 0 0 0 0 > > bounces: 4, mode: ver, userfaults: 328 279 179 191 74 86 95 15 13 10 0 0 > > bounces: 3, mode: rnd racing, userfaults: 222 215 164 70 5 20 179 0 34 3 0 0 > > bounces: 2, mode: racing, userfaults: 316 385 112 160 225 5 30 49 42 2 4 0 > > bounces: 1, mode: rnd, userfaults: 273 139 253 176 163 71 85 2 0 0 0 0 > > bounces: 0, mode:, userfaults: 165 212 633 13 24 66 24 27 15 0 10 1 > > [PASS] > > Hmm, not for me. See below. > > What setup were you testing on Bharata? I was on commit a94572f5799dd of userfault21 branch in Andrea's tree git://git.kernel.org/pub/scm/linux/kernel/git/andrea/aa.git #uname -a Linux 4.1.0-rc8+ #1 SMP Tue Aug 11 11:33:50 IST 2015 ppc64le ppc64le ppc64le GNU/Linux In fact I had successfully done postcopy migration of sPAPR guest with this setup. > > Mine is: > > $ uname -a > Linux lebuntu 4.2.0-09705-g3a166acc1432 #2 SMP Tue Sep 8 15:18:00 AEST 2015 > ppc64le ppc64le ppc64le GNU/Linux > > Which is 7d9071a09502 plus a couple of powerpc patches. > > $ zgrep USERFAULTFD /proc/config.gz > CONFIG_USERFAULTFD=y > > $ sudo ./userfaultfd 128 32 > nr_pages: 2048, nr_pages_per_cpu: 128 > bounces: 31, mode: rnd racing ver poll, error mutex 2 2 > error mutex 2 10 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
