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.
Created attachment 150166 [details] a log from radeon in a working state
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.
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
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.
Created attachment 151690 [details] xorg.conf used in the setup in question
Thanks very much for the information. Let's see what we can do with it.
Are you still seeing this with anything post-F6?
> 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.
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.]
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.}