Hi Leonard, first of all thank you for having reported this issue, secondly congrats for having discovered a real driver related crash (radeonhd_drv.so) ::
Excerpt from the bottom of http://www.onebeam.net/xwin/Xorg-conf.new.log /* II) LoadModule: "shadow" (II) Loading /usr/X11/lib/modules//libshadow.so (II) Module shadow: vendor="X.Org Foundation" compiled for 1.3.0, module version = 1.1.0 ABI class: X.Org ANSI C Emulation, version 0.3 (II) RADEONHD(0): Using ShadowFB Backtrace: 0: /usr/X11/bin/i386/Xorg'xf86SigHandler+0x84 [0x80f8d74] 1: /lib/libc.so.1'__sighndlr+0xf [0xceaef5ff] 2: /lib/libc.so.1'call_user_handler+0x2b8 [0xceae44bb] 3: /usr/X11/bin/i386/Xorg'xf86InitViewport+0x91 [0x80f2f31] Fatal server error: Caught signal 11. Server aborting */ So, for an unknown reason (only somebody with exactly your hardware, most notably including yourself, can help resolving this) Xorg gets a SIGSEGV somewhere either directly in function xf86InitViewport(), or in a subsequent call. To resolve this we need a more detailed analysis with /opt/SUNWspro/bin/dbx, or, more favorably, with mdb. Look what's on the stack at crash time. Try to figure out which function has been called the very last moment before something went wrong. Then find out why this lead to signal 11. Disassemble the last instruction (from inside the debugger). Solutions potentially include different, additional, removed compiler flags or -D defines. Otherwise type related fixes somewhere inside the radeonhd driver or even outside. START HERE: http://blogs.sun.com/comand/entry/learn_mdb_in_30_minutes http://solaristhings.blogspot.com/2006/08/dont-be-afraid-of-mdb.html . A few comments regarding your (other) log files in general: 0) http://www.onebeam.net/xwin/Xorg-autoprobe.log --->> the vesa_drv.so driver has been chosen for use. Therefore X11 boots up and you don't get above crash. 1) http://www.onebeam.net/xwin/Xorg-conf.new.log --->> "Xorg -configure" has succeeded in creating the best match for your config. It has detected from your fb's pciid, that the new radeonhd_drv.so driver should be used. It the starts initializing RADEONHD and you get above SIGSEGV. 2) http://www.onebeam.net/xwin/Xorg-xorgconfig.log --->> During manual configuration via /usr/X11/bin/xorgconfig you have indirectly chosen to use the older radeon_drv.so driver. This driver doesn't work with your new Radeon Mobility X1400 rev 0 frame buffer. Your only options are vga_drv.so (4bpp colors only, no accel, nothing), vesa_drv.so (24bpp or 32bpp colors, but no acceleration) or, and here it comes: radeonhd_drv.so, which doesn't work on your machine right now. Therefore radeon_drv.so reports, that no screens have been found and Xorg quits without a crash, but also without having booted X up. FYI: There is a readability problem of your log files if they are being opened up inside Firefox2 on Indiana x86 (the only thing I tested, as I'm currently sitting in front of this). I see you're running Sun Java System Application Server 9.1, probably on Solaris. At first I thought this is a typical dos2unix related problem. But after I downloaded your log-files to my (Solaris-) hdd, everything looked corerct again, whether with a pager, or gedit. This must be a bug either In the FF-copile shipping as part of Indiana, or it is related to Sun Java System Application Server 9.1 (rather unlikely). Can you provide ssh access to your Xorg box? Or could you please send this list a more detailed backtrace? p.s. As interim Solution I recommend you that you create a /etc/X11/xorg.conf where you define "vesa" as driver to use, and set the screen settings correspondingly (to what your monitor works best with). I recommend you do this with xorgconfig again. Or just take a copy from xorg.conf.new and replace "radeonhd" with "vesa" and manually adjust the resolution. -- %martin
