daily CVS update output

2022-01-03 Thread NetBSD source update


Updating src tree:
P src/distrib/amd64/installimage/Makefile
P src/distrib/amd64/installimage/install.sh
P src/distrib/amd64/installimage/spec.inst
P src/distrib/amd64/installimage-bios/Makefile
P src/distrib/amd64/installimage-bios/install.sh
P src/distrib/amd64/installimage-bios/spec.inst
P src/distrib/sets/lists/debug/ad.arm
cvs update: `src/distrib/sets/lists/debug/ad.earmv5' is no longer in the 
repository
cvs update: `src/distrib/sets/lists/debug/ad.earmv5eb' is no longer in the 
repository
P src/distrib/sets/lists/debug/ad.mipsel
P src/doc/CHANGES
P src/sys/arch/arm/apple/files.apple
P src/sys/arch/evbarm/conf/GENERIC64
P src/sys/conf/files
U src/sys/dev/acpi/eqos_acpi.c
P src/sys/dev/acpi/files.acpi
U src/sys/dev/ic/dwc_eqos.c
U src/sys/dev/ic/dwc_eqos_reg.h
U src/sys/dev/ic/dwc_eqos_var.h
P src/sys/dev/mii/files.mii
U src/sys/dev/mii/mcommphy.c
P src/usr.sbin/sysinst/util.c

Updating xsrc tree:


Killing core files:




Updating file list:
-rw-rw-r--  1 srcmastr  netbsd  43636552 Jan  4 03:03 ls-lRA.gz


Re: HEADS UP: Merging drm update

2022-01-03 Thread Taylor R Campbell
> Date: Mon, 03 Jan 2022 22:08:26 +0900
> From: Ryo ONODERA 
> 
> Ryo ONODERA  writes:
> 
> > __engines_record_defaults
> > intel_gt_wait_for_idle
> > intel_gt_retire_requests_timeout
> > dma_fence_wait_timeout
> > i915_fence_wait (via *fence->ops->wait)
> > i915_request_wait
> >
> > In i915_request_wait, DRM_SPIN_TIMED_WAIT_UNTIL sets timeout=0
> > and i915_request_wait returns timeout=-ETIME.

Thanks, I think there's something going wrong either with submitting
requests or noticing that they're submitted, but it only happens on
some machines.  It might be related to some of the other panics around
requests, like the cv_is_valid panic in signal_irq_work (56561), or it
might be something is mapped wrong or there's a missing cache flush /
bus_dmamap_sync...  Will investigate when I have a chance.


Re: HEADS UP: Merging drm update

2022-01-03 Thread Ryo ONODERA
Hi,

If you missed, could you read my following email?

Thank you.

Ryo ONODERA  writes:

> Hi,
>
> Taylor R Campbell  writes:
>
>>> Date: Tue, 28 Dec 2021 11:34:43 +0900
>>> From: Ryo ONODERA 
>>> 
>>> intel_gt_pm_fini() at netbsd:intel_gt_pm_fini+0x18
>>> intel_gt_init() at netbsd:intel_gt_init+0x6ad
>>> i915_gem_init() at netbsd:i915_gem_init+0x14d
>>> i915_driver_probe() at netbsd:i915_driver_probe+0x949
>>> i915drmkms_attach_real() at netbsd:i915drmkms_attach_real+0x4c
>>> config_mountroot_thread() at netbsd:config_mountroot_thread+0x60
>>
>> So intel_gt_init is failing on boot, and the driver has decided to
>> give up -- and proximate cause of the crash is that one of the error
>> branches is screwy, but while it would be nice to fix the error
>> branches it's more important to find why we're reaching them in the
>> first place.
>>
>> Can you get a line number for intel_gt_init+0x6ad, and can you also
>> insert prints into every error branch of intel_gt_init to find out
>> which one it is and how it fails?  And maybe do that recursively in
>> whichever branch does fail?
>
> In sys/external/bsd/drm2/dist/drm/i915/gt/intel_gt.c: intel_gt_init(),
> __engines_record_defaults(gt) failed and went to err_gt label,
> then the panic happened.
> "intel_gt_init+0x6ad" is err_uc_init's intel_uc_fini(>->uc).
>
> (snip)
> err = __engines_record_defaults(gt);
> if (err)
> goto err_gt;
> (snip)
> err_gt:
> __intel_gt_disable(gt);
> intel_uc_fini_hw(>->uc);
> err_uc_init:
> intel_uc_fini(>->uc);
> err_engines:
> intel_engines_release(gt);
> i915_vm_put(fetch_and_zero(>->vm));
> err_pm:
> intel_gt_pm_fini(gt);
> intel_gt_fini_scratch(gt);
> out_fw:
> if (err)
> (snip)
>
>
> And I have added some printfs to __engines_record_defaults() and
> the other functions invoked from __engines_record_defaults() as follows.
>
> __engines_record_defaults
> intel_gt_wait_for_idle
> intel_gt_retire_requests_timeout
> dma_fence_wait_timeout
> i915_fence_wait (via *fence->ops->wait)
> i915_request_wait
>
> In i915_request_wait, DRM_SPIN_TIMED_WAIT_UNTIL sets timeout=0
> and i915_request_wait returns timeout=-ETIME.
>
> #ifdef __NetBSD__
> spin_lock(rq->fence.lock);
> #define C   (i915_request_completed(rq) ? 1 : 
> \
> (spin_unlock(rq->fence.lock), 
> \
> intel_engine_flush_submission(rq->engine),
> \
> spin_lock(rq->fence.lock),
> \
> i915_request_completed(rq)))
> if (flags & I915_WAIT_INTERRUPTIBLE) {
> DRM_SPIN_TIMED_WAIT_UNTIL(timeout, &wait.wq,
> rq->fence.lock, timeout,
> C);
> } else {
> DRM_SPIN_TIMED_WAIT_NOINTR_UNTIL(timeout, &wait.wq,
> rq->fence.lock, timeout,
> C);
> }
> #undef  C
> if (timeout > 0) {  /* succeeded before timeout */
> KASSERT(i915_request_completed(rq));
> dma_fence_signal_locked(&rq->fence);
> } else if (timeout == 0) {  /* timed out */
> timeout = -ETIME;
> }
> spin_unlock(rq->fence.lock);
> DRM_DESTROY_WAITQUEUE(&wait.wq);
> #else
>
>
> Thank you.
>
> -- 
> Ryo ONODERA // r...@tetera.org
> PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3

-- 
Ryo ONODERA // r...@tetera.org
PGP fingerprint = 82A2 DC91 76E0 A10A 8ABB  FD1B F404 27FA C7D1 15F3