¿Por qué el USB no funciona en Linux cuando funciona en UEFI / BIOS?

31

Para el fondo, acabo de construir una nueva máquina con hardware moderno que incluye:

  • AMD FX-8350
  • Placa base Gigabyte GA-990FXA-UD3
  • 16 GB de RAM
  • NVidia GTX 650 Ti
  • Kingston SSD

Teniendo en cuenta eso, intenté instalar varias versiones de Linux en el SSD y casi siempre tuve fallas. Intenté instalar Arch, Debian estable, Debian sid y Ubuntu 12.10 desde una memoria USB, pero mientras el BIOS vio la unidad USB y comenzó a arrancar desde ella, tan pronto como el sistema operativo intentó enumerar los dispositivos USB, perdí toda la funcionalidad USB (incluido el dispositivo de arranque).

Finalmente grabé un DVD e instalé Ubuntu 12.10 en el SSD. Cabe señalar que mi teclado USB (y mouse) funcionan bien mientras estoy en el American Megatrends UEFI / BIOS. Incluso cuando estoy en los menús previos a la instalación en el DVD Live Ubuntu, el teclado funciona bien.

Tan pronto como se inicia Linux (ya sea Live DVD o desde el SSD) pierdo toda la funcionalidad USB y solo puedo navegar el sistema operativo usando un teclado PS / 2.

Lo que veo en el dmesg / syslog son algunas líneas sobre " failed to load microcode amd_ucode/microcode_amd_fam15h.bin" y puedo ver que los dispositivos USB no se inicializan.

Si lo hago lsusb, puedo ver todos los controladores de host USB pero ninguno de los dispositivos. Hacer una lspcime muestra todo el hardware que esperaba. Y haciendo un lsmodno veo ningún módulo usb cargado ( usb_ehcipor ejemplo).

Intenté pasar noapica la cadena de arranque del núcleo y no tuvo ningún efecto sobre este problema.

La placa base admite USB 3.0, pero todos los dispositivos que he conectado a los puertos USB 2.0 normales.

Estoy bastante desconcertado por lo que podría estar matando / evitando que el USB (y mi tarjeta de red integrada) funcionen en Linux . No parece haber ningún problema con ninguno de estos dispositivos que funcionan en BIOS y no tengo una instalación de Windows disponible para probar y ver si funciona.

Ya he usado RMA en la placa base una vez, pero la segunda tiene exactamente el mismo comportamiento, así que creo que puedo descartar con seguridad una falla de hardware (dado que el comportamiento es idéntico, no creo que sea extraño que obtenga dos placas idénticamente defectuosas son mayores que las probabilidades de que esto sea un problema de Linux).

¿Qué más puedo intentar para que funcione USB (e idealmente mi red, pero nos quedaremos con USB por ahora)?

Editar # 1:

Como no tengo redes, solo puedo relacionar partes interesantes desde dmesgaquí.

De interés en dmesglo que puedo ver que tengo 11 controladores de host USB (OHCI, EHCI, y xHCI). Detecta mis dispositivos USB y luego falla inmediatamente de la siguiente manera:

usb 3-1: new high-speed USB device number 2 using ehci_hcd
usb 3-1: device descriptor read/64, error -32

Eso se repite varias veces incrementando el número y probando otros controladores de host USB hasta que vuelve a los controladores OHCI que también fallan pero tienen un mensaje adicional:

usb 8-1: device not accepting address 4, error -32

Creo que mis problemas de red tienen que ver con el hecho de que no tengo IPv6 habilitado en mi enrutador y eso parece ser un problema

eth1: no IPv6 routers present

Editar # 2:

lspci -vvvmuestra que mis adaptadores de red (tanto integrados como de expansión) son Realtek Semiconductor (no es de extrañar); RTL8111 / 8168B y RTL8169 / 8110 respectivamente. Mis controladores USB son Etron Technology EJ168 (xHCI) y AMD nee ATI SB7x0 / SB8x0 / SB9x0 (EHCI & OHCI)

Ahora con Debian sibilante modprobeespectáculos usb_common, usbcore, xhci_hcd, ehci_hcd, y ohci_hcdtodos cargados y funcionando.

BrionS
fuente
La falla al cargar el microcódigo parece peculiar. Estoy pensando en la placa base que aún no es compatible o que falta el paquete de microcódigo.
TNW
Parece que ese problema puede desaparecer ( butterflyofdream.wordpress.com/2012/09/10/… ) ya que esta CPU ha estado fuera por un tiempo y hay paquetes que actualizan el microcódigo. Sin embargo, me pregunto cómo eso evitaría que USB funcione en Linux cuando USB funciona en BIOS sin problemas. Además, hasta que pueda descubrir por qué el dispositivo de red no se conecta tampoco podré aplicar el parche (aunque una tarjeta adicional puede permitirme descartar esto esta noche).
BrionS
1
Prefiero decir que sería raro al revés. El BIOS que se supone que es compatible con todo en la placa base tiene que funcionar. Linux no lo hace. El BIOS a menudo admite dispositivos de forma simplificada, por ejemplo, VBE para tarjeta gráfica, mientras que no le gustaría usarlos en su lugar o controladores de GPU normales.
TNW
Entonces, ¿hay alguna manera de obligar a Linux a permitir que el BIOS administre los dispositivos para los controladores USB y de red hasta el momento en que sean compatibles (¿mejor?) En el kernel de Linux?
BrionS
No lo creo. Los días en que se accedía a todos los dispositivos a través del BIOS han quedado atrás. Sin embargo, no puedo asegurarle que el problema se deba a la falta de controladores. ¿Encontró algo interesante en dmesg, trató de modprobemódulos relacionados con USB?
TNW

Respuestas:

25

Encontré la respuesta de este hilo ( http://ubuntuforums.org/showthread.php?t=2114055 ) en ubuntuforums.org.

Parece que con las placas base Gigabyte más nuevas (al menos) hay una opción de BIOS llamada IOMMU Controllerque está deshabilitada de forma predeterminada y no da ninguna pista o indicación de para qué sirve.

Habilitar esta configuración y reiniciar "mágicamente" restaura todos mis problemas de red y USB en un sistema operativo Linux de 64 bits (no importa cuál).

Estoy bastante sorprendido y eufórico de que haya sido una búsqueda tan larga de una solución tan simple.

Gracias a todos por su ayuda y sugerencias. Esperemos que otros encuentren esto útil.

Actualización: Me gustaría agregar que la configuración actual de mi BIOS también incluye habilitar la transferencia XHCI y la transferencia EHCI además del controlador IOMMU. Otros han mencionado esto también y habilitar esos dos traslados también permite que mis puertos USB 3.0 funcionen como se esperaba.

BrionS
fuente
1
Señalaré que para mí, aunque encender IOMMU funcionó para mí, desactivó todos mis puertos USB 3 internos. Además, anteriormente estaba experimentando algunos problemas con el puerto ethernet, pero al encender IOMMU se resolvieron esos problemas.
Robbie
¿Intentó habilitar xHCI Handoff para arreglar los puertos USB 3.0?
Stuart P. Bentley
@ StuartP.Bentley sí, las configuraciones de transferencia de xHCI y eHCI están habilitadas, así como el controlador IOMMU. Esto habilita mis puertos USB 3.0, pero por cualquier motivo no permite que mi teclado USB funcione en BIOS o pantallas grub, sin embargo, mi mouse USB sí lo hace (vaya a la figura). Tengo un segundo teclado estilo PS / 2 enchufado únicamente para arrancar en BIOS.
BrionS
Hay algo mas. Si navega por todos los foros de ubuntu, encontrará que se recomienda una configuración de cargador de arranque ("iommu = soft") con IOMMU DIS habilitado . Mi GB 990FXA-UD3 está habilitado de manera predeterminada y no pude usar mi concentrador USB3 externo. LÍNEA INFERIOR: esto puede no resolver su problema. Si no, sigue buscando en Google.
Bruce
Se recomienda dejar la transferencia de EHCI deshabilitada en el BIOS para obtener el mejor rendimiento con USB2.0.
Marc.2377
5

Me acabo de enterar, con mi GA-990FXA-UD7, que tanto para los controladores USB 2.0 y USB 3.0 como para el controlador Ethernet integrado para funcionar correctamente en Linux (estoy usando Mint 17.1) requería la siguiente configuración en el BIOS:

  • Traspaso xHCI: habilitado
  • Transferencia de EHCI: habilitada
  • Controlador IOMMU: habilitado

No olvide deshabilitar UEFI y cambiar todas las opciones de arranque a "Legacy Only".

Si realmente necesita arrancar desde un HDD de> 2.2TB de capacidad, es posible que tenga un problema diferente en sus manos.

Estoy usando un SSD de 256 GB para mi unidad de arranque y un par de discos duros de 3 TB en una matriz RAID 1 (reflejada) usando mdadm para mi / hogar y todo funciona bien.

Después de haber trabajado bastante con las placas Gigabyte, sé que las placas 990FXA-UD5 y 990FXA-UD3 tienen un BIOS muy similar, por lo que es probable que lo mismo se aplique también a esas placas.

PracticalTech
fuente
Me alegra que funcione para ti. Tengo exactamente su configuración (SSD de 256 GB + unidades de 3 TB duplicadas para / u (/ home)). Mis puertos USB3 funcionan, pero el concentrador USB3 colgado de uno no. (Bueno, puedo usar una memoria USB, pero no un teclado o mouse.)
Bruce
iommu=softjunto con xHCI + eHIC Handoff y IOMMU Controller (todos habilitados), sin tener que habilitar "Legacy Only". Arch Linux a velocidad máxima de arranque, EFI y sin problemas de dispositivo raíz iommu o usb3.
Echa un vistazo a esta respuesta de Askubuntu relacionada .
Pablo A
4

Por extraño que parezca, a pesar de que tengo una configuración casi idéntica (misma placa base, procesador FX8350), habilitar el IOMMU no marcó ninguna diferencia para mí. Todavía no hay USB, redes, etc.

Sin embargo, lo que ayudó fue agregar "iommu = soft" a la línea de comando del núcleo. Ahora todo funciona bien (excepto que, por alguna extraña razón, mi Logitech Zone Touch Mouse no funciona).

Ron Murray
fuente
1
Nunca son lo mismo. Incluso unas pocas semanas de diferencia en las fechas de fabricación podrían significar una nueva fuente para un componente de placa base común y / o una revisión de superio. La fabricación de placas de circuito es la sombra de la informática.
mikeserv
3

Para su información, las razones técnicas por las que Linux no puede usar dispositivos "a través" del BIOS: una vez que el sistema operativo ha pasado al "modo protegido" (32 bits) o al "modo largo" (64 bits), ya no puede enviar interrupciones a la BIOS. En "modo real" (16 bits, en el arranque) puede llamar a las interrupciones del BIOS para que lean los discos, la entrada del teclado, etc.

Pero también tiene desventajas. Por un lado, ni siquiera tienes un megabyte de memoria direccionable. Entonces, los sistemas operativos modernos cambian del modo real casi a primera hora. (En realidad, creo que grub cambia al modo protegido antes de que incluso cargue el núcleo).

Más detalles: http://wiki.osdev.org/Real_Mode http://wiki.osdev.org/Protected_Mode

DimeCadmium
fuente
2

Tengo el mismo proceso (pero 8 núcleos) el mismo MB (rev 3) la misma cantidad de RAM (Kingston)

La sugerencia con IOMMU ayudó un poco: todos los puertos pueden ver un teclado usb, un concentrador usb de monitor y un adaptador wifi usb (Realtek), pero no una unidad flash.

Parece que esta solución me ayudó:

cd /sys/bus/pci/drivers/ehci_hcd
ls

Verá un archivo con formato 0000: 00: xx.x. Ejecute el siguiente comando:

sudo sh -c 'echo -n "0000:00:xx.x" > unbind'

Reemplace xx.x con los números que se muestran en su archivo. Debería deshabilitar el ehci_hcd.

Ahora puede usar el siguiente script para deshabilitar ehci_hcd.

cd /sys/bus/pci/drivers/ehci_hcd/
sudo sh -c 'find ./ -name "0000:00:*" -print| sed "s/\.\///">unbind'

http://www.geekdevs.com/2010/04/solved-unable-to-enumerate-usb-device-disabling-ehci_hcd/

Chek
fuente
2
Sería más útil si proporcionara una solución aquí en texto, y solo use enlaces para obtener información general y detalles no esenciales. Sin eso, una vez que su enlace deja de ser válido, su respuesta no tiene valor.
Anthon
Como uno de los usuarios comentó en el enlace que proporcionó "Esto NO es una solución. Esto significa que no está utilizando su unidad a toda velocidad. Esto es como poner una curita en una extremidad cortada".
enthusiasticgeek
2

Estos pasos me funcionaron con un GIGABYTE 970A-DS3P y AMD-FX-8320 con Ubuntu 15.04

  • Traspaso xHCI: habilitado
  • Transferencia de EHCI: habilitada
  • Controlador IOMMU: habilitado
  • UEFI - Deshabilitado
  • Todas las opciones de arranque: solo legado
RVR
fuente
2

Tengo el mismo FX8350 ejecutándose en un Gigabyte 990FXA-UD3 usando OpenSuse 13.1. La solución que funcionó para mí fue editar el gestor de arranque utilizando YAST, la selección predeterminada (o la selección que está utilizando para cargar OpenSuse 13.1 en mi caso), "iommu = pt" después de "showopts silenciosos".

Por ejemplo:

"resume = / dev / disk / by-id / ata-Hitachi_HDS721010CLA332_JP2921HQ1076NA-part2 splash = showopts silenciosos iommu = pt"

¡Ahora todos mis puertos USB 2.0 y 3.0 funcionan y mi red de Internet también funciona! También asegúrese de que IOMMU esté habilitado en BIOS.

dipio
fuente
1

Ayer tuve este problema al instalar Ubuntu en mi placa base ASUSTek M5A99X. Mi objetivo era reinstalar Ubuntu desde una memoria USB en modo UEFI, para reparar la detección de IOMMU por el sistema operativo (mi sistema se instaló a través del modo "BIOS heredado", pensé que esto podría ser una razón).

Anteriormente, lo intenté instalando Ubuntu desde una memoria USB. Bien con Legacy, UEFI siempre fue un problema: o mi teclado / mouse / Wifi no funcionaba correctamente (solo energía) al ingresar al instalador, o el instalador no pudo cargar la interfaz de usuario con mensajes en la consola:

  • (…) device descriptor read/64, error -32 (para cada dispositivo USB)
  • (…) unable to find a live medium containing a live file system(después de 5-6 minutos de lectura desde el palo). Este error tiene una solución alternativa al cambiar el tipo de memoria USB a "Forzar disco duro", pero el sistema de arranque causó otros problemas más tarde después de la instalación.

Estaba pensando que los problemas son de "Unetbootin" o "Startup Disk Creator", no lo son. Pasé más de 2 horas probando todas las configuraciones en BIOS (no tengo IOMMU Controllero xHCI Handoffconfiguraciones en la mía), pero lo único que ayudó fue actualizar el BIOS a la versión más nueva con el archivo ROM descargado del sitio web de Asus para mi modelo de placa base. Es fácil descomprimir y copiar el archivo ROM en la memoria USB y usar la "utilidad EZ Flash" (en BIOS) para actualizar el firmware.

Hacer esto solucionó todo tipo de errores que tenía; Pude instalar y usar Ubuntu en modo UEFI. Más, IOMMU ahora es detectado por Ubuntu mágicamente sin problemas. Esto significa que mis problemas fueron causados ​​por errores de firmware del BIOS relacionados con el soporte USB 2.0 / 3.0 y el soporte de IOMMU. (si no necesita IOMMU, debe desactivar esto en la sección "Avanzado" porque no es algo común).

Croll
fuente