Il y' a quelque temps, le sujet du probl=E8me d'horloge avait =E9t=E9 trait=
=E9, pour=20
un portable Nitteo M707 Hyper Threading en ETCH et kernel 2.6.18-3-686.
La commande =AB=A0append=3D"noapic nolapic"=A0=BB dans lilo.conf semblait a=
voir r=E9solu=20
le probl=E8me! En fait le lendemain en allumant mon portable, j'ai eu de=20
nouveau le m=EAme probl=E8me d'horloge! Apr=E8s de nombreuses recherches, j=
'ai pu=20
lire que pour les kernels r=E9cents et notamment le 2.6.18-3-686, la comman=
de=20
=AB=A0append=3D"noapic nolapic"=A0=20
devait =EAtre remplac=E9e par celle-ci :
=AB=A0append=3Ddisable_timer_pin_1=A0=BB
# dmesg
Linux version 2.6.18-3-686 (Debian 2.6.18-7) (waldi@debian.org) (gcc vers=
ion=20
4.1.2 20061115 (prerelease) (Debian 4.1.1-20)) #1 SMP Mon Dec 4 16:41:14 U=
TC=20
2006
[...]
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
SMP mptable: bad signature [0x0]!
BIOS bug, MP table errors detected!...
... disabling SMP support. (tell your hw vendor)
Allocating PCI resources starting at 50000000 (gap: 40000000:bec00000)
Detected 2398.582 MHz processor.
Built 1 zonelists. Total pages: 261616
Kernel command line: auto BOOT_IMAGE=3DLinux ro root=3D301 disable_timer_=
pin_1
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (0180c000)
[...]
Question 1: quelqu'un pourrait-il expliquer comment, cette=20
commande =AB=A0append=3Ddisable_timer_pin_1=BB=A0 agit-elle sur le noyau?=20
pourquoi, d'autres, utilisent-ils aussi =AB=A0append=3D=A0=BBdisable_timer_=
pin_1=3D1=A0=BB?=A0
Question 2: pour pouvoir utiliser l'Hyper Threading, dois-je changer de noy=
au=20
en kernel-image-2.6-686-smp?
Le jeudi 25 janvier 2007 12:10, Jacques L'helgoualc'h a écrit :
wolfgod a écrit, jeudi 25 janvier 2007, à 11:33 : [horloge overcloquée]
> Oui c'est bien ntdate que j'ai installé (sans cron).
Avec ou sans cron, ntpdate est une commande de mise à l'heure, en interrogeant un serveur extérieur.
Tu peux essayer les paquets ntp-server, ou ntp-simple, qui feront tourner un démon de suerveillance de l'horloge ; j'ai eu de meilleurs résultats avec chrony en connexion intermittente (5mn une fois par jour en RTC --- il en faudra sans doute davantage pour étalonner ton bolide). -- Jacques L'helgoualc'h
Je ne connaissais pas chrony qui est mieux adapté pour les portables, mai s je pense qu'effectivement Thierry Leurent à raison, ce n'est pas une solutio n efficace. Si j'ai bien compris les docs pour chrony comme pour adjtimex il s sont efficaces pour des décalages de quelques secondes / 24 heures, ce qu i n'est pas mon cas.
J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
If your system clock gained 8 seconds in 24 hours, you could set the tick to 9999, and then it would lose 0.64 seconds a day (that is, 1 tick unit = 8.64 seconds per day). To correct the rest of the err or, you could set the frequency offset to (2^16)*0.64/.0864 = 485452. Thus, putting the following in rc.local would approximately correct the system clock:
adjtimex --tick 9999 --freq 485452
des corrections sont effectuées dans /etc/adjtime avec des valeurs néga tives énormes: -260.264222 1169730193 0.000000! Après ce test l'horloge ralentie durant quelques temps puis accélère de nouveau!
Je pense qu'il s'agit d'un bug du kernel
@++
Le jeudi 25 janvier 2007 12:10, Jacques L'helgoualc'h a écrit :
wolfgod a écrit, jeudi 25 janvier 2007, à 11:33 :
[horloge overcloquée]
> Oui c'est bien ntdate que j'ai installé (sans cron).
Avec ou sans cron, ntpdate est une commande de mise à l'heure, en
interrogeant un serveur extérieur.
Tu peux essayer les paquets ntp-server, ou ntp-simple, qui feront
tourner un démon de suerveillance de l'horloge ; j'ai eu de meilleurs
résultats avec chrony en connexion intermittente (5mn une fois par jour
en RTC --- il en faudra sans doute davantage pour étalonner ton bolide).
--
Jacques L'helgoualc'h
Je ne connaissais pas chrony qui est mieux adapté pour les portables, mai s je
pense qu'effectivement Thierry Leurent à raison, ce n'est pas une solutio n
efficace. Si j'ai bien compris les docs pour chrony comme pour adjtimex il s
sont efficaces pour des décalages de quelques secondes / 24 heures, ce qu i
n'est pas mon cas.
J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
If your system clock gained 8 seconds in 24 hours, you could set the
tick to 9999, and then it would lose 0.64 seconds a day (that is, 1
tick unit = 8.64 seconds per day). To correct the rest of the err or,
you could set the frequency offset to (2^16)*0.64/.0864 = 485452.
Thus, putting the following in rc.local would approximately correct the
system clock:
adjtimex --tick 9999 --freq 485452
des corrections sont effectuées dans /etc/adjtime avec des valeurs néga tives
énormes: -260.264222 1169730193 0.000000!
Après ce test l'horloge ralentie durant quelques temps puis accélère de
nouveau!
Le jeudi 25 janvier 2007 12:10, Jacques L'helgoualc'h a écrit :
wolfgod a écrit, jeudi 25 janvier 2007, à 11:33 : [horloge overcloquée]
> Oui c'est bien ntdate que j'ai installé (sans cron).
Avec ou sans cron, ntpdate est une commande de mise à l'heure, en interrogeant un serveur extérieur.
Tu peux essayer les paquets ntp-server, ou ntp-simple, qui feront tourner un démon de suerveillance de l'horloge ; j'ai eu de meilleurs résultats avec chrony en connexion intermittente (5mn une fois par jour en RTC --- il en faudra sans doute davantage pour étalonner ton bolide). -- Jacques L'helgoualc'h
Je ne connaissais pas chrony qui est mieux adapté pour les portables, mai s je pense qu'effectivement Thierry Leurent à raison, ce n'est pas une solutio n efficace. Si j'ai bien compris les docs pour chrony comme pour adjtimex il s sont efficaces pour des décalages de quelques secondes / 24 heures, ce qu i n'est pas mon cas.
J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
If your system clock gained 8 seconds in 24 hours, you could set the tick to 9999, and then it would lose 0.64 seconds a day (that is, 1 tick unit = 8.64 seconds per day). To correct the rest of the err or, you could set the frequency offset to (2^16)*0.64/.0864 = 485452. Thus, putting the following in rc.local would approximately correct the system clock:
adjtimex --tick 9999 --freq 485452
des corrections sont effectuées dans /etc/adjtime avec des valeurs néga tives énormes: -260.264222 1169730193 0.000000! Après ce test l'horloge ralentie durant quelques temps puis accélère de nouveau!
Je pense qu'il s'agit d'un bug du kernel
@++
wolfgod
Le jeudi 25 janvier 2007 13:13, Thierry Leurent a écrit :
Salut
J'ai déjà eu un problème d'horloge qui avance mais pas une post-com bustion à ce point là.
Effectivement cela me semble assez impressionnant d'avoir autant de décal age de +ou- 30 secondes d'avance en 1 minute.
Mon problème venait de nero4linux, comment pourquoi ? aucune idée. Ap rès avoir enlevé ce logitiel tout est revenu dans l'ordre.
J'essayerai d'installer un distrib basic avec le minimun de truc et surtout uniquement le mode console.
C'est déjà fait, j'en parlais dans l'un de mes précédents messages:
- Finalement désemparé, j'ai installé de nouveau ETCH avec uniqueme nt KDE sur un autre disque, histoire de voir si ce n'est pas un paquet qui aurait pu être la cause de ce décalage! Et bien non! C'est exactement le même p roblème!
- Et pour finir j'ai épluché le fichier doc /usr/share/doc/HOWTO/en-txt/TimePrecision-HOWTO.gz, mais j'ai rien trou vé qui puisse résoudre mon problème!
Et aussi voir avec la dernière version du noyau, voir le snapshot du jour. Mettre un ticket sur le bug tracking du kernel.
Oui, je pense que c'est la meilleur solution qu'il me reste.
Ca n'est la solution, je le sais mais je ne vois pas en quoi synchroniser ton horloge résoudra ton problème.
C'est vrai.
Si ma mémoire est bonne ntpd, se connecter de manière aléatoire au serveur afin d'éviter un engorgement.
Je crois aussi.
Même dans le cas où tu restes connecté tous le temps et que fais un ntpdate toutes les minutes, ton système passera plus de temps à se re-synchroniser.
C'est sur, donc inefficace.
Merci @++
wolfgod a écrit : > Le jeudi 25 janvier 2007 11:24, Jacques L'helgoualc'h a écrit : >> wolfgod a écrit, jeudi 25 janvier 2007, à 10:45 : >> [...] >> >> > L'horloge prend +ou- 30 secondes d'avance en 1 minute, utiliser ntpd >> >> avec >> >> > cron n'est donc pas possible, surtout pour un portable qui n'est pas >> > toujours connecté. >> >> ntpdate != ntpd (ou chrony), ces derniers n'utilisent pas cron, mais >> tournent en permanence --- maintenant, je ne sais pas s'ils pourro nt > > ***************** > >> supporter ton horloge turbo :-/ > > Re salut > > :D Ha! Ha! C'est le cas de le dire avec post-combustion! >> >> -- >> Jacques L'helgoualc'h > > Oui c'est bien ntdate que j'ai installé (sans cron). > > @++
Le jeudi 25 janvier 2007 13:13, Thierry Leurent a écrit :
Salut
J'ai déjà eu un problème d'horloge qui avance mais pas une post-com bustion
à ce point là.
Effectivement cela me semble assez impressionnant d'avoir autant de décal age
de +ou- 30 secondes d'avance en 1 minute.
Mon problème venait de nero4linux, comment pourquoi ? aucune idée. Ap rès
avoir enlevé ce logitiel tout est revenu dans l'ordre.
J'essayerai d'installer un distrib basic avec le minimun de truc et
surtout uniquement le mode console.
C'est déjà fait, j'en parlais dans l'un de mes précédents messages:
- Finalement désemparé, j'ai installé de nouveau ETCH avec uniqueme nt KDE sur
un autre disque, histoire de voir si ce n'est pas un paquet qui aurait pu
être la cause de ce décalage! Et bien non! C'est exactement le même p roblème!
- Et pour finir j'ai épluché le fichier
doc /usr/share/doc/HOWTO/en-txt/TimePrecision-HOWTO.gz, mais j'ai rien trou vé
qui puisse résoudre mon problème!
Et aussi voir avec la dernière version
du noyau, voir le snapshot du jour.
Mettre un ticket sur le bug tracking du kernel.
Oui, je pense que c'est la meilleur solution qu'il me reste.
Ca n'est la solution, je le sais mais je ne vois pas en quoi synchroniser
ton horloge résoudra ton problème.
C'est vrai.
Si ma mémoire est bonne ntpd, se connecter de manière aléatoire au serveur
afin d'éviter un engorgement.
Je crois aussi.
Même dans le cas où tu restes connecté tous le temps et que fais un
ntpdate toutes les minutes, ton système passera plus de temps à se
re-synchroniser.
C'est sur, donc inefficace.
Merci @++
wolfgod a écrit :
> Le jeudi 25 janvier 2007 11:24, Jacques L'helgoualc'h a écrit :
>> wolfgod a écrit, jeudi 25 janvier 2007, à 10:45 :
>> [...]
>>
>> > L'horloge prend +ou- 30 secondes d'avance en 1 minute, utiliser ntpd
>>
>> avec
>>
>> > cron n'est donc pas possible, surtout pour un portable qui n'est pas
>> > toujours connecté.
>>
>> ntpdate != ntpd (ou chrony), ces derniers n'utilisent pas cron, mais
>> tournent en permanence --- maintenant, je ne sais pas s'ils pourro nt
>
> *****************
>
>> supporter ton horloge turbo :-/
>
> Re salut
>
> :D Ha! Ha! C'est le cas de le dire avec post-combustion!
>>
>> --
>> Jacques L'helgoualc'h
>
> Oui c'est bien ntdate que j'ai installé (sans cron).
>
> @++
Le jeudi 25 janvier 2007 13:13, Thierry Leurent a écrit :
Salut
J'ai déjà eu un problème d'horloge qui avance mais pas une post-com bustion à ce point là.
Effectivement cela me semble assez impressionnant d'avoir autant de décal age de +ou- 30 secondes d'avance en 1 minute.
Mon problème venait de nero4linux, comment pourquoi ? aucune idée. Ap rès avoir enlevé ce logitiel tout est revenu dans l'ordre.
J'essayerai d'installer un distrib basic avec le minimun de truc et surtout uniquement le mode console.
C'est déjà fait, j'en parlais dans l'un de mes précédents messages:
- Finalement désemparé, j'ai installé de nouveau ETCH avec uniqueme nt KDE sur un autre disque, histoire de voir si ce n'est pas un paquet qui aurait pu être la cause de ce décalage! Et bien non! C'est exactement le même p roblème!
- Et pour finir j'ai épluché le fichier doc /usr/share/doc/HOWTO/en-txt/TimePrecision-HOWTO.gz, mais j'ai rien trou vé qui puisse résoudre mon problème!
Et aussi voir avec la dernière version du noyau, voir le snapshot du jour. Mettre un ticket sur le bug tracking du kernel.
Oui, je pense que c'est la meilleur solution qu'il me reste.
Ca n'est la solution, je le sais mais je ne vois pas en quoi synchroniser ton horloge résoudra ton problème.
C'est vrai.
Si ma mémoire est bonne ntpd, se connecter de manière aléatoire au serveur afin d'éviter un engorgement.
Je crois aussi.
Même dans le cas où tu restes connecté tous le temps et que fais un ntpdate toutes les minutes, ton système passera plus de temps à se re-synchroniser.
C'est sur, donc inefficace.
Merci @++
wolfgod a écrit : > Le jeudi 25 janvier 2007 11:24, Jacques L'helgoualc'h a écrit : >> wolfgod a écrit, jeudi 25 janvier 2007, à 10:45 : >> [...] >> >> > L'horloge prend +ou- 30 secondes d'avance en 1 minute, utiliser ntpd >> >> avec >> >> > cron n'est donc pas possible, surtout pour un portable qui n'est pas >> > toujours connecté. >> >> ntpdate != ntpd (ou chrony), ces derniers n'utilisent pas cron, mais >> tournent en permanence --- maintenant, je ne sais pas s'ils pourro nt > > ***************** > >> supporter ton horloge turbo :-/ > > Re salut > > :D Ha! Ha! C'est le cas de le dire avec post-combustion! >> >> -- >> Jacques L'helgoualc'h > > Oui c'est bien ntdate que j'ai installé (sans cron). > > @++
Jacques L'helgoualc'h
wolfgod a écrit, jeudi 25 janvier 2007, à 14:22 :
[...]. Si j'ai bien compris les docs pour chrony comme pour adjtimex ils sont efficaces pour des décalages de quelques secondes / 24 heures, ce qui n'est pas mon cas.
Ils sont prévus pour les petits écarts, c'est vrai...
J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
[...]
Après ce test l'horloge ralentie durant quelques temps puis accélère de nouveau!
Je pense qu'il s'agit d'un bug du kernel
oui, ou d'un mauvais réglage ? Le fait que ça aille juste deux fois trop vite suggère une erreur bête quelque part.
Tu n'as indiqué que des passages de paramètre via LILO, mais il est aussi possible, sans rebouter, de se servir de sysctl --- j'ai quelques réglages mémorisés dans /etc/sysctl.conf pour mon noyau 2.4. -- Jacques L'helgoualc'h
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
wolfgod a écrit, jeudi 25 janvier 2007, à 14:22 :
[...]. Si j'ai bien compris les docs pour chrony comme pour adjtimex ils
sont efficaces pour des décalages de quelques secondes / 24 heures, ce qui
n'est pas mon cas.
Ils sont prévus pour les petits écarts, c'est vrai...
J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
[...]
Après ce test l'horloge ralentie durant quelques temps puis accélère de
nouveau!
Je pense qu'il s'agit d'un bug du kernel
oui, ou d'un mauvais réglage ? Le fait que ça aille juste deux fois trop
vite suggère une erreur bête quelque part.
Tu n'as indiqué que des passages de paramètre via LILO, mais il est
aussi possible, sans rebouter, de se servir de sysctl --- j'ai quelques
réglages mémorisés dans /etc/sysctl.conf pour mon noyau 2.4.
--
Jacques L'helgoualc'h
--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et
"Reply-To:"
To UNSUBSCRIBE, email to debian-user-french-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
[...]. Si j'ai bien compris les docs pour chrony comme pour adjtimex ils sont efficaces pour des décalages de quelques secondes / 24 heures, ce qui n'est pas mon cas.
Ils sont prévus pour les petits écarts, c'est vrai...
J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
[...]
Après ce test l'horloge ralentie durant quelques temps puis accélère de nouveau!
Je pense qu'il s'agit d'un bug du kernel
oui, ou d'un mauvais réglage ? Le fait que ça aille juste deux fois trop vite suggère une erreur bête quelque part.
Tu n'as indiqué que des passages de paramètre via LILO, mais il est aussi possible, sans rebouter, de se servir de sysctl --- j'ai quelques réglages mémorisés dans /etc/sysctl.conf pour mon noyau 2.4. -- Jacques L'helgoualc'h
-- Lisez la FAQ de la liste avant de poser une question : http://wiki.debian.net/?DebianFrench Vous pouvez aussi ajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to with a subject of "unsubscribe". Trouble? Contact
wolfgod
Le jeudi 25 janvier 2007 15:38, Jacques L'helgoualc'h a écrit :
wolfgod a écrit, jeudi 25 janvier 2007, à 14:22 : > [...]. Si j'ai bien compris les docs pour chrony comme pour adjtimex i ls > sont efficaces pour des décalages de quelques secondes / 24 heures, ce > qui n'est pas mon cas.
Ils sont prévus pour les petits écarts, c'est vrai...
> J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
[...]
> Après ce test l'horloge ralentie durant quelques temps puis accél ère de > nouveau! > > Je pense qu'il s'agit d'un bug du kernel
oui, ou d'un mauvais réglage ? Le fait que ça aille juste deux fois t rop vite suggère une erreur bête quelque part.
Possible mais où!
Tu n'as indiqué que des passages de paramètre via LILO, mais il est aussi possible, sans rebouter, de se servir de sysctl --- j'ai quelques réglages mémorisés dans /etc/sysctl.conf pour mon noyau 2.4.
ça serait bien si je pouvais résoudre ce problème par l'intermédiai re de /etc/sysctl.conf.
-- Jacques L'helgoualc'h
Merci @++
Le jeudi 25 janvier 2007 15:38, Jacques L'helgoualc'h a écrit :
wolfgod a écrit, jeudi 25 janvier 2007, à 14:22 :
> [...]. Si j'ai bien compris les docs pour chrony comme pour adjtimex i ls
> sont efficaces pour des décalages de quelques secondes / 24 heures, ce
> qui n'est pas mon cas.
Ils sont prévus pour les petits écarts, c'est vrai...
> J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
[...]
> Après ce test l'horloge ralentie durant quelques temps puis accél ère de
> nouveau!
>
> Je pense qu'il s'agit d'un bug du kernel
oui, ou d'un mauvais réglage ? Le fait que ça aille juste deux fois t rop
vite suggère une erreur bête quelque part.
Possible mais où!
Tu n'as indiqué que des passages de paramètre via LILO, mais il est
aussi possible, sans rebouter, de se servir de sysctl --- j'ai quelques
réglages mémorisés dans /etc/sysctl.conf pour mon noyau 2.4.
ça serait bien si je pouvais résoudre ce problème par l'intermédiai re
de /etc/sysctl.conf.
Le jeudi 25 janvier 2007 15:38, Jacques L'helgoualc'h a écrit :
wolfgod a écrit, jeudi 25 janvier 2007, à 14:22 : > [...]. Si j'ai bien compris les docs pour chrony comme pour adjtimex i ls > sont efficaces pour des décalages de quelques secondes / 24 heures, ce > qui n'est pas mon cas.
Ils sont prévus pour les petits écarts, c'est vrai...
> J'ai fais des tests avec adjtimex, comme mentionnés dans le man:
[...]
> Après ce test l'horloge ralentie durant quelques temps puis accél ère de > nouveau! > > Je pense qu'il s'agit d'un bug du kernel
oui, ou d'un mauvais réglage ? Le fait que ça aille juste deux fois t rop vite suggère une erreur bête quelque part.
Possible mais où!
Tu n'as indiqué que des passages de paramètre via LILO, mais il est aussi possible, sans rebouter, de se servir de sysctl --- j'ai quelques réglages mémorisés dans /etc/sysctl.conf pour mon noyau 2.4.
ça serait bien si je pouvais résoudre ce problème par l'intermédiai re de /etc/sysctl.conf.
-- Jacques L'helgoualc'h
Merci @++
Max
Le 24/01/07, wolfgod a écrit :
Bonjour la liste
Il y' a quelque temps, le sujet du problème d'horloge avait été tra ité, pour un portable Nitteo M707 Hyper Threading en ETCH et kernel 2.6.18-3-686.
La commande «append="noapic nolapic"» dans lilo.conf semblait avoir résolu le problème! En fait le lendemain en allumant mon portable, j'ai eu de nouveau le même problème d'horloge! Après de nombreuses recherches, j'ai pu lire que pour les kernels récents et notamment le 2.6.18-3-686, la comm ande «append="noapic nolapic" devait être remplacée par celle-ci : «append=disable_timer_pin_1»
Il y a peut-être aussi le paramètre clock qui pourrait avoir un effet. Par exemple passer au noyau clock=tsc ou clock=pit peut parfois régle r un problème de ce type.
-- Max
Le 24/01/07, wolfgod a écrit :
Bonjour la liste
Il y' a quelque temps, le sujet du problème d'horloge avait été tra ité, pour
un portable Nitteo M707 Hyper Threading en ETCH et kernel 2.6.18-3-686.
La commande «append="noapic nolapic"» dans lilo.conf semblait avoir résolu
le problème! En fait le lendemain en allumant mon portable, j'ai eu de
nouveau le même problème d'horloge! Après de nombreuses recherches, j'ai pu
lire que pour les kernels récents et notamment le 2.6.18-3-686, la comm ande
«append="noapic nolapic"
devait être remplacée par celle-ci :
«append=disable_timer_pin_1»
Il y a peut-être aussi le paramètre clock qui pourrait avoir un effet.
Par exemple passer au noyau clock=tsc ou clock=pit peut parfois régle r
un problème de ce type.
Il y' a quelque temps, le sujet du problème d'horloge avait été tra ité, pour un portable Nitteo M707 Hyper Threading en ETCH et kernel 2.6.18-3-686.
La commande «append="noapic nolapic"» dans lilo.conf semblait avoir résolu le problème! En fait le lendemain en allumant mon portable, j'ai eu de nouveau le même problème d'horloge! Après de nombreuses recherches, j'ai pu lire que pour les kernels récents et notamment le 2.6.18-3-686, la comm ande «append="noapic nolapic" devait être remplacée par celle-ci : «append=disable_timer_pin_1»
Il y a peut-être aussi le paramètre clock qui pourrait avoir un effet. Par exemple passer au noyau clock=tsc ou clock=pit peut parfois régle r un problème de ce type.
-- Max
wolfgod
Le vendredi 26 janvier 2007 02:10, Max a écrit :
Le 24/01/07, wolfgod a écrit : > Bonjour la liste > > Il y' a quelque temps, le sujet du problème d'horloge avait été t raité, > pour un portable Nitteo M707 Hyper Threading en ETCH et kernel > 2.6.18-3-686. > > La commande «append="noapic nolapic"» dans lilo.conf semblait avo ir > résolu le problème! En fait le lendemain en allumant mon portable, j'ai > eu de nouveau le même problème d'horloge! Après de nombreuses rec herches, > j'ai pu lire que pour les kernels récents et notamment le 2.6.18-3-68 6, > la commande «append="noapic nolapic" > devait être remplacée par celle-ci : > «append=disable_timer_pin_1»
Il y a peut-être aussi le paramètre clock qui pourrait avoir un effet. Par exemple passer au noyau clock=tsc ou clock=pit peut parfois rég ler un problème de ce type.
Salut et milles merci
Après de laborieuses recherches sur les causes du problème de décalage "HOLOGE" du kernel, et ne trouvant aucune réponse, Je ne peut être que très reconnaissant de m'avoir donné la solution me permettant, enfi n, d'utilser mon portable dans des conditions normales.
Aussi de mon coté, j'ai recherché, l'explication de cette commande "mag ique". Voici donc, un tuto détaillé, mais en anglais (désolé pour ceux qui ne parle pas l'anglais, mais je n'ai rien trouvé de plausible en français, oup's ) http://kb.vmware.com/KanisaPlatform/Publishing/329/1420_f.SAL_Public.html
Dans lilo.conf : # append="clock=pit" # lilo # reboot Enfin un # dmesg pour contrôler que le noyau à bien enregistré: [...] Kernel command line: auto BOOT_IMAGE=Linux ro root01 clock=pit [...]
Pour ne pas avoir de surprise, j'ai redémarrer plusieurs fois, c'est pas un rêve, mais bien totalement stable.
Même si je me répète, je tiens encore à remercier sincèrement tou s ceux qui ont donnés un peu de leur temps dans cette affaire.
@++
Le vendredi 26 janvier 2007 02:10, Max a écrit :
Le 24/01/07, wolfgod a écrit :
> Bonjour la liste
>
> Il y' a quelque temps, le sujet du problème d'horloge avait été t raité,
> pour un portable Nitteo M707 Hyper Threading en ETCH et kernel
> 2.6.18-3-686.
>
> La commande «append="noapic nolapic"» dans lilo.conf semblait avo ir
> résolu le problème! En fait le lendemain en allumant mon portable, j'ai
> eu de nouveau le même problème d'horloge! Après de nombreuses rec herches,
> j'ai pu lire que pour les kernels récents et notamment le 2.6.18-3-68 6,
> la commande «append="noapic nolapic"
> devait être remplacée par celle-ci :
> «append=disable_timer_pin_1»
Il y a peut-être aussi le paramètre clock qui pourrait avoir un effet.
Par exemple passer au noyau clock=tsc ou clock=pit peut parfois rég ler
un problème de ce type.
Salut et milles merci
Après de laborieuses recherches sur les causes du problème de
décalage "HOLOGE" du kernel, et ne trouvant aucune réponse, Je ne peut être
que très reconnaissant de m'avoir donné la solution me permettant, enfi n,
d'utilser mon portable dans des conditions normales.
Aussi de mon coté, j'ai recherché, l'explication de cette commande "mag ique".
Voici donc, un tuto détaillé, mais en anglais (désolé pour ceux qui ne parle
pas l'anglais, mais je n'ai rien trouvé de plausible en français, oup's )
http://kb.vmware.com/KanisaPlatform/Publishing/329/1420_f.SAL_Public.html
Dans lilo.conf :
# append="clock=pit"
# lilo
# reboot
Enfin un
# dmesg pour contrôler que le noyau à bien enregistré:
[...]
Kernel command line: auto BOOT_IMAGE=Linux ro root=301 clock=pit
[...]
Pour ne pas avoir de surprise, j'ai redémarrer plusieurs fois, c'est pas un
rêve, mais bien totalement stable.
Même si je me répète, je tiens encore à remercier sincèrement tou s ceux qui
ont donnés un peu de leur temps dans cette affaire.
Le 24/01/07, wolfgod a écrit : > Bonjour la liste > > Il y' a quelque temps, le sujet du problème d'horloge avait été t raité, > pour un portable Nitteo M707 Hyper Threading en ETCH et kernel > 2.6.18-3-686. > > La commande «append="noapic nolapic"» dans lilo.conf semblait avo ir > résolu le problème! En fait le lendemain en allumant mon portable, j'ai > eu de nouveau le même problème d'horloge! Après de nombreuses rec herches, > j'ai pu lire que pour les kernels récents et notamment le 2.6.18-3-68 6, > la commande «append="noapic nolapic" > devait être remplacée par celle-ci : > «append=disable_timer_pin_1»
Il y a peut-être aussi le paramètre clock qui pourrait avoir un effet. Par exemple passer au noyau clock=tsc ou clock=pit peut parfois rég ler un problème de ce type.
Salut et milles merci
Après de laborieuses recherches sur les causes du problème de décalage "HOLOGE" du kernel, et ne trouvant aucune réponse, Je ne peut être que très reconnaissant de m'avoir donné la solution me permettant, enfi n, d'utilser mon portable dans des conditions normales.
Aussi de mon coté, j'ai recherché, l'explication de cette commande "mag ique". Voici donc, un tuto détaillé, mais en anglais (désolé pour ceux qui ne parle pas l'anglais, mais je n'ai rien trouvé de plausible en français, oup's ) http://kb.vmware.com/KanisaPlatform/Publishing/329/1420_f.SAL_Public.html
Dans lilo.conf : # append="clock=pit" # lilo # reboot Enfin un # dmesg pour contrôler que le noyau à bien enregistré: [...] Kernel command line: auto BOOT_IMAGE=Linux ro root01 clock=pit [...]
Pour ne pas avoir de surprise, j'ai redémarrer plusieurs fois, c'est pas un rêve, mais bien totalement stable.
Même si je me répète, je tiens encore à remercier sincèrement tou s ceux qui ont donnés un peu de leur temps dans cette affaire.
