* Re: [PATCH] mpm-transport: Update commit id with fixes
From: Nelson, Sam @ 2016-11-14 15:49 UTC (permalink / raw)
To: meta-ti@yoctoproject.org
In-Reply-To: <1478961971-54163-1-git-send-email-sam.nelson@ti.com>
NAK
Ignore this.
> -----Original Message-----
> From: Nelson, Sam
> Sent: Saturday, November 12, 2016 9:46 AM
> To: meta-ti@yoctoproject.org
> Cc: Nelson, Sam
> Subject: [PATCH] mpm-transport: Update commit id with fixes
>
> Update and fixes to handle different type of memory sections in sysfs entry
> or device tree.
>
> Signed-off-by: Sam Nelson <sam.nelson@ti.com>
> ---
> recipes-ti/mpm-transport/mpm-transport_git.bb | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/recipes-ti/mpm-transport/mpm-transport_git.bb b/recipes-
> ti/mpm-transport/mpm-transport_git.bb
> index 51b5e9e..ee28f2f 100644
> --- a/recipes-ti/mpm-transport/mpm-transport_git.bb
> +++ b/recipes-ti/mpm-transport/mpm-transport_git.bb
> @@ -15,11 +15,11 @@ PACKAGE_ARCH = "${MACHINE_ARCH}"
> SRC_URI = "git://git.ti.com/keystone-linux/mpm-
> transport.git;protocol=git;branch=${BRANCH}"
>
> BRANCH = "master"
> -# This commit corresponds to tag DEV.MPM-TRANSPORT-02.00.02.00 -
> SRCREV = "696a9ec37559b671860ef393194c6032b7b6d9ef"
> +# This commit corresponds to tag DEV.MPM-TRANSPORT-02.00.02.00A
> SRCREV
> += "7284e75d36b265ef8535d2e2ee54d1f2c700e862"
>
> PV = "2.0.2.0"
> -PR = "r0"
> +PR = "r1"
>
> EXTRA_OEMAKE = "PDK_INSTALL_PATH=${STAGING_INCDIR}"
> EXTRA_OEMAKE_append_k2hk-evm += "HYPLNK_TRANSPORT=true
> SRIO_TRANSPORT=true"
> --
> 1.9.1
^ permalink raw reply
* [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-14 18:25 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161114155222.GZ2078@8bytes.org>
On 14/11/16 15:52, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
>> If we've already made the decision to move away from bus ops, I don't
>> see that it makes sense to deliberately introduce new dependencies on
>> them. Besides, as it stands, this patch literally implements "tell the
>> iommu-core which hardware-iommus exist in the system and a seperate
>> iommu_ops ptr for each of them" straight off.
>
> Not sure which code you are looking at, but as I see it we have only
> per-device iommu-ops now (with this patch). That is different from
> having core-visible hardware-iommu instances where devices could link
> to.
The per-device IOMMU ops are already there since 57f98d2f61e1. This
patch generalises the other end, moving the "registering an IOMMU
instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
such if that makes the design intent clearer.
If you'd also prefer to replace iommu_fwspec::ops with an opaque
iommu_fwspec::iommu_instance pointer so that things are a bit more
centralised (and users are forced to go through the API rather then call
ops directly), I'd have no major objection either. My main point is that
we've been deliberately putting the relevant building blocks in place -
the of_iommu_{get,set}_ops stuff was designed from the start to
accommodate per-instance ops, via the ops pointer *being* the instance
token; the iommu_fwspec stuff is deliberately intended to provide
per-device ops on top of that. The raw functionality is either there in
iommu.c already, or moving there in patches already written, so if it
doesn't look right all we need to focus on is making it look right.
> Also the rest of iommu-core code still makes use of the per-bus ops. The
> per-device ops are only used for the of_xlate fn-ptr.
Hence my aforementioned patches intended for 4.10, directly following on
from introducing iommu_fwspec in 4.9:
http://www.mail-archive.com/iommu at lists.linux-foundation.org/msg14576.html
...the purpose being to provide a smooth transition from per-bus ops to
per-device, per-instance ops. Apply those and we're 90% of the way there
for OF-based IOMMU drivers (not that any of those actually need
per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
ago, but it didn't seem worth the bother). Lorenzo's series broadens the
scope to ACPI-based systems and moves the generically-useful parts into
the core where we can easily build on them further if necessary. The
major remaining work is to convert external callers of the current
bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
to device-based alternatives.
Robin.
^ permalink raw reply
* Re: [PATCH v7 04/16] drivers: iommu: make of_iommu_set/get_ops() DT agnostic
From: Robin Murphy @ 2016-11-14 18:25 UTC (permalink / raw)
To: Joerg Roedel
Cc: Lorenzo Pieralisi, iommu, Will Deacon, Hanjun Guo, Marc Zyngier,
Rafael J. Wysocki, Tomasz Nowicki, Jon Masters, Eric Auger,
Sinan Kaya, Nate Watterson, Prem Mallappa, Dennis Chen,
linux-acpi, linux-pci, linux-kernel, linux-arm-kernel
In-Reply-To: <20161114155222.GZ2078@8bytes.org>
On 14/11/16 15:52, Joerg Roedel wrote:
> On Mon, Nov 14, 2016 at 12:00:47PM +0000, Robin Murphy wrote:
>> If we've already made the decision to move away from bus ops, I don't
>> see that it makes sense to deliberately introduce new dependencies on
>> them. Besides, as it stands, this patch literally implements "tell the
>> iommu-core which hardware-iommus exist in the system and a seperate
>> iommu_ops ptr for each of them" straight off.
>
> Not sure which code you are looking at, but as I see it we have only
> per-device iommu-ops now (with this patch). That is different from
> having core-visible hardware-iommu instances where devices could link
> to.
The per-device IOMMU ops are already there since 57f98d2f61e1. This
patch generalises the other end, moving the "registering an IOMMU
instance" (i.e. iommu_fwentry) bit into the IOMMU core, from being
OF-specific. I'd be perfectly happy if we rename iommu_fwentry to
iommu_instance, fwnode_iommu_set_ops() to iommu_register_instance(), and
such if that makes the design intent clearer.
If you'd also prefer to replace iommu_fwspec::ops with an opaque
iommu_fwspec::iommu_instance pointer so that things are a bit more
centralised (and users are forced to go through the API rather then call
ops directly), I'd have no major objection either. My main point is that
we've been deliberately putting the relevant building blocks in place -
the of_iommu_{get,set}_ops stuff was designed from the start to
accommodate per-instance ops, via the ops pointer *being* the instance
token; the iommu_fwspec stuff is deliberately intended to provide
per-device ops on top of that. The raw functionality is either there in
iommu.c already, or moving there in patches already written, so if it
doesn't look right all we need to focus on is making it look right.
> Also the rest of iommu-core code still makes use of the per-bus ops. The
> per-device ops are only used for the of_xlate fn-ptr.
Hence my aforementioned patches intended for 4.10, directly following on
from introducing iommu_fwspec in 4.9:
http://www.mail-archive.com/iommu@lists.linux-foundation.org/msg14576.html
...the purpose being to provide a smooth transition from per-bus ops to
per-device, per-instance ops. Apply those and we're 90% of the way there
for OF-based IOMMU drivers (not that any of those actually need
per-instance ops, admittedly; I did prototype it for the ARM SMMU ages
ago, but it didn't seem worth the bother). Lorenzo's series broadens the
scope to ACPI-based systems and moves the generically-useful parts into
the core where we can easily build on them further if necessary. The
major remaining work is to convert external callers of the current
bus-dependent functions like iommu_domain_alloc(), iommu_present(), etc.
to device-based alternatives.
Robin.
^ permalink raw reply
* Re: [PATCH] remote-curl: don't hang when a server dies before any output
From: Jeff King @ 2016-11-14 18:24 UTC (permalink / raw)
To: David Turner; +Cc: git, spearce
In-Reply-To: <1478729910-26232-1-git-send-email-dturner@twosigma.com>
On Wed, Nov 09, 2016 at 05:18:30PM -0500, David Turner wrote:
> In the event that a HTTP server closes the connection after giving a
> 200 but before giving any packets, we don't want to hang forever
> waiting for a response that will never come. Instead, we should die
> immediately.
I agree we don't want to hang forever, but this leaves open the
question: what is hanging?
My guess is that fetch-pack is waiting for more data from the server,
and remote-curl is waiting for fetch-pack to tell us what to send for
the next request. Neither will make forward progress because they are
effectively waiting on each other.
Which means this is likely a special case of malformed input from the
server. A server which likewise sends a partial response could end up in
the same deadlock, I would think (e.g., a half-finished pktline, or a
pktline but no trailing flush).
That doesn't make it wrong to fix this specific case (especially if it's
a common one), but I wonder if we could do better.
The root of the issue is that only fetch-pack understands the protocol,
and remote-curl is blindly proxying the data. But only remote-curl knows
that the HTTP request has ended, and it doesn't relay that information
to fetch-pack. So I can think of two solutions:
1. Some way of remote-curl communicating the EOF to fetch-pack. It
can't just close the descriptor, since we need to pass more data
over it for the followup requests. You'd need something
out-of-band, or to frame the HTTP data inside another layer of
pktlines, both of which are kind of gross.
2. Have remote-curl understand enough of the protocol that it can
abort rather than hang.
I think that's effectively the approach of your patch, but for one
specific case. But could we, for example, make sure that everything
we proxy is a complete set of pktlines and ends with a flush? And
if not, then we hang up on fetch-pack.
I _think_ that would work, because even the pack is always encased
in pktlines for smart-http.
> @@ -659,6 +662,8 @@ static int post_rpc(struct rpc_state *rpc)
> curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
> curl_easy_setopt(slot->curl, CURLOPT_FILE, rpc);
>
> +
> + rpc->any_written = 0;
Extra blank line here?
> @@ -667,6 +672,9 @@ static int post_rpc(struct rpc_state *rpc)
> if (err != HTTP_OK)
> err = -1;
>
> + if (!rpc->any_written)
> + err = -1;
> +
I wondered if there were any cases where it was normal for the server to
return zero bytes. Possibly the ref advertisement is one, but this is
_just_ handling post_rpc(), so that's OK. And I think by definition
every response has to at least return a flush packet, or we would make
no forward progress (i.e., the exact case you are dealing with here).
-Peff
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: bcm2835: Return pins to inputs when freed
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: Linus Walleij, linux-kernel, linux-arm-kernel
Cc: linux-gpio, Phil Elwell, Stefan Wahren, Stephen Warren,
Linus Walleij
In-Reply-To: <1479126214-20529-1-git-send-email-linus.walleij@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
Linus Walleij <linus.walleij@linaro.org> writes:
> From: Phil Elwell <phil@raspberrypi.org>
>
> When dynamically unloading overlays, it is important that freed pins are
> restored to being inputs to prevent functions from being enabled in
> multiple places at once.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Eric Anholt <eric@anholt.net>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: [PATCH 2/2] pinctrl: bcm2835: Return pins to inputs when freed
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: linux-kernel, linux-arm-kernel
Cc: linux-gpio, Phil Elwell, Stefan Wahren, Stephen Warren,
Linus Walleij
In-Reply-To: <1479126214-20529-1-git-send-email-linus.walleij@linaro.org>
[-- Attachment #1: Type: text/plain, Size: 546 bytes --]
Linus Walleij <linus.walleij@linaro.org> writes:
> From: Phil Elwell <phil@raspberrypi.org>
>
> When dynamically unloading overlays, it is important that freed pins are
> restored to being inputs to prevent functions from being enabled in
> multiple places at once.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Eric Anholt <eric@anholt.net>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* [PATCH 2/2] pinctrl: bcm2835: Return pins to inputs when freed
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1479126214-20529-1-git-send-email-linus.walleij@linaro.org>
Linus Walleij <linus.walleij@linaro.org> writes:
> From: Phil Elwell <phil@raspberrypi.org>
>
> When dynamically unloading overlays, it is important that freed pins are
> restored to being inputs to prevent functions from being enabled in
> multiple places at once.
>
> Cc: Stefan Wahren <stefan.wahren@i2se.com>
> Cc: Eric Anholt <eric@anholt.net>
> Cc: Stephen Warren <swarren@wwwdotorg.org>
> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/9b3ddd85/attachment-0001.sig>
^ permalink raw reply
* Re: [PATCH v4] btrfs: make block group flags in balance printks human-readable
From: David Sterba @ 2016-11-14 18:24 UTC (permalink / raw)
To: Adam Borowski; +Cc: Holger Hoffstätte, David Sterba, linux-btrfs
In-Reply-To: <20161114174434.27383-1-kilobyte@angband.pl>
On Mon, Nov 14, 2016 at 06:44:34PM +0100, Adam Borowski wrote:
> They're not even documented anywhere, letting users with no recourse but
> to RTFS. It's no big burden to output the bitfield as words.
>
> Also, display unknown flags as hex.
>
> Signed-off-by: Adam Borowski <kilobyte@angband.pl>
Added to 4.10 queue, thanks.
^ permalink raw reply
* [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <427a3d44-16aa-258c-8722-48d9c7ffb593@i2se.com>
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Hi Linus,
>
> Am 14.11.2016 um 13:23 schrieb Linus Walleij:
>> From: Phil Elwell <phil@raspberrypi.org>
>>
>> Contrary to the documentation, the BCM2835 GPIO controller actually
>> has four interrupt lines - one each for the three IRQ groups and one
>> common. Confusingly, the GPIO interrupt groups don't correspond
>> directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
>> GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
>>
>> Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
>> so split out a function to process the interrupts for a single GPIO
>> bank.
>>
>> Cc: Stefan Wahren <stefan.wahren@i2se.com>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> I want to apply this to cater for my GPIOLIB_IRQCHIP
>> refactorings.
>> ---
>> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
>> 1 file changed, 39 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> index b2dd278f18b1..1d8fc104e26b 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>>
> ...
>> @@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
>> .remove = bcm2835_pinctrl_remove,
>> .driver = {
>> .name = MODULE_NAME,
>> + .owner = THIS_MODULE,
>
> this is unnecessary. Please remove it.
>
> Thanks for submitting these patches
With that dropped,
Acked-by: Eric Anholt <eric@anholt.net>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 800 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20161114/2938bc95/attachment.sig>
^ permalink raw reply
* Re: [PATCH 1/2] pinctrl: bcm2835: Fix ints for GPIOs 28-31 & 46-53
From: Eric Anholt @ 2016-11-14 18:24 UTC (permalink / raw)
To: Stefan Wahren, Linus Walleij, linux-kernel, linux-arm-kernel
Cc: linux-gpio, Phil Elwell, Stephen Warren
In-Reply-To: <427a3d44-16aa-258c-8722-48d9c7ffb593@i2se.com>
[-- Attachment #1: Type: text/plain, Size: 1691 bytes --]
Stefan Wahren <stefan.wahren@i2se.com> writes:
> Hi Linus,
>
> Am 14.11.2016 um 13:23 schrieb Linus Walleij:
>> From: Phil Elwell <phil@raspberrypi.org>
>>
>> Contrary to the documentation, the BCM2835 GPIO controller actually
>> has four interrupt lines - one each for the three IRQ groups and one
>> common. Confusingly, the GPIO interrupt groups don't correspond
>> directly with the GPIO control banks. Instead, GPIOs 0-27 generate IRQ
>> GPIO0, 28-45 IRQ GPIO1 and 46-53 IRQ GPIO2.
>>
>> Awkwardly, the GPIOs for IRQ GPIO1 straddle two 32-entry GPIO banks,
>> so split out a function to process the interrupts for a single GPIO
>> bank.
>>
>> Cc: Stefan Wahren <stefan.wahren@i2se.com>
>> Cc: Eric Anholt <eric@anholt.net>
>> Cc: Stephen Warren <swarren@wwwdotorg.org>
>> Signed-off-by: Phil Elwell <phil@raspberrypi.org>
>> Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
>> ---
>> I want to apply this to cater for my GPIOLIB_IRQCHIP
>> refactorings.
>> ---
>> drivers/pinctrl/bcm/pinctrl-bcm2835.c | 51 ++++++++++++++++++++++++++---------
>> 1 file changed, 39 insertions(+), 12 deletions(-)
>>
>> diff --git a/drivers/pinctrl/bcm/pinctrl-bcm2835.c b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> index b2dd278f18b1..1d8fc104e26b 100644
>> --- a/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>> +++ b/drivers/pinctrl/bcm/pinctrl-bcm2835.c
>>
> ...
>> @@ -1076,6 +1102,7 @@ static struct platform_driver bcm2835_pinctrl_driver = {
>> .remove = bcm2835_pinctrl_remove,
>> .driver = {
>> .name = MODULE_NAME,
>> + .owner = THIS_MODULE,
>
> this is unnecessary. Please remove it.
>
> Thanks for submitting these patches
With that dropped,
Acked-by: Eric Anholt <eric@anholt.net>
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 800 bytes --]
^ permalink raw reply
* Re: [PATCH net 2/3] bpf, mlx5: fix various refcount/prog issues in mlx5e_xdp_set
From: Daniel Borkmann @ 2016-11-14 18:23 UTC (permalink / raw)
To: Alexei Starovoitov; +Cc: davem, bblanco, tariqt, zhiyisun, ranas, netdev
In-Reply-To: <20161114173525.GA98186@ast-mbp.thefacebook.com>
On 11/14/2016 06:35 PM, Alexei Starovoitov wrote:
> On Mon, Nov 14, 2016 at 09:49:49AM +0100, Daniel Borkmann wrote:
>> On 11/14/2016 03:49 AM, Alexei Starovoitov wrote:
>>> On Mon, Nov 14, 2016 at 01:43:41AM +0100, Daniel Borkmann wrote:
>> [...]
>>>> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
>>>> index 751e806..a0fca9f 100644
>>>> --- a/kernel/bpf/syscall.c
>>>> +++ b/kernel/bpf/syscall.c
>>>> @@ -682,6 +682,17 @@ struct bpf_prog *bpf_prog_add(struct bpf_prog *prog, int i)
>>>> }
>>>> EXPORT_SYMBOL_GPL(bpf_prog_add);
>>>>
>>>> +void bpf_prog_sub(struct bpf_prog *prog, int i)
>>>> +{
>>>> + /* Only to be used for undoing previous bpf_prog_add() in some
>>>> + * error path. We still know that another entity in our call
>>>> + * path holds a reference to the program, thus atomic_sub() can
>>>> + * be safely used in such cases!
>>>> + */
>>>> + WARN_ON(atomic_sub_return(i, &prog->aux->refcnt) == 0);
>>>> +}
>>>> +EXPORT_SYMBOL_GPL(bpf_prog_sub);
>>>
>>> the patches look good. I'm only worried about net/net-next merge
>>> conflict here. (I would have to deal with it as well).
>>> So instead of copying the above helper can we apply net-next's
>>> 'bpf, mlx4: fix prog refcount in mlx4_en_try_alloc_resources error path'
>>> patch to net without mlx4_xdp_set hunk and then apply
>>> the rest of this patch?
>>> Even better is to send this patch 2/3 to net-next?
>>> yes, it's an issue, but very small one. There is no security
>>> concern here, so I would prefer to avoid merge conflict.
>>> Did you do a test merge of net/net-next by any chance?
>>
>> Yes, I did a test merge and git resolved the above just fine w/o
>> any conflicts. I have no strong opinion whether net or net-next.
>> If preferred, I can just resend this series in the evening against
>> net-next instead, perhaps that's a bit better.
>
> I have slight preference to go via net-next, but since it merges fine,
> I don't mind net route too.
Ok, I'll rebase for net-next then.
^ permalink raw reply
* Re: [PATCH -next] mfd: intel_soc_pmic_bxtwc: Fix a typo in MODULE_DEVICE_TABLE()
From: Lee Jones @ 2016-11-14 18:25 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Wei Yongjun, linux-kernel
In-Reply-To: <1478015990-9646-1-git-send-email-weiyj.lk@gmail.com>
On Tue, 01 Nov 2016, Wei Yongjun wrote:
> From: Wei Yongjun <weiyongjun1@huawei.com>
>
> Fix a typo in MODULE_DEVICE_TABLE(). 'pmic_acpi_ids' should be
> 'bxtwc_acpi_ids'.
>
> Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
> ---
> drivers/mfd/intel_soc_pmic_bxtwc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Applied, thanks.
> diff --git a/drivers/mfd/intel_soc_pmic_bxtwc.c b/drivers/mfd/intel_soc_pmic_bxtwc.c
> index f9a8c52..d5b5c7f 100644
> --- a/drivers/mfd/intel_soc_pmic_bxtwc.c
> +++ b/drivers/mfd/intel_soc_pmic_bxtwc.c
> @@ -481,7 +481,7 @@ static const struct acpi_device_id bxtwc_acpi_ids[] = {
> { "INT34D3", },
> { }
> };
> -MODULE_DEVICE_TABLE(acpi, pmic_acpi_ids);
> +MODULE_DEVICE_TABLE(acpi, bxtwc_acpi_ids);
>
> static struct platform_driver bxtwc_driver = {
> .probe = bxtwc_probe,
>
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: Announcing btrfs-dedupe
From: James Pharaoh @ 2016-11-14 18:22 UTC (permalink / raw)
To: Zygo Blaxell; +Cc: Mark Fasheh, linux-btrfs
In-Reply-To: <20161114180714.GF21290@hungrycats.org>
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.
> 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.
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.
James
^ permalink raw reply
* Re: ✗ Fi.CI.BAT: warning for drm/i915: A few DP stragglers
From: Ville Syrjälä @ 2016-11-14 18:22 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <20161114181649.16476.49173@emeril.freedesktop.org>
On Mon, Nov 14, 2016 at 06:16:49PM -0000, Patchwork wrote:
> == Series Details ==
>
> Series: drm/i915: A few DP stragglers
> URL : https://patchwork.freedesktop.org/series/15299/
> State : warning
>
> == Summary ==
>
> Series 15299v1 drm/i915: A few DP stragglers
> https://patchwork.freedesktop.org/api/1.0/series/15299/revisions/1/mbox/
>
> Test kms_pipe_crc_basic:
> Subgroup nonblocking-crc-pipe-b:
> pass -> DMESG-WARN (fi-snb-2520m)
[ 468.452200] [drm:drm_edid_block_valid] *ERROR* EDID checksum is invalid, remainder is 44
https://bugs.freedesktop.org/show_bug.cgi?id=98625
>
> fi-bdw-5557u total:244 pass:229 dwarn:0 dfail:0 fail:0 skip:15
> fi-bsw-n3050 total:244 pass:204 dwarn:0 dfail:0 fail:0 skip:40
> fi-bxt-t5700 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
> fi-byt-j1900 total:244 pass:216 dwarn:0 dfail:0 fail:0 skip:28
> fi-byt-n2820 total:244 pass:212 dwarn:0 dfail:0 fail:0 skip:32
> fi-hsw-4770 total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
> fi-hsw-4770r total:244 pass:224 dwarn:0 dfail:0 fail:0 skip:20
> fi-ilk-650 total:244 pass:191 dwarn:0 dfail:0 fail:0 skip:53
> fi-ivb-3520m total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
> fi-ivb-3770 total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
> fi-kbl-7200u total:244 pass:222 dwarn:0 dfail:0 fail:0 skip:22
> fi-skl-6260u total:244 pass:230 dwarn:0 dfail:0 fail:0 skip:14
> fi-skl-6700hq total:244 pass:223 dwarn:0 dfail:0 fail:0 skip:21
> fi-skl-6700k total:244 pass:222 dwarn:1 dfail:0 fail:0 skip:21
> fi-snb-2520m total:244 pass:211 dwarn:1 dfail:0 fail:0 skip:32
> fi-snb-2600 total:244 pass:211 dwarn:0 dfail:0 fail:0 skip:33
>
> 8670f0f0d91190e0d090ee910c73ed83c37cfef5 drm-intel-nightly: 2016y-11m-14d-16h-10m-52s UTC integration manifest
> 1c9d66a drm/i915: Simplify DP port limited color range bit platform checks
> 73f4bd0 drm/i915: Kill dp_encoder_is_mst
>
> == Logs ==
>
> For more details see: https://intel-gfx-ci.01.org/CI/Patchwork_2987/
--
Ville Syrjälä
Intel OTC
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [kvm-unit-tests PATCH] x86: Test disabled local APIC
From: Jim Mattson @ 2016-11-14 18:14 UTC (permalink / raw)
To: Paolo Bonzini, Radim Krčmář, kvm; +Cc: Jim Mattson
In-Reply-To: <b3a9fb01-c990-87d2-65f6-0d4b1fac67dc@redhat.com>
This test disables and re-enables the local APIC and ensures that
CPUID.1H:EDX.APIC[bit 9] mirrors IA32_APIC_BASE[11].
Signed-off-by: Jim Mattson <jmattson@google.com>
---
x86/apic.c | 23 +++++++++++++++++++++++
1 file changed, 23 insertions(+)
diff --git a/x86/apic.c b/x86/apic.c
index eff9a11..39c7fd1 100644
--- a/x86/apic.c
+++ b/x86/apic.c
@@ -104,6 +104,28 @@ void test_enable_x2apic(void)
}
}
+static void test_apic_disable(void)
+{
+ u64 orig_apicbase = rdmsr(MSR_IA32_APICBASE);
+
+ report_prefix_push("apic_disable");
+
+ report("Local apic enabled", orig_apicbase & APIC_EN);
+ report("CPUID.1H:EDX.APIC[bit 9] is set", cpuid(1).d & (1 << 9));
+
+ wrmsr(MSR_IA32_APICBASE, orig_apicbase & ~(APIC_EN | APIC_EXTD));
+ report("Local apic disabled", !(rdmsr(MSR_IA32_APICBASE) & APIC_EN));
+ report("CPUID.1H:EDX.APIC[bit 9] is clear", !(cpuid(1).d & (1 << 9)));
+
+ wrmsr(MSR_IA32_APICBASE, orig_apicbase & ~APIC_EXTD);
+ wrmsr(MSR_IA32_APICBASE, orig_apicbase);
+ apic_write(APIC_SPIV, 0x1ff);
+ report("Local apic enabled", rdmsr(MSR_IA32_APICBASE) & APIC_EN);
+ report("CPUID.1H:EDX.APIC[bit 9] is set", cpuid(1).d & (1 << 9));
+
+ report_prefix_pop();
+}
+
#define ALTERNATE_APIC_BASE 0x42000000
static void test_apicbase(void)
@@ -398,6 +420,7 @@ int main()
mask_pic_interrupts();
test_apic_id();
+ test_apic_disable();
test_enable_x2apic();
test_apicbase();
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [refpolicy] su_exec
From: Fakim, Walid @ 2016-11-14 18:22 UTC (permalink / raw)
To: refpolicy
In-Reply-To: <6ebc2667-b50e-e227-c6fd-16c7454c3c8c@gmail.com>
Thanks Dom - I'll experiment with that.
I can see that pam_rootok.so is already present in /lib64/security
Am using CentOS 6.8 so might be susceptible to that bug you mention.
I'll try adding the permission - Am assuming you mean -> allow mydomain_t self:passwd rootok; <- ?
Thanks.
Best Regards,
Walid Fakim
-----Original Message-----
From: Dominick Grift [mailto:dac.override at gmail.com]
Sent: 14 November 2016 18:16
To: Fakim, Walid; refpolicy@oss.tresys.com
Subject: Re: su_exec
On 11/14/2016 05:11 PM, Fakim, Walid wrote:
> Hi Guys,
>
> So for this process am trying to confine, the startup script is using su -c rather than runuser and even though I've got su_exec(mydomain_t) in my te file, it's prompting for a password at startup.
>
> Any thoughts or experience of seeing this before?
>
> Thanks.
>
> Best Regards,
>
> Walid Fakim
>
>
Add pam_rootok.so to /etc/pam.d/su maybe?
Also you may need to allow ":passwd rootok;" permission
If it hit that then the event should show up as a "USER_AVC" in audit.log (ausearch -m USER_AVC -ts today)
In the past there was a problem with PAMs' SELinux awareness and it was not logging USER_AVC denials. That should now be fixed.
--
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
^ permalink raw reply
* Re: [RFC PATCH KERNEL 0/4] x86/xen: untangle PV and PVHVM guest support code
From: David Vrabel @ 2016-11-14 18:21 UTC (permalink / raw)
To: Vitaly Kuznetsov, xen-devel
Cc: Juergen Gross, Boris Ostrovsky, x86, Andrew Jones, David Vrabel
In-Reply-To: <1479143869-27611-1-git-send-email-vkuznets@redhat.com>
On 14/11/16 17:17, Vitaly Kuznetsov wrote:
> Hi,
>
> I have a long-standing idea to separate PV and PVHVM code in kernel and
> introduce Kconfig options to make it possible to enable the required
> parts only breaking the current 'all or nothing' approach.
>
> Motivation:
> - Xen related x86 code in kernel is rather big and it is unclear which
> parts of it are required for PV, for HVM or for both. With PVH coming
> into picture is becomes even more tangled. It makes it hard to
> understand/audit the code.
>
> - In some case we may want to avoid bloating kernel by supporting Xen
> guests we don't need. In particular, 90% of the code in arch/x86/xen/ is
> required to support PV guests and one may require PVHVM support only.
>
> - PV guests are supposed to go away one day and such code separation would
> help us to get ready.
All good reasons.
> This RFC adds XEN_PV Kconfig option and makes it possible to build PV-only
> and PVHVM-only kernels. It also makes it possible to disable Dom0 support.
> The series is incomplete and probably dirty in some places, I didn't pay
> much attention to the current PVH implementation as (as far as I
> understand) it is supposed to be replaced with PVHv2 but before investing
> more I'd like to get opinions whether such refactoring will be welcomed.
This series might be best done after PVHv1 is removed. Boris, any
thoughts on the best approach here?
David
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH] mfd: core: fix device reference leak in mfd_clone_cell
From: Lee Jones @ 2016-11-14 18:25 UTC (permalink / raw)
To: Johan Hovold; +Cc: linux-kernel
In-Reply-To: <1477996698-28870-1-git-send-email-johan@kernel.org>
On Tue, 01 Nov 2016, Johan Hovold wrote:
> Make sure to drop the reference taken by bus_find_device_by_name()
> before returning from mfd_clone_cell().
>
> Fixes: a9bbba996302 ("mfd: add platform_device sharing support for mfd")
> Signed-off-by: Johan Hovold <johan@kernel.org>
> ---
> drivers/mfd/mfd-core.c | 2 ++
> 1 file changed, 2 insertions(+)
Applied, thanks.
> diff --git a/drivers/mfd/mfd-core.c b/drivers/mfd/mfd-core.c
> index 3ac486a597f3..c57e407020f1 100644
> --- a/drivers/mfd/mfd-core.c
> +++ b/drivers/mfd/mfd-core.c
> @@ -399,6 +399,8 @@ int mfd_clone_cell(const char *cell, const char **clones, size_t n_clones)
> clones[i]);
> }
>
> + put_device(dev);
> +
> return 0;
> }
> EXPORT_SYMBOL(mfd_clone_cell);
--
Lee Jones
Linaro STMicroelectronics Landing Team Lead
Linaro.org │ Open source software for ARM SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* Re: [PATCH v4 3/8] media: adv7180: add support for NEWAVMODE
From: Steve Longerbeam @ 2016-11-14 18:21 UTC (permalink / raw)
To: Hans Verkuil, Steve Longerbeam, lars; +Cc: mchehab, linux-media, linux-kernel
In-Reply-To: <c759906e-e04f-2ccd-f175-e46367879890@xs4all.nl>
On 11/14/2016 03:28 AM, Hans Verkuil wrote:
> On 08/03/2016 08:03 PM, Steve Longerbeam wrote:
>> Parse the optional v4l2 endpoint DT node. If the bus type is
>> V4L2_MBUS_BT656 and the endpoint node specifies "newavmode",
>> configure the BT.656 bus in NEWAVMODE.
>>
>> Signed-off-by: Steve Longerbeam <steve_longerbeam@mentor.com>
>>
>> ---
>>
>> v4: no changes
>> v3:
>> - the newavmode endpoint property is now private to adv7180.
>> ---
>> .../devicetree/bindings/media/i2c/adv7180.txt | 4 ++
>> drivers/media/i2c/adv7180.c | 46 ++++++++++++++++++++--
>> 2 files changed, 47 insertions(+), 3 deletions(-)
>>
>> diff --git a/Documentation/devicetree/bindings/media/i2c/adv7180.txt b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
>> index 0d50115..6c175d2 100644
>> --- a/Documentation/devicetree/bindings/media/i2c/adv7180.txt
>> +++ b/Documentation/devicetree/bindings/media/i2c/adv7180.txt
>> @@ -15,6 +15,10 @@ Required Properties :
>> "adi,adv7282"
>> "adi,adv7282-m"
>>
>> +Optional Endpoint Properties :
>> +- newavmode: a boolean property to indicate the BT.656 bus is operating
>> + in Analog Device's NEWAVMODE. Valid for BT.656 busses only.
> This is too vague.
>
> Based on the ADV7280/ADV7281/ADV7282/ADV7283 Hardware Reference Manual I
> would say something like this:
>
> - newavmode: a boolean property to indicate the BT.656 bus is operating
> in Analog Device's NEWAVMODE. Valid for BT.656 busses only. When enabled
> the generated EAV/SAV codes are suitable for Analog Devices encoders.
> Otherwise these codes are setup according to <some standard?>
> See bit 4 of user sub map register 0x31 in the Hardware Reference Manual.
>
> I may have asked this before, but do you actually have hardware that needs
> this? If so, it may be useful to give it as an example and explain why it
> is needed.
>
> If not, then I wonder if this cannot be dropped until we DO see hardware
> that needs it.
Hi Hans, thanks for reviewing this, but at least for imx6, I don't
need this patch anymore.
Recently I dug deeper into the current bt.656 programming in
adv7180.c. The driver manually configures the bus to have 21
blank lines in odd fields, and 22 blank lines in even fields (via
NVEND register) for NTSC.
That leaves 525 - (21 +22) = 482 active lines in NTSC.
After configuring the imx6 host bridge to crop those extra 2 lines,
it is capturing good 720x480 NTSC images now.
So I no longer need this patch to enable NEWAVMODE.
However I still see some issues.
First, adv7180.c attempts to enable BT.656-4 mode, but according
to the datasheet, that cannot be enabled without first enabling
NEWAVMODE. So the attempt to enable BT.656-4 mode is a no-op,
it is currently doing nothing. So I suggest removing that attempt.
Second, it is wrong for the host bridge to have to make an assumption
about cropping for a sensor. The adv7180 needs to communicate to
hosts about the number of field blanking lines it has configured, maybe
via get_selection. I.e., report full sensor frame via get_fmt, and 720x482
via get_selection.
Steve
^ permalink raw reply
* Re: Debugging Ethernet issues
From: Florian Fainelli @ 2016-11-14 18:20 UTC (permalink / raw)
To: Sebastian Frias, Mason, Andrew Lunn
Cc: netdev, Mans Rullgard, Sergei Shtylyov, Tom Lendacky, Zach Brown,
Shaohui Xie, Tim Beale, Brian Hill, Vince Bridgers,
Balakumaran Kannan, David S. Miller, Kirill Kapranov
In-Reply-To: <5829FB6F.6090106@laposte.net>
On 11/14/2016 09:59 AM, Sebastian Frias wrote:
> On 11/14/2016 06:32 PM, Florian Fainelli wrote:
>> On 11/14/2016 07:33 AM, Mason wrote:
>>> On 14/11/2016 15:58, Mason wrote:
>>>
>>>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>>>> vs
>>>> nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control off
>>>>
>>>> I'm not sure whether "flow control" is relevant...
>>>
>>> Based on phy_print_status()
>>> phydev->pause ? "rx/tx" : "off"
>>> I added the following patch.
>>>
>>> diff --git a/drivers/net/ethernet/aurora/nb8800.c b/drivers/net/ethernet/aurora/nb8800.c
>>> index defc22a15f67..4e758c1cfa4e 100644
>>> --- a/drivers/net/ethernet/aurora/nb8800.c
>>> +++ b/drivers/net/ethernet/aurora/nb8800.c
>>> @@ -667,6 +667,8 @@ static void nb8800_link_reconfigure(struct net_device *dev)
>>> struct phy_device *phydev = priv->phydev;
>>> int change = 0;
>>>
>>> + printk("%s from %pf\n", __func__, __builtin_return_address(0));
>>> +
>>> if (phydev->link) {
>>> if (phydev->speed != priv->speed) {
>>> priv->speed = phydev->speed;
>>> @@ -1274,9 +1276,9 @@ static int nb8800_hw_init(struct net_device *dev)
>>> nb8800_writeb(priv, NB8800_PQ2, val & 0xff);
>>>
>>> /* Auto-negotiate by default */
>>> - priv->pause_aneg = true;
>>> - priv->pause_rx = true;
>>> - priv->pause_tx = true;
>>> + priv->pause_aneg = false;
>>> + priv->pause_rx = false;
>>> + priv->pause_tx = false;
>>>
>>> nb8800_mc_init(dev, 0);
>>>
>>>
>>> Connected to 1000 Mbps switch:
>>>
>>> # time udhcpc | while read LINE; do date; echo $LINE; done
>>> Thu Jan 1 00:00:22 UTC 1970
>>> udhcpc (v1.22.1) started
>>> Thu Jan 1 00:00:22 UTC 1970
>>> Sending discover...
>>> [ 24.565346] nb8800_link_reconfigure from phy_state_machine
>>> Thu Jan 1 00:00:25 UTC 1970
>>> Sending discover...
>>> [ 26.575402] nb8800_link_reconfigure from phy_state_machine
>>> [ 26.580972] nb8800 26000.ethernet eth0: Link is Up - 1Gbps/Full - flow control rx/tx
>>> Thu Jan 1 00:00:28 UTC 1970
>>> Sending discover...
>>> Thu Jan 1 00:00:29 UTC 1970
>>> Sending select for 172.27.64.58...
>>> Thu Jan 1 00:00:29 UTC 1970
>>> Lease of 172.27.64.58 obtained, lease time 604800
>>> Thu Jan 1 00:00:29 UTC 1970
>>> deleting routers
>>> Thu Jan 1 00:00:29 UTC 1970
>>> adding dns 172.27.0.17
>>>
>>> real 0m7.388s
>>> user 0m0.040s
>>> sys 0m0.090s
>>>
>>>
>>>
>>> Connected to 100 Mbps switch:
>>>
>>> # time udhcpc | while read LINE; do date; echo $LINE; done
>>> Thu Jan 1 00:00:14 UTC 1970
>>> udhcpc (v1.22.1) started
>>> Thu Jan 1 00:00:15 UTC 1970
>>> Sending discover...
>>> [ 16.968621] nb8800_link_reconfigure from phy_state_machine
>>> [ 17.975359] nb8800_link_reconfigure from phy_state_machine
>>> [ 17.980923] nb8800 26000.ethernet eth0: Link is Up - 100Mbps/Full - flow control rx/tx
>>> Thu Jan 1 00:00:18 UTC 1970
>>> Sending discover...
>>> Thu Jan 1 00:00:19 UTC 1970
>>> Sending select for 172.27.64.58...
>>> Thu Jan 1 00:00:19 UTC 1970
>>> Lease of 172.27.64.58 obtained, lease time 604800
>>> Thu Jan 1 00:00:19 UTC 1970
>>> deleting routers
>>> Thu Jan 1 00:00:19 UTC 1970
>>> adding dns 172.27.0.17
>>>
>>> real 0m4.355s
>>> user 0m0.043s
>>> sys 0m0.083s
>>>
>>
>> And the time difference is clearly accounted for auto-negotiation time
>> here, as you can see it takes about 3 seconds for Gigabit Ethernet to
>> auto-negotiate and that seems completely acceptable and normal to me
>> since it is a more involved process than lower speeds.
>>
>>>
>>>
>>> OK, so now it works (by accident?) even on 100 Mbps switch, but it still
>>> prints "flow control rx/tx"...
>>
>> Because your link partner advertises flow control, and that's what
>> phydev->pause and phydev->asym_pause report (I know it's confusing, but
>> that's what it is at the moment).
>
> Thanks.
> Could you confirm that Mason's patch is correct and/or that it does not
> has negative side-effects?
The patch is not correct nor incorrect per-se, it changes the default
policy of having pause frames advertised by default to not having them
advertised by default. This influences both your Ethernet MAC and the
link partner in that the result is either flow control is enabled
(before) or it is not (with the patch). There must be something amiss if
you see packet loss or some kind of problem like that with an early
exchange such as DHCP. Flow control tend to kick in under higher packet
rates (at least, that's what you expect).
>
> Right now we know that Mason's patch makes this work, but we do not understand
> why nor its implications.
You need to understand why, right now, the way this problem is
presented, you came up with a workaround, not with the root cause or the
solution. What does your link partner (switch?) reports, that is, what
is the ethtool output when you have a link up from your nb8800 adapter?
--
Florian
^ permalink raw reply
* Re: [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Catalin Marinas @ 2016-11-14 18:19 UTC (permalink / raw)
To: Mark Rutland
Cc: Laura Abbott, Ard Biesheuvel, x86, Will Deacon, linux-kernel,
linux-mm, Ingo Molnar, H. Peter Anvin, Joonsoo Kim,
Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20161103155106.GF25852@remoulade>
On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
> > On 11/02/2016 04:52 PM, Mark Rutland wrote:
> > >On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
> > >>
> > >>__pa_symbol is technically the marco that should be used for kernel
> > >>symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
> > >
> > >Nit: s/marco/macro/
> > >
> > >I see there are some other uses of __pa() that look like they could/should be
> > >__pa_symbol(), e.g. in mark_rodata_ro().
> > >
> > >I guess strictly speaking those need to be updated to? Or is there a reason
> > >that we should not?
> >
> > If the concept of __pa_symbol is okay then yes I think all uses of __pa
> > should eventually be converted for consistency and debugging.
>
> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
> for consistency with other architectures.
At a quick grep, it seems to only be used by mips and x86 and a single
place in mm/memblock.c.
Since we haven't seen any issues on arm/arm64 without this macro, can we
not just continue to use __pa()?
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Catalin Marinas @ 2016-11-14 18:19 UTC (permalink / raw)
To: Mark Rutland
Cc: Laura Abbott, Ard Biesheuvel, x86, Will Deacon, linux-kernel,
linux-mm, Ingo Molnar, H. Peter Anvin, Joonsoo Kim,
Thomas Gleixner, Andrew Morton, linux-arm-kernel,
Marek Szyprowski
In-Reply-To: <20161103155106.GF25852@remoulade>
On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
> > On 11/02/2016 04:52 PM, Mark Rutland wrote:
> > >On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
> > >>
> > >>__pa_symbol is technically the marco that should be used for kernel
> > >>symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
> > >
> > >Nit: s/marco/macro/
> > >
> > >I see there are some other uses of __pa() that look like they could/should be
> > >__pa_symbol(), e.g. in mark_rodata_ro().
> > >
> > >I guess strictly speaking those need to be updated to? Or is there a reason
> > >that we should not?
> >
> > If the concept of __pa_symbol is okay then yes I think all uses of __pa
> > should eventually be converted for consistency and debugging.
>
> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
> for consistency with other architectures.
At a quick grep, it seems to only be used by mips and x86 and a single
place in mm/memblock.c.
Since we haven't seen any issues on arm/arm64 without this macro, can we
not just continue to use __pa()?
Thanks.
--
Catalin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [PATCHv2 5/6] arm64: Use __pa_symbol for _end
From: Catalin Marinas @ 2016-11-14 18:19 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20161103155106.GF25852@remoulade>
On Thu, Nov 03, 2016 at 03:51:07PM +0000, Mark Rutland wrote:
> On Wed, Nov 02, 2016 at 05:56:42PM -0600, Laura Abbott wrote:
> > On 11/02/2016 04:52 PM, Mark Rutland wrote:
> > >On Wed, Nov 02, 2016 at 03:00:53PM -0600, Laura Abbott wrote:
> > >>
> > >>__pa_symbol is technically the marco that should be used for kernel
> > >>symbols. Switch to this as a pre-requisite for DEBUG_VIRTUAL.
> > >
> > >Nit: s/marco/macro/
> > >
> > >I see there are some other uses of __pa() that look like they could/should be
> > >__pa_symbol(), e.g. in mark_rodata_ro().
> > >
> > >I guess strictly speaking those need to be updated to? Or is there a reason
> > >that we should not?
> >
> > If the concept of __pa_symbol is okay then yes I think all uses of __pa
> > should eventually be converted for consistency and debugging.
>
> I have no strong feelings either way about __pa_symbol(); I'm not clear on what
> the purpose of __pa_symbol() is specifically, but I'm happy even if it's just
> for consistency with other architectures.
At a quick grep, it seems to only be used by mips and x86 and a single
place in mm/memblock.c.
Since we haven't seen any issues on arm/arm64 without this macro, can we
not just continue to use __pa()?
Thanks.
--
Catalin
^ permalink raw reply
* Re: [PATCH v2 01/11] x86/domctl: Add XEN_DOMCTL_set_avail_vcpus
From: Andrew Cooper @ 2016-11-14 18:19 UTC (permalink / raw)
To: Boris Ostrovsky, xen-devel; +Cc: wei.liu2, ian.jackson, jbeulich, roger.pau
In-Reply-To: <eaaeede8-dbaa-a14d-c49c-3e2e58839048@oracle.com>
On 14/11/16 17:48, Boris Ostrovsky wrote:
> On 11/14/2016 12:17 PM, Andrew Cooper wrote:
>>>> I am not convinced though that we can start enforcing this new VCPU
>>>> count, at least for PV guests. They expect to start all max VCPUs and
>>>> then offline them. This, of course, can be fixed but all non-updated
>>>> kernels will stop booting.
>>> How about we don't clear _VPF_down if the bit in the availability bitmap
>>> is not set?
>> This is yet another PV mess. We clearly need to quirk PV guests as the
>> exception to sanity, given that they expect (and have been able to)
>> online all cpus at start-of-day.
>>
>> To avoid race conditions, you necessarily need to be able to set a
>> reduced permitted map before asking the VM to unplug.
>>
>> For HVM guests, we can set a proper permitted map at boot, and really
>> should do so.
>>
>> For PV guests, we have to wait until it has completed its SMP bringup
>> before reducing the permitted set. Therefore, making the initial
>> set_avail_vcpus call could be deferred until the first unplug request?
> I am not sure how we can determine in the hypervisor that a guest has
> completed the bringup: I don't think we can rely on the last VCPU (which
> is maxvcpu-1) doing VCPUOP_up. Just to mess up with the hypervisor the
> guest may decide to only bring up (maxvcpus-2) VCPUs. In other words, we
> can't assume a well-behaved guest.
I wasn't suggesting relying on the guest. I was referring to the first
unplug request at the toolstack level.
> And then, even if we do determine the point when (maxvcpus-1) VCPUs are
> all up, when do we clamp them down to avail_vcpus? For the same reason,
> we can't assume that the guest will VCPUOP_down all extra VCPUs.
If at some point we observe all vcpus being up, then we could set the
restricted map then. However, I can't think of a useful way of
identifying this point.
>> It also occurs to me that you necessarily need a get_avail_vcpus
>> hypercall to be able to use this interface sensibly from the toolstack.
> We could modify getdomaininfo but that would make set_avail_vcpus domctl
> non-symmetrical.
>
> And what would the use of this information be anyway?
Well, for a start, this information needs to move in the migration
stream, or by migrating a VM you will lose its current availability
bitmap and reintroduce the problem we are trying to solve.
>
> -boris
>
>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH v2 net-next 0/6] bpf: LRU map
From: David Miller @ 2016-11-14 18:19 UTC (permalink / raw)
To: kafai; +Cc: netdev, ast, daniel, kernel-team
In-Reply-To: <1478890511-1346984-1-git-send-email-kafai@fb.com>
From: Martin KaFai Lau <kafai@fb.com>
Date: Fri, 11 Nov 2016 10:55:05 -0800
> This patch set adds LRU map implementation to the existing BPF map
> family.
Alexei and Daniel, can I please get some review of this series?
Thank you.
^ 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.