Frank
2a3c0da740
MEMORY.md/learned.md/memory_summary.md/raw_memories.md churn from live sessions (DIFR deadlock diagnosis, model-swap ops, outpost verification etc.); new memory root --home-dank-.omp-agent-- started with learned.md.
5.6 KiB
5.6 KiB
- The FLM (FastFlowLM) service on Dankclaw (gemma4-it:e4b, port 7771) only supports PNG and JPEG/JPG image formats. WebP images are rejected with "Unsupported image format, skipping this image." The data URL formats it expects are data:image/png;base64, data:image/jpeg;base64, and data:image/jpg;base64. To use WebP screenshots with the NPU, convert them to PNG first. Verified 2026-08-30: a WebP screenshot (1024x576, 71K) was rejected while the same content as PNG was correctly identified by the vision model. (context: Dankclaw NPU (FLM, gemma4-it:e4b, port 7771) — image format support investigation)
- When configuring dankclaw-npu (FLM NPU endpoint on port 7771) in models.json, the model entry must include a thinkingLevelMap field. The other two providers (dankserver, dankclaw) have it; if absent, schema validation fails. Pattern: {"thinkingLevelMap": {"max": "xhigh"}}. Also verify gemma4-it:e4b model ID is registered and .xclbin kernel symlink exists under /home/dank/.config/flm/xclbins/. (context: Dankclaw NPU endpoint (dankclaw-npu provider, port 7771) had a schema error because gemma4-it:e4b was missing thinkingLevelMap. Fixed by adding it to both models.json and models.yml. The FLM NPU serves 34 models in its registry; gemma4-it:e4b is the currently wired model.)
- Dankclaw NPU serves 34 FLM (FastFlowLM) models on port 7771. Only one is wired in models.json (gemma4-it:e4b) but all 34 are registered and available via per-request model routing without restart. Known behavior: single-lane NPU queues FIFO, per-request model switch costs ~7–11s wall for 4B-class reload. Common pitfall: some registered tags fail if .xclbin kernel pack symlink is missing under /home/dank/.config/flm/xclbins/ (fix: ln -s /opt/fastflowlm/share/flm/xclbins/PackName). Registry probe: curl http://192.168.0.143:7771/v1/models.
- Frank's cursor size is 36 (up from default 24) on Dankware running niri/Wayland. Applied via three channels: gsettings org.gnome.desktop.interface cursor-size=36 (primary), GTK settings.ini gtk-cursor-theme-size=36 (fallback), XCURSOR_SIZE=36 in ~/.profile (sessions). Cursor theme: capitaine-cursors. (context: Dankware workstation — Frank requested a bigger mouse pointer; set to 36 across gsettings, GTK config, and environment)
- Frank's default browser is Firefox (firefox.desktop), set via xdg-settings on Dankware (niri/Wayland). Previously was Chromium. Changes persist across reboots. (context: Dankware workstation — Frank changed default from Chromium to Firefox via xdg-settings set default-web-browser firefox.desktop)
- Dankware (RTX 4070 Laptop, nvidia-open 610.57.04, kernel 7.2.0-1-cachyos, DynamicPowerManagement=2) suffers the known 610.x NVKMS DIFR-prefetch deadlock: nvidia-modeset/kthread_q livelocks in DifrPrefetchEventDeferredWork→nvWriteGpEntry holding the NVKMS API semaphore; any compositor (niri) atomic commit then wedges in D-state in ApplyModeSetConfig/nvkms_ioctl_from_kapi_try_pmlock. Symptoms: GUI frozen, no VT switch, SSH alive, nvidia-smi still answers (GPU idle P8, no Xid). Trigger: display-idle then flip/modeset. Unrecoverable in place — reboot via systemctl reboot --force --force. Candidate mitigations: NVreg_RegistryDwords="RMDisableDIFR=1" (one upstream report says ineffective) and DynamicPowerManagement=0. Bug class spans 595.71–610.57 upstream. (context: 2026-08-30 GUI lockup diagnosis on dankware; user suspected nvidia modesetter, confirmed via hung-task stacks. Pending user decision on writing modprobe mitigation.)
- When downloading large model shards (40GB) to dankclaw via SSH: 1. NEVER run rm on partial downloads — always clean up BEFORE starting the first download 2. Ensure only ONE wget process per file — if you see duplicate wget PIDs killing them with kill -9 before restarting, or use fuser to verify exclusivity 3. Use wget -c (continue) to resume partial downloads — SSH connections often drop mid-download on large files (~300s timeout) 4. Download sequentially (not in parallel) when using background task agents that may spawn duplicate processes, or coordinate downloads through a single agent session 5. Verify each file's size against expected values after download completes
- kingjones777's Qwen3.8-Flash-Next ROCmFP4 builds for Strix Halo (gfx1151) have three tiers: FAST (~88 GiB), STRIX_LEAN (~98.5 GiB, 3-shard), STRIX (~113.5 GiB). All are text-only — no vision tower, no mmproj, no fused MTP draft head. Uses TYPE_100/TYPE_101 ROCmFP4 tensor types (general.file_type=106), requires patched llama.cpp PR #27742 from ROCmFPX fork. STRIX_LEAN carries a 35.76 GiB PLE n-gram table streamed off SSD at runtime; ~63 GiB GTT for non-PLE weights, ~75 GiB at full 262K context. Uncensored variants exist from orcarouter but only for Qwen3.8-27B (not Flash-Next), and in non-ROCmFP4 format. (context: User requested kingjones777/Qwen3.8-Flash-Next-Uncensored-ROCmFP4-STRIX_LEAN-GGUF for frank-default-large on dankclaw. Search revealed the repo doesn't exist; only the base STRIX_LEAN tier is available, and it's text-only with no MTP.)
- Model provider config exists in TWO synchronized copies: ~/.pi/agent/models.json (source of truth) and ~/.omp/agent/models.yml (generated import; header comment states it is imported from the JSON). Any edit to providers, model ids, or display name labels must be applied to BOTH files in the same change or they silently drift. Validate after editing: jq -e '.providers|keys' models.json for the JSON and a YAML parse of the .yml. Label strings are NOT cached in ~/.omp/agent/models.db (model_cache table), so no cache flush is needed after label edits — new labels apply on the next config read.