[UPDATE 13.10.2007: Kernel 2.6.23 "Vanilla" läuft nun auf Asus G1 LinuxMint 3.1 ] (Original Artikel vom 8.9.2007) Kernel backen ist für mich eigentlich schon lange aus der Mode gekommen, dazu funktioniert einfach viel zuviel aus dem Stehgreif hinaus. Es gibt natürlich immer noch die eine oder andere Gelegenheit, zum Beispiel, wenn man einen besonderen Treiber braucht. Beim Asus G1 funktioniert ja eigentlich alles out of the box. Nur das oled Display braucht einen Patch im Kernel, ansonsten muß man immer das usbhid modul rmmoden, weil das sich blöderweise das oled Display schnappt. Der Auto von asusoled hat einen Patch bei den Kernel Entwicklern eingereicht. Mit erscheinen des 2.6.23 Kernels sollte das dann aus der Welt sein. Zur Zeit ist der RC 5 aktuell, weil ich aber den RC 1 bei mir auf der Platte habe, habe ich den einfach genommen. Ich habe zum kompilieren make-kpkg benutzt. Vorher mit der Umgebungsvariable CONCURRENCY_LEVEL die Anzahl der CPU's bekannt gemacht, (wenn man nicht ohnehin im /etc/ kernel-pkg.conf CONCURRENCY_LEVEL := 2 gesetzt hat) damit das make nicht so lange dauert, weil immer zwei parallele Prozesse angestossen werden (also das -j im normalen make) Endlich eine vernünftige Nutzung für den Dual Core
export CONCURRENCY_LEVEL=2 (oder 3)Das hat dann ca. 15 Minuten gedauert und ich konnte mit dpkg -i den Kernel installieren. Das der Nvidia Treiber nicht gleich geklappt hat, hat mich nicht besonders erschreckt, mehr schon die Tatsache, das der allerneueste NVIDIA-Linux-x86-100.14.11-pkg1.run wegen eines Compile Error abbrach. [update 13.10.2007: Der aktuelle Nvidia Kernel 100.14.19 funktioniert ohne Patch]
make-kpkg --initrd kernel_image modules_image
NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c: In function 'nvidia_init_module':
NVIDIA-Linux-x86-100.14.11-pkg1/usr/src/nv/nv.c:1326: error: too many arguments to function 'kmem_cache_create'
... und so weiter
Glücklicherweise war ich nicht der erste mit diesem Problem und so fand ich hier einen Patch, der das reparierte.
Aber ein noch größeres Problem war der Wlan Treiber, der ging nicht, auch mit viel Geduld und Spucke, war da nichts zu wollen.
Ich fand einen neueren, alternativen Treiber, auch von Intel mit Namen iwlwifi-0.1.14, den habe ich zum laufen bekommen und es geht erst mal. Der iwlwifi-0.1.15 geht übrigens nicht, das sind daily builds, da kann so was auch mal vorkommen, also ruhig den neuesten versuchen, wenns nicht geht, dann eben einen, der etwas älter ist. [update 13.10.2007]: Ich habe den iwlwifi-0.1.17 benutzt und damit quasi auf anhieb Erfolg gehabt. Allerdings erwartet der Treiber die Firmware mit Namen iwlwifi-3945-1.ucode und nicht, wie im Paket iwlwifi-3945-ucode-2.14.4 iwlwifi-3945.ucode. Einen Tipp im Vofeld habe ich bei den Gentoo Leuten gefunden und umgesetzt. Man sollte nur den MAC80211 Stack verwenden CONFIG_MAC80211=m und den üblichen, auch für den ipw3945 benutzten WLAN80211 Stack abschalten CONFIG_WLAN_80211 not set. (Ok, Modul einfach nicht laden würde auch gehen
Meine derzeit benutzte .config packe ich noch in den Downloadbereich, damits einfacher wird.
Schau dir mal folgenden Patch (gegen Ende) an: http://home.ircnet.de/cru/usblock/dist/usblock-udev.patch
Dort wird eine Methode gezeigt, ein Gerät, dass sich der usbhid-Treiber geschnappt hat, wieder zu lösen (funktioniert aber automatisch wohl nur dann, wenn man udev benutzt).
Das könnte helfen, das Problem zu lösen, ohne einen eigenen Kernel zu bauen.
Also der Patch, der vom asusoled Autor ist, funktioniert ziemlich sicher auch mit dem 2.6.20, nur wenn, dann wollte ich schon den 23er, weil der hat noch ein paar andere gimmicks. aber dein link ist auch interessant und eigentlich auch nur ein kleiner patch, das meiste ist lizenz geschwafel. Danke dafür Ps: Eben bin ich gefrustet, habe Papierkram und EK 2006 Unterlagen gesucht, son Mist, Mann, wie ich das hasse....