(gelöst) gpioirq DMA RX buffer overflow

Zitat

Original von Ingöö
hat mann eine möglichkeit nach einem neustart an den alten log zu kommen?

Der Syslog-Deamon wird in der /etc/init.d/rcStart gestartet:

# logging
progress 70 "starting syslog"
execute klogd -c 1
if [ x$RINGBUFFER_SYSLOG == x"no" ]; then
  execute syslogd -O /var/log/messages
else
  execute syslogd -C
  echo "HINT: LinVDR is using the busybox syslogd." > /var/log/messages
  echo "Type \"logread\" or \"logread -f\" to see syslog messages." >> /var/log/messages
fi

Die Variable RINGBUFFER_SYSLOG="?" wird in der /etc/syconfig eingestellt.
Steht die Variable auf "no" wird syslogd -O ausgeführt,
steht sie auf irgnedwas anderes ausser "no", oder ist garnicht vorhanden wird syslogd -C ausgeführt.

syslogd [OPTION]...
Linux system and kernel logging utility.
Options:
        -O FILE         Use an alternate log file (default=/var/log/messages)
        -C [size(KiB)]  Log to a circular buffer (read the buffer using logread)

Kurz gesagt mit dem Eintrag RINGBUFFER_SYSLOG="no" in deiner /etc/sysconfig, wird das Syslog in die Datei geschrieben die hinter syslogd -O in der Datei /etc/init.d/rcStart angegeben ist.

Das reicht jedeoch nicht aus um nach einen Reset des VDRs auf das alte Syslog zugreifen zu können.
Denn der Ornder /var/log ist ein Link nach /ramdisk.
Der Inhalt der Ramdisk wird nur bei dem sauberen runterfahren nach /var/cache/ramdisk kopiert.
Wenn man nun seine Syslog auch nach einem Reset oder Absturtz lesen möchte, muss man zusätzlich in der /etc/init.d/rcStart die Zeile execute syslogd -O /var/log/messages in (z.B.) execute syslogd -O /var/messages umändern.

Das kommt glaube ich von nem überarbeiteten DVB Treiber ... such mal nach refactoring ...

Ist aber nicht dramatisch und kann unbesorgt ignoriert werde!

Lg
Roman

Hallo Leute.

Seit dem Einbau einer zweiten Festplatte bekomme ich ebenfalls "gpioirq DMA RX buffer overflow". Ich habe herausgefunden das der DMA der ersten Festplatte deaktiviert ist. Aktiviert man ihn (hdparm -d1 /dev/hda) taucht der Fehler nicht mehr auf. Das seltsame ist nun aber, dass der DMA der Festplatten ja eigentlich automatisch beim Start des Systems aktiviert wird. Dies funktioniert zwar für die zweite Festplatte, nicht aber für die erste. Eine Überprüfung zeigt das der DMA deaktiviert ist.
Hat jemand von euch jemand eine Idee woran das liegen könnte? Danke.

Viele Grüße
Andreas

Ich hab jetzt mal das festplatten-Kabel gegen ein kürzeres ausgetauscht und LinVDR neu installiert. Bis jetzt siehts gut aus. Der DMA bleibt aktiviert und der qpioirq-Fehler ist noch nicht wieder aufgetaucht..

Grüße
Andreas

Aktueller Status des Problems:
Die Fehlerhäufigkeit hat zwar abgenommen, aber leider passiert es hin und wieder doch noch aus unerfindlichen Gründen das sich der DMA der Festplatten abschaltet, bzw. vom System abgeschaltet wird. Ich habe nun einen Workaround geschaffen der auch ganz gut funktioniert: Ich prüfe minütlich per Cron-Job ob der DMA noch aktiviert ist und setze ihn dann ggf. wieder.

Viele Grüße
Andreas

Die Probleme kommen mir ziemlich bekannt vor. Mein VDR hängt sich sehr oft bei Aufnahmen auf. Bei dem jetzt angeschlossenen Monitor bekomme ich die gleiche Meldung, allerdings habe ich Mahlzeit 4.0 beta2 ausprobiert da war es ganz oft und jetzt mit der Aktuellen easyvdr ist es nicht so oft aber nicht behoben. Habe mal gelesen es sollte mit dem aktuellen Dr. Seltsam Kernel behoben sein, bin mir aber nicht sicher, könntest Du mal den cron job script posten ich würde es mal gerne testen.

Ich habe folgende beiden Zeilen für meine beiden Festplatten an die crontab angefügt:

0-59/1  *      *     *     *     hdparm /dev/hda | grep "using_dma    =  0" && hdparm -d1 /dev/hda
0-59/1  *      *     *     *     hdparm /dev/hdb | grep "using_dma    =  0" && hdparm -d1 /dev/hdb

Somit werden die beiden hdparm-Anweisungen minütlich ausgeführt und nur (wichtig) wenn der DMA auf Null gesetzt ist (Off) wird er aktiviert.

Viele Grüße
Andreas