Scribbles for my memory

My always-on home server, an old Dell Latitude with an Intel 82579LM NIC, went silent for 22 minutes. The machine itself was fine. A reboot brought the network back, but a reboot doesn't tell you why it went down.

The kernel log from the previous boot does:

sudo journalctl -k -b -1 | grep -c "Detected Hardware Unit Hang"
sudo journalctl -k -b -1 | grep "Hardware Unit Hang" | sed -n '1p;$p'

There were 678 hits, two seconds apart, from the moment it dropped until I rebooted. The TX descriptor ring was stuck (TDH never moved), and the driver never managed to reset the card. The NIC simply stopped transmitting.

This is a long-known e1000e erratum on 82579/82574-era Intel NICs. The usual trigger is TCP segmentation offload. The standard mitigation is to stop the card doing TSO/GSO and let the CPU do it, which costs almost nothing at home-network speeds:

sudo apt install ethtool
sudo ethtool -K eno1 tso off gso off
sudo ethtool -k eno1 | grep -E '^(tcp-segmentation|generic-segmentation)-offload'

ethtool -K doesn't survive a reboot. If NetworkManager owns the interface, you don't need a udev rule or a systemd unit: NM can apply ethtool features itself on every activation:

sudo nmcli con modify "Wired connection 1" ethtool.feature-tso off ethtool.feature-gso off
nmcli -g ethtool.feature-tso,ethtool.feature-gso con show "Wired connection 1"

Applying it live only blips the link for a second, so it's safe even when you're working over that same connection, or from a VM running on the box.

If the hang ever comes back with offload off, the next suspects are Energy Efficient Ethernet and PCIe ASPM (pcie_aspm=off on the kernel command line).

Bash applies redirections from left to right. If opening an input file fails before stderr is redirected, Bash writes the open error to the original stderr.

read -r value < "$file" 2>/dev/null   # Input open happens first
read -r value 2>/dev/null < "$file"   # Stderr is redirected first

When a file may be missing and you want to hide Bash's open error, place 2>/dev/null before the input redirection. This changes where the diagnostic goes, not the command's exit status. It is not a universal “all output redirects first” rule; redirections run left to right, so their order determines which destination is active when each one is applied.

Diffwalk's own agent skill is a one-shot author: the agent reads the whole change, writes an ordered explanation for every block, and hands you a finished walkthrough. That's great for documenting your own PR, but when you're reviewing a colleague's PR it anchors you to the agent's verdict before you've formed your own.

pair-review turns the same CLI into a dialogue. The agent slices the diff into review units (a signature change travels with its call sites), opens the diff in the browser, then takes one unit per round: says what it does, raises its own suspicions, and stops for your take. The agreed text — not the debate — goes into the walk's explanations.yaml, so an interrupted review resumes at the next pending unit instead of starting over. A GitHub comment is only posted after you confirm its exact draft.

The newest bit: when the agent talks about a unit, the browser scrolls there and highlights the exact lines. It works through the Chrome DevTools Protocol. split-view launches a dedicated Chrome/Edge (separate profile, CDP port 9333) in the top half of the screen with the terminal below. Then each round the agent runs something like:

node scripts/focus.mjs change-003 --at src/Orders/OrderService.cs:42-50 --at src/Orders/OrderService.cs:40:old

focus.mjs attaches to that browser with Playwright's connectOverCDP, expands the file, and marks rows in the diff's shadow DOM. This works in split or unified layout, on the new side or (:old) the deleted side. The first range is scrolled to the centre of the screen. Your terminal keeps keyboard focus throughout, unlike the old approach of typing an anchor URL into the omnibox.

It needs a patched Diffwalk build: shukebeta/diffwalk branch local-both adds a Wrap toggle for long lines and shows each block's change-0NN id on the page, so "change-012" is something you can actually see. Build it with the bun version CI pins. A different bun silently tree-shakes the report's web components, and every diff renders unstyled:

git clone -b local-both https://github.com/shukebeta/diffwalk.git
cd diffwalk
npx --yes [email protected] install
npx --yes [email protected] run build
alias diffwalk="node $PWD/dist/diffwalk.js"   # add to your shell profile

Then install the skill and its one dependency (playwright-core, no browser download — it drives the Chrome you already have):

npx skills add shuke-personal/pair-review-skill --skill pair-review -g
cd ~/.claude/skills/pair-review/scripts && npm i

Start a new agent session and say "pair review this PR". Split view plus highlighting is scripted for Windows and Linux/X11. On macOS, start the CDP browser by hand (the command is in SKILL.md §3) and focus.mjs works unchanged.

If you keep a personal and a work GitHub account on the same machine, you have probably hit this: gh auth login both accounts, run gh auth setup-git, and half your repos start returning Repository not found. That's because gh auth git-credential always answers with the keyring's active account. It never looks at which repo git is asking about.

The fix is to put a small wrapper in front of the real gh. The wrapper picks a token by repo owner, and git uses the same wrapper as its credential helper. Now both gh and plain git go through one place that knows about your accounts.

The heart of the wrapper is a few lines of bash (save as ~/bin/gh-route, keep the real gh on PATH):

#!/usr/bin/env bash
# Pick a token by owner, then run the real gh with it.
owner_from() { sed -E 's#^(https://github.com/|[email protected]:)##; s#/.*##'; }

if [[ "$1 $2" == "auth git-credential" ]]; then
    req="$(cat)"                                   # git's request, on stdin
    owner="$(sed -n 's#^path=\([^/]*\)/.*#\1#p' <<< "$req")"
fi
[[ -n "$owner" ]] || owner="$(git remote get-url origin 2>/dev/null | owner_from)"

case "${owner,,}" in
    my-work-org|my-work-user) export GH_TOKEN="$GH_TOKEN_WORK" ;;
    ?*)                       export GH_TOKEN="$GH_TOKEN_PERSONAL" ;;
esac

if [[ -n "$req" ]]; then gh "$@" <<< "$req"; else gh "$@"; fi

Then wire git to it, and move everything to HTTPS:

# ~/.gitconfig
[credential "https://github.com"]
    helper =
    helper = !bash ~/bin/gh-route auth git-credential
    useHttpPath = true
[url "https://github.com/"]
    insteadOf = [email protected]:
    insteadOf = ssh://[email protected]/

useHttpPath is what makes this reliable. Without it git only tells the helper host=github.com, so the wrapper has to guess from the current directory, and git ls-remote <url> run outside a repo gets the wrong account. With it git sends path=<owner>/<repo>.git, so the owner is right there in the request. (git clone happens to work either way: git writes origin into the new repo and exports GIT_DIR before it asks for credentials.)

The insteadOf lines rewrite existing [email protected]: remotes on the fly, so you don't have to edit a single .git/config. HTTPS also gets through networks that reset SSH, and it's the only transport GitHub App installation tokens work with.

One trap: never run gh auth setup-git again. It appends its own [credential "https://github.com"] block after your include, and its empty helper = line silently wipes out the wrapper.

On Windows (Git Bash), call the wrapper through bash as shown instead of an .exe shim. Git spawning a shim from its own sh can die with a cygheap read copy failed fork error.

When you run a fleet of coding agents, most of their "I'm stuck, human please" pages are not really for you. A runner is wedged, a lock is stale, a relay died, or the question is one you already answered in a runbook or on an old PR. We built an oncall agent that reads every escalation first, acts as you, and only pages you with what truly needs you. The whole thing is small, and it runs on stock my-ai-team (mat) features. It took two days to go from idea to running system.

The flow:

agent ── notify-user --action ──► Telegram (you, unchanged)
   └── ssh oncall-host oncall-inbox        (same message on stdin)
             │
        oncall agent: triage (env / decision / noise), investigate over ssh
             ├── ssh <agent-host> send-relay %<pane> reply.md   → answer the stuck agent
             ├── incident record, committed to a repo
             ├── notify-user                                    → FYI to you
             └── notify-user --action + a GitHub issue          → only when you must decide

1. Forward action messages. On every agent host, point mat at the oncall host (any ssh alias that logs in without a prompt):

git config --global mat.devopsHost oncall-host