After world's recompilation with gcc-4.3 and recompilation of kernel v86d doesn't start anymore, it segfaults with the following message: v86d[358]: segfault at fffffffe eip 08049345 esp bfbd11e0 error 6 uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 It works if: - world is compiled with gcc-4.2.* and kernel is compiled with gcc-4.2.* - world is compiled with gcc-4.2.* and kernel is compiled with gcc-4.3 It doesn't work if: - world is compiled with gcc-4.3 and kernel is compiled with gcc-4.2.* - world is compiled with gcc-4.3 and kernel is compiled with gcc-4.3 Actually I had it working some time ago because I figured out it is needed to recompile glibc after world, but now it doesn't work either. I recompiled world twice and it still segfaults. Reproducible: Always Steps to Reproduce: 1. emerge world using gcc-4.3 2. recompile kernel with uvesafb Actual Results: v86d segfaults. Expected Results: v86d works. emerge --info: Portage 2.3_pre9377 (default-linux/x86/2007.0, gcc-4.3.0-pre20080227, glibc-2.7-r1, 2.6.24-zen1-g0f1ab7a2 i686) ================================================================= System uname: 2.6.24-zen1-g0f1ab7a2 i686 AMD Athlon(tm) XP 2600+ Timestamp of tree: Thu, 06 Mar 2008 11:46:01 +0000 app-shells/bash: 3.2_p33 dev-java/java-config: 1.3.7, 2.1.5 dev-lang/python: 2.5.1-r5 sys-apps/baselayout: 2.0.0 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.9.6-r2, 1.10.1 sys-devel/binutils: 2.18.50.0.3 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.24 ACCEPT_KEYWORDS="x86 ~x86" CBUILD="i686-pc-linux-gnu" CFLAGS="-O2 -march=native -pipe -fomit-frame-pointer -fno-ident" CHOST="i686-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/splash /etc/terminfo /etc/udev/rules.d" CXXFLAGS="-O2 -march=native -pipe -fomit-frame-pointer -fno-ident" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer parallel-fetch preserve-libs sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://gentoo.prz.rzeszow.pl http://src.gentoo.pl/" LANG="pl_PL.UTF-8" LC_ALL="pl_PL.UTF-8" LDFLAGS="-Wl,-O1 -Wl,--sort-common -Wl,--as-needed -Wl,--hash-style=gnu" LINGUAS="en pl" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage/layman/Eaedificata /usr/local/portage/layman/openrc /usr/local/portage/layman/dirtyepic /usr/local/portage/layman/mozilla /usr/local/portage/moje /usr/local/portage/mz /usr/local/portage/jmbsvicetto /usr/local/portage/kadu" SYNC="rsync://rsync.europe.gentoo.org/gentoo-portage" USE="3dnow 3dnowext X a52 aac acl alsa bash-completion berkdb cairo cdr cli cracklib crypt cups dbus dri dts dv dvb dvd dvdr dvdread encode fam ffmpeg firebird flac fortran gdbm gif gpm hal iconv ipv6 isdnlog jpeg kde kdehiddenvisibility ldap libsamplerate mad midi mikmod mmx mmxext mp2 mp3 mpeg mudflap multislot musepack ncurses newspr nls nptl nptlonly ogg openal opengl openmp pam pcre pdf perl png pppd python qt quicktime readline real reflection session spl sqlite3 sse ssl svg tcpd theora threads tiff truetype unicode vorbis wavpack win32codecs x264 x86 xml xorg xv xvid xvmc zlib" ALSA_CARDS="emu10k1" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="authn_core authz_core actions access_compat alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="en pl" USERLAND="GNU" VIDEO_CARDS="nvidia nv vesa" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Just a guess, but it might be related to this: http://gcc.gnu.org/ml/gcc/2008-03/msg00297.html
Something that might be worth noting -- only the following components can have impact on this segfault: - the kernel - klibc - v86d itself (and its bundled libs)
the problem is that even recompiling klibc, v86d and kernel with gcc-4.2 doesn't help.
(In reply to comment #1) > Just a guess, but it might be related to this: > http://gcc.gnu.org/ml/gcc/2008-03/msg00297.html > Well, actually it can be related to this in fact. Unfortunately I can't check it now because I restored backup with gcc-4.2.3 due to a few other problems with gcc-4.3.
Ich habe das gleiche Problem, allerdings mit dem gcc-4.1.2 v86d[909]: segfault at 0 rip 400e88 rsp 7fff07c71210 error 6 emerge --info Portage 2.1.4.4 (default-linux/amd64/2007.0, gcc-4.1.2, glibc-2.6.1-r0, 2.6.24-gentoo-r3 x86_64) ================================================================= System uname: 2.6.24-gentoo-r3 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ Timestamp of tree: Fri, 28 Mar 2008 08:00:01 +0000 app-shells/bash: 3.2_p17-r1 dev-java/java-config: 1.3.7, 2.1.4 dev-lang/python: 2.5.1-r5 sys-apps/baselayout: 1.12.11.1 sys-apps/sandbox: 1.2.18.1-r2 sys-devel/autoconf: 2.13, 2.61-r1 sys-devel/automake: 1.5, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2, 1.10 sys-devel/binutils: 2.18-r1 sys-devel/gcc-config: 1.4.0-r4 sys-devel/libtool: 1.5.26 virtual/os-headers: 2.6.23-r3 ACCEPT_KEYWORDS="amd64" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-march=athlon64 -O2 -pipe -msse3" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/share/config" CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/fonts/fonts.conf /etc/gconf /etc/php/apache2-php5/ext-active/ /etc/php/cgi-php5/ext-active/ /etc/php/cli-php5/ext-active/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c /etc/udev/rules.d" CXXFLAGS="-march=athlon64 -O2 -pipe -msse3" DISTDIR="/usr/portage/distfiles" FEATURES="distlocks metadata-transfer sandbox sfperms strict unmerge-orphans userfetch" GENTOO_MIRRORS="http://linux.rz.ruhr-uni-bochum.de/download/gentoo-mirror/ ftp://linux.rz.ruhr-uni-bochum.de/gentoo-mirror/ http://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.uni-erlangen.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo ftp://ftp.wh2.tu-dresden.de/pub/mirrors/gentoo ftp://ftp.join.uni-muenster.de/pub/linux/distributions/gentoo http://mirrors.sec.informatik.tu-darmstadt.de/gentoo/ http://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/gentoo/ ftp://ftp.gentoo.mesh-solutions.com/gentoo/ http://pandemonium.tiscali.de/pub/gentoo/ ftp://pandemonium.tiscali.de/pub/gentoo/ ftp://ftp.rz.tu-bs.de/pub/mirror/ftp.gentoo.org/gentoo-distfiles/ http://ftp.rz.tu-bs.de/pub/mirror/ftp.gentoo.org/gentoo/ http://gentoo.intergenia.de ftp://ftp.tu-clausthal.de/pub/linux/gentoo/ " LANG="de_DE@euro" LC_ALL="de_DE@euro" LINGUAS="de en_GB" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --stats --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/portage/local/layman/wschlich-testing /usr/portage/local/layman/portato" SYNC="rsync://rsync.gentoo.org/gentoo-portage" USE="3dnow 3dnowext 64bit 7zip X X509 Xaw3d a52 aac aalib accessibility acl acpi administrator aim aimextras alsa amd amd64 amr ao aoss apache apache2 apm arts artswrappersuid asf async atk automount avalon bash-completion bashlogger beagle berkdb binfilter bl bluetooth bzip2 cairo calendar capi caps cdda cddb cdparanoia cdr cdrom cgi chipcard chipcard2 chroot cli contentcache cracklib crosscompile crypt css cups custom-cflags dbus dbx deprecated dga directfb discouraged divx dmi dnd dri dts dv dvb dvd dvdr dvdread dvi dxr3 eds emul-linux-x86 encode escreen exif ext-iiimf extensions extraengine extrafilters fam fame fat fax faxonly fbdev fbsplash ffmpeg fftw firefox flac flash flatfile font-server fontconfig foomaticdb fortran freetype2 ftp fuse gdbm gdl gdm gecko-sdk geldkarte general geos gif gimp gimpprint glade gmedia gnokii gnome gphoto2 gpm grammar gs gstreamer gtk gtk2 gtkhtml gzip hal hbci high-ints highlight html http iconv icq id3 ieee1394 image imagemagick imap imlib innodb iodbc ipod ipppd ipsec ipv6 irda irmc isdn isdnlog java java5 javascript jbig jboss jingle jmx jpeg jpeg2k jpgraph jta kde kdepim kdm kerberos kipi lame latex ldap ldapsam libtommath libwww lirc live lm_sensors logitech-mouse lzo lzw mad math matrox mbrola midi mime mimencode mixer mjpeg mmx mng mod modplug moneyplex mono mozcalendar mozilla mozsvg mozxmlterm mp3 mp4 mp4live mpeg mpeg2 mplayer msn mudflap multiuser mysql mysqlfriends mysqli nas ncurses net network new-login nforce2 nfs nis nls nntp nptl nptlonly nsplugin ntfs ntlm ntlm_unsupported_patch ntp nvidia nvram odbc odk ofx ogg on-the-fly-crypt opengl openmp openssh openssl opensslcrypt osc oscache pam paste64 pccts pcre pda pdf perl php player png ppds pppd print ps python qt3 qt3support qt4 query-browser quicktime quotas rar rdesktop readline reflection regex reiser4 reiserfs replytolist resolvconf rle rsh rtc rtsp samba sametime scanner screen sdl sdl-sound sdlaudio seamonkey serial server session sftp shout slp smarty smp sms sndfile snmp sockets socks5 softfax sound sox speech speedo speex spell spl sse sse-filters sse2 ssl stream suid suidcheck svg svgz swat sysfs syslog szip taglib tagwriting tcl tcltk tcpd text texteffect tga theora thesaurus threads threadsonly thumbnail thunderbird tiff tk toolbar transcode truetype type1 unicode unzip usb userlocales v4l v4l2 vcd vdr vlm vnc vncviewer voodoo1 voodoo2 voodoo3 voodoo5 vorbis vorbis-psy wifi winbind withsamplescripts wma wmf wmp wordexp wordperfect workbench x11vnc x264 xbase xcomposite xerces-c xext xface xforms xfs xft xim xine xinerama xinetd xlockrc xml xmldoclet xmlreader xmlwriter xorg xosd xpm xprint xscreensaver xsettings xsl xslt xterm xv xvid xvmc xvnc yahoo zeroconf zip zlib zvbi" ALSA_CARDS="intel8x0" ALSA_PCM_PLUGINS="adpcm alaw asym copy dmix dshare dsnoop empty extplug file hooks iec958 ioplug ladspa lfloat linear meter mulaw multi null plug rate route share shm softvol" APACHE2_MODULES="actions alias auth_basic auth_digest authn_anon authn_dbd authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache dav dav_fs dav_lock dbd deflate dir disk_cache env expires ext_filter file_cache filter headers ident imagemap include info log_config logio mem_cache mime mime_magic negotiation proxy proxy_ajp proxy_balancer proxy_connect proxy_http rewrite setenvif so speling status unique_id userdir usertrack vhost_alias" ELIBC="glibc" INPUT_DEVICES="keyboard mouse evdev" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LINGUAS="de en_GB" USERLAND="GNU" VIDEO_CARDS="nvidia" Unset: CPPFLAGS, CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LDFLAGS, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
My v86d - version: sys-apps/v86d-0.1.3-r1
(In reply to comment #6) > My v86d - version: sys-apps/v86d-0.1.3-r1 > I have same problems problem only exist if klibc & v86d were compiled with gcc-4.3.0
I am affraid this is not a problem of gcc 4.3.0 as I have same (Or similar) problem with v86d on 4.2.3 system. v86d[303]: segfault at 0 rip 400e98 rsp 7fff6eafc0a0 error 6 uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 v86d version is 0.1.3-r1
Created attachment 150317 [details] emerge --info
Could you please try to upgrade to v86d-0.1.4 and rebuild your kernel/initramfs (so that the new version is included in the initramfs image)? If the upgrade doesn't change anything for you, please emerge v86d with the 'debug' USE flag and post the results of running `testvbe`.
I have installed v86d-0.1.4 with gcc-4.3.0 I still have got SIGSEGV v86d[932]: segfault at fffffffe eip 08049bae esp bff2bd10 error 6 Switched to high resolution mode on CPU 0 uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 thinkpad ~ # testvbe <7>task flags: 0x01 <7>EAX=00004f00 EBX=00000000 ECX=00000000 EDX=00000000 <7>ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 Segmentation fault
No segfault with v86d 0.1.4 here, but it still fails with: uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 testvbe seems to be fine here: VBE Version: 3.00 OEM String: NVIDIA OEM Vendor Name: Build 060809.4 OEM Prod. Name: MCP61 - mcp61-80 OEM Prod. Rev: Chip Rev ID attr mode --------------------------- 0100 039f 640x400-8 0101 039f 640x480-8 0102 031f 800x600-4 0103 039f 800x600-8 0104 031f 1024x768-4 0105 039f 1024x768-8 0106 031f 1280x1024-4 0107 039f 1280x1024-8 010e 039f 320x200-16 010f 039f 320x200-32 0111 039f 640x480-16 0112 039f 640x480-32 0114 039f 800x600-16 0115 039f 800x600-32 0117 039f 1024x768-16 0118 039f 1024x768-32 011a 039f 1280x1024-16 011b 039f 1280x1024-32 0130 039f 320x200-8 0131 039f 320x400-8 0132 039f 320x400-16 0133 039f 320x400-32 0134 039f 320x240-8 0135 039f 320x240-16 0136 039f 320x240-32 013d 039f 640x400-16 013e 039f 640x400-32 0145 039f 1600x1200-8 0146 039f 1600x1200-16 0147 039f 1400x1050-8 0148 039f 1400x1050-16 0152 03db 2048x1536-32
(In reply to comment #12) > No segfault with v86d 0.1.4 here, but it still fails with: > > uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) > uvesafb: vbe_init() failed with -22 > uvesafb: probe of uvesafb.0 failed with error -22 Are you using an external initramfs? If so, are you sure it contains a working copy of v86d? Also, you might want to try building uvesafb as a module to see whether it works this way.
I added v86d by hand to my initrd as genkernel does not support it ;( Same version as on /sbin/ on my system.
The same problem here, with gcc-4.2.3. I recompiled many times all critical components: v86d, klibc, splashutils. I have uvesafb compiled into the kernel (not module); kernel 2.6.24-gentoo-r4, v86d-0.1.3-r1, klibc-1.5.8. The kernel is x86_64. Always the same situation - segfault of v86d during the startup: (from dmesg): v86d[903]: segfault at 0 rip 400ff8 rsp 7fffb26ecc90 error 6 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 (testvbe): VBE Version: 3.00 OEM String: NVIDIA OEM Vendor Name: NVIDIA Corporation OEM Prod. Name: G86 Board - p403h20 OEM Prod. Rev: Chip Rev ID attr mode --------------------------- 0100 03bf 640x400-8 0101 03bf 640x480-8 0102 033f 800x600-4 0103 03bf 800x600-8 0104 033f 1024x768-4 0105 03bf 1024x768-8 0106 033f 1280x1024-4 0107 03bf 1280x1024-8 010e 03bf 320x200-16 010f 03bf 320x200-32 0111 03bf 640x480-16 0112 03bf 640x480-32 0114 03bf 800x600-16 0115 03bf 800x600-32 0117 03bf 1024x768-16 0118 03bf 1024x768-32 011a 03bf 1280x1024-16 011b 03bf 1280x1024-32 0130 03bf 320x200-8 0131 03bf 320x400-8 0132 03bf 320x400-16 0133 03bf 320x400-32 0134 03bf 320x240-8 0135 03bf 320x240-16 0136 03bf 320x240-32 013d 03bf 640x400-16 013e 03bf 640x400-32 0145 03bf 1600x1200-8 0146 03bf 1600x1200-16 014a 03bf 1600x1200-32 0160 03bf 1280x800-8 0161 03bf 1280x800-32 0162 03bf 768x480-8 017c 03bf 1920x1200-8 017d 03bf 1920x1200-32
Ok, for everyone for whom v86d segfaults when started from the kernel but testvbe works: could you please try building uvesafb a module and loading it manually after boot? If that works and you're using a proprietriary X11 driver, try to load uvesafb before the X11 driver kernel module is loaded. Does that change anything?
ok., the additional info: - uvesafb works, if and only if it is compiled as module. The order of the proprietary nvidia module and uvesafb does not play a role. At least for me, uvesafb might be loaded befeore or after nvidia. The modul uvesafb.ko has been loaded via standard mechanism (the appropriate row in /etc/modules.autoload.d). - as built-in part of the kernel uvesafb does not work, it produces the same segfault of v86d. The rest of the kernel config was identical. To have uvesafb working properly, I have to fully specify the exact mode, i.e. with mode=1920x1200-32@77 it works. Any of shorter forms (mode=1920x1200, or mode=1920x1200-32) does not work, the screen stays in the default text mode. Even as module, the funcionality of uvesafb is not perfect in the comparison with vesafb, the progress indicator at the splash screen goes only up to 33%, not more (for vesafb up to 85%), then X starts. During the shutdown I noted a few times hard-locking of the system (again at circa 33%), complete disconnection of the keyboard. Only one way was the reset button, even SysReq did not act as expected. This has happened approx. every 2nd-3rd reboot.
For me it is dark screen and that was it (afer modprobe uvesafb). No keyboard or mouse. I will also no longer on X11. Even a reboot via the network no longer works.
I don't think this is related to gcc-4.2 or 4.3, necessarily. I'm using gcc-4.1.2 here, and attempted to upgrade to gentoo-sources-2.6.25-r1. v86d segfault followed. Rebuilt, and then rebuilt and upgraded klibc and v86d (0.1.4). No luck. Attempted as module; also no luck.
... important, and I forget to mention, I'm getting the same v86d segfault, as others have reported here.
(In reply to comment #19) > I don't think this is related to gcc-4.2 or 4.3, necessarily. I have the same opinion: - I rebuilt everything (kernel, klibc, v86d, splashutils) with gcc-4.1.2, with the previous configuration of the kernel: no change. As module uvesafb works for me (the same conditions as above), as part of the kernel it just produces segfault. Perhaps is this problem hw dependent ?
(In reply to comment #17) > Even as module, the funcionality of uvesafb is not perfect in the comparison > with vesafb, the progress indicator at the splash screen goes only up to 33%, > not more (for vesafb up to 85%), then X starts. During the shutdown I noted a > few times hard-locking of the system (again at circa 33%), complete > disconnection of the keyboard. Only one way was the reset button, even SysReq > did not act as expected. This has happened approx. every 2nd-3rd reboot. > I'm experiencing the same problem. Kernel doesn't matter.
(In reply to comment #22) > (In reply to comment #17) > > Even as module, the funcionality of uvesafb is not perfect in the comparison > > with vesafb, the progress indicator at the splash screen goes only up to 33%, > > not more (for vesafb up to 85%), then X starts. During the shutdown I noted a > > few times hard-locking of the system (again at circa 33%), complete > > disconnection of the keyboard. Only one way was the reset button, even SysReq > > did not act as expected. This has happened approx. every 2nd-3rd reboot. > > > I'm experiencing the same problem. Kernel doesn't matter. I don't see how the progress indicator or the splash screen in general is related to a particular fb driver that you use (sounds more like a problem with splashutils or baselayout). Are you sure the hard locking is a side effect of uvesafb? Is it completely gone when you use vesafb instead? What kind of X driver do you? Is your problem affected in any way if you switch the driver (proprietary one <-> open source one, assuming both are available)?
(In reply to comment #23) > > I don't see how the progress indicator or the splash screen in general is > related to a particular fb driver that you use (sounds more like a problem with > splashutils or baselayout). > > Are you sure the hard locking is a side effect of uvesafb? Is it completely > gone when you use vesafb instead? What kind of X driver do you? Is your > problem affected in any way if you switch the driver (proprietary one <-> open > source one, assuming both are available)? > Very strange for me, too. But my system is rock-stable without uvesafb (using just vesafb), no hard locks, no troubles at the start-up or shutdown or reboot. No changes in splashutils or baselayout during tests of uvesafb vs. vesafb, so these should not be the reason. I am using proprietary nvidia X-driver (unfortunately 'nv' does not work with my 8500), but I tried to use vesa-driver during the tests. The same results - vesafb works without problems, uvesafb does the funny things.It does not look like X related. Because of this, I am thinking about some hw (video-card) based conflict between the video card and uvesafb. But my video card is quite standard one (XFX GeForce8500), and I did not experienced some thermal problems (GPU temperature is not above 60 degC, CPU0/1 temperatures not above 50 degC), my PC is not overclocked, it passed memtest86/memtest86+ for up to 5 days without any single error.
(In reply to comment #23) > (In reply to comment #22) > > (In reply to comment #17) > > > > Even as module, the funcionality of uvesafb is not perfect in the comparison > > > with vesafb, the progress indicator at the splash screen goes only up to 33%, > > > not more (for vesafb up to 85%), then X starts. During the shutdown I noted a > > > few times hard-locking of the system (again at circa 33%), complete > > > disconnection of the keyboard. Only one way was the reset button, even SysReq > > > did not act as expected. This has happened approx. every 2nd-3rd reboot. > > > > > I'm experiencing the same problem. Kernel doesn't matter. > > I don't see how the progress indicator or the splash screen in general is > related to a particular fb driver that you use (sounds more like a problem with > splashutils or baselayout). > > Are you sure the hard locking is a side effect of uvesafb? Is it completely > gone when you use vesafb instead? What kind of X driver do you? Is your > problem affected in any way if you switch the driver (proprietary one <-> open > source one, assuming both are available)? > My graphic card on my laptop is GeForce 8600GT. I had it working perfectly fine with 2.6.24-gentoo-r5, baselayout2 and openrc-9999 (from Roy's repo). Since that time I migrated to gcc-4.3.0 and 2.6.24-gentoo-r6 and start experiencing hard locks during the shutdown. No problems when I removed uvesafb. Later on, I've migrated to 2.6.25-gentoo-r1 (still with gcc-4.3.0) and now I've got 86d[358]: segfault at fffffffe eip 08049345 esp bfbd11e0 error 6 uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 every time I boot. I have another machine running 2.6.25-r1 with gcc-4.2.3 and nVidia Quadro and I've got: uvesafb: NVIDIA Corporation, nv44 Board - q383-0 , Chip Rev , OEM: NVIDIA, VBE v3.0 uvesafb: VBIOS/hardware supports DDC2 transfers uvesafb: monitor limits: vf = 75 Hz, hf = 81 kHz, clk = 140 MHz uvesafb: scrolling: redraw so I presume it might be gcc-4.3.0 related after all. I'm just compiling gcc 4.3.0 on yet another laptop and will test it with 2.6.25 and uvesafb.
Just to add my 2c. I'm using ati-drivers, gcc 4.3.0 (without the patch reverting cld change), kernel 2.6.24-r4, v86d 0.1.4. uvesafb works fine, though I haven't rebuilt klibc. World wasn't rebuilt with gcc 4.3.0, but kernel, v86d and ati-drivers were. uvesafb is built-in.
(In reply to comment #25) > so I presume it might be gcc-4.3.0 related after all. > I'm just compiling gcc 4.3.0 on yet another laptop and will test it with 2.6.25 > and uvesafb. > sorry for the delay, I've done fresh install with 2.6.25-r1 and gcc-4.3.0 on Laptop with Quadro FX360 Works like a charm. No segfault :S
(In reply to comment #27) > I've done fresh install with 2.6.25-r1 and gcc-4.3.0 on Laptop with Quadro > FX360 > Works like a charm. No segfault :S > Did you notice that lately a (temporary) patch has been added to gcc 4.3.0 reverting cld change (check gcc ChangeLog) ? Did you rebuilt gcc with this patch or not, cause this may invalidate your result ?
(In reply to comment #28) > (In reply to comment #27) > > I've done fresh install with 2.6.25-r1 and gcc-4.3.0 on Laptop with Quadro > > FX360 > > Works like a charm. No segfault :S > > > Did you notice that lately a (temporary) patch has been added to gcc 4.3.0 > reverting cld change (check gcc ChangeLog) ? Did you rebuilt gcc with this > patch or not, cause this may invalidate your result ? > yaay I haven't seen that! Vapier didn't bump the revision. I will check it out and let you know about the results. Cheers,
I'm using v86d, too. For me, it doesn't crash if compiled with USE=x86emu. If I don't use x86emu, it segfaults, too.
I can confirm v86d works when compiled with x86emu use flag. I tried with gcc 3.4.6 (kernel + v86d + klibc) and with 4.3.0.
Ok, I recompiled world with gcc-4.3.1, recompiled kernel, rebooted and... uvesafb didn't work. Then I recompiled v86d with USE=x86emu, kernel, reboot and it works. Pretty strange.
One thing more. v86d compiled with USE="debug": - v86d segfaults - testvbe segfaults v86d compiled with USE="x86emu debug": - v86d works - testvbe works
Created attachment 156501 [details] my emerge --info
OK, I'm starting to get lost here ;) Could everyone for whom v86d works when compiled with x86emu move to bug #226107? Also, could everyone please compile v86d with the 'debug' USE flag and provide the output of testvbe, along with the PCI ID of the graphic card? (please do that in the new bug, or here if you're not moving). To get the PCI ID: run lspci, look for 'VGA compatible controller', note its PCI address (e.g. 01:00.0), run lspci -n and get the PCI ID.
In my case if v86d is compiled with gcc 4.1.2 - work fine. World and kernel is compiled with gcc-4.3.1.
testvbe as you asked, world compiled with gcc 4.3.1, glibc 2.8, uvesafb builtin kernel andhighest versions of v86d, klibc, gentoo-sources respectively, but uvesafb not working!! testvbe VBE Version: 3.00 OEM String: NVIDIA OEM Vendor Name: NVIDIA Corporation OEM Prod. Name: G71 Board - p492h2 OEM Prod. Rev: Chip Rev ID attr mode --------------------------- 0100 039f 640x400-8 0101 039f 640x480-8 0102 031f 800x600-4 0103 039f 800x600-8 0104 031f 1024x768-4 0105 039f 1024x768-8 0106 031f 1280x1024-4 0107 039f 1280x1024-8 010e 039f 320x200-16 010f 039f 320x200-32 0111 039f 640x480-16 0112 039f 640x480-32 0114 039f 800x600-16 0115 039f 800x600-32 0117 039f 1024x768-16 0118 039f 1024x768-32 011a 039f 1280x1024-16 011b 039f 1280x1024-32 0130 039f 320x200-8 0131 039f 320x400-8 0132 039f 320x400-16 0133 039f 320x400-32 0134 039f 320x240-8 0135 039f 320x240-16 0136 039f 320x240-32 013d 039f 640x400-16 013e 039f 640x400-32 0145 039f 1600x1200-8 0146 039f 1600x1200-16 0147 039f 1400x1050-8 0148 039f 1400x1050-16 0152 03db 2048x1536-32
lspci as requested lspci 00:00.0 Host bridge: nVidia Corporation nForce2 AGP (different version?) (rev c1) 00:00.1 RAM memory: nVidia Corporation nForce2 Memory Controller 1 (rev c1) 00:00.2 RAM memory: nVidia Corporation nForce2 Memory Controller 4 (rev c1) 00:00.3 RAM memory: nVidia Corporation nForce2 Memory Controller 3 (rev c1) 00:00.4 RAM memory: nVidia Corporation nForce2 Memory Controller 2 (rev c1) 00:00.5 RAM memory: nVidia Corporation nForce2 Memory Controller 5 (rev c1) 00:01.0 ISA bridge: nVidia Corporation MCP2A ISA bridge (rev a3) 00:01.1 SMBus: nVidia Corporation MCP2A SMBus (rev a1) 00:02.0 USB Controller: nVidia Corporation MCP2A USB Controller (rev a1) 00:02.1 USB Controller: nVidia Corporation MCP2A USB Controller (rev a1) 00:02.2 USB Controller: nVidia Corporation MCP2A USB Controller (rev a2) 00:06.0 Multimedia audio controller: nVidia Corporation MCP2S AC'97 Audio Controller (rev a1) 00:08.0 PCI bridge: nVidia Corporation MCP2A PCI Bridge (rev a3) 00:09.0 IDE interface: nVidia Corporation MCP2A IDE (rev a3) 00:0b.0 IDE interface: nVidia Corporation nForce2 Serial ATA Controller (rev a3) 00:1e.0 PCI bridge: nVidia Corporation nForce2 AGP (rev c1) 01:00.0 VGA compatible controller: nVidia Corporation G70 [GeForce 7800 GS] (rev a2) 02:0b.0 Ethernet controller: VIA Technologies, Inc. VT6120/VT6121/VT6122 Gigabit Ethernet Adapter (rev 11)
I have just re-emerged my gcc and re-emerged v86d and let genkernel redo my initramfs and still no go, still v86d segfaults on startup. I am now redoing my kernel with uvesafb as a module with this command in /etc/conf.d/modules module_uvesafb_args="mode=1024x768-32 mtrr=3 scroll=ywrap" I will report tommorrow
Okay, does work but its unusable. Okay, as a module it does indeed load, autoload works but it comes far too late in the boot process and ultimately when the uvesafb module does get loaded it gives me a blank screen until gdm starts. On shutting down the splash works correctly except again it does not respect the arguments and is clearly not the correct resolution. For my purposes which really are just for fbsplash I don't need it as the regular vesa FB does fine. It seems to me that to use uvesafb with the gensplash you must have it built in to give you an early splash. I am going to again compile my kernel with uvesafb built in tomorrow but will use the regular vesafb until this gets fixed and if there is anything I can do to help you figure this out Spock, please let me know.
Problem has somehow disappeared with newest 2.6.25-r5 gentoo sources
I'm using gentoo-sources-2.6.25-r5, gcc-4.3.1, uvesafb as a module, and v86d compiled with debug and x86emu. testvbe still segfaults, though, and I get this in dmesg and /var/log/messages: task flags: 0x01 EAX=00004f00 EBX=00000000 ECX=00000000 EDX=00000000 ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 Trying to access an unsupported memory region at 5300 testvbe[6911]: segfault at 0 ip 08049198 sp bfaa1350 error 4 in testvbe[8048000+17000] When I load uvesafb: v86d: task flags: 0x01 v86d: EAX=00004f00 EBX=00000000 ECX=00000000 EDX=00000000 v86d: ESP=00000000 EBP=00000000 ESI=00000000 EDI=00000000 v86d: Trying to access an unsupported memory region at ce0b v86d[7122]: segfault at 0 ip 08049238 sp bfca0a80 error 4 in v86d[8048000+17000] uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 Appears in dmesg.
segaults with: sys-kernel/gentoo-sources-2.6.25-r5 sys-devel/gcc-4.3.1 USE="fortran mudflap nls openmp (-altivec) -bootstrap -build -doc -gcj -gtk (-hardened) -ip28 -ip32r10k -libffi (-multilib) -multislot (-n32) (-n64) -nocxx -objc -objc++ -objc-gc -test -vanilla" sys-apps/v86d-0.1.5 x11-drivers/nvidia-drivers-173.14.09 lspci: 02:00.0 VGA compatible controller: nVidia Corporation Device 0422 (rev a1) (prog-if 00 [VGA controller]) Subsystem: PC Partner Limited Device 8420 Flags: bus master, fast devsel, latency 0, IRQ 24 Memory at dc000000 (32-bit, non-prefetchable) [size=16M] Memory at c0000000 (64-bit, prefetchable) [size=256M] Memory at da000000 (64-bit, non-prefetchable) [size=32M] I/O ports at bc00 [size=128] [virtual] Expansion ROM at dd000000 [disabled] [size=128K] Capabilities: [60] Power Management version 2 Capabilities: [68] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable- Capabilities: [78] Express Endpoint, MSI 00 Capabilities: [100] Virtual Channel <?> Capabilities: [128] Power Budgeting <?> Capabilities: [600] Vendor Specific Information <?> Kernel driver in use: nvidia Kernel modules: nvidia
Not sure if this is related, but when I turned on my computer today, CPU usage was at 100%, and the offender was /sbin/v86d.
For all who have problem with segfaulting v86d: try to compile it with -O0 and see if that helps.
I have the same problem. Compiling with -O0 WORKS: (I created a file: /etc/portage/env/sys-apps/v86d containing CFLAGS="-march=i686 -O0" and CXXFLAGS="-march=i686 -O0") I previously tried USE=x86emu, which didn't help. My default flags are "-march=prescott -O2 -pipe -ftracer -fomit-frame-pointer -ftree-vectorize" I have GCC 4.3.1, and kernel 2.6.25-gentoo-r5. My processor is a Core2 Duo T9500 My graphic card is: 03:00.0 VGA compatible controller: nVidia Corporation Device 0409 (rev a1) # lspci -n | grep 03:00.0 03:00.0 0300: 10de:0409 (rev a1) testvbe output: VBE Version: 3.00 OEM String: NVIDIA OEM Vendor Name: NVIDIA Corporation OEM Prod. Name: G84 Board - siberia0 OEM Prod. Rev: Chip Rev ID attr mode --------------------------- 0100 03bf 640x400-8 0101 03bf 640x480-8 0102 033f 800x600-4 0103 03bf 800x600-8 0104 033f 1024x768-4 0105 03bf 1024x768-8 0106 033f 1280x1024-4 0107 03bf 1280x1024-8 010e 03bf 320x200-16 010f 03bf 320x200-32 0111 03bf 640x480-16 0112 03bf 640x480-32 0114 03bf 800x600-16 0115 03bf 800x600-32 0117 03bf 1024x768-16 0118 03bf 1024x768-32 011a 03bf 1280x1024-16 011b 03bf 1280x1024-32 0130 03bf 320x200-8 0131 03bf 320x400-8 0132 03bf 320x400-16 0133 03bf 320x400-32 0134 03bf 320x240-8 0135 03bf 320x240-16 0136 03bf 320x240-32 013d 03bf 640x400-16 013e 03bf 640x400-32 0145 03bf 1600x1200-8 0146 03bf 1600x1200-16 014a 03bf 1600x1200-32 0160 03bf 1280x800-8 0161 03bf 1280x800-32 0162 03bf 768x480-8 017c 03bf 1920x1200-8 017d 03bf 1920x1200-32
Still segfault. I uninstalled v86d and installed the new gentoo-sources (-r6) without v86d. After installing nvidia-drivers, reboot I follow the instructions on spock's website step by step -> segfault. Changing the USE flags to debug x86emu and the CFLAGS to -O0 does't help.
Using CFLAGS -O0, my testvbe stoped giving segfaults, v86d still does though.
I just compiled my 2.6.26-r6 kernel without the "Preemptible RCU" option. v86d stoped to give segfaults. And seems to work normaly now.
Created attachment 159848 [details, diff] klibc-1.5.11-klibcmemmove.patch As mentioned here: https://bugs.gentoo.org/show_bug.cgi?id=226107 The problem appears to be in klibc in memmove.c. Since I'm not an assembly guru, I've created a patch that simply falls back to the C implementation rather than the assembly implementation used for x86. This fixes the segfault for me with CFLAG optimizations set to "-O2".
Created attachment 159850 [details] klibc-1.5.11.ebuild ...and an updated klibc ebuild with the temporary memmove patch/workaround
The above patch corrected segfault for me (on 2 laptops - both nvidia G84 and G86), but still cant get splashscreen. During the boot it keeps the default resolution and later it reports the following error: * Failed to start the splash daemon, error code 256 Kernel command line: root=/dev/sda3 video=uvesafb:1650x1050-32,mtrr:3,ywrap quiet splash=verbose,theme:livecd-2007.0 fbcon=scrollback:128K CONSOLE=/dev/tty1 uvesafb: NVIDIA Corporation, G86 Board - filag0 , Chip Rev , OEM: NVIDIA, VBE v3.0 uvesafb: VBIOS/hardware doesn't support DDC transfers uvesafb: no monitor limits have been set, default refresh rate will be used uvesafb: scrolling: redraw uvesafb: framebuffer at 0xfb000000, mapped to 0xffffc20004100000, using 13781k, total 14336k fb0: VESA VGA frame buffer device
I have same error, it doesn't help for me. Tried to use patch, to patch manually sources, compile against glibc, whatever - nothing. Same error, just addresses changing. Probably issue in v86d?
(In reply to comment #52) > * Failed to start the splash daemon, error code 256 Please keep any splash-related issues out of this bug. For everyone else, could you please upgrade to klibc-1.5.12-r1 and v86d-0.1.5.1 and see whether this fixes the problem?
(In reply to comment #54) > For everyone else, could you please upgrade to klibc-1.5.12-r1 and v86d-0.1.5.1 > and see whether this fixes the problem? Here it doesn't: v86d[324]: segfault at c2506 ip 00002506 sp 00000ffa error 15 in zero[10000+40000] Switched to high resolution mode on CPU 0 uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 Haven't tried x86emu flag yet but I take it that was different issue and fixed already?
Comment on attachment 159848 [details, diff] klibc-1.5.11-klibcmemmove.patch Fixed by klibc-1.5.12-r1
Comment on attachment 159850 [details] klibc-1.5.11.ebuild Fixed by klibc-1.5.12-r1
(In reply to comment #54) > For everyone else, could you please upgrade to klibc-1.5.12-r1 and v86d-0.1.5.1 > and see whether this fixes the problem? > Fixed the segfault for me. Deprecating previous workaround patch and ebuild.
(In reply to comment #54) > For everyone else, could you please upgrade to klibc-1.5.12-r1 and v86d-0.1.5.1 > and see whether this fixes the problem? > I've tried it with klibc-1.5.12-r1 and v86d-0.1.5.2, but it still dosen't work for me v86d[329]: segfault at fffffffe ip 080492ff sp bffa1d90 error 6 in v86d[8048000+4000] Switched to high resolution mode on CPU 1 Switched to high resolution mode on CPU 0 uvesafb: Getting VBE info block failed (eax=0x4f00, err=1) uvesafb: vbe_init() failed with -22 uvesafb: probe of uvesafb.0 failed with error -22 I also haven't tried the "x86emu" flag
OK, I'm going to close the bug as I believe that the underlying problem has been fixed by the recent update of klibc. I realize that there are still people for whom uvesafb/v86d doesn't work. Right now, I see two possible problems and would ask you do as follows, depending on which one matches what you are experiencing with your configuration: - v86d works with x86emu, but doesn't with lrmi (-x86emu); (it is important to try it with x86emu!); it's very possible that you're suffering from the same bug as the one discussed on http://lkml.org/lkml/2008/7/10/526. Please switch to bug #226107 and see the instructions there. - v86d doesn't work regardless of whether x86emu or lrmi is used. Please move to bug #196848. + v86d works with an older version of gcc, but fails with the current one. In this case, please stay with this bug and reopen it if necessary. Thanks for your cooperation here. I'm sorry about the constant moving and splitting, but these are complex issues and it's difficult for me to track them and see common patterns unless the reports are properly organized and categorized.
Ok, I don't know why, but actually it works. I have no idea what the reason was, maybe because the ati-drivers were wrong installed (no "emerge ati-drivers" after kernel update). Now it works whitout the "x86emu" flag. :)
