I just upgraded gnome and as a result of that, xfree also upgraded from 4.2.1-r2 to 4.3.0-r5. After a xf86config and startx, I get a fatal server error. I use a Matrox Millennium (2MB) with an AcerView 33 monitor (31.468 - 38 kHz, 45 - 90 Hz) Reproducible: Always Steps to Reproduce: 1. emerge xfree 2. xf86config 3. startx Actual Results: Elf_RelocateEntry() Unsupported relocation type 10 (WW) MGA: No matching Device section for instance (BusID PCI:0:11:0) found (EE) No devices detected. Fatal server error: no screens found When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file "/var/log/XFree86.0.log". Please report problems to xfree86@xfree86.org. XIO: fatal IO error 54 (Connection reset by peer) on X server ":0.0" after 0 requests (0 known processed) with 0 events remaining. I will attach /var/log/XFree86.0.log below... Expected Results: succesfull start of the X server Gentoo Base System version 1.4.3.13 Portage 2.0.50-r1 (default-alpha-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.4.24) ================================================================= System uname: 2.4.24 alpha EV4 distcc 2.12.1 alpha-unknown-linux-gnu (protocols 1 and 2) (default port 3632) [disabled] ccache version 2.3 [enabled] Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.7.8 ACCEPT_KEYWORDS="alpha" AUTOCLEAN="yes" CFLAGS="-O2 -pipe " CHOST="alpha-unknown-linux-gnu" COMPILER="gcc3" CXXFLAGS="-O2 -pipe " FEATURES="ccache" MAKEOPTS="-j2" USE="X alpha berkdb cdr crypt cups encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 imlib jpeg libg++ libwww mikmod motif mozilla ncurses oggvorbis opengl oss pam pdflib perl png python quicktime readline sdl slang ssl tcpd truetype xml2 xmms xv zlib"
Created attachment 27740 [details] /var/log/XFree86.0.log
Created attachment 27741 [details] /etc/X11/XF86Config This file is created after configuring with xf86config
Hi Evert, the Elf_RelocateEntry() messages are unrelated to the problem you're seeing. You're XF86Config is not correct since there isn't a Device section for the Matrox card in the system. You should read http://www-106.ibm.com/developerworks/edu/os-dw-linuxxwin-i.html which will help you configure your X server.
Actually, there is a device section for my matrox: Section "Device" Identifier "Matrox Millennium 2MB" Driver "mga" #VideoRam 2048 VideoRam 2048 # Insert Clocks lines here if appropriate EndSection which is used from: Section "Screen" Identifier "Screen 1" Device "Matrox Millennium 2MB" Monitor "AcerView 33" [...cut...] EndSection which is used from: Section "ServerLayout" Identifier "Simple Layout" Screen "Screen 1" InputDevice "Mouse1" "CorePointer" InputDevice "Keyboard1" "CoreKeyboard" EndSection and the url didn't help me further...
Created attachment 27806 [details] /var/log/XFree86.0.log (with BusID in /etc/X11/XF86Config) I compared the XF86Config I used with xfree-4.2.1-r2 with the one I now use. The actual difference is in Section "Module": Load "freetype" vs. Load "speedo". I also tried XF86Config which works for 4.2.1-r2 with no luck. After some google on internet I decided to add the BusID option to Section "Device" like this: Section "Device" Identifier "Matrox Millennium 2MB" #Chipset "mga2064w" Driver "mga" BusID "PCI:0:11:0" VideoRam 2048 # Insert Clocks lines here if appropriate EndSection Now X does start, but it takes 3 MINUTES to start. With xfree-4.2.1-r2, starting X took about 15 seconds, so there's definitely something wrong with xfree-4.3.0-r5. Commenting in or out the Chipset option makes no difference (like expected). Normally the BusID option should not be necessary with only one gfx-card and it should not take 3 MINUTES for X to start!
Try commenting out the VideoRam line.
Chipset option and VideoRam option both make no difference. Without BusID it doesn't start at all (Fatal server error: no screens found) Option "NoDDC" reduced startuptime to 1 minute, still a long time but already better than 3 minutes without the NoDDC option... So the section now looks like this: Section "Device" Identifier "Matrox Millennium 2MB" #Chipset "mga2064w" Driver "mga" BusID "PCI:0:11:0" #VideoRam 2048 Option "NoDDC" # Insert Clocks lines here if appropriate EndSection
I've been reading the man page a little (man mga), seems if you have a millenium II you _should_ specify VideoRam, otherwise not.
Well, this is a Matrox Millennium, so no need to specify VideoRam. To trace what takes so long, I created a little perl script which adds date + time to the log. To be able to start the command I did a remote login to the alpha from another gentoo system. After that I did the following: local: startx remote (1 second later): tail -f -n 1000 --retry /var/log/XFree86.0.log |./add_date.pl This shows what takes so long (without Option "NoDDC"): Tue Mar 23 11:19:07 2004 (II) unmapVidMemSparse: unmapping Base 0x2ff01200000 Size 0x8000 Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA BIOS detected Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA VBE Version 2.0 Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA VBE Total Mem: 2048 kB Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA VBE OEM: Matrox Graphics Inc. Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA VBE OEM Software Rev: 1.5 Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA VBE OEM Vendor: Matrox Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA VBE OEM Product: MILLENNIUM Tue Mar 23 11:19:54 2004 (II) MGA(0): VESA VBE OEM Product Rev: 00 Tue Mar 23 11:19:54 2004 (II) Loading sub module "ddc" Tue Mar 23 11:19:54 2004 (II) LoadModule: "ddc" Tue Mar 23 11:19:54 2004 (II) Reloading /usr/X11R6/lib/modules/libddc.a Tue Mar 23 11:20:52 2004 (II) MGA(0): VESA VBE DDC supported Tue Mar 23 11:20:52 2004 (II) MGA(0): VESA VBE DDC Level none Tue Mar 23 11:20:52 2004 (II) MGA(0): VESA VBE DDC transfer in appr. 0 sec. Tue Mar 23 11:21:51 2004 (II) MGA(0): VESA VBE DDC read failed Tue Mar 23 11:21:51 2004 (II) unmapVidMemSparse: unmapping Base 0x2ff000a0000 Size 0x20000 With Option "NoDDC", startuptime is a lot better: Tue Mar 23 11:26:07 2004 (II) unmapVidMemSparse: unmapping Base 0x2ff01200000 Size 0x8000 Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA BIOS detected Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA VBE Version 2.0 Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA VBE Total Mem: 2048 kB Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA VBE OEM: Matrox Graphics Inc. Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA VBE OEM Software Rev: 1.5 Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA VBE OEM Vendor: Matrox Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA VBE OEM Product: MILLENNIUM Tue Mar 23 11:26:53 2004 (II) MGA(0): VESA VBE OEM Product Rev: 00 Tue Mar 23 11:26:53 2004 (II) Loading sub module "ddc" Tue Mar 23 11:26:53 2004 (II) LoadModule: "ddc" Tue Mar 23 11:26:53 2004 (II) Reloading /usr/X11R6/lib/modules/libddc.a Tue Mar 23 11:26:53 2004 (II) unmapVidMemSparse: unmapping Base 0x2ff000a0000 Size 0x20000 It looks like it takes 46 seconds before it detects VESA BIOS. And without NoDDC it takes almost 2 minutes before it knows it can't read DDC. I will attach the full outputs below.
Created attachment 27843 [details] time added to XFree86.0.log (with BusID, without NoDCC)
Created attachment 27844 [details] time added to XFree86.0.log (with BusID, with NoDCC)
I also see the RelocateEntry error - but on an xorg-x11 build on Alpha. My failure mode is however different (on a tdfx)
This issue exists in Xorg-X11-6.8 as well. I found the following patch while googling the problem. No idea if it made it upstream or not before the project forked from XFree86. http://groups.google.com/groups?q=Elf_RelocateEntry()+Unsupported+relocation+type+10&hl=en&lr=&ie=UTF-8&selm=1sKRQ-2iH-1531%40gated-at.bofh.it&rnum=1
Just compiled and tested xfree-4.3.0-r7, nothing changed, still loads of "Elf_RelocateEntry() Unsupported relocation type 10" msgs. Startuptime however is somewhat better, it was 60 seconds with r5, is now 50 seconds, wow!!! ;-) With xfree-4.2 I had startuptime of about 15 seconds, but well, that one disappeared from portage...
I just updated from a working xorg 6.7 to xorg-6.8.1.901 on my PPC (Pegasos2 with ATI Radeon 9200 SE) and it no longer starts - complaing about unsupported relocations type 18 and 23. It throws the error messages during the loading of the module bitmap. Sending a SIGTERM to startx leaves a xinit and a X process in the background. Only killable with SIGKILL. I recompiled without stack-protector (just out of curiosity) but that didn't solve the problem. So I retried again (whew, xorg takes way too long to compile... :-/ ) - this time without the hardened useflag. I will report back (if I don't forget it ;-) ).
Please also try USE=dlloader. Re comment #13, the fix for "type 10" relocations on Alpha was committed to Xorg HEAD on November 9: https://bugs.freedesktop.org/show_bug.cgi?id=1765 But unfortunately that will have no effect on PPC (comment #15). I'll see what I can do about getting it into 6.8.2 though.
Thanks for comment #16. I just tried a fresh compile of xorg-x11-6.8.1 with CFLAGS="-O2 -mtune=G4 -maltivec -mabi=altivec -fno-strict-aliasing -pipe" and the USE flag for xorg was set to (using emerge -pvv) USE="font-server ipv6 minimal nls opengl pam truetype-fonts xprint xv" It didn't work. Now I will try it as you suggested with ld-linux as loader. Stay tuned... ;-)
This bug is about xfree/xorg elf loader issues on alpha which is solved now. Please file a new bug if the issues persist on ppc.
OK, I will. Thanks and a happy new year!
