Pour le fond je viens de construire une nouvelle machine avec du matériel moderne comprenant:
Compte tenu de cela, j'ai essayé d'installer différentes versions de Linux sur le SSD et j'ai rencontré l'échec presque à chaque fois. J'ai essayé d'installer Arch, Debian stable, Debian Sid et Ubuntu 12.10 à partir d'une clé USB, mais pendant que le BIOS voyait la clé USB et a commencé à démarrer à partir de celle-ci, dès que le système d'exploitation a tenté d'énumérer les périphériques USB, j'ai perdu toutes les fonctionnalités USB (y compris le périphérique de démarrage).
Finalement, j'ai gravé un DVD et installé Ubuntu 12.10 sur le SSD. Il convient de noter que mon clavier (et ma souris) USB fonctionne correctement dans l'American Megatrends UEFI/BIOS. Même lorsque je suis dans les menus de pré-installation sur le DVD Live Ubuntu, le clavier fonctionne bien.
Dès que Linux est démarré (soit Live DVD ou à partir du SSD), je perds toutes les fonctionnalités USB et ne peux naviguer dans le système d'exploitation qu'à l'aide d'un clavier PS/2.
Ce que je vois dans le dmesg/syslog est quelques lignes sur "failed to load microcode AMD_ucode/microcode_AMD_fam15h.bin
"et je peux voir que les périphériques USB ne s'initialisent pas.
Si je fais un lsusb
je peux voir tous les contrôleurs USB Host mais aucun des périphériques. Faire un lspci
me montre tout le matériel auquel je m'attendais. Et en faisant un lsmod
je ne vois aucun module USB chargé (usb_ehci
par exemple).
J'ai essayé de passer noapic
à la chaîne de démarrage du noyau et cela n'a eu aucun effet sur ce problème.
La carte mère prend en charge l'USB 3.0 mais tous les appareils que j'ai connectés aux ports USB 2.0 normaux.
Je suis plutôt déconcerté par ce qui pourrait tuer/empêcher l'USB (et ma carte réseau intégrée) de fonctionner sous Linux. Il ne semble pas y avoir de problème avec l'un de ces périphériques fonctionnant dans le BIOS et je n'ai pas d'installation Windows disponible pour tester et voir si cela fonctionne.
J'ai déjà RMA une fois la carte mère, mais la seconde a exactement le même comportement, donc je pense que je peux exclure en toute sécurité une défaillance matérielle (puisque le comportement est identique, je ne pense pas que ce soit étrange que j'obtienne deux cartes identiques défectueuses sont plus grandes que les chances que cela soit un problème Linux).
Que puis-je essayer de faire fonctionner l'USB (et idéalement mon réseau, mais nous nous en tiendrons à l'USB pour l'instant)?
Éditer # 1:
Comme je n'ai pas de réseau, je ne peux que relier ici des extraits intéressants de dmesg
.
Intéressant dans dmesg
Je peux voir que j'ai 11 contrôleurs hôtes USB (OHCI, EHCI et xHCI). Il détecte mes périphériques USB et échoue immédiatement comme suit:
usb 3-1: new high-speed USB device number 2 using ehci_hcd
usb 3-1: device descriptor read/64, error -32
Cela se répète plusieurs fois en incrémentant le nombre et en essayant d'autres contrôleurs USB Host jusqu'à ce qu'il retombe sur les contrôleurs OHCI qui échouent également mais ont un message supplémentaire:
usb 8-1: device not accepting address 4, error -32
Je pense que mes problèmes de réseau sont liés au fait que je n'ai pas activé IPv6 sur mon routeur et cela semble être un problème
eth1: no IPv6 routers present
Modifier # 2:
lspci -vvv
montre que mes adaptateurs réseau (à la fois intégrés et d'extension) sont Realtek Semiconductor (pas de surprise); RTL8111/8168B et RTL8169/8110 respectivement. Mes contrôleurs USB sont Etron Technology EJ168 (xHCI) et AMD nee ATI SB7x0/SB8x0/SB9x0 (EHCI & OHCI)
Maintenant, Debian Wheezy modprobe
affiche usb_common
, usbcore
, xhci_hcd
, ehci_hcd
, et ohci_hcd
tout chargé et fonctionnel.
J'ai trouvé la réponse de ce fil ( http://ubuntuforums.org/showthread.php?t=2114055 ) sur ubuntuforums.org.
Il semble qu'avec les cartes mères Gigabyte plus récentes (au moins), il existe une option BIOS appelée IOMMU Controller
qui est désactivé par défaut et ne donne aucune indication ni indication sur son utilisation.
Activer ce paramètre et redémarrer "comme par magie" restaure tous mes problèmes USB et de réseau dans un système d'exploitation Linux 64 bits (peu importe lequel).
Je suis plutôt choqué et ravi que ce soit une si longue recherche d'une solution aussi simple.
Merci à tous pour votre aide et vos suggestions. J'espère que d'autres trouveront cela utile.
Mise à jour: Je voudrais juste ajouter que mes paramètres BIOS actuels incluent également l'activation du transfert XHCI et du transfert EHCI en plus du contrôleur IOMMU. D'autres l'ont également mentionné et l'activation de ces deux transferts permet également à mes ports USB 3.0 de fonctionner comme prévu.
Je viens d'apprendre, avec mon GA-990FXA-UD7, que pour que les contrôleurs USB 2.0 et USB 3.0 et le contrôleur Ethernet intégré fonctionnent correctement sous Linux (j'utilise Mint 17.1), il fallait les paramètres suivants dans le BIOS:
N'oubliez pas de désactiver UEFI et de changer toutes les options de démarrage en "Legacy Only".
Si vous avez vraiment besoin de démarrer à partir d'un disque dur d'une capacité> 2,2 To, vous pourriez avoir un problème différent entre les mains.
J'utilise un SSD de 256 Go pour mon lecteur de démarrage et une paire de disques durs de 3 To dans une matrice RAID 1 (en miroir) utilisant mdadm pour mon/home et tout fonctionne bien.
Ayant beaucoup travaillé avec les cartes Gigabyte, je sais que les cartes 990FXA-UD5 et 990FXA-UD3 ont un BIOS très similaire, il est donc probable que la même chose s'applique également à ces cartes.
Curieusement, même si j'ai une configuration presque identique (même carte mère, processeur FX8350), l'activation de l'IOMMU n'a pas fait de différence pour moi. Toujours pas d'USB, de mise en réseau, etc.
Ce que a fait aide, cependant, a été d'ajouter "iommu = soft" à la ligne de commande du noyau. Maintenant, tout fonctionne bien (sauf que, pour une raison étrange, ma souris tactile Logitech Zone Touch ne fonctionne pas).
Pour info, les raisons techniques pour lesquelles Linux ne peut pas utiliser de périphériques "via" le BIOS: une fois que le système d'exploitation est passé en "mode protégé" (32 bits) ou en "mode long" (64 bits), il ne peut plus envoyer d'interruptions au BIOS. En "mode réel" (16 bits, au démarrage), il peut appeler des interruptions du BIOS pour lire les disques, saisir le clavier, etc.
Mais il a aussi des inconvénients. D'une part, vous n'avez même pas un mégaoctet de mémoire adressable. Donc, le basculement du système d'exploitation moderne hors du mode réel est presque la première chose. (En fait, je crois que grub passe en mode protégé avant même de charger le noyau).
Plus de détails: http://wiki.osdev.org/Real_Modehttp://wiki.osdev.org/Protected_Mode
J'ai le même proc (mais 8 cœurs) le même Mo (rev 3) la même quantité de RAM (Kingston)
L'astuce avec IOMMU a un peu aidé - tous les ports peuvent voir un clavier USB, un concentrateur USB de moniteur et un adaptateur WiFi USB (Realtek), mais pas de lecteur flash.
Il semble que cette solution m'a aidé:
cd /sys/bus/pci/drivers/ehci_hcd
ls
Vous verrez un fichier au format 0000: 00: xx.x. Exécutez la commande suivante:
Sudo sh -c 'echo -n "0000:00:xx.x" > unbind'
Remplacez le xx.x par les nombres affichés sur votre fichier. Il devrait désactiver l'ehci_hcd.
Vous pouvez maintenant utiliser le script suivant pour désactiver 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/
Ces étapes ont fonctionné pour moi avec un GIGABYTE 970A-DS3P et AMD-FX-8320 exécutant Ubuntu 15.04
J'ai le même FX8350 fonctionnant sur un Gigabyte 990FXA-UD3 utilisant OpenSuse 13.1. La solution qui a fonctionné pour moi a été de modifier le chargeur de démarrage en utilisant YAST, la sélection par défaut (ou la sélection que vous utilisez pour charger OpenSuse 13.1 dans mon cas), "iommu = pt" après "showopts silencieux".
Par exemple:
"resume =/dev/disk/by-id/ata-Hitachi_HDS721010CLA332_JP2921HQ1076NA-part2 splash = silencieux silencieux showopts iommu = pt"
Maintenant, tous mes ports USB 2.0 et 3.0 fonctionnent et mon réseau Internet fonctionne aussi!. Assurez-vous également que IOMMU est activé dans le BIOS.
Hier, j'ai eu ce problème lors de l'installation d'Ubuntu sur ma carte mère ASUSTek M5A99X. Mon objectif était de réinstaller Ubuntu à partir d'une clé USB en mode UEFI, pour corriger la détection IOMMU par OS (mon système a été installé via le mode "Legacy BIOS", je pensais que cela pourrait être une raison).
Auparavant, j'ai essayé cela en installant Ubuntu à partir d'une clé USB. Très bien avec Legacy, UEFI a toujours été un problème - soit mon clavier/souris/Wifi ne fonctionnait pas correctement (alimentation uniquement) lors de la saisie du programme d'installation, soit le programme d'installation ne chargeait pas l'interface utilisateur avec des messages dans la console:
(…) device descriptor read/64, error -32
(pour chaque périphérique USB)(…) unable to find a live medium containing a live file system
(après 5-6 minutes de lecture du bâton). Cette erreur a une solution de contournement en changeant le type de clé USB en "Force Hard Disk", mais le système de démarrage a causé d'autres problèmes plus tard après l'installation.Je pensais que les problèmes venaient de "Unetbootin" ou de "Startup Disk Creator" - ils ne le sont pas. J'ai passé plus de 2 heures à essayer tous les paramètres du BIOS (je n'ai pas IOMMU Controller
ou xHCI Handoff
paramètres dans le mien), mais le seule chose aidée - mise à niveau du BIOS vers la version la plus récente avec ROM téléchargé depuis le site Web d'Asus pour mon modèle de carte mère. C'est aussi simple que de décompresser et en copiant le fichier ROM sur la clé USB et en utilisant "l'utilitaire EZ Flash" (dans le BIOS) pour flasher le firmware.
Faire cela a corrigé toutes sortes d'erreurs que j'avais; J'ai pu installer et utiliser Ubuntu en mode UEFI. De plus, IOMMU est maintenant détecté par Ubuntu comme par magie sans aucun problème. Cela signifie que mes problèmes ont été causés par des bogues du micrologiciel du BIOS liés à la prise en charge USB 2.0/3.0 et à la prise en charge IOMMU. (si vous n'avez pas besoin d'IOMMU, vous devez le désactiver dans la section "Avancé" car ce n'est pas chose courante).