News Linux-Kernel 3.9 mit diversen Neuerungen freigegeben

Der Download-Link zum Linux-Kernel soll glaube ich eher sarkastisch gemeint sein! :D
 
So viele Linux-Nachrichten bin ich von CB gar nicht gewohnt :D ... freut mich sehr :)
 
Momentchen mal. Kann man nun einfach den Kernel updaten oder sollte man lieber auf Distros warten die alles erledigen?
 
Rob83 kommt auf die Distro an die du benutzt, unter Gentoo zB ist das kein Problem...
Ich habe selbst den Kernel schon installiert und kann sagen das er stabil läuft...
 
@Rob83:
der normale user sollte auf die distro warten. d.h. wenn du diese frage schon stellst, dann warte lieber, ausser du möchtest dich in die materie aus interesse einarbeiten. dann hilft google dabei sehr. evtl. haben auch andere hier lust dich da in die richtige richtung zu schubsen.
 
Ich würd warten, der Kernel hat immer mal wieder 2-3 stellen die von den Distributoren gepatcht werden. Ist eh praktischer die Kernel aus den Paketquellen zu Installieren, dauert ja meistens nicht allzulang bis die Zumindest in den Experimental/Beta/was auch immer Zweig sind.
 
Hallo, wie bekomme ich den Kernel bei mir zum laufen (Windows 7)? Muss ich das irgendwie mounten?
Danke
 
rosenholz schrieb:
Hallo, wie bekomme ich den Kernel bei mir zum laufen (Windows 7)? Muss ich das irgendwie mounten?
Danke

Wie der Name (eigentlich fälschlicherweise) aussagt, ist es ein LINUX-Kernel. Fälschlichwerweise deshalb, weil der Kernel das eigentliche Linux ist, worauf GNU und die Distributionen aufsetzen.
 
Zuletzt bearbeitet:
baizon schrieb:
So viele Linux-Nachrichten bin ich von CB gar nicht gewohnt :D ... freut mich sehr :)

Engelsen schrieb:

Dito! :)

Finde Änderungen am Scheduler, die die I/O betreffen besonders interessant. Denn ich habe den Eindruck, dass gerade Disk I/O unter Linux manchmal ein kleines Trauerspiel ist, wenn es um die gesamt-responsiveness des Systems geht. Ich muss diesen Kern zeitnah mal testen und auch, ob ZFS damit brauchbar arbeitet. Das würde dann vermutlich ein Quantensprung für meinen Homeserver bedeuten. :)
 
GuaRdiaN schrieb:
Dito! :)

Finde Änderungen am Scheduler, die die I/O betreffen besonders interessant. Denn ich habe den Eindruck, dass gerade Disk I/O unter Linux manchmal ein kleines Trauerspiel ist, wenn es um die gesamt-responsiveness des Systems geht. :)

das kann nicht sein, oder in deinem fall nicht daran liegen, denn die ist schon seit vielen vielen jahren deutlich besser als es bei windows jeh war.
 
@GuaRdiaN:

habe hier kernel 3.8.10 mit ZFSonLinux und BFS + BFQ am laufen

selbst beim überspielen des Backups von mehreren dutzend GB an Daten laufen youtube videos + zweiten Audiostream bzw. 2 Audio-Quellen simultan ohne zu stocken durch *



(* das System ist noch etwas zusätzlich getunt & ~amd64 Gentoo)


soviel hat die Änderung mit dem "bouncing cow problem" beim Testen der rc4 nicht gebracht, BFS scheint immer noch die bessere Wahl zu sein (autogroup war aktiviert)


für Laptop-Benutzer interessant dürften der "Zero-Power Optical Device Driver" und die ASPM/ACPI Änderungen sein


auf das verbesserte LZO bin ich auch schon gespannt (ich nutze ZRam), damit dürfte die Latency bzw. Verzögerungen noch weiter runter gehen unter Volllast - besonders der Einsatz von ZFS dürfte hiervon profitieren


@Dese:

dann kennst du folgendes Problem nicht: http://forums.gentoo.org/viewtopic-t-793263.html

bzw. dass es zum Stocken von Ton, Video und der grafischen Oberfläche kommt beim Transfer von großen Datenmengen


gut - im Vergleich zu Windows (teilweise Minuten bzw. bis zu einer halben Stunde in der Praxiserfahrung) sind das nur wenige Sekunden nach Tuning - dennoch ist es störend und dürfte heutzutage nicht mehr auftreten
 
Zuletzt bearbeitet:
Was "rosenholz" angeht, don't feed the troll! ;-)


Top, hoffe dass das mit Linux und AMD Karten in Zukunft besser wird.
 
freak01 schrieb:
@GuaRdiaN:

habe hier kernel 3.8.10 mit ZFSonLinux und BFS + BFQ am laufen

selbst beim überspielen des Backups von mehreren dutzend GB an Daten laufen youtube videos + zweiten Audiostream bzw. 2 Audio-Quellen simultan ohne zu stocken durch *

das problem ist hier nicht das io-scheduling unter linux als solches.

es gibt (ganz grob) zwei gründe, warum man als nutzer dieses problem sehen/bekommen kann:
- entweder falsche konfiguration des audio/video und io systems (leider sind die meisten distris nicht auf desktop-ansprüche konfiguriert sondern auf server bzw. ne mischung).

- oder aber der kernel ist nicht mit preempting bzw. kürzeren interrupt zeiten compiliert, was bei heavy io-load dazu führt, dass der io-scheduler zu spät den neuen io-job bekommt und es dann dauert, bis er die io wieder richtig priorisieren kann. das ist im grunde wieder einfall, dass hier auf server getrimmt wurde, mit dem unterschied zu oben, dass dies nicht zur laufzeit konfiguriert werden kann.

es gibt da aber noch ein paar andere dinge, die das verstärken können.

ja, aus user sicht kann das einem wurscht sein. aber da du die verbesserungen des io-systems angesprochen hast und daraus dir erhoffst, dass es dieses problem löst muss ich dir leider sagen: nö, wird es nicht, denn das io-system ist nicht das problem.

p.s. ich habe dieses problem selbst nie beobachten können. selbst wenn ich nen terabeit zwischen zwei platten hin und her schaufel läuft bei mir video und audio butterweich. interessanterweise unter ubuntu ohne mein zutun mitlerweile.

p.p.s. was du vieleicht machen kannst: such mal nach io-nice. damit kannst du die io priority von processen einstellen. unter windows z.b. hat das audio und video system eine höhere io-priorität meines wissens. unter linux gibt es auf den standarddistros standardmäßig keine unterscheidung hier.

EDIT: hab nochmal genauer in den gentoo-thread geschaut. also scheint ja so zu sein, dass gentoo offenbar standardmäßig seinen kernel noch weniger für desktops konfiguriert hat als andere distris. versteh mich nicht falsch: ich mag gengoo, aber gentoo ist keine distri zum selber basteln. das problem ist hier, dass die bastler den kernel in irgendeiner defaultkonfiguration bekommen und nicht in eine für die meisten enduser sinnvollen.
 
Zuletzt bearbeitet:
Aus irgend einen mir nicht bekannten Grund kann das Kernelmodul iwlwifi die Firmware nicht laden was dazu führt das ich aktuell ohne WLan darstehe:
Code:
Opeth toxicity # dmesg | grep iwl
[    1.666770] iwlwifi 0000:08:00.0: irq 44 for MSI/MSI-X
[    1.666909] iwlwifi 0000:08:00.0: request for firmware file 'iwlwifi-2030-6.ucode' failed.
[    1.666964] iwlwifi 0000:08:00.0: request for firmware file 'iwlwifi-2030-5.ucode' failed.
[    1.667016] iwlwifi 0000:08:00.0: no suitable firmware found!
Opeth toxicity # ls -l /lib/firmware/ | grep iwl
-rw-r--r-- 1 root root 707392 30. Apr 05:32 iwlwifi-2030-6.ucode
Wie man sehen kann ist die Firmware vorhanden, aber er kann sie nicht laden...
 
kannst du mal im syslog schauen, ob es detailliertere infos dazu gibt und ggf. auch im kernel log?

evtl. ist die firmware defekt. vieleicht mal nach einer anderen quelle für genau dieses file suchen und es dann auf dein system kopieren.

p.s. du könntest auf die schnelle mal folgendes probieren:
sudo apt-get install --reinstall linux-firmware
sudo modprobe -r iwlwifi
sudo modprobe iwlwifi

das installiert das firmware packet noch einmal und versucht dann das modul neu zu laden. wenn das klappt, dann passt's.
 
Zurück
Oben