DF-5603 baseline run — 2026-10-08 12:4x UTC

Command (host):
    $ cd dfbsd-qemu && timeout 90 ./vm.sh run_root \
        'echo BASELINE-RUN-START; kldload /tmp/df5603/df5603.ko; echo "kldload rc=$?"'

Observed output:
    BASELINE-RUN-START
    (no further output; ssh hung -> timeout exit 124)

Serial console (dfbsd-qemu/vm.sh log) immediately after:
    DF-5603: calling mmc_switch(timeout=0) as mmc.c does for a card with EXT_CSD[248]=0 ...
    panic: mmc_switch: no timeout
    cpuid = 1
    mmc_switch() at mmc_switch+0x178
    df5603_modevent() at df5603_modevent+0x93
    module_register_init() ...
    linker_load_file.part.3() ...
    linker_load_module() ...
    Debugger("panic")
    db>

Aftermath: vm.sh status => down.  Guest required vm.sh reset with-src.

Interpretation:
  * The stock kernel (X86_64_GENERIC with options INVARIANTS, see
    sys/config/X86_64_GENERIC:56) compiles the KASSERT at
    sys/bus/mmc/mmc_subr.c:158 as a live panic.
  * mmc_switch() entered with timeout==0 -- the exact value mmc.c:1663-1665
    derives from a card-controlled EXT_CSD byte 248 (GEN_CMD6_TIME) of 0 for
    cards reporting spec_vers >= 6 -- panics the kernel before any bus I/O.
  * Reachability in production: any crafted or mis-programmed MMC-compliant
    card (CSD spec_vers >= 6, EXT_CSD[248] == 0) hits this at enumeration
    (mmc.c:1672 erase-group switch, mmc.c:709 bus-width switch,
    mmc.c:828/:835-836 timing switch), i.e. at boot or on insertion.