Created attachment 13601 [details]
Xorg log with logverbose 7

Log file recording what happened when I tried to change the resolution.

Hm. Both outputs are switched off, then CrtcResize is called, then the Xserver crashes deep inside RandR.

Can you install debuginfo packages (or an Xserver with debugging information embedded) and try to produce a reasonable stacktrace with gdb? (see bug 12907 how to do that without remote connection)

Bugzilla Upgrade Mass Bug Change

NEEDSINFO state was removed in Bugzilla 3.x, reopening any bugs previously listed as NEEDSINFO.

  - benjsc
    fd.o Wrangler

Ubuntu has an "xserver-xorg-core-dbg" package that "provides debugging symbols for the Xorg X sever and associated modules". Is this equivalent to the debuginfo packages?

bug 12907 has a script that directs gdb to start X, do a backtrace, and save the output. This script does not work for me, because /usr/bin/Xorg just brings up a screen with black and white zig zags and a black "X" cursor. I can move the cursor around, but I can't start KDE or exit from Xorg. (And I need to do a resize to trigger this bug.)

When I edited the script so that gdb called startx or xinit instead of directly calling Xorg, the output files were empty.

(In reply to comment #4)
> Ubuntu has an "xserver-xorg-core-dbg" package that "provides debugging symbols
> for the Xorg X sever and associated modules". Is this equivalent to the
> debuginfo packages?

I have *no* idea, I never ever installed Ubuntu. But it sounds reasonable.

> bug 12907 has a script that directs gdb to start X, do a backtrace, and save
> the output. This script does not work for me, because /usr/bin/Xorg just brings
> up a screen with black and white zig zags and a black "X" cursor. I can move
> the cursor around, but I can't start KDE or exit from Xorg. (And I need to do a
> resize to trigger this bug.)

Use it with
xf86debug & sleep 2 && DISPLAY=:0 kde

Alternatively, change /var/X11R6/bin/X (a symlink) to this script.

> When I edited the script so that gdb called startx or xinit instead of directly
> calling Xorg, the output files were empty.

Yes, it has to call Xorg directly, otherwise the debugger would watch on the wrong Xserver.

Created attachment 13770 [details]
gdb output 01

Here's the output of gdb, as created by running the xf86debug script.

I didn't have a program named "kde", so I instead used "kdesktop". This just started up the wallpaper, but I was able to right-click on it to get a context menu with a "Run Command" option. That allowed me to call "xrandr --size 800x600".

The command I used to start the xf86debug script:
xf86debug & sleep 2 && DISPLAY=:0 kdesktop

The core file from gdb, as created by the xf86debug script, was too large to upload here, so I put it up on my own web space:
http://jamesjustinharrell.com/core01.tar.bz2

Is it supposed to be that large? (287.9 MB uncompressed)

For the future: it helps a lot if the driver is compiled with "-O0 -g3" instead of "-O2 -g" (the default). 'make CFLAGS="-O0 -g3" does the trick (alternatively, './configure CFLAGS="-O0 -g3"' and just make afterwards). In this case it wouldn't help, because you're crashing deep inside RandR.

Yes, core files can be such large. Especially with the Xserver, the core file might contain the whole mapped memory (including graphics memory).


Ok, as you invoked xrandr with --size, some notes:

xrandr --size (or -s) is RandR 1.1 . You shouldn't use it with a RandR 1.2 capable driver. The command to change the resolution is 'xrandr --output <outname> --mode <modename>'. Please test. That said, all user interface tools ATM use RandR 1.1 commands.

RandR 1.1 commands shouldn't crash the Xserver (and they don't for me), but it seems that this is not a bug in the driver, but in the RandR implementation (no driver function is involved in your backtrace). Can you try a newer Xserver?

Emmes,

I'm not sure what the state of this bug is? 

Is there an interaction issue with xf86VidMode, or is this a wontfix?

I'm unsure, but since there hasn't been a reply about verification with a newer Xserver since January and I haven't seen anyone else with the same error description, I'd assume this is fixed in newer Xserver versions.

1.3.0 was known to have some errors with RandR (all SuSE Xserver are quite heftily patched, so don't even try to compare ;-).

I've upgraded from Kubuntu 7.10, which uses X.Org Server 1.3, to Kubuntu 8.04, which uses X.Org Server 1.4. I can now change the resolution (using either the RandR 1.1 and RandR 1.2 interfaces) without problem.

Shouldn't the resolution for this bug be "notourbug" instead of "fixed" since the problem was not in the RadeonHD driver?

Yes, it should. Nevertheless, it's fixed ;)