Bug 175263

Created attachment 122026 [details]
Xorg.0.log produced when machine crashes

The R300 DRI support is experimental, and is not included in our X packages.
It appears from this however:

(II) RADEON(0): [drm] loaded kernel module for "radeon" driver
(II) RADEON(0): [drm] DRM interface version 1.2
(II) RADEON(0): [drm] created "radeon" driver at busid "pci:0000:01:00.0"
(II) RADEON(0): [drm] added 8192 byte SAREA at 0xe0b13000
(II) RADEON(0): [drm] mapped SAREA 0xe0b13000 to 0xb7f43000
(II) RADEON(0): [drm] framebuffer handle = 0xd0000000
(II) RADEON(0): [drm] added 1 reserved context for kernel
(II) RADEON(0): [pci] 8192 kB allocated with handle 0xe0ce0000
(II) RADEON(0): [pci] ring handle = 0xe0ce0000
(II) RADEON(0): [pci] Ring mapped at 0xafdaa000
(II) RADEON(0): [pci] Ring contents 0x00000000
(II) RADEON(0): [pci] ring read ptr handle = 0xe0de1000
(II) RADEON(0): [pci] Ring read ptr mapped at 0xafda9000
(II) RADEON(0): [pci] Ring read ptr contents 0x00000000
(II) RADEON(0): [pci] vertex/indirect buffers handle = 0xe0de2000
(II) RADEON(0): [pci] Vertex/indirect buffers mapped at 0xafba9000
(II) RADEON(0): [pci] Vertex/indirect buffers contents 0x00000000
(II) RADEON(0): [pci] GART texture map handle = 0xe0fe2000
(II) RADEON(0): [pci] GART Texture map mapped at 0xaf6c9000
(II) RADEON(0): [drm] register handle = 0xdfdf0000
(II) RADEON(0): [dri] Visual configs initialized

That the driver is still causing the DRM kernel module to be loaded though.
The hang seems to be happening while the VIP bus is getting evaluated.

Curious.. is this an ATI All in Wonder card, or a VIVO?

You may want to try updating to the latest Fedora development packages and
see if the problem still occurs or not.

Fedora Core 5 test3 has been released.  Please update the report to indicate
if the problem still occurs in FC5test3.

NB the same hardware provokes a similar behaviour in FC5t2, see report 182196.
That report does not have the same useful log output as this one.

Comment #3 is referring to Fedora Core 5 test three, not test2.  Please
test test3.

If this issue turns out to still be reproduceable in the latest
updates for this Fedora Core release, please file a bug report
in the X.Org bugzilla located at http://bugs.freedesktop.org in
the "xorg" component.

Once you've filed your bug report to X.Org, if you paste the new
bug URL here, Red Hat will continue to track the issue in the
centralized X.Org bug tracker, and will review any bug fixes
that become available for consideration in future updates.

Setting status to "NEEDINFO_REPORTER", and awaiting upstream
bug report URL for tracking.

Thanks in advance.

This problem has been reproduced in test 3 (see 182196). The result is that RH
has removed support for all R300 DRI. This could be closed as a dup?

(In reply to comment #7)
> This problem has been reproduced in test 3 (see 182196). The result is that RH
> has removed support for all R300 DRI. This could be closed as a dup?

Technically, X11R7 contains R300 DRI driver source code (well Mesa does), but
it is experimental and disabled by default, which is where things stood when
this report was initially filed.  Some time after that, I enabled r300 dri
support for a few weeks to see what the results were as an experiment which
turned out to prove that R300 support was unstable and not shippable, so it
was re-disabled.

However, all along, our kernel has had r300 DRM code enabled in the radeon
kernel module.  Bug #182196 shows how this causes a problme on many R300 and
newer class hardware, since the X server causes the DRM module to get loaded
anyway, and that action seems to cause the kernel to hang.

If removing the kernel module and rebooting prevents this problem, then I think
it is relatively safe to conclude this is a dupe of bug #182196 though.

Our current kernel, disables r300 and newer kernel DRM support, so in
theory the problem is solved now (or worked around).

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