kdriver: gate fops_read/fops_write timeout logs behind #ifdef DEBUG#2
Open
scyto wants to merge 1 commit into
Open
kdriver: gate fops_read/fops_write timeout logs behind #ifdef DEBUG#2scyto wants to merge 1 commit into
scyto wants to merge 1 commit into
Conversation
memx_fops_read() and memx_fops_write() log an info-level message on every
wait_event_interruptible_timeout() timeout ("wait timeout N(s), retrying
again") and then re-arm. These are the only un-guarded pr_info() calls in
the two ioctl wait loops -- every other diagnostic in this file, including
the success-side "received ofmap/ifmap ... done" logs immediately after
each loop, is already wrapped in #ifdef DEBUG.
In a non-DEBUG build the read-side message floods the kernel log: an idle
but open device (e.g. Frigate holding the accelerator between motion-gated
detections) has no output feature map to return, so the 10s read timeout
fires every ~10s indefinitely on a perfectly healthy device. It is pure
log noise, not an error -- inference resumes normally as soon as work
arrives.
Wrap both timeout logs in #ifdef DEBUG to match the surrounding convention,
so they remain available in debug builds (the Makefile passes -DDEBUG) and
are silent otherwise. Applied to both the kdriver and 32bit_driver copies.
No functional change: the wait loops are driven by the while (wq_status < 1)
condition; the gated if/pr_info was diagnostic only.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
memx_fops_read()andmemx_fops_write()each emit an un-guardedpr_infoon everywait_event_interruptible_timeout()timeout:These are the only un-guarded
pr_info()calls in the two ioctl wait loops — every other diagnostic in the file, including the success-sidereceived ofmap/ifmap … donelogs immediately after each loop, is already wrapped in#ifdef DEBUG.In a non-
DEBUGbuild the read-side message floods the kernel log: an idle but open device has no output feature map to return, so the 10 s read timeout fires every ~10 s indefinitely on a perfectly healthy card. This is very visible under Frigate, which keeps aread()posted for the next inference result and only feeds the accelerator on motion — so between detections the log streams this line forever. It's pure noise, not an error: inference resumes normally as soon as work arrives.Fix
Wrap both timeout logs in
#ifdef DEBUG, matching the surrounding convention, so they stay available in debug builds (the Makefile passes-DDEBUG) and are silent otherwise. Applied to both thekdriver/and32bit_driver/kdriver/copies.No functional change — the wait loops are driven by the
while (wq_status < 1)condition; the gatedif/pr_infowas diagnostic only.Testing
Built and run on TrueNAS SCALE (kernel
6.12.91-production+truenas) with an MX3 M.2 + Frigate 0.17 (SDK 2.1), via the memryx-mx3-support sysext:dmesgstreamedfops_read: wait timeout 10(s)every ~10 s while Frigate was idle./api/statsreportsinference_speed ≈ 11.6 ms(unchanged),detection_start 0.0(healthy idle).Context: discussed on the MemryX community forum thread "Frigate on TrueNAS" with @mx-tim.