Aller au contenu principal
Messages récents
12
Installation et boot / Re : DMR,erreur bios
Dernier message par jtro -
oui,il est enabled et il le restera vu que j'ai une tumbleweesd kde en vm(avec gnome boxes qui est vraiment très pratique)
13
Installation et boot / Re : DMR,erreur bios
Dernier message par Chumi -
il semblerait que ça soit courrant:

En effet, en faisant quelques recherches on constate des plaintes similaires sur les forums de diverses distributions.

@jtro - Dans le Bios, au rayon "Virtualization" (onglet "Security" peut-être?), regarde l'état d'Intel (R) VT-d Feature (un truc comme ça). Si Enabled, passe-le à Disabled.

Pour l'explication, c'est aussi ce que j'ai compris au sujet de DMAR et tutti quanti, il question de permettre à une machine virtuelle d'accéder directement aux ressources matérielles de l'ordinateur.

Soit dit en passant, sur mon ThinkPad, j'ai toujours des erreurs ACPI, quelque soit la distribution que j'ai essayée dessus, et j'ai pris le parti de les ignorer au final.
15
Installation et boot / Re : DMR,erreur bios
Dernier message par burn2 -
Hello.

il semblerait que ça soit courrant:
https://bbs.archlinux.org/viewtopic.php?id=253883

Et que ça concerne des erreurs ACPI correspondant aux instructions de virtualisations.
ça peut poser problème si tu comptes faire du passthrough en virtualisation (dédier un périphérique matériel genre gpu à une vm directement), mais je doute que ça soit le cas sur un pc portable. :D

16
Contribuer à la communauté openSUSE / Re : Leap 15.3
Dernier message par burn2 -
Bon après avoir investigué, je confirme que c'est un pb très particulier et qui n'a rien à voir avec opensuse.
Il semblerait que le problème se pose lorsque je suis connecté en wifi en 2.4ghz!
En 5ghz le pb disparait.

Mais le plus surprenant c'est que sur cette même machine sous windows ras.
Que sur l'ancien pc portable en 2.4ghz sous leap 15.2 ras.

Surement un bug ou une incompatibilité par rapport au pilote linux et mon routeur en 2.4ghz.
17
Installation et boot / DMR,erreur bios
Dernier message par jtro -
salut,
j'ai un message au boot qui dit:
DMAR: [Firmware Bug]: Your BIOS is broken; bad RMRR [0x00000000cd800000-0x00000000cfffffff]
                                  BIOS vendor: LENOVO; Ver: JEET85WW (1.34 ); Product Version: ThinkPad S1 Yoga 12
mai 07 17:55:17 localhost kernel: DMAR: [Firmware Bug]: No firmware reserved region can cover this RMRR
et contacter le vendeur du bios à savoir lenovo.
apparemment,ça ne gêne pas la bonne marche du pc portable.
J'ai fait la mise à jour vers leap 15.3 et également une grosse mise à jour de windows 10, donc je ne sais pas d'où ça vient.
J'ai la dernière version du bios.
 La seule chose qui ait changé,c'est le secure boot, d'un côté on me dit qu'il est désactivé et de l'autre il est coché comme activé!
Je ne sais pas ce qu'est la DMAR?
c'est pas très important vu que la machine tourne bien mais le message qui apparait au boot,c'est pas très propre.
Si vous avez une idée du pourquoi du comment,n'hésitez pas.
18
Contribuer à la communauté openSUSE / Re : Leap 15.3
Dernier message par burn2 -
Hello.

Bon j'ai un petit soucis remonté en testant réellement leap 15.3.
Je ne sais pas trop d'ou ça provient mais le flux réseau coupe/freeze de temps en temps.

Symptômes:
* Je mets une webradio en ligne (testé avec deux différentes), le flux va s'interrompre puis reprendre après. (pas de problème de connexion, la même webradio sur un autre pc est ok)
* Idem sur un flux RDP,
Mais en pingant en même temps je ne vois rien de particulier, et en regardant des vidéos de youtube c'est transparents on ne perçoit pas la coupure.

Je ne sais pas si c'est propre à ma puce wifi intel AX200. (testé sur 2 portables identiques même problème)
Vous avez constaté le même soucis ou tout est ok à 100% pour vous?

Je vais lancer le flux via vlc en ligne de commande voir si j'ai des logs qui remontent.


EDIT:  la seule erreur que je vois à postériori c'est: "ES_OUT_SET_(GROUP_)PCR is called too late (pts_delay increased to 1000ms)" mais pas sur que ça soit lié.
Je vois le compteur de temps qui ne bouge plus pendant parfois un moment, puis subitement le son revient et en même temps le compteur repart.

EDIT2: c'est ça nouvelle coupure et à nouveau l'erreur via
"ES_OUT_SET_(GROUP_)PCR is called too late (jitter of 28455 ms ignored)"


EDIT3: j'ai fais le test avec la radio en même temps sur un autre pc.
En fait ça ne semble pas être un pb de tampon, sinon je resterais syncho, quand ça repart, ça repart là ou ça s'est arrêté.  (exactement comme si on met en pause)
Potentiellement un pb de pulse audio/audio ou de codec du coup. 


EDIT4: le problème était déjà présent sous LEAP 15.2 et semble identique.
EDIT5: Test sous tumbleweed ==> Idem!!!

Je ne pige pas pour le coup ce qui peut poser problème comme ça.

EDIT6: test sous manjaro, même problème!
Du coup, je me demande si ce n'est pas une incompatibilité wifi...
Je switch en 5ghz voir ce que ça donne.


EDIT7: Bon ben ça semble se confirmer, en 5ghz plus de pb. Vraiment bizarre!
ALors que mon clevo à côté est bien en 2.4Ghz sans soucis.
19
Général / Re : Tumbleweed ne veut plus s'éteindre (Network Manager)
Dernier message par chalu -
récente, récente... pas vraiment : août 2018
Dois-je comprendre qu'une petite réinstall complète de temps en temps ne ferait pas de mal ?
Je dois reconnaître être un peu frileux. La réinstall n'est pas un problème en soi, mais tout reconfigurer ça pourrait être un peu long
Non c'était par rapport au lien que tu donnes qui est ancien.
Ton problème vient peut-être de l’arrivée d’un nouveau noyau, on est sur le 5.12 de mémoire.
Tu peux déclarer le souci sur le  d’openSUSE en joignant un log.
Une mise à jour réglera peut-être le problème comme pour jtro.
20
Général / Re : Tumbleweed ne veut plus s'éteindre (Network Manager)
Dernier message par guiv -
Le lâche contournement, bien que pas très satisfaisant intellectuellement, semble très bien fonctionner.  :)
J'enchaîne les reboots les uns après les autres, dans l'objectif de reconfigurer mes logs en mémoire volatile. Parce que je sais que les avis sont partagés sur la question, mais je suis de ceux qui pensent que les logs verbeux qui fusillent les SSD sont malheureusement une réalité.

Plus de problème de blocage à l'extinction  :))
Mais si déplacer les logs en mémoire non volatile était un jeu d'enfant, dans l'autre sens ça l'est beaucoup moins !
Il ne suffit pas de supprimer la ligne "Storage=persistent" dans /etc/systemd/journald.conf
Pas non plus de la remplacer par "Storage=volatile", conformément au "man journald.conf"
Il faut, en plus de ça, supprimer le répertoire /var/log/journal
ouf !