Bug#575585: xserver-xorg-video-radeon: [KMS] Crashes when switching VTs
On Sun, 2010-04-04 at 08:31 +0200, Josselin Mouette wrote: Le vendredi 02 avril 2010 à 11:44 +0200, Michel Dänzer a écrit : After a few more tries, I’m a bit disappointed. The crash has gone, sure, but after a bit of juggling with several X servers, new X servers still refuse to start with the same error as before. Please provide the log files from both servers. Here you go. Further notes: the first X server will display a black screen as soon as you try to run the second. The cursor is still visible, can be moved and clicked… everything seems to behave normally except the display is black. Can the first X server be recovered with something like xgamma -gamma 1.0? There's a known bug where the hardware CLUT doesn't get properly restored after a VT switch. (EE) RADEON(0): [drm] failed to set drm interface version. (EE) RADEON(0): Kernel modesetting setup failed (II) UnloadModule: radeon (EE) Screen(s) found, but none have a usable configuration. Hmm, not sure why that would fail… Can you find out what value drmSetInterfaceVersion() returns? Is there anything interesting in dmesg? BTW, did you capture Xorg.0.log after reproducing the problem? It doesn't seem to show any trace of a VT switch. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270552743.5666.282.ca...@thor.local
Bug#575585: xserver-xorg-video-radeon: [KMS] Crashes when switching VTs
On Thu, 2010-04-01 at 22:01 +0200, Josselin Mouette wrote: Le jeudi 01 avril 2010 à 21:55 +0200, Josselin Mouette a écrit : Le jeudi 01 avril 2010 à 12:19 -0700, Will Set a écrit : Hi Josselin, I omitted the x-mailing-list to reduce chatter a bit. I think if you have not already upgraded to kernel 2.6.32-4-amd64 that doing so may fix your issue.. I didn’t know there was a 2.6.32-4 kernel, it looks like it still isn’t the default - probably because it includes the libata transition. However you are right: upgrading to it seems to fix the issue for good. After a few more tries, I’m a bit disappointed. The crash has gone, sure, but after a bit of juggling with several X servers, new X servers still refuse to start with the same error as before. Please provide the log files from both servers. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1270201469.25578.60.ca...@thor.local
Bug#575585: xserver-xorg-video-radeon: [KMS] Crashes when switching VTs
Le samedi 27 mars 2010 à 14:39 +0100, Michel Dänzer a écrit :
On Sat, 2010-03-27 at 12:52 +0100, Josselin Mouette wrote:
I don’t really know how to obtain a better backtrace. I haven’t managed
to make it dump core, and using gdb directly on it prevents me from
switching VTs when the server crashes.
Usually it's best to run gdb from a remote shell.
OK here we go.
Thread 1 (Thread 0x7fefb49ce6f0 (LWP 2431)):
#0 memcpy () at ../sysdeps/x86_64/memcpy.S:191
No locals.
#1 0x7fefb08ad2aa in RADEONUploadToScreenCS (pDst=value optimized out,
x=value optimized out, y=value optimized out, w=value optimized out,
h=value optimized out, src=0xa0 Address 0xa0 out of bounds,
src_pitch=160) at ../../src/radeon_exa_funcs.c:535
pScrn = value optimized out
driver_priv = value optimized out
scratch = 0xc5cd10
dst = 0x7fefb49e5000 Address 0x7fefb49e5000 out of bounds
datatype = value optimized out
dst_domain = 32751
dst_pitch_offset = value optimized out
bpp = value optimized out
scratch_pitch = 192
r = value optimized out
i = 1
__func__ = RADEONUploadToScreenCS
#2 0x7fefb01c8222 in exaHWCopyNtoN (pSrcDrawable=value optimized out,
pDstDrawable=value optimized out, pGC=value optimized out,
pbox=0x7fffbbfdf770, nbox=0, dx=-596, dy=-527, reverse=0, upsidedown=0)
at ../../exa/exa_accel.c:527
src_stride = 160
pSrcPixmap = 0x16efbb0
pDstPixmap = 0x971c10
pSrcExaPixmap = 0x16f0ef0
src_off_x = 0
src_off_y = 0
dst_off_x = 0
dst_off_y = 0
srcregion = 0xc17a90
dstregion = 0xc6c5b0
ret = value optimized out
#3 0x7fefb01c832d in exaCopyNtoN (pSrcDrawable=value optimized out,
pDstDrawable=0x9776d0, pGC=value optimized out,
pbox=value optimized out, nbox=value optimized out, dx=-596, dy=-527,
reverse=0, upsidedown=0, bitplane=0, closure=0x0)
at ../../exa/exa_accel.c:574
No locals.
#4 0x0054cc0d in miCopyRegion (pSrcDrawable=0x16efbb0,
pDstDrawable=0x0, pGC=0xa0, pDstRegion=value optimized out, dx=-596,
dy=value optimized out, copyProc=0x7fefb01c8240 exaCopyNtoN,
bitPlane=0, closure=0xa0) at ../../mi/micopy.c:138
reverse = 40
upsidedown = 7
pbox = 0x7fffbbfdf770
nbox = 1
pboxNew1 = value optimized out
pboxNew2 = value optimized out
pboxBase = value optimized out
pboxNext = value optimized out
pboxTmp = value optimized out
#5 0x0054d11a in miDoCopy (pSrcDrawable=0x16efbb0,
pDstDrawable=0x9776d0, pGC=0x1818470, xIn=0, yIn=0,
widthSrc=value optimized out, heightSrc=40, xOut=596, yOut=527,
copyProc=0x7fefb01c8240 exaCopyNtoN, bitPlane=0, closure=0x0)
at ../../mi/micopy.c:338
prgnSrcClip = 0x0
freeSrcClip = 0
prgnExposed = value optimized out
rgnDst = {extents = {x1 = 596, y1 = 527, x2 = 636, y2 = 567},
data = 0x0}
dx = 12870
dy = 5279744
box_x1 = value optimized out
box_y1 = value optimized out
box_x2 = value optimized out
box_y2 = value optimized out
fastSrc = value optimized out
fastDst = value optimized out
fastExpose = 1
#6 0x7fefb01c6763 in exaCopyArea (pSrcDrawable=0x16efbb0,
pDstDrawable=0x9776d0, pGC=0x1818470, srcx=0, srcy=value optimized out,
width=value optimized out, height=40, dstx=596, dsty=527)
at ../../exa/exa_accel.c:598
No locals.
#7 0x004c84e8 in damageCopyArea (pSrc=0x16efbb0, pDst=0x9776d0,
pGC=0x1818470, srcx=value optimized out, srcy=value optimized out,
width=40, height=40, dstx=596, dsty=527)
at ../../../miext/damage/damage.c:949
ret = value optimized out
pGCPriv = 0x16f1770
oldFuncs = 0x7c1860
#8 0x0054763d in miDCRestoreUnderCursor (pDev=value optimized out,
pScreen=0x936180, x=value optimized out, y=527, w=40,
h=value optimized out) at ../../mi/midispcur.c:592
pBuffer = value optimized out
pSave = 0x16efbb0
pWin = 0x9776d0
#9 0x0056d809 in miSpriteRemoveCursor (pDev=0xa88a80,
pScreen=0x936180) at ../../mi/misprite.c:995
pScreenPriv = 0x949bf0
pCursorInfo = 0xa9c800
#10 0x0056eded in miSpriteReportDamage (pDamage=value optimized out,
pRegion=0x7fffbbfdfa40, closure=value optimized out)
at ../../mi/misprite.c:278
pScreen = 0x936180
pCursorInfo = value optimized out
pDev = 0xa88a80
#11 0x004c575c in damageReportDamage (pDamage=0x949c90,
pDamageRegion=0x7fffbbfdfa40) at ../../../miext/damage/damage.c:134
tmpRegion = {extents = {x1 = -10480, y1 = 168, x2 = 0, y2 = 0},
data = 0x7fefb2b0b9bc}
#12 0x004c5af6 in damageRegionAppend (pDrawable=value optimized out,
pRegion=value optimized out, clip=value
Bug#575585: xserver-xorg-video-radeon: [KMS] Crashes when switching VTs
Le jeudi 01 avril 2010 à 12:19 -0700, Will Set a écrit : Hi Josselin, I omitted the x-mailing-list to reduce chatter a bit. I think if you have not already upgraded to kernel 2.6.32-4-amd64 that doing so may fix your issue.. I didn’t know there was a 2.6.32-4 kernel, it looks like it still isn’t the default - probably because it includes the libata transition. However you are right: upgrading to it seems to fix the issue for good. Thanks, -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Bug#575585: xserver-xorg-video-radeon: [KMS] Crashes when switching VTs
Le jeudi 01 avril 2010 à 21:55 +0200, Josselin Mouette a écrit : Le jeudi 01 avril 2010 à 12:19 -0700, Will Set a écrit : Hi Josselin, I omitted the x-mailing-list to reduce chatter a bit. I think if you have not already upgraded to kernel 2.6.32-4-amd64 that doing so may fix your issue.. I didn’t know there was a 2.6.32-4 kernel, it looks like it still isn’t the default - probably because it includes the libata transition. However you are right: upgrading to it seems to fix the issue for good. After a few more tries, I’m a bit disappointed. The crash has gone, sure, but after a bit of juggling with several X servers, new X servers still refuse to start with the same error as before. -- .''`. Josselin Mouette : :' : `. `' “If you behave this way because you are blackmailed by someone, `-[…] I will see what I can do for you.” -- Jörg Schilling signature.asc Description: This is a digitally signed message part
Bug#575585: xserver-xorg-video-radeon: [KMS] Crashes when switching VTs
On Sat, 2010-03-27 at 12:52 +0100, Josselin Mouette wrote: I don’t really know how to obtain a better backtrace. I haven’t managed to make it dump core, and using gdb directly on it prevents me from switching VTs when the server crashes. Usually it's best to run gdb from a remote shell. Note that when it happens, the kernel logs something like this: Mar 27 12:38:42 tomoyo kernel: [ 199.622777] Unpin not necessary for 88007b6c2e00 ! That's harmless. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer -- To UNSUBSCRIBE, email to debian-x-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/1269697180.3981.71.ca...@thor.local
