search for: warn_on

From: Dave Airlie <airlied at redhat.com> These WARN_ONs seem to trigger a lot, and we don't seem to have a plan to fix them, so just drop them, as they are most likely harmless. Cc: stable at vger.kernel.org Signed-off-by: Dave Airlie <airlied at redhat.com> --- drivers/gpu/drm/nouveau/nvkm/subdev/gsp/r535.c | 12 ++++++------ 1 file change...

...019 at 09:33:36AM -0400, Ilia Mirkin wrote: >Hi Greg, > >This feels like it's missing a From: line. > >commit b513a18cf1d705bd04efd91c417e79e4938be093 >Author: Lyude Paul <lyude at redhat.com> >Date: Mon Jan 28 16:03:50 2019 -0500 > > drm/nouveau: Don't WARN_ON VCPI allocation failures > >Is this an artifact of your notification-of-patches process and I >never noticed before, or was the patch ingested incorrectly? It was always like this for patches that came through me. Greg's script generates an explicit "From:" line in the patch...

On Tue, Nov 05, 2019 at 10:16:46AM -0500, Boris Ostrovsky wrote: > > So, I suppose it can be relaxed to a null test and a WARN_ON that it > > hasn't changed? > > You mean > > if (use_ptemod) { > ??????? WARN_ON(map->vma != vma); > ??????? ... > > > Yes, that sounds good. I amended my copy of the patch with the above, has this rework shown signs of working? @@ -436,7 +436,8 @@ stat...

...u/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder) slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn); r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, slots); - WARN_ON(!r); + if (!r) + DRM_DEBUG_KMS("Failed to allocate VCPI\n"); if (!mstm->links++) nv50_outp_acquire(mstm->outp); -- 2.20.1

...gt; > This feels like it's missing a From: line. >> > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 >> > Author: Lyude Paul <lyude at redhat.com> >> > Date: Mon Jan 28 16:03:50 2019 -0500 >> > >> > drm/nouveau: Don't WARN_ON VCPI allocation failures >> > >> > Is this an artifact of your notification-of-patches process and I >> > never noticed before, or was the patch ingested incorrectly? >> >> It was always like this for patches that came through me. Greg's script >> ge...

Hi Greg, This feels like it's missing a From: line. commit b513a18cf1d705bd04efd91c417e79e4938be093 Author: Lyude Paul <lyude at redhat.com> Date: Mon Jan 28 16:03:50 2019 -0500 drm/nouveau: Don't WARN_ON VCPI allocation failures Is this an artifact of your notification-of-patches process and I never noticed before, or was the patch ingested incorrectly? Cheers, -ilia On Fri, Sep 13, 2019 at 9:16 AM Greg Kroah-Hartman <gregkh at linuxfoundation.org> wrote: > > [ Upstream commit b51...

...Hi Greg, > > > > This feels like it's missing a From: line. > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > Author: Lyude Paul <lyude at redhat.com> > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > > drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > Is this an artifact of your notification-of-patches process and I > > never noticed before, or was the patch ingested incorrectly? > > It was always like this for patches that came through me. Greg's script > generates an explicit &q...

...ssing a From: line. > > > > > > > > commit b513a18cf1d705bd04efd91c417e79e4938be093 > > > > Author: Lyude Paul <lyude at redhat.com> > > > > Date: Mon Jan 28 16:03:50 2019 -0500 > > > > > > > > drm/nouveau: Don't WARN_ON VCPI allocation failures > > > > > > > > Is this an artifact of your notification-of-patches process and I > > > > never noticed before, or was the patch ingested incorrectly? > > > > > > It was always like this for patches that came through me...

...9;s missing a From: line. > >> > > >> > commit b513a18cf1d705bd04efd91c417e79e4938be093 > >> > Author: Lyude Paul <lyude at redhat.com> > >> > Date: Mon Jan 28 16:03:50 2019 -0500 > >> > > >> > drm/nouveau: Don't WARN_ON VCPI allocation failures > >> > > >> > Is this an artifact of your notification-of-patches process and I > >> > never noticed before, or was the patch ingested incorrectly? > >> > >> It was always like this for patches that came through me. Greg...

.../enlighten.c b/arch/x86/xen/enlighten.c index 974a528..55e3cc7 100644 --- a/arch/x86/xen/enlighten.c +++ b/arch/x86/xen/enlighten.c @@ -724,8 +724,9 @@ static u32 xen_apic_read(u32 reg) static void xen_apic_write(u32 reg, u32 val) { - /* Warn to see if there''s any stray references */ - WARN_ON(1); + printk(KERN_WARNING "xen: unexpected APIC write %#x to reg %#x\n", + val, reg); + dump_stack(); } static u64 xen_apic_icr_read(void) @@ -735,8 +736,9 @@ static u64 xen_apic_icr_read(void) static void xen_apic_icr_write(u32 low, u32 id) { - /* Warn to see if there'...

...u/nouveau_bo.c b/drivers/gpu/drm/nouveau/nouveau_bo.c index f8015e0318d7..18857cf44068 100644 --- a/drivers/gpu/drm/nouveau/nouveau_bo.c +++ b/drivers/gpu/drm/nouveau/nouveau_bo.c @@ -276,8 +276,10 @@ nouveau_bo_alloc(struct nouveau_cli *cli, u64 *size, int *align, u32 flags, break; } - if (WARN_ON(pi < 0)) + if (WARN_ON(pi < 0)) { + kfree(nvbo); return ERR_PTR(-EINVAL); + } /* Disable compression if suitable settings couldn't be found. */ if (nvbo->comp && !vmm->page[pi].comp) { -- 2.17.1

Hi all, Did someone have met this problem before. When doing the tests, I hit the WARN_ON. Is this log make sense or someone had fixed the problem. If needed, I can supply the detail log and the testcase source file. Version: the latest codes at linus git tree. [ 2140.981293] use_block_rsv: 336 callbacks suppressed [ 2140.981295] ------------[ cut here ]------------ [ 2140.981308]...

https://bugs.freedesktop.org/show_bug.cgi?id=102135 Bug ID: 102135 Summary: WARN_ON hit when loading G71 with v4.13-rc3 Product: xorg Version: unspecified Hardware: PowerPC OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at li...

...list_for_each_entry(mirror, &hmm->mirrors, list) { > > int rc; > > > > - rc = mirror->ops->sync_cpu_device_pagetables(mirror, &update); > > + rc = mirror->ops->sync_cpu_device_pagetables(mirror, nrange); > > if (rc) { > > - if (WARN_ON(update.blockable || rc != -EAGAIN)) > > + if (WARN_ON(mmu_notifier_range_blockable(nrange) || > > + rc != -EAGAIN)) > > continue; > > ret = -EAGAIN; > > break; > > This magic handling of error seems odd. I think we should merge rc and >...

https://bugs.freedesktop.org/show_bug.cgi?id=93634 Bug ID: 93634 Summary: WARN_ON triggered on DPMS event Product: xorg Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/nouveau Assignee: nouveau at lists.f...

@@ -491,16 +512,15 @@ int pirq_guest_bind(struct vcpu *v, int int rc = 0; cpumask_t cpumask = CPU_MASK_NONE; + WARN_ON(!spin_is_locked(&v->domain->evtchn_lock)); I find this WARN_ON() is triggered harmlessly when I assign device to HVM guest. The call trace is XEN_DOMCTL_bind_pt_irq -> pt_irq_create_bind_vtd() -> pirq_guest_bind(). Should we remove the WARN_ON here? Thanks, -- Dexuan -----Origin...

..._refill(struct receive_queue >>> *rq) >>> +{ >>> + int rc = true; >>> + >> bool instead of int...? > Yes, it was better. >>> + spin_lock(&rq->lock); >>> + if (rq->state & VIRTNET_RQ_LOCKED) { >>> + WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI); >>> + rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD; >>> + rc = false; >>> + } else >>> + /* we don't care if someone yielded */ >>> + rq->state = VIRTNET_RQ_STATE_NAPI; >&...

..._refill(struct receive_queue >>> *rq) >>> +{ >>> + int rc = true; >>> + >> bool instead of int...? > Yes, it was better. >>> + spin_lock(&rq->lock); >>> + if (rq->state & VIRTNET_RQ_LOCKED) { >>> + WARN_ON(rq->state & VIRTNET_RQ_STATE_NAPI); >>> + rq->state |= VIRTNET_RQ_STATE_NAPI_YIELD; >>> + rc = false; >>> + } else >>> + /* we don't care if someone yielded */ >>> + rq->state = VIRTNET_RQ_STATE_NAPI; >&...

...u/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -811,7 +811,8 @@ nv50_msto_enable(struct drm_encoder *encoder) slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn); r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, slots); - WARN_ON(!r); + if (!r) + DRM_DEBUG_KMS("Failed to allocate VCPI\n"); if (!mstm->links++) nv50_outp_acquire(mstm->outp); -- 2.20.1

...u/drm/nouveau/dispnv50/disp.c +++ b/drivers/gpu/drm/nouveau/dispnv50/disp.c @@ -759,7 +759,8 @@ nv50_msto_enable(struct drm_encoder *encoder) slots = drm_dp_find_vcpi_slots(&mstm->mgr, mstc->pbn); r = drm_dp_mst_allocate_vcpi(&mstm->mgr, mstc->port, mstc->pbn, slots); - WARN_ON(!r); + if (!r) + DRM_DEBUG_KMS("Failed to allocate VCPI\n"); if (!mstm->links++) nv50_outp_acquire(mstm->outp); -- 2.20.1