# DF-4998 — `hw.ral.msi_disable` tunable is ineffective: `~ral_msi_disable` is truthy for BOTH tunable values, so MSI is always enabled

## Where

`sys/dev/netif/ral/if_ral_pci.c:254` —
`psc->sc_irq_type = pci_alloc_1intr(dev, ~ral_msi_disable, &rid, &irq_flags);`

## What

`pci_alloc_1intr(device_t dev, int msi_enable, int *rid, u_int *flags)`
(`sys/bus/pci/pci.c:4348`) treats its second argument as a **boolean**
enable flag: `if (msi_enable) { ... pci_alloc_msi(...) }` (pci.c:4358).
`ral_msi_disable` is a 0/1 `TUNABLE_INT("hw.ral.msi_disable", ...)` (line 64-65),
so the bitwise complement yields:

- `ral_msi_disable == 0` → `~0 == 0xFFFFFFFF` (truthy) → MSI enabled ✓ (intended)
- `ral_msi_disable == 1` → `~1 == 0xFFFFFFFE` (**still truthy**) → MSI enabled ✗

i.e. `hw.ral.msi_disable=1` does **not** disable MSI.  Every other
`pci_alloc_1intr()` caller in the tree passes a plain 0/1 enable variable
(`sys/dev/netif/bge/if_bge.c:2355`, `sys/dev/netif/re/if_re.c:758`,
`sys/dev/netif/em/if_em.c:2488`, `sys/dev/drm/drm_dragonfly.c:121`, …).
The intent is clearly `!ral_msi_disable` (the operator is a `~`/`!` typo;
the operator precedence trap does not exist here since `~` binds tighter
than the function call).  The only working escape hatch is the per-device
`dev.ral.N.msi.enable=0` env hint consumed inside `pci_alloc_1intr`
(pci.c:4357).

## Impact

Functional/safety-knob regression, no direct security impact: an operator
who sets the documented-by-convention `hw.ral.msi_disable=1` knob (e.g.
working around MSI delivery quirks on broken chipsets/APICs, or reducing
the interrupt surface) silently keeps MSI.  Info severity.

## Reproduce (reasoning; no runtime needed — pure boolean logic on a live kernel path)

```
kldload if_ral; hw.ral.msi_disable=1 in /boot/loader.conf
# observed: dev.ral.X.%pnpinfo interrupt is still MSI (msi.enable env unset)
```