dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1

Zitat

Original von Briandorling
bei mir tritt der OOPS auf:

Code

Apr 15 21:12:36 brian kernel: DEBI irq oops @ 514305, psr:0x00040728, ssr:0x00805020                                    
Apr 15 21:24:57 brian kernel: DEBI irq oops @ 699576, psr:0x00040628, ssr:0x00805030

Die Ursache für die DEBI-Interrupts sind Timeouts. Wenn solche Probleme auftreten, könnte man mal ein paar Waits beim Zugriff auf das DPRAM einfügen:

diff -r 6aa6656852cb linux/drivers/media/dvb/ttpci/av7110_hw.h
--- a/linux/drivers/media/dvb/ttpci/av7110_hw.h Wed Apr 16 13:13:15 2008 -0300
+++ b/linux/drivers/media/dvb/ttpci/av7110_hw.h Fri Apr 18 20:42:57 2008 +0200
@@ -5,9 +5,11 @@


 /* DEBI transfer mode defs */


-#define DEBINOSWAP 0x000e0000
-#define DEBISWAB   0x001e0000
-#define DEBISWAP   0x002e0000
+#define DEBI_TIMEOUT 1
+
+#define DEBINOSWAP (0x000e0000 | ((DEBI_TIMEOUT) << 22))
+#define DEBISWAB   (0x001e0000 | ((DEBI_TIMEOUT) << 22))
+#define DEBISWAP   (0x002e0000 | ((DEBI_TIMEOUT) << 22))


 #define ARM_WAIT_FREE  (HZ)
 #define ARM_WAIT_SHAKE (HZ/5)




diff -r 6aa6656852cb linux/include/media/saa7146.h
--- a/linux/include/media/saa7146.h     Wed Apr 16 13:13:15 2008 -0300
+++ b/linux/include/media/saa7146.h     Fri Apr 18 20:42:57 2008 +0200
@@ -208,7 +208,8 @@ int saa7146_wait_for_debi_done(struct sa
 #define SAA7146_GPIO_OUTHI 0x50


 /* debi defines */
-#define DEBINOSWAP 0x000e0000
+#define DEBI_TIMEOUT   1
+#define DEBINOSWAP (0x000e0000 | ((DEBI_TIMEOUT) << 22))


 /* define for the register programming sequencer (rps) */
 #define CMD_NOP                0x00000000  /* No operation */

Gruß
e9hack

Zitat

Original von e9hack

Die Ursache für die DEBI-Interrupts sind Timeouts. Wenn solche Probleme auftreten, könnte man mal ein paar Waits beim Zugriff auf das DPRAM einfügen:

DEBI-Timeouts sind sehr ungewöhnlich. Hat so etwas sonst schon jemand mal gesehen?
Imho muß man hier ein HW-Problem in Betracht ziehen.

Was für eine Maschine ist das ganz genau?
- Hardware, CPU, Chipsatz?
- Kernel-Version?
- falls HG-Treiber, welchen Datums?

In jedem Fall würde ich zunächst einmal die F12623 Firmware einspielen (obwohl es damit eigentlich nicht zusammenhängen kann).

CU
Oliver

Zitat

Original von UFO
DEBI-Timeouts sind sehr ungewöhnlich.

Zwischen SAA7146 und DPRAM (CY7C024V-25) hängt noch ein PAL von Lattice. Bei 33MHz Clock wird es mit dem Timing schon eng. Grenzwertige Karten könnten da Probleme haben.

Gruß
e9hack

Zitat

Original von e9hack

Zwischen SAA7146 und DPRAM (CY7C024V-25) hängt noch ein PAL von Lattice. Bei 33MHz Clock wird es mit dem Timing schon eng. Grenzwertige Karten könnten da Probleme haben.

Hm - das ist mir neu. Wo ist dieses PAL?

Aber 33 MHz ist ein gutes Stichwort.
Briandorling:
Du hast den PCI-Bus hoffentlich nicht übertaktet?

CU
Oliver

Zitat

Original von UFO

Hm - das ist mir neu. Wo ist dieses PAL?

Ich gehe jetzt von einer TT-C2300 aus. Da sitzt zwischen SAA7146 und DPRAM ein iM4A3-32/10VC von Lattice.

Gruß
e9hack

HI,

ich habe nichts übertaktet. Karte ist eine TT-FF DVB-S Rev 1.5.,
und eine Nova-S.
Es läuft einwandfrei unter VDR 1.3.24 und früheren DVB treiber.

Hardware ist ASUS TUSL2-C mit Celeron 1400, läuft seit ca 4 jahre.

MfG

Zitat

Original von e9hack

Ich gehe jetzt von einer TT-C2300 aus. Da sitzt zwischen SAA7146 und DPRAM ein iM4A3-32/10VC von Lattice.

Ok, dann ist das wieder was Spezielles bei der TT-C2300.
Die SAT-Karten haben so etwas offenbar nicht.

CU
Oliver

Zitat

Original von Briandorling
Es läuft einwandfrei unter VDR 1.3.24 und früheren DVB treiber.

Sorry, damit kann man nichts anfangen.

CU
Oliver

Zitat

Original von UFO
Ok, dann ist das wieder was Spezielles bei der TT-C2300.
Die SAT-Karten haben so etwas offenbar nicht.

Wenn ich mir Deine Bilder vom FullTS-Mod anschaue, gibts aber auch bei den SAT-Karten noch Chips zwischen SA7146 und DPRAM. Wenn die um ca. 5ns verzögern, ist man bei 33MHz schon an der Grenze.

Gruß
e9hack

Zitat

Original von e9hack

Wenn ich mir Deine Bilder vom FullTS-Mod anschaue, gibts aber auch bei den SAT-Karten noch Chips zwischen SA7146 und DPRAM. Wenn die um ca. 5ns verzögern, ist man bei 33MHz schon an der Grenze.

2x LVC574A und 1x LVC00A, dienen zum Demuxen des AD-Busses.
Hm - 33 MHz sind 30ns Zykluszeit.

Würde aber dennoch nicht erklären, wieso es mit alten Treibern funktioniert.

CU
Oliver

Zitat

Original von Briandorling
bin gerade dabei von Kernel 2.4.27 und VDR 1.3.24 aufzurüsten.
[........]
Es läuft einwandfrei unter VDR 1.3.24 und früheren DVB treiber.

Hardware ist ASUS TUSL2-C mit Celeron 1400, läuft seit ca 4 jahre.

Ich würde mal auf den Kernel (nicht die DVB-Module) als Ursache tippen, da hat sich im Vergleich zum 2.4er einiges geändert. Auch im Bereich APIC und ACIP wurde einiges getan, das kann schon was am Verhalten ändern.
Das Mainboard ist auch so alt, dass es da noch Probleme mit fehlerhaften BIOSen geben könnte.

Was ich versuchen würde währe folgendes und auch in der Reihenfolge:
"P&P-OS" einstellung im BIOS ändern.
Neuestes BIOS installieren.
APIC und/oder ACPI testweise abschalten (Kernelparameter).

Ich habe solche Timeouts auch sporadisch, bevorzugt beim Beenden von Musikwiedergabe (mp3,music) über Menü->Wiedergabe beenden (mit F21623 wie auch mit F22623).
Ich vermute dass sich der Treiber bei neuerer Firmware zu sehr darauf verlaesst, dass die Queues nach einem Timeout wieder aufgeräumt werden. Der ReleaseBitmap nach dem Timout kommt zwar ohne Fehler zurück, aber es wird kein Firmwarekommando mehr wirklich abgearbeitet. Das macht dieses Problem ja auch so unangenehm, dass nur Neuladen des ttpci-Treibers hilft.
VDR selber ignoriert einen Returncode des osd-ioctls und sollte normal bedienbar bleiben.
Es gab mal in der ML einen Beitrag von Werner Fink, dass bei gefüllter OSD-Queue andere Kommandos verloren gehen können und danach der Status nicht mehr stimmen muss.
Spätestens zum Entladen kommt immer auch "busy MSG QUEUE"
Alles Vermutungen ... und in den letzten drei Wochen, seit ich mehr Debugging im Treiber eingebaut habe (aber auch sonst ändert sich immer so viel an den Einstellungen), hatte ich selbst mit dem neuen muggle-Plugin keine Timeouts.

Zitat

Original von TomJoad
Ich habe solche Timeouts auch sporadisch, bevorzugt beim Beenden von Musikwiedergabe (mp3,music) über Menü->Wiedergabe beenden (mit F21623 wie auch mit F22623).

Verwenden diese Plugins das OSD schwerpunktmäßig für Animationen o.ä.?

Zitat

Ich vermute dass sich der Treiber bei neuerer Firmware zu sehr darauf verlaesst, dass die Queues nach einem Timeout wieder aufgeräumt werden. Der ReleaseBitmap nach dem Timout kommt zwar ohne Fehler zurück, aber es wird kein Firmwarekommando mehr wirklich abgearbeitet. Das macht dieses Problem ja auch so unangenehm, dass nur Neuladen des ttpci-Treibers hilft.

Werner hat (vor langer Zeit) diese Timeout-Geschichte in die FW eingebaut. Zusammen mit der entsprechenden Treiberanpassung sollte die FW wieder auf die Füße kommen, auch wenn ein OSD-Timeout auftritt. War der Meinung, daß dieses Problem gegessen wäre.

Möglicherweise gibt es in Verbindung mit reiner Audio-Wiedergabe da noch ein Problem?
Tritt das Problem auch beim Abspielen von Video-Aufzeichnungen auf?

Zitat

VDR selber ignoriert einen Returncode des osd-ioctls und sollte normal bedienbar bleiben.
Es gab mal in der ML einen Beitrag von Werner Fink, dass bei gefüllter OSD-Queue andere Kommandos verloren gehen können und danach der Status nicht mehr stimmen muss.
Spätestens zum Entladen kommt immer auch "busy MSG QUEUE"
Alles Vermutungen ... und in den letzten drei Wochen, seit ich mehr Debugging im Treiber eingebaut habe (aber auch sonst ändert sich immer so viel an den Einstellungen), hatte ich selbst mit dem neuen muggle-Plugin keine Timeouts.

Bin schon etwas überrascht, daß die Sache nach so langer Zeit wieder hoch kommt. Hatte den Fehler nur noch in Verbindung mit ARM-Crashes infolge schlechten/fehlenden Signals gesehen.

Habe ich das richtig verstanden:
Das OSD funktioniert nach diesem Fehler nicht mehr, d.h. es wird auch nach einer Wartezeit von - sagen wir mal 30s - nicht mehr operational?

CU
Oliver

Zitat

Verwenden diese Plugins das OSD schwerpunktmäßig für Animationen o.ä.?

mp3 waehrend der Wiedergabe ueberhaupt nicht, music verwendet das OSD schon intensiv mit cover-Ausgabe usw

Zitat

Tritt das Problem auch beim Abspielen von Video-Aufzeichnungen auf?

Habe ich bei mir noch nie beobachtet

Zitat

Das OSD funktioniert nach diesem Fehler nicht mehr, d.h. es wird auch nach einer Wartezeit von - sagen wir mal 30s - nicht mehr operational?

Nicht nur das OSD wird nicht mehr operational, ich habe es auch nie geschafft, den VDR blind zu bedienen. Wenn es wieder auftritt, wollte ich mal remote mit svdrpl schauen, was noch geht.
Das ganze scheint mit irgendwelchen VDR-Einstellungen wahrscheinlicher zu sein, aber mit welchen?

Was auch eine Rolle spielen kann, ist der EPG-Scan, der bei Wiedergabe im Hintergrund gestartet wird. Der könnte das Timing in Treiber/Firmware beeinflussen.

Hallo,

habe hier das gleiche Problem, seit mir mein Bekannter Full-TS u. 4MB Mod gemacht hat. Ich muss aber dazu sagen, dass er vergessen hat den 8-en Pin hochzubiegen, das habe leider auch viel zu spät gesehen, als ich gar kein OSD gekriegt habe. Nachdem ich aber diesen Pin (8) selber entlötet habe, kriege ich sehr oft diese Fehlermeldungen im Log:

Apr 19 18:36:33 vdr vdr: [4136] dvbplayer thread started (pid=4064, tid=4136)
Apr 19 18:36:33 vdr vdr: [4136] resuming replay at index 67212 (0:44:48.13)
Apr 19 18:36:33 vdr vdr: [4137] non blocking file reader thread started (pid=4064, tid=4137)
Apr 19 18:36:33 vdr vdr: [4136] SetBrokenLink: no GOP header found in video packet
Apr 19 18:36:33 vdr vdr: [4136] setting audio track to 1 (0)
Apr 19 18:36:33 vdr vdr: [4138] Text2Skin: replayInfo display update thread started (pid=4064, tid=4138)
Apr 19 18:36:35 vdr vdr: [4138] Text2Skin: replayInfo display update thread ended (pid=4064, tid=4138)
Apr 19 18:36:35 vdr vdr: [4137] non blocking file reader thread ended (pid=4064, tid=4137)
Apr 19 18:36:35 vdr vdr: [4136] dvbplayer thread ended (pid=4064, tid=4136)
Apr 19 18:36:35 vdr vdr: [4139] Text2Skin: menu display update thread started (pid=4064, tid=4139)
Apr 19 18:36:36 vdr vdr: [4064] switching to channel 15
Apr 19 18:36:38 vdr vdr: [4139] Text2Skin: menu display update thread ended (pid=4064, tid=4139)
Apr 19 18:36:38 vdr vdr: [4064] loading /video0/Power_Rangers_Operation_Overdrive/2008-04-19.15.40.50.99.rec//marks.vdr
Apr 19 18:36:38 vdr vdr: [4064] replay /video0/Power_Rangers_Operation_Overdrive/2008-04-19.15.40.50.99.rec
Apr 19 18:36:38 vdr vdr: [4064] playing '/video0/Power_Rangers_Operation_Overdrive/2008-04-19.15.40.50.99.rec/001.vdr'
Apr 19 18:36:38 vdr vdr: [4064] loading /video0/Power_Rangers_Operation_Overdrive/2008-04-19.15.40.50.99.rec//marks.vdr
Apr 19 18:36:38 vdr vdr: [4140] dvbplayer thread started (pid=4064, tid=4140)
Apr 19 18:36:38 vdr vdr: [4140] PlayJump: start replay at first mark 12 (0:00:00.13)
Apr 19 18:36:38 vdr vdr: [4141] non blocking file reader thread started (pid=4064, tid=4141)
Apr 19 18:36:38 vdr vdr: [4140] SetBrokenLink: no GOP header found in video packet
Apr 19 18:36:38 vdr vdr: [4140] setting audio track to 1 (0)
Apr 19 18:36:39 vdr vdr: [4142] Text2Skin: replayInfo display update thread started (pid=4064, tid=4142)
Apr 19 18:37:04 vdr vdr: [4142] Text2Skin: replayInfo display update thread ended (pid=4064, tid=4142)
Apr 19 18:37:07 vdr vdr: [4064] ERROR (dvbdevice.c,1104): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:07 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:07 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:07 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:08 vdr vdr: [4064] ERROR (dvbdevice.c,1105): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:08 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:08 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:08 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:09 vdr vdr: [4064] ERROR (dvbdevice.c,1059): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:09 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:09 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:09 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:09 vdr vdr: [4143] Text2Skin: replaySmall display update thread started (pid=4064, tid=4143)
Apr 19 18:37:10 vdr vdr: [4064] ERROR (dvbdevice.c,1079): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:10 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:10 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:10 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:11 vdr vdr: [4064] ERROR (dvbdevice.c,1081): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:11 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:11 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:11 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:12 vdr vdr: [4064] ERROR (dvbdevice.c,1094): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:12 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:12 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:12 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:13 vdr vdr: [4064] ERROR (dvbdevice.c,1079): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:13 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:13 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:13 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:14 vdr vdr: [4064] ERROR (dvbdevice.c,1081): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:14 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:14 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:14 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:15 vdr vdr: [4064] ERROR (dvbdevice.c,1094): Die Wartezeit für die Verbindung ist abgelaufen
Apr 19 18:37:15 vdr kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Apr 19 18:37:15 vdr kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Apr 19 18:37:15 vdr kernel: dvb-ttpci: av7110_fw_cmd error -110
Apr 19 18:37:25 vdr kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
Apr 19 18:37:25 vdr vdr: [4143] Text2Skin: replaySmall display update thread ended (pid=4064, tid=4143)
Apr 19 18:37:25 vdr vdr: [4144] Text2Skin: replaySmall display update thread started (pid=4064, tid=4144)
Apr 19 18:37:25 vdr vdr: [4064] max. latency time 10 seconds
Apr 19 18:37:35 vdr kernel: dvb-ttpci: warning: timeout waiting in LoadBitmap: 0, 1
Apr 19 18:39:44 vdr shutdown[4200]: shutting down for system reboot
Apr 19 18:39:44 vdr init: Switching to runlevel: 6
Apr 19 18:39:46 vdr vdr: [4082] ERROR: lircd connection broken, trying to reconnect every 3,0 seconds
Apr 19 18:39:47 vdr vdr: [4064] caught signal 15
Apr 19 18:39:47 vdr vdr: [4064] stopping plugin: crcs

Nach diesen Fehler hilft nur reboot.

DMESG:

ACPI: PCI Interrupt Link [ALKC] enabled at IRQ 22
ACPI: PCI Interrupt 0000:00:11.5[C] -> Link [ALKC] -> GSI 22 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:11.5 to 64
Adding 1253028k swap on /dev/hdc5.  Priority:-1 extents:1 across:1253028k
EXT3 FS on hdc1, internal journal
Linux video capture interface: v2.00
saa7146: register extension 'dvb'.
ACPI: PCI Interrupt 0000:00:08.0[A] -> GSI 16 (level, low) -> IRQ 19
saa7146: found saa7146 @ mem dc88e000 (revision 1, irq 19) (0x13c2,0x000e).
DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-S rev2.3)
adapter has MAC addr = 00:d0:5c:05:17:39
dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app c0f12623
dvb-ttpci: firmware @ card 0 supports CI link layer interface
dvb-ttpci: Crystal audio DAC @ card 0 detected
saa7146_vv: saa7146 (0): registered device video0 [v4l2]
saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
DVB: registering frontend 0 (ST STV0299 DVB-S)...
input: DVB on-card IR receiver as /class/input/input2
dvb-ttpci: found av7110-0.
cx88/2: cx2388x MPEG-TS Driver Manager version 0.0.6 loaded
cx88[0]: subsystem: 14f1:0084, board: Geniatech DVB-S [card=52,autodetected]
cx88[0]: TV tuner type 4, Radio tuner type -1
cx88[0]/2: cx2388x 8802 Driver Manager
ACPI: PCI Interrupt 0000:00:09.2[A] -> GSI 17 (level, low) -> IRQ 20
cx88[0]/2: found at 0000:00:09.2, rev: 5, irq: 20, latency: 32, mmio: 0xdf000000
cx88/2: cx2388x dvb driver version 0.0.6 loaded
cx88/2: registering cx8802 driver, type: dvb access: shared
cx88[0]/2: subsystem: 14f1:0084, board: Geniatech DVB-S [card=52]
cx88[0]/2: cx2388x based DVB/ATSC card
CX24123: detected CX24123
DVB: registering new adapter (cx88[0])
DVB: registering frontend 1 (Conexant CX24123/CX24109)...
saa7146: register extension 'budget_av'.
ACPI: PCI Interrupt 0000:00:0a.0[A] -> GSI 18 (level, low) -> IRQ 21
saa7146: found saa7146 @ mem dcab8000 (revision 1, irq 21) (0x153b,0x1176).
saa7146 (1): dma buffer size 192512
DVB: registering new adapter (Terratec Cinergy 1200 DVB-C MK3)
adapter failed MAC signature check
encoded MAC from EEPROM was ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff:ff
KNC1-2: MAC addr = 00:0a:ac:11:3b:22
DVB: registering frontend 2 (Philips TDA10023 DVB-C)...
budget-av: ci interface initialised.
Non-volatile memory driver v1.2
i2c-adapter i2c-3: SMBus Quick command not supported, can't probe for chips
it87: Found IT8705F chip at 0x290, revision 2
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hdd1, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
eth1: link up, 100Mbps, full-duplex, lpa 0x45E1

Den Full-TS Mod habe ich erstmal deaktiviert.

Mein System:
Debian Etch
VDR 1.6.0
TT S2300 V 2.3 "modded"

Kann man da was machen? Bzw. ist der RAM jetzt defekt?

Danke.

Zitat

Original von TomJoad
Nicht nur das OSD wird nicht mehr operational, ich habe es auch nie geschafft, den VDR blind zu bedienen. Wenn es wieder auftritt, wollte ich mal remote mit svdrpl schauen, was noch geht.
Das ganze scheint mit irgendwelchen VDR-Einstellungen wahrscheinlicher zu sein, aber mit welchen?

Bedienung per svdrp ist dann bei mir :modontot, oder es dauert Minuten, bis vdr reagiert. Zum Reproduzieren dieses Problems starte ich den neuen muggle, gehe ins Player OSD und dann:

send() {
        echo -e "hitk $1 \nQUIT" | nc localhost 2001
}


# assume no shuffle, no repeat:
send red
send 1
send red
send 2
send red
send 2
while true
do
        key=green
        test $RANDOM -gt 12000 && key=yellow
        send $key
        sleep 0.$RANDOM
        sleep 0.$RANDOM
done

Nur - seit vorgestern kam der Fehler gar nicht mehr. Keine Ahnung,
warum.

Hat sonst jemand auch folgende Meldungen - gibt es da einen zeitlichen Zusammenhang? Und überhaupt - was bedeuten sie?

Apr 19 18:07:11 server kernel: saa7146 (1) vpeirq: used 2 times >80% of buffer (65424 bytes now)

Zitat

Original von TomJoad
Was auch eine Rolle spielen kann, ist der EPG-Scan, der bei Wiedergabe im Hintergrund gestartet wird. Der könnte das Timing in Treiber/Firmware beeinflussen.

Stichwort EPG-Scan:
Man sollte prüfen, ob man in der channels.conf "tote" Kanäle hat, d.h. Frequenzen, auf denen nicht (mehr) gesendet wird. Erkennen kann man diese an Frontend-Timeout-Meldungen im Log beim EPG-Scan bzw. am fehlenden Signal in Femon.

Der Decoder der FF-Karte crasht nämlich gern, wenn er mit ungültigen Daten gefüttert wird. So etwas könnte evtl. einen Crash beim Beenden der Wiedergabe erklären.

CU
Oliver

Jetzt habe ich das Problem mal bei laufendem music-Plugin gehabt. VDR läßt sich nur stark verzögert über das graphlcd-Display bedienen, da lies sich music auch beenden und auf Kanäle schalten, am TV erscheint aber weiter ein leerer Hintergrundbild von music und es gibt kein Live-Bild bzw. Ton.
Meldungen in der messages:

Apr 20 11:40:23 (none) user.err vdr: [4703] music: player: player thread ended (p
id=4703)
Apr 20 11:40:24 (none) user.err vdr: [4658] ERROR (dvbdevice.c,1077): Die Wartezeit für die Verbindung ist abgelaufen
Apr 20 11:40:25 (none) user.err vdr: [4658] ERROR (dvbdevice.c,1078): Die Wartezeit für die Verbindung ist abgelaufen
Apr 20 11:40:25 (none) user.err vdr: [4658] switching to channel 2
Apr 20 11:40:26 (none) user.err vdr: [4658] ERROR (dvbdevice.c,784): Die Wartezeit für die Verbindung ist abgelaufen
Apr 20 11:40:28 (none) user.err vdr: [4658] ERROR (dvbdevice.c,953): Die Wartezeit für die Verbindung ist abgelaufen
Apr 20 11:40:29 (none) user.err vdr: [4658] ERROR (dvbdevice.c,956): Die Wartezeit für die Verbindung ist abgelaufen
Apr 20 11:40:30 (none) user.err vdr: [4658] ERROR (dvbdevice.c,989): Die Wartezeit für die Verbindung ist abgelaufen
Apr 20 11:40:31 (none) user.err vdr: [4658] ERROR (dvbdevice.c,989): Die Wartezeit für die Verbindung ist abgelaufen
Apr 20 11:40:31 (none) user.err vdr: [4658] max. latency time 30 seconds
Apr 20 11:43:02 (none) user.err vdr: [4658] switching to channel 3
Apr 20 11:43:03 (none) user.err vdr: [4658] ERROR (dvbdevice.c,784): Die Wartezeit für die Verbindung ist abgelaufen

Kernelmeldungen siehe Anhang

Zitat

Original von neptunvasja
habe hier das gleiche Problem, seit mir mein Bekannter Full-TS u. 4MB Mod gemacht hat. Ich muss aber dazu sagen, dass er vergessen hat den 8-en Pin hochzubiegen, das habe leider auch viel zu spät gesehen, als ich gar kein OSD gekriegt habe. Nachdem ich aber diesen Pin (8) selber entlötet habe, kriege ich sehr oft diese Fehlermeldungen im Log:
...

Wenn ich so etwas lese, bekomme ich Bauchschmerzen.

1. Es geht um Pin 18, nicht um Pin 8!
2. Pin 18 des oberen RAMs ist hoffentlich mit dem richtigen Signal am ARM verbunden?

Zitat

Den Full-TS Mod habe ich erstmal deaktiviert.

Hat damit nichts zu tun.

Zitat

Kann man da was machen? Bzw. ist der RAM jetzt defekt?

Zunächst mal würde ich _genauestens_ prüfen (d.h. messen), ob die Verbindungen des oberen RAM mit dem unteren 100% ok sind. Ebenso die Verbindung zum ARM.

Generell ist es schlecht, wenn man Ausgänge zusammenschaltet und diese dann gegeneinander arbeiten. Insofern mache ich mir mehr Sorgen um die CS-Ausgänge des ARM als die SDRAMs. K.A. ob da etwas kaputt gegangen ist. Ich würde erst mal alles genauestens überprüfen und hoffen, daß nichts passiert ist...

CU
Oliver