av7110_debiread: wait_for_debi_done #1 failed (solved)

bandi · 21. August 2007

Hi,

ich habe mir einen neuen (VDR-) Rechner zusammengebaut und habe damit folgendes Probelm:
Beim Abspielen einer VDR-Aufnahme oder der Wiedergabe per MPlayer (Plugin) über meine FF-DVB-S-Karte habe ich gelegentlich Aussetzer von teilweise vielen Sekunden. Falls parallel Aufnahmen (auf anderen DVB-Karten) laufen, haben diese auch entsprechende Aussetzer.

Meine Kiste im Überblick:
- ASUS M2V + AMD Athlon X2 BE-2300 (64bit / 1,9GHz / 45W)
- 1x TT FF DVB-S 2.3
- 2x TT Budget DVB-S
- SuSE 10.2 + 2.6.22.3-16
- VDR 1.4.7 (+ wenige Plugins)

Im Syslog sehe ich passend dazu folgende Meldungen:
Aug 20 23:04:30 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 20 23:04:39 vdr vdr: [21834] PES packet shortened to 1288 bytes (expected: 1840 bytes)
Aug 20 23:04:39 vdr vdr: [21834] 2 cRepacker messages suppressed
Aug 20 23:04:39 vdr vdr: [21834] cAudioRepacker(0xC0): skipped 312 bytes to sync on next audio frame
Aug 20 23:04:39 vdr vdr: [21834] PES packet shortened to 1656 bytes (expected: 1840 bytes)
Aug 20 23:04:39 vdr vdr: [21834] PES packet shortened to 1288 bytes (expected: 1840 bytes)
Aug 20 23:04:44 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 20 23:04:44 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 20 23:04:44 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 20 23:04:44 vdr vdr: [21834] PES packet shortened to 1104 bytes (expected: 1840 bytes)
Aug 20 23:04:44 vdr vdr: [21834] PES packet shortened to 630 bytes (expected: 1550 bytes)
Aug 20 23:04:44 vdr vdr: [21834] PES packet shortened to 1182 bytes (expected: 1550 bytes)
Aug 20 23:04:44 vdr vdr: [21834] 5 cRepacker messages suppressed
Aug 20 23:04:44 vdr vdr: [21834] cDolbyRepacker: skipped 244 bytes while syncing on next AC3 frame
Aug 20 23:04:44 vdr vdr: [21834] PES packet shortened to 1472 bytes (expected: 1840 bytes)

Ich habe mehrere Kernel-Versionen durchprobiert (2.6.18.8-05 SuSE, 2.6.22.1-399 SuSE, 2.6.22.3 vanilla, 2.6.22.3-16 SuSE), um die auf dem relativ neuen Mainboard verbauten Komponenten benutzen zu können und weiß daher, daß dieses Probelem nicht mit dem momentan aktiven Kernel zusammen hängt. Ich benutze die kernelinternen DVB-Treiber, aber auch die HG-Version vom 18.08. geht nicht besser. Mit 2.6.18-05 SuSE (und den internen Treibern) bleibt der Rechner in dieser Situation ganz stehen.

Ich kann momentan noch keine Regelmäßigkeiten oder Zusammenhänge erkennen.
Die DVB-S-Karte würde ich ausschließen, da ich keinen Unterschied zwischen der alten 1.3 und der neuen 2.3 sehe. Da ich sonst keine Probleme mit dem Rechner habe, glaube ich auch nicht so richtig an ein Problem des Mainboards...

Hat irgendwer von Euch ähnliche Effekte oder sogar eine Idee, was das sein könnte?

Viele Grüße
Andreas Böttger

bandi · 21. August 2007

Heute hatte ich lange keinen Aussetzer mehr, dann aber wieder massive Probleme.
Als ich nebenbei einen neuen Kernel gebaut habe, blieb die Kiste sogar zweimal ganz stehen
Nach dem Neustart hatte ich in beiden Fällen das "av7110_bootarm(): load_dram() failed"-Problem. Zufall?

Hier noch ein Stück Syslog als Beispiel:

Aug 21 22:37:57 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 21 22:38:04 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:38:10 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 21 22:38:10 vdr kernel: dvb-ttpci: StopHWFilter error cmd 0b08 0001 0009 ret 0 resp 0009 b96a pid 2700
Aug 21 22:38:33 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:14 vdr vdr: [5226] max. latency time 22 seconds
Aug 21 22:39:29 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:36 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:39 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:40 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:40 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:40 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:40 vdr kernel: dvb-ttpci: StopHWFilter error cmd 0b08 0001 000a ret 0 resp 0000 0000 pid 1200
Aug 21 22:39:43 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:43 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:43 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 21 22:39:43 vdr kernel: dvb-ttpci: StopHWFilter error cmd 0b08 0001 000a ret 0 resp 0000 0000 pid 1800

Viele Grüße
Andreas Böttger

UFO · 22. August 2007

Nehme an, Du verwendest einen SMP-Kernel?
Kannst Du mal mit einem Nicht-SMP-Kernel testen?

CU
Oliver

bandi · 22. August 2007

Hi,

ich habe gestern abend .. ähm, nee .. heute früh die SMP-Unterstützung in meinem Kernel ausgeschaltet und bin nun gespannt... Allerdings muß ich tagsüber arbeiten, kann also erst abends wieder was ausprobieren.

Btw: Nach JEDEM Totalstillstand hatte ich bisher das "av7110_bootarm(): load_dram() failed"-Problem...

Viele Grüße
Andreas Böttger

bandi · 22. August 2007

Hi,

seit der Umstellung auf Nicht-SMP gab es keine derartigen Syslog-Einträge mehr.
Trotzdem ist die Kiste nicht stabil...

Als meine Frau heute ein Stück RTL-Mittagsjournal von Platte ansehen wollte, blieb der Rechner ohne Hinweis im Syslog stehen. Diesen Effekt konnte ich vorhin nachvollziehen.
Vorher lief Clever von Sat1 in TimeShift komplett ohne Probleme durch.
Gelegentlich reicht auch ein Umschalten zu einem anderen Kanal oder das bloße Benutzen des Menüs für einen Freeze ohne irgendwelche Hinweise im Syslog oder der "F10-Konsole"...

Eigentlich habe ich außer Mainboard und RAM alles schonmal irgendwie getauscht. Könnte es sein, daß mein Mainboard manchmal spinnt und dadurch der DVB-Treiber Schlagseite bekommt? Aber warum dann nur der DVB-Treiber und sonst nichts?
Ich könnte mir ein zweites solches Mainboard kaufen und mal wechseln...

Was könnte ich noch machen?

Viele Grüße
Andreas Böttger

UFO · 22. August 2007

Zitat

Original von bandi
seit der Umstellung auf Nicht-SMP gab es keine derartigen Syslog-Einträge mehr.
Trotzdem ist die Kiste nicht stabil...

Als meine Frau heute ein Stück RTL-Mittagsjournal von Platte ansehen wollte, blieb der Rechner ohne Hinweis im Syslog stehen. Diesen Effekt konnte ich vorhin nachvollziehen.
Vorher lief Clever von Sat1 in TimeShift komplett ohne Probleme durch.
Gelegentlich reicht auch ein Umschalten zu einem anderen Kanal oder das bloße Benutzen des Menüs für einen Freeze ohne irgendwelche Hinweise im Syslog oder der "F10-Konsole"...

Eigentlich habe ich außer Mainboard und RAM alles schonmal irgendwie getauscht. Könnte es sein, daß mein Mainboard manchmal spinnt und dadurch der DVB-Treiber Schlagseite bekommt? Aber warum dann nur der DVB-Treiber und sonst nichts?
Ich könnte mir ein zweites solches Mainboard kaufen und mal wechseln...

Was könnte ich noch machen?

Alles anzeigen

Hänger ohne Logeinträge deuten stark auf irgendein Hardware-Problem hin.

Also Standardprozedur:
- memtest über 10 oder 12 Stunden laufen lassen
- Festplatte mit dem Tool des Herstellers testen

CU
Oliver

bandi · 22. August 2007

Ok, werde ich machen.

Meinst Du, daß die SMP-Probleme evtl. Folgefehler sind?
Oder sind SMP-Schwächen bekannt?

UFO · 23. August 2007

Zitat

Original von bandi
Meinst Du, daß die SMP-Probleme evtl. Folgefehler sind?
Oder sind SMP-Schwächen bekannt?

Möglich ist beides. Es gab neulich auf der DVB-ML einen Fehlerbericht, der auf ein Problem in Verbindung mit SMP hindeutet. Ein Freeze kam dabei jedoch nicht vor.

Ich habe keine Ahnung, wie viele Leute hier SMP-Maschinen einsetzen. Entweder sind es nur wenige, oder die Probleme sind selten. Falls es ein Problem mit dem Treiber gibt, fehlt momentan jedenfalls noch der entscheidende Hinweis, in welche Richtung man suchen müßte.

CU
Oliver

bandi · 23. August 2007

Hi,

der RAM ist es nicht, zumindest hat memtest (SuSE 10.2 DVD) über Nacht nichts gefunden.
Da ich schonmal Kontaktprobleme mit SATA-Kabeln hatte, habe ich ein neues eingebaut. Die (System-)Platte ist neu, SMART ist zufrieden.
Außerdem habe ich wieder die alte DVB-S 1.3 drin, um nach nem Freeze nicht zweimal neu starten zu müssen

Aus meiner Sicht ist nun das Mainboard die wahrscheinlichste Problemquelle, zumal das Teil schon zweimal meinte, daß ich eine neue CPU eingebaut hätte. Das BIOS ist aktuell.
Wenn es dann doch nicht das Board sein sollte, hab ich eben zwei davon. Solange ich meine DVB-Karten benutzen will, brauche ich ein Board mit vielen PCI-Slots und davon hat dieses immernoch (!) vier. Ich hatte zwar anfänglich Probleme, alle Komponenten zum Laufen zu bringen, aber ich hab's geschafft

Mal sehen, ob ich heute Abend Zeit zum Schrauben finde...

Viele Grüße und erstmal danke bis hierher
Andreas Böttger

e9hack · 23. August 2007

Zitat

Original von UFO

Möglich ist beides. Es gab neulich auf der DVB-ML einen Fehlerbericht, der auf ein Problem in Verbindung mit SMP hindeutet. Ein Freeze kam dabei jedoch nicht vor.

Ich habe keine Ahnung, wie viele Leute hier SMP-Maschinen einsetzen. Entweder sind es nur wenige, oder die Probleme sind selten. Falls es ein Problem mit dem Treiber gibt, fehlt momentan jedenfalls noch der entscheidende Hinweis, in welche Richtung man suchen müßte.

Ein ARM-Crash könnte zu den Timeouts führen. Da ist auch noch eine kleine Schwäche im Treiber. Während dem Neustart des ARM wird auf das debi-Interface zugegriffen ohne dieses per Spinlock zu sperren.

Gruß
e9hack

bandi · 23. August 2007

So, hier bin ich wieder

Das neue Board ist drin. Viel Zeit zum Testen hatte ich noch nicht...

Beim Zusammenbauen des Rechners hatte ich einen seltsamen Effekt:
Zunächst wollte die Systemplatte nicht so richtig. Sie wurde zwar vom BIOS erkannt und Grub ging auch los, aber der hatte dann irgendwelche Probleme und fand schließlich keinen Kernel. Beim zweiten Anlauf hat die Kiste zwar gebootet, aber nach einigen Minuten war die Platte weg, allerdings mit entsprechenden Meldungen auf der Konsole (F10).
Daraufhin habe ich das SATA-Kabel auf beiden Seiten mehrfach ab- und wieder angesteckt und nun scheint es (erstmal?) zu laufen...
Ist diese SATA-Steckverbindung wirklich so anfällig?

Ich habs langsam bissl satt
Naja, schaumerma...

Viele Grüße
Andreas Böttger

bandi · 24. August 2007

Ich habe zwei Aufnahmen gestartet und wollte was von Platte ansehen, eigentlich kein Thema mit drei Karten...
Kurz danach stand die Kiste wieder!
Die Systemplatte (500GB Seagate) habe ich inzwischen auch nochmal mit SeaTools überprüft - alles ok.

Momentan fällt mir nichts mehr dazu ein

e9hack: Vielen Dank für den Tip. Demnach könnten die vermeintlichen SMP-Probleme durchaus Folgefehler von dem sein, was ich hier vergeblich suche?

Viele Grüße
Andreas Böttger

UFO · 24. August 2007

Zitat

Original von e9hack
Ein ARM-Crash könnte zu den Timeouts führen. Da ist auch noch eine kleine Schwäche im Treiber. Während dem Neustart des ARM wird auf das debi-Interface zugegriffen ohne dieses per Spinlock zu sperren.

Ich nehme das mal auf meine Todo-Liste.
Von einem ARM-Crash war allerdings bisher nicht die Rede. Das kann's also nicht sein.

CU
Oliver

UFO · 24. August 2007

Zitat

Original von bandi

Ich habe zwei Aufnahmen gestartet und wollte was von Platte ansehen, eigentlich kein Thema mit drei Karten...
Kurz danach stand die Kiste wieder!
Die Systemplatte (500GB Seagate) habe ich inzwischen auch nochmal mit SeaTools überprüft - alles ok.

Momentan fällt mir nichts mehr dazu ein

Alles anzeigen

Nach dem, was Du so über die Kabel-/Steckerprobleme (Wackelkontakt?) in Verbindung mit der SATA-Platte schreibst, würde ich mal eine andere Platte versuchen...

CU
Oliver

bandi · 24. August 2007

Hmm, ich könnte bissl mit der "alten" Systemplatte spielen. Vielleicht bootet das Teil sogar mit der neuen Hardware...

Irgendwie habe ich aber auch das Gefühl, in die falsche Richtung zu suchen. Wenn die Kiste ein allgemeines (Hardware-)Problem hat, dann sollte sie doch auch mal einfach so stehenbleiben, nicht nur in direktem Zusammenhang mit VDR/DVB. Schließlich ist das ein "produktives" System, das von früh bis nachts läuft. Wenn es die SATA-Verbindung oder irgendwas in dieser Ecke ist, warum habe ich dann keine Probleme beim Kopieren großer Files oder bei irgendeinem Plattentest...?

Vielleicht sollte ich mir nochmal verschiedene Kernel und DVB-Treiber in SMP/Nicht-SMP-Version vornehmen?
Was könnte sich mit den DVB-Treibern beißen, vielleicht der NVIDIA-Treiber?
Sind irgendwelche 64-Bit-Problem bekannt?

Viele Grüße
Andreas Böttger

e9hack · 24. August 2007

Patche doch mal saa7146_wait_for_debi_done() ein klein wenig. Möglicherweise sieht man ja mehr:

Diff

--- a/linux/drivers/media/common/saa7146_core.c Tue Aug 21 12:38:39 2007 -0300
+++ b/linux/drivers/media/common/saa7146_core.c Fri Aug 24 12:56:10 2007 +0200
@@ -63,6 +63,7 @@ int saa7146_wait_for_debi_done(struct sa
 {
        unsigned long start;
        int err;
+       u32 psr;


        /* wait for registers to be programmed */
        start = jiffies;
@@ -71,7 +72,7 @@ int saa7146_wait_for_debi_done(struct sa
                if (saa7146_read(dev, MC2) & 2)
                        break;
                if (err) {
-                       DEB_S(("timed out while waiting for registers getting programmed\n"));
+                       printk("timed out while waiting for registers getting programmed\n");
                        return -ETIMEDOUT;
                }
                if (nobusyloop)
@@ -82,11 +83,13 @@ int saa7146_wait_for_debi_done(struct sa
        start = jiffies;
        while (1) {
                err = time_after(jiffies, start + HZ/4);
-               if (!(saa7146_read(dev, PSR) & SPCI_DEBI_S))
+               psr = saa7146_read(dev, PSR);
+               if (!(psr & SPCI_DEBI_S))
                        break;
                saa7146_read(dev, MC2);
                if (err) {
-                       DEB_S(("timed out while waiting for transfer completion\n"));
+                       printk("timed out while waiting for transfer completion\n");
+                       printk("psr=%08x, ssr=%08x\n", psr, saa7146_read(dev, SSR));
                        return -ETIMEDOUT;
                }
                if (nobusyloop)

Alles anzeigen

Gruß
e9hack

bandi · 24. August 2007

Ok, also zurück zum SMP-Kernel und den Patch reinbauen... mach ich (nach der Arbeit).

Btw.: Woran erkenne ich nen ARM-Crash, sehe ich das im Syslog? Kann ich den kernelinternen Treiber "gesprächiger" machen? Die SuSE 10.2 scheint allgemein bissl weniger zu loggen als mein Altsystem.

Danke für den Patch!
Andreas Böttger

bandi · 24. August 2007

Hi,

diese Kiste will mich ärgern

Als meine Frau nachmittags irgendwas ansehen wollte, blieb das Teil mal wieder stehen. Nach dem Aus-/Einschalten hatte das BIOS Probleme, die zweite Platte zu erkennen. Die dritte (am zweiten SATA-Controller auf diesem Board) war auch weg. Nach mehreren Bootversuchen habe ich beide Platten abgesteckt. Damit ging es dann wieder...
Diese Platten (200GB Maxtor) sind aus dem alten Rechner, schon etwas älter, liefen aber bisher problemlos. Sollte die VIA-Southbridge grundsätzliche Probleme damit haben?

Das eigentliche Problem besteht aber immernoch. Zwei Aufnahmen starten, dann was von Platte ansehen, kurz warten ... *freeze*

Ich habe den Patch eingebaut und wieder auf SMP zurückgestellt. Die Übersetzung läuft...
Wahrscheinlich teste ich das aber erst morgen.

Viele Grüße
Andreas Böttger

bandi · 25. August 2007

Hi,

zunächst lief die Kiste erstaunlich stabil, dann blieb sie bei zwei Aufnahmen und einer Wiedergabe ohne irgendwelche Hinweise stehen. Beim nächsten Versuch gab es wenigstens was im Syslog:

Aug 25 11:52:02 vdr kernel: timed out while waiting for transfer completion
Aug 25 11:52:02 vdr kernel: psr=000c0028, ssr=00800030
Aug 25 11:52:02 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 11:52:02 vdr vdr: [30558] PES packet shortened to 3050 bytes (expected: 5390 bytes)
Aug 25 11:52:02 vdr vdr: [30558] cAudioRepacker(0xC1): skipped 336 bytes to sync on next audio frame
Aug 25 11:52:02 vdr vdr: [30558] cAudioRepacker(0xC0): skipped 732 bytes to sync on next audio frame
Aug 25 11:52:02 vdr vdr: [30550] PES packet shortened to 1472 bytes (expected: 1840 bytes)
Aug 25 11:52:02 vdr vdr: [30550] cAudioRepacker(0xC0): skipped 12 bytes while syncing on next audio frame
Aug 25 11:52:06 vdr kernel: timed out while waiting for transfer completion
Aug 25 11:52:06 vdr kernel: psr=000c0028, ssr=00800030
Aug 25 11:52:06 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 11:52:06 vdr vdr: [30558] PES packet shortened to 3830 bytes (expected: 7694 bytes)
Aug 25 11:52:06 vdr vdr: [30558] cDolbyRepacker: skipped 740 bytes while syncing on next AC3 frame
Aug 25 11:52:06 vdr vdr: [30550] PES packet shortened to 368 bytes (expected: 1550 bytes)
Aug 25 11:52:06 vdr vdr: [30550] PES packet shortened to 262 bytes (expected: 1550 bytes)
Aug 25 11:52:06 vdr vdr: [30550] cDolbyRepacker: skipped 598 bytes while syncing on next AC3 frame
Aug 25 11:53:56 vdr syslog-ng[3074]: syslog-ng version 1.6.11 starting

Danach ging es wieder einige Zeit ohne Probleme (immernoch zwei Aufnahmen und eine Wiedergabe) und schließlich folgte ein längerer Abschnitt mit Aussetzern (teilweise mehrere Sekunden), aber ohne richtigen Absturz. Das Log dazu ist etwas länger (bei Bedarf per Mail), hier ein Ausschnitt:

Aug 25 13:04:12 vdr vdr: [5167] PES packet shortened to 814 bytes (expected: 1550 bytes)
Aug 25 13:04:12 vdr vdr: [5167] 1 cRepacker messages suppressed
Aug 25 13:04:12 vdr vdr: [5167] cDolbyRepacker: skipped 796 bytes while syncing on next AC3 frame
Aug 25 13:04:12 vdr vdr: [5167] cAudioRepacker(0xC0): skipped 464 bytes to sync on next audio frame
Aug 25 13:04:12 vdr vdr: [5173] cAudioRepacker(0xC0): skipped 48 bytes to sync on next audio frame
Aug 25 13:04:12 vdr vdr: [5173] PES packet shortened to 878 bytes (expected: 2318 bytes)
Aug 25 13:04:12 vdr vdr: [5173] 2 cRepacker messages suppressed
Aug 25 13:04:12 vdr vdr: [5173] cAudioRepacker(0xC1): skipped 96 bytes to sync on next audio frame
Aug 25 13:04:12 vdr vdr: [5173] PES packet shortened to 4670 bytes (expected: 5390 bytes)
Aug 25 13:04:17 vdr kernel: timed out while waiting for transfer completion
Aug 25 13:04:17 vdr kernel: psr=000c0128, ssr=00800030
Aug 25 13:04:17 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 13:04:17 vdr vdr: [5173] PES packet shortened to 3038 bytes (expected: 5390 bytes)
Aug 25 13:04:17 vdr vdr: [5167] PES packet shortened to 1656 bytes (expected: 1840 bytes)
Aug 25 13:04:21 vdr kernel: timed out while waiting for transfer completion
Aug 25 13:04:21 vdr kernel: psr=000c0128, ssr=00800030
Aug 25 13:04:21 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 13:04:21 vdr vdr: [5167] PES packet shortened to 262 bytes (expected: 1550 bytes)
Aug 25 13:04:21 vdr vdr: [5167] PES packet shortened to 1288 bytes (expected: 1840 bytes)
Aug 25 13:04:25 vdr kernel: timed out while waiting for transfer completion
Aug 25 13:04:25 vdr kernel: psr=000c0128, ssr=00800030
Aug 25 13:04:25 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 13:04:25 vdr kernel: timed out while waiting for transfer completion
Aug 25 13:04:25 vdr kernel: psr=000c0028, ssr=80800030
Aug 25 13:04:25 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 25 13:04:25 vdr kernel: timed out while waiting for transfer completion
Aug 25 13:04:25 vdr kernel: psr=000c0028, ssr=80800030
Aug 25 13:04:25 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 25 13:04:25 vdr kernel: timed out while waiting for transfer completion
Aug 25 13:04:25 vdr kernel: psr=000c0128, ssr=80800030
Aug 25 13:04:25 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 25 13:04:25 vdr kernel: timed out while waiting for transfer completion
Aug 25 13:04:25 vdr kernel: psr=000c0128, ssr=80800030
Aug 25 13:04:25 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 25 13:04:25 vdr kernel: dvb-ttpci: StartHWFilter error buf 0b07 0010 002c b96a ret 0 handle ffff
Aug 25 13:04:25 vdr vdr: [5060] ERROR: can't set filter (pid=44, tid=02, mask=FF): Operation not permitted
Aug 25 13:04:25 vdr vdr: [5173] PES packet shortened to 2690 bytes (expected: 5390 bytes)
Aug 25 13:04:25 vdr vdr: [5173] PES packet shortened to 542 bytes (expected: 2318 bytes)
Aug 25 13:04:25 vdr vdr: [5167] PES packet shortened to 1472 bytes (expected: 1840 bytes)
Aug 25 13:06:01 vdr vdr: [5055] max. latency time 16 seconds

SATA-Probleme gab es seit ich nur noch die Systemplatte angesteckt habe keine mehr.

Viele Grüße
Andreas Böttger

bandi · 26. August 2007

Wenn das Problem ohne gleichzeitige Aufnahme (also nur Wiedergabe von Platte) auftritt, sieht das Log so aus:

Aug 25 20:38:19 vdr vdr: [14229] dvbplayer thread started (pid=5055, tid=14229)
Aug 25 20:38:19 vdr vdr: [14230] non blocking file reader thread started (pid=5055, tid=14230)
Aug 25 20:38:19 vdr vdr: [14229] setting audio track to 1 (0)
Aug 25 20:38:38 vdr kernel: saa7146 (2) vpeirq: used 1 times >80% of buffer (65424 bytes now)
Aug 25 20:38:38 vdr kernel: saa7146 (1) vpeirq: used 1 times >80% of buffer (61476 bytes now)
Aug 25 20:39:22 vdr kernel: saa7146 (1) vpeirq: used 1 times >80% of buffer (191384 bytes now)
Aug 25 20:39:24 vdr kernel: timed out while waiting for transfer completion
Aug 25 20:39:24 vdr kernel: psr=000c0628, ssr=00804830
Aug 25 20:39:24 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 20:40:23 vdr kernel: saa7146 (1) vpeirq: used 1 times >80% of buffer (170516 bytes now)
Aug 25 20:40:44 vdr kernel: timed out while waiting for transfer completion
Aug 25 20:40:44 vdr kernel: psr=000c0728, ssr=00804830
Aug 25 20:40:44 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 20:40:58 vdr kernel: saa7146 (2) vpeirq: used 1 times >80% of buffer (162432 bytes now)
Aug 25 20:41:19 vdr kernel: timed out while waiting for transfer completion
Aug 25 20:41:19 vdr kernel: psr=000c0728, ssr=00804830
Aug 25 20:41:19 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed
Aug 25 20:42:25 vdr kernel: timed out while waiting for transfer completion
Aug 25 20:42:25 vdr kernel: psr=000c0728, ssr=80804800
Aug 25 20:42:25 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 25 20:42:25 vdr kernel: dvb-ttpci: StopHWFilter error cmd 0b08 0001 0007 ret 0 resp 0007 b96a pid 52
Aug 25 20:42:33 vdr kernel: timed out while waiting for transfer completion
Aug 25 20:42:33 vdr kernel: psr=000c0628, ssr=00804830
Aug 25 20:42:33 vdr kernel: av7110_debiwrite: wait_for_debi_done failed
Aug 25 20:42:46 vdr kernel: saa7146 (2) vpeirq: used 1 times >80% of buffer (166380 bytes now)
Aug 25 20:42:54 vdr kernel: timed out while waiting for transfer completion
Aug 25 20:42:54 vdr kernel: psr=000c0628, ssr=00804820
Aug 25 20:42:54 vdr kernel: av7110_debiread: wait_for_debi_done #1 failed

Viele Grüße
Andreas Böttger

av7110_debiread: wait_for_debi_done #1 failed (solved)

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema