Reprise du message précédent :
ça doit limité les interactions sur les sites non ?

Pour info, la version 6.3-rc5 se compile, s'installe et fonctionne avec KRN
 

Forcément (même si les liens sont pris en charge), mais faut plutôt voir ça comme un défi de geek dans toute sa splendeur (accéder à des blogs, articles de presse ou Wikipédia depuis des machines potentiellement plus anciennes que le Web, et ne prennent donc pas en charge les algos de chiffrement actuels) ; et aussi comme un moyen d’accéder hyper-rapidement à l’info que tu veux lire (puisque tu n’as que du texte à afficher), sans subir des encarts pub ou des images et vidéos qui peuvent alourdir la page (je connais un autre type qui a créé un proxy Web similaire sur Gemini et qui donne des statistiques sur la bande passante économisée par rapport au site original : ça peut réduire le total à télécharger jusqu’à plus de 90%, parfois !).

Personnellement, je m’en sers surtout pour lire vite fait des articles de sites que je sais assez lourdingues, et que j’ai pas envie de charger d’abord en entier pour ensuite passer en mode lecture.

Le 6.2.11 ne semble pas compiler sous Debian 11... Quelqu'un a réussi ou a eu des soucis? Pour l'instant j'ai que "make: error 2", je regarde de plus près...

 
Pas encore reboot mais il a compilé sans problème ici.

 
dans les logs ubuntu, certaines constructions ont échoué car il manque libfuse-dev

Merci, mais à priori c'est plus embêtant:

J'avais autre chose à faire, faut que je regarde maintenant cette histoire.

Bon bah j'y comprend rien... J'ai fait un build avec V=1 soit verbose et pas de soucis, du coup j'ai refait un build "normal" comme avant et en partant de zéro et c'est passé aussi! Je ne cherche pas...

Ta RAM est potentiellement HS ?
Sinon juste un bug aléatoire de de ton compilateur  

Ca m'étonnerai, mon système est stable en principe (touchons du silicium).
Ca doit être le compilo qui déconnait. Ce genre de bugs c'est les pires...

la définition d'un problème de ram quoi
Quelques passes de memtest (le vrai au boot pas celui en userland) pour être sûr ça fait jamais de mal

Non non, je me suis mal exprimé. Mon système est parfaitement stable à condition de forcer la CG à pleine puissance, le fameux bug que personne n'arrive à résoudre...

Je vois pas le rapport mais je m'arrête ici, ça mène nulle part.

Je compilerai la 6.2.11 sur une VM Debian du taf lundi et je vous dirai.

Désolé, je dois parler chinois.  
 
En bref:
-Mon système est stable, je ne sais pas d'où venait cette erreur mais je ne pense pas que la RAM soit en cause.
-J'ai pu compiler la 6.2.11 au final.
 
 

AMHA, le fait de désactiver la gestion de l'énergie sur ta CG doit forcer un autre truc (le bus PCIe par ex) à tirer aussi plus de courant ce qui impacte un élément comme CPU/RAM/northbridge, possiblement en empêchant de dormir ou de se sousvolter.
On le voit plutôt dans l'autre sens avec l'overclocking mais j'avais une machine qui plantait complètement uniquement quand elle était peu chargée, le GPU légèrement utilisé et les C-states activés (CPU baytrail : https://bugzilla.kernel.org/show_bug.cgi?id=109051 ) alors c'est pas du domaine de l'impossible.

autre exemple qui se rapproche un peu : https://old.reddit.com/r/Amd/commen [...] stability/

un autre bug qui ressemble aussi : https://bugzilla.kernel.org/show_bug.cgi?id=206903 en particulier les derniers commentaires

Il y a en effet un autre bug connu, celui des C-states pour les Ryzen 1ère génération. J'ai un petit script qui désactive ça au boot et/ou c'est désactivé dans le BIOS (je sais plus ). Mais le truc de la gestion d'énergie des CG AMD est bien connu aussi et à ma connaissance personne n'a réellement de solution sauf forcer la CG à pleine puissance. Après je ne connais pas suffisamment le hardware ni le noyau Linux pour connaître toutes les choses que ça peut engrendrer etc. Je sais juste que avec le "fix" Ryzen et le "fix" CG mon système est stable. Maintenant cette histoire de SIGSEGV en compilant le .11, aucune idée, mais les chemins de l'informatique parfois...

Bien !
La compil de la 6.2.11 s'est passée comme un fleur. J'ai même pu booter une Debian 12 avec

Noyau 6.3 en approche a priori.
 
edit : wait!
 
C'est sorti .
L'annonce de Linus Torvalds :

 
 
Aussi,  

Vu là par exemple.
Quelque chose que je viens de remarquer, via dmesg :

Plop

Ca parle à des gens ici des soucis de carte réseau USB avec la connection qui plante et dmesg qui contient ces trucs?

Je suis sous Debian 11 mais avec le 6.3.1 c'est pourquoi je poste ici.
J'ai une carte réseau USB3 ASIX Electronics Corp. AX88179 Gigabit Ethernet (0b95:1790) utilisé en 100MBit car vieille box ADSL (sudo cat /sys/class/net/enx<bidule>/speed).
Le soucis arrive (depuis un certain temps) environ une fois tout les 48h, sachant que - étant en ADSL bien lent - je n'ai jamais beaucoup de traffic sur cette carte. Je ne peux pas dire quand c'est apparu la première fois hélas.
La box est en mode Bridge mais je ne pense pas que ça ait de l'importance.
Quand le bug survient la LED traffic du port au niveau de la box clignote comme un fou. Je dois débrancher et rebrancher le câble (et me reconnecter à internet - bridge comme je disais), ip set link down/up ne suffit pas. J'ai pas testé rmmod/insmod suggéré sur internet pour l'instant.

Parlant d'internet, j'ai bien sûr fait des recherches et trouvé des bugs plus ou moins similaires (https://bugs.launchpad.net/ubuntu/+ [...] ug/1667750 mais à priori là pas de soucis en 100MBit?), mais qui sont marqués résolus, d'où ma question. Je vais à l'occasion changer de carte réseau USB, j'en ai une autre quelque part mais peut-être avec la même puce si c'est lié au pilote (à voir).

Pour l'instant c'est pas trop, trop génânt, mais voulant passer à la fibre je crains des emmerdes si c'est - comme dans les vieux bugs - lié à la quantité de données qui passe par le réseau...

EDIT: Après vérification l'autre carte c'est du D-Link 1312 qui semble utiliser le même pilote. Quelqu'un qui a les mêmes soucis avec du D-Link 13x2 ou du ASIX AX88179?

 
Petit Up pour les 20 ans du topic.

Déjà ??!
 
Ça nous rajeunit pas !
 
Bon anniversaire !

bon annif'

Vu qu'on est en sous-cat' débats, VirtualBox ou KVM/libvirt? Logiquement la deuxième solution est "plus logique" car intégrée au noyau, mais peut-être VB a des avantages?
 
Perso j'utilise KVM/libvirt, ça fonctionne mais les OS (surtout des Debian aussi) sont un peu lents, je me demandais justement comment rendre ça plus fluide. Par contre le passthrough USB3 c'est du caca.

j'aime bien faire joujou avec GNOME Boxes, donc qemu, donc kvm

Virtualbox utilise KVM sur un host Linux ... et les extensions prennent en charge l'USB3 sans problèmes.  
De plus pour le guest, il y a les addons qui aident beaucoup. Je viens de monter un VM Win11 et le pilote graphique VBox 7.0.10 règle les derniers soucis d'affichage / transparence.

 
Les versions des noyaux sont à jour.

le 6.3 a dit au revoir hier

Je pensais que ça allait aussi passer ici mais rien. Vous pensez quoi de la réduction du support LTS de 6 à deux ans ?
https://www.linux.org/threads/linux [...] ars.46803/

J'ai regardé très brièvement, à première vue c'est pas une bonne chose mais ils doivent manquer de monde pour la maintenance etc...

ça me choque pas, 2 ans c'est déjà pas mal je trouve. Au delà on est vraiment dans le besoin spécifique.

De toute façon, sur les distributions comme Debian et RHEL qui durent jusqu’à 5, voire 10 ans, ce sont les mainteneurs de ces dernières qui assurent le rétroportage des correctifs de sécurité sur leurs paquets du noyau. Ça ne changera pas grand-chose, à part qu’ils n’auront plus de noyau déjà patché en amont au bout de deux ans.

Et encore, Debian ne fait pas de conservatisme morbide sur les noyaux comme chez RedHat / IBM.

bon ben évidemment le 6.6 et Nvidia... on repasse en 6.5 pour la vidéo HD

Non pour du desktop ça ne me dérange pas, pour du server un peu plus quoi....

... à moins de compter sur ça. Mais du coup, je ne comprends pas ce travail de rétroportage qui pourrait être dédié à la maintenance direct du kernel. Pas le même travail certes, mais dispersion des ressources.

J'ai installé le 6.5 pour voir (surtout comment MX s'en sort - très bien ), j'étais sur 6.1 par défaut.
Ce changement au niveau des t° cpu (plus basses encore) et du fan (qui ne se lance plus pour rien)    
autocpu freq semble enfin faire son job.
Ce silence  
Et du coup la batterie devrait s'en porter mieux aussi.
 
edit : ah ouais, ça reste en dessous de 10w de consommation maintenant    
 

 
Chaque distrib. travaillant avec certains patchs spécifiques, ça leur ajouterait du boulot de travailler en plus sur le kernel partagé.
Et ça donnerait quand même du travail de vérification aux mainteneurs officiels qui sont responsables en dernier lieu.

Essaie le dernier 6.6 ...

Ah, donc, c’est la branche de noyau Linux 6.6 qui sera la prochaine LTS quand la branche 6.7 sortira :
https://www.omgubuntu.co.uk/2023/11 [...] rm-support
 
Côté Arch Linux, on parie qu’on va encore avoir des paquets « linux-lts » en AVANCE de version sur les « linux » à ce moment-là (le passage à la branche suivante pour « linux » se faisant rarement avant la version ×.×.1, et le paquet « linux-lts » passant à la branche LTS suivante quand la non-LTS passe à la sienne) ?

Passage du laptop AMD 6800 de 6.5.0 (MX) à 6.6.1 (Liquorix) : no souci pour le chargement de amd-pstate-epp par défaut.
Par contre, celui en Intel 11, il me charge acpi-cpufreq au lieu de intel-pstate (cas sur le précédent)