# Kernel 2.6.22

## acern300

Hallo, generell habe ich Gentoo schon öfters installiert, jedoch immer der Anleitung nach mit dem Kernel aus den Gentoo-sources.

Heute wollte ich mal den Ofiziellen Kernel 2.6.22 draufpacken, habe aber leider keine Ahnung, wie ich das hinkriegen soll .... Steht leider nicht in dem Handbuch, habe die vanilla-sources versucht, kommt aber auch nur der 2.6.20 raus.... könnt ihr mir helfen ? Danke im vorraus ;-P

----------

## firefly

sync mal neu, der vanilla 2.6.22 ist schon als ebuild im portage:

http://packages.gentoo.org/search/?sstring=vanilla-sources

wie auch die gentoo-sources version

----------

## acern300

Wow, danke für die schnelle Antwort ;-P

----------

## Martux

Die gentoo-sources sind aber auch ~x86 verfügbar...

----------

## tuxianer

Nur als Tipp, wegen Kernel 2.6.22, zur Zeit meldet vmware-modules bei einem remerge unter dem neuen Kernel noch macken, konkret heißt das die Module lassen sich nicht einkompilieren.

Siehe : https://bugs.gentoo.org/show_bug.cgi?id=182595

----------

## _eckobar_

hallo leute!

habe mit den gentoo-source-2.6.22 auch so mein problem.

bei einem 

```
make && make modules_install
```

 erscheint folgende abschließende meldung 

```
Kernel: arch/i386/boot/bzImage is ready  (#1)

  Building modules, stage 2.

  MODPOST 1 modules

  CC      drivers/scsi/scsi_wait_scan.mod.o

  LD [M]  drivers/scsi/scsi_wait_scan.ko

  INSTALL drivers/scsi/scsi_wait_scan.ko

if [ -r System.map -a -x /sbin/depmod ]; then /sbin/depmod -ae -F System.map  2.6.22-gentoo; fi
```

jedoch wird scsi_wait von mir sicher nicht als modul ausgewählt, ich hab überhaupt keine module in meinem kernel (mir ist klar, dass durch diese tatsache ein make modules_install eigentlich obsolete wäre, jedoch mache ich das immer zur sicherheit, dass ich checke ob ich mich nicht verhaut habe)... hab den eintrag in der .config lokalisiert und zwar:

```
...

#

# Some SCSI devices (e.g. CD jukebox) support multiple LUNs

#

# CONFIG_SCSI_MULTI_LUN is not set

# CONFIG_SCSI_CONSTANTS is not set

# CONFIG_SCSI_LOGGING is not set

# CONFIG_SCSI_SCAN_ASYNC is not set

--> CONFIG_SCSI_WAIT_SCAN=m

#

# SCSI Transports

...
```

wenn ich den eintrag vor dem compile CONFIG_SCSI_WAIT_SCAN kommentiere oder lösche ist er nach dem durchlauf wieder im .config zu finden, SCSI_WAIT ist ebenfalls wieder als modul kompiliert.

auch ein setzen auf 

```
CONFIG_SCSI_WAIT_SCAN=y
```

 hilft nicht, nach durchlauf wieder module, sowohl compile als auch in .config

daher folgende fragen:

 wo finde ich im MENU_CONFIG das equivalent zu CONFIG_SCSI_WAIT_SCAN? ich habs nicht gefunden bzw. übersehen

 wie kann CONFIG_SCSI_WAIT_SCAN zwingend build-in machen?

hat jemand eine idee? bin wahrscheinlich nur zu blöd, aber ich komm einfach nicht drauf

----------

## _eckobar_

auch die verwendung der version 2.6.22-r1 hat nichts an meinem problem geändert

----------

## ChrisJumper

 *_eckobar_ wrote:*   

> 
> 
>  wo finde ich im MENU_CONFIG das equivalent zu CONFIG_SCSI_WAIT_SCAN? ich habs nicht gefunden bzw. übersehen
> 
>  wie kann CONFIG_SCSI_WAIT_SCAN zwingend build-in machen?
> ...

 

Sofern ich das beurteilen kann handelt es sich hier um ein Symbol das automatisch gesetzt wird, in Abhängigkeit zu den SCSI-Einstellungen. Kurz gesagt, es gibt kein equivalenten Eintrag in MENU_CONFIG. Rausgefunden hab ich das mit der Suchfunktion von "make menuconfig", dann "/" drücken und "WAIT" eintragen. Die Antwort lautete: 

```
 Symbol: SCSI_WAIT_SCAN [=m] 
```

Ob, und in wie weit das jetzt eine "make modules_install" benötigt kann ich nicht sagen. Aber theoretisch stimme ich dir zu :)

----------

## misterjack

x11-drivers/xf86-input-evdev-1.1.5-r1 funktioniert nicht mehr mit Kernel 2.6.22 - Laut Logs sind mir jetzt keine interessanten Fehlermeldungen ins Auge gesprungen, hab auch angesichts der Uhrzeit jetzt auf x11-drivers/xf86-input-mouse zurückgegriffen  :Smile: 

```
Section "InputDevice"

    Identifier  "Mouse"

    Driver      "evdev"

    Option      "Device"    "/dev/input/mouse0"

    Option      "CorePointer"

EndSection
```

@_eckobar_

Tritt das auch auf, wenn CONFIG_MODULES nicht gesetzt ist? (Modules-Support ausgeschalten)

----------

## _eckobar_

 *misterjack wrote:*   

> @_eckobar_
> 
> Tritt das auch auf, wenn CONFIG_MODULES nicht gesetzt ist? (Modules-Support ausgeschalten)

 

coole idee ... wenn CONFIG_MODULES nicht gesetzt ist, wird SCSI_WAIT "build in" gemacht. jedoch ist das für mich nicht wirklich eine option, da ich meine alsa-driver und nvidia-driver als module habe.(bei diesen zwei habe ich mich auf grund der aktualität für module entschieden und nicht build in).

hat vielleicht noch jemand eine idee, wie ich SCSI_SCAN zwingend build-in machen kann?

----------

## schachti

Also zum 2.6.22: Der fühlt sich bei mir extrem langsam an, ständig hängt was, Mausklicks werden nicht erkannt usw. - ich gehe mal wieder auf 2.6.21 zurück.

----------

## hoschi

Also bei mir funktioniert EVDEV nach wie vor wunderbar. Sagt mal, warum steuert ihr eure Eingabegeräte über /dev an?

Mit UDEV reicht wirklich nur der Gerätename, so erkennt Xorg die Maus oder was auch immer sofort.

----------

## astaecker

 *hoschi wrote:*   

> Mit UDEV reicht wirklich nur der Gerätename, so erkennt Xorg die Maus oder was auch immer sofort.

 

Kannst du dazu ein Beispiel bringen? Oder einen Link, wo man das Vorgehen nachlesen kann? Danke.

----------

## ChrisJumper

 *schachti wrote:*   

> Also zum 2.6.22: Der fühlt sich bei mir extrem langsam an, ständig hängt was, Mausklicks werden nicht erkannt usw. - ich gehe mal wieder auf 2.6.21 zurück.

 

Hi Schachti,

also ich hatte zuerst auch das Problem mit dem hängen der Maus.. oder einem stottern von Mplayer. Hab das zuerst auch auf den Kernel geschoben. Aber wie dem so ist aktualisiert man immer vieles Parallel. Und dabei flog auch der neue nvidia-Treiber ins Haus (Version  100.14.11).

Wenn du das nvidia-modul fürs glx-Rendering benutzt, starte von der Kommando-Zeile mal glxgears. Sollte da gleich nach dem start eine Fehlermeldung erscheinen, liegt es evt. (wie bei mir) daran.

Wenn ich mich richtig erinnere beschreibt die Fehlermdeldung Probleme mit den Benutzerrechten der Datei /dev/nvidiactl und das er dann auf Software-Rendering ausweicht oder sowas. (Bitte nicht auf diese Aussage Festnagel ich weiß es nicht mehr genau.)

Auf der Suche hier im Forum haben zwar einige das Problem gelöst indem sie die Datei mit chmod 666 freigeben, aber mir erschien folgende alternative sicherer..

Es hilft hier einfach den User in die Gruppe "Video" aufzunehmen und sich neu Anzumelden schon ist alles wieder im grünen Bereich.

Mfg Chris

----------

## schachti

Bei mir ist der nvidia-Treiber inzwischen wieder "gedowngradet", daran lag's wohl nicht. Ich bin dann zurück zum 2.6.21, und alles ist wieder gut. Kann sein, daß das Problem nicht direkt beim Kernel liegt, aber mit dem "alten" Kernel geht alles wie gewohnt...

----------

## hoschi

 *arlsair wrote:*   

>  *hoschi wrote:*   Mit UDEV reicht wirklich nur der Gerätename, so erkennt Xorg die Maus oder was auch immer sofort. 
> 
> Kannst du dazu ein Beispiel bringen? Oder einen Link, wo man das Vorgehen nachlesen kann? Danke.

 

 *Quote:*   

> 
> 
> Section "InputDevice"
> 
>     Identifier  "IBM Trackpoint"
> ...

 

Mit lsusb oder dmesg nach dem Geraetname ausschau halten.

Ersteres ist mein Trackpoint im Thinkpad (PS/2), und das andere ist der USB-Stick meiner Logitech V-200 Maus.

----------

## Ampheus

Habe auch diese Geschwindigkeitsprobleme und schiebe es ganz klar auf die Festplatten:

```
hdparm -tT /dev/hda

/dev/hda:

 Timing cached reads:   1976 MB in  2.00 seconds = 988.04 MB/sec

 Timing buffered disk reads:    6 MB in  3.29 seconds =   1.82 MB/sec
```

Das ist nich normal, oder?

Auch, dass die Festplatte als hda und nicht mehr als sda erkannt wird, scheint mir so nicht korrekt zu sein. Hat da jemand nen heißen Tipp?

----------

## musv

Und weil wir grad beim Lästern über 2.6.22 waren:

Lirc will auch nicht mehr. D.h. es compiliert problemlos. Laden der Module funktioniert ebenfalls perfekt (bei mir lirc_dev, lirc_i2c). Dmesg meint auch, daß alles ok wäre. Nur leider fehlt das Device (/dev/lirc/0). Tja, und damit bleibt auch bei mir erstmal 2.6.21 aktuell.

----------

## Ampheus

Ah habs behoben. Es lag daran, dass der alte ATA-Treiber noch im Kernel drin war.

----------

