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
--
fedora-list mailing list
fedora-list@xxxxxxxxxx
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
