* Re: [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Russell King - ARM Linux @ 2016-11-14 18:41 UTC (permalink / raw)
To: Steven Rostedt
Cc: Stephen Boyd, linux-kernel, linux-arm-kernel, Andrew Morton
In-Reply-To: <20161114133641.09b1abfb@gandalf.local.home>
On Mon, Nov 14, 2016 at 01:36:41PM -0500, Steven Rostedt wrote:
> On Tue, 18 Oct 2016 20:07:07 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Tue, 18 Oct 2016 16:42:00 -0700
> > Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > > In similar spirit to x86 and arm64 support, add a make_nop_arm()
> > > to replace calls to mcount with a nop in sections that aren't
> > > traced.
> > >
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Acked-by: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > I can take this if I can get an ack from the ARM maintainers.
>
> Any ARM maintainer want to ack this, or take it in their tree if they
> haven't already?
Assuming it's been tested:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH/RESEND] recordmcount: arm: Implement make_nop
From: Russell King - ARM Linux @ 2016-11-14 18:41 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114133641.09b1abfb@gandalf.local.home>
On Mon, Nov 14, 2016 at 01:36:41PM -0500, Steven Rostedt wrote:
> On Tue, 18 Oct 2016 20:07:07 -0400
> Steven Rostedt <rostedt@goodmis.org> wrote:
>
> > On Tue, 18 Oct 2016 16:42:00 -0700
> > Stephen Boyd <sboyd@codeaurora.org> wrote:
> >
> > > In similar spirit to x86 and arm64 support, add a make_nop_arm()
> > > to replace calls to mcount with a nop in sections that aren't
> > > traced.
> > >
> > > Cc: Russell King <linux@arm.linux.org.uk>
> > > Acked-by: Rabin Vincent <rabin@rab.in>
> > > Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
> >
> > I can take this if I can get an ack from the ARM maintainers.
>
> Any ARM maintainer want to ack this, or take it in their tree if they
> haven't already?
Assuming it's been tested:
Acked-by: Russell King <rmk+kernel@armlinux.org.uk>
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* Re: [PATCH] sparc64: fix compile warning section mismatch in find_node()
From: David Miller @ 2016-11-14 18:40 UTC (permalink / raw)
To: sparclinux
In-Reply-To: <1478911260-108261-1-git-send-email-thomas.tai@oracle.com>
From: Thomas Tai <thomas.tai@oracle.com>
Date: Fri, 11 Nov 2016 16:41:00 -0800
> A compile warning is introduced by a commit to fix the find_node().
> This patch fix the compile warning by moving find_node() into __init
> section. Because find_node() is only used by memblock_nid_range() which
> is only used by a __init add_node_ranges(). find_node() and
> memblock_nid_range() should also be inside __init section.
>
> Signed-off-by: Thomas Tai <thomas.tai@oracle.com>
Applied, thank you.
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Stephen Boyd @ 2016-11-14 18:40 UTC (permalink / raw)
To: Srinivas Kandagatla, Lee Jones
Cc: bjorn.andersson, Rob Herring, Andy Gross, devicetree,
linux-kernel, linux-arm-msm, linux-soc, linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..dc347d3 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
Hm? vi?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Stephen Boyd @ 2016-11-14 18:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla@linaro.org>
On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..dc347d3 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
Hm? vi?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
^ permalink raw reply
* Re: [PATCH v2 1/2] mfd: pm8xxx: add support to pm8821
From: Stephen Boyd @ 2016-11-14 18:40 UTC (permalink / raw)
To: Srinivas Kandagatla, Lee Jones
Cc: bjorn.andersson-QSEj5FYQhm4dnm+yROfE0A, Rob Herring, Andy Gross,
devicetree-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-msm-u79uwXL29TY76Z2rM5mHXA,
linux-soc-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <1479145933-9849-1-git-send-email-srinivas.kandagatla-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
On 11/14/2016 09:52 AM, Srinivas Kandagatla wrote:
> diff --git a/drivers/mfd/qcom-pm8xxx.c b/drivers/mfd/qcom-pm8xxx.c
> index 7f9620e..dc347d3 100644
> --- a/drivers/mfd/qcom-pm8xxx.c
> +++ b/drivers/mfd/qcom-pm8xxx.c
> +
> +static void pm8821_irq_handler(struct irq_desc *desc)
> +{
> + struct pm_irq_chip *chip = irq_desc_get_handler_data(desc);
> + struct irq_chip *irq_chip = irq_desc_get_chip(desc);
> + unsigned int master;
> + int ret;
> +
> + chained_irq_enter(irq_chip, desc);
> + ret = regmap_read(chip->regmap,
> + PM8821_SSBI_REG_ADDR_IRQ_MASTER0, &master);
> + if (ret) {
> + pr_err("Failed to re:Qad master 0 ret=%d\n", ret);
Hm? vi?
--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
a Linux Foundation Collaborative Project
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: CLOSE/OPEN race
From: Benjamin Coddington @ 2016-11-14 18:40 UTC (permalink / raw)
To: Trond Myklebust; +Cc: jlayton@redhat.com, linux-nfs@vger.kernel.org
In-Reply-To: <1479140976.5653.3.camel@primarydata.com>
T24gMTQgTm92IDIwMTYsIGF0IDExOjI5LCBUcm9uZCBNeWtsZWJ1c3Qgd3JvdGU6Cj4KPiBQbGVh
c2Ugc2VlIHRoZSAyIHBhdGNoZXMgSSBqdXN0IHBvc3RlZC4gVGhleSBzaG91bGQgZml4IHRoZSAK
PiBwcm9ibGVtLk7Ci8KnwrLDpsOscsK4wpt5w7rDqMKaw5hiwrJYwqzCtsOHwqd2w5hewpYpw57C
unsubsOHK8KJwrfCpcKKe8Kxwp3DuyLCnsOYXm7Ch3LCocO2wqZ6w4sawoHDq2jCmcKow6jCrcOa
JsKiw7gewq5HwqvCncOpaMKuAyjCrcOpwprCjsKKw53Comoiwp3DuhrCthttwqfDv8OvwoHDqsOk
esK5w57ClsKKw6DDvmbCo8KiwrdowprCiMKnfsKIbcKaCgpTZWVtcyBsaWtlIHRoZXkgZG8uICBU
aGFua3MhICBJJ2xsIGxlYXZlIHRoZW0gc3Bpbm5pbmcgaW4gdGhhdCB0ZXN0Cm92ZXJuaWdodCB0
byByZWFsbHkgZ2l2ZSB0aGVtIGEgd29ya291dC4KCkJlbgo=
^ permalink raw reply
* Re: Buildbot / Autobuilder / custom?
From: Bill Randle @ 2016-11-14 18:40 UTC (permalink / raw)
To: Alain Achkar; +Cc: joshua.g.lock, yocto
In-Reply-To: <CAGkf0HDBfdSNXO08PBRvV1+D=wYzWpBi==FnuNocLD3Ee9A7zw@mail.gmail.com>
Yes, the 2 TB is for everything you might do with an AutoBuilder. The
actual space used will be closer to your 35 GB, since you're building
only a single image / work product. People have used BuilBot directly
for automated builds, but using the AutoBuilder code (which runs
BuildBot underneath) gives you added flexibility and capability
without much additional overhead.
-Bill
On Mon, Nov 14, 2016 at 8:13 AM, Alain Achkar <alain.achkar@triacta.com> wrote:
> Thanks for your answers! From reading these links, it is still not clear to
> me if this might be overkill for my requirements. AB Cluster Setup talks
> about "the worker requires 2+ TB to hold all the build temp files and git
> repos. If build artifacts and a local sstate mirror are included, additional
> worker space is required."
>
> Currently, my build only takes 35GB, so I think what these links are talking
> about is how to replicate what the Autobuilder project
> https://autobuilder.yoctoproject.org/ already does.
>
> To clarify, I am not interested in running builds and tests for everything
> that Yocto already builds and tests (i.e. all the processor architectures,
> all the machine types, etc.). I am interested in running one build for one
> machine type (the Variscite DART-6UL i.MX6UL arm-based processor, for which
> NXP/Freescale and Variscite have provided recipes and layers for).
>
> I know that autobuilder includes BuildBot (this is why I specified it in
> parentheses) but my question remains: do I only install BuildBot and try to
> build my machine type with it, or do I install Autobuilder?
>
> On Mon, Nov 14, 2016 at 10:10 AM, Bill Randle <bill.randle@gmail.com> wrote:
>>
>> Also, be sure to check the Yocto Project wiki pages:
>> https://wiki.yoctoproject.org/wiki/The_Yocto_Autobuilder
>> in particular, the AB cluster setup and AB maintenance links. Even
>> though the one link refers to setting up an entire cluster, I've used
>> that procedure to setup a single autobuilder, as well.
>>
>> -Bill
>>
>> On Fri, Nov 11, 2016 at 10:37 AM, Beth 'pidge' Flanagan
>> <pidge@toganlabs.com> wrote:
>> > On Fri, 2016-11-11 at 12:35 -0500, Alain Achkar wrote:
>> >> Hello Joshua!
>> >>
>> >> We are using Yocto to build for the Variscite DART-6UL SoM which is
>> >> based on Freescale/NXP i.MX6UL (http://variwiki.com/index.php?title=D
>> >> ART-6UL_Yocto_Jethro_R1_build).
>> >>
>> >> Currently, developers run builds manually on their desktops. We are
>> >> considering using a continuous integration server. I found out that
>> >> The Yocto Project uses Autobuilder which in turn uses BuildBot. I
>> >> read most of the introductory documentation.
>> >>
>> >> Would you recommend that we install only BuildBot and configure it to
>> >> build what we need?
>> >>
>> >> OR
>> >>
>> >> Would you recommend that we install Autobuilder (and BuildBot) and
>> >> configure it to build what we need?
>> >
>> > Actually, the yocto-autobuilder already contains buildbot so no need
>> > for both.
>> >
>> > If you read:
>> >
>> > http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder/tree/README-QUIC
>> > KSTART
>> >
>> > and probably some of the other READMEs and the documentation in the
>> > docs directory of the yocto-autobuilder directory, it should get you
>> > started in the right direction.
>> >
>> > Feel free to ask questions if you need help.
>> >
>> > -b
>> >
>> > Elizabeth 'pidge' Flanagan
>> > Founder/CTO Togán Labs
>> > www.toganlabs.com
>> >
>> >>
>> >> What is the faster path to get up and running?
>> >>
>> >> Thanks!
>> >> Alain.
>> >>
>> >> --
>> >> Alain Achkar, M.Eng. | Software Engineer
>> >> Triacta Power Solutions
>> >> (O) 613.256.2868 (C) 613.406.6520
>> >> www.triacta.com
>> >
>> >
>> >
>> > --
>> > _______________________________________________
>> > yocto mailing list
>> > yocto@yoctoproject.org
>> > https://lists.yoctoproject.org/listinfo/yocto
>
>
>
>
> --
>
> Alain Achkar, M.Eng. | Software Engineer
>
> Triacta Power Solutions
>
> (O) 613.256.2868 (C) 613.406.6520
>
> www.triacta.com
^ permalink raw reply
* Re: Xen like VirtualBox
From: Dario Faggioli @ 2016-11-14 18:40 UTC (permalink / raw)
To: Jason Long, Xen-devel@lists.xen.org
In-Reply-To: <456833396.3707141.1479132318277@mail.yahoo.com>
[-- Attachment #1.1: Type: text/plain, Size: 1545 bytes --]
On Mon, 2016-11-14 at 14:05 +0000, Jason Long wrote:
> Thank you but the problem is that "virt-manager" is for Redhat and
> Redhat don't like Xen anymore because of KVM.
>
That's not really accurate. Virt-manager is --at least last time I've
tried, which is not too long ago-- a GUI front-end for libvirt.
It is may be true that a lot of its contributors works for or are
related to RedHat, and it is probably still true that it does its best
with KVM... But it actually works with Xen already (it, at least up to
a certain extent, should work with whatever uses libvirt).
In fact, if you go to https://virt-manager.org/ , this is what you
find:
"The virt-manager application is a desktop user interface for managing
virtual machines through libvirt. It primarily targets KVM VMs, but
also manages Xen and LXC (linux containers)."
It could be made a lot better, when used on Xen, but that will only
happen with some effort, and helping us assessing what does work and
what does not, would be a very valuable contribution.
> Another problem is that a program like VirtualBox has a nice GUI but
> virt-manager not.
>
Mmm.. so, you're saying that you like VirtualBox's GUI but you don't
like virt-manager's one, right? In which case, oh, well...
Dario
--
<<This happens because I choose it to happen!>> (Raistlin Majere)
-----------------------------------------------------------------
Dario Faggioli, Ph.D, http://about.me/dario.faggioli
Senior Software Engineer, Citrix Systems R&D Ltd., Cambridge (UK)
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 819 bytes --]
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v3] PCI: create revision file in sysfs
From: Daniel Vetter @ 2016-11-14 18:40 UTC (permalink / raw)
To: Emil Velikov; +Cc: Bjorn Helgaas, linux-pci, dri-devel, Greg KH
In-Reply-To: <20161111143723.5818-1-emil.l.velikov@gmail.com>
On Fri, Nov 11, 2016 at 02:37:23PM +0000, Emil Velikov wrote:
> From: Emil Velikov <emil.velikov@collabora.com>
>
> Currently the revision isn't available via sysfs/libudev thus if one
> wants to know the value they need to read through the config file.
>
> This in itself wakes/powers up the device, causing unwanted delay
> since it can be quite costly.
>
> There are at least two userspace components which could make use the new
> file libpciaccess and libdrm. The former [used in various places] wakes
> up _every_ PCI device, which can be observed via glxinfo [when using
> Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0]
> can lead to 2-3 second delays while starting firefox, thunderbird or
> chromium.
>
> Expose the revision as a separate file, just like we do for the device,
> vendor, their subsystem version and class.
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci@vger.kernel.org
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502
> Tested-by: Mauro Santos <registo.mailling@gmail.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Given that waking a gpu can take somewhere between ages and forever, and
that we read the pci revisions everytime we launch a new gl app I think
this is the correct approach. Of course we could just patch libdrm and
everyone to not look at the pci revision, but that just leads to every
pci-based driver having a driver-private ioctl/getparam thing to expose
it. Which also doesn't make much sense.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Björn, if you're all ok with this we'd like to start landing at least
libdrm patches before this patch hits a released kernel, just to shorten
the pain window for users waiting for upgrades.
Thanks, Daniel
> ---
> v2: Add r-b/t-b tags, slim down CC list, add note about userspace.
>
> v3: Add Documentation/ bits (Greg KH)
>
> Gents, please keep me in the CC list.
>
> Thanks
> Emil
> ---
> Documentation/ABI/testing/sysfs-bus-pci | 7 +++++++
> Documentation/filesystems/sysfs-pci.txt | 2 ++
> drivers/pci/pci-sysfs.c | 2 ++
> 3 files changed, 11 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
> index b3bc50f..5a1732b 100644
> --- a/Documentation/ABI/testing/sysfs-bus-pci
> +++ b/Documentation/ABI/testing/sysfs-bus-pci
> @@ -294,3 +294,10 @@ Description:
> a firmware bug to the system vendor. Writing to this file
> taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
> reduces the supportability of your system.
> +
> +What: /sys/bus/pci/devices/.../revision
> +Date: November 2016
> +Contact: Emil Velikov <emil.l.velikov@gmail.com>
> +Description:
> + This file contains the revision field of the the PCI device.
> + The value comes from device config space. The file is read only.
> diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
> index 74eaac2..6ea1ced 100644
> --- a/Documentation/filesystems/sysfs-pci.txt
> +++ b/Documentation/filesystems/sysfs-pci.txt
> @@ -17,6 +17,7 @@ that support it. For example, a given bus might look like this:
> | |-- resource0
> | |-- resource1
> | |-- resource2
> + | |-- revision
> | |-- rom
> | |-- subsystem_device
> | |-- subsystem_vendor
> @@ -41,6 +42,7 @@ files, each with their own function.
> resource PCI resource host addresses (ascii, ro)
> resource0..N PCI resource N, if present (binary, mmap, rw[1])
> resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap)
> + revision PCI revision (ascii, ro)
> rom PCI ROM resource, if present (binary, ro)
> subsystem_device PCI subsystem device (ascii, ro)
> subsystem_vendor PCI subsystem vendor (ascii, ro)
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index bcd10c7..0666287 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -50,6 +50,7 @@ pci_config_attr(vendor, "0x%04x\n");
> pci_config_attr(device, "0x%04x\n");
> pci_config_attr(subsystem_vendor, "0x%04x\n");
> pci_config_attr(subsystem_device, "0x%04x\n");
> +pci_config_attr(revision, "0x%02x\n");
> pci_config_attr(class, "0x%06x\n");
> pci_config_attr(irq, "%u\n");
>
> @@ -568,6 +569,7 @@ static struct attribute *pci_dev_attrs[] = {
> &dev_attr_device.attr,
> &dev_attr_subsystem_vendor.attr,
> &dev_attr_subsystem_device.attr,
> + &dev_attr_revision.attr,
> &dev_attr_class.attr,
> &dev_attr_irq.attr,
> &dev_attr_local_cpus.attr,
> --
> 2.9.3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH v3] PCI: create revision file in sysfs
From: Daniel Vetter @ 2016-11-14 18:40 UTC (permalink / raw)
To: Emil Velikov; +Cc: dri-devel, Bjorn Helgaas, linux-pci, Greg KH
In-Reply-To: <20161111143723.5818-1-emil.l.velikov@gmail.com>
On Fri, Nov 11, 2016 at 02:37:23PM +0000, Emil Velikov wrote:
> From: Emil Velikov <emil.velikov@collabora.com>
>
> Currently the revision isn't available via sysfs/libudev thus if one
> wants to know the value they need to read through the config file.
>
> This in itself wakes/powers up the device, causing unwanted delay
> since it can be quite costly.
>
> There are at least two userspace components which could make use the new
> file libpciaccess and libdrm. The former [used in various places] wakes
> up _every_ PCI device, which can be observed via glxinfo [when using
> Mesa 10.0+ drivers]. While the latter [in association with Mesa 13.0]
> can lead to 2-3 second delays while starting firefox, thunderbird or
> chromium.
>
> Expose the revision as a separate file, just like we do for the device,
> vendor, their subsystem version and class.
>
> Cc: Bjorn Helgaas <bhelgaas@google.com>
> Cc: linux-pci@vger.kernel.org
> Cc: Greg KH <gregkh@linuxfoundation.org>
> Link: https://bugs.freedesktop.org/show_bug.cgi?id=98502
> Tested-by: Mauro Santos <registo.mailling@gmail.com>
> Reviewed-by: Alex Deucher <alexander.deucher@amd.com>
> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Given that waking a gpu can take somewhere between ages and forever, and
that we read the pci revisions everytime we launch a new gl app I think
this is the correct approach. Of course we could just patch libdrm and
everyone to not look at the pci revision, but that just leads to every
pci-based driver having a driver-private ioctl/getparam thing to expose
it. Which also doesn't make much sense.
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Björn, if you're all ok with this we'd like to start landing at least
libdrm patches before this patch hits a released kernel, just to shorten
the pain window for users waiting for upgrades.
Thanks, Daniel
> ---
> v2: Add r-b/t-b tags, slim down CC list, add note about userspace.
>
> v3: Add Documentation/ bits (Greg KH)
>
> Gents, please keep me in the CC list.
>
> Thanks
> Emil
> ---
> Documentation/ABI/testing/sysfs-bus-pci | 7 +++++++
> Documentation/filesystems/sysfs-pci.txt | 2 ++
> drivers/pci/pci-sysfs.c | 2 ++
> 3 files changed, 11 insertions(+)
>
> diff --git a/Documentation/ABI/testing/sysfs-bus-pci b/Documentation/ABI/testing/sysfs-bus-pci
> index b3bc50f..5a1732b 100644
> --- a/Documentation/ABI/testing/sysfs-bus-pci
> +++ b/Documentation/ABI/testing/sysfs-bus-pci
> @@ -294,3 +294,10 @@ Description:
> a firmware bug to the system vendor. Writing to this file
> taints the kernel with TAINT_FIRMWARE_WORKAROUND, which
> reduces the supportability of your system.
> +
> +What: /sys/bus/pci/devices/.../revision
> +Date: November 2016
> +Contact: Emil Velikov <emil.l.velikov@gmail.com>
> +Description:
> + This file contains the revision field of the the PCI device.
> + The value comes from device config space. The file is read only.
> diff --git a/Documentation/filesystems/sysfs-pci.txt b/Documentation/filesystems/sysfs-pci.txt
> index 74eaac2..6ea1ced 100644
> --- a/Documentation/filesystems/sysfs-pci.txt
> +++ b/Documentation/filesystems/sysfs-pci.txt
> @@ -17,6 +17,7 @@ that support it. For example, a given bus might look like this:
> | |-- resource0
> | |-- resource1
> | |-- resource2
> + | |-- revision
> | |-- rom
> | |-- subsystem_device
> | |-- subsystem_vendor
> @@ -41,6 +42,7 @@ files, each with their own function.
> resource PCI resource host addresses (ascii, ro)
> resource0..N PCI resource N, if present (binary, mmap, rw[1])
> resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap)
> + revision PCI revision (ascii, ro)
> rom PCI ROM resource, if present (binary, ro)
> subsystem_device PCI subsystem device (ascii, ro)
> subsystem_vendor PCI subsystem vendor (ascii, ro)
> diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
> index bcd10c7..0666287 100644
> --- a/drivers/pci/pci-sysfs.c
> +++ b/drivers/pci/pci-sysfs.c
> @@ -50,6 +50,7 @@ pci_config_attr(vendor, "0x%04x\n");
> pci_config_attr(device, "0x%04x\n");
> pci_config_attr(subsystem_vendor, "0x%04x\n");
> pci_config_attr(subsystem_device, "0x%04x\n");
> +pci_config_attr(revision, "0x%02x\n");
> pci_config_attr(class, "0x%06x\n");
> pci_config_attr(irq, "%u\n");
>
> @@ -568,6 +569,7 @@ static struct attribute *pci_dev_attrs[] = {
> &dev_attr_device.attr,
> &dev_attr_subsystem_vendor.attr,
> &dev_attr_subsystem_device.attr,
> + &dev_attr_revision.attr,
> &dev_attr_class.attr,
> &dev_attr_irq.attr,
> &dev_attr_local_cpus.attr,
> --
> 2.9.3
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [PATCH v6] media: et8ek8: add device tree binding documentation
From: Rob Herring @ 2016-11-14 18:39 UTC (permalink / raw)
To: Pavel Machek
Cc: Ivaylo Dimitrov, Sakari Ailus, Sebastian Reichel, Pali Rohár,
linux-media@vger.kernel.org, Pawel Moll, Mark Rutland,
Ian Campbell, Kumar Gala, Mauro Carvalho Chehab,
devicetree@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <20161114183040.GB28778@amd>
On Mon, Nov 14, 2016 at 12:30 PM, Pavel Machek <pavel@ucw.cz> wrote:
> Add device tree binding documentation for toshiba et8ek8 sensor.
>
> Signed-off-by: Ivaylo Dimitrov <ivo.g.dimitrov.75@gmail.com>
> Signed-off-by: Pavel Machek <pavel@ucw.cz>
Acked-by: Rob Herring <robh@kernel.org>
^ permalink raw reply
* Re: [PATCH tip/core/rcu 1/2] documentation: Present updated RCU guarantee
From: Paul E. McKenney @ 2016-11-14 18:39 UTC (permalink / raw)
To: Pranith Kumar
Cc: LKML, Ingo Molnar, Lai Jiangshan, Dipankar Sarma, Andrew Morton,
Mathieu Desnoyers, Josh Triplett, Thomas Gleixner, Peter Zijlstra,
Steven Rostedt, David Howells, Eric Dumazet, Darren Hart,
Frederic Weisbecker, Oleg Nesterov
In-Reply-To: <CAJhHMCBeaWzhHaFDfQJhLw9UT5JyqCqciZjJE-nJWNCPiPK+Bw@mail.gmail.com>
On Mon, Nov 14, 2016 at 11:57:46AM -0500, Pranith Kumar wrote:
> Hi Paul,
>
> On Mon, Nov 14, 2016 at 11:47 AM, Paul E. McKenney
> <paulmck@linux.vnet.ibm.com> wrote:
> > Recent memory-model work deduces the relationships of RCU read-side
> > critical sections and grace periods based on the relationships of
> > accesses within a critical section and accesses preceding and following
> > the grace period. This commit therefore adds this viewpoint.
> >
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > ---
> > .../RCU/Design/Requirements/Requirements.html | 25 +++++++++++++++++++++-
> > 1 file changed, 24 insertions(+), 1 deletion(-)
> >
> > diff --git a/Documentation/RCU/Design/Requirements/Requirements.html b/Documentation/RCU/Design/Requirements/Requirements.html
> > index a4d3838130e4..81b40cb83435 100644
> > --- a/Documentation/RCU/Design/Requirements/Requirements.html
> > +++ b/Documentation/RCU/Design/Requirements/Requirements.html
> > @@ -547,7 +547,7 @@ The <tt>rcu_access_pointer()</tt> on line 6 is similar to
> > It could reuse a value formerly fetched from this same pointer.
> > It could also fetch the pointer from <tt>gp</tt> in a byte-at-a-time
> > manner, resulting in <i>load tearing</i>, in turn resulting a bytewise
> > - mash-up of two distince pointer values.
> > + mash-up of two distinct pointer values.
> > It might even use value-speculation optimizations, where it makes
> > a wrong guess, but by the time it gets around to checking the
> > value, an update has changed the pointer to match the wrong guess.
> > @@ -659,6 +659,29 @@ systems with more than one CPU:
> > In other words, a given instance of <tt>synchronize_rcu()</tt>
> > can avoid waiting on a given RCU read-side critical section only
> > if it can prove that <tt>synchronize_rcu()</tt> started first.
> > +
> > + <p>
> > + A related question is “When <tt>rcu_read_lock()</tt>
> > + doesn't generate any code, why does it matter how it relates
> > + to a grace period?”
> > + The answer if that it is not the relationship of
>
> s/if/is?
Good catch, fixed!
Thanx, Paul
> > + <tt>rcu_read_lock()</tt> itself that is important, but rather
> > + the relationship of the code within the enclosed RCU read-side
> > + critical section to the code preceding and following the
> > + grace period.
> > + If we take this viewpoint, then a given RCU read-side critical
> > + section begins before a given grace period when some access
> > + preceding the grace period observes the effect of some access
> > + within the critical section, in which case none of the accesses
> > + within the critical section may observe the effects of any
> > + access following the grace period.
> > +
> > + <p>
> > + As of late 2016, mathematical models of RCU take this
> > + viewpoint, for example, see slides 62 and 63
> > + of the
> > + <a href="http://www2.rdrop.com/users/paulmck/scalability/paper/LinuxMM.2016.10.04c.LCE.pdf">2016 LinuxCon EU</a>
> > + presentation.
> > </font></td></tr>
> > <tr><td> </td></tr>
> > </table>
> > --
> > 2.5.2
> >
>
>
>
> --
> Pranith
>
^ permalink raw reply
* [GIT PULL] ARM: at91: dt for 4.10
From: Alexandre Belloni @ 2016-11-14 18:39 UTC (permalink / raw)
To: Arnd Bergmann, Olof Johansson, arm
Cc: Nicolas Ferre, linux-arm-kernel, linux-kernel
[-- Attachment #1: Type: text/plain, Size: 2615 bytes --]
Hi Arnd, Olof
at91 DT changes for 4.10, I don't expect much more this cycle.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.10-dt1
for you to fetch changes up to b662a9dd8a1a03e6e2d61e74d3e7a08400edefb7:
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek (2016-11-14 17:04:24 +0100)
----------------------------------------------------------------
DT changes for 4.10:
- Many additions for sama5d2
- few non urgent fixes for sam9260ek, sama5d4 and sama5d2
----------------------------------------------------------------
Alexandre Belloni (4):
ARM: dts: at91: sama5d4: use proper sckc compatible
ARM: dts: at91: sama5d2: use correct sckc compatible
ARM: dts: at91: sama5d2: Add secumod node
ARM: dts: at91: sama5d2: Add securam node
Cyrille Pitchen (1):
ARM: dts: at91: sama5d2: enable FIFOs for high-speed i2c controllers
Marek Vasut (1):
ARM: dts: at91: sama5d4: Add new MA5D4EVK manufacturer compat
Peter Rosin (1):
dt-bindings: usb: atmel: fix a couple of copy-paste style typos
Sudeep Holla (1):
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
Sylvain Rochet (1):
ARM: dts: at91: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
.../devicetree/bindings/usb/atmel-usb.txt | 10 ++---
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 +-
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 +-
arch/arm/boot/dts/at91rm9200.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260ek.dts | 4 +-
arch/arm/boot/dts/at91sam9261.dtsi | 4 +-
arch/arm/boot/dts/at91sam9263.dtsi | 4 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 4 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 4 +-
arch/arm/boot/dts/at91sam9rl.dtsi | 4 +-
arch/arm/boot/dts/at91sam9x5.dtsi | 4 +-
arch/arm/boot/dts/sama5d2.dtsi | 47 ++++++++++++----------
arch/arm/boot/dts/sama5d3.dtsi | 4 +-
arch/arm/boot/dts/sama5d4.dtsi | 31 +++-----------
15 files changed, 60 insertions(+), 76 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 801 bytes --]
^ permalink raw reply
* Re: [PATCH] ps3_gelic: fix spelling mistake in debug message
From: David Miller @ 2016-11-14 18:39 UTC (permalink / raw)
To: colin.king
Cc: benh, paulus, mpe, falakreyaz, christophe.jaillet, jarod, netdev,
linuxppc-dev, linux-kernel
In-Reply-To: <20161112172030.7583-1-colin.king@canonical.com>
From: Colin King <colin.king@canonical.com>
Date: Sat, 12 Nov 2016 17:20:30 +0000
> From: Colin Ian King <colin.king@canonical.com>
>
> Trivial fix to spelling mistake "unmached" to "unmatched" in
> debug message.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
Applied.
^ permalink raw reply
* [GIT PULL] ARM: at91: dt for 4.10
From: Alexandre Belloni @ 2016-11-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd, Olof
at91 DT changes for 4.10, I don't expect much more this cycle.
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/abelloni/linux.git tags/at91-ab-4.10-dt1
for you to fetch changes up to b662a9dd8a1a03e6e2d61e74d3e7a08400edefb7:
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek (2016-11-14 17:04:24 +0100)
----------------------------------------------------------------
DT changes for 4.10:
- Many additions for sama5d2
- few non urgent fixes for sam9260ek, sama5d4 and sama5d2
----------------------------------------------------------------
Alexandre Belloni (4):
ARM: dts: at91: sama5d4: use proper sckc compatible
ARM: dts: at91: sama5d2: use correct sckc compatible
ARM: dts: at91: sama5d2: Add secumod node
ARM: dts: at91: sama5d2: Add securam node
Cyrille Pitchen (1):
ARM: dts: at91: sama5d2: enable FIFOs for high-speed i2c controllers
Marek Vasut (1):
ARM: dts: at91: sama5d4: Add new MA5D4EVK manufacturer compat
Peter Rosin (1):
dt-bindings: usb: atmel: fix a couple of copy-paste style typos
Sudeep Holla (1):
ARM: dts: at91: replace gpio-key,wakeup with wakeup-source for sam9260ek
Sylvain Rochet (1):
ARM: dts: at91: fixes dbgu pinctrl, set pullup on rx, clear pullup on tx
.../devicetree/bindings/usb/atmel-usb.txt | 10 ++---
arch/arm/boot/dts/at91-sama5d4_ma5d4.dtsi | 4 +-
arch/arm/boot/dts/at91-sama5d4_ma5d4evk.dts | 4 +-
arch/arm/boot/dts/at91rm9200.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260.dtsi | 4 +-
arch/arm/boot/dts/at91sam9260ek.dts | 4 +-
arch/arm/boot/dts/at91sam9261.dtsi | 4 +-
arch/arm/boot/dts/at91sam9263.dtsi | 4 +-
arch/arm/boot/dts/at91sam9g45.dtsi | 4 +-
arch/arm/boot/dts/at91sam9n12.dtsi | 4 +-
arch/arm/boot/dts/at91sam9rl.dtsi | 4 +-
arch/arm/boot/dts/at91sam9x5.dtsi | 4 +-
arch/arm/boot/dts/sama5d2.dtsi | 47 ++++++++++++----------
arch/arm/boot/dts/sama5d3.dtsi | 4 +-
arch/arm/boot/dts/sama5d4.dtsi | 31 +++-----------
15 files changed, 60 insertions(+), 76 deletions(-)
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/26c4f372/attachment.sig>
^ permalink raw reply
* Re: [upstream-release] [PATCH 1/2] drivers: usb: phy: Add qoriq usb 3.0 phy driver support
From: Scott Wood @ 2016-11-14 16:07 UTC (permalink / raw)
To: Sriram Dash, linux-kernel@vger.kernel.org,
linux-usb@vger.kernel.org, devicetree@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
Cc: mark.rutland@arm.com, felipe.balbi@linux.intel.com,
mathias.nyman@intel.com, catalin.marinas@arm.com,
will.deacon@arm.com, kishon@ti.com, robh+dt@kernel.org,
stern@rowland.harvard.edu, Suresh Gupta,
gregkh@linuxfoundation.org, pku.leo@gmail.com
In-Reply-To: <1479101215-26954-2-git-send-email-sriram.dash@nxp.com>
On 11/13/2016 11:27 PM, Sriram Dash wrote:
> diff --git a/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> new file mode 100644
> index 0000000..d934c80
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/phy/phy-qoriq-usb3.txt
> @@ -0,0 +1,36 @@
> +Driver for Freescale USB 3.0 PHY
> +
> +Required properties:
> +
> +- compatible : fsl,qoriq-usb3-phy
This is a very vague compatible. Are there versioning registers within
this register block?
> +/* Parameter control */
> +#define USB3PRM1CR 0x000
> +#define USB3PRM1CR_VAL 0x27672b2a
> +
> +/*
> + * struct qoriq_usb3_phy - driver data for USB 3.0 PHY
> + * @dev: pointer to device instance of this platform device
> + * @param_ctrl: usb3 phy parameter control register base
> + * @phy_base: usb3 phy register memory base
> + * @has_erratum_flag: keeps track of erratum applicable on device
> + */
> +struct qoriq_usb3_phy {
> + struct device *dev;
> + void __iomem *param_ctrl;
> + void __iomem *phy_base;
> + u32 has_erratum_flag;
> +};
> +
> +static inline u32 qoriq_usb3_phy_readl(void __iomem *addr, u32 offset)
> +{
> + return __raw_readl(addr + offset);
> +}
> +
> +static inline void qoriq_usb3_phy_writel(void __iomem *addr, u32 offset,
> + u32 data)
> +{
> + __raw_writel(data, addr + offset);
> +}
Why raw? Besides missing barriers, this will cause the accesses to be
native-endian which is not correct.
> +/*
> + * Erratum A008751
> + * SCFG USB3PRM1CR has incorrect default value
> + * SCFG USB3PRM1CR reset value should be 32'h27672B2A instead of 32'h25E72B2A.
When documenting C code, can you stick with C-style numeric constants?
For that matter, just put the constant in the code instead of hiding it
in an overly-generically-named USB3PRM1CR_VAL and then you won't need to
redundantly state the value in a comment. Normally putting magic
numbers in symbolic constants is a good thing, but in this case it's not
actually describing anything and the number is of no meaning outside of
this one erratum workaround (it might even be a different value if
another chip has a similar erratum).
> + */
> +static void erratum_a008751(struct qoriq_usb3_phy *phy)
> +{
> + qoriq_usb3_phy_writel(phy->param_ctrl, USB3PRM1CR,
> + USB3PRM1CR_VAL);
> +}
> +
> +/*
> + * qoriq_usb3_phy_erratum - List of phy erratum
> + * @qoriq_phy_erratum - erratum application
> + * @compat - comapt string for erratum
> + */
> +
> +struct qoriq_usb3_phy_erratum {
> + void (*qoriq_phy_erratum)(struct qoriq_usb3_phy *phy);
> + char *compat;
> +};
> +
> +/* Erratum list */
> +struct qoriq_usb3_phy_erratum phy_erratum_tbl[] = {
> + {&erratum_a008751, "fsl,usb-erratum-a008751"},
> + /* Add init time erratum here */
> +};
This needs to be static.
Unnecessary & on the function pointer.
> +static int qoriq_usb3_phy_init(struct phy *x)
> +{
> + struct qoriq_usb3_phy *phy = phy_get_drvdata(x);
> + int i;
> +
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + if (phy->has_erratum_flag & 1 << i)
> + phy_erratum_tbl[i].qoriq_phy_erratum(phy);
> + return 0;
> +}
> +
> +static const struct phy_ops ops = {
> + .init = qoriq_usb3_phy_init,
> + .owner = THIS_MODULE,
> +};
> +
> +static int qoriq_usb3_phy_probe(struct platform_device *pdev)
> +{
> + struct qoriq_usb3_phy *phy;
> + struct phy *generic_phy;
> + struct phy_provider *phy_provider;
> + const struct of_device_id *of_id;
> + struct device *dev = &pdev->dev;
> + struct resource *res;
> + int i, ret;
> +
> + phy = devm_kzalloc(dev, sizeof(*phy), GFP_KERNEL);
> + if (!phy)
> + return -ENOMEM;
> + phy->dev = dev;
> +
> + of_id = of_match_device(dev->driver->of_match_table, dev);
> + if (!of_id) {
> + dev_err(dev, "failed to get device match\n");
> + ret = -EINVAL;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "param_ctrl");
> + if (!res) {
> + dev_err(dev, "failed to get param_ctrl memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->param_ctrl = devm_ioremap_resource(dev, res);
> + if (!phy->param_ctrl) {
> + dev_err(dev, "failed to remap param_ctrl memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + res = platform_get_resource_byname(pdev, IORESOURCE_MEM, "phy_base");
> + if (!res) {
> + dev_err(dev, "failed to get phy_base memory\n");
> + ret = -ENOENT;
> + goto err_out;
> + }
> +
> + phy->phy_base = devm_ioremap_resource(dev, res);
> + if (!phy->phy_base) {
> + dev_err(dev, "failed to remap phy_base memory\n");
> + ret = -ENOMEM;
> + goto err_out;
> + }
> +
> + phy->has_erratum_flag = 0;
> + for (i = 0; i < ARRAY_SIZE(phy_erratum_tbl); i++)
> + phy->has_erratum_flag |= device_property_read_bool(dev,
> + phy_erratum_tbl[i].compat) << i;
I don't see the erratum property in either the binding or the device
tree. Also, a property name is not a "compat".
Is there a reason why this flag and array mechanism is needed, rather
than just checking the erratum properties from the init function -- or,
if you have a good reason to not want to do device tree accesses from
init, just using a bool per erratum? How many errata are you expecting?
-Scott
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: Austin S. Hemmelgarn @ 2016-11-14 18:39 UTC (permalink / raw)
To: James Pharaoh, Zygo Blaxell; +Cc: Mark Fasheh, linux-btrfs
In-Reply-To: <a4e42724-d84a-e4f9-a3ea-d1fec31a5629@wellbehavedsoftware.com>
On 2016-11-14 13:22, James Pharaoh wrote:
> On 14/11/16 19:07, Zygo Blaxell wrote:
>> On Mon, Nov 07, 2016 at 07:49:51PM +0100, James Pharaoh wrote:
>>> Annoyingly I can't find this now, but I definitely remember reading
>>> someone,
>>> apparently someone knowledgable, claim that the latest version of the
>>> kernel
>>> which I was using at the time, still suffered from issues regarding the
>>> dedupe code.
>>
>>> This was a while ago, and I would be very pleased to hear that there
>>> is high
>>> confidence in the current implementation! I'll post a link if I
>>> manage to
>>> find the comments.
>>
>> I've been running the btrfs dedup ioctl 7 times per second on average
>> over 42TB of test data for most of a year (and at a lower rate for two
>> years). I have not found any data corruptions due to _dedup_. I did
>> find
>> three distinct data corruption kernel bugs unrelated to dedup, and two
>> test machines with bad RAM, so I'm pretty sure my corruption detection
>> is working.
>>
>> That said, I wouldn't run dedup on a kernel older than 4.4. LTS kernels
>> might be OK too, but only if they're up to date with backported btrfs
>> fixes.
>
> Ok, I think this might have referred to the 4.2 kernel, which was newly
> released at the time. I wish I could find the post!
>
>> Kernels older than 3.13 lack the FILE_EXTENT_SAME ioctl and can
>> only deduplicate static data (i.e. data you are certain is not being
>> concurrently modified). Before 3.12 there are so many bugs you might
>> as well not bother.
>
> Yes well I don't need to be told that, sadly.
>
>> Older kernels are bad for dedup because of non-corruption reasons.
>> Between 3.13 and 4.4, the following bugs were fixed:
>>
>> - false-negative capability checks (e.g. same-inode, EOF extent)
>> reduce dedup efficiency
>>
>> - ctime updates (older versions would update ctime when a file was
>> deduped) mess with incremental backup tools, build systems, etc.
>>
>> - kernel memory leaks (self-explanatory)
>>
>> - multiple kernel hang/panic bugs (e.g. a deadlock if two threads
>> try to read the same extent at the same time, and at least one
>> of those threads is dedup; and there was some race condition
>> leading to invalid memory access on dedup's comparison reads)
>> which won't eat your data, but they might ruin your day anyway.
>
> Ok, I have thing I've seen some stuff like this, I certainly have
> problems, but never a loss of data. Things can take a LONG time to get
> out of the filesystem, though.
>
>> There is also a still-unresolved problem where the filesystem CPU usage
>> rises exponentially for some operations depending on the number of shared
>> references to an extent. Files which contain blocks with more than a few
>> thousand shared references can trigger this problem. A file over 1TB can
>> keep the kernel busy at 100% CPU for over 40 minutes at a time.
>
> Yes, I see this all the time. For my use cases, I don't really care
> about "shared references" as blocks of files, but am happy to simply
> deduplicate at the whole-file level. I wonder if this still will have
> the same effect, however. I guess that this could be mitigated in a
> tool, but this is going to be both annoying and not the most elegant
> solution.
The issue is at the extent level, so it will impact whole files too (but
it will have less impact on defragmented files that are then
deduplicated as whole files). Pretty much anything that pins references
to extents will impact this, so cloned extents and snapshots will also
have an impact.
>
>> There might also be a correlation between delalloc data and hangs in
>> extent-same, but I have NOT been able to confirm this. All I know
>> at this point is that doing a fsync() on the source FD just before
>> doing the extent-same ioctl dramatically reduces filesystem hang rates:
>> several weeks between hangs (or no hangs at all) with fsync, vs. 18 hours
>> or less without.
>
> Interesting, I'll maybe see if I can make use of this.
>
> One thing I am keen to understand is if BTRFS will automatically ignore
> a request to deduplicate a file if it is already deduplicated? Given the
> performance I see when doing a repeat deduplication, it seems to me that
> it can't be doing so, although this could be caused by the CPU usage you
> mention above.
What's happening is that the dedupe ioctl does a byte-wise comparison of
the ranges to make sure they're the same before linking them. This is
actually what takes most of the time when calling the ioctl, and is part
of why it takes longer the larger the range to deduplicate is. In
essence, it's behaving like an OS should and not trusting userspace to
make reasonable requests (which is also why there's a separate ioctl to
clone a range from another file instead of deduplicating existing data).
TBH, even though it's kind of annoying from a performance perspective,
it's a rather nice safety net to have. For example, one of the cases
where I do deduplication is a couple of directories where each directory
is an overlapping partial subset of one large tree which I keep
elsewhere. In this case, I can tell just by filename exactly what files
might be duplicates, so the ioctl's check lets me just call the ioctl on
all potential duplicates (after checking size, no point in wasting time
if the files obviously aren't duplicates), and have it figure out
whether or not they can be deduplicated.
>
> In any case, I'm considering some digging into the filesystem structures
> to see if I can work this out myself before i do any deduplication. I'm
> fairly sure this should be relatively simple to work out, at least well
> enough for my purposes.
Sadly, there's no way to avoid doing so right now.
^ permalink raw reply
* [GIT PULL] arm: mediatek: soc changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:39 UTC (permalink / raw)
To: linux-arm-kernel
Hi Arnd and Olof,
Although a bit late, please take the following changes into account.
Thanks a lot,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-soc
for you to fetch changes up to 112ef1882e12094c823937f9d72f2f598db02df7:
soc: mediatek: Add MT2701 scpsys driver (2016-10-31 00:58:58 +0100)
----------------------------------------------------------------
- prepare mtk-scpsys to for multi soc support
- add support for mt2701 to mtk-scpsys
----------------------------------------------------------------
James Liao (1):
soc: mediatek: Refine scpsys to support multiple platform
Shunli Wang (1):
soc: mediatek: Add MT2701 scpsys driver
drivers/soc/mediatek/Kconfig | 2 +-
drivers/soc/mediatek/mtk-scpsys.c | 465
++++++++++++++++++++++++++------------
2 files changed, 327 insertions(+), 140 deletions(-)
^ permalink raw reply
* [GIT PULL] arm: mediatek: soc changes for v4.10
From: Matthias Brugger @ 2016-11-14 18:39 UTC (permalink / raw)
To: arm-DgEjT+Ai2ygdnm+yROfE0A
Cc: James Liao, moderated list:ARM/Mediatek SoC support, Shunli Wang,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
Hi Arnd and Olof,
Although a bit late, please take the following changes into account.
Thanks a lot,
Matthias
---
The following changes since commit 1001354ca34179f3db924eb66672442a173147dc:
Linux 4.9-rc1 (2016-10-15 12:17:50 -0700)
are available in the git repository at:
https://github.com/mbgg/linux-mediatek.git tags/v4.9-next-soc
for you to fetch changes up to 112ef1882e12094c823937f9d72f2f598db02df7:
soc: mediatek: Add MT2701 scpsys driver (2016-10-31 00:58:58 +0100)
----------------------------------------------------------------
- prepare mtk-scpsys to for multi soc support
- add support for mt2701 to mtk-scpsys
----------------------------------------------------------------
James Liao (1):
soc: mediatek: Refine scpsys to support multiple platform
Shunli Wang (1):
soc: mediatek: Add MT2701 scpsys driver
drivers/soc/mediatek/Kconfig | 2 +-
drivers/soc/mediatek/mtk-scpsys.c | 465
++++++++++++++++++++++++++------------
2 files changed, 327 insertions(+), 140 deletions(-)
^ permalink raw reply
* Re: XFS_WANT_CORRUPTED_GOTO
From: Chris @ 2016-11-14 18:39 UTC (permalink / raw)
To: linux-xfs; +Cc: Brian Foster
In-Reply-To: <20161114125654.GA37689@bfoster.bfoster>
Dear Brian,
thank you for your detailed answer.
Brian Foster wrote:
> On Sat, Nov 12, 2016 at 11:52:02AM +0100, Chris wrote:
>> I tried XFS-repair, but it couldn't find the first or second super block
>> after four hours.
>>
>
> That sounds like something more significant is going on either with the
> fs, the storage or xfs_repair has been pointed in the wrong place. The
> above issue should at worst require zeroing the log, dealing with the
> resulting inconsistency and rebuilding the fs btrees accurately.
Well, did it crash, because I called
xfs_db -c "freespc -s" /dev/...
while it was still in this unmount-loop?
> I suspect it's too late to inspect what's going on there if you have
> already restored from backup. In the future, you can use xfs_metadump to
> capture a metadata only image of a broken fs to share with us and help
> us diagnose what might have gone wrong.
OK.
> I'd suggest to run "xfs_repair -n" on those as soon as possible to see
> if they are affected by the same problem. It might also be a good idea
> to run it against the fs you've restored from backup to see if it
> returns and possibly get an idea on what might have caused the problem.
On those filesystems, that aren't in use now, xfs_repair hasn't found any
problems.
Thanks again for your help. Next time, I'll do a metadump.
- Chris
^ permalink raw reply
* Re: [PATCH] net: atheros: atl2: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-11-14 18:38 UTC (permalink / raw)
To: tremyfr; +Cc: jcliburn, chris.snook, jarod, ben, netdev, linux-kernel
In-Reply-To: <1479059608-32456-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 13 Nov 2016 18:53:28 +0100
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> The previous implementation of set_settings was modifying
> the value of advertising, but with the new API, it's not
> possible. The structure ethtool_link_ksettings is defined
> as const.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: atheros: atl1: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-11-14 18:38 UTC (permalink / raw)
To: tremyfr; +Cc: jcliburn, chris.snook, jarod, netdev, linux-kernel
In-Reply-To: <1479058514-22438-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sun, 13 Nov 2016 18:35:14 +0100
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> The previous implementation of set_settings was modifying
> the value of advertising, but with the new API, it's not
> possible. The structure ethtool_link_ksettings is defined
> as const.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: atheros: atl1c: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-11-14 18:38 UTC (permalink / raw)
To: tremyfr; +Cc: jcliburn, chris.snook, netdev, linux-kernel
In-Reply-To: <1478968369-25034-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Sat, 12 Nov 2016 17:32:49 +0100
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: alx: use new api ethtool_{get|set}_link_ksettings
From: David Miller @ 2016-11-14 18:38 UTC (permalink / raw)
To: tremyfr; +Cc: jcliburn, chris.snook, netdev, linux-kernel
In-Reply-To: <1478903437-9049-1-git-send-email-tremyfr@gmail.com>
From: Philippe Reynes <tremyfr@gmail.com>
Date: Fri, 11 Nov 2016 23:30:37 +0100
> The ethtool api {get|set}_settings is deprecated.
> We move this driver to new api {get|set}_link_ksettings.
>
> Signed-off-by: Philippe Reynes <tremyfr@gmail.com>
Applied.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.