[DE] linux-image-3.0.0-1-rt-amd64 in sid

[devil]

es interessiert bestimmt unsere musiker, dass seit heute linux-image-3.0.0-1-rt-amd64/i686 in sid ist.
naja, der ohne rt latürnisch auch.

greetz
devil

[brummer]

Das ist wirklich erfreulich, . .
Leider läuft der gegenwärtige rt patch noch nicht (einwandfrei) auf 32 bit, ich habe sie von rt0 bis rt3 ausprobiert, nur der rc7-rt0 läuft hier (mit add patch 0.2) stabil auf 32 bit.

gruß
brummer

[autoandimat]

Ist auf jeden Fall ne interessante Sache. Ich hab ihn mal installiert aber das System weigert sich die Nvidia-Module zu bauen.

Mittlerweile bin ich in der glücklichen Lage, dass seit dem Umstieg auf 64-bit auch die Kernel von der Stange alles hergeben was ich benötige. Mehr als das hier läuft bei mir selten gleichzeitig:
http://img836.imageshack.us/img836/8325/audioz.jpg

Das rennt mit ner 32-Spur-Aufnahme und F/P 128 in jackd locker durch - mit Luft nach oben.

Allerdings würde mich so ein Test, inwieweit sich der Kernel ausserhalb dessen ausreizen lässt schon ein wenig unter den Fingern jucken. :wink:
Aber irgendwie will Nvidia nicht mit dem 3er-rt.

[towo]

Nvidia brauchte schon immer Patches für RT-Kernel.

[brummer]

Erfreulich für mich ist aber, das mein ATI endlich wieder mit libgl1-mesa-glx auf 3d läuft, statt mit dem Software Ersatz libgl1-mesa-swx11.

Hier ist der Grund warum die NVidea nicht baut
http://thread.gmane.org/gmane.linux.rt.user/6940

[autoandimat]

Hier ist der Grund warum die NVidea nicht baut
http://thread.gmane.org/gmane.linux.rt.user/6940

Ohje :oops:, da bin ich als Friese überfordert. :lol:

[ralul]

Ist nur ne zusätzliche Mutex Zeile, aber wohin ...

[agaida]

candidate/0020-x86-mtrr-lock-stop-machine-during-MTRR-rendezvous-se.patch

So wie sich das liest, ist der rt3-Patch gemeint. Das sollte ein grep doch aber bestätigen können

[brummer]

@ralul

Ist nur ne zusätzliche Mutex Zeile, aber wohin ...

Code: [Select]

brummer@box:~/Projekte/Kernel/linux-3.0$ grep 'EXPORT_SYMBOL_GPL(migrate_disable)' -R ./
./kernel/sched.c:EXPORT_SYMBOL_GPL(migrate_disable);
^C
brummer@box:~/Projekte/Kernel/linux-3.0$ grep 'EXPORT_SYMBOL_GPL(migrate_enable)' -R ./
./kernel/sched.c:EXPORT_SYMBOL_GPL(migrate_enable);
^C
brummer@box:~/Projekte/Kernel/linux-3.0$ grep 'EXPORT_SYMBOL_GPL(__rt_mutex_init)' -R ./
./kernel/rtmutex.c:EXPORT_SYMBOL_GPL(__rt_mutex_init);
^C
brummer@box:~/Projekte/Kernel/linux-3.0$

Eine zusätzlich Zeile ist nicht nötig, nur das _GPL stört den nicht GPL konformen NVidia  
gruß
brummer

[autoandimat]

Da es unter Debian im Moment mit Nvidia allgemein nicht so töfte läuft hab ich mal als Test ne Fresh-Install mit dem linux-image-3.0.0-1-rt-amd64 gemacht und auf unfreie Grafik-Treiber komplett verzichtet.
KDE spinnt da ziemlich rum wenn ich mit xrandr zwei Monitore antreiben will. Das führt in der Taskleiste zu unkontrollierbaren Entgleisungen die ich mit den Nvidia-Treibern nicht hatte.
Das ist aber nix dramatisches – nur etwas unschön. :lol:

Der Kernel rennt spitzenmässig mit Jackd. Zwei 38-Spur Aufnahmen und ein bisschen zusätzliches provozierendes Gekitzel an Ardour liessen den in seiner Performance nicht aus der Fassung bringen. Nicht mal ZynAdd hat das geschafft. :lol: Alles lief bei F/P 128 ohne Xruns durch. Das hat schon was.

Was ich nicht so ganz verstehe ist warum die Kernel von der Stange mal sehr gut mir Ardour, Jackd & Co laufen und dann beim nächsten Upgrade wiederum gar nicht mehr.
2.6.39 lief super. Beim aktuellen Kernel hält Jackd schon im Stillstand die weisse Fahne raus. :? Unter Arch verhält sich das je nach Kernel-Version äquivalent. Auch hier ist der aktuelle Kernel mit Jackd ne mittelschwere Katastrophe. :roll:

[agaida]

Zwei Sachen, die mir spontan einfallen:
* wenn das alles so ist, wie Du beschreibst (davon gehe ich mal aus), kannst Du da mal ein wenig Systematik reinbringen?
* Wenn ich Euch richtig lese, dann ist das, was funktioniert, vanilla (Brummer explizit vanilla, Arch ist imho auch im weitesten Sinne vanilla.)
* Funktionierende Kernelkonfigurationen habt ihr auch, genauso wie nicht funktionierende.

Wie wäre das, wenn man das einfach mal zusammenfasst und in einen wartbaren Kernel gießt. Das kann man erst mal ausserhalb Siduction machen, nur für den Fall, dass das Paket mist ist. Die Möglichkeiten, Userpakete zu hosten und zu bauen, habe ich. Nächster Schritt wäre ein User-Paket in Siduction und dann eventuell längerfristig, wenn man dass ein paarmal erfolgreich gebaut und aktualisiert hat, als Endziel ein Siduction RT-Kernel.

Technisch bin ich wohl bereit, mich um so was zu kümmern, aber mir fehlen Anwendungsgebiete, das zu Testen. Musik mache ich, indem ich einen Song auf den Player ziehe.

[autoandimat]

Also rein technisch fehlt mir wirklich jegliche Ahnung was die Kernel angeht. Dieser war direkt aus dem Debian-Repo:
http://packages.debian.org/sid/linux-image-3.0.0-1-rt-amd64
Ist das Vanilla? :oops:

Brummer hat da auf jeden Fall mehr Einblick. Ich selber könnte keinen rt-Kernel backen. Ich wüsste auch nicht wie man eine Kernelkonfiguration ermittelt. Ein Siduction-RT-Kernel wäre für mich natürlich ein äusserst erstrebenswertes Ziel.
Leider ist es bei den Mainline-Kerneln immer so ein Glücksspiel. Manchmal laufen auch die super – aber eben bei weitem nicht immer. :?

Als Tester bin ich immer wieder gerne bereit mich einzubringen. Im Grunde kann ich auch nicht viel mehr. Aber das tue ich immer sehr gerne.
Sowas macht auch immer Spass – vor allem wenn alles gut mit läuft: :mrgreen:
http://www.youtube.com/watch?v=HjavEDSokJ8

[agaida]

Kernelkonfig: Lesen, z.B. /usr/src/linux-header...
vanilla - immer so wie der jenige, der den code verbrochen hat, das wollte. Wird bei debian eigentlich kaum anzutreffen sein. Bei Arch schon sehr viel eher.