Comprendre la politique des kernels au niveau des versions
7 réponses
Pierre www.zetrader.info
Hello, quand on passe par exemple du kernel 4.15 au 4.16 et ainsi de
suite, je comprends qu'on essaie d'introduire de nouvelles
fonctionnalités, reconnaître du nouveau matériel et sans doute corriger
aussi quelques bugs des versions précédentes.
Ça cest pour le passage de 4.xx à 4.xy
Mais pour ce qui est des changements de version du même kernel :
4.16 à 4.16.1 et ainsi de suite.
Bref le passage de 4.xx.y à 4.xx.z
Là dans ce cas, dites moi si j'interprète mal mais je comprends qu'on
essaie juste de corriger les bugs introduits avec le passage à la
nouvelle version de kernel, on se concentre sur l'amélioration de
stabilité et logiquement le kernel 4.16.18 serait beaucoup plus abouti
et stable que le kernel 4.16.1 ?
Même chose quand ubuntu patche le kernel de 4.15.0-20 petit à petit
jusqu'à 4.15.0-43 (avec pas mal d'étapes intermédiaires), je comprends
que la recherche est surtout la suppression de bugs plutôt que l'ajout
de nouvelles fonctionnalités, donc théoriquement le kernel 4.15.0-43
serait plus abouti et stable que le kernel 4.15.0-20 ?
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Pierre www.zetrader.info
Le 22/12/2018 à 10:17, Pierre www.zetrader.info a écrit :
Hello, quand on passe par exemple du kernel 4.15 au 4.16 et ainsi de suite, je comprends qu'on essaie d'introduire de nouvelles fonctionnalités, reconnaître du nouveau matériel et sans doute corriger aussi quelques bugs des versions précédentes.
Dans la pratique, de ce que j'ai compris aussi maintenant, cela donne souvent : corriger des bugs, en introduire de nouveaux (en voulant introduire de nouvelles fonctionnalités, faire reconnaître du nouveau matériel, ou simplement en ne corrigeant pas de la bonne façon certains bugs, qui de cette manière en introduisent d'autres). Nouveaux bugs qui peuvent mettre un certain temps à être corrigés. C'est là où j'amerais savoir si les versions censées être les plus abouties et plus stables sont bien celles où on progresse sur la 3ème partie du chiffre du kernel : - passage de 4.xx.yy à 4.xx.zz (dans le cas générique) - passage de 4.xx.0-yy à 4.xx.0-zz (dans le cas d'ubuntu)
Ça cest pour le passage de 4.xx à 4.xy Mais pour ce qui est des changements de version du même kernel : 4.16 à 4.16.1 et ainsi de suite. Bref le passage de 4.xx.y à 4.xx.z Là dans ce cas, dites moi si j'interprète mal mais je comprends qu'on essaie juste de corriger les bugs introduits avec le passage à la nouvelle version de kernel, on se concentre sur l'amélioration de stabilité et logiquement le kernel 4.16.18 serait beaucoup plus abouti et stable que le kernel 4.16.1 ? Même chose quand ubuntu patche le kernel de 4.15.0-20 petit à petit jusqu'à 4.15.0-43 (avec pas mal d'étapes intermédiaires), je comprends que la recherche est surtout la suppression de bugs plutôt que l'ajout de nouvelles fonctionnalités, donc théoriquement le kernel 4.15.0-43 serait plus abouti et stable que le kernel 4.15.0-20 ?
Le 22/12/2018 à 10:17, Pierre www.zetrader.info a écrit :
Hello, quand on passe par exemple du kernel 4.15 au 4.16 et ainsi de
suite, je comprends qu'on essaie d'introduire de nouvelles
fonctionnalités, reconnaître du nouveau matériel et sans doute corriger
aussi quelques bugs des versions précédentes.
Dans la pratique, de ce que j'ai compris aussi maintenant, cela donne
souvent : corriger des bugs, en introduire de nouveaux (en voulant
introduire de nouvelles fonctionnalités, faire reconnaître du nouveau
matériel, ou simplement en ne corrigeant pas de la bonne façon certains
bugs, qui de cette manière en introduisent d'autres).
Nouveaux bugs qui peuvent mettre un certain temps à être corrigés.
C'est là où j'amerais savoir si les versions censées être les plus
abouties et plus stables sont bien celles où on progresse sur la 3ème
partie du chiffre du kernel :
- passage de 4.xx.yy à 4.xx.zz (dans le cas générique)
- passage de 4.xx.0-yy à 4.xx.0-zz (dans le cas d'ubuntu)
Ça cest pour le passage de 4.xx à 4.xy
Mais pour ce qui est des changements de version du même kernel :
4.16 à 4.16.1 et ainsi de suite.
Bref le passage de 4.xx.y à 4.xx.z
Là dans ce cas, dites moi si j'interprète mal mais je comprends qu'on
essaie juste de corriger les bugs introduits avec le passage à la
nouvelle version de kernel, on se concentre sur l'amélioration de
stabilité et logiquement le kernel 4.16.18 serait beaucoup plus abouti
et stable que le kernel 4.16.1 ?
Même chose quand ubuntu patche le kernel de 4.15.0-20 petit à petit
jusqu'à 4.15.0-43 (avec pas mal d'étapes intermédiaires), je comprends
que la recherche est surtout la suppression de bugs plutôt que l'ajout
de nouvelles fonctionnalités, donc théoriquement le kernel 4.15.0-43
serait plus abouti et stable que le kernel 4.15.0-20 ?
Le 22/12/2018 à 10:17, Pierre www.zetrader.info a écrit :
Hello, quand on passe par exemple du kernel 4.15 au 4.16 et ainsi de suite, je comprends qu'on essaie d'introduire de nouvelles fonctionnalités, reconnaître du nouveau matériel et sans doute corriger aussi quelques bugs des versions précédentes.
Dans la pratique, de ce que j'ai compris aussi maintenant, cela donne souvent : corriger des bugs, en introduire de nouveaux (en voulant introduire de nouvelles fonctionnalités, faire reconnaître du nouveau matériel, ou simplement en ne corrigeant pas de la bonne façon certains bugs, qui de cette manière en introduisent d'autres). Nouveaux bugs qui peuvent mettre un certain temps à être corrigés. C'est là où j'amerais savoir si les versions censées être les plus abouties et plus stables sont bien celles où on progresse sur la 3ème partie du chiffre du kernel : - passage de 4.xx.yy à 4.xx.zz (dans le cas générique) - passage de 4.xx.0-yy à 4.xx.0-zz (dans le cas d'ubuntu)
Ça cest pour le passage de 4.xx à 4.xy Mais pour ce qui est des changements de version du même kernel : 4.16 à 4.16.1 et ainsi de suite. Bref le passage de 4.xx.y à 4.xx.z Là dans ce cas, dites moi si j'interprète mal mais je comprends qu'on essaie juste de corriger les bugs introduits avec le passage à la nouvelle version de kernel, on se concentre sur l'amélioration de stabilité et logiquement le kernel 4.16.18 serait beaucoup plus abouti et stable que le kernel 4.16.1 ? Même chose quand ubuntu patche le kernel de 4.15.0-20 petit à petit jusqu'à 4.15.0-43 (avec pas mal d'étapes intermédiaires), je comprends que la recherche est surtout la suppression de bugs plutôt que l'ajout de nouvelles fonctionnalités, donc théoriquement le kernel 4.15.0-43 serait plus abouti et stable que le kernel 4.15.0-20 ?
Le Sat, 22 Dec 2018 10:17:04 +0100, Pierre www.zetrader.info écrivait :
Hello, quand on passe par exemple du kernel 4.15 au 4.16 et ainsi de suite, je comprends qu'on essaie d'introduire de nouvelles fonctionnalités, reconnaître du nouveau matériel et sans doute corriger aussi quelques bugs des versions précédentes.
Pfff. C'est surtout pour rajouter des bugs et des trucs pas secs, voyons. Il faut occuper les sysadmins.
Oui j'ai pu remarquer certains bugs, hier j'en ai vu un, introduit avec le noyau 4.18, qui n'est toujours pas résolu dans toutes les versions de kernel 4.18 et 4.19, et il est sorti un paquet de versions en 4.18 et on est déjà en version 4.19.12, toujours pas intégré la résolution du bug, c'est dire si cela peut mettre du temps parfois. Le bug n'était pas présent ni dans le kernel 4.17 ni dans les versions 4.15 LTS, je l'ai lu et je peux confirmer en ayant testé personnellement sous 4.15, j'ai le même problème sous 4.18. Il s'agit d'un problème de memory leak (remplissage progressif de la mémoire, même sans rien faire) sous noyau 4.18, même ceux patchés par ubuntu, de 4.18.0-10 à 4.18.0-13 le bug continue, je ne sais pas ce qu'ils corrigent, mais pas ça en tout. En testant sous noyau 4.15 LTS, ce memory leak n'est pas présent sur ma machine, alors que sous xubuntu 18.10 (noyau 4.18.0-10 ou 4.18.0-13) il y a bien remplissage progressif de la mémoire sans rien faire. Quand le module du wifi est activé (si je reste non connecté, cela reste stable), dès lors que c'est activé, la mémoire commence à se remplir au rythme d'environ 1 Mo toutes les 10 secondes, même sans rien faire, au bout d'un moment plusieurs centaines de Mo en moins, j'ai pu le voir, ça ne fait pas ça sous linux mint 19.1 avec kernel 4.15... En discutant avec un gars sous Debian hier, il m'a dit que pour lui, ce qui marche le mieux c'est kernel 4.17, les kernel 4.18 et 4.19 il évite. Cela illustre bien que c'est pas toujours que des corrections de bugs, on en apporte d'autres aussi au passage, et ça peut durer un certain temps avant que ce soit enfin corrigé.
Ça cest pour le passage de 4.xx à 4.xy Mais pour ce qui est des changements de version du même kernel : 4.16 à 4.16.1 et ainsi de suite. Bref le passage de 4.xx.y à 4.xx.z Là dans ce cas, dites moi si j'interprète mal mais je comprends qu'on essaie juste de corriger les bugs introduits avec le passage à la nouvelle version de kernel, on se concentre sur l'amélioration de stabilité et logiquement le kernel 4.16.18 serait beaucoup plus abouti et stable que le kernel 4.16.1 ?
Peut-être. Peut-être pas. De toute façon, pour obtenir un système tout à fait stable, je t'ai déjà dit qu'il fallait virer la libc (avec un rm -f). JKB
Ce ne sera pas trop stable après ? ;) -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 22/12/2018 à 10:36, JKB a écrit :
Le Sat, 22 Dec 2018 10:17:04 +0100,
Pierre www.zetrader.info <pierre@aribaut.com.invalid> écrivait :
Hello, quand on passe par exemple du kernel 4.15 au 4.16 et ainsi de
suite, je comprends qu'on essaie d'introduire de nouvelles
fonctionnalités, reconnaître du nouveau matériel et sans doute corriger
aussi quelques bugs des versions précédentes.
Pfff. C'est surtout pour rajouter des bugs et des trucs pas secs,
voyons. Il faut occuper les sysadmins.
Oui j'ai pu remarquer certains bugs, hier j'en ai vu un, introduit avec
le noyau 4.18, qui n'est toujours pas résolu dans toutes les versions de
kernel 4.18 et 4.19, et il est sorti un paquet de versions en 4.18 et on
est déjà en version 4.19.12, toujours pas intégré la résolution du bug,
c'est dire si cela peut mettre du temps parfois.
Le bug n'était pas présent ni dans le kernel 4.17 ni dans les versions
4.15 LTS, je l'ai lu et je peux confirmer en ayant testé personnellement
sous 4.15, j'ai le même problème sous 4.18.
Il s'agit d'un problème de memory leak (remplissage progressif de la
mémoire, même sans rien faire) sous noyau 4.18, même ceux patchés par
ubuntu, de 4.18.0-10 à 4.18.0-13 le bug continue, je ne sais pas ce
qu'ils corrigent, mais pas ça en tout.
En testant sous noyau 4.15 LTS, ce memory leak n'est pas présent sur ma
machine, alors que sous xubuntu 18.10 (noyau 4.18.0-10 ou 4.18.0-13) il
y a bien remplissage progressif de la mémoire sans rien faire.
Quand le module du wifi est activé (si je reste non connecté, cela reste
stable), dès lors que c'est activé, la mémoire commence à se remplir au
rythme d'environ 1 Mo toutes les 10 secondes, même sans rien faire, au
bout d'un moment plusieurs centaines de Mo en moins, j'ai pu le voir, ça
ne fait pas ça sous linux mint 19.1 avec kernel 4.15...
En discutant avec un gars sous Debian hier, il m'a dit que pour lui, ce
qui marche le mieux c'est kernel 4.17, les kernel 4.18 et 4.19 il évite.
Cela illustre bien que c'est pas toujours que des corrections de bugs,
on en apporte d'autres aussi au passage, et ça peut durer un certain
temps avant que ce soit enfin corrigé.
Ça cest pour le passage de 4.xx à 4.xy
Mais pour ce qui est des changements de version du même kernel :
4.16 à 4.16.1 et ainsi de suite.
Bref le passage de 4.xx.y à 4.xx.z
Là dans ce cas, dites moi si j'interprète mal mais je comprends qu'on
essaie juste de corriger les bugs introduits avec le passage à la
nouvelle version de kernel, on se concentre sur l'amélioration de
stabilité et logiquement le kernel 4.16.18 serait beaucoup plus abouti
et stable que le kernel 4.16.1 ?
Peut-être. Peut-être pas. De toute façon, pour obtenir un système
tout à fait stable, je t'ai déjà dit qu'il fallait virer la libc
(avec un rm -f).
JKB
Ce ne sera pas trop stable après ? ;)
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le Sat, 22 Dec 2018 10:17:04 +0100, Pierre www.zetrader.info écrivait :
Hello, quand on passe par exemple du kernel 4.15 au 4.16 et ainsi de suite, je comprends qu'on essaie d'introduire de nouvelles fonctionnalités, reconnaître du nouveau matériel et sans doute corriger aussi quelques bugs des versions précédentes.
Pfff. C'est surtout pour rajouter des bugs et des trucs pas secs, voyons. Il faut occuper les sysadmins.
Oui j'ai pu remarquer certains bugs, hier j'en ai vu un, introduit avec le noyau 4.18, qui n'est toujours pas résolu dans toutes les versions de kernel 4.18 et 4.19, et il est sorti un paquet de versions en 4.18 et on est déjà en version 4.19.12, toujours pas intégré la résolution du bug, c'est dire si cela peut mettre du temps parfois. Le bug n'était pas présent ni dans le kernel 4.17 ni dans les versions 4.15 LTS, je l'ai lu et je peux confirmer en ayant testé personnellement sous 4.15, j'ai le même problème sous 4.18. Il s'agit d'un problème de memory leak (remplissage progressif de la mémoire, même sans rien faire) sous noyau 4.18, même ceux patchés par ubuntu, de 4.18.0-10 à 4.18.0-13 le bug continue, je ne sais pas ce qu'ils corrigent, mais pas ça en tout. En testant sous noyau 4.15 LTS, ce memory leak n'est pas présent sur ma machine, alors que sous xubuntu 18.10 (noyau 4.18.0-10 ou 4.18.0-13) il y a bien remplissage progressif de la mémoire sans rien faire. Quand le module du wifi est activé (si je reste non connecté, cela reste stable), dès lors que c'est activé, la mémoire commence à se remplir au rythme d'environ 1 Mo toutes les 10 secondes, même sans rien faire, au bout d'un moment plusieurs centaines de Mo en moins, j'ai pu le voir, ça ne fait pas ça sous linux mint 19.1 avec kernel 4.15... En discutant avec un gars sous Debian hier, il m'a dit que pour lui, ce qui marche le mieux c'est kernel 4.17, les kernel 4.18 et 4.19 il évite. Cela illustre bien que c'est pas toujours que des corrections de bugs, on en apporte d'autres aussi au passage, et ça peut durer un certain temps avant que ce soit enfin corrigé.
Ça cest pour le passage de 4.xx à 4.xy Mais pour ce qui est des changements de version du même kernel : 4.16 à 4.16.1 et ainsi de suite. Bref le passage de 4.xx.y à 4.xx.z Là dans ce cas, dites moi si j'interprète mal mais je comprends qu'on essaie juste de corriger les bugs introduits avec le passage à la nouvelle version de kernel, on se concentre sur l'amélioration de stabilité et logiquement le kernel 4.16.18 serait beaucoup plus abouti et stable que le kernel 4.16.1 ?
Peut-être. Peut-être pas. De toute façon, pour obtenir un système tout à fait stable, je t'ai déjà dit qu'il fallait virer la libc (avec un rm -f). JKB
Ce ne sera pas trop stable après ? ;) -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
jp willm
Le 22/12/2018 à 10:17, Pierre www.zetrader.info a écrit :
Même chose quand ubuntu patche le kernel de 4.15.0-20 petit à petit jusqu'à 4.15.0-43 (avec pas mal d'étapes intermédiaires), je comprends que la recherche est surtout la suppression de bugs plutôt que l'ajout de nouvelles fonctionnalités, donc théoriquement le kernel 4.15.0-43 serait plus abouti et stable que le kernel 4.15.0-20 ?
Juste pour info, sur manjaro le kernel 4.19 est en fonction depuis un moment et a l'air de bien fonctionner. Sur Xubuntu, j'installais les kernels récents pour les tester et n'ai pas connu de problèmes. -- jp willm http://perso.orange.fr/willms/index.html
Le 22/12/2018 à 10:17, Pierre www.zetrader.info a écrit :
Même chose quand ubuntu patche le kernel de 4.15.0-20 petit à petit
jusqu'à 4.15.0-43 (avec pas mal d'étapes intermédiaires), je comprends
que la recherche est surtout la suppression de bugs plutôt que l'ajout
de nouvelles fonctionnalités, donc théoriquement le kernel 4.15.0-43
serait plus abouti et stable que le kernel 4.15.0-20 ?
Juste pour info, sur manjaro le kernel 4.19 est en fonction depuis un
moment et a l'air de bien fonctionner.
Sur Xubuntu, j'installais les kernels récents pour les tester et n'ai
pas connu de problèmes.
Le 22/12/2018 à 10:17, Pierre www.zetrader.info a écrit :
Même chose quand ubuntu patche le kernel de 4.15.0-20 petit à petit jusqu'à 4.15.0-43 (avec pas mal d'étapes intermédiaires), je comprends que la recherche est surtout la suppression de bugs plutôt que l'ajout de nouvelles fonctionnalités, donc théoriquement le kernel 4.15.0-43 serait plus abouti et stable que le kernel 4.15.0-20 ?
Juste pour info, sur manjaro le kernel 4.19 est en fonction depuis un moment et a l'air de bien fonctionner. Sur Xubuntu, j'installais les kernels récents pour les tester et n'ai pas connu de problèmes. -- jp willm http://perso.orange.fr/willms/index.html
Thomas Alexandre
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...] on est déjà en version 4.19.12
$ uname -r 4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé. -- Les nouvelles aventures incroyablement extraordinaires de Don Rémy del κρυπτoλoγoς : http://zywn.free.fr/remy/
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...]
on est déjà en version 4.19.12
$ uname -r
4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé.
--
Les nouvelles aventures incroyablement extraordinaires
de Don Rémy del κρυπτoλoγoς : http://zywn.free.fr/remy/
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...] on est déjà en version 4.19.12
$ uname -r 4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé. -- Les nouvelles aventures incroyablement extraordinaires de Don Rémy del κρυπτoλoγoς : http://zywn.free.fr/remy/
Marc SCHAEFER
In fr.comp.os.linux.configuration Pierre www.zetrader.info wrote:
Mais pour ce qui est des changements de version du même kernel : 4.16 à 4.16.1 et ainsi de suite. Bref le passage de 4.xx.y à 4.xx.z
Il ne faut pas oublier que les distributions ne livrent pas le kernel pur, mais une version patchée. Les patches peuvent contenir des backports de correctifs pas encore intégrés ou de versions suivantes, des améliorations de fonctionnalités idem, etc. Installer le kernel pur de kernel.org est possible, mais ça fait un moment que je ne l'ai plus fait.
In fr.comp.os.linux.configuration Pierre www.zetrader.info <pierre@aribaut.com.invalid> wrote:
Mais pour ce qui est des changements de version du même kernel :
4.16 à 4.16.1 et ainsi de suite.
Bref le passage de 4.xx.y à 4.xx.z
Il ne faut pas oublier que les distributions ne livrent pas le
kernel pur, mais une version patchée. Les patches peuvent
contenir des backports de correctifs pas encore intégrés ou
de versions suivantes, des améliorations de fonctionnalités
idem, etc.
Installer le kernel pur de kernel.org est possible, mais ça
fait un moment que je ne l'ai plus fait.
In fr.comp.os.linux.configuration Pierre www.zetrader.info wrote:
Mais pour ce qui est des changements de version du même kernel : 4.16 à 4.16.1 et ainsi de suite. Bref le passage de 4.xx.y à 4.xx.z
Il ne faut pas oublier que les distributions ne livrent pas le kernel pur, mais une version patchée. Les patches peuvent contenir des backports de correctifs pas encore intégrés ou de versions suivantes, des améliorations de fonctionnalités idem, etc. Installer le kernel pur de kernel.org est possible, mais ça fait un moment que je ne l'ai plus fait.
Pierre www.zetrader.info
Le 22/12/2018 à 12:46, Thomas Alexandre a écrit :
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...] on est déjà en version 4.19.12
$ uname -r 4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé.
Oui et non. Oui : je n'ai pas le problème de memory leak sous nouveau 4.15 mais je continue à avoir les pertes de connexion aléatoires de temps en temps, toujours ce module realtek rtl8723be pour le wifi. Et si j'avais voulu tester le noyau 4.18 c'était justement par rapport à ces problèmes de connexions aĺéatoires, la connexion était effectivement plus stable sous noyau 4.18 (comme d'autres l'avaient mentionné) mais ça se paie par un memory leak avec la connexion wifi. Peut-être que le compromis se trouve dans le noyau 4.17 qui lui bénéfice des mêmes améliorations que le noyau 4.18 par rapport au module rtl8723be, sans avoir le problème du memory leak. Parce que sous noyau 4.15 les versions de kernel patchés se succèdent, mais le problème de déconnexions aléatoires (souvent peu de temps après le début de la session, j'arrive à une déconnexion, et je dois désactiver/réactiver le wifi logiciellement pour me reconnecter) reste le même. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 22/12/2018 à 12:46, Thomas Alexandre a écrit :
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...]
on est déjà en version 4.19.12
$ uname -r
4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé.
Oui et non.
Oui : je n'ai pas le problème de memory leak sous nouveau 4.15 mais je
continue à avoir les pertes de connexion aléatoires de temps en temps,
toujours ce module realtek rtl8723be pour le wifi.
Et si j'avais voulu tester le noyau 4.18 c'était justement par rapport à
ces problèmes de connexions aĺéatoires, la connexion était effectivement
plus stable sous noyau 4.18 (comme d'autres l'avaient mentionné) mais ça
se paie par un memory leak avec la connexion wifi.
Peut-être que le compromis se trouve dans le noyau 4.17 qui lui bénéfice
des mêmes améliorations que le noyau 4.18 par rapport au module
rtl8723be, sans avoir le problème du memory leak.
Parce que sous noyau 4.15 les versions de kernel patchés se succèdent,
mais le problème de déconnexions aléatoires (souvent peu de temps après
le début de la session, j'arrive à une déconnexion, et je dois
désactiver/réactiver le wifi logiciellement pour me reconnecter) reste
le même.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...] on est déjà en version 4.19.12
$ uname -r 4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé.
Oui et non. Oui : je n'ai pas le problème de memory leak sous nouveau 4.15 mais je continue à avoir les pertes de connexion aléatoires de temps en temps, toujours ce module realtek rtl8723be pour le wifi. Et si j'avais voulu tester le noyau 4.18 c'était justement par rapport à ces problèmes de connexions aĺéatoires, la connexion était effectivement plus stable sous noyau 4.18 (comme d'autres l'avaient mentionné) mais ça se paie par un memory leak avec la connexion wifi. Peut-être que le compromis se trouve dans le noyau 4.17 qui lui bénéfice des mêmes améliorations que le noyau 4.18 par rapport au module rtl8723be, sans avoir le problème du memory leak. Parce que sous noyau 4.15 les versions de kernel patchés se succèdent, mais le problème de déconnexions aléatoires (souvent peu de temps après le début de la session, j'arrive à une déconnexion, et je dois désactiver/réactiver le wifi logiciellement pour me reconnecter) reste le même. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Pierre www.zetrader.info
Le 23/12/2018 à 22:09, Pierre www.zetrader.info a écrit :
Le 22/12/2018 à 12:46, Thomas Alexandre a écrit :
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...] on est déjà en version 4.19.12
$ uname -r 4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé.
Oui et non. Oui : je n'ai pas le problème de memory leak sous nouveau 4.15 mais je continue à avoir les pertes de connexion aléatoires de temps en temps, toujours ce module realtek rtl8723be pour le wifi. Et si j'avais voulu tester le noyau 4.18 c'était justement par rapport à ces problèmes de connexions aĺéatoires, la connexion était effectivement plus stable sous noyau 4.18 (comme d'autres l'avaient mentionné) mais ça se paie par un memory leak avec la connexion wifi. Peut-être que le compromis se trouve dans le noyau 4.17 qui lui bénéfice des mêmes améliorations que le noyau 4.18 par rapport au module rtl8723be, sans avoir le problème du memory leak. Parce que sous noyau 4.15 les versions de kernel patchés se succèdent, mais le problème de déconnexions aléatoires (souvent peu de temps après le début de la session, j'arrive à une déconnexion, et je dois désactiver/réactiver le wifi logiciellement pour me reconnecter) reste le même.
Du coup je teste le kernel 4.17.19 là, vu que du kernel 4.15.0-20 au kernel 4.15.0-43 (la dernière version lts à ce jour) le problème de déconnexion aléatoire persiste, et que cela ne semble pas dans les plans de résoudre ce problème d'instabilité de la connexion wifi avec le module rtl8723be pour le kernel LTS. Si la connexion wifi est assez stable (plus que sous kernel 4.15), que cela permet d'éviter le problème du memory leak du kernel 4.18/4.19, alors dans ce cas il est probable que je l'adopte à l'usage pour un certain temps. Voir problèmes de memory leak (que j'ai pu voir à titre perso aussi sous plusieurs kernels en version 4.18) : https://bbs.archlinux.org/viewtopic.php?id$0381 https://forum.manjaro.org/t/lts-kernel-4-19-memory-leakage-with-driver-rtl8723be/65756 Dans ce second fil, avec le même module que moi, sous kernel 4.17.19 le monsieur n'a pas le memory leak (et il ne mentionne pas de problème de connexion ou autre sous ce kernel) alors que sous kernel 4.19 il l'a, d'où l'envie de tester ce kernel 4.17.19 un certain temps pour voir si c'est le meilleur compromis. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
Le 23/12/2018 à 22:09, Pierre www.zetrader.info a écrit :
Le 22/12/2018 à 12:46, Thomas Alexandre a écrit :
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...]
on est déjà en version 4.19.12
$ uname -r
4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé.
Oui et non.
Oui : je n'ai pas le problème de memory leak sous nouveau 4.15 mais je
continue à avoir les pertes de connexion aléatoires de temps en temps,
toujours ce module realtek rtl8723be pour le wifi.
Et si j'avais voulu tester le noyau 4.18 c'était justement par rapport à
ces problèmes de connexions aĺéatoires, la connexion était effectivement
plus stable sous noyau 4.18 (comme d'autres l'avaient mentionné) mais ça
se paie par un memory leak avec la connexion wifi.
Peut-être que le compromis se trouve dans le noyau 4.17 qui lui bénéfice
des mêmes améliorations que le noyau 4.18 par rapport au module
rtl8723be, sans avoir le problème du memory leak.
Parce que sous noyau 4.15 les versions de kernel patchés se succèdent,
mais le problème de déconnexions aléatoires (souvent peu de temps après
le début de la session, j'arrive à une déconnexion, et je dois
désactiver/réactiver le wifi logiciellement pour me reconnecter) reste
le même.
Du coup je teste le kernel 4.17.19 là, vu que du kernel 4.15.0-20 au
kernel 4.15.0-43 (la dernière version lts à ce jour) le problème de
déconnexion aléatoire persiste, et que cela ne semble pas dans les plans
de résoudre ce problème d'instabilité de la connexion wifi avec le
module rtl8723be pour le kernel LTS.
Si la connexion wifi est assez stable (plus que sous kernel 4.15), que
cela permet d'éviter le problème du memory leak du kernel 4.18/4.19,
alors dans ce cas il est probable que je l'adopte à l'usage pour un
certain temps.
Voir problèmes de memory leak (que j'ai pu voir à titre perso aussi sous
plusieurs kernels en version 4.18) :
https://bbs.archlinux.org/viewtopic.php?id$0381
https://forum.manjaro.org/t/lts-kernel-4-19-memory-leakage-with-driver-rtl8723be/65756
Dans ce second fil, avec le même module que moi, sous kernel 4.17.19 le
monsieur n'a pas le memory leak (et il ne mentionne pas de problème de
connexion ou autre sous ce kernel) alors que sous kernel 4.19 il l'a,
d'où l'envie de tester ce kernel 4.17.19 un certain temps pour voir si
c'est le meilleur compromis.
--
http://zetrader.info & http://zetrader.fr
http://aribaut.com - http://zeforums.com
Le 23/12/2018 à 22:09, Pierre www.zetrader.info a écrit :
Le 22/12/2018 à 12:46, Thomas Alexandre a écrit :
Le Sat, 22 Dec 2018 10:56:49 +0100, Pierre www.zetrader.info a écrit :
memory leak [...] noyau 4.18 [...] pas résolu [...] on est déjà en version 4.19.12
$ uname -r 4.9.0-8-686-pae
noyau 4.15 LTS, ce memory leak n'est pas présent
Problème réglé.
Oui et non. Oui : je n'ai pas le problème de memory leak sous nouveau 4.15 mais je continue à avoir les pertes de connexion aléatoires de temps en temps, toujours ce module realtek rtl8723be pour le wifi. Et si j'avais voulu tester le noyau 4.18 c'était justement par rapport à ces problèmes de connexions aĺéatoires, la connexion était effectivement plus stable sous noyau 4.18 (comme d'autres l'avaient mentionné) mais ça se paie par un memory leak avec la connexion wifi. Peut-être que le compromis se trouve dans le noyau 4.17 qui lui bénéfice des mêmes améliorations que le noyau 4.18 par rapport au module rtl8723be, sans avoir le problème du memory leak. Parce que sous noyau 4.15 les versions de kernel patchés se succèdent, mais le problème de déconnexions aléatoires (souvent peu de temps après le début de la session, j'arrive à une déconnexion, et je dois désactiver/réactiver le wifi logiciellement pour me reconnecter) reste le même.
Du coup je teste le kernel 4.17.19 là, vu que du kernel 4.15.0-20 au kernel 4.15.0-43 (la dernière version lts à ce jour) le problème de déconnexion aléatoire persiste, et que cela ne semble pas dans les plans de résoudre ce problème d'instabilité de la connexion wifi avec le module rtl8723be pour le kernel LTS. Si la connexion wifi est assez stable (plus que sous kernel 4.15), que cela permet d'éviter le problème du memory leak du kernel 4.18/4.19, alors dans ce cas il est probable que je l'adopte à l'usage pour un certain temps. Voir problèmes de memory leak (que j'ai pu voir à titre perso aussi sous plusieurs kernels en version 4.18) : https://bbs.archlinux.org/viewtopic.php?id$0381 https://forum.manjaro.org/t/lts-kernel-4-19-memory-leakage-with-driver-rtl8723be/65756 Dans ce second fil, avec le même module que moi, sous kernel 4.17.19 le monsieur n'a pas le memory leak (et il ne mentionne pas de problème de connexion ou autre sous ce kernel) alors que sous kernel 4.19 il l'a, d'où l'envie de tester ce kernel 4.17.19 un certain temps pour voir si c'est le meilleur compromis. -- http://zetrader.info & http://zetrader.fr http://aribaut.com - http://zeforums.com
