* [PATCH] powerpc: Include .BTF section
From: Naveen N. Rao @ 2020-02-20 11:31 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev
Selecting CONFIG_DEBUG_INFO_BTF results in the below warning from ld:
ld: warning: orphan section `.BTF' from `.btf.vmlinux.bin.o' being placed in section `.BTF'
Include .BTF section in vmlinux explicitly to fix the same.
Signed-off-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
---
arch/powerpc/kernel/vmlinux.lds.S | 6 ++++++
1 file changed, 6 insertions(+)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index b4c89a1acebb..a32d478a7f41 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -303,6 +303,12 @@ SECTIONS
*(.branch_lt)
}
+#ifdef CONFIG_DEBUG_INFO_BTF
+ .BTF : AT(ADDR(.BTF) - LOAD_OFFSET) {
+ *(.BTF)
+ }
+#endif
+
.opd : AT(ADDR(.opd) - LOAD_OFFSET) {
__start_opd = .;
KEEP(*(.opd))
--
2.24.1
^ permalink raw reply related
* [dpdk-dev] [PATCH v2] net/mlx5: fix match on Ethertype and CVLAN tag
From: Dekel Peled @ 2020-02-20 11:33 UTC (permalink / raw)
To: matan, viacheslavo, rasland; +Cc: dev, stable
In-Reply-To: <15d7594cc67448389e09213b2ed13e907c471e3a.1582124890.git.dekelp@mellanox.com>
HW supports match on one Ethertype, the Ethertype following the last
VLAN tag of the packet (see PRM).
Previous patch added specific handling for packets with VLAN tag,
after setting match on Ethertype.
This patch moves the handling of packets with VLAN tag, to be done
before and instead of setting match on Ethertype.
Previous patch also added, as part of specific handling for packets
with VLAN tag, the setting of cvlan_tag mask bit in translation of
L3 items.
In case of L3 tunnel there is no inner L2 header, so setting this
mask bit is wrong and causes match failures.
This patch adds check to make sure L2 header exists before setting
cvlan_tag mask bit for L3 items.
Fixes: 00f75a40576b ("net/mlx5: fix VLAN match for DV mode")
Cc: stable@dpdk.org
Signed-off-by: Dekel Peled <dekelp@mellanox.com>
---
drivers/net/mlx5/mlx5_flow_dv.c | 42 ++++++++++++++++++++++++++++++++---------
1 file changed, 33 insertions(+), 9 deletions(-)
diff --git a/drivers/net/mlx5/mlx5_flow_dv.c b/drivers/net/mlx5/mlx5_flow_dv.c
index 467d1ce..6f15a91 100644
--- a/drivers/net/mlx5/mlx5_flow_dv.c
+++ b/drivers/net/mlx5/mlx5_flow_dv.c
@@ -5213,19 +5213,27 @@ struct field_modify_info modify_tcp[] = {
/* The value must be in the range of the mask. */
for (i = 0; i < sizeof(eth_m->dst); ++i)
l24_v[i] = eth_m->src.addr_bytes[i] & eth_v->src.addr_bytes[i];
- MLX5_SET(fte_match_set_lyr_2_4, headers_m, ethertype,
- rte_be_to_cpu_16(eth_m->type));
- l24_v = MLX5_ADDR_OF(fte_match_set_lyr_2_4, headers_v, ethertype);
- *(uint16_t *)(l24_v) = eth_m->type & eth_v->type;
if (eth_v->type) {
/* When ethertype is present set mask for tagged VLAN. */
MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
/* Set value for tagged VLAN if ethertype is 802.1Q. */
if (eth_v->type == RTE_BE16(RTE_ETHER_TYPE_VLAN) ||
- eth_v->type == RTE_BE16(RTE_ETHER_TYPE_QINQ))
+ eth_v->type == RTE_BE16(RTE_ETHER_TYPE_QINQ)) {
MLX5_SET(fte_match_set_lyr_2_4, headers_v, cvlan_tag,
1);
+ /* Return here to avoid setting match on ethertype. */
+ return;
+ }
}
+ /*
+ * HW supports match on one Ethertype, the Ethertype following the last
+ * VLAN tag of the packet (see PRM).
+ * Set match on ethertype only if ETH header is not followed by VLAN.
+ */
+ MLX5_SET(fte_match_set_lyr_2_4, headers_m, ethertype,
+ rte_be_to_cpu_16(eth_m->type));
+ l24_v = MLX5_ADDR_OF(fte_match_set_lyr_2_4, headers_v, ethertype);
+ *(uint16_t *)(l24_v) = eth_m->type & eth_v->type;
}
/**
@@ -5299,6 +5307,8 @@ struct field_modify_info modify_tcp[] = {
* Flow matcher value.
* @param[in] item
* Flow pattern to translate.
+ * @param[in] item_flags
+ * Bit-fields that holds the items detected until now.
* @param[in] inner
* Item is inner pattern.
* @param[in] group
@@ -5307,6 +5317,7 @@ struct field_modify_info modify_tcp[] = {
static void
flow_dv_translate_item_ipv4(void *matcher, void *key,
const struct rte_flow_item *item,
+ const uint64_t item_flags,
int inner, uint32_t group)
{
const struct rte_flow_item_ipv4 *ipv4_m = item->mask;
@@ -5366,7 +5377,12 @@ struct field_modify_info modify_tcp[] = {
ipv4_m->hdr.next_proto_id);
MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_protocol,
ipv4_v->hdr.next_proto_id & ipv4_m->hdr.next_proto_id);
- MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
+ /*
+ * On outer header (which must contains L2), or inner header with L2,
+ * set cvlan_tag mask bit to mark this packet as untagged.
+ */
+ if (!inner || item_flags & MLX5_FLOW_LAYER_INNER_L2)
+ MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
}
/**
@@ -5378,6 +5394,8 @@ struct field_modify_info modify_tcp[] = {
* Flow matcher value.
* @param[in] item
* Flow pattern to translate.
+ * @param[in] item_flags
+ * Bit-fields that holds the items detected until now.
* @param[in] inner
* Item is inner pattern.
* @param[in] group
@@ -5386,6 +5404,7 @@ struct field_modify_info modify_tcp[] = {
static void
flow_dv_translate_item_ipv6(void *matcher, void *key,
const struct rte_flow_item *item,
+ const uint64_t item_flags,
int inner, uint32_t group)
{
const struct rte_flow_item_ipv6 *ipv6_m = item->mask;
@@ -5471,7 +5490,12 @@ struct field_modify_info modify_tcp[] = {
ipv6_m->hdr.proto);
MLX5_SET(fte_match_set_lyr_2_4, headers_v, ip_protocol,
ipv6_v->hdr.proto & ipv6_m->hdr.proto);
- MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
+ /*
+ * On outer header (which must contains L2), or inner header with L2,
+ * set cvlan_tag mask bit to mark this packet as untagged.
+ */
+ if (!inner || item_flags & MLX5_FLOW_LAYER_INNER_L2)
+ MLX5_SET(fte_match_set_lyr_2_4, headers_m, cvlan_tag, 1);
}
/**
@@ -7574,7 +7598,7 @@ struct field_modify_info modify_tcp[] = {
mlx5_flow_tunnel_ip_check(items, next_protocol,
&item_flags, &tunnel);
flow_dv_translate_item_ipv4(match_mask, match_value,
- items, tunnel,
+ items, item_flags, tunnel,
dev_flow->group);
matcher.priority = MLX5_PRIORITY_MAP_L3;
last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV4 :
@@ -7597,7 +7621,7 @@ struct field_modify_info modify_tcp[] = {
mlx5_flow_tunnel_ip_check(items, next_protocol,
&item_flags, &tunnel);
flow_dv_translate_item_ipv6(match_mask, match_value,
- items, tunnel,
+ items, item_flags, tunnel,
dev_flow->group);
matcher.priority = MLX5_PRIORITY_MAP_L3;
last_item = tunnel ? MLX5_FLOW_LAYER_INNER_L3_IPV6 :
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v3 16/17] s390x: protvirt: Handle SIGP store status correctly
From: Janosch Frank @ 2020-02-20 11:30 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220120244.2ea06cec.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 1703 bytes --]
On 2/20/20 12:02 PM, Cornelia Huck wrote:
> On Fri, 14 Feb 2020 10:16:35 -0500
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> Status storing is not done by QEMU anymore, but is handled by SIE.
>>
>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>> Reviewed-by: Thomas Huth <thuth@redhat.com>
>> ---
>> target/s390x/helper.c | 4 ++++
>> target/s390x/sigp.c | 1 +
>> 2 files changed, 5 insertions(+)
>>
>> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
>> index a3a49164e4..3800c4b395 100644
>> --- a/target/s390x/helper.c
>> +++ b/target/s390x/helper.c
>> @@ -246,6 +246,10 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool store_arch)
>> hwaddr len = sizeof(*sa);
>> int i;
>>
>> + if (cpu->env.pv) {
>> + return 0;
>> + }
>> +
>> sa = cpu_physical_memory_map(addr, &len, 1);
>> if (!sa) {
>> return -EFAULT;
>> diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
>> index c604f17710..da0cfb97de 100644
>> --- a/target/s390x/sigp.c
>> +++ b/target/s390x/sigp.c
>> @@ -497,6 +497,7 @@ void do_stop_interrupt(CPUS390XState *env)
>> if (s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu) == 0) {
>> qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
>> }
>> + /* Storing will occur on next SIE entry for fmt 4 */
>
> What's fmt 4?
PVMs are using a FMT 4 SCB instead of the normal format 2 one.
So I guess this should read:
/* Storing will occur on next SIE entry for protected VMs */
>
>> if (cpu->env.sigp_order == SIGP_STOP_STORE_STATUS) {
>> s390_store_status(cpu, S390_STORE_STATUS_DEF_ADDR, true);
>> }
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH 4/5] perf metricgroup: Support metric constraint
From: Jiri Olsa @ 2020-02-20 11:35 UTC (permalink / raw)
To: kan.liang
Cc: acme, mingo, peterz, linux-kernel, mark.rutland, namhyung,
ravi.bangoria, yao.jin, ak
In-Reply-To: <1582139320-75181-5-git-send-email-kan.liang@linux.intel.com>
On Wed, Feb 19, 2020 at 11:08:39AM -0800, kan.liang@linux.intel.com wrote:
SNIP
> +static bool violate_nmi_constraint;
> +
> +static bool metricgroup__has_constraint(struct pmu_event *pe)
> +{
> + if (!pe->metric_constraint)
> + return false;
> +
> + if (!strcmp(pe->metric_constraint, "NO_NMI_WATCHDOG") &&
> + sysctl__nmi_watchdog_enabled()) {
> + pr_warning("Splitting metric group %s into standalone metrics.\n",
> + pe->metric_name);
> + violate_nmi_constraint = true;
no static flags plz.. can't you just print that rest of the warning in here?
jirka
> + return true;
> + }
> +
> + return false;
> +}
> +
> static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> struct list_head *group_list)
> {
> @@ -460,7 +490,10 @@ static int metricgroup__add_metric(const char *metric, struct strbuf *events,
> if (events->len > 0)
> strbuf_addf(events, ",");
>
> - metricgroup__add_metric_weak_group(events, ids, idnum);
> + if (metricgroup__has_constraint(pe))
> + metricgroup__add_metric_non_group(events, ids, idnum);
> + else
> + metricgroup__add_metric_weak_group(events, ids, idnum);
>
> eg = malloc(sizeof(struct egroup));
> if (!eg) {
> @@ -544,6 +577,13 @@ int metricgroup__parse_groups(const struct option *opt,
> strbuf_release(&extra_events);
> ret = metricgroup__setup_events(&group_list, perf_evlist,
> metric_events);
> +
> + if (violate_nmi_constraint) {
> + pr_warning("Try disabling the NMI watchdog to comply NO_NMI_WATCHDOG metric constraint:\n"
> + " echo 0 > /proc/sys/kernel/nmi_watchdog\n"
> + " perf stat ...\n"
> + " echo 1 > /proc/sys/kernel/nmi_watchdog\n");
> + }
> out:
> metricgroup__free_egroups(&group_list);
> return ret;
> --
> 2.7.4
>
^ permalink raw reply
* Re: [PATCHv5 29/34] drm/arm/malidp: Make verify funcitons invocations independent
From: Boris Brezillon @ 2020-02-20 11:35 UTC (permalink / raw)
To: Andrzej Pietrasiewicz
Cc: Mihail Atanassov, kernel, David Airlie, Liviu Dudau, Sandy Huang,
dri-devel, James Wang, Ayan Halder, Sean Paul
In-Reply-To: <20200220122913.5cd80425@collabora.com>
On Thu, 20 Feb 2020 12:29:13 +0100
Boris Brezillon <boris.brezillon@collabora.com> wrote:
> On Thu, 20 Feb 2020 12:26:01 +0100
> Boris Brezillon <boris.brezillon@collabora.com> wrote:
>
> > In the subject: s/funcitons/functions/
> >
> > On Tue, 17 Dec 2019 15:50:15 +0100
> > Andrzej Pietrasiewicz <andrzej.p@collabora.com> wrote:
> >
> > > This will make it easier to transition to generic afbc-aware helpers.
> > >
> > > Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@collabora.com>
> >
> > Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
>
> Wait, patch 30 is this patch completely irrelevant, so I take R-b back
s/patch 30 is this patch completely irrelevant/this patch is completely
irrelevant if patch 30 is applied/
> :-). You can just squash that one in patch 30.
>
> >
> > > ---
> > > drivers/gpu/drm/arm/malidp_drv.c | 6 +++---
> > > 1 file changed, 3 insertions(+), 3 deletions(-)
> > >
> > > diff --git a/drivers/gpu/drm/arm/malidp_drv.c b/drivers/gpu/drm/arm/malidp_drv.c
> > > index 37d92a06318e..961e5a3f5b08 100644
> > > --- a/drivers/gpu/drm/arm/malidp_drv.c
> > > +++ b/drivers/gpu/drm/arm/malidp_drv.c
> > > @@ -362,10 +362,10 @@ static bool
> > > malidp_verify_afbc_framebuffer(struct drm_device *dev, struct drm_file *file,
> > > const struct drm_mode_fb_cmd2 *mode_cmd)
> > > {
> > > - if (malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > > - return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > > + if (!malidp_verify_afbc_framebuffer_caps(dev, mode_cmd))
> > > + return false;
> > >
> > > - return false;
> > > + return malidp_verify_afbc_framebuffer_size(dev, file, mode_cmd);
> > > }
> > >
> > > static struct drm_framebuffer *
> >
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>
> _______________________________________________
> dri-devel mailing list
> dri-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/dri-devel
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH net-next 0/3] VLANs, DSA switches and multiple bridges
From: Russell King - ARM Linux admin @ 2020-02-20 11:35 UTC (permalink / raw)
To: Vivien Didelot
Cc: Andrew Lunn, Florian Fainelli, Heiner Kallweit, Ido Schimmel,
David S. Miller, Ivan Vecera, Jakub Kicinski, Jiri Pirko, netdev
In-Reply-To: <20200219130707.GB245247@t480s.localdomain>
On Wed, Feb 19, 2020 at 01:07:07PM -0500, Vivien Didelot wrote:
> Hi Russell,
>
> Some switches like the Marvell 88E6060 don't have a VTU, so programming the
> default PVID would return -EOPNOTSUPP.
The 88e6060 has its own driver separate from mv88e6xxx.
> Switches supporting only global VLAN
> filtering cannot have a VLAN filtering aware bridge as well as a non VLAN
> filtering aware bridge spanning their ports at the same time. But all this
> shouldn't be a problem because drivers inform the stack whether they support
> ds->vlan_filtering per-port, globally or not. We should simply reject the
> operation when vlan_filtering is being enabled on unsupported hardware.
>
> Linux bridge is the reference for the implementation of an Ethernet bridge,
> if it programs VLAN entries, supported DSA hardware must do so. I'm not a
> fan of having our own bridge logic in DSA, so the limitation implemented by
> 2ea7a679ca2a ("net: dsa: Don't add vlans when vlan filtering is disabled")
> needs to go in my opinion.
... which is basically what patch 3 is doing, but in a per-driver
manner.
The checks introduced in 2ea7a679ca2a ("net: dsa: Don't add vlans when
vlan filtering is disabled") were raised up a level by c5335d737ff3
("net: dsa: check bridge VLAN in slave operations") to their present
positions, which are then touched by my patch 3 to make the checks
conditional.
--
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 12.1Mbps down 622kbps up
According to speedtest.net: 11.9Mbps down 500kbps up
^ permalink raw reply
* Re: [PATCH v3 16/17] s390x: protvirt: Handle SIGP store status correctly
From: Cornelia Huck @ 2020-02-20 11:34 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <cf0c8c3c-06d9-cc49-886e-c54281759dff@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 1922 bytes --]
On Thu, 20 Feb 2020 12:30:28 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:
> On 2/20/20 12:02 PM, Cornelia Huck wrote:
> > On Fri, 14 Feb 2020 10:16:35 -0500
> > Janosch Frank <frankja@linux.ibm.com> wrote:
> >
> >> Status storing is not done by QEMU anymore, but is handled by SIE.
> >>
> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> >> Reviewed-by: Thomas Huth <thuth@redhat.com>
> >> ---
> >> target/s390x/helper.c | 4 ++++
> >> target/s390x/sigp.c | 1 +
> >> 2 files changed, 5 insertions(+)
> >>
> >> diff --git a/target/s390x/helper.c b/target/s390x/helper.c
> >> index a3a49164e4..3800c4b395 100644
> >> --- a/target/s390x/helper.c
> >> +++ b/target/s390x/helper.c
> >> @@ -246,6 +246,10 @@ int s390_store_status(S390CPU *cpu, hwaddr addr, bool store_arch)
> >> hwaddr len = sizeof(*sa);
> >> int i;
> >>
> >> + if (cpu->env.pv) {
> >> + return 0;
> >> + }
> >> +
> >> sa = cpu_physical_memory_map(addr, &len, 1);
> >> if (!sa) {
> >> return -EFAULT;
> >> diff --git a/target/s390x/sigp.c b/target/s390x/sigp.c
> >> index c604f17710..da0cfb97de 100644
> >> --- a/target/s390x/sigp.c
> >> +++ b/target/s390x/sigp.c
> >> @@ -497,6 +497,7 @@ void do_stop_interrupt(CPUS390XState *env)
> >> if (s390_cpu_set_state(S390_CPU_STATE_STOPPED, cpu) == 0) {
> >> qemu_system_shutdown_request(SHUTDOWN_CAUSE_GUEST_SHUTDOWN);
> >> }
> >> + /* Storing will occur on next SIE entry for fmt 4 */
> >
> > What's fmt 4?
>
> PVMs are using a FMT 4 SCB instead of the normal format 2 one.
>
> So I guess this should read:
> /* Storing will occur on next SIE entry for protected VMs */
Better :)
>
> >
> >> if (cpu->env.sigp_order == SIGP_STOP_STORE_STATUS) {
> >> s390_store_status(cpu, S390_STORE_STATUS_DEF_ADDR, true);
> >> }
> >
> >
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [yocto] Bitbake returning non-zero due to sstate errors
From: Richard Purdie @ 2020-02-20 11:36 UTC (permalink / raw)
To: Paul Barker, Yocto discussion list
In-Reply-To: <CAM9ZRVvDHTvvKr1Tdc+C1ZdTv2DSX8JJ9bYhHc0c-wre4qg5LA@mail.gmail.com>
On Thu, 2020-02-20 at 11:26 +0000, Paul Barker wrote:
> In my new CI setup I'm using an sstate mirror which seems to have
> some
> occasional download issues. This results in the setscene task
> failing.
> For example:
>
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: Fetcher failure: Unable to find file
> file://fd/sstate:qt3d:armv7at2hf-neon-linux-
> gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> 74_package_write_ipk.tgz;downloadfilename=fd/sstate:qt3d:armv7at2hf-
> neon-linux-gnueabi:5.13.2+gitAUTOINC+93361f1a59:r0:armv7at2hf-
> neon:3:fda6c3edff0205b07ff176cf16771247117fa310bc65a6a1df6befc4230e0a
> 74_package_write_ipk.tgz
> anywhere. The paths that were searched were:
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> /builds/SanCloudLtd/sancloud-arago/build/sstate-cache
> ERROR: qt3d-5.13.2+gitAUTOINC+93361f1a59-r0
> do_package_write_ipk_setscene: No suitable staging package found
> ERROR: Logfile of failure stored in:
> /builds/SanCloudLtd/sancloud-arago/build/tmp/work/armv7at2hf-neon-
> linux-gnueabi/qt3d/5.13.2+gitAUTOINC+93361f1a59-
> r0/temp/log.do_package_write_ipk_setscene.10524
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk_setscene: Failed
> WARNING: Setscene task
> (/builds/SanCloudLtd/sancloud-arago/sources/meta-qt5/recipes-
> qt/qt5/qt3d_git.bb:do_package_write_ipk_setscene)
> failed with exit code '1' - real task will be run instead
>
> As indicated in the final warning message there the real tasks run
> since no sstate artifact is available. These tasks succeed:
>
> NOTE: recipe qt3d-5.13.2+gitAUTOINC+93361f1a59-r0: task
> do_package_write_ipk: Succeeded
>
> The result is a successful build of the desired images. However, the
> build is marked as a failure due to those sstate errors:
>
> Summary: There were 11 ERROR messages shown, returning a non-zero
> exit code.
>
> Is this the expected behaviour? The final images are built correctly.
> I can't see any simple way to mask those setscene errors but I might
> be missing something.
>
> The full log can be seen at
> https://gitlab.com/SanCloudLtd/sancloud-arago/-/jobs/443901140/raw.
> I'm on the zeus branch here, I'll try to re-test on master later if I
> can.
We've discussed this before and it can be argued either way.
Personally, I worry about why artefacts "disappear" and this is why its
an error, files should not be disappearing part way through a build.
From a bitbake perspective, a task really did fail and task failures
are errors. The fact it was able to recover is a bonus.
Perhaps it should be a warning now we have levels of warnings that are
meaningful. Previously we threw so many, this would have been one more
lost amongst many. I know many people don't like the behaviour.
Cheers,
Richard
^ permalink raw reply
* Re: [dpdk-dev] 17.11.10 (LTS) patches review and test
From: Trahe, Fiona @ 2020-02-20 11:37 UTC (permalink / raw)
To: Luca Boccassi, dpdk stable, dev@dpdk.org; +Cc: Trahe, Fiona
In-Reply-To: <CAMw=ZnTExpkbzZRBwwejPXy1MQf2X37XzLbM12XyKBpQqQ6aFw@mail.gmail.com>
Hi Luca,
> -----Original Message-----
>
> Postponing again by one week to give more time to look into the QAT issue.
>
> Apologies again for any issue it might cause.
Thanks for that and sorry about the delay.
We're hoping to send a fix for that today.
Fiona
^ permalink raw reply
* [PATCH] selftests/rseq: Fix out-of-tree compilation
From: Michael Ellerman @ 2020-02-20 11:37 UTC (permalink / raw)
To: linux-kselftest
Cc: skhan, linux-kernel, mathieu.desnoyers, peterz, paulmck,
boqun.feng
Currently if you build with O=... the rseq tests don't build:
$ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq
make: Entering directory '/linux/tools/testing/selftests'
...
make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ -shared -fPIC rseq.c -lpthread -o /linux/output/rseq/librseq.so
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test
/usr/bin/ld: cannot find -lrseq
collect2: error: ld returned 1 exit status
This is because the library search path points to the source
directory, not the output.
We can fix it by changing the library search path to $(OUTPUT).
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
This works in all cases.
With O= set:
$ make O=$PWD/output -C tools/testing/selftests/ TARGETS=rseq
...
make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/output/rseq/basic_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ basic_percpu_ops_test.c -lpthread -lrseq -o /linux/output/rseq/basic_percpu_ops_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ param_test.c -lpthread -lrseq -o /linux/output/rseq/param_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c -lpthread -lrseq -o /linux/output/rseq/param_test_benchmark
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/output/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE param_test.c -lpthread -lrseq -o /linux/output/rseq/param_test_compare_twice
make[1]: Leaving directory '/linux/tools/testing/selftests/rseq'
make: Leaving directory '/linux/tools/testing/selftests'
And also without, in which case the selftest makefiles set OUTPUT to
the full path of the source directory:
$ make -C tools/testing/selftests/ TARGETS=rseq
...
make[1]: Entering directory '/linux/tools/testing/selftests/rseq'
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -shared -fPIC rseq.c -lpthread -o /linux/tools/testing/selftests/rseq/librseq.so
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_percpu_ops_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_percpu_ops_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_benchmark
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_compare_twice
make[1]: Leaving directory '/linux/tools/testing/selftests/rseq'
make: Leaving directory '/linux/tools/testing/selftests'
And finally, it also works if you build directly in the rseq
directory, eg:
$ cd tools/testing/selftests/rseq
$ make
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -shared -fPIC rseq.c -lpthread -o /linux/tools/testing/selftests/rseq/librseq.so
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ basic_percpu_ops_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/basic_percpu_ops_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DBENCHMARK param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_benchmark
gcc -O2 -Wall -g -I./ -I../../../../usr/include/ -L/linux/tools/testing/selftests/rseq -Wl,-rpath=./ -DRSEQ_COMPARE_TWICE param_test.c -lpthread -lrseq -o /linux/tools/testing/selftests/rseq/param_test_compare_twice
---
tools/testing/selftests/rseq/Makefile | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/rseq/Makefile b/tools/testing/selftests/rseq/Makefile
index d6469535630a..708c1b345245 100644
--- a/tools/testing/selftests/rseq/Makefile
+++ b/tools/testing/selftests/rseq/Makefile
@@ -4,7 +4,7 @@ ifneq ($(shell $(CC) --version 2>&1 | head -n 1 | grep clang),)
CLANG_FLAGS += -no-integrated-as
endif
-CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/ -L./ -Wl,-rpath=./ \
+CFLAGS += -O2 -Wall -g -I./ -I../../../../usr/include/ -L$(OUTPUT) -Wl,-rpath=./ \
$(CLANG_FLAGS)
LDLIBS += -lpthread
base-commit: 11a48a5a18c63fd7621bb050228cebf13566e4d8
--
2.21.1
^ permalink raw reply related
* Re: [Xen-devel] [PATCH 2/5] libxl/PCI: establish per-device reserved memory policy earlier
From: Wei Liu @ 2020-02-20 11:38 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <2124c861-bd26-1ec4-3b38-0cf24ee87c79@suse.com>
On Tue, Feb 18, 2020 at 04:46:44PM +0100, Jan Beulich wrote:
> Reserved device memory region processing as well as E820 table creation
> happen earlier than the adding of (PCI) devices, yet they consume the
> policy (e.g. to decide whether to add entries to the E820 table). But so
> far it was only at the stage of PCI device addition that the final
> policy was established (i.e. if not explicitly specified by the guest
> config file).
>
> Note that I couldn't find the domain ID to be available in
> libxl__domain_device_construct_rdm(), but observing that
> libxl__device_pci_setdefault() also doesn't use it, for the time being
> DOMID_INVALID gets passed. An obvious alternative would be to drop the
> unused parameter/argument, yet at that time the question would be
> whether to also drop other unused ones.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [PATCH 0/5] Support metric group constraint
From: Jiri Olsa @ 2020-02-20 11:39 UTC (permalink / raw)
To: kan.liang
Cc: acme, mingo, peterz, linux-kernel, mark.rutland, namhyung,
ravi.bangoria, yao.jin, ak
In-Reply-To: <1582139320-75181-1-git-send-email-kan.liang@linux.intel.com>
On Wed, Feb 19, 2020 at 11:08:35AM -0800, kan.liang@linux.intel.com wrote:
> From: Kan Liang <kan.liang@linux.intel.com>
>
> Some metric groups, e.g. Page_Walks_Utilization, will never count when
> NMI watchdog is enabled.
>
> $echo 1 > /proc/sys/kernel/nmi_watchdog
> $perf stat -M Page_Walks_Utilization
>
> Performance counter stats for 'system wide':
>
> <not counted> itlb_misses.walk_pending (0.00%)
> <not counted> dtlb_load_misses.walk_pending (0.00%)
> <not counted> dtlb_store_misses.walk_pending (0.00%)
> <not counted> ept.walk_pending (0.00%)
> <not counted> cycles (0.00%)
>
> 2.343460588 seconds time elapsed
>
> Some events weren't counted. Try disabling the NMI watchdog:
> echo 0 > /proc/sys/kernel/nmi_watchdog
> perf stat ...
> echo 1 > /proc/sys/kernel/nmi_watchdog
> The events in group usually have to be from the same PMU. Try
> reorganizing the group.
>
> A metric group is a weak group, which relies on group validation
> code in the kernel to determine whether to be opened as a group or
> a non-group. However, group validation code may return false-positives,
> especially when NMI watchdog is enabled. (The metric group is allowed
> as a group but will never be scheduled.)
>
> The attempt to fix the group validation code has been rejected.
> https://lore.kernel.org/lkml/20200117091341.GX2827@hirez.programming.kicks-ass.net/
> Because we cannot accurately predict whether the group can be scheduled
> as a group, only by checking current status.
>
> This patch set provides another solution to mitigate the issue.
> Add "MetricConstraint" in event list, which provides a hint for perf tool,
> e.g. "MetricConstraint": "NO_NMI_WATCHDOG". Perf tool can change the
> metric group to non-group (standalone metrics) if NMI watchdog is enabled.
the problem is in the missing counter, that's taken by NMI watchdog, right?
and it's problem for any metric that won't fit to the available
counters.. shouldn't we rather do this workaround for any metric
that wouldn't fit in available counters? not just for chosen
ones..?
thanks,
jirka
^ permalink raw reply
* Re: [cip-dev] [PATCH 4.19.y-cip 17/23] usb: typec: add dependency for TYPEC_HD3SS3220
From: Marian-Cristian Rotariu @ 2020-02-20 11:40 UTC (permalink / raw)
To: Pavel Machek; +Cc: cip-dev@lists.cip-project.org
In-Reply-To: <20200219081627.GE31996@amd>
Hi!
> -----Original Message-----
> From: Pavel Machek <pavel@denx.de>
> Sent: 19 February 2020 08:16
> To: Marian-Cristian Rotariu <marian-cristian.rotariu.rb@bp.renesas.com>
> Cc: cip-dev@lists.cip-project.org
> Subject: Re: [cip-dev] [PATCH 4.19.y-cip 17/23] usb: typec: add dependency
> for TYPEC_HD3SS3220
>
> On Tue 2020-02-18 14:05:14, Marian-Cristian Rotariu wrote:
> > From: Mao Wenan <maowenan@huawei.com>
> >
> > commit da4b5d18dd949abdda7c8ea76c9483b5edd49616 upstream.
> >
> > If CONFIG_TYPEC_HD3SS3220=y, CONFIG_USB_ROLE_SWITCH=m, below
> errors
> > can be found:
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_remove':
> > hd3ss3220.c:(.text+0x64): undefined reference to `usb_role_switch_put'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_dr_set':
> > hd3ss3220.c:(.text+0x154): undefined reference to
> `usb_role_switch_set_role'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_set_role':
> > hd3ss3220.c:(.text+0x294): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x2f4): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x348): undefined reference to
> `usb_role_switch_set_role'
> > hd3ss3220.c:(.text+0x390): undefined reference to
> `usb_role_switch_set_role'
> > drivers/usb/typec/hd3ss3220.o: In function `hd3ss3220_probe':
> > hd3ss3220.c:(.text+0x5e8): undefined reference to
> `fwnode_usb_role_switch_get'
> > hd3ss3220.c:(.text+0x8a4): undefined reference to `usb_role_switch_put'
> > make: *** [vmlinux] Error 1
>
> I guess it is okay here, but for more serious bugs it would be nice to merge
> the buggy patch with a fix -- not to break bisect.
I kind of forgot about bisect. I was mostly focused on keeping the original patches
from upstream (in this case, it is more about the commit message as the fix is trivial).
I will send this patch in v2 also, since you mostly agreed with it. Please let me know
if otherwise.
Cheers,
Marian
_______________________________________________
cip-dev mailing list
cip-dev@lists.cip-project.org
https://lists.cip-project.org/mailman/listinfo/cip-dev
^ permalink raw reply
* Re: [PATCH v2 1/2] Add Cadence XSPI driver
From: Mark Brown @ 2020-02-20 11:40 UTC (permalink / raw)
To: Konrad Kociolek
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-spi-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20200220082354.GA15619-3ZcXq++oLud4Zxsjz0bX7NBPR1lH4CV8@public.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Thu, Feb 20, 2020 at 09:23:56AM +0100, Konrad Kociolek wrote:
> The 02/10/2020 19:16, Mark Brown wrote:
> > > # Add new SPI master controllers in alphabetical order above this line
> > Please keep Kconfig and Makefile alphabetically sorted as the comment in
> > the context from the diff says. :/
> What I see is Kconfig is first and Makefile is second file in diff,
> according to:
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> Is that wrong?
Please keep the *contents* of the files Kconfig and Makefile
alphabetically sorted as the comment in the context from the diff says.
> > > +#ifdef CONFIG_OF
> > > +static const struct of_device_id cdns_xspi_of_match[] = {
> > > + {
> > > + .compatible = "cdns,xspi-nor-fpga",
> > > + },
> > Why -fpga?
> This is because this driver was tested only on FPGA board.
> This driver was not tested for ASIC version as PHY
> initialization algorithm is differ.
So there will need to be a separate compatible for any silicon
integrations? Will that always be the same for all silicon integrations
or should we have properties for the PHY type?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v2 1/2] Add Cadence XSPI driver
From: Mark Brown @ 2020-02-20 11:40 UTC (permalink / raw)
To: Konrad Kociolek; +Cc: linux-kernel, linux-spi
In-Reply-To: <20200220082354.GA15619@global.cadence.com>
[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]
On Thu, Feb 20, 2020 at 09:23:56AM +0100, Konrad Kociolek wrote:
> The 02/10/2020 19:16, Mark Brown wrote:
> > > # Add new SPI master controllers in alphabetical order above this line
> > Please keep Kconfig and Makefile alphabetically sorted as the comment in
> > the context from the diff says. :/
> What I see is Kconfig is first and Makefile is second file in diff,
> according to:
> drivers/spi/Kconfig | 11 +
> drivers/spi/Makefile | 1 +
> Is that wrong?
Please keep the *contents* of the files Kconfig and Makefile
alphabetically sorted as the comment in the context from the diff says.
> > > +#ifdef CONFIG_OF
> > > +static const struct of_device_id cdns_xspi_of_match[] = {
> > > + {
> > > + .compatible = "cdns,xspi-nor-fpga",
> > > + },
> > Why -fpga?
> This is because this driver was tested only on FPGA board.
> This driver was not tested for ASIC version as PHY
> initialization algorithm is differ.
So there will need to be a separate compatible for any silicon
integrations? Will that always be the same for all silicon integrations
or should we have properties for the PHY type?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* Re: [PATCH v3 06/17] s390x: protvirt: Add migration blocker
From: Cornelia Huck @ 2020-02-20 11:39 UTC (permalink / raw)
To: Janosch Frank; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <fbcacbf4-75d6-55f9-2ad3-6cd47b400fce@linux.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 3240 bytes --]
On Thu, 20 Feb 2020 12:24:23 +0100
Janosch Frank <frankja@linux.ibm.com> wrote:
> On 2/20/20 11:48 AM, Cornelia Huck wrote:
> > On Fri, 14 Feb 2020 10:16:25 -0500
> > Janosch Frank <frankja@linux.ibm.com> wrote:
> >
> >> Migration is not yet supported.
> >>
> >> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
> >> ---
> >> hw/s390x/s390-virtio-ccw.c | 16 ++++++++++++++++
> >> 1 file changed, 16 insertions(+)
> >>
> >> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
> >> index 5fa4372083..d64724af91 100644
> >> --- a/hw/s390x/s390-virtio-ccw.c
> >> +++ b/hw/s390x/s390-virtio-ccw.c
> >> @@ -42,6 +42,9 @@
> >> #include "hw/s390x/tod.h"
> >> #include "sysemu/sysemu.h"
> >> #include "hw/s390x/pv.h"
> >> +#include "migration/blocker.h"
> >> +
> >> +static Error *pv_mig_blocker;
> >>
> >> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
> >> {
> >> @@ -373,6 +376,7 @@ static void s390_machine_reset(MachineState *machine)
> >> CPUState *cs, *t;
> >> S390CPU *cpu;
> >> S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
> >> + static Error *local_err;
> >>
> >> /* get the reset parameters, reset them once done */
> >> s390_ipl_get_reset_request(&cs, &reset_type);
> >> @@ -422,6 +426,17 @@ static void s390_machine_reset(MachineState *machine)
> >> }
> >> run_on_cpu(cs, s390_do_cpu_reset, RUN_ON_CPU_NULL);
> >>
> >> + if (!pv_mig_blocker) {
> >> + error_setg(&pv_mig_blocker,
> >> + "protected VMs are currently not migrateable.");
> >> + }
> >> + migrate_add_blocker(pv_mig_blocker, &local_err);
> >
> > If I'm not lost in the context, that's during PV_RESET. I'm a bit
> > confused why you'd add the blocker here?
>
> Where would you want me to add it?
> It's here where we switch into secure mode and I need to block before
> switching and unblock if it fails.
>
> When having the blocker in diag.c, I'd have a hard time unblocking on a
> PV switch fail.
>
> >
> >> + if (local_err) {
> >> + error_report_err(local_err);
> >> + error_free(pv_mig_blocker);
> >> + exit(1);
> >
> > Why the exit()? Can't you fail the call?
>
> Well, if that fails and we go protected, I wouldn't be protected agains
> migrations, right?
No, I meant not go protected, if that's possible.
>
> >
> >> + }
> >> +
> >> if (s390_machine_pv_secure(ms)) {
Ok, I think what confuses me is this call: it reads as if you actually
tear down things if the machine is secure. Call it
s390_machine_pv_make_secure() to make sure it is actively doing
something and not checking a previously set value?
> >> CPU_FOREACH(t) {
> >> s390_pv_vcpu_destroy(t);
> >> @@ -430,6 +445,7 @@ static void s390_machine_reset(MachineState *machine)
> >> ms->pv = false;
> >>
> >> s390_machine_inject_pv_error(cs);
> >> + migrate_del_blocker(pv_mig_blocker);
> >> s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
> >> return;
> >> }
> >
> >
>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
From: Patchwork @ 2020-02-20 11:41 UTC (permalink / raw)
To: Christian König; +Cc: intel-gfx
In-Reply-To: <20200217154509.2265-1-christian.koenig@amd.com>
== Series Details ==
Series: series starting with [1/5] dma-buf: add dynamic DMA-buf handling v14
URL : https://patchwork.freedesktop.org/series/73586/
State : failure
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16603_full
====================================================
Summary
-------
**FAILURE**
Serious unknown changes coming with Patchwork_16603_full absolutely need to be
verified manually.
If you think the reported changes have nothing to do with the changes
introduced in Patchwork_16603_full, please notify your bug team to allow them
to document this new failure mode, which will reduce false positives in CI.
Possible new issues
-------------------
Here are the unknown changes that may have been introduced in Patchwork_16603_full:
### IGT changes ###
#### Possible regressions ####
* igt@gem_exec_balancer@hang:
- shard-tglb: [PASS][1] -> [FAIL][2]
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb2/igt@gem_exec_balancer@hang.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb5/igt@gem_exec_balancer@hang.html
Known issues
------------
Here are the changes found in Patchwork_16603_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][3] -> [SKIP][4] ([fdo#112080]) +11 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_busy@busy-vcs1.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb6/igt@gem_busy@busy-vcs1.html
* igt@gem_exec_schedule@pi-shared-iova-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677]) +1 similar issue
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb8/igt@gem_exec_schedule@pi-shared-iova-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb4/igt@gem_exec_schedule@pi-shared-iova-bsd.html
* igt@gem_exec_schedule@preempt-other-chain-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +5 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_schedule@preempt-other-chain-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb4/igt@gem_exec_schedule@preempt-other-chain-bsd.html
* igt@gem_exec_suspend@basic-s3:
- shard-skl: [PASS][9] -> [INCOMPLETE][10] ([i915#69]) +2 similar issues
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl4/igt@gem_exec_suspend@basic-s3.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl4/igt@gem_exec_suspend@basic-s3.html
* igt@gem_partial_pwrite_pread@reads-uncached:
- shard-hsw: [PASS][11] -> [FAIL][12] ([i915#694])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@gem_partial_pwrite_pread@reads-uncached.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-hsw2/igt@gem_partial_pwrite_pread@reads-uncached.html
* igt@i915_selftest@live_gt_heartbeat:
- shard-skl: [PASS][13] -> [DMESG-FAIL][14] ([fdo#112406])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl7/igt@i915_selftest@live_gt_heartbeat.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl8/igt@i915_selftest@live_gt_heartbeat.html
* igt@i915_selftest@live_gt_lrc:
- shard-tglb: [PASS][15] -> [INCOMPLETE][16] ([i915#1233])
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@live_gt_lrc.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb2/igt@i915_selftest@live_gt_lrc.html
* igt@kms_cursor_legacy@flip-vs-cursor-legacy:
- shard-skl: [PASS][17] -> [FAIL][18] ([IGT#5])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_cursor_legacy@flip-vs-cursor-legacy.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-tglb: [PASS][19] -> [FAIL][20] ([i915#488])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_flip@flip-vs-suspend:
- shard-kbl: [PASS][21] -> [DMESG-WARN][22] ([i915#180])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl3/igt@kms_flip@flip-vs-suspend.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl1/igt@kms_flip@flip-vs-suspend.html
- shard-apl: [PASS][23] -> [DMESG-WARN][24] ([i915#180])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl4/igt@kms_flip@flip-vs-suspend.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl2/igt@kms_flip@flip-vs-suspend.html
* igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu:
- shard-skl: [PASS][25] -> [FAIL][26] ([i915#49])
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl6/igt@kms_frontbuffer_tracking@psr-1p-primscrn-spr-indfb-draw-mmap-cpu.html
* igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min:
- shard-skl: [PASS][27] -> [FAIL][28] ([fdo#108145])
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl1/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl6/igt@kms_plane_alpha_blend@pipe-a-constant-alpha-min.html
* igt@kms_plane_alpha_blend@pipe-b-coverage-7efc:
- shard-skl: [PASS][29] -> [FAIL][30] ([fdo#108145] / [i915#265])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl10/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_plane_alpha_blend@pipe-b-coverage-7efc.html
* igt@kms_psr@psr2_cursor_mmap_cpu:
- shard-iclb: [PASS][31] -> [SKIP][32] ([fdo#109441]) +2 similar issues
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_mmap_cpu.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb1/igt@kms_psr@psr2_cursor_mmap_cpu.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][33] -> [SKIP][34] ([fdo#109276]) +21 similar issues
[33]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@prime_busy@hang-bsd2.html
[34]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb7/igt@prime_busy@hang-bsd2.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-skl: [FAIL][35] ([i915#679]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl1/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
* igt@gem_eio@in-flight-suspend:
- shard-kbl: [INCOMPLETE][37] ([fdo#103665]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@gem_eio@in-flight-suspend.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl1/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [SKIP][39] ([fdo#112146]) -> [PASS][40] +2 similar issues
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@gem_exec_schedule@in-order-bsd.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb3/igt@gem_exec_schedule@in-order-bsd.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [SKIP][41] ([fdo#109276]) -> [PASS][42] +13 similar issues
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb3/igt@gem_exec_schedule@independent-bsd2.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@gem_exec_schedule@independent-bsd2.html
* igt@gem_exec_store@cachelines-vcs1:
- shard-iclb: [SKIP][43] ([fdo#112080]) -> [PASS][44] +7 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_exec_store@cachelines-vcs1.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@gem_exec_store@cachelines-vcs1.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [FAIL][45] ([i915#644]) -> [PASS][46]
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk8/igt@gem_ppgtt@flink-and-close-vma-leak.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-glk1/igt@gem_ppgtt@flink-and-close-vma-leak.html
- shard-apl: [FAIL][47] ([i915#644]) -> [PASS][48]
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl3/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@kms_cursor_crc@pipe-a-cursor-size-change:
- shard-snb: [SKIP][49] ([fdo#109271]) -> [PASS][50] +1 similar issue
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb4/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-snb6/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [DMESG-WARN][51] ([i915#180]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl3/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [FAIL][53] ([i915#79]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl8/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [SKIP][55] ([i915#668]) -> [PASS][56]
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* {igt@kms_hdr@bpc-switch-dpms}:
- shard-skl: [FAIL][57] ([i915#1188]) -> [PASS][58]
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl2/igt@kms_hdr@bpc-switch-dpms.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_hdr@bpc-switch-dpms.html
* igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes:
- shard-apl: [DMESG-WARN][59] ([i915#180]) -> [PASS][60] +1 similar issue
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl7/igt@kms_plane@plane-panning-bottom-right-suspend-pipe-b-planes.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][61] ([fdo#108145]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl3/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_plane_alpha_blend@pipe-c-coverage-7efc:
- shard-skl: [FAIL][63] ([fdo#108145] / [i915#265]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl2/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl6/igt@kms_plane_alpha_blend@pipe-c-coverage-7efc.html
* igt@kms_psr@no_drrs:
- shard-iclb: [FAIL][65] ([i915#173]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@no_drrs.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_primary_page_flip:
- shard-iclb: [SKIP][67] ([fdo#109441]) -> [PASS][68] +2 similar issues
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@psr2_primary_page_flip.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@kms_psr@psr2_primary_page_flip.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][69] ([i915#31]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl2/igt@kms_setmode@basic.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-apl6/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][71] ([i915#69]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-skl5/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@perf@short-reads:
- shard-kbl: [TIMEOUT][73] ([fdo#112271] / [i915#51]) -> [PASS][74]
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@perf@short-reads.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-kbl4/igt@perf@short-reads.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][75] ([i915#831]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@prime_mmap_coherency@ioctl-errors.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-hsw2/igt@prime_mmap_coherency@ioctl-errors.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [SKIP][77] ([fdo#112080]) -> [FAIL][78] ([IGT#28])
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-iclb2/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@normal:
- shard-hsw: [FAIL][79] ([i915#818]) -> [FAIL][80] ([i915#694]) +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@gem_tiled_blits@normal.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/shard-hsw2/igt@gem_tiled_blits@normal.html
{name}: This element is suppressed. This means it is ignored when computing
the status of the difference (SUCCESS, WARNING, or FAILURE).
[IGT#28]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/28
[IGT#5]: https://gitlab.freedesktop.org/drm/igt-gpu-tools/issues/5
[fdo#103665]: https://bugs.freedesktop.org/show_bug.cgi?id=103665
[fdo#108145]: https://bugs.freedesktop.org/show_bug.cgi?id=108145
[fdo#109271]: https://bugs.freedesktop.org/show_bug.cgi?id=109271
[fdo#109276]: https://bugs.freedesktop.org/show_bug.cgi?id=109276
[fdo#109441]: https://bugs.freedesktop.org/show_bug.cgi?id=109441
[fdo#112080]: https://bugs.freedesktop.org/show_bug.cgi?id=112080
[fdo#112146]: https://bugs.freedesktop.org/show_bug.cgi?id=112146
[fdo#112271]: https://bugs.freedesktop.org/show_bug.cgi?id=112271
[fdo#112406]: https://bugs.freedesktop.org/show_bug.cgi?id=112406
[i915#1188]: https://gitlab.freedesktop.org/drm/intel/issues/1188
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#173]: https://gitlab.freedesktop.org/drm/intel/issues/173
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#265]: https://gitlab.freedesktop.org/drm/intel/issues/265
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#488]: https://gitlab.freedesktop.org/drm/intel/issues/488
[i915#49]: https://gitlab.freedesktop.org/drm/intel/issues/49
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#644]: https://gitlab.freedesktop.org/drm/intel/issues/644
[i915#668]: https://gitlab.freedesktop.org/drm/intel/issues/668
[i915#677]: https://gitlab.freedesktop.org/drm/intel/issues/677
[i915#679]: https://gitlab.freedesktop.org/drm/intel/issues/679
[i915#69]: https://gitlab.freedesktop.org/drm/intel/issues/69
[i915#694]: https://gitlab.freedesktop.org/drm/intel/issues/694
[i915#79]: https://gitlab.freedesktop.org/drm/intel/issues/79
[i915#818]: https://gitlab.freedesktop.org/drm/intel/issues/818
[i915#831]: https://gitlab.freedesktop.org/drm/intel/issues/831
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7963 -> Patchwork_16603
CI-20190529: 20190529
CI_DRM_7963: e0d737598eb749378a5dc4ed3dfafc6f79d512cb @ git://anongit.freedesktop.org/gfx-ci/linux
IGT_5448: 116020b1f83c1b3994c76882df7f77b6731d78ba @ git://anongit.freedesktop.org/xorg/app/intel-gpu-tools
Patchwork_16603: 9d3bcd8ee6f9b86d423d0135b12a1e8cb81d2c5f @ git://anongit.freedesktop.org/gfx-ci/linux
piglit_4509: fdc5a4ca11124ab8413c7988896eec4c97336694 @ git://anongit.freedesktop.org/piglit
== Logs ==
For more details see: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16603/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 5.6] mt76: fix array overflow on receiving too many fragments for a packet
From: Felix Fietkau @ 2020-02-20 11:41 UTC (permalink / raw)
To: linux-wireless; +Cc: kvalo, stable
If the hardware receives an oversized packet with too many rx fragments,
skb_shinfo(skb)->frags can overflow and corrupt memory of adjacent pages.
This becomes especially visible if it corrupts the freelist pointer of
a slab page.
Cc: stable@vger.kernel.org
Signed-off-by: Felix Fietkau <nbd@nbd.name>
---
drivers/net/wireless/mediatek/mt76/dma.c | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mediatek/mt76/dma.c b/drivers/net/wireless/mediatek/mt76/dma.c
index 6173c80189ba..1847f55e199b 100644
--- a/drivers/net/wireless/mediatek/mt76/dma.c
+++ b/drivers/net/wireless/mediatek/mt76/dma.c
@@ -447,10 +447,13 @@ mt76_add_fragment(struct mt76_dev *dev, struct mt76_queue *q, void *data,
struct page *page = virt_to_head_page(data);
int offset = data - page_address(page);
struct sk_buff *skb = q->rx_head;
+ struct skb_shared_info *shinfo = skb_shinfo(skb);
- offset += q->buf_offset;
- skb_add_rx_frag(skb, skb_shinfo(skb)->nr_frags, page, offset, len,
- q->buf_size);
+ if (shinfo->nr_frags < ARRAY_SIZE(shinfo->frags)) {
+ offset += q->buf_offset;
+ skb_add_rx_frag(skb, shinfo->nr_frags, page, offset, len,
+ q->buf_size);
+ }
if (more)
return;
--
2.24.0
^ permalink raw reply related
* Re: [Xen-devel] [PATCH 4/5] libxl/PCI: pass correct "hotplug" argument to libxl__device_pci_setdefault()
From: Wei Liu @ 2020-02-20 11:41 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <c7adfa84-2310-3d1d-a6db-574a10247380@suse.com>
On Tue, Feb 18, 2020 at 04:47:27PM +0100, Jan Beulich wrote:
> Uniformly passing "false" can't be right, but has been benign because of
> the function not using this parameter.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* RE: [PATCH net] gianfar: Don't force RGMII mode after reset, use defaults
From: Claudiu Manoil @ 2020-02-20 11:42 UTC (permalink / raw)
To: Daniel Walker (danielwa)
Cc: HEMANT RAMDASI (hramdasi), David S . Miller,
netdev@vger.kernel.org,
Sathish Jarugumalli -X (sjarugum - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco)
In-Reply-To: <20200219185747.GK24043@zorba>
>-----Original Message-----
>From: Daniel Walker (danielwa) <danielwa@cisco.com>
>Sent: Wednesday, February 19, 2020 8:58 PM
>To: Claudiu Manoil <claudiu.manoil@nxp.com>
>Cc: HEMANT RAMDASI (hramdasi) <hramdasi@cisco.com>; David S . Miller
><davem@davemloft.net>; netdev@vger.kernel.org; Sathish Jarugumalli -X
>(sjarugum - ARICENT TECHNOLOGIES MAURIITIUS LIMITED at Cisco)
><sjarugum@cisco.com>
>Subject: Re: [PATCH net] gianfar: Don't force RGMII mode after reset, use
>defaults
>
>On Wed, Nov 13, 2019 at 04:01:39PM +0000, Claudiu Manoil wrote:
>> >-----Original Message-----
>> >From: HEMANT RAMDASI (hramdasi) <hramdasi@cisco.com>
>> [..]
>> >
>> >>> This bit must be set when in half-duplex mode (MACCFG2[Full_Duplex]
>is cleared).
>> >>
>> >> Should the bit be clear when in full duplex or it does not matter?
>> >>
>> >
>> >> From my tests, in full duplex mode small frames won't get padded if
>> >> this bit is disabled, and will be counted as undersize frames and
>> >> dropped. So this bit needs to be set in full duplex mode to get packets
>smaller than 64B past the MAC (w/o software padding).
>> >
>> >This is little strange as we do not see this problem on all pkt type,
>> >icmp passes well and we observed issue with tftp ack.
>>
>> I tested on a 1Gbit (full duplex) link, and ARP and small ICMP ipv4
>> packets were not passing with the PAD_CRC bit disabled.
>
>
>Have you looked into this patch any further ?
>
Hi,
I have an idea on how to parameterize the interface mode setting.
Let me try a patch and if it passes on my boards I'll send it as v2.
^ permalink raw reply
* [Buildroot] [PATCH v3 1/2] support/scripts/pkg-stats: add support for CVE reporting
From: Peter Korsgaard @ 2020-02-20 11:42 UTC (permalink / raw)
To: buildroot
In-Reply-To: <97bf24b6-a272-3707-b825-676c9410d60a@railnova.eu>
>>>>> "Titouan" == Titouan Christophe <titouan.christophe@railnova.eu> writes:
Hi,
> I tried to evaluate how much memory the NVD JSON files actually use
> when loaded as Python objects. To do that, I used the function given
> here:
> https://goshippo.com/blog/measure-real-size-any-python-object/.
> I used the file for the year 2018 as example. This file weights 10MB
> in compressed form, and 254MB when uncompressed. I then call the
> function get_size on
> json.load(gzip.GzipFile("nvdcve-1.0-2018.json.gz"))
> In Python 2.7, the total size used is as high as 1531882276 Bytes (or
> ~1.5GB) ! The same test in Python 3.6 gives me 718038090 Bytes
> (~718MB).
Wow!
>>
>> I did a full run to verify these findings, observing the free memory with 'top'.
>> Even though this is not a fully scientific method, the 'used' memory
>> before was ~4800 MB and while the CVE parsing was ongoing I saw peaks
>> up to ~7900 MB. So yes, it seems there is a large memory footprint.
>> As my machine has enough RAM, the analysis does complete and results
>> seem correct.
>>
>>
>> This seems to be caused mostly by the fact that we load the entire
>> json file in memory.
>> As a test, I just loaded the file from an interactive python session.
> I guess we should then process the CVE files in streaming. This is
> quite easy to do in the CVE.read_nvd_dir() method. I'll give it a try
> today.
Yes, should not be too bad as we process the CVEs one at a time. What
will you use? ijson?
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH v3 06/17] s390x: protvirt: Add migration blocker
From: Janosch Frank @ 2020-02-20 11:42 UTC (permalink / raw)
To: Cornelia Huck; +Cc: qemu-s390x, mihajlov, qemu-devel, david
In-Reply-To: <20200220123953.5b0272a4.cohuck@redhat.com>
[-- Attachment #1.1: Type: text/plain, Size: 3459 bytes --]
On 2/20/20 12:39 PM, Cornelia Huck wrote:
> On Thu, 20 Feb 2020 12:24:23 +0100
> Janosch Frank <frankja@linux.ibm.com> wrote:
>
>> On 2/20/20 11:48 AM, Cornelia Huck wrote:
>>> On Fri, 14 Feb 2020 10:16:25 -0500
>>> Janosch Frank <frankja@linux.ibm.com> wrote:
>>>
>>>> Migration is not yet supported.
>>>>
>>>> Signed-off-by: Janosch Frank <frankja@linux.ibm.com>
>>>> ---
>>>> hw/s390x/s390-virtio-ccw.c | 16 ++++++++++++++++
>>>> 1 file changed, 16 insertions(+)
>>>>
>>>> diff --git a/hw/s390x/s390-virtio-ccw.c b/hw/s390x/s390-virtio-ccw.c
>>>> index 5fa4372083..d64724af91 100644
>>>> --- a/hw/s390x/s390-virtio-ccw.c
>>>> +++ b/hw/s390x/s390-virtio-ccw.c
>>>> @@ -42,6 +42,9 @@
>>>> #include "hw/s390x/tod.h"
>>>> #include "sysemu/sysemu.h"
>>>> #include "hw/s390x/pv.h"
>>>> +#include "migration/blocker.h"
>>>> +
>>>> +static Error *pv_mig_blocker;
>>>>
>>>> S390CPU *s390_cpu_addr2state(uint16_t cpu_addr)
>>>> {
>>>> @@ -373,6 +376,7 @@ static void s390_machine_reset(MachineState *machine)
>>>> CPUState *cs, *t;
>>>> S390CPU *cpu;
>>>> S390CcwMachineState *ms = S390_CCW_MACHINE(machine);
>>>> + static Error *local_err;
>>>>
>>>> /* get the reset parameters, reset them once done */
>>>> s390_ipl_get_reset_request(&cs, &reset_type);
>>>> @@ -422,6 +426,17 @@ static void s390_machine_reset(MachineState *machine)
>>>> }
>>>> run_on_cpu(cs, s390_do_cpu_reset, RUN_ON_CPU_NULL);
>>>>
>>>> + if (!pv_mig_blocker) {
>>>> + error_setg(&pv_mig_blocker,
>>>> + "protected VMs are currently not migrateable.");
>>>> + }
>>>> + migrate_add_blocker(pv_mig_blocker, &local_err);
>>>
>>> If I'm not lost in the context, that's during PV_RESET. I'm a bit
>>> confused why you'd add the blocker here?
>>
>> Where would you want me to add it?
>> It's here where we switch into secure mode and I need to block before
>> switching and unblock if it fails.
>>
>> When having the blocker in diag.c, I'd have a hard time unblocking on a
>> PV switch fail.
>>
>>>
>>>> + if (local_err) {
>>>> + error_report_err(local_err);
>>>> + error_free(pv_mig_blocker);
>>>> + exit(1);
>>>
>>> Why the exit()? Can't you fail the call?
>>
>> Well, if that fails and we go protected, I wouldn't be protected agains
>> migrations, right?
>
> No, I meant not go protected, if that's possible.
That would be an option, now that we have a proper d308 rc for such a thing.
Will add!
>
>>
>>>
>>>> + }
>>>> +
>>>> if (s390_machine_pv_secure(ms)) {
>
> Ok, I think what confuses me is this call: it reads as if you actually
> tear down things if the machine is secure. Call it
> s390_machine_pv_make_secure() to make sure it is actively doing
> something and not checking a previously set value?
Ok, will use something along these lines
>
>>>> CPU_FOREACH(t) {
>>>> s390_pv_vcpu_destroy(t);
>>>> @@ -430,6 +445,7 @@ static void s390_machine_reset(MachineState *machine)
>>>> ms->pv = false;
>>>>
>>>> s390_machine_inject_pv_error(cs);
>>>> + migrate_del_blocker(pv_mig_blocker);
>>>> s390_cpu_set_state(S390_CPU_STATE_OPERATING, cpu);
>>>> return;
>>>> }
>>>
>>>
>>
>>
>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ permalink raw reply
* Re: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
From: Martin Kepplinger @ 2020-02-20 11:43 UTC (permalink / raw)
To: Jun Li, Peter Chen, mathias.nyman@intel.com
Cc: linux-usb@vger.kernel.org, dl-linux-imx, Anson Huang,
shawnguo@kernel.org, kernel@pengutronix.de
In-Reply-To: <VE1PR04MB65289878A84E662D6CCAF13089130@VE1PR04MB6528.eurprd04.prod.outlook.com>
On 20.02.20 07:31, Jun Li wrote:
>> -----Original Message-----
>> From: Martin Kepplinger <martin.kepplinger@puri.sm>
>> Sent: 2020年2月20日 1:37
>> To: Jun Li <jun.li@nxp.com>; Peter Chen <peter.chen@nxp.com>;
>> mathias.nyman@intel.com
>> Cc: linux-usb@vger.kernel.org; dl-linux-imx <linux-imx@nxp.com>; Anson Huang
>> <anson.huang@nxp.com>; shawnguo@kernel.org; kernel@pengutronix.de
>> Subject: [PATCH] usb: host: xhci-plat: add XHCI_MISSING_CAS quirk
>>
>> From: Li Jun <jun.li@nxp.com>
>>
>> i.MX8MQ USB3 host needs XHCI_MISSING_CAS quirk to warm reset the port to enum the
>> USB3 device plugged in while system sleep, as the port state is stuck in polling
>> mode after resume.
>>
>> Signed-off-by: Li Jun <jun.li@nxp.com>
>> Acked-by: Peter Chen <peter.chen@nxp.com>
>> ---
>>
>> Hi,
>>
>> Because resume from S3 suspend is broken for me on imx8mq, I stumbled upon this
>> patch in NXP's linux tree. (Please note that I'm not the author and I've not yet
>> put my SoB tag under it). This is just a
>> question:
>>
>> This patch (and the docs) clearly is missing in mainline Linux because the imx8mq
>> devicetree description includes it (which does nothing now).
>>
>> I've tested this and this particular addition doesn't fix my problem:
>>
>> [ 84.257538] imx8mq-usb-phy 381f0040.usb-phy: bus resume
>> [ 84.263195] imx8mq-usb-phy 382f0040.usb-phy: bus resume
>> [ 84.268898] dwc3 38100000.usb: driver resume
>>
>> during resume from S3 suspend, here it still hangs.
>
> Is your problem a system hang? If yes, this may another issue,
> where the hang happens? dwc3_resume_common()?
exactly! I followed to the point it hangs once again and it's
dwc3_core_init() called from dwc3_resume_common()'s "OTG" case.
Specifically, dwc3_writel() is what I don't get past:
https://elixir.bootlin.com/linux/v5.6-rc2/source/drivers/usb/dwc3/core.c#L934
do you have an idea why this writel() hangs?
>
> The question patch is to give a warm reset for connected USB
> device if the link state is not connect/CAS after system resume,
> otherwise host will wait 2s for device appear:
>
> [ 44.834831] usb 2-1: Waited 2000ms for CONNECT
> ...
> [ 45.055718] PM: resume devices took 3.132 seconds
>
> I will post this patch and doc(to be updated) to upstream later.
>
ok, good, thanks,
martin
^ permalink raw reply
* Re: [Xen-devel] [PATCH 5/5] libxl/PCI: align reserved device memory boundary for HAP guests
From: Wei Liu @ 2020-02-20 11:43 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <2a9a998e-f2d0-3c07-e85e-7fdda18b506e@suse.com>
On Tue, Feb 18, 2020 at 04:47:49PM +0100, Jan Beulich wrote:
> As the code comment says, this will allow use of a 2Mb super page
> mapping at the end of "low" memory.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>
> --- a/tools/libxl/libxl_dm.c
> +++ b/tools/libxl/libxl_dm.c
> @@ -563,6 +563,13 @@ int libxl__domain_device_construct_rdm(l
> /* Just check if RDM > our memory boundary. */
> if (rdm_start > rdm_mem_boundary) {
> /*
> + * For HAP guests round down to a 2Mb boundary to allow use
> + * of large page mappings.
> + */
> + if (libxl_defbool_val(d_config->c_info.hap)
> + && rdm_start > 0x200000)
Please use MB(2) here.
With this fixed:
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* Re: [Xen-devel] [PATCH 3/5] libxl/PCI: make "rdm=" parsing comply with documentation
From: Wei Liu @ 2020-02-20 11:44 UTC (permalink / raw)
To: Jan Beulich
Cc: Anthony Perard, xen-devel@lists.xenproject.org, Ian Jackson,
Wei Liu
In-Reply-To: <7c8de367-4833-c603-fcdd-89c1e6ceda3a@suse.com>
On Tue, Feb 18, 2020 at 04:47:04PM +0100, Jan Beulich wrote:
> Documentation says "<RDM_RESERVATION_STRING> is a comma separated list
> of <KEY=VALUE> settings, from the following list". There's no mention
> of a specific order, yet so far the parsing logic did accept only
> strategy, then policy (and neither of the two omitted). Make "state"
> move
> - back to STATE_TYPE when finding a comma after having parsed the
> <VALUE> part of a setting,
> - to STATE_TERMINAL otherwise.
>
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ 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.