Linux 2.6.26.3-14.fc8 Fedora 8 All code was checked out with git_xorg.sh script as of 2008-08-22. Kernel driver radeon was compiled from current git too. Compile seemed to go OK, and server startup was made with the following command line: PATH=/home/alex/xserver/bin:$PATH LD_LIBRARY_PATH=/home/alex/xserver/lib:/home/alex/xserver/lib/dri xserver/bin/xinit /usr/bin/gnome-session -- -config xorg-custom.conf Server starts up OK, but then crashes on an attempt to start compiz. Screen remains in graphics mode with background wallpaper and (unmovable) mouse cursor. However, the machine is remotely accessible via ssh. dmesg yields the following message right after the crash: [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check (reg=4540 sz=1) [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed [drm] Num pipes: 3 Last output of X server before terminating: in RADEONProbeOutputModes compiz (video) - Warn: No 8 bit GLX pixmap format, disabling YV12 image format *********************************WARN_ONCE********************************* File r300_state.c function r300SetupTextures line 1548 micro tiling enabled! *************************************************************************** drmRadeonCmdBuffer: -22 gnome-session: Fatal IO error 11 (Recurso no disponible temporalmente) on X server :0.0. ICE default IO error handler doing an exit(), pid = 9487, errno = 11 xserver/bin/xinit: connection to X server lost. waiting for X server to shut down XIO: fatal IO error 4 (Interrupted system call) on X server ":0.0" after 2466 requests (2459 known processed) with 3 events remaining. Output of lspci -v: 00:00.0 Host bridge: ATI Technologies Inc Radeon Xpress 200 Host Bridge (rev 01) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64 Memory at <ignored> (64-bit, non-prefetchable) 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge (prog-if 00 [Normal decode]) Flags: bus master, 66MHz, medium devsel, latency 99 Bus: primary=00, secondary=01, subordinate=01, sec-latency=68 I/O behind bridge: 0000e000-0000efff Memory behind bridge: fde00000-fdefffff Prefetchable memory behind bridge: d8000000-dfffffff Capabilities: <access denied> 00:11.0 IDE interface: ATI Technologies Inc 437A Serial ATA Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 23 I/O ports at ff00 [size=8] I/O ports at fe00 [size=4] I/O ports at fd00 [size=8] I/O ports at fc00 [size=4] I/O ports at fb00 [size=16] Memory at fe02f000 (32-bit, non-prefetchable) [size=512] [virtual] Expansion ROM at 40000000 [disabled] [size=512K] Capabilities: <access denied> Kernel driver in use: sata_sil Kernel modules: sata_sil 00:12.0 IDE interface: ATI Technologies Inc 4379 Serial ATA Controller (rev 80) (prog-if 8f [Master SecP SecO PriP PriO]) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 22 I/O ports at fa00 [size=8] I/O ports at f900 [size=4] I/O ports at f800 [size=8] I/O ports at f700 [size=4] I/O ports at f600 [size=16] Memory at fe02e000 (32-bit, non-prefetchable) [size=512] [virtual] Expansion ROM at 40080000 [disabled] [size=512K] Capabilities: <access denied> Kernel driver in use: sata_sil Kernel modules: sata_sil 00:13.0 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19 Memory at fe02d000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: ohci_hcd Kernel modules: ohci-hcd 00:13.1 USB Controller: ATI Technologies Inc IXP SB400 USB Host Controller (rev 80) (prog-if 10 [OHCI]) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19 Memory at fe02c000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: ohci_hcd Kernel modules: ohci-hcd 00:13.2 USB Controller: ATI Technologies Inc IXP SB400 USB2 Host Controller (rev 80) (prog-if 20 [EHCI]) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 19 Memory at fe02b000 (32-bit, non-prefetchable) [size=4K] Capabilities: <access denied> Kernel driver in use: ehci_hcd Kernel modules: ehci-hcd 00:14.0 SMBus: ATI Technologies Inc IXP SB400 SMBus Controller (rev 82) Subsystem: Intel Corporation Unknown device d600 Flags: 66MHz, medium devsel I/O ports at 0b00 [size=16] Memory at fe02a000 (32-bit, non-prefetchable) [size=1K] Kernel driver in use: piix4_smbus Kernel modules: i2c-piix4 00:14.1 IDE interface: ATI Technologies Inc Standard Dual Channel PCI IDE Controller (rev 80) (prog-if 8a [Master SecP PriP]) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 16 I/O ports at 01f0 [size=8] I/O ports at 03f4 [size=1] I/O ports at 0170 [size=8] I/O ports at 0374 [size=1] I/O ports at f400 [size=16] Capabilities: <access denied> Kernel driver in use: pata_atiixp Kernel modules: pata_atiixp 00:14.2 Audio device: ATI Technologies Inc SB450 HDA Audio (rev 01) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, slow devsel, latency 64, IRQ 16 Memory at fe024000 (64-bit, non-prefetchable) [size=16K] Capabilities: <access denied> Kernel driver in use: HDA Intel Kernel modules: snd-hda-intel 00:14.3 ISA bridge: ATI Technologies Inc IXP SB400 PCI-ISA Bridge (rev 80) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 0 00:14.4 PCI bridge: ATI Technologies Inc IXP SB400 PCI-PCI Bridge (rev 80) (prog-if 01 [Subtractive decode]) Flags: bus master, VGA palette snoop, 66MHz, medium devsel, latency 64 Bus: primary=00, secondary=02, subordinate=02, sec-latency=64 I/O behind bridge: 0000d000-0000dfff Memory behind bridge: fdd00000-fddfffff Prefetchable memory behind bridge: fdc00000-fdcfffff 01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200] (prog-if 00 [VGA controller]) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, 66MHz, medium devsel, latency 64, IRQ 17 Memory at d8000000 (32-bit, prefetchable) [size=128M] I/O ports at ee00 [size=256] Memory at fdef0000 (32-bit, non-prefetchable) [size=64K] [virtual] Expansion ROM at fde00000 [disabled] [size=128K] Capabilities: <access denied> Kernel driver in use: radeon 02:02.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) Subsystem: Intel Corporation Unknown device d600 Flags: bus master, medium devsel, latency 64, IRQ 21 I/O ports at de00 [size=256] Memory at fddff000 (32-bit, non-prefetchable) [size=256] Capabilities: <access denied> Kernel driver in use: 8139too Kernel modules: 8139cp, 8139too
Created attachment 19106 [details] Full dmesg output on crash event
Created attachment 19107 [details] Console output on crash event
Created attachment 19108 [details] xorg.conf used for tests
> *********************************WARN_ONCE********************************* > File r300_state.c function r300SetupTextures line 1548 > micro tiling enabled! > *************************************************************************** I don't see in the Mesa r300 driver source code how micro tiling can ever be enabled currently, there seems to be something wrong with your r300_dri.so... What was the top commit of the mesa Git tree? Does it still happen with current Git?
(In reply to comment #0) > dmesg yields the following message right after the crash: > > [drm:r300_emit_carefully_checked_packet0] *ERROR* Offset failed range check > (reg=4540 sz=1) > [drm:r300_do_cp_cmdbuf] *ERROR* r300_emit_packet0 failed > [drm] Num pipes: 3 Looks like you are trying to texture from a bogus address. Are you using a stock driver? If not, check your texture offsets and make sure they are valid.
(In reply to comment #4) > > *********************************WARN_ONCE********************************* > > File r300_state.c function r300SetupTextures line 1548 > > micro tiling enabled! > > *************************************************************************** > > I don't see in the Mesa r300 driver source code how micro tiling can ever be > enabled currently, there seems to be something wrong with your r300_dri.so... > What was the top commit of the mesa Git tree? Does it still happen with current > Git? > Just in case I was using the distro versions, I moved the files away while performing a new test. It produced the same results. The versions I used for this test are as follows: mesa: commit ed4c6cbe017b4e8bacb7e012d4baaf77a20a2c33 Author: Michel Dänzer <michel@tungstengraphics.com> Date: Mon Sep 22 11:49:34 2008 +0200 r300: Adapt to the removal of _tnl_ProgramCacheInit() and friends. drm: commit 3949f3c9eaad9547fe046ca4d469fa7cc8f12304 Author: Xiang, Haihao <haihao.xiang@intel.com> Date: Mon Sep 22 10:16:19 2008 +0800 intel: Fix driver-supplied argument to exec function (fd.o bug #17653). xf86-video-ati: commit d100a6af8f828eb94f8ba6e8a96c24389b5cf46f Author: Alex Deucher <alexdeucher@gmail.com> Date: Fri Sep 19 14:04:59 2008 -0400 cleanup macbook quirk commit ca9fae00795a114bca4397c32b543d6326a4c547 Author: Owen Taylor <otaylor@redhat.com> Date: Mon Sep 22 12:42:41 2008 -0700 Change 'remap' to 'map' in saveset functions/macros
(In reply to comment #6) > mesa: > > commit ed4c6cbe017b4e8bacb7e012d4baaf77a20a2c33 > Author: Michel Dänzer <michel@tungstengraphics.com> > Date: Mon Sep 22 11:49:34 2008 +0200 > > r300: Adapt to the removal of _tnl_ProgramCacheInit() and friends. Does it work with mesa commit e019ead5d76fd4e6e7d47d23e0284058391e1e29 ? I suspect r300 SW TCL may need more fixups for recent changes in preparation for the Gallium merge. If that commit doesn't work either, can you try going further back (e.g. to the 7.1 release) and if you find a working commit, find the commit that broke it with git bisect?
(In reply to comment #7) > (In reply to comment #6) > > mesa: > > > > commit ed4c6cbe017b4e8bacb7e012d4baaf77a20a2c33 > > Author: Michel Dänzer <michel@tungstengraphics.com> > > Date: Mon Sep 22 11:49:34 2008 +0200 > > > > r300: Adapt to the removal of _tnl_ProgramCacheInit() and friends. > > Does it work with mesa commit e019ead5d76fd4e6e7d47d23e0284058391e1e29 ? I > suspect r300 SW TCL may need more fixups for recent changes in preparation for > the Gallium merge. > > If that commit doesn't work either, can you try going further back (e.g. to the > 7.1 release) and if you find a working commit, find the commit that broke it > with git bisect? > Commit e019ead5d76fd4e6e7d47d23e0284058391e1e29 does not compile for me. When I try, I get the following: gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main -g -O2 -Wall -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_POSIX_SOURCE -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGLX_DIRECT_RENDERING x86/common_x86_asm.S -o x86/common_x86_asm.o x86/common_x86_asm.S: Assembler messages: x86/common_x86_asm.S:45: Error: invalid character '_' in mnemonic x86/common_x86_asm.S:47: Error: no such instruction: `aligntext4' x86/common_x86_asm.S:48: Error: no such instruction: `globl GLNAME(_mesa_x86_has_cpuid)' x86/common_x86_asm.S:49: Error: invalid character '(' in mnemonic x86/common_x86_asm.S:50: Error: invalid character '(' in mnemonic ....
> Commit e019ead5d76fd4e6e7d47d23e0284058391e1e29 does not compile for me. When I > try, I get the following: > > gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main -g -O2 -Wall > -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC > -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_POSIX_SOURCE > -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DPTHREADS > -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGLX_DIRECT_RENDERING > x86/common_x86_asm.S -o x86/common_x86_asm.o > x86/common_x86_asm.S: Assembler messages: > x86/common_x86_asm.S:45: Error: invalid character '_' in mnemonic > x86/common_x86_asm.S:47: Error: no such instruction: `aligntext4' > x86/common_x86_asm.S:48: Error: no such instruction: `globl > GLNAME(_mesa_x86_has_cpuid)' > x86/common_x86_asm.S:49: Error: invalid character '(' in mnemonic > x86/common_x86_asm.S:50: Error: invalid character '(' in mnemonic > .... > That commit is missing a reference to #include "assyntax.h" in common_x86_asm.S . Added manually, currently compiling...
(In reply to comment #9) > > Commit e019ead5d76fd4e6e7d47d23e0284058391e1e29 does not compile for me. When I > > try, I get the following: > > > > gcc -c -I../../include -I../../src/mesa -I../../src/mesa/main -g -O2 -Wall > > -Wmissing-prototypes -std=c99 -ffast-math -fno-strict-aliasing -fPIC > > -DUSE_X86_ASM -DUSE_MMX_ASM -DUSE_3DNOW_ASM -DUSE_SSE_ASM -D_POSIX_SOURCE > > -D_POSIX_C_SOURCE=199309L -D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE -DPTHREADS > > -DHAVE_POSIX_MEMALIGN -DUSE_EXTERNAL_DXTN_LIB=1 -DIN_DRI_DRIVER > > -DGLX_INDIRECT_RENDERING -DHAVE_ALIAS -DGLX_DIRECT_RENDERING > > x86/common_x86_asm.S -o x86/common_x86_asm.o > > x86/common_x86_asm.S: Assembler messages: > > x86/common_x86_asm.S:45: Error: invalid character '_' in mnemonic > > x86/common_x86_asm.S:47: Error: no such instruction: `aligntext4' > > x86/common_x86_asm.S:48: Error: no such instruction: `globl > > GLNAME(_mesa_x86_has_cpuid)' > > x86/common_x86_asm.S:49: Error: invalid character '(' in mnemonic > > x86/common_x86_asm.S:50: Error: invalid character '(' in mnemonic > > .... > > > > That commit is missing a reference to > #include "assyntax.h" > in common_x86_asm.S . Added manually, currently compiling... > Commit e019ead5d76fd4e6e7d47d23e0284058391e1e29 did not work either. It crashes X in the exact same way. I will try going further back, as suggested. However, since the suspicious message is in the kernel log, maybe the drm component (drm/linux_core) is at fault?
(In reply to comment #10) > > However, since the suspicious message is in the kernel log, maybe the drm component (drm/linux_core) is at fault? That's highly unlikely. The DRM code checks that the texture hardware address lies within one of the ranges supported by the GPU. It's been very heavily tested and working fine. Also, as I pointed out in comment #4, the Mesa r300 driver warning indicates a situation that should not be possible at all from my reading of the code, indicating that the texture hardware address used by the Mesa r300 driver is completely bogus (possibly even uninitialized?). Are you using any unusual compile options/flags for Mesa? It might also be interesting if you could attach the full Xorg.0.log file.
Created attachment 19158 [details] Xorg.0.log of crashed xserver, mesa compiled at mesa_7_2
Created attachment 19159 [details] Console output on crash event - mesa_7_2
Created attachment 19160 [details] dmesg output - mesa_7_2 All of this with mesa checked out at mesa_7_2 tag.
Created attachment 19161 [details] Copy of build.sh used to build entire tree PATH=/home/alex/xserver/bin:/usr/lib/qt-3.3/bin:/usr/kerberos/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/home/alex/bin ./util/modular/build.sh -m /home/alex/install/xorg-build-full/mesa/mesa -r mesa/mesa /home/alex/xserver Let build.sh generate all "appropriate" build flags.
Created attachment 19162 [details] config.log from mesa configure at mesa_7_2
Created attachment 19163 [details] config.log from drm configure at initial HEAD
Created attachment 19164 [details] config.log from xserver configure at initial HEAD
Created attachment 19165 [details] config.log from xf86-video-ati configure at initial HEAD
From the log file: (II) RADEON(0): Detected total video RAM=32768K, accessible=131072K (PCI BAR=131072K) (--) RADEON(0): Mapped VideoRAM: 32768 kByte (128 bit DDR SDRAM) [...] (II) RADEON(0): Will use 6900 kb for front buffer at offset 0x00000000 (II) RADEON(0): Will use 6900 kb for back buffer at offset 0x006c5000 (II) RADEON(0): Will use 6900 kb for depth buffer at offset 0x00d82000 (II) RADEON(0): Will use 6016 kb for textures at offset 0x0143f000 (II) RADEON(0): Will use 6020 kb for X Server offscreen at offset 0x01a1f000 Neither the texture area nor the EXA offscreen area can even fit a single fullscreen window, which might explain the problem. Maybe you can somehow increase the amount of 'video RAM' available, e.g. in the BIOS setup? Otherwise, you'll probably have to try reducing the depth to 16 rather than 24 or reducing the virtual resolution. P.S. Please set MIME type text/plain for text attachments.
*** Bug 17767 has been marked as a duplicate of this bug. ***
(In reply to comment #20) > From the log file: > > (II) RADEON(0): Detected total video RAM=32768K, accessible=131072K (PCI > BAR=131072K) > (--) RADEON(0): Mapped VideoRAM: 32768 kByte (128 bit DDR SDRAM) > > [...] > > (II) RADEON(0): Will use 6900 kb for front buffer at offset 0x00000000 > (II) RADEON(0): Will use 6900 kb for back buffer at offset 0x006c5000 > (II) RADEON(0): Will use 6900 kb for depth buffer at offset 0x00d82000 > (II) RADEON(0): Will use 6016 kb for textures at offset 0x0143f000 > (II) RADEON(0): Will use 6020 kb for X Server offscreen at offset 0x01a1f000 > > Neither the texture area nor the EXA offscreen area can even fit a single > fullscreen window, which might explain the problem. Maybe you can somehow > increase the amount of 'video RAM' available, e.g. in the BIOS setup? > Otherwise, you'll probably have to try reducing the depth to 16 rather than 24 > or reducing the virtual resolution. > I tried setting the amount of video RAM available to 64Mb on the BIOS, and now it works! I could enable compiz with mesa_7_2 and exercise all the effects. However, I still think it is a bug to trigger a server crash on insufficient memory instead of gracefully failing.
Created attachment 19206 [details] Xorg.0.log of xserver, mesa compiled at mesa_7_2, 64Mb of video memory
Can you try xf86-video-ati 6.9.0 rather than git and see if it works there with 32 MB of vram? If 6.9.0 works, can you git bisect to see where it broke?
(In reply to comment #22) > However, I still think it is a bug to trigger a server crash on insufficient > memory instead of gracefully failing. Absolutely. I think something like the patches I attached to bug 12385 should do the trick, though 0xffffffff would probably be better as an invalid offset than 0.
(In reply to comment #24) > Can you try xf86-video-ati 6.9.0 rather than git and see if it works there with > 32 MB of vram? If 6.9.0 works, can you git bisect to see where it broke? > No luck. 6.9.0 crashes in exactly the same way as current git with 32 Mb of memory. Attaching logs...
Created attachment 19311 [details] Console output on crash event - mesa git, xserver git, radeon 6.9.0 Mesa at 08b9e29c1d4d28fee13658b0421b4522d9c36b3a in branch master xserver at eb8be3e90a9c90a428696026d1e3b2152d7eefb4 in branch master xf86-video-ati at tag xf86-video-ati-6.9.0
Created attachment 19312 [details] dmesg output of affected kernel - 6.9.0
Created attachment 19313 [details] Xorg.0.log of crashed xserver, radeon 6.9.0
Changed bug description to indicate memory influence. Since 6.9.0 also crashes, I am not sure where to start bisecting. I could try to guess commits, but I am not sure that this ever worked at all (using AIGLX with compiz and 32 Mb of memory). Any ideas on which commit is the best to try before 6.9.0 ?
(In reply to comment #30) > > Since 6.9.0 also crashes, I am not sure where to start bisecting. I could try > to guess commits, but I am not sure that this ever worked at all (using AIGLX > with compiz and 32 Mb of memory). Right, I don't think this could ever have worked with zero-copy texture-from-pixmap. Somebody just needs to find the time to prepare fixes per comment #25.
Created attachment 19378 [details] [review] check pixmap offset for tfp Something like this?
Created attachment 19401 [details] [review] xserver patch to check return value
Created attachment 19402 [details] [review] Use ~0ULL
Created attachment 19403 [details] [review] Use ~0ULL Please test these patches for xserver and the driver with 32 MB of VRAM.
Created attachment 19415 [details] Console output on endless loop - 32Mb VRAM (compressed) The supplied patches did not fix the bug at all. On the contrary, they introduce an endless loop when trying to start compiz. What is worse, the endless loop appears even on the (previously working) 64Mb VRAM case.
Created attachment 19416 [details] Console output on endless loop - 32Mb VRAM (compressed) The supplied patches did not fix the bug at all. On the contrary, they introduce an endless loop when trying to start compiz. What is worse, the endless loop appears even on the (previously working) 64Mb VRAM case. I had to revert both patches to get an usable xorg setup again.
Created attachment 19417 [details] dmesg output on endless loop - 32 Mb VRAM (compressed)
Created attachment 19418 [details] Xorg.0.log on endless loop - 32 Mb VRAM (compressed)
Created attachment 19420 [details] Xorg.0.log on endless loop - 64 Mb VRAM (compressed)
Hrm, looks like the Mesa r300 driver doesn't correctly handle the failure to allocate texture memory either... That doesn't explain the problem with 64 MB though, is the console/dmesg output identical in that case?
Created attachment 19463 [details] Console output with 64 Mb VRAM I have confirmed that the xserver patch by itself (without applying the ati driver patch) is enough to cause the endless loop. Console output attached. dmesg output is identical - a flood of messages about a lock not held. Since the xserver patch merely attempts to check a condition that is set by the ati patch, and the endless loop still triggers, I think that the call to texOffsetStart itself is causing the looping failure. Maybe the call is illegal in that particular point in the code. What else can I try?
Created attachment 19483 [details] [review] Switch to server DRI context as necessary (In reply to comment #42) > Since the xserver patch merely attempts to check a condition that is set by the > ati patch, and the endless loop still triggers, I think that the call to > texOffsetStart itself is causing the looping failure. Maybe the call is illegal > in that particular point in the code. I think that's spot on! Try this xserver patch. The difference in console output indicates that there could be additional problems in the Mesa r300 driver though with too little texture memory, and even if those are fixed, the result will be software rendering and probably unusably slow at least... but I guess at least the failure mode might be slightly better then. :}
Created attachment 19537 [details] Console output with 32 Mb VRAM and 2nd server patch The second xserver patch was not valid - it forgot to access the 'pixmap' parameter. I fixed it by passing the pixmap parameter as a function parameter. With this and the driver patch applied, the server no longer loops or crashes with 32 Mb VRAM. However, the compiz output is corrupted, as was somewhat expected. Specifically, the wallpaper fails to be rendered completely, and window dragging leaves ugly trails on the screen.
Created attachment 19538 [details] dmesg output with patches
Created attachment 19539 [details] Xorg.0.log of xserver with patches applied
Created attachment 19540 [details] Desktop snapshot with patches applied - 32 Mb VRAM
Created attachment 19541 [details] Desktop snapshot with patches applied - 64 Mb VRAM
Created attachment 19553 [details] [review] xserver patch that actually compiles... (In reply to comment #44) > The second xserver patch was not valid - it forgot to access the 'pixmap' > parameter. I fixed it by passing the pixmap parameter as a function parameter. Ugh yeah, sorry; I thought I had compile-tested it, but obviously not... > With this and the driver patch applied, the server no longer loops or crashes > with 32 Mb VRAM. However, the compiz output is corrupted, as was somewhat > expected. Yeah, the Mesa r300 driver would need to be fixed to fall back to software rendering if it can't allocate texture memory for the GPU. Feel free to file another bug report for this. There's also a crash in the log file though, does that only occur on shutdown? If so, I think this is a substantial improvement over the original failure mode, and I'll push the patches when I get to it if nobody beats me to it.
> > There's also a crash in the log file though, does that only occur on shutdown? > If so, I think this is a substantial improvement over the original failure > mode, and I'll push the patches when I get to it if nobody beats me to it. > It seems that the new failure mode is more bearable than the old one. However, I still get some sporadic crashes (even with 64 Mb VRAM). I opened bug #17895 for it.
(In reply to comment #50) > > > > There's also a crash in the log file though, does that only occur on shutdown? > > If so, I think this is a substantial improvement over the original failure > > mode, and I'll push the patches when I get to it if nobody beats me to it. > > > > It seems that the new failure mode is more bearable than the old one. However, > I still get some sporadic crashes (even with 64 Mb VRAM). I opened bug #17895 > for it. > Bad news - a regression while testing this on current git. I opened bug #18734 for it.
Finally got around to pushing the xf86-video-ati patch to Git, so it'll be in the 6.11 release. Can this report be closed?
Created attachment 22981 [details] Xorg.0.log for now-working case with 32 Mb VRAM I am now running updated Fedora 10 with the following stock packages: kernel-2.6.27.12-170.2.5.fc10.i686 mesa-libGL-7.2-0.15.fc10.i386 mesa-dri-drivers-7.2-0.15.fc10.i386 xorg-x11-drv-ati-6.10.0-2.fc10.i386 From an earlier advice, I am running with a xorg.conf with an explicit "Virtual 1400 1080" setting. I have tried booting with 32 Mb of VRAM in the BIOS, and the crashes and corruptions are now gone, even with compiz. Attached is my current Xorg.0.log . It might be that the issue of an incorrectly-sized default Virtual setting was causing the problem all along, and this fixed the issue in my case.
Created attachment 22982 [details] xorg.conf used with xserver Current xorg.conf. Notice the explicit Virtual setting.
Closing per Michel's comments. Reopen if this is still a bug.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.