# gentoo-sources-2.6.23 diverse probleme

## Stormkings

Hallo zusammen!

benutzt hier auch schon jemand die gentoo-sources-2.6.23? Ich habe sie installiert, da ich mir längere akkulaufzeiten versprochen hatte.

Seit dem wechsel von 2.6.22-r5 habe ich hier auf einem hp/compaq 6710 notebook diverse probleme. 

 uvesafb funktioniert nicht und demnach kein bootsplash mehr (eigentlich geht der fb überhaupt nicht mehr)

 bei schließen des deckels (acpi button/lid) hängt sich der rechner häufig auf

 booten bzw laden der module durch udev dauert sehr lange ohne irgendwelche meldungen

 tasten für display brightness funktionieren nicht mehr, jedoch kann kpowersave es nun einstellen in den profilen

 portage melded sandbox violation bei alsa-driver und anderen paketen, die module instalieren (iwlwifi)

Würde mich interessieren, ob noch mehr solche probleme haben oder es schon lösungen gibt.

Grüße, dk

PS: hier vielleicht noch ein lspci, falls es interessant ist:

```
noname david # lspci

00:00.0 Host bridge: Intel Corporation Mobile Memory Controller Hub (rev 0c)

00:02.0 VGA compatible controller: Intel Corporation Mobile Integrated Graphics Controller (rev 0c)

00:02.1 Display controller: Intel Corporation Mobile Integrated Graphics Controller (rev 0c)

00:1a.0 USB Controller: Intel Corporation USB UHCI Controller #4 (rev 03)

00:1a.1 USB Controller: Intel Corporation USB UHCI Controller #5 (rev 03)

00:1a.7 USB Controller: Intel Corporation USB2 EHCI Controller #2 (rev 03)

00:1b.0 Audio device: Intel Corporation HD Audio Controller (rev 03)

00:1c.0 PCI bridge: Intel Corporation PCI Express Port 1 (rev 03)

00:1c.1 PCI bridge: Intel Corporation PCI Express Port 2 (rev 03)

00:1c.2 PCI bridge: Intel Corporation PCI Express Port 3 (rev 03)

00:1c.4 PCI bridge: Intel Corporation PCI Express Port 5 (rev 03)

00:1d.0 USB Controller: Intel Corporation USB UHCI Controller #1 (rev 03)

00:1d.1 USB Controller: Intel Corporation USB UHCI Controller #2 (rev 03)

00:1d.2 USB Controller: Intel Corporation USB UHCI Controller #3 (rev 03)

00:1d.7 USB Controller: Intel Corporation USB2 EHCI Controller #1 (rev 03)

00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev f3)

00:1f.0 ISA bridge: Intel Corporation Mobile LPC Interface Controller (rev 03)

00:1f.1 IDE interface: Intel Corporation Mobile IDE Controller (rev 03)

00:1f.2 SATA controller: Intel Corporation Mobile SATA Controller AHCI (rev 03)

02:04.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev b6)

10:00.0 Network controller: Intel Corporation PRO/Wireless 3945ABG Network Connection (rev 02)

18:00.0 Ethernet controller: Broadcom Corporation Unknown device 1713 (rev 02)

```

Last edited by Stormkings on Wed Oct 24, 2007 1:15 pm; edited 1 time in total

----------

## firefly

 *Stormkings wrote:*   

> uvesafb funktioniert nicht und demnach kein bootsplash mehr (eigentlich geht der fb überhaupt nicht mehr)

 

das umstellen der auflösung wurde in ein userspace tool ausgelagert (v86d) siehe http://dev.gentoo.org/~spock/projects/uvesafb/

 *Stormkings wrote:*   

> portage melded sandbox violation bei alsa-driver und anderen paketen, die module instalieren (iwlwifi)

 

Scheint ein sandbox bug zu sein (https://bugs.gentoo.org/show_bug.cgi?id=135745)

----------

## Stormkings

 *firefly wrote:*   

>  *Stormkings wrote:*   uvesafb funktioniert nicht und demnach kein bootsplash mehr (eigentlich geht der fb überhaupt nicht mehr) 
> 
> das umstellen der auflösung wurde in ein userspace tool ausgelagert (v86d) siehe http://dev.gentoo.org/~spock/projects/uvesafb/

 

Das weiß ich wohl. Ist auch eingetragen in der initrd im kernel. Ob sich das allerdings mit meiner eigenen verträgt weiß ich natürlich nicht. Kann man denn zwei initrd zusammen nutzen?

 *firefly wrote:*   

> 
> 
>  *Stormkings wrote:*   portage melded sandbox violation bei alsa-driver und anderen paketen, die module instalieren (iwlwifi) 
> 
> Scheint ein sandbox bug zu sein (https://bugs.gentoo.org/show_bug.cgi?id=135745)

 

Danke für die info, ist gelöst.

----------

## firefly

 *Stormkings wrote:*   

>  *firefly wrote:*    *Stormkings wrote:*   uvesafb funktioniert nicht und demnach kein bootsplash mehr (eigentlich geht der fb überhaupt nicht mehr) 
> 
> das umstellen der auflösung wurde in ein userspace tool ausgelagert (v86d) siehe http://dev.gentoo.org/~spock/projects/uvesafb/ 
> 
> Das weiß ich wohl. Ist auch eingetragen in der initrd im kernel. Ob sich das allerdings mit meiner eigenen verträgt weiß ich natürlich nicht. Kann man denn zwei initrd zusammen nutzen?

 

Dann wird die interne nicht verwendet, wenn du eine andere per initrd im bootlader angibst. Du musst dann v86d in deine initrd mit aufnehemen.

----------

## musv

Jein, 

mir scheint uvesafb noch ein bißchen buggy. Bei absolut identischer Kernelkonfiguration und nur unterschiedlichen Auflösungen bekomm ich mein Hintergrundbild beim Booten auf meinem großen Rechner, mein Notebook zeigt hingegen das Ding erst an, wenn der fbcondev-Dienst gestartet wird. Mit 2.6.22 und uvesafb ging es noch auf beiden problemlos.

Siehe dazu hier:

https://forums.gentoo.org/viewtopic-t-597482.html#4366949

----------

## Stormkings

Scheint mir in der tat etwas buggy zu sein. Hier zeigt dmesg zwar folgendes an es passiert aber nix. 

```
uvesafb: Intel Corporation, Intel(r)Crestline Graphics Controller, Hardware Version 0.0, OEM: Intel(r)Crestline Graphics Chip Accelerated VGA BIOS, VBE v3.0

uvesafb: VBIOS/hardware supports DDC2 transfers

uvesafb: monitor limits: vf = 60 Hz, hf = 49 kHz, clk = 71 MHz

uvesafb: scrolling: redraw

uvesafb: framebuffer at 0xd0000000, mapped to 0xf8a80000, using 7616k, total 7616k
```

Ob ich das init-script starte oder nicht spielt keine rolle. Wie kann sowas in den kernel aufgenommen werden?

dk

----------

## firefly

 *Stormkings wrote:*   

> Scheint mir in der tat etwas buggy zu sein. Hier zeigt dmesg zwar folgendes an es passiert aber nix. 
> 
> ```
> uvesafb: Intel Corporation, Intel(r)Crestline Graphics Controller, Hardware Version 0.0, OEM: Intel(r)Crestline Graphics Chip Accelerated VGA BIOS, VBE v3.0
> 
> ...

 

öhm der teil von uvesafb im kernel macht garnichts mit der auflösung. Das ändern der Auflösung wird vom v86d userspace programm übernommen.

Ich vermute einfach, das du dieses Programm nicht in deiner initrd(eigentlich heißt das jetzt initramfs) am richtigen platz hast (/sbin)

Ich habe hier eine initramfs am laufen welches v86d(uvesafb) + tuxonice/suspend2 userui v7.2 enthält, wenn ihr wollt kann ich die mal bereitstellen.

----------

## Stormkings

Ich meinte eher wieso uvesafb im kernel ist, wenn es so kompliziert ist. Die dokumentation finde ich sehr dürftig. Früher was es zb. möglich nach dem booten die module zu laden und den framebuffer zu starten. Das hab ich aber leider auch nicht hinbekommen. v86d liegt im /sbin verzeichnis meiner initramfs.

Wie erstellst du denn die initramfs? Mich würde mal die verzeichnisstruktur interessieren und das init-script darin.

dk

----------

## firefly

 *Stormkings wrote:*   

> Ich meinte eher wieso uvesafb im kernel ist, wenn es so kompliziert ist. Die dokumentation finde ich sehr dürftig. Früher was es zb. möglich nach dem booten die module zu laden und den framebuffer zu starten. Das hab ich aber leider auch nicht hinbekommen. v86d liegt im /sbin verzeichnis meiner initramfs.
> 
> Wie erstellst du denn die initramfs? Mich würde mal die verzeichnisstruktur interessieren und das init-script darin.
> 
> dk

 

öhm kompliziert ist es nicht wirklich.

Die Beschreibung, bis auf das mit der initramfs, sollte eigentlich ausreichend sein. In meiner initramfs befindet sich kein init-script, da sich in diesem image nur die programme für tuxonice/suspend2-userui, fbsplash_helper/fbcondecor_helepr(noch vom alten fbsplash), v86d, benötigte device-nodes und verzeichnisse und die splash konfigurationen befinden und somit kein initscript benötigt wird.

Bei dem initramfs image handelt es sich um ein cpio archiv. Zum erstellen des archives verwende ich 2 tools vom kernel und ein selbstgeschriebenes script(welches einfach nur die beiden anderen mit passenden parametern aufruft und das archiv dann noch komprimiert).

- gen_init_cpio (zu finden unter usr/ im kernel-build verzeichniss), welches das eigentliche archiv anhand einer dateiliste erstellt. 

- gen_initramfs_list.sh (zu finden unter scripts/ im kernel-source verzeichniss), dieses shell-script erzeugt die dateiliste für das gen_init_cpio tool. Diesem script wird einfach das Verzeichniss angegeben in dem sich die Verzeichniss-struktur samt dateien befindet, welche ins initramfs gepackt werden sollen.

- create_initramfs.sh:

```
#!/bin/bash 

./gen_initramfs_list.sh initramfs/ > temp.list

./gen_init_cpio temp.list > initrd-swsusp2

gzip initrd-swsusp2

rm -f temp.list
```

Ich habe ein Verzeichnis (initramfs) in dem sich folgende Dateistruktur befindet:

 *Quote:*   

> ll -R
> 
> .:
> 
> total 0
> ...

 

----------

## s.hase

 *musv wrote:*   

> Jein, 
> 
> mir scheint uvesafb noch ein bißchen buggy. Bei absolut identischer Kernelkonfiguration und nur unterschiedlichen Auflösungen bekomm ich mein Hintergrundbild beim Booten auf meinem großen Rechner, mein Notebook zeigt hingegen das Ding erst an, wenn der fbcondev-Dienst gestartet wird. 

 

Wirklich 100%-tig gleich? Guck mal nach

```

FB_CON_DECOR = y

```

in Deiner Kernelconfig. Eventuell hast Du das einfach vergessen.

----------

## musv

 *s.hase wrote:*   

> [
> 
> Wirklich 100%-tig gleich? Guck mal nach
> 
> ```
> ...

 

AthlonXP (funktioniert):

```
 zcat /proc/config.gz | grep FB_CON_DECOR

CONFIG_FB_CON_DECOR=y
```

Notebook (funktioniert nicht)

```
 zcat /proc/config.gz | grep FB_CON_DECOR

CONFIG_FB_CON_DECOR=y
```

Bei beiden ist die Initramdisk im Kernel aktiviert, bei beiden v86d installiert und bei beiden Rechnern auch die initramdisk erstellt. Mit vesafb-tng hat's auch bei beiden noch funktioniert.

----------

## s.hase

Ok, hätte ja sein können das es daran liegt. War bei mir zuerst das Problem. Alles ging (bis auf die Wiederholfrequenz), nur der Hintergrund kam erst später beim Booten.

----------

## AROK

 *Stormkings wrote:*   

> Ich meinte eher wieso uvesafb im kernel ist, wenn es so kompliziert ist. Die dokumentation finde ich sehr dürftig. Früher was es zb. möglich nach dem booten die module zu laden und den framebuffer zu starten. Das hab ich aber leider auch nicht hinbekommen. v86d liegt im /sbin verzeichnis meiner initramfs.
> 
> Wie erstellst du denn die initramfs? Mich würde mal die verzeichnisstruktur interessieren und das init-script darin.
> 
> dk

 

entschuldigt die dumme Frage, aber warum braucht man für uvesafb eine initramfs Datei? 

Ich dachte immer man braucht die nur, wenn man z.B den Treiber für den Zugriff auf / nicht im Kernel hat. 

Gruß

AROK

----------

## michel7

 *AROK wrote:*   

> 
> 
> entschuldigt die dumme Frage, aber warum braucht man für uvesafb eine initramfs Datei? 
> 
> Ich dachte immer man braucht die nur, wenn man z.B den Treiber für den Zugriff auf / nicht im Kernel hat. 
> ...

 

braucht man eigentlich nicht unbedingt, aber wenn du willst dass dein splash gleich nachm kernel laden kommt dann ist initramfs ein muss

----------

## firefly

 *michel7 wrote:*   

>  *AROK wrote:*   
> 
> entschuldigt die dumme Frage, aber warum braucht man für uvesafb eine initramfs Datei? 
> 
> Ich dachte immer man braucht die nur, wenn man z.B den Treiber für den Zugriff auf / nicht im Kernel hat. 
> ...

 

uvesafb und v86d haben nichts mit splash zu tun, dafür ist der fbcondecor zuständig.

Sondern nur für die Änderung der Auflösung. Wenn v86d in der initramfs liegt wird dei Auflösung auch beim kernel-start direkt umgeschalten. Denn dafür ist das programm v86d da. Ohne v86d keine Änderung der Auflösung.

Es kann sein, das nachdem "/" gemountet wurde, das der kernel, bzw. der kernel teil von uvesafb das program v86d startet.

----------

## nikk

 *Quote:*   

> uvesafb und v86d haben nichts mit splash zu tun, dafür ist der fbcondecor zuständig. 

 

Das heißt dann also, der Hinweis im Gentoo Wiki http://de.gentoo-wiki.com/Fbsplash ist falsch?

 *Quote:*   

> Vesafb-Tng ist nicht mehr enthalten ab gentoo-sources-2.6.23! Stattdessen nur noch uvesafb. Damit können sowohl 32-bit als auch 64-bit Systeme (x86 / amd64) fbsplash nutzen! 

 

Ich versuch das gerade auf einem AMD64 Sytem umzusetzen  und "brech mir irgendwie die Finger" dabei  :Sad: 

----------

## firefly

 *nikk wrote:*   

>  *Quote:*   uvesafb und v86d haben nichts mit splash zu tun, dafür ist der fbcondecor zuständig.  
> 
> Das heißt dann also, der Hinweis im Gentoo Wiki http://de.gentoo-wiki.com/Fbsplash ist falsch?
> 
>  *Quote:*   Vesafb-Tng ist nicht mehr enthalten ab gentoo-sources-2.6.23! Stattdessen nur noch uvesafb. Damit können sowohl 32-bit als auch 64-bit Systeme (x86 / amd64) fbsplash nutzen!  
> ...

 

Ja und Nein. Der hinweis ist an sich richtig. 

uvesafb + userspace tool v86d ersetzen vesafb-tng. 

vesafb-tng hatte auch nichts mit dem anzeigen des Splash selbst zu tun, sondern nur zum ändern der Auflösung/Grafikmodus, damit es überhaupt möglich ist einen fb-splash anzeigen zu können. 

fbdecorator ersetzt den fbsplash patch bzw. fbsplash wurde in fbdecorator umbenannt.

Soweit ich das verstanden habe, stellt der kernel patch von fbdecorator/fbsplash  nur eine schnitstelle bereit, über die dann die userspace tools splash_helper(fbsplash, alt) bzw. fbcondecor_helper den splash anzeigen können.

So nun kommen wir zu deinem Problem:

Hast du folgende Punkte von der Anleitung von spock (http://dev.gentoo.org/~spock/projects/uvesafb/ sektion uvesafb::installation instructions) beachtet?

Kernel konfiguration:

Connector - unified userspace <-> kernelspace linker(CONFIG_CONNECTOR=y) und

Graphics support ---> Userspace VESA VGA graphics support (CONFIG_FB_UVESA=y)

den kernel neu übersetzt, kblic reemerged und v86d installiert

danach die kernel-konfiguration für die initramfs unterstützung entsprechend ändern, nur notwendig, wenn man direkt beim starten die Auflösung ändern möchte, z.b. zum anzeigen eines boot-Splash(diese Änderung kann man auch gleichzeigt mit dem aktivieren der uvesafb option im kernel machen ):

Initial RAM filesystem and RAM disk (initramfs/initrd) support

 und  /usr/share/v86d/initramfs in Initramfs source file(s) <---- Verwendung dieses initramfs source ist nur zum testen ob uvesafb überhaupt funktioniert bzw. wenn man kein bootsplash haben möchte

kernel neu übersetzen

in der konfiguration des bootmanagers die kernel zeile so abändern das jetzt uvesafb verwendet werden soll

beispiel (nur der relevante part):  *Quote:*   

> video=uvesafb:1024x768-32,mtrr:3,ywrap

 

Wenn lilo verwendet wird dann nicht vergessen die veränderte konfiguration per lilo in den MBR zu schreiben.

Wenn du diese punkte beachtet hast, dann sollte zumindestens beim starten des Kernels sich die Auflösung der Konsole ändern.

Denn wenn sich nicht die Auflösung/der Videomode ändert, dann kann (soweit ich weis) kein splash angezeigt werden.

Also überprüf doch erstmal ob sich bei dir die Auflösung ändert beim starten des Kernels. Dann sehen wir weiter.

----------

## nikk

Schön das Du mir helfen willst.

Am Wochenende werd ich es mal weiter ausprobieren.

Ich benutze grub und hab mir die Anweisungen auf der Seite von Spock angeschaut.

 *Quote:*   

> "fbdecorator"

  => damit meinst du sicher diesen "fbcondecor" ?

----------

## firefly

 *nikk wrote:*   

> Schön das Du mir helfen willst.
> 
> Am Wochenende werd ich es mal weiter ausprobieren.
> 
> Ich benutze grub und hab mir die Anweisungen auf der Seite von Spock angeschaut.
> ...

 

stimmt hab mich vertippt

----------

