* Re: [PATCH V4 4/5] virtio: introduce a vDPA based transport
From: Jason Gunthorpe @ 2020-02-20 15:19 UTC (permalink / raw)
To: Jason Wang
Cc: mst@redhat.com, linux-kernel@vger.kernel.org, kvm@vger.kernel.org,
virtualization@lists.linux-foundation.org, netdev@vger.kernel.org,
tiwei.bie@intel.com, maxime.coquelin@redhat.com,
cunming.liang@intel.com, zhihong.wang@intel.com,
rob.miller@broadcom.com, xiao.w.wang@intel.com,
haotian.wang@sifive.com, lingshan.zhu@intel.com,
eperezma@redhat.com, lulu@redhat.com, Parav Pandit,
kevin.tian@intel.com, stefanha@redhat.com, rdunlap@infradead.org,
hch@infradead.org, aadam@redhat.com, Jiri Pirko, Shahaf Shuler,
hanand@xilinx.com, mhabets@solarflare.com
In-Reply-To: <20200220061141.29390-5-jasowang@redhat.com>
On Thu, Feb 20, 2020 at 02:11:40PM +0800, Jason Wang wrote:
> +static int virtio_vdpa_probe(struct vdpa_device *vdpa)
> +{
> + const struct vdpa_config_ops *ops = vdpa->config;
> + struct virtio_vdpa_device *vd_dev;
> + int ret = -EINVAL;
> +
> + vd_dev = kzalloc(sizeof(*vd_dev), GFP_KERNEL);
> + if (!vd_dev)
> + return -ENOMEM;
> +
> + vd_dev->vdev.dev.parent = vdpa_get_dma_dev(vdpa);
> + vd_dev->vdev.dev.release = virtio_vdpa_release_dev;
> + vd_dev->vdev.config = &virtio_vdpa_config_ops;
> + vd_dev->vdpa = vdpa;
> + INIT_LIST_HEAD(&vd_dev->virtqueues);
> + spin_lock_init(&vd_dev->lock);
> +
> + vd_dev->vdev.id.device = ops->get_device_id(vdpa);
> + if (vd_dev->vdev.id.device == 0)
> + goto err;
> +
> + vd_dev->vdev.id.vendor = ops->get_vendor_id(vdpa);
> + ret = register_virtio_device(&vd_dev->vdev);
> + if (ret)
> + goto err;
This error unwind is wrong. register_virtio_device() does
device_initialize() as it's first action. After that point error
unwind must be done with put_device() - particularly calling
kfree(vd_dev) after doing dev_set_name() leaks memory.
Looks like about half of the register_virtio_device() users did this
right, the others not. Perhaps you should fix them too...
Jason
^ permalink raw reply
* Re: [Xen-devel] [PATCH] rwlock: allow recursive read locking when already locked in write mode
From: Roger Pau Monné @ 2020-02-20 15:20 UTC (permalink / raw)
To: Jan Beulich
Cc: Jürgen Groß, Stefano Stabellini, Julien Grall, Wei Liu,
Konrad Rzeszutek Wilk, George Dunlap, Andrew Cooper, Ian Jackson,
xen-devel
In-Reply-To: <a2111136-e91c-4077-5bea-ea310a43979e@suse.com>
On Thu, Feb 20, 2020 at 04:11:08PM +0100, Jan Beulich wrote:
> On 20.02.2020 15:38, Roger Pau Monné wrote:
> > On Thu, Feb 20, 2020 at 03:23:38PM +0100, Jürgen Groß wrote:
> >> On 20.02.20 15:11, Roger Pau Monné wrote:
> >>> On Thu, Feb 20, 2020 at 01:48:54PM +0100, Jan Beulich wrote:
> >>>> On 20.02.2020 13:02, Roger Pau Monne wrote:
> >>>>> @@ -166,7 +180,8 @@ static inline void _write_unlock(rwlock_t *lock)
> >>>>> * If the writer field is atomic, it can be cleared directly.
> >>>>> * Otherwise, an atomic subtraction will be used to clear it.
> >>>>> */
> >>>>> - atomic_sub(_QW_LOCKED, &lock->cnts);
> >>>>> + ASSERT(_is_write_locked_by_me(atomic_read(&lock->cnts)));
> >>>>> + atomic_sub(_write_lock_val(), &lock->cnts);
> >>>>
> >>>> I think this would be more efficient with atomic_and(), not
> >>>> the least because of the then avoided smp_processor_id().
> >>>> Whether to mask off just _QW_WMASK or also the CPU number of
> >>>> the last write owner would need to be determined. But with
> >>>> using subtraction, in case of problems it'll likely be
> >>>> harder to understand what actually went on, from looking at
> >>>> the resulting state of the lock (this is in part a pre-
> >>>> existing problem, but gets worse with subtraction of CPU
> >>>> numbers).
> >>>
> >>> Right, a mask would be better. Right now both need to be cleared (the
> >>> LOCKED and the CPU fields) as there's code that relies on !lock->cnts
> >>> as a way to determine that the lock is not read or write locked. If we
> >>> left the CPU lying around those checks would need to be adjusted.
> >>
> >> In case you make _QR_SHIFT 16 it is possible to just write a 2-byte zero
> >> value for write_unlock() (like its possible to do so today using a
> >> single byte write).
> >
> > That would limit the readers count to 65536, what do you think Jan?
>
> If the recurse_cpu approach is considered bad, I think this would
> be acceptable. But of course you'll need to consult with the Arm
> guys regarding the correctness of such a "half" store in their
> memory model; I would hope this to be universally okay, but I'm
> not entirely certain.
I would like to get confirmation from the Arm folks, but I see Arm has
write_atomic and supports such operation against a uint16_t, so I
don't see why it wouldn't work.
Thanks, Roger.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [Xen-devel] [xen-unstable-smoke test] 147361: tolerable all pass - PUSHED
From: osstest service owner @ 2020-02-20 15:20 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 147361 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/147361/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
version targeted for testing:
xen cb6a6e9527c0f87708dce9facb74d11f0169992b
baseline version:
xen 6e0b445ee738cd829ed28c7532cded8afe25886d
Last test of basis 147354 2020-02-20 11:01:37 Z 0 days
Testing same since 147361 2020-02-20 13:01:07 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Hongyan Xia <hongyxia@amazon.com>
Jan Beulich <jbeulich@suse.com>
Sander Eikelenboom <linux@eikelenboom.it>
Wei Liu <wei.liu2@citrix.com>
Wei Liu <wl@xen.org>
jobs:
build-arm64-xsm pass
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-arm64-arm64-xl-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-amd64-libvirt pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
To xenbits.xen.org:/home/xen/git/xen.git
6e0b445ee7..cb6a6e9527 cb6a6e9527c0f87708dce9facb74d11f0169992b -> smoke
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
^ permalink raw reply
* [PATCH net-next 0/3] Improve bind(addr, 0) behaviour.
From: Kuniyuki Iwashima @ 2020-02-20 15:20 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, edumazet
Cc: kuniyu, kuni1840, netdev, osa-contribution-log
Currently we fail to bind sockets to ephemeral ports when all of the ports
are exhausted even if all sockets have SO_REUSEADDR enabled. In this case,
we still have a chance to connect to the different remote hosts.
The second and third patches fix the behaviour to fully utilize all space
of the local (addr, port) tuples.
Kuniyuki Iwashima (3):
tcp: Remove unnecessary conditions in inet_csk_bind_conflict().
tcp: bind(addr, 0) remove the SO_REUSEADDR restriction when ephemeral
ports are exhausted.
tcp: Prevent port hijacking when ports are exhausted
net/ipv4/inet_connection_sock.c | 36 ++++++++++++++++++++++-----------
1 file changed, 24 insertions(+), 12 deletions(-)
--
2.17.2 (Apple Git-113)
^ permalink raw reply
* [PATCH net-next 1/3] tcp: Remove unnecessary conditions in inet_csk_bind_conflict().
From: Kuniyuki Iwashima @ 2020-02-20 15:20 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, edumazet
Cc: kuniyu, kuni1840, netdev, osa-contribution-log
In-Reply-To: <20200220152020.13056-1-kuniyu@amazon.co.jp>
When we get an ephemeral port, the relax is false, so the SO_REUSEADDR
conditions may be evaluated twice. We do not need to check the conditions
again.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
---
net/ipv4/inet_connection_sock.c | 18 ++++++++----------
1 file changed, 8 insertions(+), 10 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index a4db79b1b643..2e9549f49a82 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -146,17 +146,15 @@ static int inet_csk_bind_conflict(const struct sock *sk,
(!sk->sk_bound_dev_if ||
!sk2->sk_bound_dev_if ||
sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
- if ((!reuse || !sk2->sk_reuse ||
- sk2->sk_state == TCP_LISTEN) &&
- (!reuseport || !sk2->sk_reuseport ||
- rcu_access_pointer(sk->sk_reuseport_cb) ||
- (sk2->sk_state != TCP_TIME_WAIT &&
- !uid_eq(uid, sock_i_uid(sk2))))) {
- if (inet_rcv_saddr_equal(sk, sk2, true))
- break;
- }
- if (!relax && reuse && sk2->sk_reuse &&
+ if (reuse && sk2->sk_reuse &&
sk2->sk_state != TCP_LISTEN) {
+ if (!relax &&
+ inet_rcv_saddr_equal(sk, sk2, true))
+ break;
+ } else if (!reuseport || !sk2->sk_reuseport ||
+ rcu_access_pointer(sk->sk_reuseport_cb) ||
+ (sk2->sk_state != TCP_TIME_WAIT &&
+ !uid_eq(uid, sock_i_uid(sk2)))) {
if (inet_rcv_saddr_equal(sk, sk2, true))
break;
}
--
2.17.2 (Apple Git-113)
^ permalink raw reply related
* [PATCH net-next 2/3] tcp: bind(addr, 0) remove the SO_REUSEADDR restriction when ephemeral ports are exhausted.
From: Kuniyuki Iwashima @ 2020-02-20 15:20 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, edumazet
Cc: kuniyu, kuni1840, netdev, osa-contribution-log
In-Reply-To: <20200220152020.13056-1-kuniyu@amazon.co.jp>
Commit aacd9289af8b82f5fb01bcdd53d0e3406d1333c7 ("tcp: bind() use stronger
condition for bind_conflict") introduced a restriction to forbid to bind
SO_REUSEADDR enabled sockets to the same (addr, port) tuple in order to
assign ports dispersedly so that we can connect to the same remote host.
The change results in accelerating port depletion so that we fail to bind
sockets to the same local port even if we want to connect to the different
remote hosts.
You can reproduce this issue by following instructions below.
1. # sysctl -w net.ipv4.ip_local_port_range="32768 32768"
2. set SO_REUSEADDR to two sockets.
3. bind two sockets to (localhost, 0) and the latter fails.
Therefore, when ephemeral ports are exhausted, bind(addr, 0) should
fallback to the legacy behaviour to enable the SO_REUSEADDR option and make
it possible to connect to different remote (addr, port) tuples.
This patch allows us to bind SO_REUSEADDR enabled sockets to the same
(addr, port) only when all ephemeral ports are exhausted.
The only notable thing is that if all sockets bound to the same port have
both SO_REUSEADDR and SO_REUSEPORT enabled, we can bind sockets to an
ephemeral port and also do listen().
Fixes: aacd9289af8b ("tcp: bind() use stronger condition for bind_conflict")
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
---
net/ipv4/inet_connection_sock.c | 10 +++++++++-
1 file changed, 9 insertions(+), 1 deletion(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index 2e9549f49a82..cddeab240ea6 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -174,12 +174,14 @@ inet_csk_find_open_port(struct sock *sk, struct inet_bind_bucket **tb_ret, int *
int port = 0;
struct inet_bind_hashbucket *head;
struct net *net = sock_net(sk);
+ bool relax = false;
int i, low, high, attempt_half;
struct inet_bind_bucket *tb;
u32 remaining, offset;
int l3mdev;
l3mdev = inet_sk_bound_l3mdev(sk);
+ports_exhausted:
attempt_half = (sk->sk_reuse == SK_CAN_REUSE) ? 1 : 0;
other_half_scan:
inet_get_local_port_range(net, &low, &high);
@@ -217,7 +219,7 @@ inet_csk_find_open_port(struct sock *sk, struct inet_bind_bucket **tb_ret, int *
inet_bind_bucket_for_each(tb, &head->chain)
if (net_eq(ib_net(tb), net) && tb->l3mdev == l3mdev &&
tb->port == port) {
- if (!inet_csk_bind_conflict(sk, tb, false, false))
+ if (!inet_csk_bind_conflict(sk, tb, relax, false))
goto success;
goto next_port;
}
@@ -237,6 +239,12 @@ inet_csk_find_open_port(struct sock *sk, struct inet_bind_bucket **tb_ret, int *
attempt_half = 2;
goto other_half_scan;
}
+
+ if (!relax) {
+ /* We still have a chance to connect to different destinations */
+ relax = true;
+ goto ports_exhausted;
+ }
return NULL;
success:
*port_ret = port;
--
2.17.2 (Apple Git-113)
^ permalink raw reply related
* Re: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
From: Nirmoy @ 2020-02-20 15:20 UTC (permalink / raw)
To: amd-gfx
In-Reply-To: <a8e8df99-aaed-5c0a-10ee-7cb63861c283@amd.com>
Hi Monk,
How can I reproduce this bug ?
Regards,
Nirmoy
On 2/20/20 4:15 PM, Nirmoy wrote:
>
> On 2/20/20 2:35 PM, Liu, Monk wrote:
>> Sorry, my previous idea still leave RQ null, please check if below
>> method works:
>>
>> 29 static struct drm_sched_rq *
>> 130 drm_sched_entity_get_free_sched(struct drm_sched_entity *entity)
>> 131 {
>> 132 struct drm_sched_rq *rq = NULL;
>> 133 unsigned int min_jobs = UINT_MAX, num_jobs;
>> 134 int i;
>>
>> 135
>> While (!mutex_trylock(....))
>> Sleep()
> We can't do that drm_sched_entity_get_free_sched is in another
> module(drm scheduler) independent of amdgpu
>> 136 for (i = 0; i < entity->num_rq_list; ++i) {
>> 137 struct drm_gpu_scheduler *sched = entity->rq_list[i]->sched;
>> 138
>> 139 if (!entity->rq_list[i]->sched->ready) { //we take the
>> gpu reset mutex lock, so now sched->ready won't be set to "not ready"
>> 140 DRM_WARN("sched%s is not ready, skipping", sched->name);
>> 141 continue;
>> 142 }
>> 143
>> 144 num_jobs = atomic_read(&sched->num_jobs);
>> 145 if (num_jobs < min_jobs) {
>> 146 min_jobs = num_jobs;
>> 147 rq = entity->rq_list[i];
>> 148 }
>> 149 }
>>
>> Mutex_unlock(...)
>>
>> 150
>> 151 return rq;
>> 152 }
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cnirmoy.das%40amd.com%7C42d1848a368c4371069a08d7b6175779%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178083693348777&sdata=FWeewzJ8jYBlBxAVMkMeq%2BIEOzGapqMiRfW22VYr1SI%3D&reserved=0
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH net-next 3/3] tcp: Prevent port hijacking when ports are exhausted.
From: Kuniyuki Iwashima @ 2020-02-20 15:20 UTC (permalink / raw)
To: davem, kuznet, yoshfuji, edumazet
Cc: kuniyu, kuni1840, netdev, osa-contribution-log
In-Reply-To: <20200220152020.13056-1-kuniyu@amazon.co.jp>
If all of the sockets bound to the same port have SO_REUSEADDR and
SO_REUSEPORT enabled, any other user can hijack the port by exhausting all
ephemeral ports, binding sockets to (addr, 0) and calling listen().
In this case, we should be able to bind sockets to the same port only if
the user has the first listening socket on the port or if the existing
socket is in TIME_WAIT.
Signed-off-by: Kuniyuki Iwashima <kuniyu@amazon.co.jp>
---
net/ipv4/inet_connection_sock.c | 12 +++++++++---
1 file changed, 9 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/inet_connection_sock.c b/net/ipv4/inet_connection_sock.c
index cddeab240ea6..a6d9ee19baeb 100644
--- a/net/ipv4/inet_connection_sock.c
+++ b/net/ipv4/inet_connection_sock.c
@@ -131,7 +131,7 @@ static int inet_csk_bind_conflict(const struct sock *sk,
{
struct sock *sk2;
bool reuse = sk->sk_reuse;
- bool reuseport = !!sk->sk_reuseport && reuseport_ok;
+ bool reuseport = !!sk->sk_reuseport;
kuid_t uid = sock_i_uid((struct sock *)sk);
/*
@@ -148,10 +148,16 @@ static int inet_csk_bind_conflict(const struct sock *sk,
sk->sk_bound_dev_if == sk2->sk_bound_dev_if)) {
if (reuse && sk2->sk_reuse &&
sk2->sk_state != TCP_LISTEN) {
- if (!relax &&
+ if ((!relax ||
+ (!reuseport_ok &&
+ reuseport && sk2->sk_reuseport &&
+ !rcu_access_pointer(sk->sk_reuseport_cb) &&
+ (sk2->sk_state != TCP_TIME_WAIT &&
+ !uid_eq(uid, sock_i_uid(sk2))))) &&
inet_rcv_saddr_equal(sk, sk2, true))
break;
- } else if (!reuseport || !sk2->sk_reuseport ||
+ } else if (!reuseport_ok ||
+ !reuseport || !sk2->sk_reuseport ||
rcu_access_pointer(sk->sk_reuseport_cb) ||
(sk2->sk_state != TCP_TIME_WAIT &&
!uid_eq(uid, sock_i_uid(sk2)))) {
--
2.17.2 (Apple Git-113)
^ permalink raw reply related
* Re: [PATCH v3 1/2] driver core: Rework logic in __driver_deferred_probe_check_state to allow EPROBE_DEFER to be returned for longer
From: Rob Herring @ 2020-02-20 15:20 UTC (permalink / raw)
To: Saravana Kannan
Cc: John Stultz, lkml, Bjorn Andersson, Mark Brown,
Greg Kroah-Hartman, Kevin Hilman, Len Brown, Liam Girdwood,
open list:THERMAL, Pavel Machek, Rafael J. Wysocki, Todd Kjos,
Ulf Hansson, Android Kernel Team
In-Reply-To: <20200220052739.87057-1-saravanak@google.com>
On Wed, Feb 19, 2020 at 11:27 PM Saravana Kannan <saravanak@google.com> wrote:
>
> Apologies in advance for replying to this one email but discussing the
> points raised in all the other replies. I'm not cc'ed in this thread and
> replying to each email individually is a pain.
>
> On Tue, Feb 18, 2020 at 4:07 PM John Stultz wrote:
> > Due to commit e01afc3250255 ("PM / Domains: Stop deferring probe
> > at the end of initcall"), along with commit 25b4e70dcce9
> > ("driver core: allow stopping deferred probe after init") after
> > late_initcall, drivers will stop getting EPROBE_DEFER, and
> > instead see an error causing the driver to fail to load.
>
> Both of those patches were the best solution at that point in time. But
> the kernel has changed a lot since then. Power domain and IOMMU drivers
> can work as modules now. We have of_devlink and sync_state().
>
> So, while a delay might have been the ideal solution back then, I think
> we need to work towards removing arbitrary timeouts instead of making
> the timeout mechanism more elaborate.
If you don't have some way to say all the dependencies that can be
resolved have been resolved already, how do you get away from a
timeout? Nothing has changed in that respect.
If a dtb+kernel works, updating just the dtb with new dependencies
should not break things.
> I think driver_deferred_probe_check_state() logic should boiled down
> to something like:
>
> int driver_deferred_probe_check_state(struct device *dev)
> {
> /* No modules and init done, deferred probes are pointless from
> * now. */
> if (!defined(CONFIG_MODULES) && initcall_done)
> return -ENODEV;
>
> /* If modules and of_devlink then you clean want dependencies to
> * be enforced.
> */
> if (defined(CONFIG_MODULES) && of_devlink)
> return -EPROBE_DEFER;
>
> /* Whatever other complexity (including timeouts) we want to
> * add. Hopefully none - we can discuss in this thread. */
> if (.....)
> return -Exxxx;
>
> /* When in doubt, allow probe deferral. */
> return -EPROBE_DEFER;
> }
Mostly makes sense to me. I think using CONFIG_MODULES is good.
However, there is the case in pinctrl that we have a DT flag
'pinctrl-use-default' and we stop deferring at the end of initcalls if
set. With the above, there's no way to detect that. I'm pretty sure
that's broken now with of_devlink and maybe from Thierry's change too.
> Rob, for the original use case those two patches were added for, do they need
> to support CONFIG_MODULES?
At the time since the subsystems involved were not typically modules
so using CONFIG_MODULES didn't really matter. As you said, that's
changed now.
> > That change causes trouble when trying to use many clk drivers
> > as modules, as the clk modules may not load until much later
> > after init has started. If a dependent driver loads and gets an
> > error instead of EPROBE_DEFER, it won't try to reload later when
> > the dependency is met, and will thus fail to load.
>
> Once we add of_devlink support for power-domains, you won't even hit the
> genpd error path if you have of_devlink enabled. I believe in the case
> you are testing DB 845c, of_devlink is enabled?
>
> If of_devlink is enabled, the devices depending on the unprobed power
> domains would be deferred without even calling the driver's probe()
> function.
>
> Adding power-domain support to of_devlink is a 2 line change. I'll send
> it out soon.
>
> Also, regulator_init_complete() can be replaced by a sync_state() based
> implementation. I have a downstream implementation that works. But it's
> definitely not upstream ready. I plan to rewrite it and send it upstream
> at some point, but it's fairly straightforward if anyone else want to
> implement it. My main point being, we shouldn't have to make the timeout
> logic more complex (or even need one) for regulator clean up either.
>
> On Tue, Feb 18, 2020 at 6:07 PM Rob Herring wrote:
> > The one complication which I mentioned already is with consoles. A
> > timeout (and dependencies in modules) there doesn't work. You have to
> > probe and register the console before init is done.
>
> Rob,
>
> I've seen you say this a couple of times before. But I don't think this
> is true any more. With of_devlink enabled I've booted hardware countless
> times with the console device probing after userspace comes up. The only
> limitation for console drivers is that they need to be built-in if they
> need to support earlycon. If you don't care to support earlycon (very
> useful for bringup debugging), I think the console driver can even be a
> module. I don't think even of_devlink needs to be enabled technically if
> you load the modules in the right order.
Every serial driver has to be built-in to enable console support.
That's not because of earlycon. It's been that way for as long as I've
worked on linux. Now of course, a driver could be built-in and still
probe after userspace starts, but in my testing with the timeout that
didn't work. I don't see how of_devlink changes that.
It could depend on what userspace you have. Certainly, booting with
'console=ttyS0 init=/bin/sh' would not work for example. What I
probably tested with was a busybox based rootfs. What are you testing
with? Android?
Rob
^ permalink raw reply
* RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
From: Zhou, David(ChunMing) @ 2020-02-20 15:15 UTC (permalink / raw)
To: He, Jacob, Koenig, Christian, amd-gfx@lists.freedesktop.org
In-Reply-To: <MN2PR12MB3376E699E0A85E8065D3E72D9B130@MN2PR12MB3376.namprd12.prod.outlook.com>
[-- Attachment #1.1: Type: text/plain, Size: 12016 bytes --]
[AMD Official Use Only - Internal Distribution Only]
You can enhance amdgpu_vm_ioctl In amdgpu_vm.c to return vmid to userspace.
-David
From: He, Jacob <Jacob.He@amd.com>
Sent: Thursday, February 20, 2020 10:46 PM
To: Zhou, David(ChunMing) <David1.Zhou@amd.com>; Koenig, Christian <Christian.Koenig@amd.com>; amd-gfx@lists.freedesktop.org
Subject: RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
amdgpu_vm_reserve_vmid doesn't return the reserved vmid back to user space. There is no chance for user mode driver to update RLC_SPM_VMID.
Thanks
Jacob
From: He, Jacob<mailto:Jacob.He@amd.com>
Sent: Thursday, February 20, 2020 6:20 PM
To: Zhou, David(ChunMing)<mailto:David1.Zhou@amd.com>; Koenig, Christian<mailto:Christian.Koenig@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
Looks like amdgpu_vm_reserve_vmid could work, let me have a try to update the RLC_SPM_VMID with pm4 packets in UMD.
Thanks
Jacob
From: Zhou, David(ChunMing)<mailto:David1.Zhou@amd.com>
Sent: Thursday, February 20, 2020 10:13 AM
To: Koenig, Christian<mailto:Christian.Koenig@amd.com>; He, Jacob<mailto:Jacob.He@amd.com>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: RE: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
[AMD Official Use Only - Internal Distribution Only]
Christian is right here, that will cause many problems for simply using VMID in kernel.
We already have an pair interface for RGP, I think you can use it instead of involving additional kernel change.
amdgpu_vm_reserve_vmid/ amdgpu_vm_unreserve_vmid.
-David
-----Original Message-----
From: amd-gfx <amd-gfx-bounces@lists.freedesktop.org<mailto:amd-gfx-bounces@lists.freedesktop.org>> On Behalf Of Christian König
Sent: Wednesday, February 19, 2020 7:03 PM
To: He, Jacob <Jacob.He@amd.com<mailto:Jacob.He@amd.com>>; amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
Subject: Re: [PATCH] drm/amdgpu: Add a chunk ID for spm trace
Am 19.02.20 um 11:15 schrieb Jacob He:
> [WHY]
> When SPM trace enabled, SPM_VMID should be updated with the current
> vmid.
>
> [HOW]
> Add a chunk id, AMDGPU_CHUNK_ID_SPM_TRACE, so that UMD can tell us
> which job should update SPM_VMID.
> Right before a job is submitted to GPU, set the SPM_VMID accordingly.
>
> [Limitation]
> Running more than one SPM trace enabled processes simultaneously is
> not supported.
Well there are multiple problems with that patch.
First of all you need to better describe what SPM tracing is in the commit message.
Then the updating of mmRLC_SPM_MC_CNTL must be executed asynchronously on the ring. Otherwise we might corrupt an already executing SPM trace.
And you also need to make sure to disable the tracing again or otherwise we run into a bunch of trouble when the VMID is reused.
You also need to make sure that IBs using the SPM trace are serialized with each other, e.g. hack into amdgpu_ids.c file and make sure that only one VMID at a time can have that attribute.
Regards,
Christian.
>
> Change-Id: Ic932ef6ac9dbf244f03aaee90550e8ff3a675666
> Signed-off-by: Jacob He <jacob.he@amd.com<mailto:jacob.he@amd.com>>
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 7 +++++++
> drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c | 10 +++++++---
> drivers/gpu/drm/amd/amdgpu/amdgpu_job.h | 1 +
> drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h | 1 +
> drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c | 15 ++++++++++++++-
> drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c | 3 ++-
> drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c | 15 ++++++++++++++-
> 8 files changed, 48 insertions(+), 7 deletions(-)
>
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> index f9fa6e104fef..3f32c4db5232 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c
> @@ -113,6 +113,7 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
> uint32_t uf_offset = 0;
> int i;
> int ret;
> + bool update_spm_vmid = false;
>
> if (cs->in.num_chunks == 0)
> return 0;
> @@ -221,6 +222,10 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
> case AMDGPU_CHUNK_ID_SYNCOBJ_TIMELINE_SIGNAL:
> break;
>
> + case AMDGPU_CHUNK_ID_SPM_TRACE:
> + update_spm_vmid = true;
> + break;
> +
> default:
> ret = -EINVAL;
> goto free_partial_kdata;
> @@ -231,6 +236,8 @@ static int amdgpu_cs_parser_init(struct amdgpu_cs_parser *p, union drm_amdgpu_cs
> if (ret)
> goto free_all_kdata;
>
> + p->job->need_update_spm_vmid = update_spm_vmid;
> +
> if (p->ctx->vram_lost_counter != p->job->vram_lost_counter) {
> ret = -ECANCELED;
> goto free_all_kdata;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> index cae81914c821..36faab12b585 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_ib.c
> @@ -156,9 +156,13 @@ int amdgpu_ib_schedule(struct amdgpu_ring *ring, unsigned num_ibs,
> return -EINVAL;
> }
>
> - if (vm && !job->vmid) {
> - dev_err(adev->dev, "VM IB without ID\n");
> - return -EINVAL;
> + if (vm) {
> + if (!job->vmid) {
> + dev_err(adev->dev, "VM IB without ID\n");
> + return -EINVAL;
> + } else if (adev->gfx.rlc.funcs->update_spm_vmid && job->need_update_spm_vmid) {
> + adev->gfx.rlc.funcs->update_spm_vmid(adev, job->vmid);
> + }
> }
>
> alloc_size = ring->funcs->emit_frame_size + num_ibs * diff --git
> a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> index 2e2110dddb76..4582536961c7 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_job.h
> @@ -52,6 +52,7 @@ struct amdgpu_job {
> bool vm_needs_flush;
> uint64_t vm_pd_addr;
> unsigned vmid;
> + bool need_update_spm_vmid;
> unsigned pasid;
> uint32_t gds_base, gds_size;
> uint32_t gws_base, gws_size;
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> index d3d4707f2168..52509c254cbd 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_rlc.h
> @@ -126,6 +126,7 @@ struct amdgpu_rlc_funcs {
> void (*stop)(struct amdgpu_device *adev);
> void (*reset)(struct amdgpu_device *adev);
> void (*start)(struct amdgpu_device *adev);
> + void (*update_spm_vmid)(struct amdgpu_device *adev, unsigned vmid);
> };
>
> struct amdgpu_rlc {
> diff --git a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> index 5e9fb0976c6c..91eb788d6229 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v10_0.c
> @@ -4214,6 +4214,18 @@ static int gfx_v10_0_update_gfx_clock_gating(struct amdgpu_device *adev,
> return 0;
> }
>
> +static void gfx_v10_0_update_spm_vmid(struct amdgpu_device *adev,
> +unsigned vmid) {
> + u32 data;
> +
> + data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> +
> + data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> + data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> +RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> +
> + WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data); }
> +
> static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
> .is_rlc_enabled = gfx_v10_0_is_rlc_enabled,
> .set_safe_mode = gfx_v10_0_set_safe_mode, @@ -4224,7 +4236,8 @@
> static const struct amdgpu_rlc_funcs gfx_v10_0_rlc_funcs = {
> .resume = gfx_v10_0_rlc_resume,
> .stop = gfx_v10_0_rlc_stop,
> .reset = gfx_v10_0_rlc_reset,
> - .start = gfx_v10_0_rlc_start
> + .start = gfx_v10_0_rlc_start,
> + .update_spm_vmid = gfx_v10_0_update_spm_vmid
> };
>
> static int gfx_v10_0_set_powergating_state(void *handle, diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> index 8f20a5dd44fe..b24fc55cf13a 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v7_0.c
> @@ -4221,7 +4221,8 @@ static const struct amdgpu_rlc_funcs gfx_v7_0_rlc_funcs = {
> .resume = gfx_v7_0_rlc_resume,
> .stop = gfx_v7_0_rlc_stop,
> .reset = gfx_v7_0_rlc_reset,
> - .start = gfx_v7_0_rlc_start
> + .start = gfx_v7_0_rlc_start,
> + .update_spm_vmid = NULL
> };
>
> static int gfx_v7_0_early_init(void *handle) diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> index fa245973de12..66640d2b6b37 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v8_0.c
> @@ -5600,7 +5600,8 @@ static const struct amdgpu_rlc_funcs iceland_rlc_funcs = {
> .resume = gfx_v8_0_rlc_resume,
> .stop = gfx_v8_0_rlc_stop,
> .reset = gfx_v8_0_rlc_reset,
> - .start = gfx_v8_0_rlc_start
> + .start = gfx_v8_0_rlc_start,
> + .update_spm_vmid = NULL
> };
>
> static void gfx_v8_0_update_medium_grain_clock_gating(struct
> amdgpu_device *adev, diff --git
> a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> index 9b7ff783e9a5..df872f949f68 100644
> --- a/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> +++ b/drivers/gpu/drm/amd/amdgpu/gfx_v9_0.c
> @@ -4704,6 +4704,18 @@ static int gfx_v9_0_update_gfx_clock_gating(struct amdgpu_device *adev,
> return 0;
> }
>
> +static void gfx_v9_0_update_spm_vmid(struct amdgpu_device *adev,
> +unsigned vmid) {
> + u32 data;
> +
> + data = RREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL);
> +
> + data &= ~RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK;
> + data |= (vmid & RLC_SPM_MC_CNTL__RLC_SPM_VMID_MASK) <<
> +RLC_SPM_MC_CNTL__RLC_SPM_VMID__SHIFT;
> +
> + WREG32_SOC15(GC, 0, mmRLC_SPM_MC_CNTL, data); }
> +
> static const struct amdgpu_rlc_funcs gfx_v9_0_rlc_funcs = {
> .is_rlc_enabled = gfx_v9_0_is_rlc_enabled,
> .set_safe_mode = gfx_v9_0_set_safe_mode, @@ -4715,7 +4727,8 @@
> static const struct amdgpu_rlc_funcs gfx_v9_0_rlc_funcs = {
> .resume = gfx_v9_0_rlc_resume,
> .stop = gfx_v9_0_rlc_stop,
> .reset = gfx_v9_0_rlc_reset,
> - .start = gfx_v9_0_rlc_start
> + .start = gfx_v9_0_rlc_start,
> + .update_spm_vmid = gfx_v9_0_update_spm_vmid
> };
>
> static int gfx_v9_0_set_powergating_state(void *handle,
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org<mailto:amd-gfx@lists.freedesktop.org>
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cdavid1.zhou%40amd.com%7C354be34ff18e4f424f6708d7b52b43b0%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177069753914395&sdata=9rSL4kgPJweuZ4EJpdqtqTxyCVGEkmsg6aUzbtvGFrs%3D&reserved=0<https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cjacob.he%40amd.com%7C0b340cec0e2d41dd4f8c08d7b5ee6f65%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637177908007702357&sdata=dRtYat6X178kHA8kJgsJOfiM9XhjDpmhM7dZTZy11lk%3D&reserved=0>
[-- Attachment #1.2: Type: text/html, Size: 22970 bytes --]
[-- Attachment #2: Type: text/plain, Size: 154 bytes --]
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [PATCH v6 00/16] mm: Page fault enhancements
From: Peter Xu @ 2020-02-20 15:19 UTC (permalink / raw)
To: linux-mm, linux-kernel
Cc: Martin Cracauer, Mike Rapoport, Hugh Dickins, Jerome Glisse,
Kirill A . Shutemov, Matthew Wilcox, Pavel Emelyanov,
Brian Geffon, Maya Gokhale, Denis Plotnikov, Andrea Arcangeli,
Johannes Weiner, Dr . David Alan Gilbert, Linus Torvalds,
Mike Kravetz, Marty McFadden, David Hildenbrand, Bobby Powers,
Mel Gorman
In-Reply-To: <20200220145432.4561-1-peterx@redhat.com>
On Thu, Feb 20, 2020 at 09:54:16AM -0500, Peter Xu wrote:
> This is v6 of the series. It is majorly a rebase to 5.6-rc2, nothing
> else to be expected (plus some tests after the rebase). Instead of
> rewrite the cover letter I decided to use what we have for v5.
My mail server fails again for me during the middle of sending this
series. I wanted to fix this manually but it could have made it even
a bit more messed up... I'll try to fix this all and resend the
series. Sorry. Please ignore this whole thread for now.
There is also another standalone patch:
Subject: [PATCH v6 04/16] x86/mm: Use helper fault_signal_pending()
Message-Id: <20200220150113.5068-1-peterx@redhat.com>
Please ignore that too; that's also some fallout of this misery...
Thanks,
--
Peter Xu
^ permalink raw reply
* Re: [RFC PATCH v3 03/27] qcow2: Process QCOW2_CLUSTER_ZERO_ALLOC clusters in handle_copied()
From: Max Reitz @ 2020-02-20 15:19 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <e327f4c1ed2f9626ce018c1fd2b9db437721b30c.1577014346.git.berto@igalia.com>
[-- Attachment #1.1: Type: text/plain, Size: 4618 bytes --]
I have no idea how I managed to forgot some style comments I wrote
during the review, but, anyway:
On 22.12.19 12:36, Alberto Garcia wrote:
> When writing to a qcow2 file there are two functions that take a
> virtual offset and return a host offset, possibly allocating new
> clusters if necessary:
>
> - handle_copied() looks for normal data clusters that are already
> allocated and have a reference count of 1. In those clusters we
> can simply write the data and there is no need to perform any
> copy-on-write.
>
> - handle_alloc() looks for clusters that do need copy-on-write,
> either because they haven't been allocated yet, because their
> reference count is != 1 or because they are ZERO_ALLOC clusters.
>
> The ZERO_ALLOC case is a bit special because those are clusters that
> are already allocated and they could perfectly be dealt with in
> handle_copied() (as long as copy-on-write is performed when required).
>
> In fact, there is extra code specifically for them in handle_alloc()
> that tries to reuse the existing allocation if possible and frees them
> otherwise.
>
> This patch changes the handling of ZERO_ALLOC clusters so the
> semantics of these two functions are now like this:
>
> - handle_copied() looks for clusters that are already allocated and
> which we can overwrite (NORMAL and ZERO_ALLOC clusters with a
> reference count of 1).
>
> - handle_alloc() looks for clusters for which we need a new
> allocation (all other cases).
>
> One importante difference after this change is that clusters found in
s/importante/important/
> handle_copied() may now require copy-on-write, but this will be anyway
> necessary once we add support for subclusters.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2-cluster.c | 226 +++++++++++++++++++++++-------------------
> 1 file changed, 126 insertions(+), 100 deletions(-)
>
> diff --git a/block/qcow2-cluster.c b/block/qcow2-cluster.c
> index e078bddcc2..9387f15866 100644
> --- a/block/qcow2-cluster.c
> +++ b/block/qcow2-cluster.c
[...]
> @@ -1035,15 +1040,53 @@ void qcow2_alloc_cluster_abort(BlockDriverState *bs, QCowL2Meta *m)
> static void calculate_l2_meta(BlockDriverState *bs,
> uint64_t host_cluster_offset,
> uint64_t guest_offset, unsigned bytes,
> - QCowL2Meta **m, bool keep_old)
> + uint64_t *l2_slice, QCowL2Meta **m, bool keep_old)
> {
[...]
> + /* Return if there's no COW (all clusters are normal and we keep them) */
> + if (keep_old) {
> + int i;
> + for (i = 0; i < nb_clusters; i++) {
> + l2_entry = be64_to_cpu(l2_slice[l2_index + i]);
> + if (qcow2_get_cluster_type(bs, l2_entry) != QCOW2_CLUSTER_NORMAL) {
> + break;
> + }
> + }
> + if (i == nb_clusters) {
> + return;
> + }
> + }
> +
> + /* Get the L2 entry from the first cluster */
s/from/of/
(Otherwise it sounds a bit like this is the same entry for all clusters)
> + l2_entry = be64_to_cpu(l2_slice[l2_index]);
> + type = qcow2_get_cluster_type(bs, l2_entry);
> +
> + if (type == QCOW2_CLUSTER_NORMAL && keep_old) {
> + cow_start_from = cow_start_to;
> + } else {
> + cow_start_from = 0;
> + }
> +
> + /* Get the L2 entry from the last cluster */
s/from/of/
> + l2_entry = be64_to_cpu(l2_slice[l2_index + nb_clusters - 1]);
> + type = qcow2_get_cluster_type(bs, l2_entry);
> +
> + if (type == QCOW2_CLUSTER_NORMAL && keep_old) {
> + cow_end_to = cow_end_from;
> + } else {
> + cow_end_to = ROUND_UP(cow_end_from, s->cluster_size);
> + }
>
> *m = g_malloc0(sizeof(**m));
> **m = (QCowL2Meta) {
> @@ -1069,18 +1112,20 @@ static void calculate_l2_meta(BlockDriverState *bs,
> QLIST_INSERT_HEAD(&s->cluster_allocs, *m, next_in_flight);
> }
>
> -/* Returns true if writing to a cluster requires COW */
> -static bool cluster_needs_cow(BlockDriverState *bs, uint64_t l2_entry)
> +/* Returns true if writing to the cluster pointed to by @l2_entry
> + * requires a new allocation (that is, if the cluster is unallocated
> + * or has refcount > 1 and therefore cannot be written in-place). */
Not sure why Patchew hasn’t complained, but the current coding style
requires /* and */ to be on separate lines for multi-line comments.
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply
* [Intel-gfx] ✓ Fi.CI.IGT: success for series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12. (rev3)
From: Patchwork @ 2020-02-20 15:22 UTC (permalink / raw)
To: Caz Yokoyama; +Cc: intel-gfx
In-Reply-To: <3e1780946bd06f42b9d9e2a2fd1169923dd52e9f.1581444370.git.caz.yokoyama@intel.com>
== Series Details ==
Series: series starting with [1/1] drm/i915: MCHBAR memory info registers are moved since GEN 12. (rev3)
URL : https://patchwork.freedesktop.org/series/73332/
State : success
== Summary ==
CI Bug Log - changes from CI_DRM_7963_full -> Patchwork_16609_full
====================================================
Summary
-------
**SUCCESS**
No regressions found.
New tests
---------
New tests have been introduced between CI_DRM_7963_full and Patchwork_16609_full:
### New IGT tests (58) ###
* igt@i915_pm_backlight@bad-brightness:
- Statuses : 3 pass(s) 4 skip(s)
- Exec time: [0.0, 0.03] s
* igt@i915_pm_backlight@basic-brightness:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.23] s
* igt@i915_pm_backlight@fade:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 2.59] s
* igt@i915_pm_backlight@fade_with_dpms:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.82] s
* igt@i915_pm_backlight@fade_with_suspend:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.50] s
* igt@i915_pm_lpsp@edp-native:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_lpsp@edp-panel-fitter:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.05] s
* igt@i915_pm_lpsp@non-edp:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.12] s
* igt@i915_pm_lpsp@screens-disabled:
- Statuses : 1 pass(s) 7 skip(s)
- Exec time: [0.0, 0.04] s
* igt@i915_pm_rc6_residency@media-rc6-accuracy:
- Statuses : 7 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rc6_residency@rc6-accuracy:
- Statuses : 8 pass(s)
- Exec time: [3.0, 3.00] s
* igt@i915_pm_rpm@basic-pci-d3-state:
- Statuses : 7 pass(s)
- Exec time: [0.25, 5.05] s
* igt@i915_pm_rpm@basic-rte:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [1.39, 11.47] s
* igt@i915_pm_rpm@cursor:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 42.05] s
* igt@i915_pm_rpm@cursor-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 41.34] s
* igt@i915_pm_rpm@debugfs-forcewake-user:
- Statuses : 7 pass(s)
- Exec time: [10.41, 14.33] s
* igt@i915_pm_rpm@debugfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 80.92] s
* igt@i915_pm_rpm@dpms-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 0.82] s
* igt@i915_pm_rpm@dpms-mode-unset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 13.41] s
* igt@i915_pm_rpm@dpms-mode-unset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.04] s
* igt@i915_pm_rpm@dpms-non-lpsp:
- Statuses : 4 pass(s) 3 skip(s)
- Exec time: [0.0, 0.18] s
* igt@i915_pm_rpm@drm-resources-equal:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 11.01] s
* igt@i915_pm_rpm@fences:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.98] s
* igt@i915_pm_rpm@fences-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.00] s
* igt@i915_pm_rpm@gem-evict-pwrite:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 3.92] s
* igt@i915_pm_rpm@gem-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 15.29] s
* igt@i915_pm_rpm@gem-execbuf-stress:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 42.62] s
* igt@i915_pm_rpm@gem-execbuf-stress-pc8:
- Statuses : 8 skip(s)
- Exec time: [0.0, 0.00] s
* igt@i915_pm_rpm@gem-idle:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.14] s
* igt@i915_pm_rpm@gem-pread:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 5.80] s
* igt@i915_pm_rpm@i2c:
- Statuses : 7 pass(s)
- Exec time: [0.90, 11.25] s
* igt@i915_pm_rpm@legacy-planes:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 169.38] s
* igt@i915_pm_rpm@legacy-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 146.76] s
* igt@i915_pm_rpm@modeset-lpsp:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 4.94] s
* igt@i915_pm_rpm@modeset-lpsp-stress:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 51.07] s
* igt@i915_pm_rpm@modeset-lpsp-stress-no-wait:
- Statuses : 3 pass(s) 5 skip(s)
- Exec time: [0.0, 18.23] s
* igt@i915_pm_rpm@modeset-non-lpsp:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 4.04] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 8.14] s
* igt@i915_pm_rpm@modeset-non-lpsp-stress-no-wait:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 7.36] s
* igt@i915_pm_rpm@modeset-pc8-residency-stress:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@modeset-stress-extra-wait:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 73.52] s
* igt@i915_pm_rpm@pc8-residency:
- Statuses : 8 skip(s)
- Exec time: [0.0] s
* igt@i915_pm_rpm@pm-caching:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 19.74] s
* igt@i915_pm_rpm@pm-tiling:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 16.86] s
* igt@i915_pm_rpm@reg-read-ioctl:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 8.00] s
* igt@i915_pm_rpm@sysfs-read:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 4.13] s
* igt@i915_pm_rpm@system-suspend:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 9.01] s
* igt@i915_pm_rpm@system-suspend-devices:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 13.50] s
* igt@i915_pm_rpm@system-suspend-execbuf:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 85.90] s
* igt@i915_pm_rpm@system-suspend-modeset:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 14.66] s
* igt@i915_pm_rpm@universal-planes:
- Statuses : 7 pass(s)
- Exec time: [2.97, 226.18] s
* igt@i915_pm_rpm@universal-planes-dpms:
- Statuses : 7 pass(s) 1 skip(s)
- Exec time: [0.0, 195.46] s
* igt@i915_pm_rps@basic-api:
- Statuses : 8 pass(s)
- Exec time: [0.00, 0.03] s
* igt@i915_pm_rps@min-max-config-idle:
- Statuses : 8 pass(s)
- Exec time: [0.11, 0.60] s
* igt@i915_pm_rps@min-max-config-loaded:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [0.31, 3.02] s
* igt@i915_pm_rps@reset:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [3.52, 3.65] s
* igt@i915_pm_rps@waitboost:
- Statuses : 1 fail(s) 7 pass(s)
- Exec time: [2.52, 2.64] s
* igt@i915_pm_sseu@full-enable:
- Statuses : 4 pass(s) 4 skip(s)
- Exec time: [0.0, 0.01] s
Known issues
------------
Here are the changes found in Patchwork_16609_full that come from known issues:
### IGT changes ###
#### Issues hit ####
* igt@gem_busy@busy-vcs1:
- shard-iclb: [PASS][1] -> [SKIP][2] ([fdo#112080]) +9 similar issues
[1]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_busy@busy-vcs1.html
[2]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb7/igt@gem_busy@busy-vcs1.html
* igt@gem_eio@in-flight-suspend:
- shard-apl: [PASS][3] -> [DMESG-WARN][4] ([i915#180]) +2 similar issues
[3]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@gem_eio@in-flight-suspend.html
[4]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-apl3/igt@gem_eio@in-flight-suspend.html
* igt@gem_exec_schedule@pi-userfault-bsd:
- shard-iclb: [PASS][5] -> [SKIP][6] ([i915#677])
[5]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_exec_schedule@pi-userfault-bsd.html
[6]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb4/igt@gem_exec_schedule@pi-userfault-bsd.html
* igt@gem_exec_schedule@wide-bsd:
- shard-iclb: [PASS][7] -> [SKIP][8] ([fdo#112146]) +4 similar issues
[7]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_schedule@wide-bsd.html
[8]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb2/igt@gem_exec_schedule@wide-bsd.html
* igt@gem_partial_pwrite_pread@writes-after-reads:
- shard-hsw: [PASS][9] -> [FAIL][10] ([i915#694]) +1 similar issue
[9]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_partial_pwrite_pread@writes-after-reads.html
[10]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw4/igt@gem_partial_pwrite_pread@writes-after-reads.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-skl: [PASS][11] -> [FAIL][12] ([i915#644])
[11]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl7/igt@gem_ppgtt@flink-and-close-vma-leak.html
[12]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-skl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
- shard-hsw: [PASS][13] -> [FAIL][14] ([i915#644])
[13]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[14]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw4/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gem_workarounds@suspend-resume-fd:
- shard-kbl: [PASS][15] -> [DMESG-WARN][16] ([i915#180]) +2 similar issues
[15]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl7/igt@gem_workarounds@suspend-resume-fd.html
[16]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-kbl1/igt@gem_workarounds@suspend-resume-fd.html
* igt@i915_selftest@live_gt_lrc:
- shard-tglb: [PASS][17] -> [INCOMPLETE][18] ([i915#1233])
[17]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb8/igt@i915_selftest@live_gt_lrc.html
[18]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-tglb3/igt@i915_selftest@live_gt_lrc.html
* igt@kms_cursor_legacy@all-pipes-forked-bo:
- shard-tglb: [PASS][19] -> [DMESG-WARN][20] ([i915#402])
[19]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb3/igt@kms_cursor_legacy@all-pipes-forked-bo.html
[20]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-tglb3/igt@kms_cursor_legacy@all-pipes-forked-bo.html
* igt@kms_flip@2x-flip-vs-expired-vblank:
- shard-glk: [PASS][21] -> [FAIL][22] ([i915#79])
[21]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk2/igt@kms_flip@2x-flip-vs-expired-vblank.html
[22]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-glk8/igt@kms_flip@2x-flip-vs-expired-vblank.html
* igt@kms_flip@flip-vs-absolute-wf_vblank:
- shard-tglb: [PASS][23] -> [FAIL][24] ([i915#488])
[23]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_flip@flip-vs-absolute-wf_vblank.html
[24]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-tglb1/igt@kms_flip@flip-vs-absolute-wf_vblank.html
* igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt:
- shard-tglb: [PASS][25] -> [SKIP][26] ([i915#668]) +6 similar issues
[25]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb2/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt.html
[26]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-tglb1/igt@kms_frontbuffer_tracking@fbcpsr-1p-primscrn-indfb-plflip-blt.html
* igt@kms_psr@psr2_cursor_blt:
- shard-iclb: [PASS][27] -> [SKIP][28] ([fdo#109441]) +1 similar issue
[27]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb2/igt@kms_psr@psr2_cursor_blt.html
[28]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb3/igt@kms_psr@psr2_cursor_blt.html
* igt@kms_vblank@pipe-c-ts-continuation-suspend:
- shard-skl: [PASS][29] -> [INCOMPLETE][30] ([i915#69])
[29]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl5/igt@kms_vblank@pipe-c-ts-continuation-suspend.html
[30]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-skl4/igt@kms_vblank@pipe-c-ts-continuation-suspend.html
* igt@perf_pmu@cpu-hotplug:
- shard-hsw: [PASS][31] -> [INCOMPLETE][32] ([i915#1176] / [i915#61])
[31]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@perf_pmu@cpu-hotplug.html
[32]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw5/igt@perf_pmu@cpu-hotplug.html
* igt@prime_busy@hang-bsd2:
- shard-iclb: [PASS][33] -> [SKIP][34] ([fdo#109276]) +23 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_16609/shard-iclb5/igt@prime_busy@hang-bsd2.html
#### Possible fixes ####
* {igt@gem_ctx_persistence@close-replace-race}:
- shard-iclb: [FAIL][35] ([i915#1241]) -> [PASS][36]
[35]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@gem_ctx_persistence@close-replace-race.html
[36]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb4/igt@gem_ctx_persistence@close-replace-race.html
* {igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox}:
- shard-skl: [FAIL][37] ([i915#679]) -> [PASS][38]
[37]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl8/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
[38]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-skl10/igt@gem_ctx_persistence@legacy-engines-mixed-process@vebox.html
* igt@gem_exec_balancer@smoke:
- shard-iclb: [SKIP][39] ([fdo#110854]) -> [PASS][40]
[39]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb5/igt@gem_exec_balancer@smoke.html
[40]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb1/igt@gem_exec_balancer@smoke.html
* {igt@gem_exec_schedule@implicit-write-read-bsd1}:
- shard-iclb: [SKIP][41] ([fdo#109276] / [i915#677]) -> [PASS][42]
[41]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb7/igt@gem_exec_schedule@implicit-write-read-bsd1.html
[42]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb1/igt@gem_exec_schedule@implicit-write-read-bsd1.html
* igt@gem_exec_schedule@in-order-bsd:
- shard-iclb: [SKIP][43] ([fdo#112146]) -> [PASS][44] +4 similar issues
[43]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@gem_exec_schedule@in-order-bsd.html
[44]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb3/igt@gem_exec_schedule@in-order-bsd.html
* igt@gem_exec_schedule@independent-bsd2:
- shard-iclb: [SKIP][45] ([fdo#109276]) -> [PASS][46] +15 similar issues
[45]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb3/igt@gem_exec_schedule@independent-bsd2.html
[46]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb4/igt@gem_exec_schedule@independent-bsd2.html
* igt@gem_exec_store@cachelines-vcs1:
- shard-iclb: [SKIP][47] ([fdo#112080]) -> [PASS][48] +10 similar issues
[47]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_exec_store@cachelines-vcs1.html
[48]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb4/igt@gem_exec_store@cachelines-vcs1.html
* igt@gem_ppgtt@flink-and-close-vma-leak:
- shard-glk: [FAIL][49] ([i915#644]) -> [PASS][50]
[49]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-glk8/igt@gem_ppgtt@flink-and-close-vma-leak.html
[50]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-glk4/igt@gem_ppgtt@flink-and-close-vma-leak.html
- shard-apl: [FAIL][51] ([i915#644]) -> [PASS][52]
[51]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl1/igt@gem_ppgtt@flink-and-close-vma-leak.html
[52]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-apl3/igt@gem_ppgtt@flink-and-close-vma-leak.html
* igt@gem_tiled_blits@interruptible:
- shard-hsw: [FAIL][53] ([i915#818]) -> [PASS][54]
[53]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw1/igt@gem_tiled_blits@interruptible.html
[54]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw5/igt@gem_tiled_blits@interruptible.html
* igt@kms_cursor_crc@pipe-a-cursor-size-change:
- shard-snb: [SKIP][55] ([fdo#109271]) -> [PASS][56] +1 similar issue
[55]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-snb4/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
[56]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-snb7/igt@kms_cursor_crc@pipe-a-cursor-size-change.html
* igt@kms_cursor_crc@pipe-a-cursor-suspend:
- shard-apl: [DMESG-WARN][57] ([i915#180]) -> [PASS][58] +1 similar issue
[57]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
[58]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-apl6/igt@kms_cursor_crc@pipe-a-cursor-suspend.html
* igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy:
- shard-hsw: [FAIL][59] ([i915#96]) -> [PASS][60]
[59]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw8/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
[60]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw7/igt@kms_cursor_legacy@2x-long-cursor-vs-flip-legacy.html
* igt@kms_fbcon_fbt@fbc-suspend:
- shard-kbl: [DMESG-WARN][61] ([i915#180]) -> [PASS][62]
[61]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl1/igt@kms_fbcon_fbt@fbc-suspend.html
[62]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-kbl2/igt@kms_fbcon_fbt@fbc-suspend.html
* igt@kms_flip@flip-vs-expired-vblank-interruptible:
- shard-skl: [FAIL][63] ([i915#79]) -> [PASS][64]
[63]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl5/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
[64]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-skl2/igt@kms_flip@flip-vs-expired-vblank-interruptible.html
* igt@kms_flip@flip-vs-suspend-interruptible:
- shard-hsw: [INCOMPLETE][65] ([i915#61]) -> [PASS][66]
[65]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@kms_flip@flip-vs-suspend-interruptible.html
[66]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw5/igt@kms_flip@flip-vs-suspend-interruptible.html
* igt@kms_frontbuffer_tracking@psr-1p-rte:
- shard-tglb: [SKIP][67] ([i915#668]) -> [PASS][68]
[67]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-tglb5/igt@kms_frontbuffer_tracking@psr-1p-rte.html
[68]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-tglb1/igt@kms_frontbuffer_tracking@psr-1p-rte.html
* igt@kms_plane_alpha_blend@pipe-a-coverage-7efc:
- shard-skl: [FAIL][69] ([fdo#108145]) -> [PASS][70]
[69]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl9/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
[70]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-skl7/igt@kms_plane_alpha_blend@pipe-a-coverage-7efc.html
* igt@kms_psr@no_drrs:
- shard-iclb: [FAIL][71] ([i915#173]) -> [PASS][72]
[71]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb1/igt@kms_psr@no_drrs.html
[72]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb4/igt@kms_psr@no_drrs.html
* igt@kms_psr@psr2_cursor_plane_move:
- shard-iclb: [SKIP][73] ([fdo#109441]) -> [PASS][74] +1 similar issue
[73]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb4/igt@kms_psr@psr2_cursor_plane_move.html
[74]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb2/igt@kms_psr@psr2_cursor_plane_move.html
* igt@kms_setmode@basic:
- shard-apl: [FAIL][75] ([i915#31]) -> [PASS][76]
[75]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-apl2/igt@kms_setmode@basic.html
[76]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-apl6/igt@kms_setmode@basic.html
* igt@kms_vblank@pipe-a-ts-continuation-suspend:
- shard-skl: [INCOMPLETE][77] ([i915#69]) -> [PASS][78]
[77]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-skl3/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
[78]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-skl5/igt@kms_vblank@pipe-a-ts-continuation-suspend.html
* igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend:
- shard-kbl: [INCOMPLETE][79] ([fdo#103665]) -> [PASS][80] +1 similar issue
[79]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
[80]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-kbl1/igt@kms_vblank@pipe-c-ts-continuation-dpms-suspend.html
* igt@perf@short-reads:
- shard-kbl: [TIMEOUT][81] ([fdo#112271] / [i915#51]) -> [PASS][82]
[81]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-kbl6/igt@perf@short-reads.html
[82]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-kbl6/igt@perf@short-reads.html
* igt@prime_mmap_coherency@ioctl-errors:
- shard-hsw: [FAIL][83] ([i915#831]) -> [PASS][84]
[83]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@prime_mmap_coherency@ioctl-errors.html
[84]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw4/igt@prime_mmap_coherency@ioctl-errors.html
#### Warnings ####
* igt@gem_ctx_isolation@vcs1-nonpriv:
- shard-iclb: [SKIP][85] ([fdo#112080]) -> [FAIL][86] ([IGT#28]) +1 similar issue
[85]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-iclb6/igt@gem_ctx_isolation@vcs1-nonpriv.html
[86]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-iclb4/igt@gem_ctx_isolation@vcs1-nonpriv.html
* igt@gem_tiled_blits@normal:
- shard-hsw: [FAIL][87] ([i915#818]) -> [FAIL][88] ([i915#694])
[87]: https://intel-gfx-ci.01.org/tree/drm-tip/CI_DRM_7963/shard-hsw2/igt@gem_tiled_blits@normal.html
[88]: https://intel-gfx-ci.01.org/tree/drm-tip/Patchwork_16609/shard-hsw4/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
[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#110854]: https://bugs.freedesktop.org/show_bug.cgi?id=110854
[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
[i915#1176]: https://gitlab.freedesktop.org/drm/intel/issues/1176
[i915#1197]: https://gitlab.freedesktop.org/drm/intel/issues/1197
[i915#1233]: https://gitlab.freedesktop.org/drm/intel/issues/1233
[i915#1239]: https://gitlab.freedesktop.org/drm/intel/issues/1239
[i915#1241]: https://gitlab.freedesktop.org/drm/intel/issues/1241
[i915#173]: https://gitlab.freedesktop.org/drm/intel/issues/173
[i915#180]: https://gitlab.freedesktop.org/drm/intel/issues/180
[i915#31]: https://gitlab.freedesktop.org/drm/intel/issues/31
[i915#402]: https://gitlab.freedesktop.org/drm/intel/issues/402
[i915#488]: https://gitlab.freedesktop.org/drm/intel/issues/488
[i915#51]: https://gitlab.freedesktop.org/drm/intel/issues/51
[i915#61]: https://gitlab.freedesktop.org/drm/intel/issues/61
[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
[i915#96]: https://gitlab.freedesktop.org/drm/intel/issues/96
Participating hosts (10 -> 10)
------------------------------
No changes in participating hosts
Build changes
-------------
* CI: CI-20190529 -> None
* Linux: CI_DRM_7963 -> Patchwork_16609
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_16609: 8d576d7a32d859ba01ad2c4a0948387b8bbda35e @ 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_16609/index.html
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [yocto] Bitbake returning non-zero due to sstate errors
From: Paul Barker @ 2020-02-20 15:22 UTC (permalink / raw)
To: Richard Purdie; +Cc: Yocto discussion list
In-Reply-To: <b5158d1f6ef3cebc4bff046b28c8851ba7db29ac.camel@linuxfoundation.org>
On Thu, 20 Feb 2020 at 12:04, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
>
> On Thu, 2020-02-20 at 11:59 +0000, Paul Barker wrote:
> > I'm now looking into this...
> >
> > In sstate_checkhashes() we mark sstate as available if
> > fetcher.checkstatus() succeeds. Then at a later point
> > sstate_setscene() calls sstate_installpkg() calls pstaging_fetch()
> > calls fetcher.download() to actually get the sstate artifact. If the
> > artifact is removed from the mirror between these two accesses (due
> > to an sstate mirror clean up running in parallel to a build), or if
> > there is an intermittent download failure we could see checkstatus()
> > succeed then download() fail.
> >
> > I don't think we should ignore all setscene errors but in the
> > specific case where it's the download step that fails I think that
> > should be a warning. Or it could be an error by default with a
> > variable we can set to turn it into a warning. Does that sound
> > reasonable? If so I'll work up a patch.
>
> Thinking about the code, I'm not sure how you're generically going to
> tell the difference between a setscene task that fails as the file
> disappeared compared to a setscene failure with another real error? :/
>
> We could make all failed setscene tasks warnings but I think that
> buries actual real errors.
>
> This is probably why I've not changed the code before now.
>
> Special exit code values? :/
>
> I'm open to proposals.
>
> I know we could put in some configuration option but in general I hate
> these as it just means more test matrix combinations and more ways for
> people to see different behaviours. They have a time/place but I'm not
> sure its here.
I agree - I really don't want to have to add additional complexity
here. But I do think we need to fix this in some way, others are
affected by this as can be seen from previous discussions. And in the
case of a public sstate mirror we can't control when users decide to
run builds, there will always be the chance of a user running a build
on an old commit while old sstate artifacts are cleaned or starting a
build just as the mirror is taken offline for some maintenance.
I think we might be able to make this work if we can avoid adding any
new conditional logic to the fetcher itself. I can see that almost
every call to logger.error() is followed by raising an error - perhaps
we could rework the code to include all the relevant info in the
raised error object and allow higher level code to catch the exception
and decide what to do with it. Because once logger.error() is called,
knotty counts an error and bitbake will exit non-zero even if the
error is safely handled. Once the fetcher simply raises exceptions in
the case of failed downloads we could handle this neatly in
sstate.bbclass. Would that be a viable way forward? Or would that
break the other fetcher use cases?
Thanks,
Paul
^ permalink raw reply
* Re: USB questions
From: Alan Stern @ 2020-02-20 15:23 UTC (permalink / raw)
To: Greg KH; +Cc: James, linux-usb
In-Reply-To: <20200220072745.GA3240818@kroah.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=UTF-8, Size: 3194 bytes --]
On Thu, 20 Feb 2020, Greg KH wrote:
> On Wed, Feb 19, 2020 at 04:55:28PM -0500, James wrote:
> > https://asrock.com/MB/AMD/B450M%20Pro4/index.us.asp#Specification
> > - 2 x USB 2.0 Ports (Supports ESD Protection)
> > - 1 x USB 3.1 Gen2 Type-A Port (10 Gb/s) (Supports ESD Protection)
> > - 1 x USB 3.1 Gen2 Type-C Port (10 Gb/s) (Supports ESD Protection)
> > - 4 x USB 3.1 Gen1 Ports (Supports ESD Protection)
> >
> > $ lsusb
> > Bus 004 Device 002: ID 13fe:6300 Kingston Technology Company Inc. USB DISK
> > 3.0
> > Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> > Bus 003 Device 004: ID 051d:0002 American Power Conversion Uninterruptible
> > Power Supply
> > Bus 003 Device 003: ID 04a9:190f Canon, Inc. CanoScan LiDE 220
> > Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> > Bus 002 Device 002: ID 0bc2:2321 Seagate RSS LLC Expansion Portable
> > Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
> > Bus 001 Device 006: ID 1bcf:0005 Sunplus Innovation Technology Inc. Optical
> > Mouse
> > Bus 001 Device 005: ID 04d9:1503 Holtek Semiconductor, Inc. Keyboard
> > Bus 001 Device 004: ID 1a40:0101 Terminus Technology Inc. Hub
> > Bus 001 Device 003: ID 046d:082c Logitech, Inc. HD Webcam C615
> > Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
> >
> > $ lsusb -t
> > /: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
> > |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
> > /: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 480M
> > |__ Port 2: Dev 3, If 0, Class=Vendor Specific Class, Driver=, 480M
> > |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbfs,
> > 1.5M
> > /: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
> > |__ Port 2: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
> > /: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 480M
> > |__ Port 5: Dev 3, If 0, Class=Audio, Driver=snd-usb-audio, 480M
> > |__ Port 5: Dev 3, If 1, Class=Audio, Driver=snd-usb-audio, 480M
> > |__ Port 5: Dev 3, If 2, Class=Video, Driver=uvcvideo, 480M
> > |__ Port 5: Dev 3, If 3, Class=Video, Driver=uvcvideo, 480M
> > |__ Port 6: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
> > |__ Port 3: Dev 6, If 0, Class=Human Interface Device,
> > Driver=usbhid, 1.5M
> > |__ Port 1: Dev 5, If 1, Class=Human Interface Device,
> > Driver=usbhid, 1.5M
> > |__ Port 1: Dev 5, If 0, Class=Human Interface Device,
> > Driver=usbhid, 1.5M
> >
> >
> > 1. Does this mean the installer used the USB2 connections on the motherboard
> > even though it looks like USB3.1 Gen ones were available?
>
> No, why do you say that?
>
> > 2. What is the number after the slash (4p) on xhci_hcd/4p?
>
> ports.
>
> > 3. Shouldn't "Linux Foundation 3.0 root hub" be "Linux Foundation 3.1 Gen 1
> > root hub"?
>
> No, we don't say that from within the kernel.
But there's no reason we couldn't. Greg, you could allocate a new
Product ID value for USB-3.1 root hubs and update lsusb to recognize
it. (I don't know if it's worth including the "Gen 1" vs "Gen 2" part,
though.)
Alan Stern
^ permalink raw reply
* Re: [RFC PATCH v3 04/27] qcow2: Add get_l2_entry() and set_l2_entry()
From: Eric Blake @ 2020-02-20 15:22 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <a1be1f4311da643b439cb5e1924b0ddfb052f338.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> The size of an L2 entry is 64 bits, but if we want to have subclusters
> we need extended L2 entries. This means that we have to access L2
> tables and slices differently depending on whether an image has
> extended L2 entries or not.
>
> This patch replaces all l2_slice[] accesses with calls to
> get_l2_entry() and set_l2_entry().
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2-cluster.c | 65 ++++++++++++++++++++++--------------------
> block/qcow2-refcount.c | 17 +++++------
> block/qcow2.h | 12 ++++++++
> 3 files changed, 55 insertions(+), 39 deletions(-)
>
> @@ -978,12 +981,12 @@ int qcow2_alloc_cluster_link_l2(BlockDriverState *bs, QCowL2Meta *m)
> * cluster the second one has to do RMW (which is done above by
> * perform_cow()), update l2 table with its cluster pointer and free
> * old cluster. This is what this loop does */
> - if (l2_slice[l2_index + i] != 0) {
> - old_cluster[j++] = l2_slice[l2_index + i];
> + if (get_l2_entry(s, l2_slice, l2_index + i) != 0) {
> + old_cluster[j++] = get_l2_entry(s, l2_slice, l2_index + i);
> }
>
> - l2_slice[l2_index + i] = cpu_to_be64((cluster_offset +
> - (i << s->cluster_bits)) | QCOW_OFLAG_COPIED);
> + set_l2_entry(s, l2_slice, l2_index + i, QCOW_OFLAG_COPIED |
> + (cluster_offset + (i << s->cluster_bits)));
Cute commutative law use for line length reasons.
> +++ b/block/qcow2.h
scripts/git.orderfile can be used to hoist this part of the patch to the
front of the message (as it is more valuable to review first).
> @@ -495,6 +495,18 @@ typedef enum QCow2MetadataOverlap {
>
> #define INV_OFFSET (-1ULL)
>
> +static inline uint64_t get_l2_entry(BDRVQcow2State *s, uint64_t *l2_slice,
> + int idx)
> +{
> + return be64_to_cpu(l2_slice[idx]);
> +}
> +
> +static inline void set_l2_entry(BDRVQcow2State *s, uint64_t *l2_slice,
> + int idx, uint64_t entry)
> +{
> + l2_slice[idx] = cpu_to_be64(entry);
> +}
> +
Reviewed-by: Eric Blake <eblake@redhat.com>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* [PATCH v2] iomap: return partial I/O count on error in iomap_dio_bio_actor
From: Goldwyn Rodrigues @ 2020-02-20 15:23 UTC (permalink / raw)
To: linux-ext4; +Cc: linux-fsdevel, hch, darrick.wong
In case of a block device error, written parameter in iomap_end()
is zero as opposed to the amount of submitted I/O.
Filesystems such as btrfs need to account for the I/O in ordered
extents, even if it resulted in an error. Having (incomplete)
submitted bytes in written gives the filesystem the amount of data
which has been submitted before the error occurred, and the
filesystem code can choose how to use it.
The final returned error for iomap_dio_rw() is set by
iomap_dio_complete().
Partial writes in direct I/O are considered an error. So,
->iomap_end() using written == 0 as error must be changed
to written < length. In this case, ext4 is the only user.
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
---
fs/ext4/inode.c | 2 +-
fs/iomap/direct-io.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e60aca791d3f..e50e7414351a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3475,7 +3475,7 @@ static int ext4_iomap_end(struct inode *inode, loff_t offset, loff_t length,
* the I/O. Any blocks that may have been allocated in preparation for
* the direct I/O will be reused during buffered I/O.
*/
- if (flags & (IOMAP_WRITE | IOMAP_DIRECT) && written == 0)
+ if (flags & (IOMAP_WRITE | IOMAP_DIRECT) && written < length)
return -ENOTBLK;
return 0;
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 41c1e7c20a1f..01865db1bd09 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -264,7 +264,7 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
size_t n;
if (dio->error) {
iov_iter_revert(dio->submit.iter, copied);
- copied = ret = 0;
+ ret = 0;
goto out;
}
--
2.25.0
^ permalink raw reply related
* 回复: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
From: Liu, Monk @ 2020-02-20 15:24 UTC (permalink / raw)
To: Das, Nirmoy, amd-gfx@lists.freedesktop.org
In-Reply-To: <c778adb5-1ded-3b66-3f74-120f3388d611@amd.com>
I don't know
The patch is from me, I just think the patch is dropping a vm update which looks not perfect to me
-----邮件原件-----
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Nirmoy
发送时间: 2020年2月20日 23:21
收件人: amd-gfx@lists.freedesktop.org
主题: Re: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
Hi Monk,
How can I reproduce this bug ?
Regards,
Nirmoy
On 2/20/20 4:15 PM, Nirmoy wrote:
>
> On 2/20/20 2:35 PM, Liu, Monk wrote:
>> Sorry, my previous idea still leave RQ null, please check if below
>> method works:
>>
>> 29 static struct drm_sched_rq *
>> 130 drm_sched_entity_get_free_sched(struct drm_sched_entity *entity)
>> 131 {
>> 132 struct drm_sched_rq *rq = NULL;
>> 133 unsigned int min_jobs = UINT_MAX, num_jobs;
>> 134 int i;
>>
>> 135
>> While (!mutex_trylock(....))
>> Sleep()
> We can't do that drm_sched_entity_get_free_sched is in another
> module(drm scheduler) independent of amdgpu
>> 136 for (i = 0; i < entity->num_rq_list; ++i) {
>> 137 struct drm_gpu_scheduler *sched =
>> entity->rq_list[i]->sched;
>> 138
>> 139 if (!entity->rq_list[i]->sched->ready) { //we take the
>> gpu reset mutex lock, so now sched->ready won't be set to "not ready"
>> 140 DRM_WARN("sched%s is not ready, skipping",
>> sched->name);
>> 141 continue;
>> 142 }
>> 143
>> 144 num_jobs = atomic_read(&sched->num_jobs);
>> 145 if (num_jobs < min_jobs) {
>> 146 min_jobs = num_jobs;
>> 147 rq = entity->rq_list[i];
>> 148 }
>> 149 }
>>
>> Mutex_unlock(...)
>>
>> 150
>> 151 return rq;
>> 152 }
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> nk.liu%40amd.com%7C3635fc8baa4d4b90387108d7b6188069%7C3dd8961fe4884e60
> 8e11a82d994e183d%7C0%7C0%7C637178088661253651&sdata=Ki0SmulPESLIj7
> dGyT10Be0zXungK4U9fXONp45NjaA%3D&reserved=0
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7C3635fc8baa4d4b90387108d7b6188069%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178088661253651&sdata=Ki0SmulPESLIj7dGyT10Be0zXungK4U9fXONp45NjaA%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* [PATCH v2] iomap: return partial I/O count on error in iomap_dio_bio_actor
From: Goldwyn Rodrigues @ 2020-02-20 15:24 UTC (permalink / raw)
To: linux-ext4; +Cc: linux-fsdevel, hch, darrick.wong
In case of a block device error, written parameter in iomap_end()
is zero as opposed to the amount of submitted I/O.
Filesystems such as btrfs need to account for the I/O in ordered
extents, even if it resulted in an error. Having (incomplete)
submitted bytes in written gives the filesystem the amount of data
which has been submitted before the error occurred, and the
filesystem code can choose how to use it.
The final returned error for iomap_dio_rw() is set by
iomap_dio_complete().
Partial writes in direct I/O are considered an error. So,
->iomap_end() using written == 0 as error must be changed
to written < length. In this case, ext4 is the only user.
Signed-off-by: Goldwyn Rodrigues <rgoldwyn@suse.com>
---
fs/ext4/inode.c | 2 +-
fs/iomap/direct-io.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c
index e60aca791d3f..e50e7414351a 100644
--- a/fs/ext4/inode.c
+++ b/fs/ext4/inode.c
@@ -3475,7 +3475,7 @@ static int ext4_iomap_end(struct inode *inode, loff_t offset, loff_t length,
* the I/O. Any blocks that may have been allocated in preparation for
* the direct I/O will be reused during buffered I/O.
*/
- if (flags & (IOMAP_WRITE | IOMAP_DIRECT) && written == 0)
+ if (flags & (IOMAP_WRITE | IOMAP_DIRECT) && written < length)
return -ENOTBLK;
return 0;
diff --git a/fs/iomap/direct-io.c b/fs/iomap/direct-io.c
index 41c1e7c20a1f..01865db1bd09 100644
--- a/fs/iomap/direct-io.c
+++ b/fs/iomap/direct-io.c
@@ -264,7 +264,7 @@ iomap_dio_bio_actor(struct inode *inode, loff_t pos, loff_t length,
size_t n;
if (dio->error) {
iov_iter_revert(dio->submit.iter, copied);
- copied = ret = 0;
+ ret = 0;
goto out;
}
--
2.25.0
--
Goldwyn
^ permalink raw reply related
* Re: [PATCH v3 15/16] net: qrtr: Do not depend on ARCH_QCOM
From: Bjorn Andersson @ 2020-02-20 15:23 UTC (permalink / raw)
To: Manivannan Sadhasivam
Cc: gregkh, arnd, smohanad, jhugo, kvalo, hemantk, linux-arm-msm,
linux-kernel, David S. Miller, netdev
In-Reply-To: <20200220095854.4804-16-manivannan.sadhasivam@linaro.org>
On Thu 20 Feb 01:58 PST 2020, Manivannan Sadhasivam wrote:
> IPC Router protocol is also used by external modems for exchanging the QMI
> messages. Hence, it doesn't always depend on Qualcomm platforms. As a side
> effect of removing the ARCH_QCOM dependency, it is going to miss the
> COMPILE_TEST build coverage.
The COMPILE_TEST was there so that the code could be compile tested on
other platforms, but without the ARCH_QCOM dependency this will always
be the case. So I would suggest that you drop the last sentence. (Or
write "With this we no longer need to depend on COMPILE_TEST, so remove
that too.")
Reviewed-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Regards,
Bjorn
>
> Cc: "David S. Miller" <davem@davemloft.net>
> Cc: netdev@vger.kernel.org
> Signed-off-by: Manivannan Sadhasivam <manivannan.sadhasivam@linaro.org>
> ---
> net/qrtr/Kconfig | 1 -
> 1 file changed, 1 deletion(-)
>
> diff --git a/net/qrtr/Kconfig b/net/qrtr/Kconfig
> index 8eb876471564..f362ca316015 100644
> --- a/net/qrtr/Kconfig
> +++ b/net/qrtr/Kconfig
> @@ -4,7 +4,6 @@
>
> config QRTR
> tristate "Qualcomm IPC Router support"
> - depends on ARCH_QCOM || COMPILE_TEST
> ---help---
> Say Y if you intend to use Qualcomm IPC router protocol. The
> protocol is used to communicate with services provided by other
> --
> 2.17.1
>
^ permalink raw reply
* [PATCH] alsa-utils: upgrade 1.2.1 -> 1.2.2
From: praveen @ 2020-02-20 15:02 UTC (permalink / raw)
To: openembedded-core
Signed-off-by: Praveen Muthusamy <praveen@linumiz.com>
---
...lsa-utils-scripts_1.2.1.bb => alsa-utils-scripts_1.2.2.bb} | 0
.../alsa/{alsa-utils_1.2.1.bb => alsa-utils_1.2.2.bb} | 4 ++--
2 files changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-multimedia/alsa/{alsa-utils-scripts_1.2.1.bb =>
alsa-utils-scripts_1.2.2.bb} (100%)
rename meta/recipes-multimedia/alsa/{alsa-utils_1.2.1.bb =>
alsa-utils_1.2.2.bb} (97%)
diff --git a/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.1.bb
b/meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.2.bb
similarity index 100%
rename from meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.1.bb
rename to meta/recipes-multimedia/alsa/alsa-utils-scripts_1.2.2.bb
diff --git a/meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
b/meta/recipes-multimedia/alsa/alsa-utils_1.2.2.bb
similarity index 97%
rename from meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
rename to meta/recipes-multimedia/alsa/alsa-utils_1.2.2.bb
index 9144af628a..8bbc5d3ef3 100644
--- a/meta/recipes-multimedia/alsa/alsa-utils_1.2.1.bb
+++ b/meta/recipes-multimedia/alsa/alsa-utils_1.2.2.bb
@@ -21,8 +21,8 @@ PACKAGECONFIG[manpages] = "--enable-xmlto,
--disable-xmlto, xmlto-native docbook
# alsa-utils specified in SRC_URI due to alsa-utils-scripts recipe
SRC_URI =
"https://www.alsa-project.org/files/pub/utils/alsa-utils-${PV}.tar.bz2"
-SRC_URI[md5sum] = "c4628bae7632937eac2de4cf2a3de82e"
-SRC_URI[sha256sum] =
"0b110ba71ef41d3009db1bc4dcae0cf79efb99cb5426fa19d0312470560a2c0d"
+SRC_URI[md5sum] = "00612234ff4722c8f7f8f7a83ff9bc63"
+SRC_URI[sha256sum] =
"44807bd578c5f6df6e91a11b8d37e546424a5a1ea8d8e659ee359fe01730e4f3"
# On build machines with python-docutils (not python3-docutils !!)
installed
# rst2man (not rst2man.py) is detected and compile fails with
--
2.17.1
^ permalink raw reply related
* Re: [RFC PATCH v3 06/27] qcow2: Add dummy has_subclusters() function
From: Eric Blake @ 2020-02-20 15:24 UTC (permalink / raw)
To: Alberto Garcia, qemu-devel
Cc: Kevin Wolf, Anton Nefedov, qemu-block, Max Reitz,
Vladimir Sementsov-Ogievskiy, Denis V . Lunev
In-Reply-To: <bebe4058df5210ac3293e917ad6b61abac398f60.1577014346.git.berto@igalia.com>
On 12/22/19 5:36 AM, Alberto Garcia wrote:
> This function will be used by the qcow2 code to check if an image has
> subclusters or not.
>
> At the moment this simply returns false. Once all patches needed for
> subcluster support are ready then QEMU will be able to create and
> read images with subclusters and this function will return the actual
> value.
>
> Signed-off-by: Alberto Garcia <berto@igalia.com>
> ---
> block/qcow2.h | 6 ++++++
> 1 file changed, 6 insertions(+)
Reviewed-by: Eric Blake <eblake@redhat.com>
>
> diff --git a/block/qcow2.h b/block/qcow2.h
> index 6823d3f68f..1db3fc5dbc 100644
> --- a/block/qcow2.h
> +++ b/block/qcow2.h
> @@ -495,6 +495,12 @@ typedef enum QCow2MetadataOverlap {
>
> #define INV_OFFSET (-1ULL)
>
> +static inline bool has_subclusters(BDRVQcow2State *s)
> +{
> + /* FIXME: Return false until this feature is complete */
> + return false;
> +}
> +
> static inline uint64_t get_l2_entry(BDRVQcow2State *s, uint64_t *l2_slice,
> int idx)
> {
>
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization: qemu.org | libvirt.org
^ permalink raw reply
* 回复: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
From: Liu, Monk @ 2020-02-20 15:25 UTC (permalink / raw)
To: Liu, Monk, Das, Nirmoy, amd-gfx@lists.freedesktop.org
In-Reply-To: <DM6PR12MB3931DCBEB1DC6C722605E6F484130@DM6PR12MB3931.namprd12.prod.outlook.com>
Isn't from me... damn keyboard
-----邮件原件-----
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Liu, Monk
发送时间: 2020年2月20日 23:24
收件人: Das, Nirmoy <Nirmoy.Das@amd.com>; amd-gfx@lists.freedesktop.org
主题: 回复: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
I don't know
The patch is from me, I just think the patch is dropping a vm update which looks not perfect to me
-----邮件原件-----
发件人: amd-gfx <amd-gfx-bounces@lists.freedesktop.org> 代表 Nirmoy
发送时间: 2020年2月20日 23:21
收件人: amd-gfx@lists.freedesktop.org
主题: Re: 回复: [PATCH] drm/amdgpu: fix a bug NULL pointer dereference
Hi Monk,
How can I reproduce this bug ?
Regards,
Nirmoy
On 2/20/20 4:15 PM, Nirmoy wrote:
>
> On 2/20/20 2:35 PM, Liu, Monk wrote:
>> Sorry, my previous idea still leave RQ null, please check if below
>> method works:
>>
>> 29 static struct drm_sched_rq *
>> 130 drm_sched_entity_get_free_sched(struct drm_sched_entity *entity)
>> 131 {
>> 132 struct drm_sched_rq *rq = NULL;
>> 133 unsigned int min_jobs = UINT_MAX, num_jobs;
>> 134 int i;
>>
>> 135
>> While (!mutex_trylock(....))
>> Sleep()
> We can't do that drm_sched_entity_get_free_sched is in another
> module(drm scheduler) independent of amdgpu
>> 136 for (i = 0; i < entity->num_rq_list; ++i) {
>> 137 struct drm_gpu_scheduler *sched =
>> entity->rq_list[i]->sched;
>> 138
>> 139 if (!entity->rq_list[i]->sched->ready) { //we take the
>> gpu reset mutex lock, so now sched->ready won't be set to "not ready"
>> 140 DRM_WARN("sched%s is not ready, skipping",
>> sched->name);
>> 141 continue;
>> 142 }
>> 143
>> 144 num_jobs = atomic_read(&sched->num_jobs);
>> 145 if (num_jobs < min_jobs) {
>> 146 min_jobs = num_jobs;
>> 147 rq = entity->rq_list[i];
>> 148 }
>> 149 }
>>
>> Mutex_unlock(...)
>>
>> 150
>> 151 return rq;
>> 152 }
>>
> _______________________________________________
> amd-gfx mailing list
> amd-gfx@lists.freedesktop.org
> https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flist
> s.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmo
> nk.liu%40amd.com%7C3635fc8baa4d4b90387108d7b6188069%7C3dd8961fe4884e60
> 8e11a82d994e183d%7C0%7C0%7C637178088661253651&sdata=Ki0SmulPESLIj7
> dGyT10Be0zXungK4U9fXONp45NjaA%3D&reserved=0
>
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7C81ad7d959e7a4ed972bb08d7b618fc41%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178090738811091&sdata=7BAfVNQKI92Mbw7B2kBRYoEnM2OxDwtedu%2FM7r6cJZ4%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.freedesktop.org%2Fmailman%2Flistinfo%2Famd-gfx&data=02%7C01%7Cmonk.liu%40amd.com%7C81ad7d959e7a4ed972bb08d7b618fc41%7C3dd8961fe4884e608e11a82d994e183d%7C0%7C0%7C637178090738811091&sdata=7BAfVNQKI92Mbw7B2kBRYoEnM2OxDwtedu%2FM7r6cJZ4%3D&reserved=0
_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx
^ permalink raw reply
* Re: [dpdk-dev] [PATCH] net/mlx5: fix running without rxq
From: Raslan Darawsheh @ 2020-02-20 15:26 UTC (permalink / raw)
To: Shiri Kuzin, dev@dpdk.org, srn@nexatech.fr
Cc: Matan Azrad, Slava Ovsiienko, stable@dpdk.org
In-Reply-To: <1582209716-26527-1-git-send-email-shirik@mellanox.com>
Hi,
> -----Original Message-----
> From: Shiri Kuzin <shirik@mellanox.com>
> Sent: Thursday, February 20, 2020 4:42 PM
> To: dev@dpdk.org
> Cc: Matan Azrad <matan@mellanox.com>; Raslan Darawsheh
> <rasland@mellanox.com>; Slava Ovsiienko <viacheslavo@mellanox.com>;
> stable@dpdk.org
> Subject: [PATCH] net/mlx5: fix running without rxq
>
> When running mlx5_dev_start in mlx5_ethdev the function calls
> mlx5_dev_configure_rss_reta in order to configure the rxq's.
>
> Before mlx5_dev_configure_rss_reta there isn't a check whether
> there are rxq's and if rxq's are 0 the function fails.
> For example, this command:
> /build/app/test-pmd/testpmd -n 4 -w 0000:08:00.0,rx_vec_en=0
> -- --burst=64 --mbcache=512 -i --nb-cores=27 --txd=2048 --rxd=2048
> --vxlan-gpe-port=6081 --mp-alloc=xbuf --rxq 0 --forward-mode=txonly
> would fail.
>
> In order to fix this issue, we should call mlx5_dev_configure_rss_reta
> only if we have rxq's.
>
> Fixes: 63bd16292c3a ("net/mlx5: support RSS on hairpin")
> Cc: stable@dpdk.org
>
Reported-by: Sylvain <srn@nexatech.fr>
> Signed-off-by: Shiri Kuzin <shirik@mellanox.com>
> Acked-by: Matan Azrad <matan@mellanox.com>
> ---
> drivers/net/mlx5/mlx5_trigger.c | 12 +++++++-----
> 1 file changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/net/mlx5/mlx5_trigger.c
> b/drivers/net/mlx5/mlx5_trigger.c
> index be47df5..571b7a0 100644
> --- a/drivers/net/mlx5/mlx5_trigger.c
> +++ b/drivers/net/mlx5/mlx5_trigger.c
> @@ -280,11 +280,13 @@
> rte_net_mlx5_dynf_inline_mask = 1UL << fine_inline;
> else
> rte_net_mlx5_dynf_inline_mask = 0;
> - ret = mlx5_dev_configure_rss_reta(dev);
> - if (ret) {
> - DRV_LOG(ERR, "port %u reta config failed: %s",
> - dev->data->port_id, strerror(rte_errno));
> - return -rte_errno;
> + if (dev->data->nb_rx_queues > 0) {
> + ret = mlx5_dev_configure_rss_reta(dev);
> + if (ret) {
> + DRV_LOG(ERR, "port %u reta config failed: %s",
> + dev->data->port_id, strerror(rte_errno));
> + return -rte_errno;
> + }
> }
> ret = mlx5_txq_start(dev);
> if (ret) {
> --
> 1.8.3.1
Patch applied to next-net-mlx,
Kindest regards,
Raslan Darawsheh
^ permalink raw reply
* Re: functionfs gadget with multiple endpoints
From: Alan Stern @ 2020-02-20 15:26 UTC (permalink / raw)
To: Belisko Marek; +Cc: Linux USB Mailing List
In-Reply-To: <CAAfyv36n=--KiHmdyS7hOGzF8fVtq8y=uZx0cxARgp7fUta4ng@mail.gmail.com>
On Thu, 20 Feb 2020, Belisko Marek wrote:
> Hi,
>
> I'm playing with functionfs and use configfs + functionfs + ffs-test
> from kernel to test connection between my device and host. ffs-test
> example provide 1 configuration with 1 interface and with 2 bulk
> endpoints.
>
> I'm writing application which will write/read data to usb device but
> can be accessed from other multiple application. I'm planning to write
> kind of gatekeeper which will serialize data to endpoint and notify
> reader about received data.
>
> I was thinking about other possibility to extend gadget to provide
> more endpoints (like 2). I was able to extend ffs-test and also I can
> send/receive data (using libusb) over original endpoints but not over
> new created one (I've run 2 instances of same application which
> basically create transfers for 2 different endpoints) but when running
> second application I got this error:
>
> libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=16
> libusb: error [submit_bulk_transfer] submiturb failed error -1 errno=16
Only one program at a time can claim an interface, and submitting an
URB to an endpoint automatically claims the endpoint's interface.
> I'm not USB expert but multiple endpoint should be possible (maybe I
> need to put them to other interface?-> tried that also but got same
> error as above with errno=2). Thanks for any pointers and advice.
errno=16 and errno=2 are different errors, not the same error.
Putting the endpoints in different interfaces should work; you probably
have a bug somewhere in your code.
Alan Stern
^ 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.