Nach Systemupdate Klötzchen und Hänger

Zitat

Original von carzimo

Habe hier im Forum gelesen, dass es das Problem mit dem 2.6.12 Kernel nicht geben soll. Werde mal downgraden und gucken wie es dann läuft.

Leichter gesagt als getan.
Habe gerade versucht den Kernel 2.6.12.4 zu installieren, bekomme aber folgende Fehlermeldung:

SYSMAP .tmp_System.map 
Inconsistent kallsyms data 
Try setting CONFIG_KALLSYMS_EXTRA_PASS 
make: *** [vmlinux] Error 1

Scheint wohl ein bekanntes Problem zu sein, aber wo setze ich denn dieses

CONFIG_KALLSYMS_EXTRA_PASS=y

??

hab genau das gleiche problem wie oben beschrieben.
ich würde gerne mal einen anderen dvb treiber ausprobieren, weiss welcher der erste im cvs idt der auf der Linux version 2.6.13-15 läuft.

kann mir wer sagen wie ich das rausbekomme?

danke
abs.

Ich hatte/habe dieses Problem auch. Bei mir traten die Fehler auf, sobald auf hdc zugegriffen wurde. Seitdem ich dann diese Festplatte deaktiviert habe, funktionieren die Aufnahmen.

mir ist aufgefallen dass trotz aktivierung des UDMA100 modus in yast die festplatten teilweise die werte nicht übernommen haben.
der vdr hat im abstand von ca. 25 sek. immer für 5 sek. ununterbrochen auf dei festplatte geschrieben und danach hats fehlermeldungen "audio remux dolby buffer" etc. gehagelt.
hab jetzt mit hdparm den UDMA100 modus bei allen festplatten aktiviert dadurch hat sich die anzahl der fehlermeldungen deutlich reduziert - aber eben nicht ganz

Dr.Nop:
Seit einigen Wochen kämpfe ebenfalls mit den Symptomen dieses Threads
und
seit einigen Wochen habe ich eine 2. Platte (hdc) im System. Ich hatte die Platte geschenkt bekommen (war in einem RAID), da sie evtl. defekt ist. Ich habe sie lowlevel formatiert und mit smartctl untersucht. Vorerst scheint alles zu laufen mit der Platte. smartd meldet auch nichts aufregendes.

Meine Idee war auch schon, die Platte wieder zu entfernen. Leider kann ich nicht mehr überprüfen, ob die Fehler zeitgleich zur Inbetriebnamhe der 2. Platte anfingen.

Gestern habe ich jedoch von
Kernel 2.6.13 / vdr 1.3.34 (2 Patches) / Firmware 261f
auf
Kernel 2.6.12 / vdr 1.3.27 vanilla / Firmware 261f
gedowngraded. Ich hatte ebenfalls die Treiber des 2.6.13er Kernel in Verdacht. Eine erste Auswertung zeigt immer noch:

Oct 27 22:01:20 vdr vdr[6915]: transfer thread ended (pid=6915, tid=-1367340112)
Oct 27 22:01:20 vdr vdr[6915]: cTS2PES got 0 TS errors, 104 TS continuity errors
Oct 27 22:01:20 vdr vdr[6915]: cTS2PES got 0 TS errors, 31 TS continuity errors
Oct 27 22:01:20 vdr vdr[6915]: cTS2PES got 0 TS errors, 19 TS continuity errors
Oct 27 22:01:20 vdr vdr[6915]: buffer stats: 145136 (6%) used

Der Ausbau der 2. Platte ist nach deinem Hinweis definitiv der nächste Versuch.

Willst du die Platte zukünftig draussen lassen oder hast du schon eine Idee, wie du sie und den vdr ohne Fehler zum Laufen bekommst?

Viele Grüße,
TeeRose

Momentan benutze ich sie nicht für Aufzeichnungen sondern für alle anderen Daten.

Nachdem ich seit einigen Tagen die 2. Festplatte (hdc) als einiziges Gerät am Secondary IDE-Port abgehängt habe, treten die Fehler nur noch sporadisch auf.

cTS2PES tritt vereinzelt beim Beenden einer Aufnahme auf und hat lediglich ein bis drei Fehler:

Nov  1 20:16:00 vdr vdr[2140]: file writer thread ended (pid=2140, tid=-1288701008)
ov  1 20:16:00 vdr vdr[2140]: cTS2PES got 0 TS errors, 1 TS continuity errors

Ich denke, ich kann das erst einmal vernachlässigen. Was heißt die Meldung eingentlich?

cAudioRepacker tritt ebenfalls nur noch vereinzelt auf. Interessanterweise in folgendem Zusammenhang:

Oct 31 20:53:02 vdr /USR/SBIN/CRON[5997]: (mail) CMD (  if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi)
Oct 31 20:53:02 vdr kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 31 20:53:02 vdr kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 31 20:53:02 vdr kernel: ide: failed opcode was: unknown
Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 54 bytes to sync on next audio frame
Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 386 bytes to sync on next audio frame
Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 232 bytes to sync on next audio frame

Kann mir jemand sagen, was meine Platte hda da für ein Problem hat? DMA ist aktiviert und smartctl hatte bei den letzten Sichtungen nichts ergeben. Da werde ich heute abend aber noch mal genau schauen.

Hi,

kann es etwas mit der Timer Änderungs vom 2.6.13-er Kernel zu tun haben?
Ab 2.6.13 ist der default Timer jetzt 4ms anstelle von 1ms.

Viele Grüße,

Chris

Da ich das Problem auch habe mal mein Senf zum Thema:
Konifguration:
Technotrend FF 1.3 und Skystar 2
c't VDR 1.3.33 von e-tobi
Linux Kernel 2.4.27 (Standard Kernel der c't VDR 3 Disti)
Meine Beobachtungen:
- Wenn ich nur auf einer Karte aufnehme, gibt es nie Probleme (ist dann immer die Skystar)
- Wenn ich auf zwei Karten aufnehme, geht es meistens gut, allerdings nicht immer. Einige fehlerverursachende Konfigurationen sind bei mir:
- ZDF und Pro7
- ZDF und Sat.1
- ZDF und Kabel 1
- ARD und ZDF
- HR3 und SWR Baden Würtemberg
- ARD und NDR

Paralleles Aufnehmen von z.B. Sat.1 und ARD geht ohne Probleme und Klötzchen. Leider habe ich bis jetzt keine Idee, was die Gemeinsamkeit der Sender ist.

CeBe:

Ich habe mittlerweile den 2.6.14er Kernel und ebenfalls die Proble mit der hda. Diese Probleme begleiten mich aber schon seit einigen Kernel-Versionen (deutlich vor 2.6.13).

Oder meintest du speziell die Kombination dma_intr-Fehler der hda und anschließendem cAudioRepacker-Fehler?

Bei mir treten Probleme mit dem Audio-repacker auch auf wenn ich die Daten über streamdev schicke. Da einige leute behaupten dass der 2.6.12-Kernel die probleme nicht hat, vermute ich mal das es am neuen Linux-timing liegen könnte.
Damit wäre der vdr nicht die erste Anwendung die damit Probleme bekommen hätte. (Auf der Linux-Kernel Liste hat einer über probleme beim brennen berichtet..)
Sobald ich zuhause bin werde ich das mal bei mir Testen und dann hier die Ergebnisse posten.

Hi,

so ich habe bei meinem Server den Timer auf 1ms gestellt und seid dem habe ich keine Probleme mehr feststellen können.

Vielleicht will das sonst noch wer mal ausprobieren und mir sagen ob es geholfen hat.

die Parameter in der Kernel-Config sind:

CONFIG_HZ_1000=y
CONFIG_HZ=1000

viele Grüße,

Chris

Ich kann die cAudioRepacker wunderbar reproduzieren: Aufnahme auf hda starten und gleichzeitig "mkfs.ext3 /dev/hdc1" aufrufen. Dann rappelt es nur so von cAudioRepacker-Fehlern - mehrere die Sekunde und das kontinuierlich.

Ich habe auch die Kernel-Einstellungen
CONFIG_HZ_1000=y
CONFIG_HZ=1000
probiert. Allerdings kann ich die Fehler wie gerade beschrieben reproduzieren. Muss ich evtl. noch etwas auswählen (Scheduler)?

Hi,

das mit dem scheduler ist sicherlich eine gute idee:

probiere mal:

"echo deadline > /sys/block/hda/queue/scheduler"

bzw

"echo anticipatory > /sys/block/hda/queue/scheduler"

Ich glaube seid dem 2.6.13-er Kernel ist der default-scheduler auf den cfq geändert worden.

ansonsten könntest Du noch probieren die Prioritäten der Writes zu erhöhen:
(nur möglich wenn der scheduler auf deadline oder anticipatory gesetzt ist)
echo 500 > /sys/block/hda/queue/iosched/write_expire

falls Du kein sysfs gemountet hast:

"mkdir /sys; mount none /sys -t sysfs"

Zitat

Original von TeeRose
cAudioRepacker tritt ebenfalls nur noch vereinzelt auf. Interessanterweise in folgendem Zusammenhang:

Code

Oct 31 20:53:02 vdr /USR/SBIN/CRON[5997]: (mail) CMD (  if [ -x /usr/lib/exim/exim3 -a -f /etc/exim/exim.conf ]; then /usr/lib/exim/exim3 -q ; fi)
Oct 31 20:53:02 vdr kernel: hda: dma_intr: status=0x51 { DriveReady SeekComplete Error }
Oct 31 20:53:02 vdr kernel: hda: dma_intr: error=0x84 { DriveStatusError BadCRC }
Oct 31 20:53:02 vdr kernel: ide: failed opcode was: unknown
Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 54 bytes to sync on next audio frame
Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 386 bytes to sync on next audio frame
Oct 31 20:53:02 vdr vdr[2141]: cAudioRepacker(0xC0): skipped 232 bytes to sync on next audio frame

Kann mir jemand sagen, was meine Platte hda da für ein Problem hat? DMA ist aktiviert und smartctl hatte bei den letzten Sichtungen nichts ergeben. Da werde ich heute abend aber noch mal genau schauen.

Dasselbe Problem hatte ich auch. Bei mir lags daran, dass das Board und die Platte nur mit UltraDMA 3 fehlerfrei zusammenarbeiten. Alle höheren DMA-Einstellungen führen zu den SeekComplete und BadCRC-Fehlern. In Folge dessen bekommt der VDR keine Daten mehr und der AudioRepacker muss ran.

Also hab ich hdparm -m16 -d1 -X67 -c3 -k1 /dev/hda in die Start-Skripte eingebaut & nun läufts problemlos.

Viele Grüße,
Alex

Ich werde die letzten beiden Tipps mal probieren.

Wenn ich den UDMA-Modus ändere, brauch ich dann bei Einstellungen > UMDA-2 nicht auch ein 80-adriges IDE-Kabel?
Mein Board kann zumindest Ultra-ATA/66, also UDMA-4 mit 66,6 MByte/s.

Meine derzeitge Einstellung der beiden Platten ist "hdparm ... -c1". Kann dass vielleicht die Ursache sein? Der Modus 3 scheint eine Synchronisierung zu sein, die etwas mehr Ressourcen frisst, aber stabiler sein könnte. Deute ich die man page von hdparm richtig?

-c     Query/enable  (E)IDE  32-bit I/O support.  A numeric parameter can be used to enable/disable 32-bit
       I/O support: Currently supported values include 0 to disable 32-bit I/O support, 1 to enable 32-bit
       data transfers, and 3 to enable 32-bit data transfers with a special sync sequence required by many
       chipsets.  The value 3 works with nearly all 32-bit IDE chipsets, but incurs  slightly  more  over-
       head.   Note  that  "32-bit" refers to data transfers across a PCI or VLB bus to the interface card
       only; all (E)IDE drives still have only a 16-bit connection over the ribbon cable from  the  inter-
       face card.

Ich habe einiges probiert:

hdparm -c3 ... bringt nichts bei mir.

hdparm -X68 ... kann ich nicht einstellen, da gibt es im syslog die Meldung "kernel: ide0: Speed warnings UDMA 3/4/5 is not functional". Ich werde mal zwei 80polige IDE Kabel besorgen, um auf UDMA-4 gehen zu können. Vielleicht ist das die Lösung.

Dann habe ich noch probiert, die Platten am IDE umzubauen:
Platte 1 (hda) & Platte 2 (hdc): Fehler mit Meldung cAudioRepacker
Platte 1 (hda) & Platte 2 (hdd): Fehler mit Meldung cAudioRepacker
Platte 1 (hda) & Platte 2 (hdb): noch keine Fehler nach Tests, die bisher reproduzierbar waren. Ich benutze nach wie vor 40polige Kabel. Vielleicht ist bei meinem Borad irgendwas mit dem 2. IDE-Port nicht in Odnung.

Zitat

Original von Pilotfish
.. auch klötzchen wenn ich mit der SS2 live kucke, ich tippe auf ein Treiberproblem.

Ich weiß nicht, ob man mal eben einen älteren Treiber für nen 2.6er kernel übersetzen und installieren kann, muss heute Abend mal kucken.

das selbe problem habe ich auch mit meiner ss2, sobald meine festplatten belastet werden, habe ich diese klötzchen.
das problem scheint ab der kernelversion 2.6.13(12?) und 2.6.14 einzusetzen.
unter gentoo läuft die karte mit den 2.6.11er kernel auf jedenfall tadellos. das dumme ist nur, das ich unter archlinux nicht downgraden kann, da mir gcc 4.0.2 bei einem kernel < 2.6.13 einen schrottigen code prdouziert und den vorgang abbricht und auf ein rollback möchte ich verzichten.

Zitat

Original von All-Ex

Also hab ich hdparm -m16 -d1 -X67 -c3 -k1 /dev/hda in die Start-Skripte eingebaut & nun läufts problemlos.

Viele Grüße,
Alex

danke genau das hat mir geholfen!

Nachdem ich die beiden Platten als hda und hdb am ersten IDE-Port mit einem 80poligem Kabel habe, sind die Fehler zurückgegeangen, aber noch nicht komplett eliminiert. Ich betreibe die beiden Platten nun mittels "hdparm -X68 ..." nun im UDMA-4-Modus.

Kernel ist nach wie vor 2.6.14.