212531 2008-03-06 21:11 0000 sys-apps/v86d segfaults at start if system is compiled with gcc-4.3 2008-07-27 09:17:02 0000 1 1 1 Unclassified Gentoo Linux Applications unspecified x86 Linux RESOLVED FIXED P2 normal --- 198121 1 electricityispower@gmail.com spock@gentoo.org alexxy@gentoo.org arfrever@gentoo.org armando@goodship.net caster@gentoo.org dagger@gentoo.org esigra@gmail.com even.more.spam.for.me@googlemail.com hyperquantum@gmail.com info@chrisheitkamp.de it-knodel@gmx.net miki3@gmx.net morgoth6@gmail.com mpagano@gentoo.org n-roeser@gmx.net perttu.luukko@iki.fi portage@bigmichi1.dyndns.org reini@crimer.de rotech@orcon.net.nz samvimes@fastmail.fm simon@highlyillogical.org srrijkers@gmail.com tai@ja-ta.dyndns.org the_unknown@gmx.net Thomas.Rausch@gmx.de titefleur@gentoo.org victor.ashirov@gmail.com electricityispower@gmail.com 2008-03-06 21:11:52 0000 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 hyperquantum@gmail.com 2008-03-07 14:27:58 0000 Just a guess, but it might be related to this: http://gcc.gnu.org/ml/gcc/2008-03/msg00297.html spock@gentoo.org 2008-03-07 16:16:00 0000 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) electricityispower@gmail.com 2008-03-10 15:50:36 0000 the problem is that even recompiling klibc, v86d and kernel with gcc-4.2 doesn't help. electricityispower@gmail.com 2008-03-10 23:34:08 0000 (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. Thomas.Rausch@gmx.de 2008-03-28 10:23:08 0000 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 Thomas.Rausch@gmx.de 2008-03-28 11:37:56 0000 My v86d - version: sys-apps/v86d-0.1.3-r1 alexxy@gentoo.org 2008-04-12 20:20:51 0000 (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 morgoth6@gmail.com 2008-04-19 19:31:42 0000 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 morgoth6@gmail.com 2008-04-19 19:32:00 0000 Created an attachment (id=150317) emerge --info spock@gentoo.org 2008-04-20 07:37:22 0000 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`. alexxy@gentoo.org 2008-04-20 09:43:12 0000 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 morgoth6@gmail.com 2008-04-20 11:10:20 0000 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 spock@gentoo.org 2008-04-20 11:50:18 0000 (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. morgoth6@gmail.com 2008-04-20 12:48:49 0000 I added v86d by hand to my initrd as genkernel does not support it ;( Same version as on /sbin/ on my system. tai@ja-ta.dyndns.org 2008-04-20 20:01:49 0000 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 spock@gentoo.org 2008-04-21 08:23:05 0000 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? tai@ja-ta.dyndns.org 2008-04-21 21:42:20 0000 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. Thomas.Rausch@gmx.de 2008-04-22 06:23:22 0000 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. armando@goodship.net 2008-04-23 16:22:13 0000 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. armando@goodship.net 2008-04-23 16:23:30 0000 ... important, and I forget to mention, I'm getting the same v86d segfault, as others have reported here. tai@ja-ta.dyndns.org 2008-04-23 16:35:57 0000 (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 ? dagger@gentoo.org 2008-04-30 15:43:52 0000 (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. spock@gentoo.org 2008-05-01 08:32:49 0000 (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)? tai@ja-ta.dyndns.org 2008-05-01 09:09:16 0000 (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. dagger@gentoo.org 2008-05-01 13:10:25 0000 (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. galtgendo@o2.pl 2008-05-02 15:06:14 0000 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. dagger@gentoo.org 2008-05-02 15:42:04 0000 (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 galtgendo@o2.pl 2008-05-02 17:16:57 0000 (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 ? dagger@gentoo.org 2008-05-02 17:25:52 0000 (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, info@chrisheitkamp.de 2008-05-21 09:16:19 0000 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. shirk87@gmail.com 2008-05-21 12:06:23 0000 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. electricityispower@gmail.com 2008-06-11 14:32:59 0000 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. electricityispower@gmail.com 2008-06-12 14:24:52 0000 One thing more. v86d compiled with USE="debug": - v86d segfaults - testvbe segfaults v86d compiled with USE="x86emu debug": - v86d works - testvbe works electricityispower@gmail.com 2008-06-12 14:25:19 0000 Created an attachment (id=156501) my emerge --info spock@gentoo.org 2008-06-12 19:14:25 0000 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. iserg@comtv.ru 2008-06-15 22:17:15 0000 In my case if v86d is compiled with gcc 4.1.2 - work fine. World and kernel is compiled with gcc-4.3.1. billydv1@verizon.net 2008-06-16 23:29:35 0000 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 billydv1@verizon.net 2008-06-17 03:15:30 0000 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) billydv1@verizon.net 2008-06-17 03:33:13 0000 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 billydv1@verizon.net 2008-06-17 04:41:02 0000 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. billydv1@verizon.net 2008-06-20 02:27:48 0000 Problem has somehow disappeared with newest 2.6.25-r5 gentoo sources 2010dli@tjhsst.edu 2008-06-27 04:42:30 0000 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. it-knodel@gmx.net 2008-06-27 08:43:32 0000 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 2010dli@tjhsst.edu 2008-06-27 22:44:05 0000 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. electricityispower@gmail.com 2008-07-01 14:04:12 0000 For all who have problem with segfaulting v86d: try to compile it with -O0 and see if that helps. simon@highlyillogical.org 2008-07-02 12:55:23 0000 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 it-knodel@gmx.net 2008-07-02 22:40:49 0000 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. reini@crimer.de 2008-07-02 23:29:37 0000 Using CFLAGS -O0, my testvbe stoped giving segfaults, v86d still does though. reini@crimer.de 2008-07-03 14:59:15 0000 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. bmerrill@broadweave.net 2008-07-08 00:14:27 0000 Created an attachment (id=159848) 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". bmerrill@broadweave.net 2008-07-08 00:18:48 0000 Created an attachment (id=159850) klibc-1.5.11.ebuild ...and an updated klibc ebuild with the temporary memmove patch/workaround dagger@gentoo.org 2008-07-09 11:43:25 0000 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 nuclearcat@nuclearcat.com 2008-07-12 23:45:13 0000 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? spock@gentoo.org 2008-07-16 19:50:35 0000 (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? caster@gentoo.org 2008-07-17 08:56:36 0000 (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? bmerrill@broadweave.net 2008-07-18 00:15:09 0000 (From update of attachment 159848) Fixed by klibc-1.5.12-r1 bmerrill@broadweave.net 2008-07-18 00:15:33 0000 (From update of attachment 159850) Fixed by klibc-1.5.12-r1 bmerrill@broadweave.net 2008-07-18 00:16:42 0000 (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. miki3@gmx.net 2008-07-18 13:29:38 0000 (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 spock@gentoo.org 2008-07-24 21:34:48 0000 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. miki3@gmx.net 2008-07-27 09:17:02 0000 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. :) 150317 2008-04-19 19:32 0000 emerge --info emerge-info.txt text/plain UG9ydGFnZSAyLjEuNV9yYzQgKGRlZmF1bHQtbGludXgvYW1kNjQvMjAwNy4wL2Rlc2t0b3AsIGdj Yy00LjIuMywgZ2xpYmMtMi43LXIyLCAyLjYuMjQuNSB4ODZfNjQpCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09ClN5c3RlbSB1 bmFtZTogMi42LjI0LjUgeDg2XzY0IEFNRCBBdGhsb24odG0pIDY0IFgyIER1YWwgQ29yZSBQcm9j ZXNzb3IgNDAwMCsKVGltZXN0YW1wIG9mIHRyZWU6IEZyaSwgMTggQXByIDIwMDggMjA6MDA6MDEg KzAwMDAKY2NhY2hlIHZlcnNpb24gMi40IFtlbmFibGVkXQphcHAtc2hlbGxzL2Jhc2g6ICAgICAz LjJfcDMzCmRldi1qYXZhL2phdmEtY29uZmlnOiAxLjMuNywgMi4xLjUKZGV2LWxhbmcvcHl0aG9u OiAgICAgMi41LjIKZGV2LXB5dGhvbi9weWNyeXB0bzogMi4wLjEtcjYKZGV2LXV0aWwvY2NhY2hl OiAgICAgMi40LXI3CnN5cy1hcHBzL2Jhc2VsYXlvdXQ6IDIuMC4wCnN5cy1hcHBzL29wZW5yYzog ICAgIDAuMi4yCnN5cy1hcHBzL3NhbmRib3g6ICAgIDEuMi4xOC4xLXIyCnN5cy1kZXZlbC9hdXRv Y29uZjogIDIuMTMsIDIuNjIKc3lzLWRldmVsL2F1dG9tYWtlOiAgMS40X3A2LCAxLjUsIDEuNy45 LXIxLCAxLjguNS1yMywgMS45LjYtcjIsIDEuMTAuMQpzeXMtZGV2ZWwvYmludXRpbHM6ICAyLjE4 LXIxCnN5cy1kZXZlbC9nY2MtY29uZmlnOiAxLjQuMC1yNApzeXMtZGV2ZWwvbGlidG9vbDogICAx LjUuMjYKdmlydHVhbC9vcy1oZWFkZXJzOiAgMi42LjI0CkFDQ0VQVF9LRVlXT1JEUz0iYW1kNjQg fmFtZDY0IgpDQlVJTEQ9Ing4Nl82NC1wYy1saW51eC1nbnUiCkNGTEFHUz0iLW1hcmNoPWF0aGxv bjY0IC1PMiAtcGlwZSAtbXNzZTMiCkNIT1NUPSJ4ODZfNjQtcGMtbGludXgtZ251IgpDT05GSUdf UFJPVEVDVD0iL2V0YyAvdXNyL2tkZS8zLjUvZW52IC91c3Iva2RlLzMuNS9zaGFyZS9jb25maWcg L3Vzci9rZGUvMy41L3NodXRkb3duIC91c3Ivc2hhcmUvY29uZmlnIC92YXIvbGliL2hzcWxkYiIK Q09ORklHX1BST1RFQ1RfTUFTSz0iL2V0Yy9lbnYuZCAvZXRjL2Vudi5kL2phdmEvIC9ldGMvZm9u dHMvZm9udHMuY29uZiAvZXRjL2djb25mIC9ldGMvZ2VudG9vLXJlbGVhc2UgL2V0Yy9yZXZkZXAt cmVidWlsZCAvZXRjL3Rlcm1pbmZvIC9ldGMvdGV4bWYvd2ViMmMgL2V0Yy91ZGV2L3J1bGVzLmQi CkNYWEZMQUdTPSItbWFyY2g9YXRobG9uNjQgLU8yIC1waXBlIC1tc3NlMyIKRElTVERJUj0iL3Vz ci9wb3J0YWdlL2Rpc3RmaWxlcyIKRU1FUkdFX0RFRkFVTFRfT1BUUz0iLS13aXRoLWJkZXBzIHkg LS1kZWVwIgpGRUFUVVJFUz0iY2NhY2hlIGNvbGxpc2lvbi1wcm90ZWN0IGRpc3Rsb2NrcyBmaXhw YWNrYWdlcyBtZXRhZGF0YS10cmFuc2ZlciBwYXJhbGxlbC1mZXRjaCBzYW5kYm94IHNmcGVybXMg c3RyaWN0IHVubWVyZ2Utb3JwaGFucyB1c2VyZmV0Y2giCkdFTlRPT19NSVJST1JTPSJodHRwOi8v ZGlzdGZpbGVzLmdlbnRvby5vcmcgaHR0cDovL2Rpc3Ryby5pYmlibGlvLm9yZy9wdWIvbGludXgv ZGlzdHJpYnV0aW9ucy9nZW50b28iCkxBTkc9ImVuX1VTLlVURi04IgpMREZMQUdTPSItV2wsLU8x LC0taGFzaC1zdHlsZT1ib3RoIgpMSU5HVUFTPSJwbCBlbiBkZSIKTUFLRU9QVFM9Ii1qMyAtcyIK UEtHRElSPSIvdXNyL3BvcnRhZ2UvcGFja2FnZXMiClBPUlRBR0VfUlNZTkNfT1BUUz0iLS1yZWN1 cnNpdmUgLS1saW5rcyAtLXNhZmUtbGlua3MgLS1wZXJtcyAtLXRpbWVzIC0tY29tcHJlc3MgLS1m b3JjZSAtLXdob2xlLWZpbGUgLS1kZWxldGUgLS1zdGF0cyAtLXRpbWVvdXQ9MTgwIC0tZXhjbHVk ZT0vZGlzdGZpbGVzIC0tZXhjbHVkZT0vbG9jYWwgLS1leGNsdWRlPS9wYWNrYWdlcyIKUE9SVEFH RV9UTVBESVI9Ii92YXIvdG1wIgpQT1JURElSPSIvdXNyL3BvcnRhZ2UiClBPUlRESVJfT1ZFUkxB WT0iL3Vzci9wb3J0YWdlL2xvY2FsL2xheW1hbi9kZXNrdG9wLWVmZmVjdHMgL3Vzci9sb2NhbC9w b3J0YWdlIgpTWU5DPSJyc3luYzovL3JzeW5jLmdlbnRvby5vcmcvZ2VudG9vLXBvcnRhZ2UiClVT RT0iMTZiaXQgM2Rub3cgM2Rub3dleHQgN3ppcCBYIGE1MiBhYWMgYWFsaWIgYWNjZXNzaWJpbGl0 eSBhY2N0IGFjZSBhY2wgYWNwaSBhaW0gYWlvIGFsc2EgYW1hcm9rIGFtZCBhbWQ2NCBhbXIgYW1y bmIgYW1yd2IgYW5pbWF0aW9uIGFvIGFwbSBhcmNoaXZlIGFydHMgYXJ0c3dyYXBwZXJzdWlkIGFy dHdvcmtleHRyYSBhc3BlbGwgYXN5bmMgYXRtIGF1ZGFjaW91cyBhdWRpb2ZpbGUgYXVkaXQgYXV0 b21vdW50IGF2YWhpIGJhc2gtY29tcGxldGlvbiBiZXJrZGIgYmluYXJ5LWRyaXZlcnMgYml0dG9y cmVudCBibHVldG9vdGggYm9vc3QgYnJhbmRpbmcgYnppcDIgY2Fpcm8gY2RhdWRpbyBjZGRhIGNk ZGIgY2RpbyBjZHBhcmFub2lhIGNkciBjZHJvbSBjZyBjbGkgY29sb3JkaWZmIGNvbnNvbGUgY29u c29sZWtpdCBjb250cmliIGNwdWZyZXEgY3JhY2tsaWIgY3J5cHQgY3NzIGN0eXBlIGN1cHMgY3Vy bCBjdXJsd3JhcHBlcnMgY3Vyc29ycyBjdnMgY3h4IGRidXMgZGV2aWNlLW1hcHBlciBkZ2EgZGhj cCBkaXNrLXBhcnRpdGlvbiBkaXZ4IGRqdnUgZG1pIGRuZCBkbm90aWZ5IGRyaSBkdHMgZHYgZHZk IGR2ZHIgZHZkcmVhZCBkdmkgZWRpdG9yIGVkcyBlbGYgZW1ib3NzIGVtb3RpY29uIGVuY2EgZW5j b2RlIGVzZCBldm8gZXhpZiBleHBhdCBleHRlbnNpb25zIGV4dHJhLWFsZ29yaXRobXMgZXh0cmFz IGZhbSBmYW1lIGZhdCBmZm1wZWcgZmZ0dyBmaXJlZm94IGZsYWMgZmxhc2ggZm9udGNvbmZpZyBm b3J0cmFuIGZ0cCBmdXNlIGdhZHUgZ2FtZXMgZ2FtbXUgZ2NqIGdjb25mIGdkYm0gZ2RtIGdlY2tv IGdlZGl0IGdpZiBnaW1wIGdpdCBnbGliIGdsaXR6IGdsdXQgZ21wIGdub2tpaSBnbm9tZSBnbnV0 bHMgZ3Bob3RvMiBncG0gZ3JhcGh2aXogZ3J1YiBncyBnc20gZ3N0cmVhbWVyIGd0ayBndGtzcGVs bCBndWlsZSBnemlwIGhhbCBoZnMgaHRtbCBodHRwIGh2bSBpY2V3ZWFzZWwgaWNvbnMgaWNvbnYg aWNxIGljdSBpZDMgaWQzdGFnIGllZWUxMzk0IGlmcCBpbWFnZSBpbWFnZW1hZ2ljayBpbWxpYiBp bWxpYjIgaW1tcXQtYmMgaW5vZGUgaW5vdGlmeSBpbnRsIGlwb2QgaXB2NiBpcmMgaXJkYSBpc2Ru IGlzZG5sb2cgamF2YSBqYXZhY29tbSBqYXZhc2NyaXB0IGpmcyBqb3lzdGljayBqcGVnIGpwZWcy ayBrZGUga2RlZW5hYmxlZmluYWwga2RlaGlkZGVudmlzaWJpbGl0eSBrZG0ga2VyYmVyb3Mga3Bv bGwga3FlbXUgbGFtZSBsYXJnZWZpbGUgbGF0ZXggbGNtcyBsZGFwIGxpYmJ1cm4gbGliZHNrIGxp YmZmaSBsaWJub3RpZnkgbGlic2FtcGxlcmF0ZSBsaWJ2aXN1YWwgbGlid3d3IGxpbnV4dGhyZWFk cy10bHMgbG1fc2Vuc29ycyBsb2dyb3RhdGUgbG9nd2F0Y2ggbHptYSBsem8gbWFkIG1haWx3cmFw cGVyIG1hdHJvc2thIG1kbnNyZXNwb25kZXItY29tcGF0IG1pZGkgbWlrbW9kIG1pbWUgbWl4ZXIg bW1hcCBtbXggbW14ZXh0IG1vdXNlIG1wMyBtcDQgbXBlZyBtcGVnMiBtcGkgbXBsYXllciBtcHU0 MDEgbXNuIG11ZGZsYXAgbXVsdGlwcm9jZXNzIG11c2VwYWNrIG5hdXRpbHVzIG5jdXJzZXMgbmV0 Ym9vdCBuZXR3b3JrIG5ldHdvcmtpbmcgbmV0d29ya21hbmFnZXIgbmZzIG5scyBucHRsIG5wdGxv bmx5IG5zcGx1Z2luIG50ZnMgbnZpZGlhIG9iZXggb2dnIG9wZW5hbCBvcGVuZ2wgb3Blbm1wIG9z cyBwYW0gcGFuZ28gcGNoIHBjaSBwY3JlIHBkYSBwZGYgcGVybCBwZXJsc3VpZCBwaWRnaW4gcGl4 bWFwcyBwbG90dXRpbHMgcGx1Z2lucyBwbW91bnQgcG11IHBuZyBwb2xsaW5nIHBvc3RzY3JpcHQg cHBwZCBwdGggcHVsc2VhdWRpbyBweXRob24gcXQzIHF0M3N1cHBvcnQgcXQ0IHF1aWNrdGltZSBy YWRpbyByYXIgcmF3IHJlYWRsaW5lIHJlYWxtZWRpYSByZWNvZGUgcmVmbGVjdGlvbiByZWlzZXI0 IHJlaXNlcmZzIHNhbWJhIHNjYW5uZXIgc2RsIHNlcmlhbCBzZXNzaW9uIHNoYXJlZG1lbSBzbGFu ZyBzbWFydGNhcmQgc21wIHNtcyBzbmRmaWxlIHNwZWV4IHNwZWxsIHNwbCBzcnQgc3NlIHNzZTIg c3NsIHNzc2UzIHN0YXJ0dXAtbm90aWZpY2F0aW9uIHN0bHBvcnQgc3VidGl0bGVzIHN1YnZlcnNp b24gc3VpZCBzdmcgc3lzZnMgc3lzdmlwYyBzemlwIHRjbCB0Y3BkIHRldGV4IHRnYSB0aGVvcmEg dGhyZWFkcyB0aWZmIHRpbWlkaXR5IHRrIHRsZW4gdGxzIHRvbXNmYXN0bWF0aCB0cmFja2VyIHRy YW5zY29kZSB0cnVldHlwZSB1aSB1bmljb2RlIHVwbnAgdXNiIHV0ZW1wdGVyIHY0bCB2NGwyIHZj ZCB2aXN1YWxpemF0aW9uIHZuYyB2b3JiaXMgdnRlIHdhdiB3YXZwYWNrIHdpZmkgd21hIHdtZiB3 bXAgd3h3aW5kb3dzIHgyNjQgeDg2ZW11IHhhbmltIHhhdHRyIHhjYiB4Y29tcG9zaXRlIHhmdCB4 aW5lIHhpbmVyYW1hIHhpbmV0ZCB4bWwgeG9yZyB4b3NkIHhwbSB4cmVuZGVyIHhzY3JlZW5zYXZl ciB4diB4dmlkIHh2bWMgeXYxMiB6aXAgemxpYiIgQUxTQV9DQVJEUz0idmlybWlkaSBtcHU0MDEg bG9vcGJhY2sgZW11MTBrMSBlbXUxMGsxeCB2aWE4Mnh4IGludGVsOHgwIGludGVsOHgwbSBoZGEt aW50ZWwgdXNiLWF1ZGlvIiBBTFNBX1BDTV9QTFVHSU5TPSJhZHBjbSBhbGF3IGFzeW0gY29weSBk bWl4IGRzaGFyZSBkc25vb3AgZW1wdHkgZXh0cGx1ZyBmaWxlIGhvb2tzIGllYzk1OCBpb3BsdWcg bGFkc3BhIGxmbG9hdCBsaW5lYXIgbWV0ZXIgbXVsYXcgbXVsdGkgbnVsbCBwbHVnIHJhdGUgcm91 dGUgc2hhcmUgc2htIHNvZnR2b2wiIEFQQUNIRTJfTU9EVUxFUz0iYWN0aW9ucyBhbGlhcyBhdXRo X2Jhc2ljIGF1dGhuX2FsaWFzIGF1dGhuX2Fub24gYXV0aG5fZGJtIGF1dGhuX2RlZmF1bHQgYXV0 aG5fZmlsZSBhdXRoel9kYm0gYXV0aHpfZGVmYXVsdCBhdXRoel9ncm91cGZpbGUgYXV0aHpfaG9z dCBhdXRoel9vd25lciBhdXRoel91c2VyIGF1dG9pbmRleCBjYWNoZSBkYXYgZGF2X2ZzIGRhdl9s b2NrIGRlZmxhdGUgZGlyIGRpc2tfY2FjaGUgZW52IGV4cGlyZXMgZXh0X2ZpbHRlciBmaWxlX2Nh Y2hlIGZpbHRlciBoZWFkZXJzIGluY2x1ZGUgaW5mbyBsb2dfY29uZmlnIGxvZ2lvIG1lbV9jYWNo ZSBtaW1lIG1pbWVfbWFnaWMgbmVnb3RpYXRpb24gcmV3cml0ZSBzZXRlbnZpZiBzcGVsaW5nIHN0 YXR1cyB1bmlxdWVfaWQgdXNlcmRpciB1c2VydHJhY2sgdmhvc3RfYWxpYXMiIEVMSUJDPSJnbGli YyIgSU5QVVRfREVWSUNFUz0iZXZkZXYga2V5Ym9hcmQgbW91c2Ugam95c3RpY2sgd2Fjb20iIEtF Uk5FTD0ibGludXgiIExDRF9ERVZJQ0VTPSJiYXlyYWQgY2ZvbnR6IGNmb250ejYzMyBnbGsgaGQ0 NDc4MCBsYjIxNiBsY2RtMDAxIG10eG9yYiBuY3Vyc2VzIHRleHQiIExJTkdVQVM9InBsIGVuIGRl IiBVU0VSTEFORD0iR05VIiBWSURFT19DQVJEUz0icmFkZW9uIHIxMDAgcjIwMCByMzAwIHY0bCB2 ZXNhIG52IG52aWRpYSIKVW5zZXQ6ICBDUFBGTEFHUywgQ1RBUkdFVCwgSU5TVEFMTF9NQVNLLCBM Q19BTEwsIFBPUlRBR0VfQ09NUFJFU1MsIFBPUlRBR0VfQ09NUFJFU1NfRkxBR1MsIFBPUlRBR0Vf UlNZTkNfRVhUUkFfT1BUUwoK 156501 2008-06-12 14:25 0000 my emerge --info emergeinfo.txt text/plain UG9ydGFnZSAyLjNfcHJlMTA2MDcgKGRlZmF1bHQvbGludXgveDg2LzIwMDguMCwgZ2NjLTQuMy4x LCBnbGliYy0yLjhfcDIwMDgwNjAyLXIwLCAyLjYuMjYtcmM1LXplbjEuMCBpNjg2KQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PQpTeXN0ZW0gdW5hbWU6IExpbnV4LTIuNi4yNi1yYzUtemVuMS4wLWk2ODYtQU1EX0F0aGxvbi10 bS1fWFBfMjYwMCstd2l0aC1nbGliYzIuMApUaW1lc3RhbXAgb2YgdHJlZTogVGh1LCAxMiBKdW4g MjAwOCAxMDoxNTowMiArMDAwMAphcHAtc2hlbGxzL2Jhc2g6ICAgICAzLjJfcDM5CmRldi1qYXZh L2phdmEtY29uZmlnOiAxLjMuNywgMi4xLjYKZGV2LWxhbmcvcHl0aG9uOiAgICAgMi41LjItcjQK c3lzLWFwcHMvYmFzZWxheW91dDogMi4wLjAKc3lzLWFwcHMvb3BlbnJjOiAgICAgMC4yLjUKc3lz LWFwcHMvc2FuZGJveDogICAgMS4yLjE4LjEtcjIKc3lzLWRldmVsL2F1dG9jb25mOiAgMi4xMywg Mi42MgpzeXMtZGV2ZWwvYXV0b21ha2U6ICAxLjUsIDEuNy45LXIxLCAxLjguNS1yMywgMS45LjYt cjIsIDEuMTAuMS1yMQpzeXMtZGV2ZWwvYmludXRpbHM6ICAyLjE4LjUwLjAuNwpzeXMtZGV2ZWwv Z2NjLWNvbmZpZzogMS40LjAtcjQKc3lzLWRldmVsL2xpYnRvb2w6ICAgMi4yLjQKdmlydHVhbC9v cy1oZWFkZXJzOiAgMi42LjI1LXI0CkFDQ0VQVF9LRVlXT1JEUz0ieDg2IH54ODYiCkNCVUlMRD0i aTY4Ni1wYy1saW51eC1nbnUiCkNGTEFHUz0iLU8yIC1tYXJjaD1uYXRpdmUgLXBpcGUgLWZvbWl0 LWZyYW1lLXBvaW50ZXIgLWZ0cmVlLXZlY3Rvcml6ZSAtZm5vLWlkZW50IgpDSE9TVD0iaTY4Ni1w Yy1saW51eC1nbnUiCkNPTkZJR19QUk9URUNUPSIvZXRjIC91c3Iva2RlLzMuNS9lbnYgL3Vzci9r ZGUvMy41L3NoYXJlL2NvbmZpZyAvdXNyL2tkZS8zLjUvc2h1dGRvd24gL3Vzci9zaGFyZS9jb25m aWcgL3Zhci9saWIvaHNxbGRiIgpDT05GSUdfUFJPVEVDVF9NQVNLPSIvZXRjL2NhLWNlcnRpZmlj YXRlcy5jb25mIC9ldGMvZW52LmQgL2V0Yy9lbnYuZC9qYXZhLyAvZXRjL2ZvbnRzL2ZvbnRzLmNv bmYgL2V0Yy9nY29uZiAvZXRjL2dlbnRvby1yZWxlYXNlIC9ldGMvcGhwL2FwYWNoZTItcGhwNS9l eHQtYWN0aXZlLyAvZXRjL3BocC9jZ2ktcGhwNS9leHQtYWN0aXZlLyAvZXRjL3BocC9jbGktcGhw NS9leHQtYWN0aXZlLyAvZXRjL3JldmRlcC1yZWJ1aWxkIC9ldGMvc3BsYXNoIC9ldGMvdGVybWlu Zm8gL2V0Yy91ZGV2L3J1bGVzLmQiCkNYWEZMQUdTPSItTzIgLW1hcmNoPW5hdGl2ZSAtcGlwZSAt Zm9taXQtZnJhbWUtcG9pbnRlciAtZnRyZWUtdmVjdG9yaXplIC1mbm8taWRlbnQiCkRJU1RESVI9 Ii91c3IvcG9ydGFnZS9kaXN0ZmlsZXMiCkZFQVRVUkVTPSJkaXN0bG9ja3MgcGFyYWxsZWwtZmV0 Y2ggcHJlc2VydmUtbGlicyBzYW5kYm94IHNmcGVybXMgc3RyaWN0IHVubWVyZ2Utb3JwaGFucyB1 c2VyZmV0Y2giCkdFTlRPT19NSVJST1JTPSJodHRwOi8vZ2VudG9vLnByei5yemVzem93LnBsIGh0 dHA6Ly9nZW50b28uemllLnBnLmdkYS5wbCIKTEFORz0icGxfUEwuVVRGLTgiCkxDX0FMTD0icGxf UEwuVVRGLTgiCkxERkxBR1M9Ii1XbCwtTzEgLVdsLC0tc29ydC1jb21tb24gLVdsLC0tYXMtbmVl ZGVkIC1XbCwtLWhhc2gtc3R5bGU9Z251IgpMSU5HVUFTPSJlbiBwbCIKTUFLRU9QVFM9Ii1qMiIK UEtHRElSPSIvdXNyL3BvcnRhZ2UvcGFja2FnZXMiClBPUlRBR0VfUlNZTkNfT1BUUz0iLS1yZWN1 cnNpdmUgLS1saW5rcyAtLXNhZmUtbGlua3MgLS1wZXJtcyAtLXRpbWVzIC0tY29tcHJlc3MgLS1m b3JjZSAtLXdob2xlLWZpbGUgLS1kZWxldGUgLS1zdGF0cyAtLXRpbWVvdXQ9MTgwIC0tZXhjbHVk ZT0vZGlzdGZpbGVzIC0tZXhjbHVkZT0vbG9jYWwgLS1leGNsdWRlPS9wYWNrYWdlcyIKUE9SVEFH RV9UTVBESVI9Ii92YXIvdG1wIgpQT1JURElSPSIvdXNyL3BvcnRhZ2UiClBPUlRESVJfT1ZFUkxB WT0iL3Vzci9sb2NhbC9wb3J0YWdlL2xheW1hbi9FYWVkaWZpY2F0YSAvdXNyL2xvY2FsL3BvcnRh Z2UvbGF5bWFuL3Jvc2xpbiAvdXNyL2xvY2FsL3BvcnRhZ2UvbGF5bWFuL3plbi1vdmVybGF5IC91 c3IvbG9jYWwvcG9ydGFnZS9tb2plIC91c3IvbG9jYWwvcG9ydGFnZS9teiAvdXNyL2xvY2FsL3Bv cnRhZ2Uvam1ic3ZpY2V0dG8gL3Vzci9sb2NhbC9wb3J0YWdlL2ZvbnRzIgpTWU5DPSJyc3luYzov LzE5NC45Ny40LjI1MC9nZW50b28tcG9ydGFnZSIKVVNFPSIzZG5vdyAzZG5vd2V4dCBYIGE1MiBh YWMgYWNsIGFsc2EgYmFzaC1jb21wbGV0aW9uIGJlcmtkYiBiemlwMiBjYWlybyBjZHIgY2xpIGNy YWNrbGliIGNyeXB0IGN1cHMgZGJ1cyBkcmkgZHRzIGR2IGR2YiBkdmQgZHZkciBkdmRyZWFkIGVu Y29kZSBmYW0gZmZtcGVnIGZpcmViaXJkIGZsYWMgZm9ydHJhbiBnZGJtIGdpZiBncG0gaGFsIGlj b252IGlzZG5sb2cganBlZyBrZGUga2RlaGlkZGVudmlzaWJpbGl0eSBsZGFwIGxpYnNhbXBsZXJh dGUgbWFkIG1pZGkgbWlrbW9kIG1teCBtbXhleHQgbXAyIG1wMyBtcGVnIG11ZGZsYXAgbXVsdGlz bG90IG11c2VwYWNrIG5jdXJzZXMgbmV3c3ByIG5scyBucHRsIG5wdGxvbmx5IG9nZyBvcGVuYWwg b3BlbmdsIG9wZW5tcCBwYW0gcGNyZSBwZGYgcGVybCBwbmcgcHBwZCBweXRob24gcXQgcXVpY2t0 aW1lIHJlYWRsaW5lIHJlYWwgcmVmbGVjdGlvbiBzZXNzaW9uIHNwbCBzcWxpdGUzIHNzZSBzc2wg c3ZnIHRjcGQgdGhlb3JhIHRocmVhZHMgdGlmZiB0cnVldHlwZSB1bmljb2RlIHZvcmJpcyB3YXZw YWNrIHdpbjMyY29kZWNzIHgyNjQgeDg2IHhtbCB4b3JnIHh2IHh2aWQgeHZtYyB6bGliIiBBTFNB X0NBUkRTPSJlbXUxMGsxIiBBTFNBX1BDTV9QTFVHSU5TPSJhZHBjbSBhbGF3IGFzeW0gY29weSBk bWl4IGRzaGFyZSBkc25vb3AgZW1wdHkgZXh0cGx1ZyBmaWxlIGhvb2tzIGllYzk1OCBpb3BsdWcg bGFkc3BhIGxmbG9hdCBsaW5lYXIgbWV0ZXIgbXVsYXcgbXVsdGkgbnVsbCBwbHVnIHJhdGUgcm91 dGUgc2hhcmUgc2htIHNvZnR2b2wiIEFQQUNIRTJfTU9EVUxFUz0iYXV0aG5fY29yZSBhdXRoel9j b3JlIGFjdGlvbnMgYWNjZXNzX2NvbXBhdCBhbGlhcyBhdXRoX2Jhc2ljIGF1dGhfZGlnZXN0IGF1 dGhuX2Fub24gYXV0aG5fZGJkIGF1dGhuX2RibSBhdXRobl9kZWZhdWx0IGF1dGhuX2ZpbGUgYXV0 aHpfZGJtIGF1dGh6X2RlZmF1bHQgYXV0aHpfZ3JvdXBmaWxlIGF1dGh6X2hvc3QgYXV0aHpfb3du ZXIgYXV0aHpfdXNlciBhdXRvaW5kZXggY2FjaGUgZGF2IGRhdl9mcyBkYXZfbG9jayBkYmQgZGVm bGF0ZSBkaXIgZGlza19jYWNoZSBlbnYgZXhwaXJlcyBleHRfZmlsdGVyIGZpbGVfY2FjaGUgZmls dGVyIGhlYWRlcnMgaWRlbnQgaW1hZ2VtYXAgaW5jbHVkZSBpbmZvIGxvZ19jb25maWcgbG9naW8g bWVtX2NhY2hlIG1pbWUgbWltZV9tYWdpYyBuZWdvdGlhdGlvbiBwcm94eSBwcm94eV9hanAgcHJv eHlfYmFsYW5jZXIgcHJveHlfY29ubmVjdCBwcm94eV9odHRwIHJld3JpdGUgc2V0ZW52aWYgc28g c3BlbGluZyBzdGF0dXMgdW5pcXVlX2lkIHVzZXJkaXIgdXNlcnRyYWNrIHZob3N0X2FsaWFzIiBF TElCQz0iZ2xpYmMiIElOUFVUX0RFVklDRVM9ImtleWJvYXJkIG1vdXNlIiBLRVJORUw9ImxpbnV4 IiBMQ0RfREVWSUNFUz0iYmF5cmFkIGNmb250eiBjZm9udHo2MzMgZ2xrIGhkNDQ3ODAgbGIyMTYg bGNkbTAwMSBtdHhvcmIgbmN1cnNlcyB0ZXh0IiBMSU5HVUFTPSJlbiBwbCIgVVNFUkxBTkQ9IkdO VSIgVklERU9fQ0FSRFM9Im52aWRpYSBudiB2ZXNhIgpVbnNldDogIENQUEZMQUdTLCBDVEFSR0VU LCBFTUVSR0VfREVGQVVMVF9PUFRTLCBJTlNUQUxMX01BU0ssIFBPUlRBR0VfQ09NUFJFU1MsIFBP UlRBR0VfQ09NUFJFU1NfRkxBR1MsIFBPUlRBR0VfUlNZTkNfRVhUUkFfT1BUUwoK 159848 2008-07-08 00:14 0000 klibc-1.5.11-klibcmemmove.patch klibc-1.5.11-klibcmemmove.patch text/plain LS0tIC4va2xpYmMtMS41LjExL3Vzci9rbGliYy9tZW1tb3ZlLmMJMjAwOC0wNi0xNSAxODoyODoy My4wMDAwMDAwMDAgLTA2MDAKKysrIC4va2xpYmMtMS41LjExL3Vzci9rbGliYy9tZW1tb3ZlLmMu Zml4CTIwMDgtMDctMDcgMTc6MTQ6NTIuMDAwMDAwMDAwIC0wNjAwCkBAIC04LDE3ICs4LDE3IEBA CiB7CiAJY29uc3QgY2hhciAqcCA9IHNyYzsKIAljaGFyICpxID0gZHN0OwotI2lmIGRlZmluZWQo X19pMzg2X18pIHx8IGRlZmluZWQoX194ODZfNjRfXykKLQlpZiAocSA8IHApIHsKLQkJYXNtIHZv bGF0aWxlKCJjbGQgOyByZXAgOyBtb3ZzYiIKLQkJCSAgICAgOiAiK2MiIChuKSwgIitTIihwKSwg IitEIihxKSk7Ci0JfSBlbHNlIHsKLQkJcCArPSAobiAtIDEpOwotCQlxICs9IChuIC0gMSk7Ci0J CWFzbSB2b2xhdGlsZSgic3RkIDsgcmVwIDsgbW92c2IiCi0JCQkgICAgIDogIitjIiAobiksICIr UyIocCksICIrRCIocSkpOwotCX0KLSNlbHNlCisvLyNpZiBkZWZpbmVkKF9faTM4Nl9fKSB8fCBk ZWZpbmVkKF9feDg2XzY0X18pCisvLwlpZiAocSA8IHApIHsKKy8vCQlhc20gdm9sYXRpbGUoImNs ZCA7IHJlcCA7IG1vdnNiIgorLy8JCQkgICAgIDogIitjIiAobiksICIrUyIocCksICIrRCIocSkp OworLy8JfSBlbHNlIHsKKy8vCQlwICs9IChuIC0gMSk7CisvLwkJcSArPSAobiAtIDEpOworLy8J CWFzbSB2b2xhdGlsZSgic3RkIDsgcmVwIDsgbW92c2IiCisvLwkJCSAgICAgOiAiK2MiIChuKSwg IitTIihwKSwgIitEIihxKSk7CisvLwl9CisvLyNlbHNlCiAJaWYgKHEgPCBwKSB7CiAJCXdoaWxl IChuLS0pIHsKIAkJCSpxKysgPSAqcCsrOwpAQCAtMzAsNyArMzAsNyBAQAogCQkJKi0tcSA9ICot LXA7CiAJCX0KIAl9Ci0jZW5kaWYKKy8vI2VuZGlmCiAKIAlyZXR1cm4gZHN0OwogfQo= 159850 2008-07-08 00:18 0000 klibc-1.5.11.ebuild klibc-1.5.11.ebuild text/plain IyBDb3B5cmlnaHQgMTk5OS0yMDA4IEdlbnRvbyBGb3VuZGF0aW9uCiMgRGlzdHJpYnV0ZWQgdW5k ZXIgdGhlIHRlcm1zIG9mIHRoZSBHTlUgR2VuZXJhbCBQdWJsaWMgTGljZW5zZSB2MgojICRIZWFk ZXI6IC92YXIvY3Zzcm9vdC9nZW50b28teDg2L2Rldi1saWJzL2tsaWJjL2tsaWJjLTEuNS4xMS5l YnVpbGQsdiAxLjEgMjAwOC8wNi8yNiAxODoxODowOSByb2JiYXQyIEV4cCAkCgojIFJvYmluIEgu IEpvaG5zb24gPHJvYmJhdDJAZ2VudG9vLm9yZz4sIDEyIE5vdiAyMDA3OgojIFRoaXMgc3RpbGwg bmVlZHMgbWFqb3Igd29yay4KIyBCdXQgaXQgaXMgc2lnbmlmaWNlbnRseSBiZXR0ZXIgdGhhbiB0 aGUgcHJldmlvdXMgdmVyc2lvbi4KIyBJbiB0aGF0IGl0IHdpbGwgbm93IGJ1aWxkIG9uIGJpYXJj aCBzeXN0ZW1zLCBzdWNoIGFzIHBwYzY0LTMydWwuCgojIE5PVEVTOgojID09PT09PQojIFdlIG5l ZWQgdG8gYnJpbmcgaW4gdGhlIGtlcm5lbCBzb3VyY2VzIHNlcGVyYXRlbHkKIyBCZWNhdXNlIHRo ZXkgaGF2ZSB0byBiZSBjb25maWd1cmVkIGluIGEgd2F5IHRoYXQgZGlmZmVycyBmcm9tIHRoZSBj b3B5IGluCiMgL3Vzci9zcmMvLiBUaGUgc3lzLWtlcm5lbC9saW51eC1oZWFkZXJzIGFyZSB0b28g c3RyaXBwZWQgZG93biB0byB1c2UKIyB1bmZvcnR1bmV0bHkuCiMgVGhpcyB3aWxsIGJlIGFibGUg dG8gZ28gYXdheSBvbmNlIHRoZSBrbGliYyBhdXRob3IgdXBkYXRlcyBoaXMgY29kZQojIHRvIGJ1 aWxkIGFnYWluIHRoZSBoZWFkZXJzIHByb3ZpZGVkIGJ5IHRoZSBrZXJuZWwncyAnaGVhZGVyc19p bnN0YWxsJyB0YXJnZXQuCgppbmhlcml0IGV1dGlscyBtdWx0aWxpYiB0b29sY2hhaW4tZnVuY3MK CkRFU0NSSVBUSU9OPSJBIG1pbmltYWwgbGliYyBzdWJzZXQgZm9yIHVzZSB3aXRoIGluaXRyYW1m cy4iCkhPTUVQQUdFPSJodHRwOi8vd3d3Lnp5dG9yLmNvbS9tYWlsbWFuL2xpc3RpbmZvL2tsaWJj IgpLVl9NQUpPUj0iMiIgS1ZfTUlOT1I9IjYiIEtWX1NVQj0iMjMiCk9LVj0iJHtLVl9NQUpPUn0u JHtLVl9NSU5PUn0uJHtLVl9TVUJ9IgpQS1Y9IiR7S1ZfTUFKT1J9LiR7S1ZfTUlOT1J9LiQoKCR7 S1ZfU1VCfSsxKSktcmM3IgpQQVRDSF9VUkk9Im1pcnJvcjovL2tlcm5lbC9saW51eC9rZXJuZWwv diR7S1ZfTUFKT1J9LiR7S1ZfTUlOT1J9L3BhdGNoLSR7UEtWfS5iejIiCktFUk5FTF9VUkk9Im1p cnJvcjovL2tlcm5lbC9saW51eC9rZXJuZWwvdiR7S1ZfTUFKT1J9LiR7S1ZfTUlOT1J9L3Rlc3Rp bmcvbGludXgtJHtPS1Z9LnRhci5iejIiClNSQ19VUkk9IgoJbWlycm9yOi8va2VybmVsL2xpbnV4 L2xpYnMva2xpYmMvJHtQfS50YXIuYnoyCgltaXJyb3I6Ly9rZXJuZWwvbGludXgvbGlicy9rbGli Yy9UZXN0aW5nLyR7UH0udGFyLmJ6MgoJJHtQQVRDSF9VUkl9Cgkke0tFUk5FTF9VUkl9IgoKTElD RU5TRT0ifHwgKCBHUEwtMiBMR1BMLTIgKSIKS0VZV09SRFM9In5hbWQ2NCAtbWlwcyB+cHBjIH5z cGFyYyB+eDg2IgpTTE9UPSIwIgpJVVNFPSJkZWJ1ZyBuMzIiCgpERVBFTkQ9ImRldi1sYW5nL3Bl cmwiClJERVBFTkQ9IiR7REVQRU5EfSIKCktTPSIke1dPUktESVJ9L2xpbnV4LSR7T0tWfSIKCiMg S2xpYmMgaGFzIG5vIFBUX0dOVV9TVEFDSyBzdXBwb3J0LCBzbyBzY2FubmluZyBmb3IgZXhlY3N0 YWNrcyBpcyBtb290ClFBX0VYRUNTVEFDSz0iKiIKIyBEbyBub3Qgc3RyaXAKUkVTVFJJQ1Q9InN0 cmlwIgoKc3JjX3VucGFjaygpIHsKCXVucGFjayBsaW51eC0ke09LVn0udGFyLmJ6MiAke1B9LnRh ci5iejIKCUVQQVRDSF9PUFRTPSItZCAke0tTfSAtcDEiIGVwYXRjaCAiJHtESVNURElSfSIvcGF0 Y2gtJHtQS1Z9LmJ6MgoJY2QgIiR7U30iCgoJIyBTeW1saW5rIC91c3Ivc3JjL2xpbnV4IHRvICR7 U30vbGludXgKCWxuIC1zbmYgIiR7S1N9IiBsaW51eAoJI2xuIC1zbmYgIi91c3IiIGxpbnV4CgoJ IyBCdWlsZCBpbnRlcnAubyB3aXRoIEVYVFJBX0tMSUJDQUZMQUdTICguUyBzb3VyY2UpCgllcGF0 Y2ggIiR7RklMRVNESVJ9Ii8ke1BOfS0xLjQuMTEtaW50ZXJwLWZsYWdzLnBhdGNoCgoJIyBGaXhl cyBmb3Igc3BhcmMgYW5kIHBwYwoJZXBhdGNoICIke0ZJTEVTRElSfSIvJHtQTn0tMS41LXNpZ2Fj dGlvbi5wYXRjaAoKCSMgUHJldmVudCBrbGliYyBmcm9tIHByZXN0cmlwcGluZyBzdHVmZgojCWVw YXRjaCAiJHtGSUxFU0RJUn0iLyR7UH0tbm9zdHJpcC5wYXRjaAoKCSMgRml4IHRoZSBhc20tcHBj IHZzLiBhc20tcG93ZXJwYyBpc3N1ZSwgYnVnICMxOTY1MjEKCWVwYXRjaCAiJHtGSUxFU0RJUn0i LyR7UE59LTEuNS4xMS1rbGliY2FzbWFyY2gucGF0Y2gKCgkjIEZpeCB1c2FnZSBvZiAtcywgYnVn ICMyMDEwMDYKCWVwYXRjaCAiJHtGSUxFU0RJUn0iL2tsaWJjLTEuNS43LXN0cmlwLWZpeC1kYXNo LXMucGF0Y2gKCgkjIGJ1ZyAyMjk1MjUsIHVzci9pbmNsdWRlL2FyY2gveDg2XzY0L3N5cy9pby5o IGhhcyB1bmRlZmluZWQgdmFyaWFibGVzCgllcGF0Y2ggIiR7RklMRVNESVJ9Ii8ke1BOfS0xLjUu MTEteDg2XzY0LWlvLmgtcmV0dXJuLmRpZmYKCgllcGF0Y2ggIiR7RklMRVNESVJ9Ii8ke1BOfS0x LjUuMTEta2xpYmNtZW1tb3ZlLnBhdGNoIHx8IGRpZSAiRmFpbGVkIHRvIHBhdGNoIG1lbW1vdmUi Cn0KCiMgRm9yIGEgZ2l2ZW4gR2VudG9vIEFSQ0gsCiMgc3BlY2lmeSB0aGUga2VybmVsIGRlZmNv bmZpZyBtb3N0IHJlbGV2YW50Cmtlcm5lbF9kZWZjb25maWcoKSB7CglhPSIkezE6JHtBUkNIfX0i CgkjIG1vc3QsIGJ1dCBub3QgYWxsIGFyY2hlcyBoYXZlIGEgc2FuZWx5IG5hbWVkIGRlZmNvbmZp ZwoJY2FzZSAke2F9IGluCgkJcHBjNjQpIGVjaG8gcHBjNjRfZGVmY29uZmlnIDs7CgkJcHBjKSBl Y2hvIHBtYWMzMl9kZWZjb25maWcgOzsKCQlhcm0qfHNoKikgZGllICJUT0RPOiBZb3VyIGFyY2gg aXMgbm90IHN1cHBvcnRlZCBieSB0aGUga2xpYmMgZWJ1aWxkLiBQbGVhc2Ugc3VnZ2VzdCBhIGRl ZmNvbmZpZyBpbiBhIGJ1Zy4iIDs7CgkJKikgZWNobyBkZWZjb25maWcgOzsKCWVzYWMKfQoKIyBr bGliYyBoYXMgaXQncyBvd24gaWRlYXMgb2YgYXJjaGVzCiMgVGhleSByZWZsZWN0IHVzZXJzcGFj ZSBzdHJpY3RseS4KIyBUaGlzIGZ1bmN0aW9ucyBtYXBzIGZyb20gYSBHZW50b28gQVJDSCwgdG8g YW4gYXJjaCB0aGF0IGtsaWJjIGV4cGVjdHMKIyBMb29rIGF0IGtsaWJjLSR7U30vdXNyL2tsaWJj L2FyY2ggZm9yIGEgbGlzdCBvZiB0aGVzZSBhcmNoZXMKa2xpYmNfYXJjaCgpIHsKCWE9IiR7MTok e0FSQ0h9fSIKCWNhc2UgJHthfSBpbgoJCWFtZDY0KSBlY2hvIHg4Nl82NDs7CgkJbWlwcykgZGll ICdUT0RPOiBVc2UgdGhlICRBQkknIDs7CgkJeDg2KSBlY2hvIGkzODY7OwoJCSopIGVjaG8gJHth fSA7OwoJZXNhYwp9CgprZXJuZWxfYXNtX2FyY2goKSB7CglhPSIkezE6JHtBUkNIfX0iCgljYXNl ICR7YX0gaW4KCQkjIE1lcmdlZCBhcmNoZXMKCQl4ODZ8YW1kNjQpIGVjaG8geDg2IDs7CgkJcHBj KikgZWNobyBwb3dlcnBjIDs7CgkJIyBOb24tbWVyZ2VkCgkJYWxwaGF8YXJtfGlhNjR8bTY4a3xt aXBzfHNofHNwYXJjKikgZWNobyAkezF9IDs7CgkJKikgZGllICJUT0RPOiBVcGRhdGUgdGhlIGNv ZGUgZm9yIHlvdXIgYXNtLUFSQ0ggc3ltbGluayIgOzsKCWVzYWMKfQoKc3JjX2NvbXBpbGUoKSB7 Cglsb2NhbCBteWFyZ3MKCWxvY2FsIG15QVJDSD0iJHtBUkNIfSIgbXlBQkk9IiR7QUJJfSIKCSMg VE9ETzogRm9yIGNyb3NzLWNvbXBpbGluZwoJIyBZb3Ugc2hvdWxkIHNldCBBUkNIIGFuZCBBQkkg aGVyZQoJQ0M9IiQodGMtZ2V0Q0MpIgoJSE9TVENDPSIkKHRjLWdldEJVSUxEX0NDKSIKCUtMSUJD QVJDSD0iJChrbGliY19hcmNoICR7QVJDSH0pIgoJS0xJQkNBU01BUkNIPSIkKGtlcm5lbF9hc21f YXJjaCAke0FSQ0h9KSIKCWxpYmRpcj0iJChnZXRfbGliZGlyKSIKCSMgVGhpcyBzaG91bGQgYmUg dGhlIGRlZmNvbmZpZyBjb3JyZXNwb25kaW5nIHRvIHlvdXIgdXNlcnNwYWNlIQoJIyBOT1QgeW91 ciBrZXJuZWwuIFBQQzY0LTMydWwgd291bGQgY2hvb3NlICdwcGMnIGZvciBleGFtcGxlLgoJZGVm Y29uZmlnPSQoa2VybmVsX2RlZmNvbmZpZyAke0FSQ0h9KQoJdW5zZXQgQUJJIEFSQ0ggIyBVbnNl dCB0aGVzZSwgYmVjYXVzZSB0aGV5IGludGVyZmVyZQoJdW5zZXQgS0JVSUxEX09VVFBVVCAjIHdl IGFyZSB1c2luZyBhIHByaXZhdGUgY29weQoKCWNkICIke0tTfSIKCWVtYWtlICR7ZGVmY29uZmln fSB8fCBkaWUgIk5vIGRlZmNvbmZpZyIKCWVtYWtlIHByZXBhcmUgfHwgZGllICJGYWlsZWQgdG8g cHJlcGFyZSBrZXJuZWwgc291cmNlcyBmb3IgaGVhZGVyIHVzYWdlIgoKCWNkICIke1N9IgoKCXVz ZSBkZWJ1ZyAmJiBteWFyZ3M9IiR7bXlhcmdzfSBWPTEiCgoJZW1ha2UgXAoJCUVYVFJBX0tMSUJD QUZMQUdTPSItV2EsLS1ub2V4ZWNzdGFjayIgXAoJCUVYVFJBX0tMSUJDTERGTEFHUz0iLXosbm9l eGVjc3RhY2siIFwKCQlIT1NUQ0M9IiR7SE9TVENDfSIgQ0M9IiR7Q0N9IiBcCgkJSU5TVEFMTERJ Uj0iL3Vzci8ke2xpYmRpcn0va2xpYmMiIFwKCQlLTElCQ0FSQ0g9JHtLTElCQ0FSQ0h9IFwKCQlL TElCQ0FTTUFSQ0g9JHtLTElCQ0FTTUFSQ0h9IFwKCQlTSExJQkRJUj0iLyR7bGliZGlyfSIgXAoJ CWxpYmRpcj0iL3Vzci8ke2xpYmRpcn0iIFwKCQltYW5kaXI9Ii91c3Ivc2hhcmUvbWFuIiBcCgkJ JHtteWFyZ3N9IHx8IGRpZSAiQ29tcGlsZSBmYWlsZWQhIgoKCQkjU0hMSUJESVI9Ii8ke2xpYmRp cn0iIFwKCglBUkNIPSIke215QVJDSH0iIEFCST0iJHtteUFCSX0iCn0KCnNyY19pbnN0YWxsKCkg ewoJbG9jYWwgbXlhcmdzCglsb2NhbCBteUFSQ0g9IiR7QVJDSH0iIG15QUJJPSIke0FCSX0iCgkj IFRPRE86IEZvciBjcm9zcy1jb21waWxpbmcKCSMgWW91IHNob3VsZCBzZXQgQVJDSCBhbmQgQUJJ IGhlcmUKCUNDPSIkKHRjLWdldENDKSIKCUhPU1RDQz0iJCh0Yy1nZXRCVUlMRF9DQykiCglLTElC Q0FSQ0g9IiQoa2xpYmNfYXJjaCAke0FSQ0h9KSIKCUtMSUJDQVNNQVJDSD0iJChrZXJuZWxfYXNt X2FyY2ggJHtBUkNIfSkiCglsaWJkaXI9IiQoZ2V0X2xpYmRpcikiCgkjIFRoaXMgc2hvdWxkIGJl IHRoZSBkZWZjb25maWcgY29ycmVzcG9uZGluZyB0byB5b3VyIHVzZXJzcGFjZSEKCSMgTk9UIHlv dXIga2VybmVsLiBQUEM2NC0zMnVsIHdvdWxkIGNob29zZSAncHBjJyBmb3IgZXhhbXBsZS4KCWRl ZmNvbmZpZz0kKGtlcm5lbF9kZWZjb25maWcgJHtBUkNIfSkKCgl1c2UgZGVidWcgJiYgbXlhcmdz PSIke215YXJnc30gVj0xIgoKCWxvY2FsIGtsaWJjX3ByZWZpeAoJaWYgdGMtaXMtY3Jvc3MtY29t cGlsZXIgOyB0aGVuCgkJa2xpYmNfcHJlZml4PSQoIiR7U30va2xjYy8ke0tMSUJDQVJDSH0ta2xj YyIgLXByaW50LWtsaWJjLXByZWZpeCkKCWVsc2UKCQlrbGliY19wcmVmaXg9JCgiJHtTfS9rbGNj L2tsY2MiIC1wcmludC1rbGliYy1wcmVmaXgpCglmaQoKCXVuc2V0IEFCSSBBUkNIICMgVW5zZXQg dGhlc2UsIGJlY2F1c2UgdGhleSBpbnRlcmZlcmUKCXVuc2V0IEtCVUlMRF9PVVRQVVQgIyB3ZSBh cmUgdXNpbmcgYSBwcml2YXRlIGNvcHkKCgllbWFrZSBcCgkJRVhUUkFfS0xJQkNBRkxBR1M9Ii1X YSwtLW5vZXhlY3N0YWNrIiBcCgkJRVhUUkFfS0xJQkNMREZMQUdTPSIteixub2V4ZWNzdGFjayIg XAoJCUhPU1RDQz0iJHtIT1NUQ0N9IiBDQz0iJHtDQ30iIFwKCQlJTlNUQUxMRElSPSIvdXNyLyR7 bGliZGlyfS9rbGliYyIgXAoJCUlOU1RBTExST09UPSIke0R9IiBcCgkJS0xJQkNBUkNIPSR7S0xJ QkNBUkNIfSBcCgkJS0xJQkNBU01BUkNIPSR7S0xJQkNBU01BUkNIfSBcCgkJU0hMSUJESVI9Ii8k e2xpYmRpcn0iIFwKCQlsaWJkaXI9Ii91c3IvJHtsaWJkaXJ9IiBcCgkJbWFuZGlyPSIvdXNyL3No YXJlL21hbiIgXAoJCSR7bXlhcmdzfSBcCgkJaW5zdGFsbCB8fCBkaWUgIkluc3RhbGwgZmFpbGVk ISIKCgkJI1NITElCRElSPSIvJHtsaWJkaXJ9IiBcCgoJIyBrbGliYyBkb2Vzbid0IHN1cHBvcnQg cHJlbGlua2luZywgc28gd2UgbmVlZCB0byBtYXNrIGl0CgljYXQgPiAiJHtUfS83MGtsaWJjIiA8 PC1FT0YKCQlQUkVMSU5LX1BBVEhfTUFTSz0iL3Vzci8ke2xpYmRpcn0va2xpYmMiCglFT0YKCglk b2VudmQgIiR7VH0iLzcwa2xpYmMKCgkjIEZpeCB0aGUgcGVybWlzc2lvbnMgKGJ1ZyAjMTc4MDUz KSBvbiAvdXNyLyR7bGliZGlyfS9rbGliYy9pbmNsdWRlCgkjIEFjdHVhbGx5IEkgaGF2ZSBubyBp ZGVhLCB3aHkgdGhlIGluY2x1ZGVzIGhhdmUgdGhvc2Ugd2VpcmQtYXNzIHBlcm1pc3Npb25zCgkj IG9uIGEgcGFydGljdWxhciBzeXN0ZW0sIG1pZ2h0IGJlIGR1ZSB0byBpbmhlcml0ZWQgcGVybWlz c2lvbnMgZnJvbSBwYXJlbnQKCSMgZGlyZWN0b3J5CglmaW5kICIke0R9Ii91c3IvJHtsaWJkaXJ9 L2tsaWJjL2luY2x1ZGUgfCB4YXJncyBjaG1vZCBvK3JYCgoJIyBIYXJkbGlua3MgYmVjb21pbmcg Y29waWVzCglmb3IgeCBpbiBndW56aXAgemNhdCA7IGRvCgkJcm0gLWYgIiR7RH0vJHtrbGliY19w cmVmaXh9L2Jpbi8ke3h9IgoJCWRvc3ltIGd6aXAgIiR7a2xpYmNfcHJlZml4fS9iaW4vJHt4fSIK CWRvbmUKCgkjIFJlc3RvcmUgbm93LCBzbyB3ZSBjYW4gdXNlIHRoZSB0Yy0gZnVuY3Rpb25zCglB UkNIPSIke215QVJDSH0iIEFCST0iJHtteUFCSX0iCglpZiAhIHRjLWlzLWNyb3NzLWNvbXBpbGVy IDsgdGhlbgoJCWNkICIke1N9IgoJCWluc2ludG8gL3Vzci9zaGFyZS9hY2xvY2FsCgkJZG9pbnMg Y29udHJpYi9rbGliYy5tNAoKCQlkb2RvYyBSRUFETUUgdXNyL2tsaWJjL0NBVkVBVFMgdXNyL2ts aWJjL1JFQURNRQoJCW5ld2RvYyB1c3Iva2xpYmMvYXJjaC9SRUFETUUgUkVBRE1FLmtsaWJjLmFy Y2gKCQlkb2NpbnRvIGRhc2g7IG5ld2RvYyB1c3IvZGFzaC9SRUFETUUua2xpYmMgUkVBRE1FCgkJ ZG9jaW50byBnemlwOyBkb2RvYyB1c3IvZ3ppcC9SRUFETUUKCWZpCgoJIyBGaXggdXAgdGhlIHN5 bWxpbmsKCSMgTWFpbmx5IGZvciBtZXJnZWQgYXJjaGVzCglsaW5rbmFtZT0iJHtEfS91c3IvJHts aWJkaXJ9L2tsaWJjL2luY2x1ZGUvYXNtIgoJaWYgWyAtTCAiJHtsaW5rbmFtZX0iIF0gJiYgWyAh IC1lICIke2xpbmtuYW1lfSIgXSA7IHRoZW4KCQlsbiAtc25mIGFzbS0ke0tMSUJDQVNNQVJDSH0g IiR7bGlua25hbWV9IgoJZmkKfQo=