[solved] amd64 x2 3800+ "time to fast"

tortelini · 30. November 2005

Habe den vdr-1.3.37 installiert. Bekomme immer wieder folgende FM:

Code

Nov 30 00:49:30 XXX vdr[11017]: ERROR: invalid Count in cRingBufferLinear::Del: 0 (limited to -1350769504)
Nov 30 00:52:37 XXX vdr[11017]: ERROR: invalid Count in cRingBufferLinear::Del: 0 (limited to -1392508472)
Nov 30 04:49:15 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 14 bytes to sync on next audio frame
Nov 30 04:49:15 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 14 bytes to sync on next audio frame
Nov 30 04:49:15 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 243 bytes to sync on next audio frame
Nov 30 07:58:31 XXX vdr[11017]: ERROR: invalid Count in cRingBufferLinear::Del: 0 (limited to -605725998)
Nov 30 08:59:03 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 1464 bytes while syncing on next audio frame
Nov 30 08:59:03 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 1468 bytes while syncing on next audio frame
Nov 30 08:59:04 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 453 bytes to sync on next audio frame
Nov 30 08:59:04 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 907 bytes while syncing on next audio frame
Nov 30 08:59:04 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 1826 bytes while syncing on next audio frame
Nov 30 08:59:04 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 1826 bytes while syncing on next audio frame
Nov 30 08:59:04 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 71 bytes while syncing on next audio frame
Nov 30 09:55:20 XXX vdr[11017]: cAudioRepacker(0xC0): skipped 4 bytes to sync on next audio frame

Alles anzeigen

Wenn ich eine aufnahme starte, endet es immer mit einem "initiating emergency exit".
Was hat diese FM zu bedeuten? Gibt es da einen work a round?

Ich habe auch noch das Problem, dass die Systemzeit zu schnell ist, und deshalb ein cronjob mir die Zeit nach stellt.

Code

Nov 30 07:00:01 XXX /USR/SBIN/CRON[23671]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 06:49:13 XXX ntpdate[23686]: step time server XXX offset -648.733824 sec
Nov 30 07:00:01 XXX /USR/SBIN/CRON[23986]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 06:57:56 XXX ntpdate[23988]: step time server XXX offset -124.865321 sec
Nov 30 07:00:02 XXX /USR/SBIN/CRON[24095]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 06:59:41 XXX ntpdate[24100]: step time server XXX offset -20.856847 sec
Nov 30 07:00:01 XXX /USR/SBIN/CRON[24148]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 06:59:59 XXX ntpdate[24153]: step time server XXX offset -2.939495 sec
Nov 30 07:00:01 XXX /USR/SBIN/CRON[24203]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 07:00:00 XXX ntpdate[24206]: step time server XXX offset -1.120008 sec
Nov 30 08:00:01 XXX /USR/SBIN/CRON[25759]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 07:49:34 XXX ntpdate[25776]: step time server XXX offset -627.126107 sec
Nov 30 08:00:01 XXX /USR/SBIN/CRON[26076]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 07:58:28 XXX ntpdate[26080]: step time server XXX offset -93.359955 sec
Nov 30 08:00:01 XXX /USR/SBIN/CRON[26160]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 07:59:19 XXX ntpdate[26162]: step time server XXX offset -42.705966 sec
Nov 30 08:00:01 XXX /USR/SBIN/CRON[26214]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 07:59:54 XXX ntpdate[26218]: step time server XXX offset -6.999321 sec
Nov 30 08:00:01 XXX /USR/SBIN/CRON[26269]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 08:00:01 XXX ntpdate[26272]: step time server XXX offset -1.386220 sec
Nov 30 09:00:01 XXX /USR/SBIN/CRON[27826]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 08:53:39 XXX ntpdate[27832]: step time server XXX offset -382.571789 sec
Nov 30 09:00:01 XXX /USR/SBIN/CRON[28035]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 08:59:32 XXX ntpdate[28038]: step time server XXX offset -28.939206 sec
Nov 30 09:00:01 XXX /USR/SBIN/CRON[28088]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 08:59:59 XXX ntpdate[28094]: step time server XXX offset -2.699190 sec
Nov 30 09:00:01 XXX /USR/SBIN/CRON[28143]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 09:00:01 XXX ntpdate[28149]: step time server XXX offset -0.149909 sec
Nov 30 10:00:01 XXX /USR/SBIN/CRON[29700]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 09:54:24 XXX ntpdate[29705]: step time server XXX offset -336.993309 sec
Nov 30 10:00:01 XXX /USR/SBIN/CRON[29886]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 09:59:11 XXX ntpdate[29893]: step time server XXX offset -50.942354 sec
Nov 30 10:00:01 XXX /USR/SBIN/CRON[29941]: (root) CMD (/etc/init.d/ntpdate start 1>/dev/null 2>&1)
Nov 30 09:59:54 XXX ntpdate[29946]: step time server XXX offset -7.278829 sec

Alles anzeigen

Ich vermute das ich deshalb diese vdr - Probleme habe. Hat schon jemand diese erfahrung gemacht? Kann mir einer helfen?

tortelini · 30. November 2005

Ich verwende den softdevice:xv plugin.
Und den Linux kernel 2.6.14.
Nur falls es wichtig sein sollte.

Hat noch jemand einen amd64 x2 im einsatz????

scobby · 30. November 2005

ähmmmm nein
so ein prozzi für nen vdr...... ähmmmm nein
hoffe das is nicht nur nen vdr sonst würde ich irgendwie an dir zweifeln

tortelini · 30. November 2005

Zitat

Original von scobby
so ein prozzi für nen vdr...... ähmmmm nein
hoffe das is nicht nur nen vdr sonst würde ich irgendwie an dir zweifeln

Hi scobby,

mit den vdr-softdevice:xv bzw. vdr-xine plugins will ich HDTV sehen (sicher ist sicher). Nur der dvb-s2 standard macht mir noch sorgen. Aber das ist eine andere Geschichte. Ansonsten kann die WM2006 kommen.

Und an die 300GB raid1 habe ich auch noch (fuer die filme), daran haengen (nfs+smb).
Sei nicht entteuscht. Bei den heutigen Preisen, muss ich mir das wirklich nicht mehr langen ueberlegen. Kost ja nicht mehr die Welt. Wenn man mahl die Wasserkuehlung nicht beachtet. Jetzt ist das Ding schön im Kasten verbaut.

@alle
Hat wirklich keiner Ideen?

mwa · 30. November 2005

Das ist doch nicht etwa das TSC Drift Problem mit den unterschiedlichen Sleepstates der beiden Cores, was auch Windows XP die Probleme macht?
Angeblich kann man das bei LInux beheben indem man als Boot Option "notsc" oder "clock=pmtmr" angibt.

Vielleicht hilfts... Solange die Systemzeit jedenfalls so hin und her springt wird das Softdevice nicht vernünftig laufen, das benutzt die Systemzeit zum synchronisieren von Audio und Video.

Martin

Wicky · 30. November 2005

ist die Batterie des Mainboards ok ? bzw. die Spannung ausreichend ?

Gruß
Wicky

tortelini · 30. November 2005

Zitat

Original von mwa
Das ist doch nicht etwa das TSC Drift Problem mit den unterschiedlichen Sleepstates der beiden Cores, was auch Windows XP die Probleme macht?
Angeblich kann man das bei LInux beheben indem man als Boot Option "notsc" oder "clock=pmtmr" angibt.

Vielleicht hilfts... Solange die Systemzeit jedenfalls so hin und her springt wird das Softdevice nicht vernünftig laufen, das benutzt die Systemzeit zum synchronisieren von Audio und Video.

So lese ich das auch aus dem File. Klingt sehr gut. Dem werde ich mal nachgehen.
Meine .config beinhaltet u.a.:
CONFIG_X86_TSC=y
Werde dieses mal deaktivieren.

Zitat

Original von Wicky
ist die Batterie des Mainboards ok ? bzw. die Spannung ausreichend ?

Meinst du die Spannung des Netzteils oder der Batterie?
Naja. Das das Netzteil oder die Baterie was hat kann ich nicht ausschlieszen. Die Zeit in /proc/rtc ist aber immer OK.

Wicky · 30. November 2005

Zitat

Naja. Das das Netzteil oder die Baterie was hat kann ich nicht ausschlieszen. Die Zeit in /proc/rtc ist aber immer OK.

Die Spannung der Batterie !! Eine neue Batterie hat ca. 3,1V. Da dein Mainboard jedoch recht neu ist, ist die Wahrscheinlichkeit recht gering, dass sie bereits leer ist.

Gruß
Wicky

tortelini · 30. November 2005

Wicky
mwa
danke an beide

@all
Der Tipp ist Gold wert:

Zitat

Original von mwa
indem man als Boot Option "notsc" oder "clock=pmtmr" angibt.

Ich habe den Parameter "CONFIG_X86_TSC" in der .config deaktiviert.

1. VORSICHT nach einem "make oldconfig" ist dieser Parameter weider auf "Yes".
2. VORSICHT den parameter sieht man auch nicht in der Konfiguration (make config; make menuconfig; udg.).

Deshalb bleibt nur das eingeben des Boot-Parameters "notsc", und natuerlich im grub/lilo einkonfiguriert.
Den Parameter "clock=pmtmr" habe ich nicht ausprobiert.

WICHTIG: Kennt jemand den unterschied der beiden Parameter?

Dr.Nop · 1. Dezember 2005

Bei den aktuellsten Kerneln hat sich viel getan, was die Timerquellen betrifft. Kompilier doch mal HPET Unterstützung ein. Ausserdem kannst du unter Power Management/APCI auch irgendwas mit Timern einstellen. Das ist auch ein Versuch Wert.

Der Parameter notsc verbietet dem Kernel den TimeStampCounter der Prozessoren zu nutzen, was auch äußerst schlecht ist, da bei einem 2 Prozessor System diese nicht synchronisiert werden.

PowerManagementTiMeR ist ein spezieller Timer des ACPI Systems, welcher deutlich besser synchronisiert sein sollte.

Bei solch einem modernen Prozessor sollte eingentlich ein HighPrecisionEventTimer verfügbar sein, welcher sicherlich momentan das Nonplusultra ist.

tortelini · 8. Februar 2006

Hi,

seit damals laeuft bei mir der vdr mit dem pmTimer. Soweit ist das OK.

Es gibt aber im Bios den Eintrag "APCI supports version 2" oder so.
Wenn man den auf "Enabled" setzt, kann man unter linux nur noch den TSC verwenden, und der ist misst. Also am besten deaktivieren!

Anscheinend wird HPET von dem VIA chipsatz NICHT unterschtuetzt. Ich haette mir doch den Nvidia chipsatz kaufen sollen.

Gruss
tortelini

LordJaxom · 8. Februar 2006

Hatte dasselbe Problem mit meinem AMD64 (allerdings kein X2 ).

Die Uhr lief genau doppelt so schnell (liess sich recht leicht verifizieren mit einem Shell Script welches jede Sekunde hwclock aufruft - jede Sekunde wird genau zwei Mal angezeigt), und alle Timerquellen halfen nichts (nichtmal notsc). Muss dazusagen der Kernel ist noch 32 bittig. Bis ich dann herausfand, dass im 64-bit Mode der Timer mit notsc richtig lief. (Ist übrigens ein 2.6.13.4 und das Mainboard hat nen Radeon Express 200 Chipsatz falls es interessiert)

Schlussendlich musste ich mir nen Patch für die 32-bit Timer Quelldateien basteln, der mir den notsc Modus freischaltet.

Just for the record

[solved] amd64 x2 3800+ "time to fast"

Jetzt mitmachen!

Teilen