FS#9482 - uvesafb support: include v86d and rebuild klibc

Attached to Project: Arch Linux
Opened by Giorgio Lando (patroclo7) - Thursday, 07 February 2008, 09:19 GMT
Last edited by Roman Kyrylych (Romashka) - Sunday, 06 April 2008, 09:09 GMT
Task Type Feature Request
Category Packages: Testing
Status Closed
Assigned To Tobias Powalowski (tpowa)
Thomas Bächler (brain0)
Architecture All
Severity Medium
Priority Normal
Reported Version 2007.08-2
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 5
Private No


The kernel 2.6.24 in testing include the new uvesafb driver as a module. However, in order to use it, two actions are needed from the user and could perhaps be done from the distro (when 2.6.24 hits testing):
1) klibc needs to be rebuilt against a kernel tree including uvesafb (so against a 2.6.24 kernel), as stated in http://dev.gentoo.org/~spock/projects/uvesafb/
2) uvesafb needs a regulating daemon, called v86d, see again http://dev.gentoo.org/~spock/projects/uvesafb/. May be this could be included in an official repo since it is a needed in order to use a kernel module in the stock kernel. It is actually in the AUR. The package in the AUR includes also the initcpio hook needed to run v86d in early userspace.

However, this initcpio could be unnecessary, for me it is enough that the user lists the regulating daeomon in BINARIES in /etc/mkinitcpio.conf. And actually the possible scenarios with uvesafb are heterogeneous, as you can see in the wiki article for uvesafb: http://wiki.archlinux.org/index.php/Uvesafb, so perhaps it is enough to package the v86d regulating daemon and leaves to the user the freedom to define everything else.

Additional info:
* package version(s): kernel26-2.6.24, klibc-1.5-3, v86d-0.1.3

Steps to reproduce:
This task depends upon
 FS#9813 - mkinitcpio: add /dev/mem 

Closed by  Roman Kyrylych (Romashka)
Sunday, 06 April 2008, 09:09 GMT
Reason for closing:  Implemented
Comment by Thomas Bächler (brain0) - Thursday, 07 February 2008, 10:23 GMT
Building klibc against 2.6.24 is problematic: When I finally managed to rebuild it, I couldn't link any binaries against this new klibc version. Until I can solve this problem, I can't provide v86d.
Comment by Shevchenko Taras (airstep) - Wednesday, 13 February 2008, 09:46 GMT
Same thing - after building klibc my system is fault. Kernel panic - bad value. Just in waiting for new klibc :P.
Comment by Marco Rocco (ech0s7) - Thursday, 14 February 2008, 19:50 GMT
If i recompile klibc(any versions!) on kernel 2.6.24, recreated mkinitcpio, at boot kernel go in panic:
::Loading Initramfs
-/init: 44: replace: not found
-/init: 44: replace: not found
export: 44: bad variable name

Comment by Thomas Bächler (brain0) - Thursday, 14 February 2008, 19:56 GMT
You cannot simply recompile klibc without recompiling applications that depend on it. You have to be very careful with that. However, I hope to get time do try again tomorrow.
Comment by Marco Rocco (ech0s7) - Thursday, 14 February 2008, 21:02 GMT
brain0, klibc-extras doesn't compiles on kernel 2.6.24, this is the log of makepkg for klibc-extras: http://pastebin.archlinux.org/28770
Comment by Thomas Bächler (brain0) - Thursday, 14 February 2008, 21:29 GMT
That's because you broke klibc, it took me hours to get that solved, and there were still problems.
Comment by Thomas Bächler (brain0) - Thursday, 28 February 2008, 08:40 GMT
I got klibc to build and work again, the current version is in the Arch CVS tree. I added some patch from gentoo to support the new x86 architecture in 2.6.24 and added options=(!strip), because some modified logic in makepkg thought klibc.so was an executable, thus removing its symbols and making it impossible to link against it.

I am going to add this to testing as soon as I finished updating klibc-udev (I also built the old klibc-udev version against the new klibc for testing purposes). Please be patient for another day or so.

I also built v86d. I think the messages I get in dmesg are now more sane, but 'modprobe uvesafb' still gives me a blank screen and seems to freeze my machine.
Comment by Thomas Bächler (brain0) - Friday, 29 February 2008, 18:50 GMT
I added the new klibc stuff to testing. klibc-udev is still the old version 116, but compiled against new klibc (expect a 118 package soon). v86d is also in testing now, however I still couldn't make it work, any feedback on that is appreciated (also patches to the mkinitcpio hook if it needs to be improved).
Comment by Thomas Bächler (brain0) - Sunday, 02 March 2008, 16:34 GMT
The -3 package is now more complete, see the arch wiki for instructions. Romashka reported it working on i686, but I cannot make it work on x86_64, the screen simply becomes blank.
Comment by Giuseppe Calderaro (iceman81) - Monday, 10 March 2008, 22:31 GMT
v86d package in testing does NOT work with fbcondecor+splash at boot in initramfs.
this is the output of the "file" command for v86d_klibc
v86d_klibc: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked (uses shared libs), stripped

and this is the output of the "file" comma[iceman81@wopr sbin]$ file v86d-ice
v86d-ice: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.6.16, statically linked, stripped

maybe that "uses shared libs" could be the problem...
Comment by Thomas Bächler (brain0) - Monday, 10 March 2008, 22:33 GMT
No, that is not the problem. The "uses shared libs" part means that klibc is loaded on runtime instead of being built into the binary. You could elaborate more on what doesn't work exactly.
Comment by Giuseppe Calderaro (iceman81) - Monday, 10 March 2008, 22:44 GMT
using v86d_klibc i get this error

uvesafb: Getting VBE info block failed (eax=0x4f00, err=-3)
uvesafb: vbe_init() failed with -22
uvesafb: probe of uvesafb.0 failed with error -22

i use 915resolution_static BEFORE loading uvesafb module in order to use 1280x800 resolution.
to do so i patched the init file in the ramdisk.
i also patched initscripts in order to use silent splash screen during the boot.
v86d-ice works even with all this tricks.
Comment by Giuseppe Calderaro (iceman81) - Tuesday, 11 March 2008, 09:41 GMT
i think i solved the issue. i looked at v86d source code. it needs /dev/zero and /dev/mem to be into ramfs, 'cos it mmaps such files.
i changed /lib/initcpio/install/v86d and /lib/initcpio/hooks/v86d.
now it works perfectly. i think all the packages about v86d on aur are quite useless now.


   v86d (0.3 KiB)
   v86d (0.1 KiB)
Comment by Thomas Bächler (brain0) - Tuesday, 11 March 2008, 10:31 GMT
We have to add /dev/mem to initramfs by default, then this should work (the rest is there already). This should also solve the problem that v86d fails if started before udev.
Comment by Giuseppe Calderaro (iceman81) - Tuesday, 11 March 2008, 10:39 GMT
i inflated kernel26.img and have NOT found /dev/mem (/dev/zero was already there instead). however i think that every packet should provide every stuff it needs to work properly. So i suggest to add /dev/mem and /dev/zero in the install script even if they are already there.
Comment by Giorgio Lando (patroclo7) - Tuesday, 11 March 2008, 10:44 GMT
The solution to the bug which is blocking this would already accomplish this result: /dev/mem will be added to the initramfs by the base hook of mkinitcpio, so just follow  bug 9813 
Comment by Thomas Bächler (brain0) - Tuesday, 11 March 2008, 10:57 GMT
The place for /dev/mem is in the base hook. The bug is only a problem if you want uvesafb to start very early (before udev). I will take care of the /dev/mem problem.