I followed the tutorial on the gentoo wiki to use uvesafb. But in nearly 40% of all boots the kernel hangs on the scheduler selection (resolution is still small, probably the point where uvesa would be loaded). I can not find any hints in dmesg and logfiles. And I can not tell how to reproduce. It seems very randomly. In addition, splashutils wont work for me as well. I do not get any error message, but the splash does not appear. Do not know if splashutils causes this problem, but with vesafb everything is fine. If the boot was successful I do not have any further problems. Here the part of my old grub.conf (now I use 2.6.23-r9 with vesafb): title=Gentoo Linux 2.6.25 Exp root (hd0,0) kernel /boot/kernel_25_exp root=/dev/sda3 video=uvesafb:1024x768-32@60,mtrr:3,ywrap splash=verbose,fadein,theme:Shodan CONSOLE=/dev/tty1 initrd (hd0,0)/boot/shodan-1024x768 Reproducible: Sometimes Steps to Reproduce: 1. Build the kernel with the v86d ramdisk and activate uvesa in kernel features and grub config. Probably use splashutils 2. Boot the kernel 3. Have bad luck Actual Results: The kernel hangs at the scheduler selection and does not react anymore. I have to reset my machine Expected Results: boot as usual I run an ~amd64 machine with intel quadcore, 4GB DDR2-800, nforce chipset and geforce 8800gtx. I use splashutils, which wont work with uvesafb for me. Gentoo is up to date
Could you please provide the output of fbset -i (when uvesafb works during boot)? Could you also try emerging v86d with the 'debug' USE flag and running testvbe (please attach the output of this program). And finally, could you maybe try to build uvesafb as a module and try loading it manually with modprobe a few times (you'll have to reboot after uvesafb is successfully loaded) to see whether it causes a hang this way as well?
It seems that hrtricks (high-resolution preemption ticks) are to blame for this bug: https://bugs.launchpad.net/linux/+bug/258381 Would the reporter please confirm as to whether the problem disappears in a 2.6.27.5 based kernel? In the meantime, I'm adding bug 247453 as a depend.
Also, I've added a patch for 2.6.25 which the reporter may wish to test against the specific kernel he was using at the time that the bug was detected: http://bugs.gentoo.org/attachment.cgi?id=172297&action=view
