With ati-drivers 8.13.4 which support the Ati Radeon XPress 200m, if I enable drm (with Option nodrm="no" in xorg.conf) Xorg segfaults on startup. Reproducible: Always Steps to Reproduce: 1.emerge /usr/portage/media-video/ati-drivers/ati-drivers-8.13.4.ebuild 2.modprobe fglrx 3.run X with fglrx driver and nodrm="no" option Actual Results: X crashes (I've never been able to enable drm on my platform with ati drivers close or open source. emerge --info: Portage 2.0.51.22-r2 (default-linux/amd64/2005.0, gcc-3.4.4, glibc-2.3.5-r0, 2.6.12-cko3 x86_64) ================================================================= System uname: 2.6.12-cko3 x86_64 AMD Athlon(tm) 64 Processor 3500+ Gentoo Base System version 1.6.13 ccache version 2.4 [enabled] dev-lang/python: 2.3.5, 2.4.1-r1 sys-apps/sandbox: 1.2.11 sys-devel/autoconf: 2.13, 2.59-r7 sys-devel/automake: 1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6 sys-devel/binutils: 2.16.1 sys-devel/libtool: 1.5.18-r1 virtual/os-headers: 2.6.11-r2 ACCEPT_KEYWORDS="amd64 ~amd64" AUTOCLEAN="yes" CBUILD="x86_64-pc-linux-gnu" CFLAGS="-O2 -march=athlon64 -pipe -mmmx -m3dnow -msse -msse2" CHOST="x86_64-pc-linux-gnu" CONFIG_PROTECT="/etc /usr/kde/2/share/config /usr/kde/3.3/env /usr/kde/3.3/share/config /usr/kde/3.3/shutdown /usr/kde/3.4/env /usr/kde/3.4/share/config /usr/kde/3.4/shutdown /usr/kde/3/share/config /usr/lib/X11/xkb /usr/lib64/mozilla/defaults/pref /usr/share/config /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/splash /etc/terminfo /etc/texmf/web2c /etc/env.d" CXXFLAGS="-O2 -march=athlon64 -pipe -mmmx -m3dnow -msse -msse2" DISTDIR="/usr/portage/distfiles" FEATURES="autoconfig candy ccache distlocks sandbox sfperms strict" GENTOO_MIRRORS="http://www.die.unipd.it/pub/Linux/distributions/gentoo-sources/ ftp://ftp.unina.it/pub/linux/distributions/gentoo http://mirror.switch.ch/ftp/mirror/gentoo/ ftp://mirror.switch.ch/mirror/gentoo/ http://ibiblio.org/pub/Linux/MIRRORS.html " LANG="it_IT" LC_ALL="it_IT" LINGUAS="it" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" SYNC="rsync://rsync.de.gentoo.org/gentoo-portage" USE="amd64 X aalib acpi alsa arts audiofile avi bash-completion bash-completition bcmath berkdb bindist bitmap-fonts bluetooth bonobo bzlib caps cdparanoia cdr crypt css ctype cups curl dbm dbus dbx dga doc dv dvb dvd dvdr dvdread eds encode esd exif expat fbcon ffmpeg fftw flac flash foomaticdb fortran freetype ftp gb gd gdbm gif gimpprint glut gmp gnome gphoto2 gpm gstreamer gtk gtk2 gtkhtml guile hal howl iconv ieee1394 imagemagick imap imlib innodb ipv6 java javascript jpeg junit kde kdeenablefinal kernel_linux lcms ldap lesstif libcaca libedit libgda libwww lirc lm_sensors logitech lzw lzw-tiff mad mhash mikmod mime ming mmap mng motif mozilla mp3 mpeg msn musepack mysql mysqli ncurses nls nptl ogg oggvorbis openal opengl pam pcmcia pcre pdflib perl plotutils plugin png posix postgres ppds python qt quicktime readline samba scanner sdl session sharedext sharedmem simplexml slang sndfile snmp soap sockets sox speex spell spl sqlite ssl sumlink svg sysvipc szip tcltk tcpd tetex theora threads tidy tiff tokenizer truetype truetype-fonts type1-fonts unicode usb userlocales v4l vcd videos vorbis wifi wmf wxwindows xface xine xinerama xml xml2 xmlrpc xmms xosd xpm xsl xv xvid zeroconf zlib linguas_it userland_GNU elibc_glibc" Unset: ASFLAGS, CTARGET, LDFLAGS, PORTDIR_OVERLAY
Created attachment 64342 [details] Xorg.log
Created attachment 64343 [details] xorg.conf Sorry if there's some configuration garbage in it
Have you tried a stock config generated by fglrxconfig?
My actual config (attached, apart for the no_dri option) is an hybrid between fglrxconfig and xorg config. I tried a bare stock config from fglrxconfig but as a result I, interestingly, gained a black screen (a functional one :-), I was able to kill X, the screen remained black, so I typed reboot and anything went fine. At the end in Xorg.0.log I found nothing interesting for this last run, everything seems perfect). Umh, this seems to me as a progress!
Created attachment 64454 [details] Xorg.log with fglrxconfig stock config
Created attachment 64455 [details] Stock config by fglrxconf
From your log: Symbol R200_MMREADULONG_INDEX from module /usr/lib64/modules/drivers/fglrx_drv.o is unresolved! Symbol R200_MMREADULONG_INDEX from module /usr/lib64/modules/drivers/fglrx_drv.o is unresolved! Looks like you're not alone: http://forums.fedoraforum.org/showpost.php?p=298906&postcount=1 Can you confirm this kernel oops? Looks like your card might be "supported", that is, not. :/
No. I receive no kernel Oops... Now, using a fglrxconfig made xorg.conf, I'm able to set up DRM! But the screen is completely black and I have to do an hard reboot in order to get control over my machine...
Ah, do the 8.14.13 drivers work with your card? If so, the -r2 will fix problems with 2.6.12 kernels (most likely the issue you are having). If not, maybe you can get some of the patches from 8.14.13-r2 to work with your version.
Sadly not. It's not supported. I will try to enter some of the patches into 8.13.4, but I'm not a source expert. We'll see... Anyway the screen becomes (and persist) black only with drm on. Everything runs perfectly with drm off...
Hi! With version 8.18.8 when I activate drm the screen is black and unusuable. And if I kill X the screen remains black, but the keyboard seems to be responsive
could you please: attach a dmesg log attach a lspci output attach the kernel .config
Created attachment 72413 [details] The dmesg log This is the dmesg after modprobing fglrx
Created attachment 72414 [details] this is a verbose lspci
Created attachment 72415 [details] This my current .config for kernel 2.6.14-archck1 (with a little patch by me)
could you please use the gentoo-sources just to sort out a possible cause? (and get a dmesg after the system went black.
Created attachment 72417 [details] The dmesg Dmesg with fglrx 8.18.8, linux-2.6.14-gentoo. Nothing has changed. The screen becomes black (please note: not poweroff, just black) and it stay unusable until next reboot. This only with drm enableb. If I put no_drm=yes everything runs (as you can see ;-)
Could you try if disabling acpi and/or apic the situation changes?
Hi! I've tried with no acpi/apic but nothing changes. I don't think it's a kernel problems, because from the log it seems that all works. I assume that the desktop environment is loaded too (though with the usual black screen...)
Im getting a very similar problem with my setup. Have not been able to get system to boot with dri enabled ... black screen and crash. Xorg log seems ok. Using gentoo 2.6.13, latest unstable fglrx (have tried all versions), and latest stable xorg. I have an amd64 processor but a 32bit system (x86). My video card is an x800 xt and my mobo is k8n neo2 platinum by MSI (nvidia nforce3 chipset). There is a forum post in which someone else with an x800 xt radeon and my mobo also has an identical problem. I can send config files and help debug is someone needs.
I've had the same problem with an HP zv6000. Using the instructions on the Gentoo Hardware wiki (http://www.google.com/url?sa=t&ct=res&cd=1&url=http%3A//gentoo-wiki.com/HARDWARE_Gentoo_Linux_64bit_on_HP_Pavilion_zv6000_series_notebook&ei=1BbpQ6eGMqessgGBh5XaAQ&sig2=E0kSC-bwRfOK5Wxp3behZA) doesn't work on my box. From much Googling and looking around, you have to hit just the right combination of kernel/xorg/ati-drivers/fglrx.ko Certainly nothing that you can rely on for a regular box that doesn't require a great deal of maintenance.
My machine is a HP Pavilion ZV6069EA. I discovered that to make 3d works you have to disable sideport memory in the bios and enabling UMA. This is only a workaround and a bad one, since everything run slower...
So far, that BIOS trick hasn't worked for me. But it does make the machine run slower.
Try setting Option "ColorTiling" "false" in the video card driver section. I can't recall if this is just an open-source option or if it works for the binaries too.
Some users have reported that the latest version of ATI's drivers (8.32.5) may fix this issue. YMMV.
Dead bug, assuming fixed in up-to-date ati-drivers. If not, you should complain upstream because we can't fix binary stuff anyway.
Well, I can't check it anymore, because my laptop with ATI cards was stolen 10 months ago :-( I now own a laptop with NVidia card, so I can't be useful anymore for this bug.
