Re: Kernel 2.4 The kernel of pain? slashdot article
On Sat, 19 Jan 2002, Philippe Strauss wrote: N'empeche qu'a chaque noyau c'est une nouvel fin du monde: quel horreur il est moins stable que la version stable d'il y a deux ans. J'y vois rien d'autre qu'un processus normal, naturel: une version stable d'il y a deux ans est plus stable que la version stable qui vient d'etre appelee stable. On s'habitue a la stabilite Non: il ne s'agit pas de cela. 2.4.x, x = 9 était une version tout à fait utilisable, sans crashes, sans les problèmes de `oops, no memory, killing XXX' de 2.2.x. Dans un certain sens elle était `meilleure' que 2.2.x, du moins pour les serveurs. Mais rien n'empeche d'appliquer un patch 2.4.18-pre3-ac2 (alan cox) qui utilise la VM de rik van riel (celle de 2.4.9) Ou de faire le contraire, soit prendre 2.4.9 et ajouter les patches de sécurité ou de fonctionnalité nécessaires. Pour l'instant c'est ce que je fais. Maintenir des kernel patches ca prend du temps, et c'est un de ces trucs qui pourrait faire l'objet d'une cooperation entre utilisateurs avances (qui s'amuse a compiler des noyau patches) et moins avances. Les distributions le font. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Tue, Jan 22, 2002 at 12:09:44PM +0100, Marc SCHAEFER wrote: On Sat, 19 Jan 2002, Philippe Strauss wrote: N'empeche qu'a chaque noyau c'est une nouvel fin du monde: quel horreur il est moins stable que la version stable d'il y a deux ans. J'y vois rien d'autre qu'un processus normal, naturel: une version stable d'il y a deux ans est plus stable que la version stable qui vient d'etre appelee stable. On s'habitue a la stabilite Non: il ne s'agit pas de cela. 2.4.x, x = 9 était une version tout à fait utilisable, sans crashes, sans les problèmes de `oops, no memory, killing XXX' de 2.2.x. Dans un certain sens elle était `meilleure' que 2.2.x, du moins pour les serveurs. ok, mais si linus a change la VM dans 2.4.10, meme si il a reconnu par la suite que ce n'etait pas du tout le bon moment, ce n'est pas pour agasser tout ces utilisateurs. C'est parce que le design de la nouvelle est a son gout, meilleur que la precedentes. Creer un peu de bronx pour remplacer qqchose par une reecriture mieux concue, c'est, en terme de creation, toute la force du libre. au niveau timing je ne dit pas, c'etait pas bon :) mais vu que je ne gere pas de machine chargee ces temps, j'ai pas d'experience de serveur instable en 2.4.x avec x 9, stable en 2.4.9 et pas tres stable en 2.2.19 ou .20 T'as raporte cet experience sur linux-kernel? ca les interesserait peut-etre. Mais rien n'empeche d'appliquer un patch 2.4.18-pre3-ac2 (alan cox) qui utilise la VM de rik van riel (celle de 2.4.9) Ou de faire le contraire, soit prendre 2.4.9 et ajouter les patches de sécurité ou de fonctionnalité nécessaires. Pour l'instant c'est ce que je fais. Maintenir des kernel patches ca prend du temps, et c'est un de ces trucs qui pourrait faire l'objet d'une cooperation entre utilisateurs avances (qui s'amuse a compiler des noyau patches) et moins avances. Les distributions le font. oui, mais choisir les options du kernel, c'est toujours qu'un enorme compromis, pour les cas ou les compromis des distrib ne conviennent plus, c'est une possiblite. une sous-distribution du kernel au niveau regional, pour slalomer entre les 'speciales' de compaq et autres fabriquants de PC pas vraiment PC :) -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
Salut a tous, Ca n'a peut etre pas grand-chose a voir avec ce thread, mais bon : il existe un bug dans la plupart des Athlon/Duron concernant l'extended paging (4Mb). Ce bug peut affecter le fonctionnement de l'AGP sous un kernel 2.4 compile pour Pentium. Un workaround rapide est de rajouter la ligne append mem=nopentium dans lilo.conf Voir http://slashdot.org/articles/02/01/21/0750226.shtml http://www.vnunet.com/News/1128504 Dom -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Saturday 19 January 2002 09:10, Marc SCHAEFER wrote: - mais de toute manière entre temps on peut espérer que le 2.5.x sera utilisable ... ce qui ne sera pas vrai avant 1 à 2 ans dans les faits :( J'ai trouvé cette petite annonce chez Transtec. Linux, pour la première fois avec USB 2.0 Linus Torvalds a lancé une nouvelle version 2.5.2 du noyau Linux, qui pour la première fois supporte le standard USB 2.0. Ce standard, qui avait été adopté en 2000, mais jusqu'à présent adapté avec réticence, atteint des taux de transfert maximal de 480 Mbit/s. Même le système d'exploitation Windows XP de Microsoft ne devrait le supporter que dans l'une des prochaines mises à jour. Donc, il y a déjà un 2.5.2... mais dans quel état ?-) Daniel -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Sat, Jan 19, 2002 at 09:10:13AM +0100, Marc SCHAEFER wrote: On Fri, 18 Jan 2002, Francois Deppierraz wrote: On Fri, Jan 18, 2002 at 03:30:14PM +0100, Marc SCHAEFER wrote: Une moins efficace VM (2.4.9-pristine) vaut mieux que deux VM de m*rde (= 2.4.10-pristine). Houla, plus ça va plus je me dis que mon futur kernel s'appellera plutôt /bsd... Résumons: - 2.4.9 semble être une version très fiable, mais pas forcément toujours très efficace en interactif. [ j'en ai en production ] - 2.4.10-2.4.15 semblent inutilisables. - 2.4.17 semble utilisable, mais crashe de temps en temps même en `workstation load'. [ je n'en ai pas en production ] En bref, le changement de VM de 2.4.9 à 2.4.10 était une catastrophe. Comme déjà dit, c'est clair que s'ils avaient appliqué leurs propres règles (pas de changement majeur dans une version stable) cela ne serait pas arrivé. On a déjà vécu la même chose en 2.0.x, de 2.0.14 à 2.0.35. Maintenant, que va-t-il se passer ? - les bugs restant dans la 2.4.17 vont au fur et à mesure être corrigés, si bien qu'il sortira un jour une 2.4.42 qui sera aussi fiable que 2.4.9 et aussi performante que 2.4.10. - mais de toute manière entre temps on peut espérer que le 2.5.x sera utilisable ... ce qui ne sera pas vrai avant 1 à 2 ans dans les faits :( Solution: la seule que je vois: - implémenter un système de contrôle de version stable/instable à la Debian, *mais avec des cycles de développement assez courts*. Apparemment, l'engagement d'un nouveau mainteneur (le jeune Brésilien) qui semble comprendre les implications des problèmes de qualité logiciel va dans la bonne direction. PS: peut-être que ton futur kernel s'appellera /hurd ? :) Note qu'a chaque noyau recemment 'stable' c'est la meme histoire. Bon la effectivement linus a change ca trop tard (ou trop tot). N'empeche qu'a chaque noyau c'est une nouvel fin du monde: quel horreur il est moins stable que la version stable d'il y a deux ans. J'y vois rien d'autre qu'un processus normal, naturel: une version stable d'il y a deux ans est plus stable que la version stable qui vient d'etre appelee stable. On s'habitue a la stabilite de la version qui prend le temps de devenir mur et on a peur du probleme restant a ajuste dans la derniere toute fraiche. Oh c'est sain comme reaction, au moins la communaute d'utilisateur reste critique. Mais bon, depuis 2.4.0, je n'ai pas reboote ma machine en 2.2, jamais eu de crash, sur ma station de travail qui c'est vrai n'a pas trop de charge et 384 MB de ram. Si j'avais des serveur charges a maintenir, sans doute bien qu'il serait encore en 2.2. Mais rien n'empeche d'appliquer un patch 2.4.18-pre3-ac2 (alan cox) qui utilise la VM de rik van riel (celle de 2.4.9) Rien n'empeche non plus de s'organiser au niveau local pour gerer des versions de kernel patchees en fonctions de certaines contraintes applicatives pour les serveurs charges. Maintenir des kernel patches ca prend du temps, et c'est un de ces trucs qui pourrait faire l'objet d'une cooperation entre utilisateurs avances (qui s'amuse a compiler des noyau patches) et moins avances. Heureusement que le developpement du noyau est encore un bazaar bordelique, ca ne serait pas linux autrement. Les *BSD semble avoir un model de developpement plus stricte, faudra que j'en installe un une fois pour voir ce que ca donne comme resultat, mais je me dit que le model un peu bordelique de linux est gage de plus de creativite. un interview d'Alan Cox qui parle de la VM et de Marcello Tosatti: http://kerneltrap.org/article.php?sid=490 aplus -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Fri, Jan 18, 2002 at 09:21:33PM +0100, Francois Deppierraz wrote: On Fri, Jan 18, 2002 at 01:54:39PM +0100, Philippe Strauss wrote: ohh ksymoops is gonna be your friend :)) Jan 17 21:29:45 gollum kernel: 1Unable to handle kernel paging request at virtual address 10627759 Jan 17 21:29:45 gollum kernel: c01367c0 Jan 17 21:29:45 gollum kernel: *pde = Jan 17 21:29:45 gollum kernel: Oops: Jan 17 21:29:45 gollum kernel: CPU:0 Jan 17 21:29:45 gollum kernel: EIP:0010:[link_path_walk+1408/1760] Not tainted Jan 17 21:29:45 gollum kernel: EFLAGS: 00010202 Jan 17 21:29:45 gollum kernel: eax: 10627731 ebx: c5264340 ecx: c18143f0 edx: Jan 17 21:29:45 gollum kernel: esi: c63d7f70 edi: c63d7fa4 ebp: cb950479 esp: c63d7f54 Jan 17 21:29:45 gollum kernel: ds: 0018 es: 0018 ss: 0018 Jan 17 21:29:45 gollum kernel: Process navigator-smoti (pid: 7018, stackpage=c63d7000) Jan 17 21:29:45 gollum kernel: Stack: d6a9c000 c63d7fa4 0009 0001 0009 d6a9c021 c5264340 Jan 17 21:29:45 gollum kernel:d6a9c01f 0002 00019b4c c013693a c0136cc5 c63d6000 c63d7fa4 08f9a8c0 Jan 17 21:29:45 gollum kernel:bfffe30c c0133f79 c63d6000 087cbc60 c7085b40 dffeb340 c63d6000 087cbc60 Jan 17 21:29:45 gollum kernel: Call Trace: [path_walk+26/32] [__user_walk+53/80] [sys_stat64+25/112] [system_call+51/56] Jan 17 21:29:45 gollum kernel: Code: 83 78 28 00 0f 84 87 00 00 00 be 00 e0 ff ff 21 e6 83 be 54 Code; Before first symbol _EIP: Code; Before first symbol 0: 83 78 28 00 cmpl $0x0,0x28(%eax) Code; 0004 Before first symbol 4: 0f 84 87 00 00 00 je 91 _EIP+0x91 0090 Before first symbol Code; 000a Before first symbol a: be 00 e0 ff ffmov$0xe000,%esi Code; 000e Before first symbol f: 21 e6 and%esp,%esi Code; 0010 Before first symbol 11: 83 be 54 00 00 00 00 cmpl $0x0,0x54(%esi) Je crois que j'ai un peu de peine avec l'assembleur :) moi non plus, mais c'est pas grave, le Call Trace est deja tres informatif, meme en fait la premiere ligne 1Unable to handle kernel paging request at virtual address 10627759 est tres informative: c'est bien la VM qui aurait du etre capable de trouver une page memoire (c'est son boulot), et le Call Trace indique dans quel appel systeme cette famine c'est passee. un stat64, soit l'appel systeme pour avoir le contenu d'un repertoire ou les metadata d'un fichier (sauf erreur), lui meme declanche par netscrap. -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
http://www.uwsg.indiana.edu/hypermail/linux/kernel/0201.2/0395.html rapide historique de la VM sous 2.4 -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Thu, Jan 17, 2002 at 10:04:36PM +0100, Francois Deppierraz wrote: On Thu, Jan 17, 2002 at 01:42:41PM +0100, Slava Zimine wrote: Est-ce qu'il y a des gens ici qui ont eu des problemes serieux avec 2.4.x sur les serveur sous des stress importants? J'ai pas (encore ?) eu de problèmes sur des serveurs mais par contre sur ma station de travail j'ai des trucs de ce genre et des freezes de temps en temps avec 2.4.17. ohh ksymoops is gonna be your friend :)) Unable to handle kernel paging request at virtual address 10627759 printing eip: c01367c0 *pde = Oops: CPU:0 EIP:0010:[c01367c0]Not tainted EFLAGS: 00010202 eax: 10627731 ebx: c5264340 ecx: c18143f0 edx: esi: da473f70 edi: da473fa4 ebp: cb950479 esp: da473f54 ds: 0018 es: 0018 ss: 0018 Process navigator-smoti (pid: 6736, stackpage=da473000) ah netscape. ouai ca peu bien etre un bug de memoire virtuelle :)) Stack: d2c75000 da473fa4 0009 0001 0009 d2c75021 c5264340 d2c7501f 0002 00019b4c c013693a c0136cc5 da472000 da473fa4 0a75b340 bfffe30c c0133f79 da472000 087cbc60 c7085b40 dffeb340 da472000 087cbc60 Call Trace: [c013693a] [c0136cc5] [c0133f79] [c0106c4b] Code: 83 78 28 00 0f 84 87 00 00 00 be 00 e0 ff ff 21 e6 83 be 54 -- Philippe Strauss http://philou.ch/ L'indifférence est le plus grand risque de notre temps, la forme civilisée de la cruauté. -- Zenta Maurina -- -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Fri, Jan 18, 2002 at 01:54:39PM +0100, Philippe Strauss wrote: ohh ksymoops is gonna be your friend :)) Jan 17 21:29:45 gollum kernel: 1Unable to handle kernel paging request at virtual address 10627759 Jan 17 21:29:45 gollum kernel: c01367c0 Jan 17 21:29:45 gollum kernel: *pde = Jan 17 21:29:45 gollum kernel: Oops: Jan 17 21:29:45 gollum kernel: CPU:0 Jan 17 21:29:45 gollum kernel: EIP:0010:[link_path_walk+1408/1760] Not tainted Jan 17 21:29:45 gollum kernel: EFLAGS: 00010202 Jan 17 21:29:45 gollum kernel: eax: 10627731 ebx: c5264340 ecx: c18143f0 edx: Jan 17 21:29:45 gollum kernel: esi: c63d7f70 edi: c63d7fa4 ebp: cb950479 esp: c63d7f54 Jan 17 21:29:45 gollum kernel: ds: 0018 es: 0018 ss: 0018 Jan 17 21:29:45 gollum kernel: Process navigator-smoti (pid: 7018, stackpage=c63d7000) Jan 17 21:29:45 gollum kernel: Stack: d6a9c000 c63d7fa4 0009 0001 0009 d6a9c021 c5264340 Jan 17 21:29:45 gollum kernel:d6a9c01f 0002 00019b4c c013693a c0136cc5 c63d6000 c63d7fa4 08f9a8c0 Jan 17 21:29:45 gollum kernel:bfffe30c c0133f79 c63d6000 087cbc60 c7085b40 dffeb340 c63d6000 087cbc60 Jan 17 21:29:45 gollum kernel: Call Trace: [path_walk+26/32] [__user_walk+53/80] [sys_stat64+25/112] [system_call+51/56] Jan 17 21:29:45 gollum kernel: Code: 83 78 28 00 0f 84 87 00 00 00 be 00 e0 ff ff 21 e6 83 be 54 Code; Before first symbol _EIP: Code; Before first symbol 0: 83 78 28 00 cmpl $0x0,0x28(%eax) Code; 0004 Before first symbol 4: 0f 84 87 00 00 00 je 91 _EIP+0x91 0090 Before first symbol Code; 000a Before first symbol a: be 00 e0 ff ffmov$0xe000,%esi Code; 000e Before first symbol f: 21 e6 and%esp,%esi Code; 0010 Before first symbol 11: 83 be 54 00 00 00 00 cmpl $0x0,0x54(%esi) Je crois que j'ai un peu de peine avec l'assembleur :) -- Francois Deppierraz [EMAIL PROTECTED] Nimag Networks Sàrl - www.nimag.net PGP Key ID: 9D283BC9 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Fri, Jan 18, 2002 at 03:30:14PM +0100, Marc SCHAEFER wrote: Une moins efficace VM (2.4.9-pristine) vaut mieux que deux VM de m*rde (= 2.4.10-pristine). Houla, plus ça va plus je me dis que mon futur kernel s'appellera plutôt /bsd... -- Francois Deppierraz [EMAIL PROTECTED] Nimag Networks Sàrl - www.nimag.net PGP Key ID: 9D283BC9 -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
Vendredi 17 janvier 2002 François Depierraz a écrit: On Fri, Jan 18, 2002 at 03:30:14PM +0100, Marc SCHAEFER wrote: Une moins efficace VM (2.4.9-pristine) vaut mieux que deux VM de m*rde (= 2.4.10-pristine). Houla, plus ça va plus je me dis que mon futur kernel s'appellera plutôt /bsd... L'idée n'est peut-être pas mauvaise, mais je peux témoigner: - que mon pc au travail tourne le kernel 2.4.3 sans problème depuis le 28 juin 2001 (les arrêts ne sont que des changements de hardware) - que mon portable à la maison tourne le kernel 2.4.9 depuis le 18 novembre sans problème non plus Cela ne veut pas dire qu'il n'y a pas de problèmes, car je ne fais pas de gros calculs, vit avec 512/256 MB de mémoire ... Ce ne sont que des kernels redhat non patchés par moi. (celui que j'ai patché pour un test d'une tablette graphique a bien fonctionné mais ne m'est plus nécessaire). Je dois aussi dire que je n'ai pas entendu de drames à l'EPFL, mais nous n'avons pas pour habitude d'upgrader des serveurs qui fonctionnent. Un de nos serveurs (peu stressé) a un uptime de 221 jours (2.4.2) Anne -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Kernel 2.4 The kernel of pain? slashdot article
Une article et une discussion sur slashdot http://slashdot.org/articles/02/01/17/0240242.shtml http://www.linuxworld.com/site-stories/2002/0114.kernel.html l'article Est-ce qu'il y a des gens ici qui ont eu des problemes serieux avec 2.4.x sur les serveur sous des stress importants? Je n'ai rien a dire de particulier a propos de ma home machine qui run 2.4.4 standard de suse 7.2 bp de daemons, tomcat, apache, mysql mais le load n'est pas important. Jamais eu des system freeze. Regards, Slava -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.
Re: Kernel 2.4 The kernel of pain? slashdot article
On Thu, 17 Jan 2002, Slava Zimine wrote: Est-ce qu'il y a des gens ici qui ont eu des problemes serieux avec 2.4.x sur les serveur sous des stress importants? En 2.4.9 sur une machine parfois assez chargée (indexation de deux ans de la hiérarchie fr.* par exemple :-) avec un style de travaux plutôt `batch' (à opposer à une utilisation interactive, ou WWW avec plein de serveurs/servlets et autres), j'ai remarqué: - une tendance à swapper plus que `normale'. - une tendance à une interactivité plus que moyenne par contre, pas de comportement finalement dérangeant: l'augmentation du swap est relativement modérée et le temps user-space reste bon. Avec deux processus I/O intensifs en fonction (dans ce cas un benchmark Bonnie++, pas une indexation), c'est déjà beaucoup moins bien. Exemples de graphes en fonctionnement: http://www-internal.alphanet.ch/~schaefer/some_files/temp/search/ mais jamais de freeze, crashs ou de OOM (ok, machine avec 640 MB de mémoire, swap 2 GB). Je n'ai pas encore essayé avec la nouvelle VM (dès 2.4.10) car jusqu'en 2.4.15 c'était assez inutilisable AFAIK. J'essaierai 2.4.17 à l'occasion, mais pour l'instant rien ne m'y pousse. NB: dans tous les cas lorsque je donne une version de kernel il s'agit d'une versiond de base sans patches concernant la VM ou le scheduling. -- http://www-internal.alphanet.ch/linux-leman/ avant de poser une question. Ouais, pour se désabonner aussi.