j'en peux plus, =E7a fait deux jours que je suis sur ce probl=E8me, et en p=
lus,=20
c'est m=EAme pas pour moi !!
J'administre plusieurs Gentoo =E0 distance pour divers usage.=20
Sur l'une d'entre-elles, j'ai le probl=E8me suivant :
le lancement de kopete indique qu'il ne trouve pas la librairie
/usr/lib/kde3/kcm_kopete_accountconfig.so=20
Effectivement, ce fichier n'existe pas.
Comme souvent avec les outils KDE, cette biblioth=E8que n'est pas li=E9e de=
fa=E7on=20
standard =E0 kopete : 'ldd $(which kopete)' ne liste pas=20
kcm_kopete_accountconfig.so dans ses d=E9pendances. J'imagine que c'est un=
=20
'dlopen()' qui est utilis=E9. Bref.
L=E0, je fais un 'ls /usr/lib/kde3', et je vois entre-autres un=20
'/usr/lib/kde3/kcm_kopete_accountconfig.la'. Premi=E8re question qu'est ce =
que=20
c'est que ce truc ? Un '.la' ?
J'avais jamais vu. Les premi=E8res lignes de ce fichier indique que =E7a pe=
rmet de=20
lier...
Mais surtout, surtout, je cherche =E0 savoir qui a install=E9 ce fichier (e=
t =E0=20
oubli=E9 au passage le .so...) donc :
Et l=E0 : aucune r=E9ponse !! Aucun ebuild n'a install=E9 ce fichier.
J'ai d=E9j=E0 fait des emerge unmerge kdenetwork ; emerge kdenetwork, rien =
=E0=20
faire.
J'y comprends rien ! D'autant que sur les autres b=E9canes, kopete fonction=
ne=20
sans ce fichier, du moins pas =E0 cet endroit (ils sont=20
dans /usr/kde/3.x/lib/*, pas dans /usr/lib/kde3). Alors si vous avez une=20
id=E9e, je suis preneur, parceque c'est le genre de probl=E8me que je ne su=
pporte=20
pas sur la gentoo, et il y en a beaucoup !=20
En particulier, il est quasi impossible de faire des emerge -uD world dans =
une=20
crontab, principalement =E0 cause des messages d'erreurs (manipulations =E0=
=20
r=E9aliser au fur et =E0 mesure), ou des probl=E8mes de slots... (kde-3.1, =
3.2,=20
3.3, bient=F4t, il y en aura 20...).
J'adore la gentoo, mais il me semble qu'il manque des m=E9thodes de tests p=
our=20
assurer la fiabilit=E9 des upgrades !
Bref, je suis un peu d=E9sesp=E9r=E9 ! 2 jours... A l'aide !=20
http://tdegreni.free.fr/gentoo/portlog-info (ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf, pour activer les logs détaillés par ebuild)
Ici, le script ne quittait pas après l'affichage du message d'aide obtenu par -h (seulement en cas d'option inconnue), et mes variables dans /etc/make.conf sont entourées de doubles quotes : PORTLOG_DIR="/var/log/portage", ce qui ne plaisait pas.
Donc voila un patch attaché qui devrait corriger ces 2 problèmes.
ps: sed c'est pas mon truc mais bon ça a l'air de faire ce que je veux.
# Change this if you want to force PORT_LOGDIR -PORT_LOGDIR="`sed -n 's:^PORT_LOGDIR=::p' /etc/make.conf`" +PORT_LOGDIR="`sed -n '/^PORT_LOGDIR=/ { s/PORT_LOGDIR=// ; s/"//g ; p }' /etc/make.conf`"
############################################################################### # Checks and warnings @@ -186,6 +186,7 @@ if [ -n "${usageerror}" ]; then exit 1 fi + exit 0 }
http://tdegreni.free.fr/gentoo/portlog-info
(ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf,
pour activer les logs détaillés par ebuild)
Ici, le script ne quittait pas après l'affichage du message d'aide
obtenu par -h (seulement en cas d'option inconnue), et mes variables
dans /etc/make.conf sont entourées de doubles quotes :
PORTLOG_DIR="/var/log/portage", ce qui ne plaisait pas.
Donc voila un patch attaché qui devrait corriger ces 2 problèmes.
ps: sed c'est pas mon truc mais bon ça a l'air de faire ce que je veux.
# Change this if you want to force PORT_LOGDIR
-PORT_LOGDIR="`sed -n 's:^PORT_LOGDIR=::p' /etc/make.conf`"
+PORT_LOGDIR="`sed -n '/^PORT_LOGDIR=/ { s/PORT_LOGDIR=// ; s/"//g ; p }' /etc/make.conf`"
###############################################################################
# Checks and warnings
@@ -186,6 +186,7 @@
if [ -n "${usageerror}" ]; then
exit 1
fi
+ exit 0
}
http://tdegreni.free.fr/gentoo/portlog-info (ça nécessite d'avoir un répertoire PORTLOG_DIR dans make.conf, pour activer les logs détaillés par ebuild)
Ici, le script ne quittait pas après l'affichage du message d'aide obtenu par -h (seulement en cas d'option inconnue), et mes variables dans /etc/make.conf sont entourées de doubles quotes : PORTLOG_DIR="/var/log/portage", ce qui ne plaisait pas.
Donc voila un patch attaché qui devrait corriger ces 2 problèmes.
ps: sed c'est pas mon truc mais bon ça a l'air de faire ce que je veux.
# Change this if you want to force PORT_LOGDIR -PORT_LOGDIR="`sed -n 's:^PORT_LOGDIR=::p' /etc/make.conf`" +PORT_LOGDIR="`sed -n '/^PORT_LOGDIR=/ { s/PORT_LOGDIR=// ; s/"//g ; p }' /etc/make.conf`"
############################################################################### # Checks and warnings @@ -186,6 +186,7 @@ if [ -n "${usageerror}" ]; then exit 1 fi + exit 0 }
-- mailing list --------------030904020303030803050605--
Thomas de Grenier de Latour
On Wed, 02 Feb 2005 16:04:54 +0100 Yoann Pannier wrote:
Ici, le script ne quittait pas après l'affichage du message d'aide obtenu par -h (seulement en cas d'option inconnue), et mes variables dans /etc/make.conf sont entourées de doubles quotes : PORTLOG_DIR="/var/log/portage", ce qui ne plaisait pas.
o/ Premier bug report depuis facile 1 an que cette infamie traine à droite à gauche :)
Pour le coup du PORT_LOGDIR avec les quotes, j'ai en fait remplacé le sed fautif par un "$(/usr/lib/portage/bin/portageq envvar PORT_LOGDIR)", ça sera plus propre. Et pour le "exit 0" qui manquait, en fait je viens de voir que la version en ligne était pas la dernière que j'avais faite, où c'était justement corrigé (la seule autre différence étant que la dernière affiche aussi la taille du fichier de log apparemment, enfin c'est ce que je comprends de mon diff...). J'upload donc une nouvelle version ! Je pensais pas que ça arriverait un jour :)
Merci à toi,
-- TGL.
-- mailing list
On Wed, 02 Feb 2005 16:04:54 +0100
Yoann Pannier <gentoo-user-fr@umsar.org> wrote:
Ici, le script ne quittait pas après l'affichage du message
d'aide obtenu par -h (seulement en cas d'option inconnue), et
mes variables dans /etc/make.conf sont entourées de doubles
quotes : PORTLOG_DIR="/var/log/portage", ce qui ne plaisait pas.
o/ Premier bug report depuis facile 1 an que cette infamie
traine
à droite à gauche :)
Pour le coup du PORT_LOGDIR avec les quotes, j'ai en fait remplacé
le sed fautif par un "$(/usr/lib/portage/bin/portageq envvar
PORT_LOGDIR)", ça sera plus propre. Et pour le "exit 0" qui
manquait, en fait je viens de voir que la version en ligne était
pas la dernière que j'avais faite, où c'était justement corrigé
(la seule autre différence étant que la dernière affiche aussi la
taille du fichier de log apparemment, enfin c'est ce que je
comprends de mon diff...). J'upload donc une nouvelle version !
Je pensais pas que ça arriverait un jour :)
On Wed, 02 Feb 2005 16:04:54 +0100 Yoann Pannier wrote:
Ici, le script ne quittait pas après l'affichage du message d'aide obtenu par -h (seulement en cas d'option inconnue), et mes variables dans /etc/make.conf sont entourées de doubles quotes : PORTLOG_DIR="/var/log/portage", ce qui ne plaisait pas.
o/ Premier bug report depuis facile 1 an que cette infamie traine à droite à gauche :)
Pour le coup du PORT_LOGDIR avec les quotes, j'ai en fait remplacé le sed fautif par un "$(/usr/lib/portage/bin/portageq envvar PORT_LOGDIR)", ça sera plus propre. Et pour le "exit 0" qui manquait, en fait je viens de voir que la version en ligne était pas la dernière que j'avais faite, où c'était justement corrigé (la seule autre différence étant que la dernière affiche aussi la taille du fichier de log apparemment, enfin c'est ce que je comprends de mon diff...). J'upload donc une nouvelle version ! Je pensais pas que ça arriverait un jour :)
Merci à toi,
-- TGL.
-- mailing list
panda
bonjour,
utilisant la version AMD64 x86_64, j'ai eu quelques petits problèmes récement.
Je suis passé il y a quelque temps de gcc 3.3 à 3.4 (avec beaucoup de peine, vu qu'il fallait jouer avec "multilib") Mais j'ai au final réussi.
Et a partir de là kde à commencer à joyeusement planter : KCMinit qui se crashe au démarrage, puis KNotify avec plein d'allégresse (il devait être jaloux je le connaissait pas avant).
Bon,bon,bon, je recompile kde en entier, et en passant les bibliothèques systèmes et quelques autres. Plus de problèmes , KCMinit et KNotify se calment. Par contre maintenant le lecteur multimedia JuK se met à planter ( signal 11 au début, puis signal 6 maintenant), pas de trace lisible ( c'est ce que dit monsieur Backtrace) Bon, tant pis je prend xmms, mais là le sons est très mauvais , avec des bruits de brouillages radio. J'essaye donc amarok, qui marche très bien ... pendant 10 minutes. Maintenant il crashe quand j'essaye de lire un fichier mp3, et lors de la fermeture monsieur "The KDE Crash Handler" me dit que c'est un signal 11, pas de trace lisible non plus.
Je regarde dans /var/log/message et là je trouve un message qui revient à répétition :
5 16:06:55 alpha Hangcheck: hangcheck value past margin!
avec celui-ci de temps en temps
Feb 5 16:12:50 alpha warning: many lost ticks. Feb 5 16:12:50 alpha Your time source seems to be instable or some driver is hogging interupts Feb 5 16:12:50 alpha rip default_idle+0x20/0x30
quelqu'un à une idée ?
Pour le système il s'agit d'un 2.6.9-gentoo-r14 sur opteron 242 avec 1G de mémoire.
Si vous voulez des info quelqu'on dites le moi (lspci, option noyaux ... etc)
meci d'avance
Gabriel
-- mailing list
bonjour,
utilisant la version AMD64 x86_64, j'ai eu quelques petits problèmes
récement.
Je suis passé il y a quelque temps de gcc 3.3 à 3.4 (avec beaucoup de
peine, vu qu'il fallait jouer avec "multilib")
Mais j'ai au final réussi.
Et a partir de là kde à commencer à joyeusement planter : KCMinit qui
se crashe au démarrage, puis KNotify avec plein d'allégresse (il devait
être jaloux je le connaissait pas avant).
Bon,bon,bon, je recompile kde en entier, et en passant les bibliothèques
systèmes et quelques autres.
Plus de problèmes , KCMinit et KNotify se calment.
Par contre maintenant le lecteur multimedia JuK se met à planter (
signal 11 au début, puis signal 6 maintenant), pas de trace lisible (
c'est ce que dit monsieur Backtrace)
Bon, tant pis je prend xmms, mais là le sons est très mauvais , avec des
bruits de brouillages radio.
J'essaye donc amarok, qui marche très bien ... pendant 10 minutes.
Maintenant il crashe quand j'essaye de lire un fichier mp3, et lors de
la fermeture monsieur "The KDE Crash Handler" me dit que c'est un signal
11, pas de trace lisible non plus.
Je regarde dans /var/log/message
et là je trouve un message qui revient à répétition :
5 16:06:55 alpha Hangcheck: hangcheck value past margin!
avec celui-ci de temps en temps
Feb 5 16:12:50 alpha warning: many lost ticks.
Feb 5 16:12:50 alpha Your time source seems to be instable or some
driver is hogging interupts
Feb 5 16:12:50 alpha rip default_idle+0x20/0x30
quelqu'un à une idée ?
Pour le système il s'agit d'un 2.6.9-gentoo-r14 sur opteron 242 avec 1G
de mémoire.
Si vous voulez des info quelqu'on dites le moi (lspci, option noyaux ...
etc)
utilisant la version AMD64 x86_64, j'ai eu quelques petits problèmes récement.
Je suis passé il y a quelque temps de gcc 3.3 à 3.4 (avec beaucoup de peine, vu qu'il fallait jouer avec "multilib") Mais j'ai au final réussi.
Et a partir de là kde à commencer à joyeusement planter : KCMinit qui se crashe au démarrage, puis KNotify avec plein d'allégresse (il devait être jaloux je le connaissait pas avant).
Bon,bon,bon, je recompile kde en entier, et en passant les bibliothèques systèmes et quelques autres. Plus de problèmes , KCMinit et KNotify se calment. Par contre maintenant le lecteur multimedia JuK se met à planter ( signal 11 au début, puis signal 6 maintenant), pas de trace lisible ( c'est ce que dit monsieur Backtrace) Bon, tant pis je prend xmms, mais là le sons est très mauvais , avec des bruits de brouillages radio. J'essaye donc amarok, qui marche très bien ... pendant 10 minutes. Maintenant il crashe quand j'essaye de lire un fichier mp3, et lors de la fermeture monsieur "The KDE Crash Handler" me dit que c'est un signal 11, pas de trace lisible non plus.
Je regarde dans /var/log/message et là je trouve un message qui revient à répétition :
5 16:06:55 alpha Hangcheck: hangcheck value past margin!
avec celui-ci de temps en temps
Feb 5 16:12:50 alpha warning: many lost ticks. Feb 5 16:12:50 alpha Your time source seems to be instable or some driver is hogging interupts Feb 5 16:12:50 alpha rip default_idle+0x20/0x30
quelqu'un à une idée ?
Pour le système il s'agit d'un 2.6.9-gentoo-r14 sur opteron 242 avec 1G de mémoire.
Si vous voulez des info quelqu'on dites le moi (lspci, option noyaux ... etc)
meci d'avance
Gabriel
-- mailing list
cedcox
Pierre Vignéras wrote:
Oui, je ne dis pas que les outils ne font pas bien ce qu'ils sont censés faire (ou si je l'ai dit, ce n'est pas ce que je voulais dire, enfin bref), mais qu'il manque manifestement quelquechose pour qu'un upgrade se passe bien, sans heurts.
Au dernière nouvelles, mplayer et imlib ne compile plus (problème avec gif, de mémoire). Et ça, je trouve que pour une distrib supposé stable (pas de ~x86), c'est qu'il y a un truc qui cloche !! Je ne sais pas quoi, mais ce n'est pas le comportement que j'attends d'une distrib dite stable !
Pire, j'ai recommandé à un pote d'utiliser la Gentoo, parce que pour apprendre, on voit tout de suite ce qu'il se passe ! Mais d'un autre côté quand un emerge ne termine pas (alors que c'est l'outil de base du système, sinon à quoi bon une distrib, un LFS suffit), je trouve que cela manque de sérieux. D'où les tests dont je parlais...
Bon, malgré tout, j'administre 4 bécanes dont un serveur LTSP, le tout à distance, c'est donc que je lui fait un peu confiance à la gentoo quand même.
C'est tout à fait vrai. Cela fait très longtemps (plus de 2 ans je crois) que j'utilise la gentoo, et avant je n'avais pas problème avec un emerge -u world dans une crontab. Les problèmes étaient très très très rares. mais depuis quelques mois ils sont de plus en plus présents et j'ai l'impression qu'en ce moment il n'y a pas une mise à jour sans problème. Il suffit de voir la misère avec automake, ces X versions d'installées (1.7.9-r1 1.8.5-r3 1.5 1.4_p6 1.6.3 1.9.4). Le nombre de problèmes reportés sur le forum à cause de ça. Alors il propose des solutions où il faut modifier l'ebuild mais si à chaque rsync il faut refaire tous les ebuilds que l'on a déjà modifiés, on ne s'en sort plus.
Je pense tout simplement que la gentoo est victime de son succès et que les developpeurs font maitenant passer en priorité la vitesse de la mise en place en stable plutôt que la qualité de l'ebuild stable.
De plus, il serait plus important à mon avis de corriger les bugs existants avant de vouloir faire passer les ~x86 en x86. Il suffit pour ça de voir le nombre de bugs existant depuis des mois et qui sont tombés dans les oubliettes. Cela donne l'impression que les dev croisent les doigts en ésperant que les bugs auront disparus avec la version supérieure.
Moi aussi je conseillais la gentoo au débutant car il n'avait jamais de problèmes avant, mais là je pense que je vais être de nouveau obligé de les rediriger vers une distrib plus usine à gaz comme Mandrake avant de les ramener vers gentoo (si elle ne continue pas d'empirer). Dommage...
Moi même, en tant qu'administrateur, je n'ai pas toute ma journée à passer à corriger les problèmes de compilations sur les machines gentoo même avec un serveur rsync local sachant qu'elles ont chacune un rôle particulier donc des outils et des applis différents. Qu'il y'ai des problèmes de temps en temps, ca peut arriver, mais quand c'est tout le temps, c'est que la distrib n'est plus fiable ni stable.
J'éspère que la gentoo reviendra assez rapidement dans le droit chemin de la stabilité et de la simplicité dont on était habitué...
ced
-- mailing list
Pierre Vignéras wrote:
Oui, je ne dis pas que les outils ne font pas bien ce qu'ils sont censés faire
(ou si je l'ai dit, ce n'est pas ce que je voulais dire, enfin bref), mais
qu'il manque manifestement quelquechose pour qu'un upgrade se passe bien,
sans heurts.
Au dernière nouvelles, mplayer et imlib ne compile plus (problème avec gif, de
mémoire). Et ça, je trouve que pour une distrib supposé stable (pas de ~x86),
c'est qu'il y a un truc qui cloche !! Je ne sais pas quoi, mais ce n'est pas
le comportement que j'attends d'une distrib dite stable !
Pire, j'ai recommandé à un pote d'utiliser la Gentoo, parce que pour
apprendre, on voit tout de suite ce qu'il se passe ! Mais d'un autre côté
quand un emerge ne termine pas (alors que c'est l'outil de base du système,
sinon à quoi bon une distrib, un LFS suffit), je trouve que cela manque de
sérieux. D'où les tests dont je parlais...
Bon, malgré tout, j'administre 4 bécanes dont un serveur LTSP, le tout à
distance, c'est donc que je lui fait un peu confiance à la gentoo quand même.
C'est tout à fait vrai. Cela fait très longtemps (plus de 2 ans je
crois) que j'utilise la gentoo, et avant je n'avais pas problème avec un
emerge -u world dans une crontab. Les problèmes étaient très très très
rares. mais depuis quelques mois ils sont de plus en plus présents et
j'ai l'impression qu'en ce moment il n'y a pas une mise à jour sans
problème. Il suffit de voir la misère avec automake, ces X versions
d'installées (1.7.9-r1 1.8.5-r3 1.5 1.4_p6 1.6.3 1.9.4). Le nombre de
problèmes reportés sur le forum à cause de ça. Alors il propose des
solutions où il faut modifier l'ebuild mais si à chaque rsync il faut
refaire tous les ebuilds que l'on a déjà modifiés, on ne s'en sort plus.
Je pense tout simplement que la gentoo est victime de son succès et que
les developpeurs font maitenant passer en priorité la vitesse de la mise
en place en stable plutôt que la qualité de l'ebuild stable.
De plus, il serait plus important à mon avis de corriger les bugs
existants avant de vouloir faire passer les ~x86 en x86. Il suffit pour
ça de voir le nombre de bugs existant depuis des mois et qui sont tombés
dans les oubliettes. Cela donne l'impression que les dev croisent les
doigts en ésperant que les bugs auront disparus avec la version supérieure.
Moi aussi je conseillais la gentoo au débutant car il n'avait jamais de
problèmes avant, mais là je pense que je vais être de nouveau obligé de
les rediriger vers une distrib plus usine à gaz comme Mandrake avant de
les ramener vers gentoo (si elle ne continue pas d'empirer). Dommage...
Moi même, en tant qu'administrateur, je n'ai pas toute ma journée à
passer à corriger les problèmes de compilations sur les machines gentoo
même avec un serveur rsync local sachant qu'elles ont chacune un rôle
particulier donc des outils et des applis différents. Qu'il y'ai des
problèmes de temps en temps, ca peut arriver, mais quand c'est tout le
temps, c'est que la distrib n'est plus fiable ni stable.
J'éspère que la gentoo reviendra assez rapidement dans le droit chemin
de la stabilité et de la simplicité dont on était habitué...
Oui, je ne dis pas que les outils ne font pas bien ce qu'ils sont censés faire (ou si je l'ai dit, ce n'est pas ce que je voulais dire, enfin bref), mais qu'il manque manifestement quelquechose pour qu'un upgrade se passe bien, sans heurts.
Au dernière nouvelles, mplayer et imlib ne compile plus (problème avec gif, de mémoire). Et ça, je trouve que pour une distrib supposé stable (pas de ~x86), c'est qu'il y a un truc qui cloche !! Je ne sais pas quoi, mais ce n'est pas le comportement que j'attends d'une distrib dite stable !
Pire, j'ai recommandé à un pote d'utiliser la Gentoo, parce que pour apprendre, on voit tout de suite ce qu'il se passe ! Mais d'un autre côté quand un emerge ne termine pas (alors que c'est l'outil de base du système, sinon à quoi bon une distrib, un LFS suffit), je trouve que cela manque de sérieux. D'où les tests dont je parlais...
Bon, malgré tout, j'administre 4 bécanes dont un serveur LTSP, le tout à distance, c'est donc que je lui fait un peu confiance à la gentoo quand même.
C'est tout à fait vrai. Cela fait très longtemps (plus de 2 ans je crois) que j'utilise la gentoo, et avant je n'avais pas problème avec un emerge -u world dans une crontab. Les problèmes étaient très très très rares. mais depuis quelques mois ils sont de plus en plus présents et j'ai l'impression qu'en ce moment il n'y a pas une mise à jour sans problème. Il suffit de voir la misère avec automake, ces X versions d'installées (1.7.9-r1 1.8.5-r3 1.5 1.4_p6 1.6.3 1.9.4). Le nombre de problèmes reportés sur le forum à cause de ça. Alors il propose des solutions où il faut modifier l'ebuild mais si à chaque rsync il faut refaire tous les ebuilds que l'on a déjà modifiés, on ne s'en sort plus.
Je pense tout simplement que la gentoo est victime de son succès et que les developpeurs font maitenant passer en priorité la vitesse de la mise en place en stable plutôt que la qualité de l'ebuild stable.
De plus, il serait plus important à mon avis de corriger les bugs existants avant de vouloir faire passer les ~x86 en x86. Il suffit pour ça de voir le nombre de bugs existant depuis des mois et qui sont tombés dans les oubliettes. Cela donne l'impression que les dev croisent les doigts en ésperant que les bugs auront disparus avec la version supérieure.
Moi aussi je conseillais la gentoo au débutant car il n'avait jamais de problèmes avant, mais là je pense que je vais être de nouveau obligé de les rediriger vers une distrib plus usine à gaz comme Mandrake avant de les ramener vers gentoo (si elle ne continue pas d'empirer). Dommage...
Moi même, en tant qu'administrateur, je n'ai pas toute ma journée à passer à corriger les problèmes de compilations sur les machines gentoo même avec un serveur rsync local sachant qu'elles ont chacune un rôle particulier donc des outils et des applis différents. Qu'il y'ai des problèmes de temps en temps, ca peut arriver, mais quand c'est tout le temps, c'est que la distrib n'est plus fiable ni stable.
J'éspère que la gentoo reviendra assez rapidement dans le droit chemin de la stabilité et de la simplicité dont on était habitué...
ced
-- mailing list
Carmine Chiancone
je ne connais pas l'architecture AMD64, et donc ce que je vais dire e st peut-être tout faux, mais je pense que le problème:
Feb 5 16:12:50 alpha warning: many lost ticks. Feb 5 16:12:50 alpha Your time source seems to be instable or some driver is hogging interupts Feb 5 16:12:50 alpha rip default_idle+0x20/0x30
provient d'une mauvaise configuration du noyau au niveau des "Device Drivers" et/ou "Processor type and features"
Il y a un forum gentoo spécialisé pour AMD64, là:
http://forums.gentoo.org/viewforum.php?fF
et cette discussion semble parler de ce problème:
http://forums.gentoo.org/viewtopic.php?t1716
(mais encore une fois, ce que je dis là est peut-être tout faux).
-- mailing list
je ne connais pas l'architecture AMD64, et donc ce que je vais dire e st
peut-être tout faux, mais je pense que le problème:
Feb 5 16:12:50 alpha warning: many lost ticks.
Feb 5 16:12:50 alpha Your time source seems to be instable or some driver
is hogging interupts
Feb 5 16:12:50 alpha rip default_idle+0x20/0x30
provient d'une mauvaise configuration du noyau au niveau des "Device
Drivers" et/ou "Processor type and features"
Il y a un forum gentoo spécialisé pour AMD64, là:
http://forums.gentoo.org/viewforum.php?f=46
et cette discussion semble parler de ce problème:
http://forums.gentoo.org/viewtopic.php?t=191716
(mais encore une fois, ce que je dis là est peut-être tout faux).
je ne connais pas l'architecture AMD64, et donc ce que je vais dire e st peut-être tout faux, mais je pense que le problème:
Feb 5 16:12:50 alpha warning: many lost ticks. Feb 5 16:12:50 alpha Your time source seems to be instable or some driver is hogging interupts Feb 5 16:12:50 alpha rip default_idle+0x20/0x30
provient d'une mauvaise configuration du noyau au niveau des "Device Drivers" et/ou "Processor type and features"
Il y a un forum gentoo spécialisé pour AMD64, là:
http://forums.gentoo.org/viewforum.php?fF
et cette discussion semble parler de ce problème:
http://forums.gentoo.org/viewtopic.php?t1716
(mais encore une fois, ce que je dis là est peut-être tout faux).
