Moin moin, ich benutze hier (unter SuSE 8.0) 'VDR' als digitalen Videorecorder. Bis 'vor kurzem' funktionierte das auch ganz prima, nun aber bricht jedes angestossene Aufzeichnen 'irgendwo mittendrin einfach' ab. Da dies, jedenfalls nach meinem Verständnis der folgenden Fehlermeldungen, wohl kaum durch das Programm selbst, sondern durch einen Fehler in/bei der DMA-Festplattensteuerung verursacht zu werden scheint, erlaube ich mir, dazu hier um Rat zu bitten: Jun 17 10:16:06 linux vdr[2209]: buffer usage: 76% Jun 17 10:16:06 linux last message repeated 5 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 77% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 78% Jun 17 10:16:06 linux last message repeated 5 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 79% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 80% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 81% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 82% Jun 17 10:16:06 linux last message repeated 5 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 83% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 84% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 85% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 86% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 87% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 88% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 89% Jun 17 10:16:06 linux last message repeated 5 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 90% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 91% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 92% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 93% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 94% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 95% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 96% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 97% Jun 17 10:16:06 linux last message repeated 3 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 98% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 99% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 100% Jun 17 10:16:14 linux vdr[376]: max. latency time 5 seconds Jun 17 10:16:14 linux kernel: hdc: timeout waiting for DMA Jun 17 10:16:14 linux kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14 Jun 17 10:16:14 linux kernel: hdc: status timeout: status=0xd0 { Busy } Jun 17 10:16:14 linux kernel: hdc: drive not ready for command Jun 17 10:16:15 linux kernel: ide1: reset: success Jun 17 10:16:46 linux vdr[2209]: ERROR: video data stream broken Jun 17 10:16:46 linux vdr[2209]: initiating emergency exit Jun 17 10:16:46 linux vdr[376]: emergency exit requested - shutting down Ich verstehe das so, dass offensichtlich erst der Plattenpuffer volläuft und dann die Datenerfassung (ganz) abgebrochen wird, weil nicht (mehr) auf die Platte geschrieben werden kann und dies, weil der Plattencontroller quasi "eingeschlafen" ist, nicht mehr reagiert - oder? Auf jeden Fall würde ich, natürlich, gern wissen, wo's konkret dran liegen und wie ich's, nun ja, 'wieder hinbiegen' kann. Und mich deshalb über jeden dem näherbringenden Tipp sehr freuen! Und tschö Jürgen -- Wer das erste Knopfloch verfehlt, kommt mit dem Zuknöpfen nicht zurande. Goethe
Hy, Am 02/06/17@11:15 schrieb Jürgen Hein:
Moin moin,
ich benutze hier (unter SuSE 8.0) 'VDR' als digitalen Videorecorder. Bis 'vor kurzem' funktionierte das auch ganz prima, nun aber bricht jedes angestossene Aufzeichnen 'irgendwo mittendrin einfach' ab. Da dies, jedenfalls nach meinem Verständnis der folgenden Fehlermeldungen, wohl kaum durch das Programm selbst, sondern durch einen Fehler in/bei der DMA-Festplattensteuerung verursacht zu werden scheint, erlaube ich mir, dazu hier um Rat zu bitten:
Ohne was von 8.0 zu kennen, ließt man in den letzten Tagen hier, dass die 8.0 von "Haus aus" wohl dma nur für Platten unterstützt => neuen Kernel backen. -- :wq-y Maik
Maik Holtkamp wrote:
Ohne was von 8.0 zu kennen, ließt man in den letzten Tagen hier, dass die 8.0 von "Haus aus" wohl dma nur für Platten unterstützt => neuen Kernel backen.
Tach Maik, soweit ich weiss ist das Projekt VDR ein Video-Rekorder, der die Filme auf Festplatten abspeichert... Peter
Hy, Am 02/06/17@21:48 schrieb Peter Wiersig:
Maik Holtkamp wrote:
Ohne was von 8.0 zu kennen, ließt man in den letzten Tagen hier, dass die 8.0 von "Haus aus" wohl dma nur für Platten unterstützt => neuen Kernel backen.
soweit ich weiss ist das Projekt VDR ein Video-Rekorder, der die Filme auf Festplatten abspeichert...
Ja, Blödsinn. Tut mir leid. OP: Nicht machen, hilft beim akuten Problem bestimmt nicht. -- :wq-y Maik
On Mon, 17 Jun 2002, Jürgen Hein wrote:
ich benutze hier (unter SuSE 8.0) 'VDR' als digitalen Videorecorder. Bis 'vor kurzem' funktionierte das auch ganz prima, nun aber bricht jedes angestossene Aufzeichnen 'irgendwo mittendrin einfach' ab. Da dies, jedenfalls nach meinem Verständnis der folgenden Fehlermeldungen, wohl kaum durch das Programm selbst, sondern durch einen Fehler in/bei der DMA-Festplattensteuerung verursacht zu werden scheint, erlaube ich mir, dazu hier um Rat zu bitten:
[...]
Jun 17 10:16:06 linux vdr[2209]: buffer usage: 99% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 100% Jun 17 10:16:14 linux vdr[376]: max. latency time 5 seconds Jun 17 10:16:14 linux kernel: hdc: timeout waiting for DMA Jun 17 10:16:14 linux kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14 Jun 17 10:16:14 linux kernel: hdc: status timeout: status=0xd0 { Busy } Jun 17 10:16:14 linux kernel: hdc: drive not ready for command Jun 17 10:16:15 linux kernel: ide1: reset: success Jun 17 10:16:46 linux vdr[2209]: ERROR: video data stream broken Jun 17 10:16:46 linux vdr[2209]: initiating emergency exit Jun 17 10:16:46 linux vdr[376]: emergency exit requested - shutting down
Ich verstehe das so, dass offensichtlich erst der Plattenpuffer volläuft und dann die Datenerfassung (ganz) abgebrochen wird, weil nicht (mehr) auf die Platte geschrieben werden kann und dies, weil der Plattencontroller quasi "eingeschlafen" ist, nicht mehr reagiert - oder?
Scheint so. In welchem dma-Modus läuft die Platte? # hdparm -i /dev/hdc unmittelbar nach dem Booten sagt das. Eventuell runtersetzen; udma2 reicht völlig. Oder neueren Kernel probieren, es hat sich in letzter Zeit einiges getan im IDE-Subsystem. Viel Erfolg! -ron
Am Mittwoch, 19. Juni 2002 03:07 schrieb Rolf Naef: Moin moin Rolf, zuerst natürlich vielen Dank für Deine Antwort.
Jun 17 10:16:06 linux vdr[2209]: buffer usage: 99% Jun 17 10:16:06 linux last message repeated 4 times Jun 17 10:16:06 linux vdr[2209]: buffer usage: 100% Jun 17 10:16:14 linux vdr[376]: max. latency time 5 seconds Jun 17 10:16:14 linux kernel: hdc: timeout waiting for DMA Jun 17 10:16:14 linux kernel: ide_dmaproc: chipset supported ide_dma_timeout func only: 14 Jun 17 10:16:14 linux kernel: hdc: status timeout: status=0xd0 { Busy } Jun 17 10:16:14 linux kernel: hdc: drive not ready for command Jun 17 10:16:15 linux kernel: ide1: reset: success Jun 17 10:16:46 linux vdr[2209]: ERROR: video data stream broken Jun 17 10:16:46 linux vdr[2209]: initiating emergency exit Jun 17 10:16:46 linux vdr[376]: emergency exit requested - shutting down
Ich verstehe das so, dass offensichtlich erst der Plattenpuffer volläuft und dann die Datenerfassung (ganz) abgebrochen wird, weil nicht (mehr) auf die Platte geschrieben werden kann und dies, weil der Plattencontroller quasi "eingeschlafen" ist, nicht mehr reagiert - oder?
Scheint so. In welchem dma-Modus läuft die Platte? # hdparm -i /dev/hdc
Gibt aus: DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 und bedeutet ja wohl, dass sie mit udma5 läuft, nicht wahr?
unmittelbar nach dem Booten sagt das. Eventuell runtersetzen; udma2 reicht völlig.
Äh, also Du meinst, dass ..5 eventuell zu hoch=schnell und somit vielleicht quasi "unterfordert" sein könnte und deshalb "einschläft"?! Und wie kann man das runtersetzen? Habe just versucht - allerdings mit meinen miserablen English"kenntnissen" - im man von hdparm dazu was zu finden, leider ohne Erfolg.
Oder neueren Kernel probieren, es hat sich in letzter Zeit einiges getan im IDE-Subsystem.
Hhm, nach 2.4.18 echt so viel, dass sich das Holen eines (noch) neueren tatsächlich lohnen würde? (Naja, verfüge hier nur über 'ne Modemanbindung :-( )
Viel Erfolg!
Jo, danke nochmal und tschö Jürgen -- Wer das erste Knopfloch verfehlt, kommt mit dem Zuknöpfen nicht zurande. Goethe
On Wed, 19 Jun 2002, Jürgen Hein wrote:
Am Mittwoch, 19. Juni 2002 03:07 schrieb Rolf Naef:
[IDE-Timeoutprobleme]
In welchem dma-Modus läuft die Platte? # hdparm -i /dev/hdc
Gibt aus: DMA modes: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 *udma5 und bedeutet ja wohl, dass sie mit udma5 läuft, nicht wahr?
Ja.
unmittelbar nach dem Booten sagt das. Eventuell runtersetzen; udma2 reicht völlig.
Äh, also Du meinst, dass ..5 eventuell zu hoch=schnell und somit vielleicht quasi "unterfordert" sein könnte und deshalb "einschläft"?! Und wie kann man das runtersetzen? Habe just versucht - allerdings mit meinen miserablen English"kenntnissen" - im man von hdparm dazu was zu finden, leider ohne Erfolg.
Ich dachte dabei eher an ein Kabelproblem. '# hdparm -X66d1 /dev/hdc' setzt die Platte, für die aktuelle Sitzung, auf udma2. Vorheriges Backup kann nicht schaden ;).
Oder neueren Kernel probieren, es hat sich in letzter Zeit einiges getan im IDE-Subsystem.
Hhm, nach 2.4.18 echt so viel, dass sich das Holen eines (noch) neueren tatsächlich lohnen würde? (Naja, verfüge hier nur über 'ne Modemanbindung :-( )
Du brauchst auch nicht den ganzen Kernel zu holen. der original 2.4.18 (nicht SuSE) von der CD lässt sich mit z.B: ftp://ftp.gwdg.de/pub/linux/kernel/v2.4/testing/patch-2.4.19-pre10.bz2 problemlos patchen. Sind aber immer noch 4,5 Mb. Falls Du nicht selber kompilieren willst, gibt's auf: ftp://ftp.gwdg.de/pub/linux/suse/ftp.suse.com/people/mantel/next/RPM/ den inoffiziellen, vorkompilierten k_deflt-2.4.18-174.i386.rpm vom 14. Juni. Immerhin ist dein System mal störungsfrei gelaufen. Glücklich ist in solchen Fällen wer über ein pedantisch geführtes Changelog verfügt ;)) -ron
participants (4)
-
Jürgen Hein
-
Maik Holtkamp
-
Peter Wiersig
-
Rolf Naef