Bonjour, j’ai installé le kernel 5.3 qui se trouve dans buster-backports, mais je n’ai pas vu d’améliorations après le redémarrage. De plus, mes jeux natifs Linux refusent de lancer, sauf si j’utilise le runtime de SteamPlay.
Cependant, je suis parti dans le bios et j’ai constaté que l’option IOMMU était activée. Je l’ai donc désactivée, mais j’ai toujours les mêmes problèmes.
Concernant le lecteur de cartes, j’avais une erreur sur la carte. J’ai dû retirer la carte SD à un mauvais moment et les données étaient corrompues. Je m’en suis rendu compte, car dès que j’accédais au contenu de la carte, tous les fichiers étaient en lecture seule. Lorsque j’essayais de flasher mon fichier binaire dans la mémoire flash, j’avais systématiquement une erreur.
J’ai formaté la carte SD, cela fonctionne mieux, mais par moment le lecteur de carte s’éteint quand j’insère la carte SD et je dois quelques secondes avant de pouvoir y accéder.
Concernant la copie de fichiers sur clé USB, c’est toujours le même constat. La dernière fois, j’ai copier un film dont la taille est inférieure à 1GO, la copie n’est pas allé plus loin que 98% pour ne pas changer.
Si c’est pour tenter de voir comme je le suggérais s’il s’agit d’un conflit entre le kernel et la version de bios, c’est raté : tu avais probablement un noyau 4.19 avec Stretch.
Tu parles de flasher quoi ? Ton BIOS ? Si tu as eu des erreurs, es-tu sûr (même si le fait que tu aies pu redémarrer est plutôt rassurant) que ton BIOS est bien correctement fonctionnel ? Je pense que tu ne peux être vraiment sûr de ça que si, au final, tu as réussi un flashage sans erreur, avec un fichier binaire dont tu as bien vérifié la somme de contrôle.
Je ne suis pas certain que ce soit forcément inquiétant : il faut bien le temps que le changement soit détecté et que tout soit mis en place. Ce n’est généralement vraiment pas immédiat (quelques secondes voire un peu plus).
Attention : la progression de la copie n’est pas vraiment significative. Souvent, le fichier source est mis en cache et, quand il est lu (donc quand le compteur indique 98% voire 100%), le cache est flushé sur la clé ou la carte, ce qui peut prendre du temps s’il y a un gros cache (1Go, c’est un peu long si tu es en USB 2 ! ). Assez en tous cas pour se demander si tout n’est pas planté… et éventuellement retirer la clé/carte trop tôt !
Sinon, et si tu est bien certain de tout ce que j’ai mentionné ci-dessus, je ne vois pas… Désolé : j’espère que quelqu’un de plus compétent pourra te venir en aide !
Avec Buster oui, c’était bien un kernel 4.19. J’ai migré vers sid, le problème est toujours présent avec le kernel 5.4.
Je n’ai pas flashé le BIOS, je suis développeur et je compile des fichiers binaires pour d’anciennes consoles de jeux vidéo. La ROM ou fichier binaire, est copier sur une carte SD que j’insère dans un flash cart, ce qui me permet de tester mon programme sur la console.
Je comprends, mais sa prend plus que quelques secondes il me semble. Parfois, il faut attendre et d’autre fois, il ne se passe absolument rien. Je dois recommencé l’opération pour que cela fonctionne. Ce qui me tracasse, c’est que le lecteur de cartes fonctionnait très bien sous Windows et le problème est apparu dès que j’ai migré vers Linux en installant Debian, mais bon, du moment que sa fonctionne ^^.
Disons que je ne trouve pas cela normal et pourtant j’ai cet ordinateur depuis 2013. J’ai quasiment que des ports USB que se soit à l’arrière ou en façade et j’utilise des clés USB relativement rapide. Un fichier de 700mo est assez rapide à copier généralement, mais depuis mon passage sous Debian, impossible de copier un fichier correctement. Pour preuve, cela fait plus de 10 minutes que j’attends que mon fichier de 733mo soit terminé d’être copié et il ne passe rien.
Je vais essayer de creuser le problème, en attendant je peux utiliser un disque dur externe pour copier mes fichiers via USB, dans cas de figure, la copie est très rapidement et ne bloque pas à 97%. Merci pour ton aide
J’ai peut être une piste en regardant ce que donne la commande kentosama@teradrive:~$ sudo dmesg -l warn
0.000000] secureboot: Secure boot could not be determined (mode 0)
[ 0.015956] ACPI BIOS Warning (bug): Optional FADT field Pm2ControlBlock has valid Length but zero Address: 0x0000000000000000/0x1 (20190816/tbfadt-615)
[ 1.654157] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 1.809801] CRAT table not found
[ 2.183727] sdb: p2 size 2248864640 extends beyond EOD, enabling native capacity
[ 2.196303] sdb: p2 size 2248864640 extends beyond EOD, truncated
[ 16.206310] r8169 0000:03:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[ 5820.720584] FAT-fs (sdh1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[ 6966.386512] kauditd_printk_skb: 12 callbacks suppressed
[10585.560417] kauditd_printk_skb: 313 callbacks suppressed
[13446.801038] sr 7:0:0:0: Power-on or device reset occurred
[13454.833214] sr 7:0:0:0: Power-on or device reset occurred
[27523.683185] FAT-fs (sdh1): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
[29982.279297] r8169 0000:03:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[41817.146485] show_signal_msg: 312 callbacks suppressed
[42000.499169] r8169 0000:03:00.0: Direct firmware load for rtl_nic/rtl8168e-3.fw failed with error -2
[42712.977200] FAT-fs (sdi): Volume was not properly unmounted. Some data may be corrupt. Please run fsck.
Gagné ! J’ai installé le paquet firmware-realtek et tout fonctionne parfaitement bien maintenant pour la copie de fichier, mais le lecteur de cartes continue de faire le fou
Effectivement, “volume was not properly unmounted”, ce n’est pas normal surtout avec une carte que tu viens de reformater. Et comme je suppose que ce n’est pas toi qui, à chaque fois, la sors du lecteur sans la démonter proprement, ça veut dire très probablement que mes gros soupçons sur la connectique sont justifiés. Je suis un peu moins sûr sur ce point, mais je pense que les “Power-on or device restet occured” ne font que confirmer un problème de connectique.
Évidemment, si ça a commencé pile au moment du passage sous Buster, ça met un doute. Mais, curieusement, j’ai souvent vu ce genre de coïncidence assez vicieuse parce qu’effectivement, on va chercher ailleurs alors que le problème est bien là où on a peine à le croire.
Donc, essaie de trouver une solution pour résoudre ce(s) problème(s) de connectique, et je pense réellement que tout va rentrer dans l’ordre. Si ce n’est pas le cas, tu pourras toujours chercher ailleurs ensuite, au moins tu seras vraiment sûr sur ce point.
En installant le paquet firmware-realtek je n’ai plus de problème pour la copie de fichier. C’est rapide et va jusqu’à la fin sans problème. Il reste lecteur de cartes qui s’éteint quand je mets la carte SD puis se rallume au bout de 20 / 30 secondes et m’affiche le contenu de la carte.
Donc, je dirais que tu as un double problème : effectivement, je n’avais pas pensé au firmware, ça peut expliquer certaines choses. Mais si ton lecteur s’éteint toujours quand tu insères une carte, je maintiens que tu devrais vérifier la connectique.
Finalement ce n’est ni le hardware, le firmware ou le bios. C’est un problème connu et donc il n’y a pas de solution visiblement. En réalité, je me suis trompé, je viens de me rendre compte que j’avais formater la clé USB en NTSC aulieu de FAT32. Je viens de le remarquer en branchant la clé sur ma PlayStation 2 qui, forcément n’a pas reconnu la partition.
Lorsque j’ai formaté la clé USB en fat32 ce fut le retour de ce problème des 99%.
En réalité la copie va très vite vite, car le fichier est copié dans la mémoire tampon, mais même en attendant 1 heure, la copie ne se termine jamais. La solution qui est indiqué et que j’ai utilisé par hasard est d’utiliser une partition NTFS. La copie est très rapide et se termine sans encombre.
Hors mon problème est que je veux utiliser le fat32.
Je n’ai pas encore migré mes postes de travail sous Buster (faudrait bien que je m’y mette, pourtant !), et je ne me souviens plus si j’ai utilisé une clé FAT32 sur mon serveur ou pas… Ça me surprend quand même un peu, ce problème sans solution. Tu as un lien qui l’explique ?
Bon, je pense que ce n’est pas la peine de te suggérer de passer ta clé en Ext4, tu veux du FAT pour compatibilité avec d’autres appareils ? Perso, j’utilise Ext4 sauf si la clé ou carte doit être lue sur un système qui ne le reconnaît pas : ça me semble plus naturel avec GNU/Linux.
Mais tu es sur que le format NTFS ne passe pas sur ta playstation 2 ? C’est sensé fonctionner sur la 3.
Et ça vaudrait le coup de voir aussi ce que dit ta PS2 avec un format ext, sait on jamais (je n’ai pas trouvé la liste des formats disques supportés sur la PS2).
Oui, le fat32 me permet d’utiliser la clé USB sur différents appareils, mais en réalité, dans ce cas précis, c’est une clé que j’utilise pour la sauvegarde de mes données et transporter quelques outils. Donc une partition ext4 pourrait être une solution effectivement.
Un lien qui explique le problème :
C’est ce que la plupart des personnes expliquent sur différents fils de discutions. D’ailleurs, j’ai patienté un petit moment hier avant de copier un fichier de 1GO sur la clé USB et effectivement, le fichier fini par ce copier. J’ai d’ailleurs pu lancer un ISO depuis cette clé sur ma PlayStation 2.
Je n’ai pas dit ça.
J’ai dit que ça méritait d’être vérifié.
Sinon, je ne sait plus si on t’a demandé:
le blocage arrive aussi quand tu fais un bête cp ?
Parceque ton truc parle d’un bug de nautilus, donc autant ne pas utiliser nautilus, et ton probléme sear règlé, non ?
Oui, comme dit @mattotop, cp serait peut-être la solution. Sinon, as-tu tenté de réduire la taille du buffer, comme proposé dans le lien que tu donnes ? Ce n’est pas parce que quelqu’un dit que ça ne fonctionne pas sous Ubuntu que c’est pareil sous Debian ! Le test est assez vite fait, et si ce n’est pas concluant, tu remets la valeur d’origine.
Disons que pour les autres pareils, il s’agit de fichiers de petites tailles, donc si je dois utiliser une autre clé USB en fat32, cela ne posera pas de problèmes.
Cependant, il serait peut-être judicieux d’utiliser le format ext2 afin de pas écrire inutilement sur la clé usb.
Tu parles de la journalisation d’ext4 ? Je ne pense pas que ça ait une grosse importance de ce point de vue, mais bon : ext2 devrait faire le job aussi, à toi de voir.
