Bug 679105

Created attachment 418970 [details]
Xorg.0.log

Please try without KMS as mentioned in our release notes. Does that fix the issue?

Hi Stefan

As mentioned in the bug report I tried failsafe boot which also disables KMS by setting nomodeset. This doesn't help to prevent the freeze.

What I forgot to mention: It's a laptop NX6125.

Do you have other suggestions?

Hmm. Failsafe boot means fbdev driver instead of radeon UMS driver. That would rule out a X driver problem.

Tried to verify failsave boot and did complete fresh OpenSuSE 11.4 final reinstall. With failsave or nomodeset I get crash in the x-server:

Backtrace:
[    30.354] 0: /usr/bin/Xorg (xorg_backtrace+0x37) [0x80ee5f7]
[    30.354] 1: /usr/bin/Xorg (0x8048000+0x5cbea) [0x80a4bea]
[    30.354] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xffffe410]
[    30.354] Segmentation fault at address (nil)
[    30.354]
Fatal server error:
[    30.354] Caught signal 11 (Segmentation fault). Server aborting

Created attachment 419057 [details]
Xorg.0.log with nomodeset crash

X Server log after starting with kernel command line:

root=/dev/disk/by-id/ata-ST9808211A_3LF1YF4P-part6 resume=/dev/disk/by-id/ata-ST9808211A_3LF1YF4P-part2 splash=silent quiet vga=0x342 nomodeset

I'm seeing the same problem. My hardware is:

IBM Thinkpad R51e, 1.5GHz Celeron, 512M RAM, ATI Xpress 200M. 

I tried booting with nomodeset, but that only disabled the GUI altogether.

Markus, I would like to see the X logfile for failsafe boot entry. It sounds weird for me that also fbdev crashes X.

Per, could you add your X logfile as well?

Willdo. Quick additional comment - at first I also thought it was firefox and/or openoffice related, but I've just now got hung up when I started k3b.

Created attachment 419094 [details]
Xorg.0.log from thinkpad r51e

(In reply to comment #10)
> Created an attachment (id=419094) [details]
> Xorg.0.log from thinkpad r51e

[    25.907] (II) RADEON(0): Direct rendering enabled

Apparently you've attached the wrong logfile. Please attach the one when booting with 'nomodeset'.

Created attachment 419212 [details]
init log

Hi Stefan
Just tried to record xorg.log in failsafe mode.
But x isn't starting at all and thus there's no xorg.0.log.
Trying to start kdm from console mode shows that there is a failsafe configuration file missing.

(In reply to comment #12)
> Created an attachment (id=419212) [details]
> init log

> The failsafe X.Org configuration /etc/X11/xorg.conf.install no longer exists.
> Either move it back (if still available) or copy /etc/X11/xorg.conf to
> /etc/X11/xorg.conf.install to use the native graphics driver instead of the
> failsafe graphics driver. Of course the latter option no longer can be called
> failsafe.

Hmm. Did you remove /etc/X11/xorg.conf.install ?!?

For sure I didn't delete it manually. Its fresh install from KDE Live CD with updates (installation of remaining packages as suggested by Yast) via network. In the Yast's runlevel editor I disabled virtualbox and vmware tools.

(In reply to comment #14)
> For sure I didn't delete it manually. Its fresh install from KDE Live CD with
> updates (installation of remaining packages as suggested by Yast) via network.
> In the Yast's runlevel editor I disabled virtualbox and vmware tools.

Ok. I guess when doing a LiveCD installation there is no /etc/X11/xorg.conf.install created on the installed system since already the Live system runs without any xorg.conf in place. Its different with a real installation. There
we have a fbdev driver based configuration with xorg.conf in place which is copied
to /etc/11/xorg.conf.install during installation as fallback and for the failsafe
mode.

And that's just because of the installation medium? No matter whether doing installation from boot prompt or from running live system.

I suppose failsafe was working in one of the previous milestones/RCs.

Is /etc/11/xorg.conf.install part of a rpm package which could be installed?

(In reply to comment #16)
> And that's just because of the installation medium? 

That's my understanding, yes.

> No matter whether doing installation from boot prompt or from running live 
> system.

?
 
> I suppose failsafe was working in one of the previous milestones/RCs.

Is that a claim or a question? I doubt that this ever worked with a LiveCD
installation.

> Is /etc/11/xorg.conf.install part of a rpm package which could be installed?

No, it's generated on the fly during a regular installation.

>> No matter whether doing installation from boot prompt or from running live 
>> system.

>?

I mean even if LiveCD I have the choice between starting the installation from the grub boot prompt as well as from the running desktop.

>Is that a claim or a question? I doubt that this ever worked with a LiveCD
>installation.

It's a strong guess. I'm sure I booted failsafe in the last couple of weeks, but can't remember what version it was, it could be even 11.3. However, I always used KDE CDs the last years for installation.

(In reply to comment #18)
> >> No matter whether doing installation from boot prompt or from running live 
> >> system.
> 
> >?
> 
> I mean even if LiveCD I have the choice between starting the installation from
> the grub boot prompt as well as from the running desktop.

Ok. Understood. I didn't know that a LiveCD installation is also possible from
the grub boot prompt.
 
> >Is that a claim or a question? I doubt that this ever worked with a LiveCD
> >installation.

> It's a strong guess. I'm sure I booted failsafe in the last couple of weeks,
> but can't remember what version it was, it could be even 11.3. However, I
> always used KDE CDs the last years for installation.

Ok. Maybe the LiveCD installation did change since openSUSE 11.3.

>> I mean even if LiveCD I have the choice between starting the installation from
>> the grub boot prompt as well as from the running desktop.

>Ok. Understood. I didn't know that a LiveCD installation is also possible from
>the grub boot prompt.

And the installation from grub was definitely what I did.

Well, what possibilities exist of getting this failsafe configuration back?

(In reply to comment #20)
> Well, what possibilities exist of getting this failsafe configuration back?

I suggest to open a seperate bugreport filed against YaST component to request this file back.

I check bugzilla and found there is already bug 664308 reported about the failsafe problem.

Is there anything that can be done about the x-server crash with nomodeset?
So far I installed the debug symbols of the x-server but call stack is still not resolved.

Markus, unfortunately I can't help you at the moment. Additionally we no longer have any Xpress 200M graphics hardware available for testing.

OpenSuSE 11.4 is too nice to give up so early :-)

I started the x-server in the debug mode and got finally a reasonable callstack:

Program received signal SIGSEGV, Segmentation fault.
0x00000000 in ?? ()
(gdb) bt
#0  0x00000000 in ?? ()
#1  0xad16b226 in ?? () from /usr/lib/dri/r300_dri.so
#2  0xb7a78050 in __glXDRIscreenProbe (pScreen=0x8263380) at glxdri.c:1131
#3  0xb7a6f278 in GlxExtensionInit () at glxext.c:377
#4  0x080d0ea5 in InitExtensions (argc=1, argv=0xbffff664) at ../../../mi/miinitext.c:553
#5  0x080666f2 in main (argc=1, argv=0xbffff664, envp=0xbffff66c) at main.c:213
(gdb)

I'll try to install debug symbols for the shared dri library to get more information about the root of the problem.

It looks like the x server is failing to talk with the dri driver:


    psp->api_mask = (1 << __DRI_API_OPENGL);

->  *driver_modes = driDriverAPI.InitScreen(psp);
    if (*driver_modes == NULL) {
        free(psp);
        return NULL;
    }


(gdb) bt
#0  0x00000000 in ?? ()
#1  0xad16b226 in driCreateNewScreen (scrn=0, ddx_version=0xbffff3f8, dri_version=0xbffff3ec,
    drm_version=0xbffff3e0, frame_buffer=0xbffff3c4, pSAREA=0xb77ff000, fd=18, extensions=0xb7aa04c4,
    driver_modes=0xbffff404, loaderPrivate=0x82a1520) at ../common/dri_util.c:830
#2  0xb7a78050 in __glXDRIscreenProbe (pScreen=0x8263380) at glxdri.c:1131
#3  0xb7a6f278 in GlxExtensionInit () at glxext.c:377
#4  0x080d0ea5 in InitExtensions (argc=1, argv=0xbffff624) at ../../../mi/miinitext.c:553
#5  0x080666f2 in main (argc=1, argv=0xbffff624, envp=0xbffff62c) at main.c:213
(gdb) print driDriverAPI
$5 = {InitScreen = 0, DestroyScreen = 0xad16f1a0 <dri_destroy_screen>,
  CreateContext = 0xad16e2d0 <dri2_create_context>, DestroyContext = 0xad16ed70 <dri_destroy_context>,
  CreateBuffer = 0xad16e260 <dri2_create_buffer>, DestroyBuffer = 0xad16fbb0 <dri_destroy_buffer>,
  SwapBuffers = 0, MakeCurrent = 0xad16ee70 <dri_make_current>, UnbindContext = 0xad16ede0 <dri_unbind_context>,
  GetSwapInfo = 0, WaitForMSC = 0, WaitForSBC = 0, SwapBuffersMSC = 0, CopySubBuffer = 0, GetDrawableMSC = 0,
  InitScreen2 = 0xad16e0b0 <dri2_init_screen>}
(gdb)

Is the x-server allowed to use dri with nomodeset?

Created attachment 419540 [details]
Full callstack

> Is the x-server allowed to use dri with nomodeset?

Well, for some reason radeon UMS behaves here differently than radeon KMS. A workaround would be to disable DRI completely in X by adding

Section "Module"
  Disable "dri"
  Disable "dri2"
EndSection

to /etc/X11/xorg.conf.d/50-device.conf. Of course then everything falls back to
software rendering, but that's still better than a crashing Xserver already
during startup.

> Section "Module"
>   Disable "dri"
>   Disable "dri2"
> EndSection

This works around x-server crash with nomodeset successfully. 

Checking stability now...

That's just another duplicate.

*** This bug has been marked as a duplicate of bug 678264 ***