[qemu] l'horloge s'affole

Le
Stéphan Peccini
Bonsoir,

J'ai un problème avec qemu ; mon horloge avance à un rythme effréné.

Mon système de base est une FC6 avec un noyau en 2.6.22 ; j'ai installé qemu
avec kqemu et ma machine virtuelle est une debian (installée à partir de
cet iso : debian-40r1-i386-businesscard.iso).

Au lancement, voici la commande :
qemu -m 256 -smp 2 -localtime -no-acpi -k fr -cdrom /dev/cdrom
debian.img -net nic -net tap,script=no,ifname=tap0
-nographic -append "console=ttyS0 root=/dev/hda1 ro"

Si je laisse faire le système, l'horloge doit aller 10 fois plus vite que la
normale. Je suis obligé de synchroniser à coup de ntpdate dans la
crontab :-(

Au démarrage j'ai une erreur qui semble être bien connue :
Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
error, but for better emulation accuracy either use a 2.6 host Linux kernel
or type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.
Étant déjà en 2.6, je ne vois pas ce que je peux faire sauf à me dire que le
noyau de la FC6 n'est pas « conforme ». Est-ce que cela à un rapport avec
mon problème ? (en lisant Google, il semble que non)

Je ne trouve rien de probant dans le /var/log/messages de la debian.

Auriez vous une piste à me suggérer ?

Merci d'avance

--
Stéphan Peccini
Les photos : <URL:http://photonature.fr>
Les Pyrénées : <URL:http://photonature.fr/pyrenees>
Le blog : <URL:http://pyrenees.peccini.fr>
Questions / Réponses high-tech
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Stéphan Peccini
Le #1903484
Sur fr.comp.os.linux.configuration, Stéphan Peccini s'est exprimé ainsi :

J'ai un problème avec qemu ; mon horloge avance à un rythme effréné.


Cela a en plus une incidence car j'utilise les limites d'iptables pour
adapter l'activité réseau. Mais avec une horloge qui avance de 3 à 10
secondes toute les secondes, il semble difficile de fixer correctement les
valeurs et vérifier le résultat. Et pourtant, j'obtiens des résultats
cohérents (enfin il me semble) :

-A FILTRE -p icmp --icmp-type echo-request
-m limit --limit 1/s --limit-burst 2 -j ACCEPT
-A FILTRE -p icmp -j REJECT --reject-with icmp-port-unreachable

[ rules.d]# ping -i 0 eweb
PING eweb.domicile (192.168.0.30) 56(84) bytes of data.
64 bytes from eweb.domicile (192.168.0.30): icmp_seq=1 ttld time=1.74 ms
64 bytes from eweb.domicile (192.168.0.30): icmp_seq=2 ttld time=1.16 ms
From eweb.domicile (192.168.0.30) icmp_seq=3 Destination Port Unreachable
...
64 bytes from eweb.domicile (192.168.0.30): icmp_seq98 ttld time=0.745
ms
From eweb.domicile (192.168.0.30) icmp_seq99 Destination Port Unreachable

--- eweb.domicile ping statistics ---
420 packets transmitted, 8 received, +12 errors, 98% packet loss, time
6379ms
rtt min/avg/max/mdev = 0.745/0.966/1.742/0.320 ms, pipe 2, ipg/ewma
15.224/1.188
ms
[ rules.d]#

Donc 8 paquets acceptés en 6 secondes : les 2 premiers (issus
de --limit-burst 2) et les 6 autres, 1 par seconde (issus de --limit 1/s).
Cela semble donc correct.

Comment est-ce possible avec une horloge qui déconne ? Une petite idée :-)

--
Stéphan Peccini
Les photos : Les Pyrénées : Le blog :
Stéphan Peccini
Le #1903482
C'est peut-être fini. Cela vient de tomber en marche suite à un reboot de la
FC6. ??????

--
Stéphan Peccini
Les photos : Les Pyrénées : Le blog :
Publicité
Poster une réponse
Anonyme