# Kernel 2.6.20 ist raus.

## Klaus Meier

Sieht recht easy aus. An der Treiberstruktur hat sich nichts wesentliches geändert, also da sollte es keine Probleme mit Laufwerken und Controllern geben. Es lief auch alles prima durch und gestartet ist der Rechner auch wieder. Scheint diesmal ein Update ohne Streß zu sein.Last edited by Klaus Meier on Mon Feb 05, 2007 5:37 pm; edited 1 time in total

----------

## tost

Ich sehe keinen Grund auf ~ARCH umzusteigen wenn das System funktioniert und alles läuft.

tost

----------

## Klaus Meier

 *tost wrote:*   

> Ich sehe keinen Grund auf ~ARCH umzusteigen wenn das System funktioniert und alles läuft.
> 
> tost

 

Mußt du auch nicht. Aber irgend jemand muß es ja testen, sonst wird es nie stable. Habs halt geschrieben, weil der Umstieg von 2.6.18 auf 2.6.19 etwas holperig war.

----------

## treor

arg... 

ich schieb das update schon einige zeit vor mir her... häng noch bei 2.6.18. 

naja, noch 1 1/2 wochen dann sind klausuren rumm.. dann hab ich ja zeit mich mitm system rumzuschlagen  :Wink: 

----------

## tost

 *Quote:*   

> Mußt du auch nicht. Aber irgend jemand muß es ja testen, sonst wird es nie stable. Habs halt geschrieben, weil der Umstieg von 2.6.18 auf 2.6.19 etwas holperig war.

 

Soetwas ist löblich.

Ich dachte hier wäre nur wieder die "Ich-brauch-die-neuste-Version" Mentalität am Werke !

tost

----------

## slick

Wie weit ist eigentlich qemu um mit kvm zu arbeiten? Gibts da schon eine "Gentoo-Lösung"? Lohnt das überhaupt?

----------

## Klaus Meier

Also ich dachte, hier kommen Erfahrungen, Tips und Probleme mit dem neuen Kernel. Diskussionen über Sinn und Unsinn bitte woanders machen.

----------

## ConiKost

Yuhuu ... da isser endlich =)

Endlich wird meine Geode LX AES Hardware Engine supported ...

----------

## Carminox

 *tost wrote:*   

>  *Quote:*   Mußt du auch nicht. Aber irgend jemand muß es ja testen, sonst wird es nie stable. Habs halt geschrieben, weil der Umstieg von 2.6.18 auf 2.6.19 etwas holperig war. 
> 
> Soetwas ist löblich.
> 
> Ich dachte hier wäre nur wieder die "Ich-brauch-die-neuste-Version" Mentalität am Werke !
> ...

 

Ohne diese "Mentalität" würde keine Software der Welt stabil werden  :Wink: 

----------

## mrsteven

Bin auch schon bei 2.6.20. Na ja, das Update war langweilig, beim letzten war irgendwie mehr los...  :Wink: 

----------

## hoschi

Jetzt beschweren sie sich auch noch   :Rolling Eyes: 

 :Wink: 

----------

## platinumviper

 *tost wrote:*   

> Ich sehe keinen Grund auf ~ARCH umzusteigen

 

Das ist bezüglich des Kernels auch nicht sinnvoll, denn dann würdest Du auch die neuesten RCs bekommen, was i.d.R. nicht erwünscht ist. Ohne ~ARCH bekommst Du einen völlig veralteten Kernel, bei AMD64 ist vanilla-sources-2.6.16.19 "aktuell". Nimm dev-util/ketchup, damit hast Du volle Kontrolle über den verwendeten Kernel, die Echtheit der Sourcen wird mit gpg überprüft und Du sparst Datenvolumen und Zeit weil mit Patches gearbeitet wird.

platinumviper

----------

## Klaus Meier

 *platinumviper wrote:*   

> Das ist bezüglich des Kernels auch nicht sinnvoll, denn dann würdest Du auch die neuesten RCs bekommen, was i.d.R. nicht erwünscht ist.
> 
> platinumviper

 

Kannst mir das mal irgendwie erläutern? Man bekommt ja keine Versionen der mm-sources. Wir reden hier von den gentoo-sources. Und da beinhalten die Versionen mit dem -rx am Ende offizielle Fehlerkorrekturen des aktuellen Kernels. Und diese sind bei mir sehr erwünscht. Da werden keine experimentellen Features eingebaut.

----------

## hoschi

 *platinumviper wrote:*   

>  *tost wrote:*   Ich sehe keinen Grund auf ~ARCH umzusteigen 
> 
> Das ist bezüglich des Kernels auch nicht sinnvoll, denn dann würdest Du auch die neuesten RCs bekommen, was i.d.R. nicht erwünscht ist. Ohne ~ARCH bekommst Du einen völlig veralteten Kernel, bei AMD64 ist vanilla-sources-2.6.16.19 "aktuell". Nimm dev-util/ketchup, damit hast Du volle Kontrolle über den verwendeten Kernel, die Echtheit der Sourcen wird mit gpg überprüft und Du sparst Datenvolumen und Zeit weil mit Patches gearbeitet wird.
> 
> platinumviper

 

?!?!?!?!?!?!

 *Quote:*   

> 
> 
> /etc/portage/package.keywords
> 
> =sys-kernel/vanilla-sources-2.6.20
> ...

 

Man kann Portage nicht zum Spass genau sagen welche Version man haben moechte.

----------

## platinumviper

 *hoschi wrote:*   

>  *Quote:*   
> 
> /etc/portage/package.keywords
> 
> =sys-kernel/vanilla-sources-2.6.20
> ...

 

Dazu muss ich aber erst nachsehen welcher Kernel aktuell ist und ihn dann eintragen. Wenn ich nur sys-kernel/vanilla-sources eintrage, erhalte ich auch 2.6.21-rc1 (sobald er erschienen ist), den will ich aber nicht. Da ist ketchup viel einfacher, mit "ketchup 2.6" bekomme ich nach 2.6.20 erst wieder 2.6.20.1, wenn mich die RCs auch interessieren, brauche ich einfach nur "ketchup 2.6-rc" einzugeben. Ein weiterer Vorteil ist, dass der Kernel an einer Stelle liegt, an der ich ihn kompilieren kann und nicht unter /usr/src, wo er nichts zu suchen hat und wo auch kein User Schreibrechte besitzt.

platinumviper

----------

## franzf

 *platinumviper wrote:*   

> Ein weiterer Vorteil ist, dass der Kernel an einer Stelle liegt, an der ich ihn kompilieren kann und nicht unter /usr/src, wo er nichts zu suchen hat und wo auch kein User Schreibrechte besitzt.

 

Sorry für das OT, aber es passt grad so schön  :Smile: 

Ich erinnere mich an einen Thread hier im Forum, wo genau beschrieben ist, wie man den Kernel kompilieren soll, ohne diesem Symlink /usr/src/linux. Kann ich leider nimmer finden, und sämtliche Kernel-compile-howtos die ich finden konnte, arbeiten mit diesem bösen symlink...

Grüße

Franz

----------

## Klaus Meier

 *platinumviper wrote:*   

> Ein weiterer Vorteil ist, dass der Kernel an einer Stelle liegt, an der ich ihn kompilieren kann und nicht unter /usr/src, wo er nichts zu suchen hat und wo auch kein User Schreibrechte besitzt.
> 
> platinumviper

 

Hm, liegt das jetzt an mir oder an dir? Ich kann absolut nichts von dem nachvollziehen, was du schreibst. Erst mal, warum verwendest du nicht die gentoo-sources, die verwenden immer die stabile Version ohne experimentelle Features. Und wieso der Kernel nichts unter /usr/src zu suchen hat, will mir auch nicht so recht einleuchten. Wozu brauch man beim Installieren eines Kernels Schreibrechte als User? Ich installiere mir den immer als Root. emerge gentoo-sources läuft bei mir nicht als User. Wie schiebst du den denn als User nach /boot?

----------

## franzf

 *Klaus Meier wrote:*   

> Ich installiere mir den immer als Root. emerge gentoo-sources läuft bei mir nicht als User. Wie schiebst du den denn als User nach /boot?

 

Grundsätzlich kann jeder User kompilieren  :Wink:  make install kann aber nur root (wenn als PREFIX ein Verzeichnis außerhalb der rechtlichen Möglichkeiten des Users angegeben ist).

----------

## astaecker

 *franzf wrote:*   

> 
> 
> Sorry für das OT, aber es passt grad so schön 
> 
> Ich erinnere mich an einen Thread hier im Forum, wo genau beschrieben ist, wie man den Kernel kompilieren soll, ohne diesem Symlink /usr/src/linux. Kann ich leider nimmer finden, und sämtliche Kernel-compile-howtos die ich finden konnte, arbeiten mit diesem bösen symlink...

 

Du meinst "KERNEL_DIR=" .

----------

## platinumviper

 *franzf wrote:*   

> Ich erinnere mich an einen Thread hier im Forum, wo genau beschrieben ist, wie man den Kernel kompilieren soll, ohne diesem Symlink /usr/src/linux. Kann ich leider nimmer finden, und sämtliche Kernel-compile-howtos die ich finden konnte, arbeiten mit diesem bösen symlink...

 

Über den Symlink schrieb Linus schon vor sieben Jahren: *Quote:*   

> It's a symlink for
> 
> historical reasons, none of them very good any more (and haven't been
> 
> for a long time), and it's a disaster unless you want to be a C library
> ...

  Quelle: http://lkml.org/lkml/2000/7/27/10

Meinst Du das hier? https://forums.gentoo.org/viewtopic-p-3430245-highlight-.html#3430245

Was ich dort beschrieben habe, bezieht sich auf einen Rechner mit mehreren Benutzern, die den Kernel kompilieren dürfen. Wenn Du es alleine machst, kannst Du das natürlich auch in Deinem home-Directory machen.

Zu diesem Thema gibt es seit kurzem das Buch Linux Kernel in a Nutshell (Download-Version am Ende der Seite) von Greg Kroah-Hartmann (Mitglied des Gentoo-Kernel-Teams).

Noch ein kurzes Zitat daraus: *Quote:*   

> There have been bugs in the kernel build process in the past, causing some special
> 
> files in the /dev directory to be deleted if the user had superuser permissions while
> 
> building the Linux kernel.*
> ...

 

platinumviper

----------

## platinumviper

 *Klaus Meier wrote:*   

> warum verwendest du nicht die gentoo-sources, die verwenden immer die stabile Version ohne experimentelle Features.

 Alle acht Patches sind experimentell und deshalb nicht im offiziellen Kernel enthalten. Ich verwende davon nur squashfs um gelegentlich Änderungen an der Firmware meiner Fritz!Box vorzunehmen, den Rest brauche ich nicht.

platinumviper

----------

## franzf

@arslair + platinumviper:

Besten Dank, Thread gebookmarked  :Smile: 

Dass er ja nimmer verloren geht.

----------

## Necoro

@platinumviper: das ist aber toll, dass Linus das geschrieben hat ...

aber 1.) nur weil Linus das sagt, ist es noch lange nicht der Wahrheit letzter Schluss

und 2.) das mag auf binär distros zutreffen - aber in Gentoo ist es nunmal notwendig, dass der Kernel als Source vorliegt - und da _alle_ Programme mit emerge als root compiliert werden ist eher schwachsinnig, für den Kernel dies genau nicht zu machen

und 3.) macht es irgendein unterschied, ob der Kernel in /usr/src/linux oder in /opt/Linus/rocks/the/fuckin/planet liegt? - wichtig ist nur, dass er an einer definierten stelle liegt

p.s. sorry klaus, dass wir diesen thread kaputt machen  :Wink:  ... mag n mod diese Kernel-Lokations-Diskussion evtl auslagern?

----------

## Klaus Meier

 *Necoro wrote:*   

> p.s. sorry klaus, dass wir diesen thread kaputt machen  ... mag n mod diese Kernel-Lokations-Diskussion evtl auslagern?

 

Nö, diesen Thread hast du mir nicht kaputt gemacht, den hat mir Linus höchstpersönlich kaputt gemacht. Der 2.6.20 schnurrt sowas von problemlos, das mrsteven sich darüber sogar noch beschwert...

Aber ich fand es recht lustig, was für verbohrte und lustige Argumente hier losgelassen wurden. /usr/src/linux, da schauen alle Pakete, welche von der Kernelkonfiguration abhängig sind nach, wie diese aussieht. Wenn man das woanders hinpackt, dann frag ich mich, wie die Gentoo ans Laufen bekommen. gentoo-sources ist der empfohle Kernel, ich denke mal, 95% aller gentooer nutzen den, ohne das Ihnen wegen der explosiven Patches der Rechner um die Ohren fliegt.

War nicht das, was ich wollte, aber der Thread war dank Linus sowieso überflüssig. Konnte man ja vorher einfach nicht wissen.

----------

## Finswimmer

 *Quote:*   

> gentoo-sources ist der empfohle Kernel, ich denke mal, 95% aller gentooer nutzen den

 

Sure?

Ich nutze die vanilla-sources. 

Oder die hibernate-2-sources.

Wobei ich auf ungepatchte Kernels stehe, denn dann kann man davon ausgehen, dass alle Pakete damit funktionieren, denn damit werden sie auf jeden Fall getestet, was bei der Vielzahl an gepatchten Kernels wohl eher unmöglich ist...

Tobi

----------

## Carlo

 *Necoro wrote:*   

> aber 1.) nur weil Linus das sagt, ist es noch lange nicht der Wahrheit letzter Schluss
> 
> und 2.) das mag auf binär distros zutreffen - aber in Gentoo ist es nunmal notwendig, dass der Kernel als Source vorliegt - und da _alle_ Programme mit emerge als root compiliert werden ist eher schwachsinnig, für den Kernel dies genau nicht zu machen

 

Erstens geht es nicht darum, daß die Kernel-Sourcen zur Verfügung stehen, sondern darum, daß variable Daten in /usr gemäß FHS nichts zu suchen haben. Zweitens benutzt (hoffentlich) jeder, der sich ein wenig mit Portage auseinandergesetzt hat, FEATURES="userpriv usersandbox", um eben nicht mit Administrationsrechten zu compilieren. Alles andere ist zumindest achtlos zu nennen.

----------

## l3u

Ich hab auch die vanilla-sources. Und den pöhsen /usr/src/linux-Symlink :-P

 *Quote:*   

> sondern darum, daß variable Daten in /usr gemäß FHS nichts zu suchen haben

 

Ist ein Argument.

 *Quote:*   

> FEATURES="userpriv usersandbox" [...]
> 
> Alles andere ist zumindest achtlos zu nennen.

 

Warum ist das dann nicht die Standardeinstellung bzw. die Standardempfehlung? Warum steht es nicht hier? http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=2&chap=3

----------

## Carlo

Libby, schreib doch einen Bug Report, ich frage mich das auch schon eine geraume Weile. Die Webpage verweist als allererstes auf man make.conf ...

----------

## Klaus Meier

 *Finswimmer wrote:*   

> Wobei ich auf ungepatchte Kernels stehe, denn dann kann man davon ausgehen, dass alle Pakete damit funktionieren, denn damit werden sie auf jeden Fall getestet, was bei der Vielzahl an gepatchten Kernels wohl eher unmöglich ist...
> 
> Tobi

 

Na gut, können auch weniger sein. Aber ich hab hier noch nie von einem Problem gehört, welches aus den Gentoo-Patches resultiert. Soll jetzt aber nicht heißen, das es keine gibt. Ich nutze die gentoo-sources eigentlich solange wie ich gentoo nutze. Und naja, also beim 2.6.19 hab es mal für 12 Stunden etwas geklemmt.

----------

## Klaus Meier

 *Carlo wrote:*   

> Erstens geht es nicht darum, daß die Kernel-Sourcen zur Verfügung stehen, sondern darum, daß variable Daten in /usr gemäß FHS nichts zu suchen haben.

 Vom Prinzip her ok, aber alle Pakete, die die Kernelkonfiguration abfragen, schauen da nach. Oder kann man einstellen, wo der Kernel hin soll und wo dann auch die Konfiguration geprüft wird? Wenn man den Kernel nach /var/src installiert, dann müssen halt auch einige Pakete angepaßt werden.

Und dann ging es mir um das Argument gegen /usr/src, weil man da als User keine Schreibrechte hat. Ich für mich auf meinem Rechner halte alles andere für unbrauchbar. Kernel konfigurieren ist nun mal Aufgabe des Administrators. Also ich möchte keinen Kernel haben, wo mir als Administrator ein User sagt, den hab ich konfiguriert und gebaut, installier den mal für mich. Wobei ich alleine an meinem Rechner arbeite und Administrator und User die gleiche Person sind. Es mag bei anderen anders aussehen.

----------

## platinumviper

 *Necoro wrote:*   

> aber 1.) nur weil Linus das sagt, ist es noch lange nicht der Wahrheit letzter Schluss

 

Stimmt, aber er besitzt erheblich mehr Kernel-Kompetenz als die meisten von uns hier.

 *Necoro wrote:*   

> und 2.) das mag auf binär distros zutreffen - aber in Gentoo ist es nunmal notwendig, dass der Kernel als Source vorliegt

 

Nein, nur Kernel-Module (z.B. nvidia-drivers) benötigen Teile der Sourcen, alle anderen Programme greifen über die glibc auf Kernel-Funktionen zu. Deshalb gibt es die Header-Files zwei mal, einmal die des Kernels, und einmal die, mit denen die glibc kompiliert wurde.

 *Necoro wrote:*   

> und da _alle_ Programme mit emerge als root compiliert werden ist eher schwachsinnig, für den Kernel dies genau nicht zu machen

 

Emerge kompiliert alle Programme in einer Sandbox unterhalb von /var/tmp/portage, das war der Grund für die Probleme mit Kernel 2.6.19, da wurde versucht ausserhalb der Sandbox (im Kernel-Verzeichnis) einige Dateien anzulegen.

 *Necoro wrote:*   

> und 3.) macht es irgendein unterschied, ob der Kernel in /usr/src/linux oder in /opt/Linus/rocks/the/fuckin/planet liegt? - wichtig ist nur, dass er an einer definierten stelle liegt

 

Nein, es spielt keine Rolle wo der Kernel liegt, solange derjenige, der ihn kompilieren will Lesezugriff auf das Source-Verzeichnis und Schreibrechte im Output-Verzeichnis hat. Die Position muss auch nicht besonders definiert sein, bei der Installation werden Links in /lib/modules/<Versionsnummer> angelegt.

```
file -d /lib/modules/`uname -r`/{build,source} 

/lib/modules/2.6.19.3/build:  symbolic link to `/kernel/out/2.6.19.3'

/lib/modules/2.6.19.3/source: symbolic link to `/kernel/src/linux-2.6.19.3'
```

Und damit bin ich wieder beim ursprünglichen Thema: einen Tag nach 2.6.20 erschien 2.6.19.3 und damit geht auch VMware wieder.

platinumviper

----------

## mrsteven

 *Carlo wrote:*   

> Erstens geht es nicht darum, daß die Kernel-Sourcen zur Verfügung stehen, sondern darum, daß variable Daten in /usr gemäß FHS nichts zu suchen haben.

 

So gesehen gehört der Portage-Tree aber auch nach /var, oder was verstehe ich hier falsch?  :Confused: 

----------

## franzf

 *mrsteven wrote:*   

>  *Carlo wrote:*   Erstens geht es nicht darum, daß die Kernel-Sourcen zur Verfügung stehen, sondern darum, daß variable Daten in /usr gemäß FHS nichts zu suchen haben. 
> 
> So gesehen gehört der Portage-Tree aber auch nach /var, oder was verstehe ich hier falsch? 

 

Schau dir mal im Verzeichnis an was passiert, wenn ein Kernel (oder sonstwas) kompiliert wird. Ich glaube das ist es was Carlos als "variable Dateien" versteht. Wenn du nämlich nicht syncst ändert sich am portagetree auch nix.

Grüße

Franz

----------

## platinumviper

 *Klaus Meier wrote:*   

>  *Carlo wrote:*   Erstens geht es nicht darum, daß die Kernel-Sourcen zur Verfügung stehen, sondern darum, daß variable Daten in /usr gemäß FHS nichts zu suchen haben. Vom Prinzip her ok, aber alle Pakete, die die Kernelkonfiguration abfragen, schauen da nach. Oder kann man einstellen, wo der Kernel hin soll und wo dann auch die Konfiguration geprüft wird? Wenn man den Kernel nach /var/src installiert, dann müssen halt auch einige Pakete angepaßt werden.

 

Außer genkernel kenne kein Paket, das die Sourcen in /usr/src/linux sucht, so etwas nennt man Programmierfehler. Alle anderen Pakete suchen in /lib/modules/<Versionsnummer>/source bzw. /lib/modules/<Versionsnummer>/build. Zusätzlich gibt es bei Gentoo die Variablen KERNEL_DIR und KBUILD_OUTPUT, Pakete, die diese Variablen berücksichtigen können schon für den neuen Kernel kompiliert werden bevor mit ihm gebootet wurde (z.B. nvidia-drivers), Pakete, die sich an der Versionsnummer (uname -r) orientieren, können nur für den gerade laufenden Kernel kompiliert werden (z.B. vmware-mudules).

platinumviper

----------

## Carlo

 *Klaus Meier wrote:*   

> Prinzip her ok, aber alle Pakete, die die Kernelkonfiguration abfragen, schauen da nach. Oder kann man einstellen, wo der Kernel hin soll und wo dann auch die Konfiguration geprüft wird? Wenn man den Kernel nach /var/src installiert, dann müssen halt auch einige Pakete angepaßt werden.

 

Wie franzf schon angemerkt hat, ging es mir nicht darum, wo der Kernel nun installiert wird, sondern um die unnötige Kompilation als root und den hinterlassenen Objekt Code, der beim klassischen cd /usr/src/linux ; make <target> eben wieder in /usr landet.

Für Gentoos Profilauswahl ist übrigens ein Wechel vom Symlink zu einer Umgebungsvariable angedacht, iirc. Den unnötigen Kernel-Symlink loszuwerden, sollte auch machbar sein.

 *mrsteven wrote:*   

> So gesehen gehört der Portage-Tree aber auch nach /var, oder was verstehe ich hier falsch? 

 

Diese Diskussion gab es schon mehrfach. Bezüglich des Repositorys pflichte ich bei, die Distfiles würde ich nicht in /var sehen wollen. Letztendlich ist es so wie es ist, sei es aus historischen Gründen oder weil irgendwer andere Vorstellungen hatte. PORTDIR und DISTDIR sind frei wählbar und daher kümmert's mich nicht großartig.

----------

## l3u

Neues Thema? https://forums.gentoo.org/viewtopic-p-3891643.html

----------

## think4urs11

 *Libby wrote:*   

> Neues Thema? https://forums.gentoo.org/viewtopic-p-3891643.html

 

Neues Thema!  :Wink: 

Sofern etwas zum Thema FHS und wie Gentoo damit umgeht zu diskutieren ist dies bitte in Libbys Thread tun, sonstiges das zum eigentlichen Thema *dieses* Threads paßt bitte weiter hier.

----------

## jayson

Ich hab den Kernel 2.6.19 und 2.6.20 konfiguriert und kompiliert und bin völlig unzufrieden. Mein DVD Laufwerk funktioniert nicht richtig, meine Festplatte schafft laut hdparm 43mb/s und in der Praxis 23mb/s. Unter Kernel 2.6.18 hatte ich schnelle 38MB/s auch bei USB!

Also da muss irgendein ein Bug existieren, anders kann ich mir das nicht erklären. Ich verwende nämlich die gleichen (!!) Treiber.

Falls jemand ein ähnliches Problem hat und dazu eine Lösung gefunden hat, wäre es nett wenn derjenige diese postenoder auf diesen (http://groups.google.com/group/linux.gentoo.user/browse_thread/thread/5d333675df5c6343/de91cde32be112b3) Mailinglisten Beitrag antworten könnte

MfG Jay

----------

## Finswimmer

Hast du evtl. die Treiber von deinem Mainboard nicht aktiviert?

Gib mal Spezifikationen rüber, ob du exotische Hardware verwendest.

Tobi

----------

## Klaus Meier

Also ich hab auch das Gefühl, das mit 2.6.20 alles deutlich langsamer geworden ist. Dauert wesentlich länger, bis Anwendungen gestartet werden und Dateien kopieren scheint doppelt so lange zu dauern.

----------

## Finswimmer

 *Klaus Meier wrote:*   

> Also ich hab auch das Gefühl, das mit 2.6.20 alles deutlich langsamer geworden ist. Dauert wesentlich länger, bis Anwendungen gestartet werden und Dateien kopieren scheint doppelt so lange zu dauern.

 

Auf solche subjektiven Aussagen geb ich nicht wirklich viel.

Mir fällt zum Beispiel nichts auf.

Mach doch mal ein paar Tests mit time $cmd

Tobi

----------

## jayson

 *Quote:*   

> Hast du evtl. die Treiber von deinem Mainboard nicht aktiviert? 

 

Nicht das ich wüsste. Ich habe stinknormale SATA Controller, einen Core Duo mit 2GHz, ein 100gig SATA Festplatte und ein Dell Inspiron 9400 Royal.

Ich habe mal ein paar Dateien angehängt evtl. hat ja jemand eine ähnliche Konfiguration und kann mir helfen.

Danke!

(lspci -vv) http://www.web-upload.com/uploads/lspci-very-verbose.txt

(dmesg) http://www.web-upload.com/download_45808.html?her=dateimanager&order=uploaddatum&dir=DESC&von=0&where=

(kernel 2.6.20 gentoo-sources .config) http://www.web-upload.com/uploads/.config

MfG Jay

----------

## Vaarsuvius

noch eine kurze anmerkung fuer leute, die auf den 2.6.20 updaten wollen:

wenn ihr iptables benutzt, muesst ihr aufpassen, da hat sich was an der netfilter konfiguration geaendert... make oldconfig findets auch nicht, also die optionen manuell ueberpruefen..

wenn ihr v4l-dvb benutzt, die module kompilieren (noch) nicht gegen den 2.6.20er kernel. (steht auch hier)

----------

## sohalt

ati-drivers kompilieren auch nicht mit >= 2.6.18.

Dafür aber:

eselect kernel set <unter 2.6.18>

cp /boot/config /usr/src/linux

make -C /usr/src/linux modules_prepare

emerge ati-drivers

eselect kernel set 2.6.20

cp /lib/modules/<unter 2.6.18>/video/fglrx.ko /lib/modules/2.6.20/video

----------

## Necoro

 *sohalt wrote:*   

> ati-drivers kompilieren auch nicht mit >= 2.6.18.
> 
> Dafür aber:
> 
> eselect kernel set <unter 2.6.18>
> ...

 

Also meine Version (8.33.6-r1) kompiliert sich einwandfrei Oo (mit Kernel: 2.6.19-r5)

----------

## sohalt

Naja, aktuelle Stable funktioniert zumindest bei mir nicht. Ich glaube auch, mich an einen Bugreport auf bugs.gentoo.org errinnern zu können.

----------

## Klaus Meier

Also bis auf kurzfristige Ausnahmen läuft nvidia immer unter gentoo. Bei ATI gehen in 95% der Fälle entweder aktuelle Karten oder aktuelle Kernel oder aktueller Xorg nicht. Genauso ist das Verhältnis der Supportanfragen nvidia zu ATI 5 zu 95.

Wenn man keinen Streß haben will, dann sollte man Intel oder Nvidia Grafik benutzen. Und wenn man dann keine Onboardlösung haben möchte, dann bleibt nur Nvidia über.

----------

## Necoro

 *sohalt wrote:*   

> Naja, aktuelle Stable funktioniert zumindest bei mir nicht. Ich glaube auch, mich an einen Bugreport auf bugs.gentoo.org errinnern zu können.

 

das ATI-stable nicht funktioniert ist aber normal  :Wink: 

----------

## sohalt

Da kann ich als mehrjähriger ATI-Benutzer nichtmal wiedersprechen. Oft schafft der OpenSource-ATI-Treiber Abhilfe, nur war ich nicht in der Lage, mit ihm eine Auflösung von 1280x800 hinzubekommen. Würde ich mich jetzt eine Grafikkarte / Chip kaufen, würde ich mich gegen ATI entscheiden, doch bisher war es so, dass ich entweder keine Ahnung, oder keinen Einfluss hatte.

Zurzeit bin ich mit ATI aber relativ zufrieden (verhältnissmäßig), wenn man auf 3D verzichten kann, ist es OK.

----------

## mrsteven

```
#...

Section "Monitor"

        Identifier      "Monitor"   #evtl. anpassen

        VendorName      "foo"

        ModelName       "Laptop Display"

        HorizSync       31.5 - 60.0

        VertRefresh     50 - 70

        DisplaySize     331 207

        Option          "DPMS"

        Modeline        "1280x800@60" 83.9 1280 1312 1624 1656 800 816 624 841

EndSection

#...
```

  :Wink: 

----------

## sohalt

Faszinierend.

Ich krieg es leider nicht hin, "No mode of this name" (oder so ähnlich)  :Sad: . Auch mit deinem Stück xorg.conf war ich erfolglos, trozdem danke!

----------

## Genone

 *platinumviper wrote:*   

> Über den Symlink schrieb Linus schon vor sieben Jahren: *Quote:*   It's a symlink for
> 
> historical reasons, none of them very good any more (and haven't been
> 
> for a long time), and it's a disaster unless you want to be a C library
> ...

 

Sorry wenn ich diesen Subthread jetzt wieder aufwärme, aber es sollte erwähnt werden dass sich dieser Artikel hauptsächlich auf den /usr/include/asm bzw. /usr/include/linux Symlink bezieht und eben nicht auf /usr/src/linux, die Anmerkungen bzgl. /usr/src sind im wesentlichen nur eine Konsequenz um Probleme mit einem existierenden Symlink in /usr/include zu vermeiden. K.A. warum du ausgerechnet die interessanten Teile des Artikels weggelassen hast.

----------

## ChrisJumper

 *kil wrote:*   

> noch eine kurze anmerkung fuer leute, die auf den 2.6.20 updaten wollen:
> 
> wenn ihr iptables benutzt, muesst ihr aufpassen, da hat sich was an der netfilter konfiguration geaendert... make oldconfig findets auch nicht, also die optionen manuell ueberpruefen..
> 
> 

 

Ah.. habs grad bemerkt danke!

Aber schaut sich das einer mal an:

```
**WARNING** I2C adapter driver [NVIDIA i2c adapter 0 at 1:00.0] forgot to specify physical device; fix it!

```

Falscher Mainboard-Treiber? Ich steh auf dem schlauch.

----------

## Treborius

 *ChrisJumper wrote:*   

>  *kil wrote:*   noch eine kurze anmerkung fuer leute, die auf den 2.6.20 updaten wollen:
> 
> wenn ihr iptables benutzt, muesst ihr aufpassen, da hat sich was an der netfilter konfiguration geaendert... make oldconfig findets auch nicht, also die optionen manuell ueberpruefen..
> 
>  
> ...

 

wäre mal nett zu wissen wo die meldung herkommt ...

ist es vielleicht nur ein c-preprocessor #warning anweisung?

----------

## Bloodsurfer

Hm, mit I2C und der Kombi 2.6.20/nvidia-drivers hab ich auch Probleme, das wäre vielleicht einen eigenen Thread wert...

----------

