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

Bitte teste mal angehängten Patch.

CU
Oliver

Mit dem Patch sieht vom Treiber aus wieder alles normaler aus, dh. es kommt irgendwann ein osd_ioctl SetBlock und man sieht die üblichen 3 Einträge in FillDmaTx, danach passiert 10 s kein gpioirq mit debitype DATA_BMP_LOAD und es kommt der bekannte Hänger. Ich denke, dass der trace mit ERESTARTSYS ein Sonderfall war.
Wenn aber das Problem in der Firmware liegt, warum kann man es mit einem trace-Aufruf auf den Userprozess provozieren? Das kann doch an den Daten nichts ändern, nur am Timing im System, nicht dem auf der Karte.

Zitat

Original von TomJoad
Mit dem Patch sieht vom Treiber aus wieder alles normaler aus, dh. es kommt irgendwann ein osd_ioctl SetBlock und man sieht die üblichen 3 Einträge in FillDmaTx, danach passiert 10 s kein gpioirq mit debitype DATA_BMP_LOAD und es kommt der bekannte Hänger. Ich denke, dass der trace mit ERESTARTSYS ein Sonderfall war.

ERESTARTSYS bedeutet, daß der Prozeß von irgendwoher ein Signal bekommen hat. Wäre schon interessant zu wissen, was da los ist. Dürfte normalerweise gar nicht auftreten.

Zitat

Wenn aber das Problem in der Firmware liegt, warum kann man es mit einem trace-Aufruf auf den Userprozess provozieren? Das kann doch an den Daten nichts ändern, nur am Timing im System, nicht dem auf der Karte.

Änderungen im Timing decken bei Mehrprozessorsystemen - die Kombination PC plus FF-Karte ist nichts anderes - oft versteckte Bugs auf. Was allerdings nicht bedeutet, daß sie leicht zu lokalisieren wären.

CU
Oliver

Zitat

Original von TomJoad
Mit dem Patch sieht vom Treiber aus wieder alles normaler aus, dh. es kommt irgendwann ein osd_ioctl SetBlock und man sieht die üblichen 3 Einträge in FillDmaTx, danach passiert 10 s kein gpioirq mit debitype DATA_BMP_LOAD und es kommt der bekannte Hänger. Ich denke, dass der trace mit ERESTARTSYS ein Sonderfall war.

Kannst Du bitte mal folgendes prüfen, wenn der Hänger auftritt:
- Bleibt die Audio-Wiedergabe über DVB stehen?
- Wächst newloops in arm_thread() weiter an? (Vermutlich ja.)

Mittlerweilse habe ich mir den Code im Treiber noch mal angeschaut.

Jetzt ist mir wenigstens klar, wieso der Treiber den ARM bei "busy MSG queue" nicht zurücksetzt.
Anbei ein entsprechender Patch.

Damit sollte das System im Fehlerfall auch ohne Treiber-Reload wieder auf die Füße kommen. (Nur ein Workaround, am eigentlichen Problem ändert sich nichts.)

CU
Oliver

Zur Zeit ist das Wetter zu schön für neue Experimente.
- Die Tonausgabe über DVB bleibt stehen
- Wird arm_errors nicht spätestens nach 5 Sekunden wieder auf 0 gesetzt, wenn der newloop-Mechanismus funktioniert oder verstehe ich den Code falsch?

Zitat

Original von TomJoad
Zur Zeit ist das Wetter zu schön für neue Experimente.

Kein Problem, ich habe das Problem ja nicht...

Zitat

- Die Tonausgabe über DVB bleibt stehen
- Wird arm_errors nicht spätestens nach 5 Sekunden wieder auf 0 gesetzt, wenn der newloop-Mechanismus funktioniert oder verstehe ich den Code falsch?

- Daher ja auch meine Frage nach den newloops.
- In den oben geposteten Logs war der Abstand zwischen den "timeout waiting on busy MSG queue" Fehlern so klein, daß es funktionieren müßte

CU
Oliver