Howto : ASUS M2NPV-VM mit Kanotix/easyVDR

geht jetzt atmo auch mit xineliboutput? Ich dachte nur mit softdevice??

?
du kannst doch die FF fürs atmo nutzen und dann halt xineliboutput als weiteres ausgabe device? last geht dann natürlich auf die cpu.

@ Wicki:

Hi,

nur um sicher zu gehen. Deine Skript Vorbereitung ist für Dein Asus Board. Macht es jetzt einen Unterschied, wenn ich mir das hier angesprochene Asus Pundit kaufe. Sind die Mainboards Bau/Treiber gleich?
So, daß alles was bei Dir läuft, ohne weitere Anpassungen auch auf dem Pundit läuft.

Grüße

Dr Jones

Wicky
Vielleicht sollten wir einen neuen Thread starten für die EasyVDR Geschichte. Hier blickt ja keiner mehr durch...

Grüße
Sven

Quote

Original von infinite
?
du kannst doch die FF fürs atmo nutzen und dann halt xineliboutput als weiteres ausgabe device? last geht dann natürlich auf die cpu.

achso? das geht dann? setzt aber mindestens voraus, dass bei mehr als einer DVB das live-tv immer auf der FF läuft, sonst passt das ja nicht und wie ist das dann bei aufnahmen?

Muss ich mich schon wieder selbst zitieren:

Quote

Original von linuxservice
Ein paar Kleinigkeiten sind mir aufgefallen: Mit der Hauppauge FF im ersten und der Twinhan DST im zweiten PCI-Slot funktionierte die Twinhan manchmal nicht richtig, festschrauben durfte ich sie schon gar nicht (Modul lädt, Logmeldungen sehen normal aus, aber sie tunt nicht). In umgekehrter Reihenfolge ist das Problem behoben, allerdings teilt sie sich dann den Interrupt 16 mit der Onboard-Grafik und einer der beiden Treiber hat da anscheinend ein Problem - wenn die DST aktiv ist, kann die Grafik manchmal einfrieren (hauptsächlich bei 3D oder XVideo-Kram, aber auch schon beim einfachen Desktop-Umschalten erlebt) und dann heisst es Reset, der Rechner ist mausetot.

(Debuggen wird mir das wohl niemand, falls ich es nicht eines Tages mal ohne nvidia-Treiber reproduzieren kann - so wie ich die durchschnittliche Codequalität von nvidia einschätze, wird der wohl auch Schuld sein) Daher die Frage: Kennt jemand von Euch eine Möglichkeit, wie man einem der beiden einen anderen Interrupt zuweisen kann? (18 wäre noch frei)

Das Freeze-Problem wird zunehmend schlimmer. Zwar habe ich jetzt auch wieder die Kombination FF in PCI1 und DST in PCI2 zum Laufen bekommen, was das Problem _etwas_ entschärft (die DST produziert mehr Interrupts), aber es tritt inzwischen dennoch häufig genug auf, um mehr als nur ein bisschen zu stören (mit dem aktuellen Kernel 2.6.23.1-21 sind die Uptimes zwischen den Freezes selten mehr als 2 Tage, manchmal nur 2 Stunden). Auch ohne besondere Aktivität. Einfach nur vdr im Hintergrund mit der entsprechenden Interrupt-Last durch die DVB-Karten. Ohne vdr ist mir die Kiste noch nicht eingefroren, aber ich bin inzwischen der Meinung, jede andere Interruptlast würde das früher oder später auch provozieren - zumindest wenn sie auf einem Interrupt stattfindet, der mit der Nvidia-Grafik gesharet wird.

Das liegt auch nicht an diesem Board speziell, im Nvidia-Forum gibts einige Threads wie diesen. Einzige Gemeinsamkeit scheint zu sein, dass der Treiber nur im Dualcore-Betrieb einfriert und dass der freie 2D-Treiber nv das Problem nicht hat. Einziger wirksamer Workaround (ausser auf den nvidia-Treiber zu verzichten) ist damit wohl, den zweiten Kern abzuschalten: Kerneloption maxcpus=1. (Was sonst noch so vorgeschlagen wird, wie ältere Treiberversion, bestimmte Treiberoptionen, bestimmte Optionen in Usermode-3d-Programmen, scheint mir den Bug nur zu kaschieren - ältere Treiberversion z.B. bedingt älteren Kernel, und die hatten ihn generell nicht so häufig. Im Bereich Interrupts/Locking wurde letzthin einiges getan, möglicherweise werden dadurch Bugs im nvidia-Treiber sichtbar, die vorher nicht auftreten konnten). Der aktuelle 96er hängt sich jedenfalls gefühlt genauso oft auf wie der 100er. Mit noapic/nolapic werde ich die Tage noch experimentieren, aber falls das helfen sollte, wird es das wohl auch eher dank geändertem Zeitverhalten tun und nicht weil es den Bug wirklich umschifft.

Daher möchte ich meine Frage von oben wiederholen: Kennt jemand eine Möglichkeit, entweder die Grafik oder eine der beiden DVB-Karten auf Interrupt 18 zu legen? Meine Vermutung geht mittlerweile sehr stark in die Richtung, dass es am Interruptsharing liegt.
Suche nur noch eine Möglichkeit, das zu verifizieren.

Hi linuxservice,

Habe mit dem selben Board dieses Problem:

Nvidia und wlan(RT61) teilen sich ein Interrupt.
Einen Freece bekomme ich nicht, aber das WLAN stellt nach einer gewissen Zeit seine Arbeit ein. Ich habe auch die Vermutung, dass es am IRQ Sharing liegt.
Hast Du einen selbsterstellten Kernel?
Wenn ja versuche doch bitte mal die PCI-Zugriffsmethode auf "direct" zu stellen.
Ich kann es leider nicht testen, da ich dieses System für einen Bekannten erstellt habe. Ein Kernelupdate via SSH ist mir zu riskant.
Ansonsten läuft die Kiste aber ausgezeichnet. (VDR via xineliboutput xv)

Peter

Hallo,

auch ich darf nun ein M2NVP-VM mein Eigen nennen :].
Da ich nun von Intel auf AMD umsteige, wollte ich nach einer config für
den Kernel in Bezug auf das Board bitten oder fragen ob Ihr mir bitte die
Einstellungen für den Kernel nennen könnt, damit das Board in Bezug
auf Leistung und Lautstärke (Q&Q ..) alles geben kann.

Danke und Gruß Kail

Quote

Original von linuxservice
Muss ich mich schon wieder selbst zitieren:

Einzige Gemeinsamkeit scheint zu sein, dass der Treiber nur im Dualcore-Betrieb einfriert und dass der freie 2D-Treiber nv das Problem nicht hat. Einziger wirksamer Workaround (ausser auf den nvidia-Treiber zu verzichten) ist damit wohl, den zweiten Kern abzuschalten: Kerneloption maxcpus=1. (Was sonst noch so vorgeschlagen wird, wie ältere Treiberversion, bestimmte Treiberoptionen, bestimmte Optionen in Usermode-3d-Programmen, scheint mir den Bug nur zu kaschieren - ältere Treiberversion z.B. bedingt älteren Kernel, und die hatten ihn generell nicht so häufig. Im Bereich Interrupts/Locking wurde letzthin einiges getan, möglicherweise werden dadurch Bugs im nvidia-Treiber sichtbar, die vorher nicht auftreten konnten).

Update: Es lag wohl an den Interrupts, aber ganz anders als ich dachte Endgültig angefangen zu wundern habe ich mich, als auch mit dem nv-Treiber ein Freeze auftrat. Und dann war da letztens ein Patch, der sich vielversprechend anhörte. Jetzt hat mein System schon wieder fast 6 Tage Uptime (mit 2.6.23.8-34.fc7), und ich neige langsam dazu, das Problem als gelöst zu betrachten. Was hat sich getan?

In 2.6.23.9 (obiger Fedora-Kernel basiert auf 2.6.23.9-rc1 und heisst deshalb noch .8 ) ist dieser Patch aufgenommen worden:

commit 653e60e2a9c16df6fccb3ae16f12d984cf83fb68
Author: David P. Reed <dpreed@reed.com>
Date:   Wed Nov 14 17:47:35 2007 -0500


    x86: fix freeze in x86_64 RTC update code in time_64.c

    patch c399da0d97e06803e51085ec076b63a3168aad1b in mainline.

    x86: fix freeze in x86_64 RTC update code in time_64.c

    Fix hard freeze on x86_64 when the ntpd service calls
    update_persistent_clock()

    A repeatable but randomly timed freeze has been happening in Fedora 6
    and 7 for the last year, whenever I run the ntpd service on my AMD64x2
    HP Pavilion dv9000z laptop.  This freeze is due to the use of
    spin_lock(&rtc_lock) under the assumption (per a bad comment) that
    set_rtc_mmss is called only with interrupts disabled.  The call from
    ntp.c to update_persistent_clock is made with interrupts enabled.

    [ tglx@linutronix.de: ported to 2.6.23.stable ]

    Signed-off-by: David P. Reed <dpreed@reed.com>
    Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
    Signed-off-by: Ingo Molnar <mingo@elte.hu>
    Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>

Das war eine tickende Zeitbombe - es ging immer so lange gut, bis mal ein Interrupt dazwischen kam. Klar, dass die Interruptlast der DVB-Karten das Problem verschärfte. Warum es erst jetzt so schlimm wurde, ist mir nicht ganz klar. Aber wie gesagt, im Interrupt-Bereich wurde unlängst gebastelt.

Ergänzend habe ich noch den nvidia-Treiber auf 100.14.09 downgraded, da die neueren mitunter eigenartige xv-Probleme zeigen (xv funktioniert erstmal, irgendwann gibts aber via Adaptor #0: "NV17 Video Texture" nur noch Pixelmüll, während Adaptor #1: "NV05 Video Blitter" noch funktioniert - leider nimmt tvtime anscheined den ersten Port, den es kriegen kann, während man ihn bei mplayer auswählen kann).

Um diesen älteren Treiber unter aktuellen Kerneln zu kompilieren, braucht man noch einen Patch - der funktioniert auch mit .09 und .03. Habe mich erstmal für .09 entschieden, weil ich mich zu erinnern glaube, dass der .11 erstmals Probleme machte. Werde das aber vielleicht noch verifizieren, wenn ich demnächst mal wieder mutig bin. Für den Moment erfreue ich mich erstmal wieder eines Systems, das sich nicht dauernd aufhängt, wenn man es nur scharf ansieht

Hallo VDRler,

ich muss mich hier auch mal einklinken. Habe in das Board eine Technotrend FF DVB-C eingebaut und damit startet das Board nicht. Egal welcher PCI Port. Karte wieder raus und der VDR funktioniert wieder einwandfrei.

Anschließend die FF in ein alte P III Board und läuft einwandfrei. Das Netzzeil hat sogar weniger Power...

Habt ihr eine Idee? Ist bisschen ärgerlich!

Hallo nochmal,

funktioniert jetzt. Habe im PCI Menu die automatische PCI Konfiguration ausgeschaltet und als primäre Grafikkarte die Onboard Karte gewählt. Muss noch herausfinden, welche der beiden Optionen schuld war.

Grüße

Ich hätte hierzu auch mal ne Frage.

Läuft das ganze auch mit der Mahlzeit Iso?? Ich blick irgendwie noch net so ganz durch.

Danke

Gruß
Chris

:lol2*rofl* hab gerade fur 1e stunde das m2a-vm HDMI bestellt um es noch vor weinnachten ab zu holten

DANKE!

Quote

Original von linuxserviceHabe mich erstmal für .09 entschieden, weil ich mich zu erinnern glaube, dass der .11 erstmals Probleme machte. Werde das aber vielleicht noch verifizieren, wenn ich demnächst mal wieder mutig bin.

So, Update: Kurz vor Weihnachten kam noch der 169.07 raus, mit ein paar netten Notes im Changelog, u.a. diese

# Fixed stability problems with some GeForce 6200/7200/7300 GPUs multi-core/SMP systems.
# Improved RENDER performance.
# Fixed a bug that caused corruption with redirected XV on GPUs without TurboCache support.

Punkt 1 bezieht sich wahrscheinlich auf die Freezes, die auch ohne x86_64 berichtet wurden. 6150 ist da nicht erwähnt - aber schaden kann es sicher nicht.
Punkt 2 ist interessant für alle, die nicht nur vdr auf der Kiste haben. Auch wenn in den einschlägigen Foren die Meinung vorherrscht, dass das nur für wenige synthetische Benchmarks etwas bringt - mir ist sofort aufgefallen, dass Firefox flüssiger wurde. Da der Fedora-Firefox schon mit Pango/Cairo rendert, dürfte das daran liegen.
Punkt 3 schliesslich könnte für meine xv-Probleme verantwortlich gewesen sein - ist mit 169.07 noch nicht wieder aufgetreten.

Einem Update sollte damit nichts im Wege stehen

Hallo, nachdem ich aufgrund dieses Threads nicht mehr widerstehen konnte hab ich mir auch so ein Board zugelegt. Jetzt musste ich leider feststellen, das das Board nicht mit meinem Silverstone LC11 harmoniert. Das mit der Risercard haut nicht hin. Muss mich nun nach was anderem umsehen. Ich habe dabei an das Thermaltake Mozart SX gedacht, möchte aber erst wissen, ob es dabei mit der Risercard hinhaut. Hat da jemand schon Erfahrungen oder kann mir ein Gehäuse mit ähnlichen Massen empfehlen?

Quote

Ich verwende den TV-out des M2NPV-VM und bin sehr begeistert von der Ausgabequlität !!

noch mehr bin ich aber von der Ausgabequalitaet meines VGA->RGB SCART (PAL) Adapterkabels begeistert, das ich direkt am VGA Ausgang der nVidia angeschlossen habe.

Modeline:

Modeline "720x576i"   13.875 720  744  808  888  576  580  585  625 -HSync -Vsync interlace

damit kannst du direkt einen Roehren-TV interlaced (eben PAL) betreiben und hast damit auch aus elektrischer Sicht Super-Signalqulitaet. Adapter-Kabel ist aehnlich diesem hier:

https://www.vdr-portal.de/board/attachme…achmentid=13022

es muss aber noch zusaetzlich 1 Transister + 1 Widerstand dazu, da die nVidia Grafik im Gegensatz zur Radeon kein Composite-Sync beherrscht.

Da mit dieser Methode der TV-OUT Encoder gar nicht mehr genutzt wird, hat man bei der Konfiguration auch keine TV-OUT spezifischen Probleme mehr.