[FreeBSD 6-B1] impressions de compilation + message à l'arrêt
8 réponses
gregg
Bonjour,
Je viens d'installer la 6 beta-1 (via ftp, il manque quelques
paquetages, que j'ai recompilés).
J'ai l'impression que la compilation des paquetages, justement, prend
plus longtemps. (J'ai bien sûr désactivé les options de débogage idoines
dans le noyau).
Par exemple, la compilation du jdk 1.5 a pris à peu près 3h30 là où elle
n'en prend "que" 2h50, voire 3h, avec la série 5 (notamment STABLE).
Il s'agit de la même machine.
Est-ce seulement de mon côté (j'ai laissé traîner un truc ?), ou
certains d'entre vous l'ont-ils remarqué aussi ?
Sinon, j'ai systématiquement le message:
"unmount of devfs failed: [BUSY]"
lors de l'extinction. C'est la première fois que ça m'arrive.
(Damned, ils ont enlevé le menu "daemon" du démarrage de noyau ??)
Sinon, j'ai systématiquement le message: "unmount of devfs failed: [BUSY]" lors de l'extinction. C'est la première fois que ça m'arrive.
C'est "/DEV", et non devfs (qui est un article que je suis en train de lire :-( j'ai probablement besoin de sommeil :-P
++
F. Senault
Est-ce seulement de mon côté (j'ai laissé traîner un truc ?), ou certains d'entre vous l'ont-ils remarqué aussi ?
Si je ne me trompe, les options de compilation par défaut sont passées de -O à -O2 - en d'autres mots, les optimisations à la compilation ont grimpé d'un cran, ce qui fait perdre en temps de compilation, mais devrait faire gagner en vitesse d'exécution.
Pour être certain de ça, jette un oeil au man de make.conf(5) ou au fichier /usr/share/examples/etc/make.conf.
Sinon, j'ai systématiquement le message: "unmount of devfs failed: [BUSY]" lors de l'extinction. C'est la première fois que ça m'arrive.
C'est un problème connu, je pense. Je ne sais pas si ça a été réssolu depuis la beta 1, par contre.
(Damned, ils ont enlevé le menu "daemon" du démarrage de noyau ??)
Aucune idée, là. Tout ce que je peux dire, c'est que je l'enlève systématiquement, personnellement, mais bon... :)
Fred -- Now all we need is a unified field theory that allows quantum LARTING. (Random, in the SDM)
Est-ce seulement de mon côté (j'ai laissé traîner un truc ?), ou
certains d'entre vous l'ont-ils remarqué aussi ?
Si je ne me trompe, les options de compilation par défaut sont passées
de -O à -O2 - en d'autres mots, les optimisations à la compilation ont
grimpé d'un cran, ce qui fait perdre en temps de compilation, mais
devrait faire gagner en vitesse d'exécution.
Pour être certain de ça, jette un oeil au man de make.conf(5) ou au
fichier /usr/share/examples/etc/make.conf.
Sinon, j'ai systématiquement le message:
"unmount of devfs failed: [BUSY]"
lors de l'extinction. C'est la première fois que ça m'arrive.
C'est un problème connu, je pense. Je ne sais pas si ça a été réssolu
depuis la beta 1, par contre.
(Damned, ils ont enlevé le menu "daemon" du démarrage de noyau ??)
Aucune idée, là. Tout ce que je peux dire, c'est que je l'enlève
systématiquement, personnellement, mais bon... :)
Fred
--
Now all we need is a unified field theory that allows quantum LARTING.
(Random, in the SDM)
Est-ce seulement de mon côté (j'ai laissé traîner un truc ?), ou certains d'entre vous l'ont-ils remarqué aussi ?
Si je ne me trompe, les options de compilation par défaut sont passées de -O à -O2 - en d'autres mots, les optimisations à la compilation ont grimpé d'un cran, ce qui fait perdre en temps de compilation, mais devrait faire gagner en vitesse d'exécution.
Pour être certain de ça, jette un oeil au man de make.conf(5) ou au fichier /usr/share/examples/etc/make.conf.
Sinon, j'ai systématiquement le message: "unmount of devfs failed: [BUSY]" lors de l'extinction. C'est la première fois que ça m'arrive.
C'est un problème connu, je pense. Je ne sais pas si ça a été réssolu depuis la beta 1, par contre.
(Damned, ils ont enlevé le menu "daemon" du démarrage de noyau ??)
Aucune idée, là. Tout ce que je peux dire, c'est que je l'enlève systématiquement, personnellement, mais bon... :)
Fred -- Now all we need is a unified field theory that allows quantum LARTING. (Random, in the SDM)
Laurent Lefevre
Patrick Lamaizière writes:
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
-- Laurent
Patrick Lamaizière <adresse@est.invalid> writes:
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
-- Laurent
F. Senault
Patrick Lamaizière writes:
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
Ca m'étonnerait très fort. Tu veux peut-être dire loader.conf, voire loader.rc ?
Fred -- - "Cargo Plane/Truck Carrying Entire Usenet Archive Crashes In Freak Storm/Freak Traffic Accident" - Near the crash site, a discarded rocket launcher was found, with a note attached: "X-No-Archive: YES, FUCKING YES YES YES" (Bruce Tomlin & Juergen Nieveler in the SDM)
Patrick Lamaizière <adresse@est.invalid> writes:
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
Ca m'étonnerait très fort. Tu veux peut-être dire loader.conf, voire
loader.rc ?
Fred
--
- "Cargo Plane/Truck Carrying Entire Usenet Archive Crashes In Freak
Storm/Freak Traffic Accident" - Near the crash site, a discarded rocket
launcher was found, with a note attached: "X-No-Archive: YES, FUCKING
YES YES YES" (Bruce Tomlin & Juergen Nieveler in the SDM)
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
Ca m'étonnerait très fort. Tu veux peut-être dire loader.conf, voire loader.rc ?
Fred -- - "Cargo Plane/Truck Carrying Entire Usenet Archive Crashes In Freak Storm/Freak Traffic Accident" - Near the crash site, a discarded rocket launcher was found, with a note attached: "X-No-Archive: YES, FUCKING YES YES YES" (Bruce Tomlin & Juergen Nieveler in the SDM)
Laurent Lefevre
"F. Senault" writes:
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
Ca m'étonnerait très fort. Tu veux peut-être dire loader.conf, voire loader.rc ?
Oui, c'est dans loader.conf. En plus, au demarrage, ca ne peut p[as etre rc.conf, m'enfin....
-- Laurent
"F. Senault" <fred@lacave.net> writes:
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
Ca m'étonnerait très fort. Tu veux peut-être dire loader.conf, voire
loader.rc ?
Oui, c'est dans loader.conf. En plus, au demarrage, ca ne peut p[as
etre rc.conf, m'enfin....
Sinon je n'ai pas trouvé pour rétablir Beastie au boot ? Y'a un moyen ?
C'est une option de rc.conf.
Ca m'étonnerait très fort. Tu veux peut-être dire loader.conf, voire loader.rc ?
Oui, c'est dans loader.conf. En plus, au demarrage, ca ne peut p[as etre rc.conf, m'enfin....
-- Laurent
gregg
F. Senault wrote:
Si je ne me trompe, les options de compilation par défaut sont passées de -O à -O2 - en d'autres mots, les optimisations à la compilation ont grimpé d'un cran, ce qui fait perdre en temps de compilation, mais devrait faire gagner en vitesse d'exécution.
J'ai utilisé un make.conf provenant de ma version précédente ( 5-Stable) Avec les options -O -pipe
Je me demandais s'il y avait des sysctl, peut-être, qui ralentissaient le bazar ?
En tous les cas, l'utilisation CPU est nettement plus importante (en particulier avec FireFox).
Bon, je suis repassé en 5 sur le portable. Je vais utiliser une tour pour la 6...
Merci pour vos indications ! ++
F. Senault wrote:
Si je ne me trompe, les options de compilation par défaut sont passées
de -O à -O2 - en d'autres mots, les optimisations à la compilation ont
grimpé d'un cran, ce qui fait perdre en temps de compilation, mais
devrait faire gagner en vitesse d'exécution.
J'ai utilisé un make.conf provenant de ma version précédente ( 5-Stable)
Avec les options -O -pipe
Je me demandais s'il y avait des sysctl, peut-être, qui ralentissaient
le bazar ?
En tous les cas, l'utilisation CPU est nettement plus importante (en
particulier avec FireFox).
Bon, je suis repassé en 5 sur le portable.
Je vais utiliser une tour pour la 6...
Si je ne me trompe, les options de compilation par défaut sont passées de -O à -O2 - en d'autres mots, les optimisations à la compilation ont grimpé d'un cran, ce qui fait perdre en temps de compilation, mais devrait faire gagner en vitesse d'exécution.
J'ai utilisé un make.conf provenant de ma version précédente ( 5-Stable) Avec les options -O -pipe
Je me demandais s'il y avait des sysctl, peut-être, qui ralentissaient le bazar ?
En tous les cas, l'utilisation CPU est nettement plus importante (en particulier avec FireFox).
Bon, je suis repassé en 5 sur le portable. Je vais utiliser une tour pour la 6...
Merci pour vos indications ! ++
gregg
Xavier wrote:
C'est écrit en MAJUSCULES au début du boot (less /var/run/dmesg.boot)
Ah bon ?! Chez moi ça ne donne (donnait) rien.
Le noyau est compilé par défaut avec des options de debug
Non. Il n'y a pas d'options, ni aucun message. Comme je l'avais précisé dans un précédent message, certes pas en majuscules :-) , je parle d'un noyau recompilé avec les options de débogage désactivées.
Et je me demandais s'il n'y avait pas d'autres indicateurs ailleurs (genre dans un fichier de conf, qui chargerait des sysctl... J'ai regardé, et n'ai pas vu, mais j'avoue que je ne suis pas un spécialiste des sysctl, ou des hints).
Le problème est résolu, je suis repassé en 5-R, et là tout fonctionne très bien, sans surcharge processeur, sans ralentissement lors des compilations de ports, et autres. Des performances correctes, que du bonheur.
C'était juste de la curiosité.
++
Xavier wrote:
C'est écrit en MAJUSCULES au début du boot (less /var/run/dmesg.boot)
Ah bon ?!
Chez moi ça ne donne (donnait) rien.
Le noyau est compilé par défaut avec des options de debug
Non.
Il n'y a pas d'options, ni aucun message.
Comme je l'avais précisé dans un précédent message, certes pas en
majuscules :-) , je parle d'un noyau recompilé avec les options de
débogage désactivées.
Et je me demandais s'il n'y avait pas d'autres indicateurs ailleurs
(genre dans un fichier de conf, qui chargerait des sysctl... J'ai
regardé, et n'ai pas vu, mais j'avoue que je ne suis pas un spécialiste
des sysctl, ou des hints).
Le problème est résolu, je suis repassé en 5-R, et là tout fonctionne
très bien, sans surcharge processeur, sans ralentissement lors des
compilations de ports, et autres.
Des performances correctes, que du bonheur.
C'est écrit en MAJUSCULES au début du boot (less /var/run/dmesg.boot)
Ah bon ?! Chez moi ça ne donne (donnait) rien.
Le noyau est compilé par défaut avec des options de debug
Non. Il n'y a pas d'options, ni aucun message. Comme je l'avais précisé dans un précédent message, certes pas en majuscules :-) , je parle d'un noyau recompilé avec les options de débogage désactivées.
Et je me demandais s'il n'y avait pas d'autres indicateurs ailleurs (genre dans un fichier de conf, qui chargerait des sysctl... J'ai regardé, et n'ai pas vu, mais j'avoue que je ne suis pas un spécialiste des sysctl, ou des hints).
Le problème est résolu, je suis repassé en 5-R, et là tout fonctionne très bien, sans surcharge processeur, sans ralentissement lors des compilations de ports, et autres. Des performances correctes, que du bonheur.
C'était juste de la curiosité.
++
Marc Fonvieille
On Thu, 28 Jul 2005 16:25:34 +0200, gregg wrote:
Xavier wrote:
C'est écrit en MAJUSCULES au début du boot (less /var/run/dmesg.boot)
Ah bon ?! Chez moi ça ne donne (donnait) rien.
Le noyau est compilé par défaut avec des options de debug
Non. Il n'y a pas d'options, ni aucun message. Comme je l'avais précisé dans un précédent message, certes pas en majuscules :-) , je parle d'un noyau recompilé avec les options de débogage désactivées.
Et je me demandais s'il n'y avait pas d'autres indicateurs ailleurs (genre dans un fichier de conf, qui chargerait des sysctl... J'ai regardé, et n'ai pas vu, mais j'avoue que je ne suis pas un spécialiste des sysctl, ou des hints).
[...]
malloc.conf correctement positionné? i.e. ln -s aj /etc/malloc.conf
Marc
On Thu, 28 Jul 2005 16:25:34 +0200, gregg <greggNOSPAMarbage@NOSPAMfree.WANTEDfr> wrote:
Xavier wrote:
C'est écrit en MAJUSCULES au début du boot (less /var/run/dmesg.boot)
Ah bon ?!
Chez moi ça ne donne (donnait) rien.
Le noyau est compilé par défaut avec des options de debug
Non.
Il n'y a pas d'options, ni aucun message.
Comme je l'avais précisé dans un précédent message, certes pas en
majuscules :-) , je parle d'un noyau recompilé avec les options de
débogage désactivées.
Et je me demandais s'il n'y avait pas d'autres indicateurs ailleurs
(genre dans un fichier de conf, qui chargerait des sysctl... J'ai
regardé, et n'ai pas vu, mais j'avoue que je ne suis pas un spécialiste
des sysctl, ou des hints).
[...]
malloc.conf correctement positionné? i.e. ln -s aj /etc/malloc.conf
C'est écrit en MAJUSCULES au début du boot (less /var/run/dmesg.boot)
Ah bon ?! Chez moi ça ne donne (donnait) rien.
Le noyau est compilé par défaut avec des options de debug
Non. Il n'y a pas d'options, ni aucun message. Comme je l'avais précisé dans un précédent message, certes pas en majuscules :-) , je parle d'un noyau recompilé avec les options de débogage désactivées.
Et je me demandais s'il n'y avait pas d'autres indicateurs ailleurs (genre dans un fichier de conf, qui chargerait des sysctl... J'ai regardé, et n'ai pas vu, mais j'avoue que je ne suis pas un spécialiste des sysctl, ou des hints).
[...]
malloc.conf correctement positionné? i.e. ln -s aj /etc/malloc.conf
