Dispositivo USB no reconocido: la configuración de energía que mata tus puertos

febrero 14, 2026 • febrero 14, 2026 • Lectura: 26 min • Views: 0

¿Te fue útil?

Conectas un dispositivo USB y Windows muestra “Dispositivo no reconocido”, Linux lanza un críptico error de descriptor, o la unidad se monta y luego desaparece a mitad de copia como si acabara de recordar que dejó la estufa encendida. Cambias de puerto. Reinicias. Mirás el cable con recelo. Nada.

Aquí está la verdad incómoda: un gran porcentaje de incidentes “el USB está roto” son en realidad “la gestión de energía está haciendo exactamente lo que fue diseñada para hacer, solo que no lo que vos querías”. Tu sistema operativo, el firmware del portátil y tu hub USB están intentando ahorrar miliamperios. Tu dispositivo USB intenta no corromper datos. Solo uno puede ganar.

Por qué las configuraciones de energía rompen el USB (y por qué parece aleatorio)

USB se vendió como “plug and play”. En la realidad de producción es “conectar, negociar, enumerar, asignar energía, quizá descargar firmware, y luego funcionar”. Esa cadena es frágil. Cuando cualquier capa se vuelve “útil” con el ahorro de energía, no obtendrás un error limpio como “corriente de irrupción insuficiente en VBUS.” Obtendrás los clásicos: dispositivo desconocido, solicitud de descriptor fallida, un dispositivo que funciona los martes, o una unidad flash que solo se comporta cuando el portátil está conectado a la corriente.

La gestión de energía puede romper el USB de tres formas principales:

Lógica de suspensión del host: “USB selective suspend” en Windows, autosuspend en Linux, comportamientos power nap en macOS. El host decide cortar energía o poner el enlace en estados de bajo consumo.
Presupuestación y protección del hub: Un hub tiene un presupuesto de energía y reglas; los hubs baratos también tienen interpretaciones creativas de la física. Se dispara la protección por sobrecorriente, los puertos hagan brownout, o el hub miente sobre la corriente disponible.
Tolerancia del dispositivo: Algunos dispositivos tienen gran corriente de irrupción (discos giratorios), firmware inestable, o temporizaciones estrictas durante la enumeración. Una caída momentánea los reinicia; los reinicios repetidos parecen “no reconocido”.

Por qué se siente aleatorio: el desencadenante suele ser una transición de estado. La pantalla se apaga. La tapa se cierra. El sistema operativo decide que un dispositivo está inactivo. El paquete de la CPU cambia de C-states. Un hub se calienta. Un SSD USB empieza una escritura sostenida y el controlador consume más corriente. ¿Aleatorio? No tanto. Es una historia de sistemas: múltiples optimizadores actuando independientemente.

Dos reglas en las que confío:

Si el dispositivo falla durante la enumeración, sospecha primero de la energía y de la integridad de la señal (cable, puerto, hub, cableado del panel frontal, política de energía) antes de perseguir controladores.
Si falla bajo carga (copiar, transmisión de cámara, enlace NIC, interfaz de audio), sospecha del presupuesto de energía, peculiaridades de UASP y gestión de energía de enlace. Luego sospecha del firmware.

Broma #1: USB significa “Universal Serial Bus”, pero algunos días parece “Usually Something’s Broken” (usualmente algo está roto).

Guía rápida de diagnóstico

Este es el orden que uso cuando necesito respuestas rápido y no quiero “probar cosas” durante dos horas. El objetivo es aislar el cuello de botella: puerto, cable, hub, controlador/driver del host, política de energía, o firmware del dispositivo.

Primero: decidir si es por política de energía o hardware puro

Reproducir con alimentación AC (portátil) y con pantalla activa. Si solo falla con batería o tras inactividad, la política de energía es la principal sospechosa.
Mover de puerto: puerto trasero de la placa (escritorio) o un lateral distinto (portátil). Evita primero headers del panel frontal.
Quitar hubs/docks: ir directo host ↔ dispositivo. Si empieza a funcionar, el hub/dock es culpable hasta demostrar lo contrario.

Segundo: capturar evidencia (no resolver a ciegas)

Windows: Visor de eventos (Kernel-PnP), pestaña “Administración de energía” en el Administrador de dispositivos y configuraciones de powercfg.
Linux: dmesg -Tw mientras conectás el dispositivo; revisar autosuspend y la topología USB.
macOS: System Information → árbol USB; buscar “Accessory needs power” o desconexiones repetidas.

Tercero: aplicar la solución menos invasiva

Desactivar selective suspend/autosuspend para el dispositivo o controlador afectado antes de destruir configuraciones globales.
Usar un hub con alimentación para discos alimentados por bus y dispositivos de alto consumo; evitar hubs “solo carga” misteriosos.
Actualizar BIOS/UEFI y firmware/controladores del controlador USB (sí, todavía).

Cuarto: confirmar la solución bajo estrés

Ejecutar una copia sostenida, transmisión de cámara o prueba de E/S durante 10–20 minutos.
Poner la máquina en suspensión y despertarla. Desconectar/reconectar. Probar el modo de fallo que te importa.

Hechos e historia interesantes (breve, útil, ligeramente inquietante)

USB 1.0 se anunció en 1996, en parte para reemplazar un zoológico de puertos (serial, paralelo, PS/2). La parte “universal” fue política tanto como técnica.
La alimentación USB era originalmente conservadora: los puertos tempranos se diseñaron pensando en periféricos de bajo consumo como ratones y teclados, no en SSD que consumen corriente real durante escrituras.
El concepto de “unit load” (bloques de 100 mA en las especificaciones tempranas) moldeó cómo los dispositivos solicitan energía durante la enumeración. Algunos dispositivos aún se comportan como si fuera 1999.
USB 3.x añadió más estados de energía y complejidad en la gestión del enlace. Más velocidad, más casos límite, más “¿por qué se durmió?”.
UASP (USB Attached SCSI Protocol) mejoró el rendimiento para almacenamiento pero expuso bugs de firmware en algunos bridges. El transporte bulk-only era más lento pero tolerante.
Type-C hizo explícita la negociación de energía, pero también introdujo una nueva clase de fallos: cables incorrectos y adaptadores “casi conformes” que informan mal sus capacidades.
Las funciones BIOS “Sleep and charge” son básicamente lógica de enrutamiento de energía. En algunas placas interactúan mal con la suspend/resume del OS.
Los puertos del panel frontal suelen tener trazas físicamente más largas y conectores más baratos. La integridad de señal y la caída de voltaje empeoran.
La protección por sobrecorriente es real: algunos hosts apagarán un puerto si detectan una sobretensión. Para el OS, se parece a una desconexión misteriosa.

Qué significa realmente “Dispositivo USB no reconocido” a nivel eléctrico y de protocolo

Los dispositivos USB no “aparecen” por arte de magia. El host proporciona 5V en VBUS, detecta una resistencia pull-up en D+ o D- (USB 2.0) o negocia en las líneas SuperSpeed (USB 3.x), resetea el dispositivo y luego solicita descriptores: device, configuration, interface, endpoints. Si cualquiera de esos pasos caduca, obtendrás “dispositivo desconocido”, “device descriptor request failed” o un dispositivo que se reconecta sin parar.

Los problemas de energía pueden golpear en varios puntos:

Al conectar: la corriente de irrupción provoca una caída de tensión; el dispositivo sufre brownout antes de responder a la primera solicitud de descriptor.
Durante el reset: el host aplica un reset; el firmware del dispositivo reinicia; las temporizaciones se deslizan; la enumeración falla de forma intermitente.
Tras la configuración: el dispositivo está configurado y luego el host lo suspende agresivamente; el dispositivo no despierta correctamente; el OS lo marca como no responsivo.
Bajo carga: el chip bridge del SSD consume más corriente, o la caída en el cable aumenta; el dispositivo se reinicia; la corrupción del sistema de archivos se vuelve posible.

La integridad de la señal se hace pasar por problemas de energía y viceversa. Un cable malo puede causar reintentos que parecen timeouts; el host puede resetear el puerto, lo que parece un ciclo de energía. Del mismo modo, una pequeña caída de voltaje puede hacer que el PHY se comporte mal, lo que parece un cable defectuoso.

Mi sesgo: si un dispositivo “no es reconocido” y estás usando un hub/dock, asume que el hub miente sobre la energía o está disparando protecciones. Muchos hubs funcionan bien—hasta que agregas el único dispositivo de alto consumo que convierte tu setup en un simulador de brownout.

Broma #2: La especificación USB tiene miles de páginas; tu cable cuesta tres dólares. Adivina cuál arruinará tu tarde.

Tareas prácticas: comandos, salidas y qué decisión tomar

Abajo están las tareas reales que uso. Cada una incluye el comando, la salida típica, qué significa y la decisión que tomo a partir de ello. Úsalas como un libro de cocina, no como un texto filosófico.

Task 1 (Linux): Watch kernel events while plugging the device

cr0x@server:~$ sudo dmesg -Tw
[Mon Feb  3 12:18:41 2026] usb 2-1: new SuperSpeed USB device number 7 using xhci_hcd
[Mon Feb  3 12:18:41 2026] usb 2-1: device descriptor read/64, error -71
[Mon Feb  3 12:18:41 2026] usb 2-1: device descriptor read/64, error -71
[Mon Feb  3 12:18:42 2026] usb 2-1: new SuperSpeed USB device number 8 using xhci_hcd
[Mon Feb  3 12:18:42 2026] usb 2-1: device not accepting address 8, error -71
[Mon Feb  3 12:18:42 2026] usb 2-1: USB disconnect, device number 8

Qué significa: Error -71 suele ser fallo a nivel de protocolo (EPROTO). En la práctica: señal marginal, energía marginal, o un hub/cable que hace que SuperSpeed sea infeliz.

Decisión: Ir directo al host (sin hub), cambiar el cable, probar un puerto/modo USB 2.0 (a veces más estable), y revisar ahorro de energía/autosuspend después.

Task 2 (Linux): Show USB topology and negotiated speed

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 1: Dev 7, If 0, Class=Mass Storage, Driver=uas, 5000M

Qué significa: El dispositivo está en un controlador xHCI a 5 Gbps y usando UAS. Eso es bueno para rendimiento, pero algunos bridges se vuelven inestables con UAS.

Decisión: Si hay desconexiones bajo carga, considerar forzar BOT en lugar de UAS para ese dispositivo (quirk dirigido), o probar vía USB 2.0 para ver si el problema es SI/potencia en SuperSpeed.

Task 3 (Linux): Check autosuspend settings for a device

cr0x@server:~$ for f in /sys/bus/usb/devices/2-1/power/*; do echo "$f: $(cat $f)"; done
/sys/bus/usb/devices/2-1/power/autosuspend: 2
/sys/bus/usb/devices/2-1/power/autosuspend_delay_ms: 2000
/sys/bus/usb/devices/2-1/power/control: auto
/sys/bus/usb/devices/2-1/power/runtime_status: active

Qué significa: El dispositivo es elegible para runtime autosuspend (control: auto), con un retraso de 2 segundos. Eso puede estar bien para ratones. Puede ser fatal para algunos bridges de almacenamiento, interfaces de audio y adaptadores seriales.

Decisión: Si la falla ocurre tras inactividad, poner control a on para este dispositivo (arreglo dirigido) y volver a probar.

Task 4 (Linux): Disable autosuspend for one device (temporary)

cr0x@server:~$ echo on | sudo tee /sys/bus/usb/devices/2-1/power/control
on

Qué significa: Runtime PM está deshabilitado para ese dispositivo USB hasta el reinicio.

Decisión: Si la estabilidad mejora, hacerlo persistente con una regla udev (tarea posterior) en lugar de deshabilitar autosuspend globalmente.

Task 5 (Linux): Find USB errors and resets in logs

cr0x@server:~$ sudo journalctl -k -b | egrep -i 'usb|xhci|reset|over-current|descriptor' | tail -n 20
Feb 03 12:18:41 server kernel: usb 2-1: device descriptor read/64, error -71
Feb 03 12:18:42 server kernel: usb 2-1: device not accepting address 8, error -71
Feb 03 12:18:42 server kernel: usb 2-1: USB disconnect, device number 8
Feb 03 12:22:10 server kernel: usb 2-1: new SuperSpeed USB device number 9 using xhci_hcd
Feb 03 12:22:10 server kernel: usb 2-1: New USB device found, idVendor=174c, idProduct=55aa

Qué significa: Errores de descriptor repetidos seguidos de eventual éxito sugieren fuertemente condiciones intermitentes en la capa física: cable/hub/caída de energía.

Decisión: Tratarlo como un problema de camino de hardware primero. Si es un dock, cambiar dock. Si es panel frontal, mover al IO trasero. Si es un cable largo, acortarlo.

Task 6 (Linux): Check negotiated power for USB-C / PD (when available)

cr0x@server:~$ ls /sys/class/typec
port0

cr0x@server:~$ for f in /sys/class/typec/port0/* 2>/dev/null; do [ -f "$f" ] && echo "$f: $(cat "$f")"; done
/sys/class/typec/port0/data_role: host
/sys/class/typec/port0/power_role: source
/sys/class/typec/port0/port_type: dual

Qué significa: El puerto actúa como fuente de energía y host. En algunos sistemas también se puede leer corriente/voltaje negociados vía interfaces USB PD; la disponibilidad varía.

Decisión: Si el cambio de roles Type-C ocurre alrededor de las fallas, sospechar de la conformidad del cable/adaptador y considerar un cable e-marked conocido para modos de mayor corriente.

Task 7 (Linux): Force a USB storage device to use BOT instead of UAS (targeted quirk)

cr0x@server:~$ lsusb
Bus 002 Device 007: ID 174c:55aa ASMedia Technology Inc. ASM1051E SATA 6Gb/s bridge

cr0x@server:~$ echo 'options usb-storage quirks=174c:55aa:u' | sudo tee /etc/modprobe.d/usb-storage-quirks.conf
options usb-storage quirks=174c:55aa:u

cr0x@server:~$ sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.8.0-41-generic

Qué significa: Ese bridge USB evitará UAS (:u) y usará el transporte bulk-only más antiguo. A menudo menos performante, pero a veces mucho más estable.

Decisión: Si un dispositivo de almacenamiento se desconecta bajo carga y los logs muestran resets, este es un intercambio legítimo por estabilidad. Para backups, la estabilidad gana.

Task 8 (Linux): Create a persistent udev rule to disable autosuspend for one device

cr0x@server:~$ sudo tee /etc/udev/rules.d/99-usb-no-autosuspend.rules <<'EOF'
ACTION=="add", SUBSYSTEM=="usb", ATTR{idVendor}=="174c", ATTR{idProduct}=="55aa", TEST=="power/control", ATTR{power/control}="on"
EOF

cr0x@server:~$ sudo udevadm control --reload

cr0x@server:~$ sudo udevadm trigger

Qué significa: Cada vez que ese dispositivo específico sea añadido, se deshabilitará autosuspend para él.

Decisión: Usar esto para dispositivos con problemas conocidos. No deshabilites la gestión de energía en masa en laptops del parque si disfrutas quejas sobre batería y tickets por temperatura.

Task 9 (Windows): Find selective suspend configuration via powercfg

cr0x@server:~$ powercfg /q SCHEME_CURRENT SUB_USB USBSELECTIVE SUSPEND
Power Setting GUID: 2a737441-1930-4402-8d77-b2bebba308a3  (USB selective suspend setting)
  GUID Alias: USBSELECTIVE
  Minimum Possible Setting: 0x00000000
  Maximum Possible Setting: 0x00000001
  Possible Settings increment: 0x00000001
  Possible Settings units: 
Current AC Power Setting Index: 0x00000001
Current DC Power Setting Index: 0x00000001

Qué significa: La suspensión selectiva está activada tanto en AC como en batería (DC). Eso es un sospechoso principal cuando los dispositivos fallan tras inactividad o en períodos de baja actividad.

Decisión: Si el dispositivo es crítico (consola serial, instrumento de laboratorio, disco externo para backups), desactivar selective suspend al menos en AC, preferiblemente vía política para sistemas afectados.

Task 10 (Windows): Disable selective suspend (per power scheme)

cr0x@server:~$ powercfg /setacvalueindex SCHEME_CURRENT SUB_USB USBSELECTIVE 0

cr0x@server:~$ powercfg /setdcvalueindex SCHEME_CURRENT SUB_USB USBSELECTIVE 0

cr0x@server:~$ powercfg /setactive SCHEME_CURRENT

Qué significa: La suspensión selectiva está desactivada para el plan de energía actualmente activo.

Decisión: Volver a probar el modo de fallo exacto (inactividad → despertar, copia larga, acoplar/desacoplar). Si lo arregla, considerar aplicarlo mediante baseline corporativo—con cuidado—y documentar el intercambio.

Task 11 (Windows): Inspect power management on USB Root Hub devices

cr0x@server:~$ powercfg /devicequery wake_armed
HID Keyboard Device
HID-compliant mouse
Intel(R) USB 3.20 eXtensible Host Controller - 1.20 (Microsoft)

Qué significa: Dispositivos permitidos para despertar el sistema. Esto no muestra directamente “Permitir que el equipo apague este dispositivo”, pero te dice qué controladores están involucrados en el comportamiento de wake.

Decisión: Si el sistema despierta pero los dispositivos USB están muertos tras la suspensión, probablemente tengas un problema de restauración de estado del hub/controlador; desactivar selective suspend y actualizar drivers/chipset/BIOS suele ayudar.

Task 12 (Windows): Quickly list PnP problem devices

cr0x@server:~$ pnputil /enum-devices /problem
Microsoft PnP Utility

Instance ID: USB\VID_0000&PID_0002\5&2B6A2B1A&0&3
Device Description: Unknown USB Device (Device Descriptor Request Failed)
Class Name: USB
Class GUID: {36fc9e60-c465-11cf-8056-444553540000}
Problem Code: 43
Problem Status: 0xC00000E5

Qué significa: Código 43 con descriptor request failed suele estar aguas arriba de los drivers: la enumeración no se completó. Los drivers no pueden enlazarse a un dispositivo que nunca se presentó correctamente.

Decisión: Tratarlo como hardware/camino de energía: probar otro puerto, quitar hub, desactivar selective suspend y solo entonces reinstalar drivers del controlador.

Task 13 (Windows): Restart USB controllers without a full reboot (sometimes)

cr0x@server:~$ devcon restart "PCI\CC_0C0330*"
PCI\CC_0C0330: Restarted
1 device(s) restarted.

Qué significa: Reiniciaste dispositivos del controlador xHCI (se muestra el código de clase). Requiere devcon instalado y permisos apropiados.

Decisión: Útil para instrucciones de manos remotas cuando no podés reiniciar la máquina en medio de un incidente. Si el dispositivo vuelve tras reiniciar el controlador, sospecha de estados de energía raros del controlador o bugs en driver/firmware.

Task 14 (macOS): Show USB device tree and power hints

cr0x@server:~$ system_profiler SPUSBDataType
USB:

    USB 3.1 Bus:

      Host Controller Driver: AppleUSBXHCITR
      PCI Device ID: 0x15d9

        USB3.0 Hub:

          Product ID: 0x2812
          Vendor ID: 0x2109  (VIA Labs, Inc.)
          Current Available (mA): 900
          Current Required (mA): 896

Qué significa: El hub está casi en su límite de corriente. Ese número “Required” es lo que los dispositivos declaran, no necesariamente lo que consumen durante picos, pero es una pista enorme.

Decisión: Si estás al borde del límite, verás resets bajo carga. Usar un hub con alimentación o mover un dispositivo a otro bus.

Task 15 (Linux): Confirm whether the port is reporting over-current events

cr0x@server:~$ sudo dmesg | egrep -i 'over-current|overcurrent|ocp|port power'
[Mon Feb  3 12:30:14 2026] usb usb2-port1: over-current condition
[Mon Feb  3 12:30:14 2026] usb usb2-port1: disabled by hub (EMI?), re-enabling...

Qué significa: El host/hub detectó sobrecorriente y apagó el puerto. Puede ser un cortocircuito real, un dispositivo malo, o una irrupción transitoria que dispara la protección en un hub barato.

Decisión: Dejar de “intentar de nuevo.” Cambiar dispositivo y hub. Si es un disco, no sigas ciclando la energía: estás entrenándolo para corromper datos.

Task 16 (Linux): Stress a mounted USB drive and watch for resets

cr0x@server:~$ sudo dd if=/dev/zero of=/mnt/usb/testfile.bin bs=64M count=64 oflag=direct status=progress
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 9 s, 239 MB/s
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 18 s, 239 MB/s

Qué significa: Esto crea carga de escritura sostenida. Si el dispositivo se desconecta a mitad de la ejecución, verás errores y probablemente resets en dmesg.

Decisión: Si falla solo bajo ese tipo de carga, estás tratando con presupuesto de energía, caída de voltaje en el cable, problemas UAS, o una caja con inestabilidad térmica.

Tres micro-historias del mundo corporativo (anonimizadas, dolorosamente plausibles)

Micro-historia 1: El incidente causado por una suposición errónea

Un equipo desplegó una pequeña flota de mini PCs como “coleccionadores de borde” en sucursales. Cada caja tenía un módem LTE USB para conectividad de respaldo y un SSD USB para buffering local. En laboratorio las pruebas eran buenas: conectar todo, hacer una transferencia rápida, despachar.

En campo, las unidades funcionaban días y luego de repente perdían su módem. A veces el SSD se remontaba como solo lectura. El troubleshooting remoto fue un desastre porque las unidades eran sin cabeza; cuando el módem moría, la caja desaparecía de la red. La única pista de los pocos logs recuperados: desconexiones USB alrededor de la misma hora cada noche.

La suposición errónea fue simple: “Si funciona en laboratorio, funcionará en la tienda.” En laboratorio, los dispositivos descansaban en un banco con AC constante y sin suspensión. En las tiendas, las pantallas estaban configuradas para apagarse por la noche; los mini PCs entraban en estados de inactividad más profundos y Windows empezó a jugar a la suspensión selectiva con el módem y la carcasa de almacenamiento.

La solución fue aburrida y efectiva: desactivar selective suspend en AC y bloquear la gestión de energía de los root hubs USB específicos. Además movieron el SSD a una carcasa con alimentación. El postmortem no se trató de culpables; se trató de reconocer que “inactividad nocturna” es una condición de producción como cualquier otra.

Micro-historia 2: La optimización que salió mal

Un equipo de imágenes de estaciones de trabajo quiso máquinas más verdes y mayor duración de batería en laptops. Actualizaron planes de energía, activando suspensión selectiva USB agresiva y temporizadores de inactividad más cortos en todo. En papel y en algunas pruebas sintéticas de batería se veía genial.

Luego la planta de ingeniería empezó a reportar problemas “aleatorios”: docks USB-C que a veces aparecían sin Ethernet, interfaces de audio que hacían pops y se desconectaban durante reuniones, y carcasas NVMe externas que caían a mitad de un build dejando artefactos corruptos. La gente hizo lo que hace la gente: cambió cables, compró hubs diferentes y maldijo en silencio al equipo de TI.

La optimización falló porque trató a todos los dispositivos USB por igual. Un ratón tolera suspend/resume. Un dock que contiene un hub, controlador Ethernet y códec de audio es un pequeño sistema distribuido que necesita energía estable y una secuencia de resume limpia. Lo mismo aplica a un dispositivo de almacenamiento UASP haciendo escrituras sostenidas.

El rollback fue dirigido. Mantuvieron optimizaciones de batería para categorías de bajo riesgo (dispositivos HID) pero desactivaron selective suspend para estaciones de acoplamiento y bridges de almacenamiento identificados por VID/PID. También exigieron actualizaciones de firmware para un modelo popular de dock. La ganancia medible de batería se redujo, pero el volumen de incidentes colapsó. Ese es el tradeoff que aceptás cada vez.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

Un grupo de investigación tenía PCs de instrumentación conectados al equipo de laboratorio mediante adaptadores seriales USB. La configuración corría 24/7 coleccionando datos. Nada sofisticado—solo confiable.

Cuando renovaron hardware, un ingeniero con buenas intenciones sugirió consolidar puertos a través de un hub multiport montado bajo cada banco. Mejoró la gestión de cables. También empeoró la tasa de fallos. Los dispositivos desaparecían tras unas horas; a veces volvían, otras veces había que reiniciar el experimento.

Una persona había estado en silencio practicando una regla “aburrida” durante años: mantener inventario de adaptadores y hubs con buena reputación, y etiquetar qué dispositivos requieren configuraciones “sin suspensión”. También tenían una checklist estándar: prueba directo a puerto, prueba con hub con alimentación, luego aplicar reglas udev (Linux) o cambios en el plan de energía (Windows) solo si era necesario.

Esa disciplina los salvó. Descubrieron que el nuevo hub bajo el banco era alimentado por bus mediante un adaptador USB-C marginal; funcionaba en reposo, pero había brownouts cuando múltiples instrumentos transmitían simultáneamente. Lo reemplazaron por un hub industrial con alimentación y aplicaron una regla no-autosuspend por dispositivo. Los experimentos volvieron a ser aburridos. En operaciones, aburrido es el objetivo.

Errores comunes: síntomas → causa raíz → solución

Esta sección es deliberadamente específica. Si podés mapear tu síntoma a uno de estos, podés dejar de hacer danzas interpretativas con el Administrador de dispositivos.

1) “Unknown USB Device (Device Descriptor Request Failed)” en Windows

Síntoma: Código 43, descriptor request failed, el dispositivo nunca aparece correctamente.
Causa raíz: La enumeración falló—a menudo caída de potencia en cable/hub/puerto, a veces un dispositivo atascado en mal estado de firmware.
Solución: Quitar hub/dock, usar un cable corto conocido, probar otro puerto; desactivar selective suspend; ciclar la energía del dispositivo completamente (desconectar la alimentación, esperar 10 segundos). Luego actualizar drivers de chipset/USB y BIOS.

2) El dispositivo funciona con AC pero falla con batería

Síntoma: Estable cuando está enchufado; inestable cuando es móvil.
Causa raíz: Plan de energía DC agresivo, selective suspend, estados de plataforma más profundos, o restricciones del rol USB-C PD.
Solución: Desactivar selective suspend en DC para ese plan; considerar “Mejor rendimiento” para trabajo intensivo en USB; usar un hub/carcasa con alimentación para almacenamiento.

3) Disco externo se desconecta durante una copia grande

Síntoma: Empieza bien; cae a mitad de la copia; el sistema de archivos puede quejarse al reconectar.
Causa raíz: Presupuesto de energía o picos de irrupción; bugs de firmware UAS; throttling térmico que provoca resets.
Solución: Probar hub con alimentación o otra carcasa; probar desactivar UAS (quirk en Linux) o usar otro driver; acortar el cable; evitar panel frontal.

4) Dock pierde Ethernet/audio después de suspensión

Síntoma: Tras el resume, faltan algunas funciones del dock hasta que se vuelve a enchufar.
Causa raíz: Secuencia de resume del hub + desajuste de gestión de energía; bug de firmware del dock; selective suspend cortando un dispositivo hijo.
Solución: Actualizar firmware del dock; desactivar selective suspend; desactivar “Permitir que el equipo apague este dispositivo” para hubs/controladores USB si es necesario; probar otro puerto/bus.

5) Linux: mensajes repetidos “reset SuperSpeed USB device”

Síntoma: dmesg muestra resets y bucles de desconexión/reconexión.
Causa raíz: Problemas de integridad de señal en las líneas SuperSpeed o potencia marginal.
Solución: Cambiar cable; evitar cables pasivos largos; evitar hub; probar modo USB 2.0 (si es aceptable); usar hub con alimentación para dispositivos de alto consumo.

6) Los puertos del panel frontal son poco fiables, los traseros funcionan bien

Síntoma: Mismo dispositivo + mismo cable funciona en el IO trasero, falla en el frontal.
Causa raíz: Caída de voltaje e integridad de señal peor por el cableado del chasis; conectores sueltos; ambiente ruidoso.
Solución: Usar puertos traseros para almacenamiento/docks; asentar el header del panel frontal; si debes usar frontal, usar un hub con alimentación montado cerca del IO trasero.

7) “Accessory needs power” en macOS

Síntoma: El dispositivo se detecta pero se rechaza por energía.
Causa raíz: Dispositivo alimentado por bus superando la corriente disponible, o un hub que anuncia corriente limitada.
Solución: Usar un hub con alimentación; reducir la cantidad de dispositivos alimentados por bus en ese bus; evitar adaptadores dudosos.

Listas de verificación / plan paso a paso

Checklist A: La comprobación física “no pierdas tiempo”

Ir directo host ↔ dispositivo (sin hub, sin dock).
Usar un cable corto conocido y de buena calidad (especialmente para USB 3.x).
Cambiar a otro puerto del host (IO trasero en desktop).
Si es almacenamiento: probar una carcasa con alimentación o un hub con alimentación.
Si es Type-C: probar otro cable/adaptador; preferir cables e-marked para mayor corriente.

Checklist B: Paso a paso en Windows (primero energía, luego drivers)

Comprobar estado de selective suspend con powercfg /q.
Desactivar selective suspend en AC (y DC si es necesario) para el plan actual.
Reproducir: dejar inactivo 5–10 minutos, luego usar el dispositivo; también probar suspensión/despertar.
Si sigue fallando: desinstalar/reinstalar el dispositivo en el Administrador de dispositivos (especialmente “Unknown USB Device”), luego reiniciar.
Actualizar drivers de chipset/controlador USB y BIOS/UEFI; los docking stations suelen requerir firmware.
Si el problema está limitado a un hub: reemplazar por un hub con alimentación y fuente confiable.

Checklist C: Paso a paso en Linux (observar, luego fijar la política)

Ejecutar dmesg -Tw mientras conectás.
Mapear topología con lsusb -t.
Comprobar estado autosuspend en /sys/bus/usb/devices/.../power/.
Deshabilitar autosuspend temporalmente para ese dispositivo (control=on), volver a probar.
Si es estable: añadir una regla udev para persistir.
Si se desconecta bajo carga: considerar desactivar UAS para el VID:PID específico y volver a probar.

Checklist D: Reglas de sentido para ingenieros de almacenamiento (porque los datos importan)

Si un disco USB se desconecta a mitad de escritura, asumir posible corrupción. Ejecutar comprobaciones de sistema de archivos antes de confiar en él de nuevo.
Preferir carcasas con alimentación para HDDs de 2.5″ y muchas bridges NVMe.
No usar “hubs misteriosos” para backups. Tu dispositivo de backup no debería compartir un bus con cinco juguetes alimentados por bus.
Si vas a usar USB para rutas de datos críticas, probar bajo carga sostenida y a través de ciclos de suspensión/resume.

Preguntas frecuentes

1) ¿La “suspensión selectiva USB” es realmente mala?

No. Es una característica razonable para muchos dispositivos. Se vuelve mala cuando se aplica de forma uniforme a dispositivos que no reanudan limpiamente o que necesitan energía estable (docks, bridges de almacenamiento, interfaces de audio).

2) ¿Debo desactivar la suspensión selectiva globalmente?

Solo como diagnóstico o cuando hayas aceptado el intercambio. Preferí targeting por dispositivo o por clase cuando sea posible. Los cambios globales arreglan un ticket y crean tres más.

3) ¿Por qué cambiar de un puerto USB 3 a uno USB 2 “lo arregla”?

USB 2.0 usa señalización diferente y es más tolerante con cables y conectores marginales. Es más lento, pero a menudo más indulgente cuando la integridad de la señal es el problema real.

4) Mi SSD externo es rápido pero se desconecta durante copias grandes. ¿Cuál es la mejor solución?

Empezá por energía y cable: cable corto y de alta calidad, puerto directo, luego hub/carcasa con alimentación. Si es Linux y usa UAS, probar desactivar UAS para ese dispositivo. Si la carcasa calienta mucho, considerar comportamiento térmico también.

5) ¿Un hub USB puede causar “dispositivo no reconocido” aunque sea “compatible USB 3.0”?

Sí. La conformidad no garantiza buena entrega de energía bajo carga o buen comportamiento con cada dispositivo. Hubs con alimentación y fuentes reputadas reducen una clase entera de fallos.

6) ¿Por qué fallan más los puertos frontales?

Trazas más largas, más conectores, a veces entrega de energía más débil y mayor desgaste mecánico. Los puertos traseros de la placa suelen ser la ruta eléctrica más limpia.

7) Tras la suspensión, mis dispositivos USB están muertos hasta que los vuelvo a enchufar. ¿Es energía o drivers?

Con frecuencia es restauración de estado de energía: el controlador/hub reanuda en un estado extraño. Las soluciones suelen incluir desactivar selective suspend, actualizar BIOS/chipset/firmware del dock, o reiniciar el controlador.

8) En Linux, ¿qué significa “device descriptor read/64, error -71”?

Es un error de protocolo de bajo nivel durante la enumeración. En la práctica apunta a condiciones físicas marginales (cable/hub/energía) o un dispositivo que se reinicia en medio del handshake.

9) ¿Un hub con alimentación siempre lo soluciona?

No, pero resuelve suficientes casos como para probarlo temprano con dispositivos de alto consumo. Si no ayuda, tu problema puede ser integridad de señal, firmware o un problema del controlador.

10) ¿Cuál es la configuración más fiable para almacenamiento USB que me importa?

Cable corto conocido y de buena calidad, puerto trasero directo o un hub con alimentación de alta calidad, plan de energía estable (sin suspensión agresiva) y una carcasa/bridge conocido por comportarse bajo carga sostenida.

Conclusión: siguientes pasos que realmente perduran

Cuando USB falla, la tentación es tratarlo como magia: volver a enchufar hasta que funcione, y luego fingir que nada pasó. Así terminás con fallos intermitentes y copias corruptas.

Hacé esto en su lugar:

Aislar el camino: puerto directo, cable corto, sin hub. Confirmar si la falla es “comportamiento hub/dock” o “comportamiento dispositivo/host”.
Interrogar la política de energía: suspensión selectiva/autosuspend es sospechosa de primer nivel cuando las fallas se correlacionan con inactividad o batería.
Arreglar de manera puntual: no-autosuspend por dispositivo, hub con alimentación para alto consumo, quirks UAS solo para dispositivos que lo requieren.
Probar y demostrar: prueba de carga sostenida más suspensión/resume. Si no probás el modo de fallo, no lo arreglaste—sólo tuviste suerte.

Una idea operacional que vale la pena mantener (paráfrasis): Werner Vogels ha enfatizado que construís confiabilidad diseñando para el fallo y recuperando rápido, no suponiendo que los componentes se comporten perfectamente.