Bug 175263 - Xorg (ati radeon) causes hard hang of machine
Summary: Xorg (ati radeon) causes hard hang of machine
Status: CLOSED DUPLICATE of bug 182196
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 5
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: X/OpenGL Maintenance List
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2005-12-08 11:42 UTC by cam
Modified: 2007-11-30 22:11 UTC (History)
0 users

Clone Of:
Last Closed: 2006-03-11 00:38:40 UTC

Attachments (Terms of Use)
Xorg.0.log produced when machine crashes (37.80 KB, text/plain)
2005-12-08 11:44 UTC, cam
no flags Details

Description cam 2005-12-08 11:42:32 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Description of problem:
The last message seen in the Xorg.o.log was:

(II) RADEON(0): No response from device 0 on VIP bus

Full log attached.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
Install FC5t1 on Dell Inspiron 6000 (128Mb Radeon x300, 1920x1200 screen)

Actual Results:  Machine hangs requiring power off, just after starting X

Expected Results:  X should run normally 

Additional info:

Workaround: comment out dri line in Xorg.conf. This allows X to start successfully.

Comment 1 cam 2005-12-08 11:44:00 UTC
Created attachment 122026 [details]
Xorg.0.log produced when machine crashes

Comment 2 Mike A. Harris 2006-01-31 20:28:07 UTC
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.

Comment 3 Mike A. Harris 2006-02-21 11:16:33 UTC
Fedora Core 5 test3 has been released.  Please update the report to indicate
if the problem still occurs in FC5test3.

Comment 4 cam 2006-02-21 12:13:48 UTC
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 5 Mike A. Harris 2006-02-21 13:46:20 UTC
Comment #3 is referring to Fedora Core 5 test three, not test2.  Please
test test3.

Comment 6 Mike A. Harris 2006-03-08 11:51:33 UTC
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.

Comment 7 cam 2006-03-10 01:04:17 UTC
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?

Comment 8 Mike A. Harris 2006-03-10 06:39:38 UTC
(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).

Comment 9 Mike A. Harris 2006-03-11 00:38:40 UTC

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

Note You need to log in before you can comment on or make changes to this bug.