Bug 679674

Summary: ATI RV280 [Radeon 9200 PRO] Fails Testcase_radeon_basic (logs are from VESA driver)
Product: [Fedora] Fedora Reporter: Phil V <pv.bugzilla>
Component: xorg-x11-drv-atiAssignee: Jérôme Glisse <jglisse>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 15CC: mcepl, valent.turkovic, xgl-maint
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-07 16:27:44 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Attachments:
Description Flags
/var/log/Xorg.0.log
none
dmesg output
none
renderchecklog
none
/var/log/Xorg.0.log FROM gfx_test_week_20110221_x86-64.iso nomodeset on Boot
none
dmesg output FROM gfx_test_week_20110221_x86-64.iso nomodeset on Boot none

Description Phil V 2011-02-23 07:48:25 UTC
Test Day:2011-02-23 Radeon
Followed https://fedoraproject.org/wiki/QA:Testcase_radeon_basic

Attempted to boot Live Image gfx_test_week_20110221_x86-64.iso

default options result in mostly black screen with horizontal columns of dot patterns

Sometimes the system will reboot itself.

One monitor attached to VGA port, another to DVI.
(Note:Card works with dual head in Fedora 13.)


Boot Option for [Minimal?] Video does work, but 
xrandr does not get meaningful results. (please see Bug 653803 for details)

Comment 1 Phil V 2011-02-23 11:26:44 UTC
Created attachment 480418 [details]
/var/log/Xorg.0.log

Comment 2 Phil V 2011-02-23 11:31:25 UTC
Created attachment 480421 [details]
dmesg output

Comment 3 Phil V 2011-02-23 11:31:58 UTC
Created attachment 480422 [details]
renderchecklog

Comment 4 Phil V 2011-02-23 11:45:56 UTC
gfx_test_week_20110221_x86-64.iso has no file /etc/X11/xorg.conf ,
nor have I created one.

Comment 5 Matěj Cepl 2011-02-23 13:15:41 UTC
(In reply to comment #0)
> Boot Option for [Minimal?] Video does work, but 
> xrandr does not get meaningful results. (please see Bug 653803 for details)

yes, it doesn't ... Basic Video uses VESA driver, which doesn't support xrandr.

Comment 6 Matěj Cepl 2011-02-23 14:43:20 UTC
Hi, yes, I was reminded by the maintainer, we would like to get /var/log/Xorg.0.log and output of dmesg from the failed attempt to start.

If you cannot collect the logs from the computer when it fails, you can reboot to runlevel 3 (add 3 to the kernel command line), and then start X after that via command startx as normal user. If it fails, still /var/log/Xorg.0.log and the output of dmesg program from the failed attempt to start X would be useful.

We will review this issue again once you've had a chance to attach this information.

Thank you very much in advance.

Comment 7 Phil V 2011-02-23 19:36:56 UTC
added 3 to kernel command line for normal boot (and deleting quiet and rhgb)
some text scrolls past quickly (last line on my photo of the screen was something like 'loading drm'

and then screen fills with a fixed dot pattern and keyboard is unresponsive.
Must hard reboot.

so no logs available on the normal boot...

Comment 8 Phil V 2011-02-24 05:37:32 UTC
Created attachment 480647 [details]
/var/log/Xorg.0.log FROM gfx_test_week_20110221_x86-64.iso nomodeset on Boot

Booted gfx_test_week_20110221_x86-64.iso, adding to the default boot, 'nomodeset'

Results: only cloning of output monitors. Can't do true dual head display.

xrandr --verbose
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 640 x 480, current 1280 x 1024, maximum 1280 x 1024
default connected 1280x1024+0+0 (0x138) normal (normal) 0mm x 0mm
	Identifier: 0x137
	Timestamp:  49615
	Subpixel:   no subpixels
	Clones:    
	CRTC:       0
	CRTCs:      0
	Transform:  1.000000 0.000000 0.000000
	            0.000000 1.000000 0.000000
	            0.000000 0.000000 1.000000
	           filter: 
  1280x1024 (0x138)    0.0MHz *current
        h: width  1280 start    0 end    0 total 1280 skew    0 clock    0.0KHz
        v: height 1024 start    0 end    0 total 1024           clock    0.0Hz
  1024x768 (0x139)    0.0MHz
        h: width  1024 start    0 end    0 total 1024 skew    0 clock    0.0KHz
        v: height  768 start    0 end    0 total  768           clock    0.0Hz
  800x600 (0x13a)    0.0MHz
        h: width   800 start    0 end    0 total  800 skew    0 clock    0.0KHz
        v: height  600 start    0 end    0 total  600           clock    0.0Hz
  640x480 (0x13b)    0.0MHz
        h: width   640 start    0 end    0 total  640 skew    0 clock    0.0KHz
        v: height  480 start    0 end    0 total  480           clock    0.0Hz

Comment 9 Phil V 2011-02-24 05:39:38 UTC
Created attachment 480650 [details]
dmesg output FROM gfx_test_week_20110221_x86-64.iso nomodeset on Boot

Comment 10 Phil V 2011-02-26 05:47:00 UTC
I have tried various combinations of:
drm.debug=0x04
drm.debug=14

log_buf_len=16M 

radeon.agpmode=-1 | 1 | 4
radeon.no_wb=1

and most combinations result in a two text comments followed by a few lines of '.' in the preboot process and then a second or two of boot log messages flying by, and then the screen fills with a fixed black/white pixel pattern and the keyboard becomes unresponsive.

However I did find that:
==== 'nomodeset drm.debug=0x04' results in: =====

No root device found


No root device found

Dropping to debug shell.

sh: can't access tty; job control turned off
dracut:/#"

==================================================
and at this point I only have access to:
/usr/bin/: bzip2 checkisomd5 eject flock less mkfifo
/usr/sbin/chroot
/bin/: 28 commands
/sbin/: 46 commands

What can I do from this point?

Comment 11 Phil V 2011-02-26 06:36:09 UTC
nomodeset drm.debug=14 also gives the same result.

Comment 12 Phil V 2011-02-28 19:46:50 UTC
Matej, 
(1) would the dmesg output at the point of dropping into the dracut debug shell be helpful?
(2) any recommendations on saving it to a file with the limited commands available at this point?

Thank you for your help!

Comment 13 Matěj Cepl 2011-02-28 23:57:09 UTC
(In reply to comment #12)
> Matej, 
> (1) would the dmesg output at the point of dropping into the dracut debug 
> shell be helpful?

Of course, that would be awesome!

> (2) any recommendations on saving it to a file with the limited commands
> available at this point?

http://fedoraproject.org/wiki/Dracut/Debugging, but I think dmesg would be lovely. Also, you can try to start in runlevel 3, and if you get to the command prompt (please, collect dmesg as soon as you get there first), you can try to run startx as non-root user and collect /var/log/Xorg.0.log from that run (or stdout/stderr from X itself).

Thank you

Comment 14 Phil V 2011-03-03 18:31:43 UTC
Help needed on:

> (2) any recommendations on saving it to a file with the limited commands
> available at this point?

Does dmesg help if nomodeset causes the vesa driver to load?

Does runlevel 3 with vesa driver help?
Or do you need runlevel 3 with radeon driver?

Comment 15 Valent Turkovic 2011-05-27 11:04:44 UTC
I think I have the same issue, I'll try to force radeon driver with xorg.conf file and then report back and send any logs I can gather.

Comment 16 Valent Turkovic 2011-05-27 11:05:23 UTC
(In reply to comment #14)
> Help needed on:
> 
> > (2) any recommendations on saving it to a file with the limited commands
> > available at this point?
> 
> Does dmesg help if nomodeset causes the vesa driver to load?
> 
> Does runlevel 3 with vesa driver help?
> Or do you need runlevel 3 with radeon driver?

Phil have you found some fix with your card?

Comment 17 Fedora End Of Life 2012-08-07 16:27:46 UTC
This message is a notice that Fedora 15 is now at end of life. Fedora
has stopped maintaining and issuing updates for Fedora 15. It is
Fedora's policy to close all bug reports from releases that are no
longer maintained. At this time, all open bugs with a Fedora 'version'
of '15' have been closed as WONTFIX.

(Please note: Our normal process is to give advanced warning of this
occurring, but we forgot to do that. A thousand apologies.)

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, feel free to reopen
this bug and simply change the 'version' to a later Fedora version.

Bug Reporter: Thank you for reporting this issue and we are sorry that
we were unable to fix it before Fedora 15 reached end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora, you are encouraged to click on
"Clone This Bug" (top right of this page) and open it against that
version of Fedora.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

The process we are following is described here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping