Bug 232510

Summary: radeon driver, ATI Radeon X700 (RV410) card, does not always find /dev/dri/card0
Product: [Fedora] Fedora Reporter: Michal Jaegermann <michal>
Component: xorg-x11-drv-atiAssignee: Adam Jackson <ajax>
Status: CLOSED INSUFFICIENT_DATA QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 6CC: mcepl, mcepl, xgl-maint
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2008-01-15 14:38:35 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
a log from radeon in a working state
none
a sample with dri not detected
none
xorg.conf used in the setup in question none

Description Michal Jaegermann 2007-03-15 20:09:35 UTC
Description of problem:

Radeon driver apparently searches for a very long time for needed
devices and sometimes fails to find /dev/dri/card0.  Here is
a diff from "bad" and "good" startups.   The other startup was
achieved simply by 'pkill -f gdm' which forces X restart:


--- Xorg.0.log.old      2007-03-15 12:02:38.000000000 -0600
+++ Xorg.0.log  2007-03-15 12:43:39.000000000 -0600
@@ -12,7 +12,7 @@
 Markers: (--) probed, (**) from config file, (==) default setting,
        (++) from command line, (!!) notice, (II) informational,
        (WW) warning, (EE) error, (NI) not implemented, (??) unknown.
-(==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 15 12:00:10 2007
+(==) Log file: "/var/log/Xorg.0.log", Time: Thu Mar 15 12:02:38 2007
 (==) Using config file: "/etc/X11/xorg.conf"
 (==) ServerLayout "single head configuration"
 (**) |-->Screen "Screen0" (0)
@@ -570,9 +570,7 @@
 (--) RADEON(0): BIOS at 0xfbdc0000
 (II) RADEON(0): PCIE card detected
 drmOpenDevice: node name is /dev/dri/card0
-drmOpenDevice: open result is -1, (No such device or address)
-drmOpenDevice: open result is -1, (No such device or address)
-drmOpenDevice: Open failed
+drmOpenDevice: open result is 6, (OK)
 drmOpenByBusid: Searching for BusID pci:0000:01:00.0
 drmOpenDevice: node name is /dev/dri/card0
 drmOpenDevice: open result is 6, (OK)
@@ -1011,30 +1009,6 @@
 (--) <default pointer>: PnP-detected protocol: "ExplorerPS/2"
 (II) <default pointer>: ps2EnableDataReporting: succeeded
 (**) RADEON(0): RADEONSaveScreen(2)
-(II) AIGLX: Suspending AIGLX clients for VT switch
-(**) RADEON(0): RADEONLeaveVT
-(**) RADEON(0): EngineRestore (32/32)
-(**) RADEON(0): RADEONRestore
-(**) RADEON(0): RADEONRestoreMode()
-(**) RADEON(0): RADEONRestoreMode(0x9f90c8)
-(**) RADEON(0): RADEONRestoreMemMapRegisters() :
-(**) RADEON(0):   MC_FB_LOCATION   : 0xd7ffd000
-(**) RADEON(0):   MC_AGP_LOCATION  : 0x003f0000
-(**) RADEON(0):   Map Changed ! Applying ...
-(**) RADEON(0):   Map applied, resetting engine ...
-(**) RADEON(0): Updating display base addresses...
-(**) RADEON(0): Memory map updated.
-(**) RADEON(0): Programming CRTC1, offset: 0x00000000
-(**) RADEON(0): Wrote: 0x00080002 0x00020020 0x00000000 (0x0000bf00)
-(**) RADEON(0): Wrote: rd=2, fd=32, pd=2
-(**) RADEON(0): Ok, leaving now...
-(**) RADEON(0): RADEONCloseScreen
-(**) RADEON(0): RADEONDRIStop
-(**) RADEON(0): EngineRestore (32/32)
-(**) RADEON(0): Disposing accel...
-(**) RADEON(0): Disposing cusor info
-(**) RADEON(0): Disposing DGA
-(**) RADEON(0): Unmapping memory
-(**) RADEON(0): RADEONDRICloseScreen
-(II) RADEON(0): [drm] removed 1 reserved context for kernel
-(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at
0x2aaab59f5000+(**) RADEON(0): RADEONSaveScreen(2)
+(**) RADEON(0): RADEONSaveScreen(0)
+(**) RADEON(0): RADEONDisplayPowerManagementSet(2,0x0)

I am not sure if this a reason or a result but when this happens
then there is just a black screen and a monitor control light blinks
"no signal".  Sometimes switching to another, text, console and back
brings display from this "funk" state and sometimes nothing short
of restarting X works. When it works then it works very well only
it is difficult to tell when it will need a kick.

The system in question is "remote" so I cannot observe it directly,
I am afraid.

A full Xorg.0.log for a "good start" is attached.  This gives
monitor details as well (Samsung SyncMaster 244T, LCD with 1920x1200
"native" resolution and "1920x1200" needs to be specified explicitely
in Modes or "1600x1200", which is distorted, will be picked up).

Version-Release number of selected component (if applicable):
xorg-x11-drv-ati-6.6.3-1.fc6
mesa-libGL-6.5.1-9.fc6

How reproducible:
Happens unpredictably.

Comment 1 Michal Jaegermann 2007-03-15 20:09:35 UTC
Created attachment 150166 [details]
a log from radeon in a working state

Comment 2 Michal Jaegermann 2007-03-15 20:13:27 UTC
At the bottom of the quoted diff should be, of course,
....
-(II) RADEON(0): [drm] removed 1 reserved context for kernel
-(II) RADEON(0): [drm] unmapping 8192 bytes of SAREA 0x2efff000 at 0x2aaab59f5000
+(**) RADEON(0): RADEONSaveScreen(2)
+(**) RADEON(0): RADEONSaveScreen(0)
.....
but it appears that bugzilla decided to do some formatting.  Hopefuly
I dissuaded it from that this time.

Comment 3 Matěj Cepl 2007-04-04 15:55:52 UTC
Sorry, I am too lazy to patch your log files. Could I get non-functional log
files as well, please? I would also need /etc/X11/xorg.conf and if you can try
to run Xorg without any /etc/X11/xorg.conf file at all and report results (with
appropriate /var/log/Xorg.*.log files if appropriate) it would be awesome.

Thanks

Comment 4 Michal Jaegermann 2007-04-04 18:03:40 UTC
Created attachment 151689 [details]
a sample with dri not detected

> Sorry, I am too lazy to patch your log files.
Oh, well, here is one patched for you.
> I would also need /etc/X11/xorg.conf
In the next attachment
> and if you can try to run Xorg without any /etc/X11/xorg.conf file
Not an option, I am afraid.  This card then comes in 1600x1200
resolution instead of a required 1920x1200.  In any case as I mentioned
before I do not have this machine on my desk and my access to it
and possibilities to experiment are severely limited.

The real problem is that the whole thing seesm to be extremely fragile.
Every time X server restarts (you logged out from a session and gdm
restart server, for example) this takes a very long time and often happens
that, even if logs do not indicate anythning amiss, a signal which
reaches a monitor makes it for some reasons unhappy.  If that happens
then there is only a blinking control light on a monitor and no picture.
It can be quite difficult to get then a picture again.

A failure like described in this report may cause such state but,
unfortunately, this is not the only way to get there as it turned out
in further use.

Comment 5 Michal Jaegermann 2007-04-04 18:04:27 UTC
Created attachment 151690 [details]
xorg.conf used in the setup in question

Comment 6 Matěj Cepl 2007-04-04 20:36:06 UTC
Thanks very much for the information. Let's see what we can do with it.

Comment 7 Adam Jackson 2007-09-27 21:14:54 UTC
Are you still seeing this with anything post-F6?

Comment 8 Michal Jaegermann 2007-09-27 23:48:39 UTC
> Are you still seeing this with anything post-F6?

The machine in question still runs F6 but I am not aware of
this particular error occuring for some time.

There is something more general here.  That 1920x1200 display
used to be "iffy" in that sense that on an X server (re)starts
(say, you just logged out of a session) it was roll-of-a-dice
if you will get a picture or a blank screen.  No apparent
differences in logs between one case or another.

I started to check around and found that a single-link digital
cable which came packaged with a monitor is a bit underspeced.  Not
much but apparently enough. It got replaced by a dual-link cable
and picture problems seem to be gone.  Analog cable worked all
the time but there was a visible difference in an image quality.

The original issue may, or may not, have something to do with
the above (but, again, later there was no apparent log differences
between picture or no picture results).  In any case  I am not
aware of not found drm devices happening any longer.

Comment 9 Matěj Cepl 2007-12-10 09:23:36 UTC
Fedora Core 6 is no longer supported, could you please reproduce this with the
updated version of the currently supported distribution (Fedora 7, 8, or
Rawhide)? If this issue turns out to still be reproducible, please let us know
in this bug report. If after a month's time we have not heard back from you, we
will have to close this bug as CANTFIX.

Setting status to NEEDINFO, and awaiting information from the reporter.

[This is mass-filed message to all open Fedora Core 6 bugs related to Xorg or
Gecko. If you see any other reason, why this bug shouldn't be closed, please,
comment on it here.]

Comment 10 Matěj Cepl 2008-01-15 14:38:35 UTC
Since there are insufficient details provided in this report for us to
investigate the issue further, and we have not received feedback to the
information we have requested above, we will assume the problem was not
reproducible, or has been fixed in one of the updates we have released for the
reporter's distribution.

Users who have experienced this problem are encouraged to upgrade to the latest
update of their distribution, and if this issue turns out to still be
reproducible in the latest update, please reopen this bug with additional
information.

Closing as INSUFFICIENT_DATA.

{This is mass-closing of all obsolete bugs; if this bug was in your opinion
closed by mistake, please, reopen it with additional information; thanks a lot
and I am sorry for bothering you in such case.}