av7110_debiread: wait_for_debi_done #1 failed (solved)

Zitat

Original von UFO
Ich hab's ausprobiert:
Der "wait for registers to be programmed"-Teil darf auf keinen Fall entfernt werden.

Wie man sieht, ist der Code ziemlich feuergefährlich.

Dann ist aber was anders auch noch faul. Das UPLD_DEBI-Bit kann nur 0 sein, wenn in eines der DEBI-Register geschrieben wurde und kein neuer Upload erfolgt ist. Außer während der Initialisierung (+Reinitialisierung nach ARM-Crash), erfolgt der Zugriff auf die DEBI-Register nur innerhalb des DEBI-Locks. Während der Initialisierung greift nur ein Thread auf die Register zu. Es darf daher keine Situation geben, bei der man auf den Upload warten muß.

Zitat

Ich möchte auf keinen Fall irgendwelche Regressions in den Treiber einbauen.

Deswegen habe ich die Funktion ja nach av7110_xx ausgelagert.

Zitat

Daher schlage ich vor, den Code in saa7146_core nur so weit zu korrigieren, daß der busyloop-Timeout auch mit gesperrten Interrupts funktioniert. Die Timeouts sind zwar relativ hoch, aber damit sind wir auf der sicheren Seite.

Ich würde der Funktion schon in irgendeiner Form ein Timeout übergeben wollen. Bei gesperrten Interrupts sollte die Wartezeit eigentlich < 50µs sein. 250ms sind da indiskutabel.

Man sollte auch darüber nachdenken, wie man den DEBI-Zugriff außerhalb der Interrupt-Routinen regelt. Man kann da immer kurz nach einem DMA-Start treffen. Dann muß man im schlechtesten Fall ca. 650µs bei gesperrten Interrupts warten. Für die Funktionen wdebi()/rdebi() sollte es einen zusätzlichen Mutex zum Verriegeln und eine Wait-Queue geben. Außerdem sollte start_debi_dma() ein Flag in den Device-Daten setzen, das einen aktiven DMA-Transfer markiert. wdebi()/rdebi() prüft dann innerhalb des DEBI-Spinlocks auf einen aktiven DMA-Transfer. Ist der vorhanden, werden die Daten für den DEBI-Request in den Device-Daten abgelegt und es wird über eine Wait-Queue auf die Abarbeitung des Requests gewartet. Die Abarbeitung erfolgt dann in debiirq(). debiirq() führt gegebenenfalls einen zusätzlichen Request aus, weckt den wartenden Thread auf und setzt das DMA-Flag zurück. Gleichzeitige Zugriffe von rdebi()/wdebi() werden durch den zusätzlichen Mutex verhindert. Möglicherweise kann man hierfür auch den dcom-Lock mitbenutzen.

Gruß
e9hack

Zitat

Original von e9hack

Dann ist aber was anders auch noch faul. Das UPLD_DEBI-Bit kann nur 0 sein, wenn in eines der DEBI-Register geschrieben wurde und kein neuer Upload erfolgt ist. Außer während der Initialisierung (+Reinitialisierung nach ARM-Crash), erfolgt der Zugriff auf die DEBI-Register nur innerhalb des DEBI-Locks. Während der Initialisierung greift nur ein Thread auf die Register zu. Es darf daher keine Situation geben, bei der man auf den Upload warten muß.

Wo steht, daß der saa7146 den Upload sofort ausführt? Das kann ohne weiteres von allen möglichen (undokumentierten) Zuständen innerhalb des Chips abhängen. Ich denke, der Code in saa7146_core wurde nicht ohne Grund so geschrieben ("praktische Erfahrung").

Zitat

Deswegen habe ich die Funktion ja nach av7110_xx ausgelagert.

Ich würde der Funktion schon in irgendeiner Form ein Timeout übergeben wollen. Bei gesperrten Interrupts sollte die Wartezeit eigentlich < 50µs sein. 250ms sind da indiskutabel.

Das ist alles nur worst-case, falls irgendetwas hängenbleibt. In der Praxis also völlig irrelevant. Ebenso kann man nicht sicher sein, wie lange irgendwelche anderen PCI-Chips (und "kaputte" PCI-Bridges) Transfers verzögern. Deswegen macht es Sinn, hier üppig Luft zu lassen. Wem bringt es etwas, wenn ein Transfer unnötigerweise mit Timeout endet?

Zitat

Man sollte auch darüber nachdenken, wie man den DEBI-Zugriff außerhalb der Interrupt-Routinen regelt. Man kann da immer kurz nach einem DMA-Start treffen. Dann muß man im schlechtesten Fall ca. 650µs bei gesperrten Interrupts warten. Für die Funktionen wdebi()/rdebi() sollte es einen zusätzlichen Mutex zum Verriegeln und eine Wait-Queue geben. Außerdem sollte start_debi_dma() ein Flag in den Device-Daten setzen, das einen aktiven DMA-Transfer markiert. wdebi()/rdebi() prüft dann innerhalb des DEBI-Spinlocks auf einen aktiven DMA-Transfer. Ist der vorhanden, werden die Daten für den DEBI-Request in den Device-Daten abgelegt und es wird über eine Wait-Queue auf die Abarbeitung des Requests gewartet. Die Abarbeitung erfolgt dann in debiirq(). debiirq() führt gegebenenfalls einen zusätzlichen Request aus, weckt den wartenden Thread auf und setzt das DMA-Flag zurück. Gleichzeitige Zugriffe von rdebi()/wdebi() werden durch den zusätzlichen Mutex verhindert. Möglicherweise kann man hierfür auch den dcom-Lock mitbenutzen.

Darüber hatte ich schon mal nachgedacht und es dann verworfen. Diese Baustelle mache ich jetzt nicht auf. Ich möchte mich endlich um wichtige Dinge kümmern, die auf meiner Todo-Liste stehen. Jede Änderung in dieser Ecke bringt mit großer Wahrscheinlichkeit nur Ärger. Auch deshalb, weil die Chip-Datenblätter entweder nicht klar genug formuliert oder die Chips buggy sind.

Wenn Du in dieser Richtung arbeiten möchtest, nur zu. Mach Dich aber darauf gefaßt, als Lohn für diese Arbeit vor allem Prügel zu beziehen.

CU
Oliver

Zitat

Original von bandi
hat sich e9hack nun von UFO abschrecken lassen?
Also ich werde keine Prügel verteilen.

Es soll niemand abgeschreckt werden. Man muß sich halt im klaren sein, daß derart kritische Änderungen nicht "einfach so" übernommen werden können.

Sie erfordern eine längere Testphase auf vielen unterschiedlichen Systemen. Schließlich soll die mühsam erarbeitete Stablität des Treibers nicht wieder verloren gehen.

Genügend Tester zu finden, ist leider auch nicht so einfach. Die wenigsten möchten mit ihrem stabil laufenden System experimentieren.

Zurück zum ursprünglichen Problem:
(Btw, die angedachte Änderung würde dieses Problem vermutlich nicht lösen.)

Noch ein paar evtl. hilfreiche Threads:
- av7110_bootarm(): load_dram() failed: [bestätigt] Oszillator Bug auf Nexus als Ursache für ARM Boot-Fehler!?
- SMP/Interrupt-Problem: VDR und SMP-Kernel Probleme (K.A., ob dies mit Deinem Problem zusammenhängt.)

Wäre evtl. hilfreich, einen Schritt zurück zu gehen und zu testen, ob es mit einem 32 Bit/Non-SMP-Kernel diese Probleme auch gibt...

CU
Oliver

Zitat

Original von bandi

das habe ich mir auch als Variante überlegt. Blöderweise habe ich aber im Job gerade mächtig Streß (viel mehr Arbeit als Leute) und dadurch praktisch keine Zeit für sowas. Andererseits kann ich die Kiste auch nicht ewig so halbfertig lassen...

Leider kann ich Dir keinen besseren Tipp geben. Dein Problem scheint ziemlich einzigartig zu sein.

Angehängt ist ein Patch, der den busywait-Fix von e9hack auf alle saa7146-Karten überträgt, ohne an den Timeouts zu drehen. Läuft hier bislang problemlos. Kannst ja mal versuchen, ob das Einfrieren damit verhindert wird.

Zitat

Reicht es eigentlich, den Kernel auf 32bit zu compilieren, oder muß dann das ganze System 32bit sein? Oder geht vielleicht sogar das andere Extrem, daß nur die DVB-Module 32bit sind?

Ob ein 32-Bit Kernel mit einem 64-Bit System zusammenarbeitet, kann ich nicht sagen. Vermute mal eher nicht. Bitte korrigieren, falls ich mich irre.

Ein Treiber muß jedoch _definitiv_ mit exakt demselben Compiler und exakt denselben Kompileroptionen übersetzt werden wie der Kernel selbst. Sonst gibt's sehr merkwürdige "Effekte".

Zitat

Wie weit hat sich eigentlich Dein optimierter Treiber inzwischen vom Original entfernt? Könnte der in Sachen 64bit/SMP anders (besser) aussehen?

Die Änderungem betreffen das Interrupt- und Buffer-Handling. Wäre möglich, daß er sich anders verhält. Bewußt verändert habe ich in dieser Richtung jedoch nichts.

CU
Oliver

Zitat

Original von bandi
Ich habe ihn seit ca. einer Stunde drin und konnte mein Problem bisher nicht provozieren.
Das sieht schonmal recht gut aus Schaumermal, ich werde berichten...

Wenn vorher der Watchdog den DVB-Treiber wachküssen mußte, sollte es jetzt Timeoutmeldungen geben.

Ich habe mittlerweile auch einen 64Bit-Kernel parallel am laufen. Ich konnte keine Hänger oder Timeouts provozieren. Ich lasse auch eine Meldung ausgeben, wenn auf den DEBI-Upload über MC2 gewartete werden muß. Es mußte aber nie gewartet werden. Irgendwie habe ich den Eindruck, daß auf meiner TT-2300C eine besserer (neuerer?) SAA7146 verbaut wurde.

Gruß
e9hack

Zitat

Original von e9hack
Ich lasse auch eine Meldung ausgeben, wenn auf den DEBI-Upload über MC2 gewartete werden muß. Es mußte aber nie gewartet werden. Irgendwie habe ich den Eindruck, daß auf meiner TT-2300C eine besserer (neuerer?) SAA7146 verbaut wurde.

Kann schon sein. Bei meiner Rev 1.3 muß ziemlich oft auf den Upload gewartet werden. Wenn ich dort eine Ausgabe einbaue, wächst das Syslog munter vor sich hin.

Lt. Treiber ist es Revision 1 des saa7146. Aber das will ja nicht unbedingt heißen, daß es nicht unterschiedlich Rev. 1 Serien gibt.

CU
Oliver

Zitat

Original von e9hack
Ich habe mittlerweile auch einen 64Bit-Kernel parallel am laufen. Ich konnte keine Hänger oder Timeouts provozieren.

D.h. Du hast ohne Probleme einen 64 Bit SMP Kernel am laufen, wobei die Interrupts auf beide CPUs verteilt werden?

CU
Oliver

Hallo zusammen,

Meine 1.6 DVB-s hat sich - jetzt mit Patch - erstmalig aufgehängt:

Sep 18 11:41:52 vivian vdr: [3386] cAudioRepacker(0xC0): skipped 306 bytes to sync on next audio frame
Sep 18 11:49:07 vivian vdr: [3386] cDolbyRepacker: skipped 920 bytes to sync on next AC3 frame
Sep 18 11:54:13 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:13 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Sep 18 11:54:13 vivian kernel: dvb-ttpci: av7110_fw_cmd error -110
Sep 18 11:54:13 vivian vdr: [3031] ERROR (dvbdevice.c,987): Die Wartezeit für die Verbindung ist abgelaufen
Sep 18 11:54:14 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:14 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Sep 18 11:54:14 vivian kernel: dvb-ttpci: av7110_fw_cmd error -110
Sep 18 11:54:14 vivian vdr: [3031] ERROR (dvbdevice.c,988): Die Wartezeit für die Verbindung ist abgelaufen
Sep 18 11:54:15 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:15 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Sep 18 11:54:15 vivian kernel: dvb-ttpci: av7110_fw_cmd error -110
Sep 18 11:54:15 vivian vdr: [3031] ERROR (dvbdevice.c,742): Die Wartezeit für die Verbindung ist abgelaufen
Sep 18 11:54:16 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:16 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Sep 18 11:54:16 vivian kernel: dvb-ttpci: av7110_fw_cmd error -110
Sep 18 11:54:16 vivian vdr: [3031] ERROR (dvbdevice.c,870): Die Wartezeit für die Verbindung ist abgelaufen
Sep 18 11:54:17 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:17 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Sep 18 11:54:17 vivian kernel: dvb-ttpci: av7110_fw_cmd error -110
Sep 18 11:54:17 vivian vdr: [3031] ERROR (dvbdevice.c,873): Die Wartezeit für die Verbindung ist abgelaufen
Sep 18 11:54:18 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:18 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Sep 18 11:54:18 vivian kernel: dvb-ttpci: av7110_fw_cmd error -110
Sep 18 11:54:18 vivian vdr: [3031] ERROR (dvbdevice.c,899): Die Wartezeit für die Verbindung ist abgelaufen
Sep 18 11:54:19 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:19 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110
Sep 18 11:54:19 vivian kernel: dvb-ttpci: av7110_fw_cmd error -110
Sep 18 11:54:19 vivian vdr: [3031] ERROR (dvbdevice.c,899): Die Wartezeit für die Verbindung ist abgelaufen
Sep 18 12:04:45 vivian -- MARK --
Sep 18 12:17:01 vivian /USR/SBIN/CRON[3765]: (root) CMD (   run-parts --report /etc/cron.hourly)
Sep 18 12:44:45 vivian -- MARK --

Danach bleibt das Bild stehen und der vdr hängt komplett.

Grüße,
Stefan

ich kann da auch noch einen Beisteuern : ich habe gemeint, ich müsste mal das System neu aufsetzen - es war nen Suse mit inzwischen defektem Yast - lief aber ansonsten rock-solid unter kernel 2.6.22.6 mit FF und Budget, mit lirc und mit aktuellen v4l's.

Nach dem Neuaufsetzen mit Suse 10.1. ging erstmal alles ganz normal - es war halt nur der alte kernel und die alten v4l's. Also 2.6.22.6 gebaut, die gleichen Treiber wie unter dem alten system - und was soll ich sagen : Aussetzer in Bild und Ton mit gleichzeitigen bösen Logeinträgen... lirc geht gar nicht, obwohl absolut 100% identische Version und alles neu gebaut - kein irw und kein vdr auf der Schiene. In Foren hab ich was zu DMA-Problemen im Kernel 2.6.22.6 gefunden und parallel dazu hat mir das Kernel bauen auch freundlich mitgeteilt, daß mein Compiler (gcc 4.10) dazu neigt, Fehler in den Kernel zu compilieren - dankeschön. Ich gehe jetzt den mühseligen Weg von 2.6.16.13 bis 2.6.x, solange, bis ich wieder auf die Nase falle - wobei ich immernoch nocht kapiert hab, wieso es VOR dem Neuinstall ging... Und jetz sach keiner ich hätte vorher nicht den Kernel 2.6.22.6 gehabt...

kann mir noch jemand verraten, welchen gcc ich nehmen soll - und wie ich die rpm's von Suse zum gcc komplett loswerde, und trotzdem noch alles bauen kann, was ich will - ich hab ein wenig schiss, daß hinterher nichts mehr geht - welche Pakete vom gcc ausm Netz brauch ich denn ?

Zitat

Original von Fourty2
Meine 1.6 DVB-s hat sich - jetzt mit Patch - erstmalig aufgehängt:

Code

Sep 18 11:54:13 vivian kernel: __av7110_send_fw_cmd: timeout waiting on busy MSG QUEUE
Sep 18 11:54:13 vivian kernel: dvb-ttpci: av7110_send_fw_cmd(): av7110_send_fw_cmd error -110

Danach bleibt das Bild stehen und der vdr hängt komplett.

Ich glaube nicht, daß Dein Problem was mit den wait_for_debi_done Timeouts zu tun hat. Solche Fehler bekomme ich auch, wenn ich eine alte Firmware benutze oder bei zu vielen gleichzeitigen Aufnahmen und wildem zappen im OSD.

Gruß
e9hack

Zitat

Original von UFO

D.h. Du hast ohne Probleme einen 64 Bit SMP Kernel am laufen, wobei die Interrupts auf beide CPUs verteilt werden?

Ich habe keinen Dual-Core. Deswegen habe ich auch nichts von SMP geschrieben.

Gruß
e9hack

So, nachdem ich nun heute auch dieses tolle Problem "gefunden" habe schreib ich mal mein Szenario.

Erstmal habe ich, damit mir genau sowas nicht passiert, tagelang mein System mit
Athlon 64 X2 3800+ EE auf Asus M2V Mobo mit 1GB Ram, 1 SATA HDD, 1x FF 1.3, 1x Nvidia 6200TC
ausgiebig mit Kernel 2.6.22.6 getestet - zappen, aufnehmen, heftige OSD Aktivitäten, alles kein Thema. Kein einziger Absturz.

Also kam heute der Umbau der restlichen Hardware aus dem alten VDR-Server in den neuen. Nun befindet sich folgendes zusätzlich im System:
3 x DVB-S Budget TT/Nova
1 x Sata HDD
3 x Pata HDD
1 x DVD-Brenner
Anstelle der FF 1.3 nun eine FF 1.6.

Auch das habe ich im Arbeitszimmer noch einige Zeit laufen gehabt während ich lustig Daten von einer auf die andere Platte geschaufelt habe, alles kein Thema. Dabei war allerdings nur der Sat-Eingang der FF am Multiswitch.

Dann kam der Umzug in den Keller und letztlich der Anschluss aller 4 DVB-S Karten an den Multiswitch und dann der Test, ob das im Wohnzimmer auch wieder alles schön funktioniert.
Und voila, einmal femon aufgerufen und dort die Karten durchschalten wollen und schon nach dem 2. Umschalten hing die Kiste und auf dem Monitor im Keller prangte die schöne "av7110_debiwrite: ..." Fehlermeldung.

Da dachte ich mir doch gleich: "Kacke, da hat meine 1.6 wohl ein Problem mit dem Asus Board."
Also fluchs gegen die 1.3er FF ausgetauscht, nur leider hat das Null gebracht.
Vorsorglich auch noch das Undervolting der CPU deaktiviert - auch nix.
Und natürlich passiert das, wenn der Rechner was für die Frau aufnehmen soll ... und nach tagelangen Tests.

Edit1:
Gerade nochmal die Budgets raus und siehe da, nur mit FF funktionierts einwandfrei, ich krieg die Kriese.

Eidt2:
Und jetzt 1xFF und 1X Budget - keine Probleme.
Gruml, ich hab das Board doch extra genommen weil es eins der weinigen AM2 Boards mit 4 PCI Slots ist.

Edit3:
1xFF, 2X Budget - bang, kompletter Stillstand, diesmal allerdings ohne das Fehlermeldungen irgendwo auftauchen, einfach nur eingefrohrenes System.

Edit4:
So, ich hab jetzt so ziemlich alle Konstellationen von 2 Budget und 1 FF durch, die ich hier hinkriegen kann.
Das Problem ist nicht wegzukriegen sobald 2 Budgets im Rechner sind (oder vielleicht ja 3 Karten mit SAA7146?).

/proc/interrupts für 2 bzw. 3 Karten im System (jeweils 1xFF, rest budget) sieht so aus:

CPU0 CPU1
0: 101 0 IO-APIC-edge timer
1: 7 1 IO-APIC-edge i8042
4: 26314 1 IO-APIC-edge lirc_serial
6: 2 1 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 0 1 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 2 2 IO-APIC-edge i8042
14: 1539 22 IO-APIC-edge ide0
15: 340 19 IO-APIC-edge ide1
21: 3954 1 IO-APIC-fasteoi eth0
22: 6549 7712 IO-APIC-fasteoi sata_via, ehci_hcd:usb2, uhci_hcd:usb4
23: 34 1 IO-APIC-fasteoi uhci_hcd:usb1
24: 0 0 IO-APIC-fasteoi uhci_hcd:usb3
25: 0 0 IO-APIC-fasteoi uhci_hcd:usb5
26: 208449 2677 IO-APIC-fasteoi HDA Intel, saa7146 (0)
27: 1649268 1924994 IO-APIC-fasteoi saa7146 (1)
NMI: 0 0
LOC: 602324 626761
ERR: 0
MIS: 0

CPU0 CPU1
0: 101 0 IO-APIC-edge timer
1: 7 1 IO-APIC-edge i8042
6: 2 1 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 0 1 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 2 2 IO-APIC-edge i8042
14: 114 22 IO-APIC-edge ide0
15: 390 19 IO-APIC-edge ide1
21: 650 1 IO-APIC-fasteoi eth0
22: 7046 590 IO-APIC-fasteoi sata_via, uhci_hcd:usb3, ehci_hcd:usb4
23: 42 1 IO-APIC-fasteoi uhci_hcd:usb1
24: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
25: 0 0 IO-APIC-fasteoi uhci_hcd:usb5
26: 6337 1 IO-APIC-fasteoi HDA Intel, saa7146 (0)
27: 786 1 IO-APIC-fasteoi saa7146 (1)
28: 132338 119766 IO-APIC-fasteoi saa7146 (2)
NMI: 0 0
LOC: 42819 48682
ERR: 0
MIS: 0

Und weil es so traurig ist jetzt noch was ganz krankes.
2x FF und 1X Budget funktioniert (zumindest im kurztest).

Da sieht /proc/interrupts dann so aus:
CPU0 CPU1
0: 101 0 IO-APIC-edge timer
1: 7 1 IO-APIC-edge i8042
4: 1700 1 IO-APIC-edge lirc_serial
6: 2 1 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 0 1 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 2 2 IO-APIC-edge i8042
14: 115 22 IO-APIC-edge ide0
15: 393 19 IO-APIC-edge ide1
21: 359 1 IO-APIC-fasteoi eth0
22: 6714 1268 IO-APIC-fasteoi sata_via, uhci_hcd:usb3, ehci_hcd:usb5
23: 45 1 IO-APIC-fasteoi uhci_hcd:usb1
24: 0 0 IO-APIC-fasteoi uhci_hcd:usb2
25: 0 0 IO-APIC-fasteoi uhci_hcd:usb4
26: 14026 1 IO-APIC-fasteoi saa7146 (0), HDA Intel
27: 113058 1 IO-APIC-fasteoi saa7146 (1)
28: 26175 397201 IO-APIC-fasteoi saa7146 (2)
NMI: 0 0
LOC: 79862 75116
ERR: 0
MIS: 0

Jetzt wäre es sehr interessant, ob das Problem nur mit TT Budgets auftritt, oder ob auch andere Budgets das Problem machen - nur leider hab ich nur TT-Design FF und Budgets.

Und sehr interessant wäre es natürlich auch zu wissen, ob die anderen, die das debiwrite Problem haben, auch mehrere Budgets (und wenn ja, welche) neben der FF im System haben.

Zitat

Original von bandi

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)

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

Viele Grüße
Andreas Böttger

Alles anzeigen

Da frag ich mich doch, warum ich den Thread nicht eher gefunden habe - bevor ich das Mainboard meines Arbeitsrechners zum Server gemacht habe.

Tu mir mal einen gefallen und nimm eine Budget raus und probier mal, ob du mit 1xFF und 1X Budget das Problem immer noch hast.
Bei mir ist das Problem dann nämlich weg.
Vielleicht hilfts ja, als 2. Budget eine nicht TT bzw. ohne SAA7146 zu nehmen.

Mit freundlichen Grüßen

Norbert

P.S.: Mein System ist ganz ähnlich, allerdings hab ich nen x2 3800+ EE drin, den ich masslos undervolted habe (für die Tests hier natürlich nicht, will ja nicht, dass der Schuld sein könnte), da der Server eh meist nur idle ist bzw. bei 1 GHz dürfte da der Unterschied zum BE marginal sein.

Zitat

Original von Egalus
Da frag ich mich doch, warum ich den Thread nicht eher gefunden habe - bevor ich das Mainboard meines Arbeitsrechners zum Server gemacht habe.

Evtl. ist dieser Thread noch interessant: VDR und SMP-Kernel Probleme

(Ich warte noch immer auf Erkenntnisse, ob die Fehler mit der Interruptverteilung zusammenhängen.)

CU
Oliver