Created attachment 328049 [details] server 1.5.99.3-5.fc11 locking up with "FIFO timed out, resetting engine..." Description of problem: Installing xorg-x11-drv-ati-6.9.0-65.fc11 together with xorg-x11-server-Xorg-1.5.99.3-5.fc1 had very bad effects on my monitor. A picture became too wide, much wider than a viewing area while on a "monitor menu" H-width control was in a center position. After this happened changing that position does not have any effect anymore and the damage is permanent. Connected to another machine, with entirely different graphics card, this monitor shows the same distortion does not matter what is displayed. Other picture controls on a monitor remain operational but this does not help very much. It is true that the monitor in question was old, and the damage may be coincidental, but X server/drivers were causing clicking noises in my monitor while apparently probing for parameters and it looks like that this time the monitor got probed somewhat too hard. Now it has to be scrapped. After replacing the destroyed monitor with a Samsung SyncMaster 213T LCD panel (1600x1200 native resolution with lower ones emulated and DVI connection) I tried to continue testing. First the general note - without "nomodeset" kernel parameter with rawhide this is good for one boot without turning off power. On the second boot a picture is missing both vertical and horizontal sync even for BIOS messages and/or grub menus. That happens regardless which versions of x11 drivers are used. Adding "nomodeset" kills that effect. In any case in this setup any attempts to bring X were invariably ending with a complete machine lockup (no image, no keyboard, no network access). In whatever was written in logs invariably the following could be found: (EE) RADEON(0): Static buffer allocation failed. Disabling DRI. Attached are two samples of Xorg.0.log; both with xorg.conf absent. The first one ends up with (EE) RADEON(0): FIFO timed out, resetting engine... (EE) RADEON(0): FIFO timed out, resetting engine... (EE) RADEON(0): FIFO timed out, resetting engine... (EE) RADEON(0): FIFO timed out, resetting engine... The second makes somewhat better impression but visible results were the same. After backing off to xorg-x11-server-Xorg-1.5.3-6.fc10.x86_64, xorg-x11-drv-ati-6.9.0-63.fc10.x86_64 and xorg-x11-drv-keyboard-1.3.0-3.fc9.x86_64 from F10 distribution I started to get somewhere. That gets a picture only mouse and keyboard are absent due to, I believe, the following errors: (EE) module ABI major version (4) doesn't match the server's version (2) (EE) Failed to load module "evdev" (module requirement mismatch, 0) (EE) No input driver matching `evdev' (EE) config/hal: NewInputDeviceRequest failed That despite that there were no complaints about unsatisfied dependencies with xorg-x11-drv-evdev-2.1.0-3.fc11 and 'package-cleanup --problems' does not have any issues. In any case it turns out that it is possible to work around that with a help of "ServerFlags" section in xorgs.conf. Attached is a log from something which can be used at last. Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.9.0-65.fc11 xorg-x11-server-Xorg-1.5.99.3-5.fc11.x86_64 xorg-x11-server-common-1.5.99.3-5.fc11.x86_64
Created attachment 328050 [details] server 1.5.99.3-5.fc11 apparently "normal" but machine locking up
Created attachment 328051 [details] after backing off to F10 server and ati driver binaries - no xorg.conf and no keyboard
Created attachment 328052 [details] 1.5.3-6.fc10 server and xorg-x11-drv-ati-6.9.0-63.fc10 - working at last with xorg.conf
Created attachment 328053 [details] /etc/X11/xorg.conf used in the last case
Created attachment 328054 [details] Xorg.0.log from Fedora 10 installation on the same hardware - for comparison This is a log file from F10 running on the same machine (only different disk partitions). Note that that there are no problems with DRI and "static buffer". To wit: (II) LoadModule: "dri" (II) Module dri: vendor="X.Org Foundation" (II) Loading extension XFree86-DRI drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: node name is /dev/dri/card0 (II) RADEON(0): [dri] Found DRI library version 1.3.0 and kernel module version 1.29.0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: node name is /dev/dri/card0 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): [DRI] installation complete (WW) RADEON(0): DRI init changed memory map, adjusting ... drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: node name is /dev/dri/card0 (II) AIGLX: Loaded and initialized /usr/lib64/dri/r300_dri.so (II) GLX: Initialized DRI GL provider for screen 0 xorg.conf used is the same one as attached except that a "ServerFlags" section is missing.
This bug appears to have been reported against 'rawhide' during the Fedora 11 development cycle. Changing version to '11'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Does fedora 12 lastest live cd work any better for you ? https://fedoraproject.org/get-prerelease
Sorry, live CD is not a good option here. The current rawhide with xorg-x11-drv-ati-6.13.0-0.7.20091006git457646d73.fc12.x86_64 and xorg-x11-server-Xorg-1.7.0-1.fc12.x86_64 works without much fuss. A monitor may still loose a sync after a reboot and has to be powered off and on before starting to behave. I cannot repeat experiments with an old monitor as it was, like reported, destroyed and had to be scrapped.
Can you attach Xorg log & dmesg after monitor did loose sync. Also can you provide reference of the monitor.
> Can you attach Xorg log & dmesg after monitor did loose sync. This goes like that: - you boot with KMS - everythings works like it is supposed to - you reboot without powering down - a grub menu screen comes up (some BIOS too before that but this is quick) and everything jumps around like crazy with some "rainbow" colours jumping out here and there; that never happens if this was not a warm reboot - flipping power on a monitor down and up stablizes the picture or, if you can wait, once booting progressed (I think to a modesetting part) a picture gets normal again In other words - if you are far enough to get logs everything is already fine. It appears that something was changed either on graphics card or written to a monitor which is not liked. I only know that this never happens with Fedora 10 installation on the same hardware and is "expected" when I am running rawhide. No idea how I can get some data out of that. Unfortunately there is not even a serial port on that hardware. > can you provide reference of the monitor. This is Samsung SyncMaster 213T manufactured in 2005. (II) RADEON(0): EDID (in hex): (II) RADEON(0): 00ffffffffffff004c2d91003132424e (II) RADEON(0): 0d0f0103802b20a02ad0c4a15a4b9723 (II) RADEON(0): 174f57bfef80a9408180010101010101 (II) RADEON(0): 010101010101ed3240a060b023403020 (II) RADEON(0): 2400b0441100001a000000fd00384b1e (II) RADEON(0): 510e000a202020202020000000fc0053 (II) RADEON(0): 796e634d61737465720a2020000000ff (II) RADEON(0): 00484348593330353131340a20200021 and ATI Technologies Inc R300 AD [Radeon 9500 Pro] graphics card.
Created attachment 364784 [details] Xorg.0.log from the current rawhide with 2.6.31.1-56.fc12.x86_64 kernel
Created attachment 364786 [details] dmesg from the current rawhide with 2.6.31.1-56.fc12.x86_64 kernel
So it's some state we don't properly restore at shutdown. It's hard to track and i don't think this bug is really important as as soon as kms kickin it fixes the issue right ? I let you the choice to close or not the bug, i am switching it to low priority.
> i don't think this bug is really important as as soon as kms kickin it > fixes the issue right ? Maybe. I do not know. As long as hardware will not get fried and I already have seen that. Is anybody around with a knowledge on this level who could chip in? Out-of-sync grub screen is surely mightly annoying when you a trying to reboot.
I think you can't fried LCD stuff, i would be quite astonish if anyone everdid. You can fried old crtc thought but this kind of monitor is already dying on its own.
> I think you can't fried LCD stuff ... That "I think" is what somewhat bothers me. Besides not all monitors around are LCD yet. I think that this one should be closed. It appears to stray too far from the original issue. Or you would rather have it open for a reference?
I am closing this one as your new issue is too different. Please open a new one with following title: RADEON:R300:9500:AGP KMS corrupt VGA (grub) display after reboot Attach lastest dmesg & Xorg.log, with output of lspci -vnnxx When i said i think you can't fried LCD, i am in fact convinced of that, i am sure it's a fact. I have been doing graphic drivers development for quite sometimes now and i fried some CRTC along the way but i never ever damaged an LCD panel. Most the LCD panel ignore wrong signal, and one which does not won't suffer from that.
> Please open a new one ... OK, will do that. Thanks for reassurances about LCD.