KVM Input Switch Sleep Issues#

What Was Established#

Switching inputs on a KVM switch can trigger connected PCs to enter sleep mode and fail to wake up. This is typically caused by EDID handshake interruptions or power management settings reacting to display signal loss when the KVM switches away from a connected machine.

Key Decisions & Troubleshooting Steps#

• Hardware Model: Inland Dual 4K Display KVM Switch/Dock.
• EDID Emulation: The most critical fix. Ensure the KVM is configured for EDID emulation (often via dip switches or firmware settings) to maintain a persistent display handshake and prevent the host OS from detecting a disconnected monitor.
• Firmware Updates: Check manufacturer resources (e.g., Micro Center for Inland) for firmware updates to improve display handshake compatibility.
• Windows Power Management:
  • Set ‘Screen’ and ‘Sleep’ to ‘Never’ in Power & Sleep settings.
  • Adjust NVIDIA Control Panel power management to ‘Prefer Maximum Performance’.
  • Use Group Policy (gpedit.msc) to disable video/display power saving templates.
• Linux Mint Power Management:
  • Configure /etc/X11/xorg.conf to disable blank/standby/suspend/off times (ServerFlags section).
  • Add xset s off and xset -dpms to startup applications.
  • Modify GRUB cmdline (/etc/default/grub) with video=vesafb:off video=eefb:off drm_kms_helper.edid_firmware=edid/1920x1080.bin.
• Hardware Checks: Use high-quality/shorter HDMI/DisplayPort cables, ensure direct monitor connections to KVM outputs, and utilize the KVM’s built-in USB hub for peripherals.
• Workaround: Manual wake via brief power button press or keyboard input if automatic wake fails due to lost display signal.

Historical Notes#

• Conversation date: 2025-11-29.
• Specific to Inland Dual 4K KVM dock behavior.
• EDID emulation is consistently the primary resolution for this class of KVM-induced sleep issues.

Open Questions#

• Does the specific Inland dock model have a known firmware revision that fully resolves this behavior?
• Are external EDID emulators required if built-in emulation remains insufficient?

Related Pages#

• wiki/hardware/monitor-standards.md
• wiki/infrastructure/gpu-passthrough-lxc.md

Sources#

• ingested/chats/122-KVM Input Switch Causes PC Sleep Issue.md

OPNsense Interface Reassignment & NIC Troubleshooting#

What Was Established#

Procedures for reassigning WAN/LAN interfaces via the OPNsense console following a system upgrade, and troubleshooting connectivity loss after a physical NIC replacement.

Key Decisions#

• Console-Based Reassignment: Use the OPNsense console menu (1. Assign Interfaces) to map physical ports to WAN/LAN roles.
• Network-Only Reset: If configuration is lost, use 2. Reset to factory defaults and select “Reset only the network configuration” to preserve other settings.
• Manual Config Edit: Fallback to vi /conf/config.xml to manually adjust <interfaces> tags (<wan>, <lan>) if the menu fails.
• NIC Troubleshooting Workflow: Verify driver recognition (vmstat -i), link status (ifconfig), and system logs (dmesg). Check NAT/Outbound and LAN firewall rules. Isolate hardware issues by reverting to the original NIC.

Current Configuration#

• Gateway: UCG Express “Olorín” (OPNsense) at 192.168.1.1.
• VLANs: Gandalf (192.168.1.x), Mithrandir (192.168.2.x), Tharkûn (192.168.3.x), Rivendell (192.168.4.x).
• Switch: Netgear MS308E (trunk/access VLANs managed via OPNsense).

Historical Notes#

• Procedures documented for OPNsense upgrades where interface assignments reset.
• Troubleshooting steps refined for scenarios involving physical NIC swaps (e.g., 2.5GbE to 1GbE) causing interface loss.
• Note: Driver support (Intel igb/em, Realtek) and firmware updates may be required for newer NICs.

Open Questions#

• Specific driver requirements for the current UCG Express “Olorín” gateway NICs.
• Automation of interface reassignment to prevent manual console steps during future upgrades.

Related Pages#

• OPNsense DHCP Configuration
• VLAN Configuration: OPNsense & Netgear MS308E
• Troubleshooting Network Interface Changes
• Network Infrastructure & VLANs

Sources#

• ingested/chats/034-Reassign WAN and LAN on OPNsense Post-Upgrade.md
• Historical DeepSeek conversation on OPNsense console interface reassignment and NIC troubleshooting.

AI Infrastructure Overview#

What Was Established#

The homelab is transitioning into a multi-node agentic architecture, utilizing a mix of existing laptops, desktops, and a future Mac Studio to handle different tiers of LLM workloads (Batch vs. Interactive).

Key Decisions#

Nodes are specialized by their hardware capabilities (VRAM and CPU/RAM) to optimize for cost and performance:

• Inference Node (Batch/Heavy + Embeddings): HP Pavilion 15t-e300 — hostname nk-celebrimbor, IP 192.168.2.192. Intel i7, 32GB RAM, NVIDIA MX550 (2GB VRAM, CUDA disabled). Runs gemma4:e4b for monitoring pipeline synthesis (~15-18 t/s, CPU-only) and nomic-embed-text for wiki semantic embeddings (768-dim, via Ollama on port 11434).
• Orchestrator Node: Thinkpad T480. Intel i5/i7 8th Gen, 32GB RAM. Running headless Ubuntu. Hosts n8n and lightweight models (Gemma 4 E4B) for routing and decision-making.
• Interactive Node (Potential): ROG Zephyrus (GU501). Intel i7, NVIDIA GTX 1080 Max-Q (8GB VRAM). Ideal for 7B/8B models requiring high tokens-per-second for real-time chat.
• Primary Reasoning Node (Deployed 2026-04-24): Mac Studio M1 Max, 64GB Unified Memory — hostname Legolas, IP 192.168.1.45. Handles all wiki pipeline LLM calls: gemma4:e2b (text cleaning), qwen3.6:35b-a3b-coding-nvfp4 (JSON crystallization), minicpm-v:8b (PDF OCR/vision). Fast interactive inference — 31B models at ~25+ t/s vs Pavilion’s ~15 t/s CPU-only. See Mac Studio.
• Parallelism Nodes: Various i5 8th Gen desktops. 32GB RAM, no GPU. Used for distributed pipeline stages or additional lightweight model instances.

Current Configuration#

• Legolas (Mac Studio): Ollama at 192.168.1.45:11434. Running gemma4:e2b, qwen3.6:35b-a3b-coding-nvfp4, minicpm-v:8b for wiki pipeline. Deployed 2026-04-24.
• nk-celebrimbor (Pavilion): headless Ubuntu, Ollama CPU-only (CUDA disabled — MX550 2GB VRAM too small). Running gemma4:e4b at ~15-18 t/s for hourly monitoring pipeline; nomic-embed-text for wiki embeddings.
• T480: planned orchestrator role not yet active.

Related Pages#

Ollama Configuration, Open WebUI Deployment, Mac Studio, Pavilion (AI PC) Configuration

Mac Studio#

What Was Established#

Mac Studio M1 Max 64GB purchased 2026-04-17 for $2,299 (used/refurbished market). Deployed 2026-04-24 as the primary AI inference node for the homelab, replacing the Pavilion as the fast interactive reasoning machine.

Hardware#

Why This Hardware#

64GB unified memory is the key spec for LLM inference on Apple Silicon. Memory bandwidth determines tokens/second — the M1 Max at ~400 GB/s delivers ~25+ t/s for 27-31B models vs the Pavilion’s ~15 t/s CPU-only for E4B. At the time of purchase, 64GB Mac Studio/Mac Mini new from Apple was backordered to late June. The used M1 Max at $2,299 was judged a reasonable buy given scarcity.

Troubleshooting Network Interface Changes#

What Was Established#

When replacing a physical Network Interface Card (NIC)—for example, swapping a 2.5GbE card for a 1GbE card—the system will lose connectivity if the software configuration still references the old interface name.

Key Decisions#

Connectivity loss after a hardware swap is usually due to a mismatch in the bridge-ports setting within the network configuration. The new NIC will likely have a different kernel interface name (e.g., changing from enp0s1 to enp0s2).