search for: fqs

...ests (test generic/464) but no repro for QEMU, so the fault may be on the side of crosvm. The dump for the crosvm/xfstests stall: [ 2504.175276] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 2504.176681] rcu: 0-...!: (1 GPs behind) idle=9b2/1/0x4000000000000000 softirq=1089198/1089202 fqs=0 [ 2504.178270] rcu: 2-...!: (1 ticks this GP) idle=cfe/1/0x4000000000000002 softirq=1055108/1055110 fqs=0 [ 2504.179802] rcu: 3-...!: (1 GPs behind) idle=1d6/1/0x4000000000000002 softirq=1046798/1046802 fqs=0 [ 2504.181215] rcu: 4-...!: (2 ticks this GP) idle=522/1/0x40000000000000...

...ests (test generic/464) but no repro for QEMU, so the fault may be on the side of crosvm. The dump for the crosvm/xfstests stall: [ 2504.175276] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: [ 2504.176681] rcu: 0-...!: (1 GPs behind) idle=9b2/1/0x4000000000000000 softirq=1089198/1089202 fqs=0 [ 2504.178270] rcu: 2-...!: (1 ticks this GP) idle=cfe/1/0x4000000000000002 softirq=1055108/1055110 fqs=0 [ 2504.179802] rcu: 3-...!: (1 GPs behind) idle=1d6/1/0x4000000000000002 softirq=1046798/1046802 fqs=0 [ 2504.181215] rcu: 4-...!: (2 ticks this GP) idle=522/1/0x40000000000000...

...did not see any of this in my and your testing with Qemu. > > > The dump for the crosvm/xfstests stall: > [ 2504.175276] rcu: INFO: rcu_sched detected stalls on CPUs/tasks: > [ 2504.176681] rcu: 0-...!: (1 GPs behind) idle=9b2/1/0x4000000000000000 > softirq=1089198/1089202 fqs=0 > [ 2504.178270] rcu: 2-...!: (1 ticks this GP) > idle=cfe/1/0x4000000000000002 softirq=1055108/1055110 fqs=0 > [ 2504.179802] rcu: 3-...!: (1 GPs behind) idle=1d6/1/0x4000000000000002 > softirq=1046798/1046802 fqs=0 > [ 2504.181215] rcu: 4-...!: (2 ticks this GP) >...

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

On 5/14/19 7:54 AM, Pankaj Gupta wrote: > + if (!list_empty(&vpmem->req_list)) { > + req_buf = list_first_entry(&vpmem->req_list, > + struct virtio_pmem_request, list); > + req_buf->wq_buf_avail = true; > + wake_up(&req_buf->wq_buf); > + list_del(&req_buf->list); Yes, this change is the right one, thank you! > + /* > + * If

...04ba724 [PATCH] netfilter: nfnetlink: extended ACK reporting nft 5de112c [PATCH] include: Remove datatype_register() [Wed Jul 12 12:47:45 2017] INFO: rcu_sched self-detected stall on CPU [Wed Jul 12 12:47:45 2017] 0-...: (5249 ticks this GP) idle=dca/140000000000001/0 softirq=2845/2845 fqs=2623 [Wed Jul 12 12:47:45 2017] (t=5251 jiffies g=1649 c=1648 q=99) [Wed Jul 12 12:47:45 2017] NMI backtrace for cpu 0 [Wed Jul 12 12:47:45 2017] CPU: 0 PID: 1489 Comm: nft Not tainted 4.12.0-rc2+ #86 [Wed Jul 12 12:47:45 2017] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011 [Wed Jul 12 12:...

https://bugs.freedesktop.org/show_bug.cgi?id=101553 Bug ID: 101553 Summary: [ 8.944203] nouveau 0000:01:00.0: DRM: failed to create kernel channel, -22 Product: xorg Version: unspecified Hardware: Other OS: All Status: NEW Severity: normal Priority: medium

...4 <4d> 85 e4 75 cd 49 8b 86 80 00 00 00 48 8d b8 30 26 00 00 e8 16 [ 4067.622934] nouveau 0000:01:00.0: fifo: SCHED_ERROR 0a [CTXSW_TIMEOUT] [ 4071.796744] INFO: rcu_sched self-detected stall on CPU [ 4071.796751] 4-...: (15000 ticks this GP) idle=47b/140000000000001/0 softirq=374433/374433 fqs=14495 [ 4071.796753] (t=15000 jiffies g=289046 c=289045 q=4218) [ 4071.796757] Task dump for CPU 4: [ 4071.796759] kworker/4:1 R running task 0 6743 2 0x00000008 [ 4071.796809] Workqueue: events gk104_fifo_recover_work [nouveau] [ 4071.796811] ffffffff81c53e40 ffff88023fd03dc8...

...55 48 c7 c6 43 53 0a bd 48 89 e5 e8 19 ff ff ff b8 ff ff ff ff 5d c3 8b 07 <c3> 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00 48 81 fe ff ff [ 91.721133] INFO: rcu_sched self-detected stall on CPU [ 91.721137] 6-...: (15000 ticks this GP) idle=c15/140000000000001/0 softirq=603/603 fqs=7479 [ 91.721138] (t=15001 jiffies g=343 c=342 q=90238) [ 91.721139] Task dump for CPU 6: [ 91.721139] plymouthd R running task 0 227 1 0x00000008 [ 91.721140] Call Trace: [ 91.721141] <IRQ> [ 91.721143] sched_show_task+0xd5/0x140 [ 91.721144] d...

...to the core dump. This triggers lockdep_assert_held(&walk.mm->mmap_sem) in walk_page_range(). 2) Then after a delay, I get: [ 137.852986] rcu: INFO: rcu_sched self-detected stall on CPU [ 137.858594] rcu: 0-....: (26000 ticks this GP) idle=69e/1/0x4000000000000002 softirq=34555/34555 fqs=6497 [ 137.868439] (t=26007 jiffies g=14653 q=271) [ 137.872711] NMI backtrace for cpu 0 [ 137.876205] CPU: 0 PID: 6228 Comm: hmm-tests Not tainted 5.6.0-rc6+ #2 [ 137.882730] Hardware name: System manufacturer System Product Name/SABERTOOTH X79, BIOS 4302 08/29/2013 [ 137.892115] Call Trace:...

On 3/17/20 5:59 AM, Christoph Hellwig wrote: > On Tue, Mar 17, 2020 at 09:47:55AM -0300, Jason Gunthorpe wrote: >> I've been using v7 of Ralph's tester and it is working well - it has >> DEVICE_PRIVATE support so I think it can test this flow too. Ralph are >> you able? >> >> This hunk seems trivial enough to me, can we include it now? > > I can send

This adds infrastructure required for supporting multiple ring formats. The idea is as follows: we convert descriptors to an independent format first, and process that converting to iov later. Used ring is similar: we fetch into an independent struct first, convert that to IOV later. The point is that we have a tight loop that fetches descriptors, which is good for cache utilization. This will

...0 active=1/1 [ 2106.072247] pending: addrconf_verify_work [ 2106.072250] pool 0: cpus=0 node=0 flags=0x0 nice=0 hung=2099s workers=3 idle: 339 1446 [ 2107.382179] INFO: rcu_sched self-detected stall on CPU [ 2107.382184] 0-....: (210098 ticks this GP) idle=bae/140000000000001/0 softirq=382/382 fqs=97823 [ 2107.382185] (t=210099 jiffies g=-237 c=-238 q=28) [ 2107.382188] NMI backtrace for cpu 0 [ 2107.382191] CPU: 0 PID: 3 Comm: kworker/0:0 Tainted: G L 4.15.0-rc4-next2g-g400b6af-dirty #2 [ 2107.382192] Hardware name: Marvell Armada 380/385 (Device Tree) [ 2107.382195] Workque...