Red Hat Bugzilla – Bug 468015
Running nautilus on Altix IA64 causes system to hang
Last modified: 2010-10-23 01:21:00 EDT
Description of problem:
On Altix IA64 with FireMV 2200 graphics running
RHEL5.2-Snapshot1, starting nautilus causes the
system to hang. If nautilus is disabled in
/usr/share/gnome/default.session, the gnome
desktop runs without any problems. When run with
the --no-desktop option, there is no problem
either. However, even without the gnome desktop
(just using 'xinit' to start the X server with
an xterm and no window manager), running nautilus
without any options prints the following and
causes the system to hang:
Initializing nautilus-open-terminal extension
** (nautilus:4557): WARNING **: Can not caclulate _NET_NUMBER_OF_DESKTOPS
** (nautilus:4557): WARNING **: Can not calculate _NET_NUMBER_OF_DESKTOPS
** (nautilus:4557): WARNING **: Can not get _NET_WORKAREA
** (nautilus:4557): WARNING **: Can not determine workarea, guessing at layout
Supporting Materials: This issue was initially held up by bug 448139 (fixed in RHEL 5.3). Now that we've provided them with test packages, they were able to do a bit of debugging (see https://enterprise.redhat.com/issue-tracker/?module=issues&action=view&tid=170845&gid=707&view_type=lifoall#eid_2361662 ). If a sysreport is required let me know and I'll get one, but they seem to have narrowed it down.
Requested Action from SEG: Fix/Escalate. I'd like to generate a release note for 5.3, so a bugzilla sooner rather than later would be appreciated!
Steps to Reproduce:
Run 'xinit' to start the X server with just an
xterm and no window manager, then run 'nautilus'.
System hangs without any error messages,
nautilus and window system run normally.
Event posted 09-23-2008 05:57pm EDT by jlim-sgi
I've narrowed the problem down:
#0 fbBlt (srcLine=0x2000000005807800, srcStride=5120, srcX=0,
dstLine=0x600000000033fcf0, dstStride=5120, dstX=0, width=5120,
height=1024, alu=3, pm=4294967295, bpp=32, reverse=0, upsidedown=0)
#1 0x2000000004ffadf0 in fbCopyNtoN (pSrcDrawable=0x60000000002f7e10,
pbox=0x60000fffffc3f0f0, nbox=0, dx=0, dy=1030, reverse=0, upsidedown=0,
bitplane=0, closure=0x0) at fbcopy.c:85
#2 0x2000000004ffdfa0 in fbCopyRegion (pSrcDrawable=0x60000000002f7e10,
pDstRegion=0x60000fffffc3f0f0, dx=0, dy=1030, copyProc=0x2000000000a81940,
bitPlane=0, closure=0x0) at fbcopy.c:394
#3 0x2000000004fff410 in fbDoCopy (pSrcDrawable=0x60000000002f7e10,
pDstDrawable=0x6000000000301d30, pGC=0x6000000000214510, xIn=0, yIn=1030,
widthSrc=1280, heightSrc=1024, xOut=0, yOut=0, copyProc=0x2000000000a81940,
bitPlane=0, closure=0x0) at fbcopy.c:594
#4 0x2000000004fff960 in fbCopyArea (pSrcDrawable=0x60000000002f7e10,
pDstDrawable=0x6000000000301d30, pGC=0x6000000000214510, xIn=0, yIn=0,
widthSrc=1280, heightSrc=1024, xOut=0, yOut=0) at fbcopy.c:632
#5 0x20000000050d3c80 in XAACopyAreaPixmap (pSrc=0x60000000002f7e10,
pDst=0x6000000000301d30, pGC=0x6000000000214510, srcx=0, srcy=0,
width=1280, height=1024, dstx=0, dsty=0) at xaaGC.c:400
#6 0x40000000004dd4f0 in cwCopyArea (pSrc=0x60000000002f7e10,
pDst=0x6000000000301d30, pGC=0x6000000000214510, srcx=0, srcy=0, w=1280,
h=1024, dstx=0, dsty=0) at cw_ops.c:202
#7 0x40000000004c3d60 in damageCopyArea (pSrc=0x60000000002f7e10,
pDst=0x6000000000301d30, pGC=0x6000000000214510, srcx=0, srcy=0,
width=1280, height=1024, dstx=0, dsty=0) at damage.c:790
#8 0x200000000515ff80 in XAAMoveOutOffscreenPixmap (pPix=0x60000000002f7e10)
#9 0x200000000515f8d0 in XAARemoveAreaCallback (area=0x60000000002fe170)
#10 0x20000000050cf580 in XAAValidateGC (pGC=0x60000000002c9600,
changes=8388607, pDraw=0x600000000031f8b0) at xaaGC.c:104
#11 0x40000000004d6660 in cwValidateGC (pGC=0x60000000002c9600,
stateChanges=8388607, pDrawable=0x600000000031f8b0) at cw.c:166
#12 0x40000000004bdcc0 in damageValidateGC (pGC=0x60000000002c9600,
changes=8388607, pDrawable=0x600000000031f8b0) at damage.c:410
#13 0x40000000000f4e30 in ValidateGC (pDraw=0x600000000031f8b0,
pGC=0x60000000002c9600) at gc.c:79
#14 0x40000000000a3300 in ProcPolyFillRectangle (client=0x6000000000293ef0)
#15 0x4000000000091c70 in Dispatch () at dispatch.c:459
#16 0x400000000003b400 in main (argc=1, argv=0x60000fffffc3fc78,
envp=0x60000fffffc3fc88) at main.c:447
46 fbBlt (FbBits *srcLine,
85 CARD8 *src = (CARD8 *) srcLine;
96 memcpy(dst + i * dstStride, src + i * srcStride, width);
The hang occurs in memcpy(); src appears to be out of bounds.
Xorg uses XAA for acceleration by default. To prevent the hang, one of
the following entries may be specified in the "Device" section (for the
Radeon driver) in /etc/X11/xorg.conf:
Option "NoAccel" "on"
Option "AccelMethod" "EXA"
David: can you open a BZ against Xorg? Thanks.
Waiting on sysreport.
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being proposed as a blocker for this release.
Please resolve ASAP.
Created attachment 322809 [details]
console excerpt and Xorg.0.log from using Dave's ATI driver
> Okay lets concentrate on the nautilius issue, I don't have access to IT so I'll
> have to get someone to attach that unless there is another bz open for it.
> What I'm getting right now, is that out of the box with XAA, it works except
> for Nautilus crashes everything? This must be one of the accel operatrions
> EXA isn't going to be supported at present, NoAccel is probably interesting to
> track down.
> Can someone try the packages from:
> with XAA to see it goes away?
The above is from BZ 448139. I installed the package and ran 'startx' with XAA enabled by default, but it didn't work: the machine hung while nautilus was starting. I set NoAccel and tried again but got the same result.
can we try Option "XAANoOffscreenPixmaps" "true"
(In reply to comment #4)
> can we try Option "XAANoOffscreenPixmaps" "true"
Okay, that works: nautilus isn't causing the machine to hang anymore.
Also, I can open a terminal window and move it around without causing
a hang as described in BZ 448139; it also works when running only xinit
I'm doing a server build at the moment that might potentially fix this properly
If this could get tested ASAP on the Altix without the XAANoOffscreenPixmaps workaround in place.
(In reply to comment #6)
> I'm doing a server build at the moment that might potentially fix this properly
> If this could get tested ASAP on the Altix without the XAANoOffscreenPixmaps
> workaround in place.
I reverted to the RHEL5.3-Snapshot1 xorg-x11-drv-ati and installed the following
from the location above:
I also commented out XAANoOffscreenPixmaps in xorg.conf.
The system hung just as the desktop was coming up when I ran 'startx'.
Devel ack, should just turn off offscreen pixmaps on altix.
(In reply to comment #7)
> I reverted to the RHEL5.3-Snapshot1 xorg-x11-drv-ati and installed the
> following from the location above:
> I also commented out XAANoOffscreenPixmaps in xorg.conf.
> The system hung just as the desktop was coming up when I ran 'startx'.
In addition to the above, I installed xorg-x11-drv-ati-6.6.3-3.20.el5 and graphics came up fine.
Jonathan, can you retest with snap6 when it comes out and report you results.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.