Description of problem: On F8 installation which happens to have a graphic card identified in logs as: (--) RADEON(0): Chipset: "ATI Radeon X1200" (ChipID = 0x791e) I see in logs a constant stream of writes which look like that: ..... CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 ...... and punctuated from time to time with something of that kind: .... CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10009 CailReadATIRegister(6084) = 0 CailWriteATIRegister(6084,0) CailReadATIRegister(60ec) = 100 CailWriteATIRegister(60ec,100) Unblank CRTC 0 success In relatively short time one can collect literally megabytes of that. Even if there is some useful information there it will be drowned in all this noise so all these churn seem to miss the point. Is this really required or helpfull? Maybe is at least possible to consolidate repeating log entries? The same generation driver but this time with (--) RADEON(0): Chipset: "ATI Radeon 9250 5960 (AGP)" (ChipID = 0x5960) card and on F9 installation seems to be much more frugal with log scribbles. R500 vs. an older ATI chipset? xorg-x11-drv-ati-6.9.0-2.fc10 appears to be bent of on logging over and over the following: ...... (II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA-0:ddc2" removed. (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Found color CRT connected to primary DAC in RADEONProbeOutputModes (II) RADEON(0): Adding Screen mode: 1024x768 (II) RADEON(0): Adding Screen mode: 800x600 (II) RADEON(0): Adding Screen mode: 640x480 (II) RADEON(0): Total number of valid Screen mode(s) added: 3 (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI-0:ddc2" removed. (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 (II) RADEON(0): I2C device "VGA-0:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "VGA-0:ddc2" removed. (II) RADEON(0): Output: VGA-0, Detected Monitor Type: 0 (II) RADEON(0): Found color CRT connected to primary DAC in RADEONProbeOutputModes (II) RADEON(0): Adding Screen mode: 1024x768 (II) RADEON(0): Adding Screen mode: 800x600 (II) RADEON(0): Adding Screen mode: 640x480 (II) RADEON(0): Total number of valid Screen mode(s) added: 3 (II) RADEON(0): I2C device "DVI-0:ddc2" registered at address 0xA0. (II) RADEON(0): I2C device "DVI-0:ddc2" removed. (II) RADEON(0): Output: DVI-0, Detected Monitor Type: 0 (II) RADEON(0): Output: S-video, Detected Monitor Type: 0 ..... and this grows logs even faster than on F8 (it looks that in an order of 2Megs per hour). That with (--) RADEON(0): Chipset: "ATI Radeon 9500 AD (AGP)" (ChipID = 0x4144) for a change. Hopefuly this is just a "rawhide". Version-Release number of selected component (if applicable): xorg-x11-drv-ati-6.8.0-4.fc8 xorg-x11-drv-ati-6.8.0-14.fc9 xorg-x11-drv-ati-6.9.0-2.fc10
Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please attach your X server config file (/etc/X11/xorg.conf) and X server log file (/var/log/Xorg.*.log; just brief -- startup and shutdown xorg session) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link below. Could you please also try to run without any /etc/X11/xorg.conf whatsoever and let X11 autodetect your display and video card? Attach to this bug /var/log/Xorg.0.log from this attempt as well, please. We will review this issue again once you've had a chance to attach this information. Thanks in advance.
Created attachment 316261 [details] xorg.conf a configuration file from an F8 machine with X1200 card
Created attachment 316263 [details] sample log full of 'CailReadATIRegister' and similar entries I have another log file which grew to 1.3 Meg with a help of "CailReadATIRegister(609c) = 20002", and the like, but it is not likely that this really adds something to the picture.
Thanks, this is absolutely perfect.
There have been bunch of bug fixes Could you retest with the latest kernel ( -132 at the time of this writing ) You can get the latest kernel build here http://koji.fedoraproject.org/koji/buildinfo?buildID=72270 And with the latest xorg-x11-drv-ati. ( -60 at the time of this writing ) You can get the latest xorg-x11-drv-ati build here http://koji.fedoraproject.org/koji/packageinfo?packageID=95 And report back if it either improves or fixes this issue.. Thanks.
As requested I tried with kernel-2.6.27.7-134.fc10.x86_64 and xorg-x11-drv-ati-6.9.0-61.fc10.x86_64 which are current now on koji. A spillage of that sort: ..... CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 CailReadATIRegister(609c) = 10002 ..... is gone. It was actually gone with a kernel and a driver from F10 release only those are producing events like that: [drm] Loading R300 Microcode BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<ffffffffa0041e5b>] radeon_cp_init_ring_buffer+0x234/0x521 [radeon] PGD 8080067 PUD c9e1067 PMD 1d860067 PTE 0 Oops: 0000 [1] SMP .... and crash process Xorg. That does not happen after updates. OTOG in Xorg logs I have over and over: (EE) RADEON(0): Unknown EDID version 0 and if I am NOT using 'nomodeset' then in dmesg an logs I am collecting a constant repeating stream of that sort: [drm:edid_is_valid] *ERROR* EDID has major version 0, instead of 1 [drm:edid_is_valid] *ERROR* Raw EDID: <3>00 ff ff ff ff ff ff 00 2c 93 e6 05 a6 82 13 1c ........,....... <3>0e 07 00 00 0c 1c 15 00 e8 00 b2 a0 57 49 9b 26 ............WI.& <3>10 48 4f ff fe 00 81 80 00 00 00 00 00 00 00 00 .HO............. <3>00 00 00 00 00 00 f8 2a 00 c0 51 00 24 40 28 b8 .......*..Q.$@(. <3>13 00 04 c3 10 00 00 1e 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ <3>00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 f4 ................ pci 0000:01:00.0: VGA-1: EDID invalid. i2c-adapter i2c-1: unable to read EDID block. pci 0000:01:00.0: DVI-I-1: no EDID data Moreover a monitor is making very uhealthy sounding clicking noises and the moment X server starts all text consoles are becoming black-on-black. Also there are repeated sequences of mtrr: base(0xd913d000) is not aligned on a size(0x785000) boundary [drm] DAC-6: set mode 1024x768 d plus mtrr: base(0xda05d000) is not aligned on a size(0x420000) boundary mtrr: base(0xda7f5000) is not aligned on a size(0x420000) boundary mtrr: base(0xd95af000) is not aligned on a size(0x420000) boundary mtrr: base(0xd9d3f000) is not aligned on a size(0x420000) boundary mtrr: base(0xdb3f7000) is not aligned on a size(0x420000) boundary All this "EDID" stuff and "not aligned" disappears if I am using 'nomodeset' booting parameter. Also text consoles actually do display then a visible text. But then this starts to show up, repeatedly, for a change: agpgart-amd64 0000:00:00.0: AGP 3.5 bridge agpgart-amd64 0000:00:00.0: putting AGP V3 device into 8x mode pci 0000:01:00.0: putting AGP V3 device into 8x mode [drm:radeon_do_init_cp] *ERROR* PCI GART memory not allocated! and a trying to return from a user-switcher initiated another session crashes and restarts gdm making attempts to switch sessions moot. This was not so spectacularly misbehaving earlier.
Just seen that: http://lkml.org/lkml/2008/12/3/535. I do not have a "smoking gun" but to me it also looks that xorg-x11-drv-ati changes are really responsible for a slew of problems.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.