X.org Keeps Dying Out Of The Blue

Jim Cornette fc-cornette at insight.rr.com
Tue Jan 22 11:57:14 UTC 2008


Brian Mury wrote:
> On Sun, 2008-01-20 at 19:39 -0500, Kelly Miller wrote:
>> I'm not sure what the problem could be; all I know is that randomly, 
>> while I'm working on the desktop, my monitor goes dark and shows an 
>> "Input Not Supported" message.

This problem sounds like it is caused by the screen somehow deciding to 
change its resolution during the X session. I don't know if adding the 
desired mode line to the xorg.conf file or if changing the settings 
which re adjustable by the user without root privileges would work to 
stabilize the desired screen resolution.


> 
> This has been happening to me as well on F8. I just hadn't gotten around
> to reporting it yet. FC1 through F7 were fine on this box, so it
> definitely looks like something F8 specific.

This change to xorg.conf started at F8 if I recall. I do a lot of 
running rawhide so I sometimes vaguely remember the release changes are 
implemented.

> 
> I don't get the "Input Not Supported" message, but I suspect that is
> simply due to a different monitor. What I do see is the screen goes
> black, and the power LED on the monitor flickers every few seconds, the
> same way it does when the monitor switches resolutions/refresh rates.
> 
> I can switch to a different console (Ctrl-Alt-F1 or whatever), then back
> to my desktop (Ctrl-Alt-F7) and everything is fine, no need to reboot,
> or restart X, or anything like that.
> 
> BTW, I also have a Radeon 9200 card (which you mentioned in a later
> email). I am *not* using the ATI drivers.
> 
> I do see some interesting stuff in my Xorg.0.log, but there are no
> timestamps in that log (why not???) which makes it hard to separate out
> the different occurrences. I've appended a line to the file so I will
> know where to look next time it happens.
> 
> Basically I get a whole bunch of stuff that looks like this (but without
> timestamps I'm not sure where to start the copy & paste, not sure how
> useful this is to anyone):
> 
> (II) RADEON(0): [RESUME] Attempting to re-init Radeon hardware.
> (==) RADEON(0): Using AGP 8x
> (II) RADEON(0): [agp] Mode 0x1f00420a [AGP 0x10de/0x01e0; Card
> 0x1002/0x5961]
> enable montype: 1
> enable montype: 1

This part interests me since I get monotype 2. The ati driver used to 
work for me but completely locks up the server with whatever crazy 
changes the developers subjected the driver to back in mid December 
(Rawhide version).
The monotype entry probably does not indicate any problem.

> (II) <default pointer>: ps2EnableDataReporting: succeeded
> (II) Mouse0-usb-0000:00:02.0-2/input0: On
> (II) evdev brain: Rescanning devices (5).
> (II) Mouse0-usb-0000:00:02.0-2/input0: Off
> (II) AIGLX: Suspending AIGLX clients for VT switch
> disable montype: 1
> disable montype: 1
> (II) RADEON(0): RADEONRestoreMemMapRegisters() : 
> (II) RADEON(0):   MC_FB_LOCATION   : 0x1fff0000
> (II) RADEON(0):   MC_AGP_LOCATION  : 0x27ff2000
> finished PLL2
> finished PLL1
> Entering Restore TV
> Restore TV PLL
> Restore TVHV
> Restore TV Restarts
> Restore Timing Tables
> Restore TV standard
> Leaving Restore TV
> (II) Open ACPI successful (/var/run/acpid.socket)
> (II) AIGLX: Resuming AIGLX clients after VT switch
> init memmap
> init common
> init crtc1
> init pll1
> restore memmap
> (II) RADEON(0): RADEONRestoreMemMapRegisters() : 
> (II) RADEON(0):   MC_FB_LOCATION   : 0xd7ffd000
> (II) RADEON(0):   MC_AGP_LOCATION  : 0xe07fe000
> restore common
> restore crtc1
> restore pll1
> finished PLL1
> restore dac
> enable montype: 1
> init memmap
> init common
> init crtc2
> init pll2
> restore memmap
> (II) RADEON(0): RADEONRestoreMemMapRegisters() : 
> (II) RADEON(0):   MC_FB_LOCATION   : 0xd7ffd000
> (II) RADEON(0):   MC_AGP_LOCATION  : 0xe07fe000
> restore common
> restore crtc2
> restore pll2
> restore memmap
> (II) RADEON(0): RADEONRestoreMemMapRegisters() : 
> (II) RADEON(0):   MC_FB_LOCATION   : 0xd7ffd000
> (II) RADEON(0):   MC_AGP_LOCATION  : 0xe07fe000
> restore common
> restore crtc2
> restore pll2
> finished PLL2
> restore dac
> enable montype: 1
> (II) RADEON(0): [RESUME] Attempting to re-init Radeon hardware.
> (==) RADEON(0): Using AGP 8x
> (II) RADEON(0): [agp] Mode 0x1f00420a [AGP 0x10de/0x01e0; Card
> 0x1002/0x5961]
> enable montype: 1
> enable montype: 1
> (II) <default pointer>: ps2EnableDataReporting: succeeded
> (II) Mouse0-usb-0000:00:02.0-2/input0: On
> (II) evdev brain: Rescanning devices (6).
> 

I never see the MC_FB type of information in my radeon logs for this 
laptop. Also evdiv brain sounds a bit like the automated aspects for the 
new server/driver information is not functioning cognitively. It sure 
shows the limitations for Artificial intelligence. - :)


Hopefully some lister with other ideas can offer advice or you two can 
figure out what might be causing these problems. Bugzila could show 
clues too from others who are not part of this list.

Sorry I cannot figure out a good clue that would resolve the problem.

Jim

-- 
Fourth Law of Thermodynamics:
	If the probability of success is not almost one, it is damn near zero.
		-- David Ellis




More information about the fedora-list mailing list