Description of problem: The radeon driver is working better than is has in a long time on my ancient radeon 7200, but this one (so far) oddity has shown up I figured I ought to report: I'm in a standard gnome session, someone (I think policykit) does something selinux doesn't like, so selinux tries to popup a message at the top of the screen under the notification area. Instead of a message though, I see a box the size of a message that is mostly a black background and some mostly red crosshatched lines, with smatterings of other random pixels here and there. I usually see some sort of flash out the corner of my eye as well, perhaps it is drawn all white at first then becomes the final version - I'm not sure about the flash. I'm actually pretty impressed that this card works at all, for a long time a crash at boot has been the only result unless I used radeon.modeset=0 Version-Release number of selected component (if applicable): kernel: kernel-2.6.31-2.fc12.x86_64 radeon driver: xorg-x11-drv-ati-6.13.0-0.4.20090908git651fe5a47.fc12.x86_64 lspci info: 01:00.0 VGA compatible controller: ATI Technologies Inc Radeon R100 QD [Radeon 7200] How reproducible: Every time I got some kind of popup message, the same black box appeared instead of the real message. Steps to Reproduce: 1. see above 2. 3. Actual results: crosshatched black box Expected results: readable message Additional info: https://www.redhat.com/archives/fedora-test-list/2009-September/msg00275.html is the fedora-test-list thread where I initially reported my results.
Created attachment 361003 [details] Xorg log file Here's a copy of the xorg log file from the system with the popup problems. Also, in case it is useful, here's the smolt profile: http://www.smolts.org/client/show/?uuid=pub_6ad59b18-0285-44eb-8d23-6f7c0d60b251
Another possibly relevant bit of info is this from /var/log/dmesg: pci 0000:01:00.0: AGP bridge [1002/5144] pci 0000:01:00.0: aperture size 4096 MB is not right, using settings from NB Aperture pointing to e820 RAM. Ignoring. pci 0000:01:00.0: aperture from AGP @ dc01d8000000 size 32 MB Aperture beyond 4GB. Ignoring. pci 0000:00:18.3: no usable aperture found pci 0000:00:18.3: consider rebooting with iommu=memaper=2 to get a good aperture This motherboard is primarily a PCIE board, but has a weird hardware bridge for using an AGP card. I assume that's what these messages are about (and by the way, when I add the iommu=memaper=2 kernel boot option, absolutely nothing changes - it still prints this message).
from discussion on the test list, this isn't limited to notification bubbles. G. Wolfe Woodbury reported to the list: "GNOME works with the Xorg ATI driver for Radeon QD/7200/r100 without radeon.modeset=0 (anaconda still needs this for installing!) but KDE shows a very scrambled screen. The major organization is ok, but the bottom panel and popups are unrecognizable except for the outlines; contents are a weave of dots and lines. The bottom panel is outlined ok, but the icons and texts are scrambled." This is almost certainly the same corruption with the same root cause. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Noticed another message box that comes up mostly black: The firefox "All downloads have completed" message box.
And in my latest experiments, I installed KDE, and can confirm that the bar at the bottom of the screen is just unreadable lines, and if I go by memory and get a box that looks to be about the size of the launcher or main menu or whatever KDE calls it to come up, it is also unreadable lines. Unlike the other boxes though, these are mostly white with various colored lines rather than black. If I do manage to get an app started (konsole is availabe from context menu, which I can read), then the decorations around the window are also garbled the same way as the other things. (I don't see garbled window decorations in gnome, I guess gnome and kde do the decorations using some different technique). For grins, I tried running ksnapshot from the console, and the screen image shows the garbling, so it isn't just being painted wrong from a correctly rendered screen buffer, it is apparently rendered wrong in the first place.
Is this still happening? There have been some updates recently.
I just checked for any kernel or ati driver updates on my system with the radeon 7200, and I seem to have the latest stuff installed: xorg-x11-drv-ati-6.13.0-0.7.20091006git457646d73.fc12.x86_64 kernel-2.6.31.1-56.fc12.x86_64 still see the same mostly black box for popup messages (downloaded a file from firefox to test, got the black popup).
can you check with a later kernel build (one that's not in Rawhide officially yet)? http://koji.fedoraproject.org/koji/buildinfo?buildID=137800 is the latest. There may have been relevant fixes since 2.6.31.1-56 . There's also a slightly newer xorg-x11-drv-ati: http://koji.fedoraproject.org/koji/buildinfo?buildID=135880 , though I don't think there's any relevant changes there. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Discussed at the blocker bug meeting today. This hardware may be ancient, but there's a lot of 'em out there: http://www.smolts.org/reports/view_device/Radeon%20R100%20QD%20%5BRadeon%207200%5D given that, we'll keep it on the list for now. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Just tried the new kernel and ati driver from comment #8 and the popups are still not readable, but perhaps there is one clue: Instead of a mostly black box, the popups now come up as a mostly gray box :-). I also noticed for the first time that the gdm login window has what might be a tooltip or something that comes up if you linger over a name. That tooltip is also coming up as just a gray box. As another possibly relevant historical clue, this old bug was submitted a long time ago for the same video card: https://bugs.freedesktop.org/show_bug.cgi?id=15846 That was screwing up the whole screen, but maybe whatever that was is still there but only screwing up some particular kind of windows? (Probably completely different, but I include it for completeness).
Please try booting your kernel with option: radeon.agpmode=-1 added to kernel boot line cmd.
Well, the popup was mostly black again instead of gray, but other than that the radeon.agpmode=-1 kernel option made no difference.
Just thought I'd add a note about a change in behavior on latest updates. Most things are still broken (mostly black box instead of toolbar in KDE, etc), but the tooltips in the gdm login prompt just showed up correctly rather than as black or gray boxes. Don't have a clue why the change would be restricted to tooltips, but maybe someone does. Current package versions: kernel-2.6.31.5-96.fc12.x86_64 xorg-x11-drv-ati-6.13.0-0.10.20091006git457646d73.fc12.x86_64 gdm-2.28.1-12.fc12.x86_64 gtk2-2.18.3-15.fc12.x86_64
we've been futzing with the default tooltips lately (making them blue and partly translucent and with rounded corners), I guess that may have something to do with it. to be clear, it's the fact that this bug renders kde mostly inoperable that bothers me about it. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I am not able to reproduce this one, can you take a picture a Tom ? Also does anyone know an easy to trigger those popup, for what ever reason i don't have any popup ever, neither with firefox or with selinux error message. Tom is there some application which shows same symptom. Tom after reading the FDO bug report i believe you don't suffer from Tom issue, well if Tom can provide picture that would to be assert this. My believe is that your issue was related to colormap. We had a bunch of fixes in last few weeks about that.
Jerome, I did suggest a couple of things in IRC but maybe you didn't see. Try either just logging into KDE (since it's claimed to affect lots of bits of KDE's interface), or try setting an appointment in Evolution for 1 minute in the future, you should get a pop up at the time of the appointment. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I'll do some screenshots when I get home (the last time I tried, the corruption was reproduced in the screenshot, so it wasn't just an artifact of being displayed wrong, the screen buffer was also a black box). (And that freedesktop report is really old, so I suspect it was indeed something completely different). Some ways to reproduce it: 1. Run a KDE session - the toolbar at the bottom of the screen and everything that pops up from the toolbar is just unreadable trash. Also the borders around windows are sort of corroded like they aren't all there. 2. In gnome, if you linger the mouse over a window manager decoration (like the [x] in the corner), you get a tooltip popup, the tooltips I've gotten from the window manager have all been black or gray boxes. (Weirdly, the tooltips inside various applications have been fine). 3. In firefox, about:config browser.download.manager.showAlertOnComplete should be set to true (the default) Then if you "Save As..." any old web page, a popup message appears when it is done - that popup is always black for me.
So it seems i can't reproduce that on 7000 or 7500. I don't have any 7200. Do you have same rendering issue when kms is disabled ? (boot kernel with nomodeset or with radeon.modeset=0)
Created attachment 367365 [details] screen dump showing firefox download finished popup This screendump was taken when booted with nomodeset, so clearly that had no effect. I did a "Save Link As..." on a chunk of fedora release notes, and the popup near the top right corner is what came out. As near as I can tell the screen dump looks exactly the same as the screen itself did when the message was up.
Do you have compiz enabled or desktop effect ?
Nope. In fact, if I bring up the Preferences>Desktop Effects item, it just shows a dialog that says desktop effects are not available.
glisse: i'm wondering if it's transparency? KDE 4 uses some effects like that by default, I think, which might explain why it's more screwed up... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I don't have any issue with KDE on 7000 or 7500, or on 9200 radeon, i have been looking at the code see if there is anythings obvious, but everythings seems fine.
Grmph, just as I was about to justify dropping this from the blocker list... <jon_vanalten> adamw: That's actually the exact issue I have. Old IBM T30, have to run with nomodeset in order for graphics to be useful at all, and the popup notifications are as described. jon doesn't have his laptop with him at present, until 'tonight' (6 hours or so in his timezone). However, Lenovo's site gives me this for 'T30': http://www-307.ibm.com/pc/support/site.wss/MIGR-42218.html which specifies: 16MB RADEON 7500 ATI Mobility video chipset so certainly sounds like the same problem. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I should specify - that means it happens on at least two somewhat different r100s, which makes it rather more worrying and justifies keeping it on the blocker list for at least a bit longer... -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Yes, I've had the unreadable cross-hatching patterned popup notifications, such as when connecting to wireless or vpn and other events, running a F12 Beta install on my old IBM T30. This was in Gnome, fresh install with absolutely no changes from ootb settings, but running with nomodeset. (I had extreme rendering issues without nomodeset, where the display would show up but everything was sort of pixellated and text was pretty much unreadable; I managed to make it through the install in this state!) I don't have the laptop with me atm but I can test anything you guys might want later tonight, approx 6PM EST, maybe a bit later.
(In reply to comment #26) > Yes, I've had the unreadable cross-hatching patterned popup notifications, such > as > when connecting to wireless or vpn and other events, running a F12 Beta install > on my old IBM T30. This was > in Gnome, fresh install with absolutely no changes from ootb settings, but > running with nomodeset. (I had extreme rendering issues without nomodeset, > where the display would show up but everything was sort of pixellated and text > was pretty much unreadable; I managed to make it through the install in this > state!) > > I don't have the laptop with me atm but I can test anything you guys might want > later tonight, approx 6PM EST, maybe a bit later. Can you try updating to latest on that laptop? The F12 beta is pretty old and there have been quite a few updates, including to X and the -ati driver since then.
Tom, Jon VanAlten says he only hits this with KMS *disabled*, with KMS enabled he doesn't. If I read correctly you say you hit it in both cases, right? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 367561 [details] panel and windecos in KDE not displayed Hi, I have fully updated all packages on my laptop. Still I have same problem. I've been trying in KDE too. This screenshot shows the extent of the problem. In gnome it is only the notification popups that show the issue. After some trial and error (and help on #fedora-devel and #fedora-kde) a workaround for at least gnome is to change the notification theme to "standard". It is worth noting that this issue *only* presents for me when I boot with nomodeset. Without this argument, as mentioned, I get an entirely different problem; possibly it is selecting a terrible resolution. I will also attach X log for that case.
Created attachment 367562 [details] X log without nomodeset
I'm not sure the kernel decides it can do modesetting with this driver, but with or without the nomodeset option I see the same behavior (I also see the text mode progress bar during boot, not a fedora bubble filling up).
is the text mode progress bar at native resolution or low, console resolution (like the BIOS screen)? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
I tried to reproduce this on a T42 with r7500/32MB and could not get any corruption under KDE with either the KDE taskbar or Firefox tooltips or otherwise during soem 5 minutes of browsing and usage. Modesetting was active. But, booting with "nomodeset", I can confirm that I get the *same* results as comment #29. The KDE taskbar at the bottom and all window borders are corrupted and have lots of black vertical lines. Since we're defaulting to modesetting though, and since modesetting + radeon seems to work OK (except for r100/r200/r300 glyph corruption which is bug #529081), do we really care that much about 'nomodeset' ?
we care about UMS (nomodeset) about as much as I care for the Maple Leafs, which is to say not at all. It's deprecated and full of dragons and in any case where KMS works but UMS doesn't we usually don't give a toss. HOWEVER, there is the wrinkle that Tom seems to wind up without mode setting whatever he does. I'm wondering if he's got something bad stuffed in grub config, now. Tom, can you see if you can reproduce this with a clean boot of a relatively recent F12 live CD - anything from http://alt.fedoraproject.org/pub/alt/nightly-composes/ would be fine? Also, can you post your /boot/grub/menu.lst here? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Tom, can we also get your dmesg (from a boot that ought to be with KMS enabled, i.e. one where you don't specify 'nomodeset') or /var/log/messages ? Thanks. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Re comment #32: Yes, the machine runs at BIOS resolution all the way until X actually starts, at which time it switches to the native 1920x1080. Don't know if this is relevant, but this video card clearly has a broken BIOS as far as picking a resolution goes. If I boot the system while the machine is connected to the monitor (via a KVM switch), then it reads the EDID info, picks a totally unusable resolution, and the screen says mode not supported up till X starts. If I remain switched away from it while the BIOS is initializing (till I hear the first beep), then switch the KVM switch back to it, it is running at some perfectly ordinary resolution like 1024x768 and I can see things boot. I'll get the logs when I get home today.
OK, so you've clearly got KMS disabled even when you don't think you've set 'nomodeset', which is why you're seeing this. This particular bug consistently only happens when KMS is disabled. Your dmesg might tell us why you're getting no KMS. At least now we have a sane story on when this bug happens. Jerome, I'll bet you can reproduce with 'nomodeset'. But that obviously means this particular corruption isn't a blocker. We _could_ consider a) vanaltj's weird display when KMS is enabled and b) whatever's causing Tom not to have KSM enabled (if it's not a user issue) to be blockers, I guess, but...meh. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Jon my guess is that you don't have KDE corruption if you add radeon.agpmode=-1 to your kernel boot command line. Tom dmesg would definitly be helpfull to see what's wrong also please install : yum install radeontool And do the following under working (nokms configuration) sudo radeontool regs > r7200-working-lvds
Created attachment 367672 [details] X log with nomodeset for comparison
Jerome, When I add radeon.agpmode=-1 (and leave off the nomodeset) it does not change anything. Actually, I see a brief message indicating that kernel argument is not recognized before it goes into graphical boot screen. This boot screen looks, for lack of a better word, pixellated (ie curves turn into zig-zags). When I do get to a desktop, the same effect applies to all icons, text, windows, window contents such as web page in firefox, etc. However, and I just noticed this for the first time a couple minutes ago, the desktop background image appears "normal". Last night I had tried to take a screen capture to upload, but it came out looking normal! I don't have a camera with me or I'd take an actual picture of the screen; I can do so later if need be.
a picture of the screen would be very helpful so we know what kind of breakage we're looking at, yeah. the 'argument not recognized' message is bogus and can be ignored - the parameter _does_ get passed on to the module and used. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Created attachment 367741 [details] /var/log/dmesg Here's the dmesg from my system. I just did a yum update to make sure I had the latest kernel, ati driver, etc, and this is the dmesg from rebooting after that update (still no KMS by default). Don't forget comment #2 - weird PCIE<->AGP bridge on motherboard may be relevant.
Created attachment 367742 [details] /boot/grub/grub.conf Here's the grub.conf which, as you can see, has no weird kernel args.
Created attachment 367744 [details] /var/log/messages Throwing in /var/log/messages for good measure.
Created attachment 367745 [details] radeontool regs output Finally, here is the output from running radeontool regs
does that tell you anything, jerome? tom, what happens if you try and force KMS on? boot with 'radeon.modeset=1' parameter. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Since my issue (with default boot params) appears to be separate, I've moved it to a new bug: https://bugzilla.redhat.com/show_bug.cgi?id=533314
With radeon.modeset=1, a kernel stack trace flashes up the screen faster than I can see anything during initrd processing, the screen resolution stays at the BIOS setting, and the progress bar runs really, really slow, gets to the end, and the machine is hung :-).
i guess that proves there's a reason it defaults to UMS =) jerome, is this helping you figure out the story? at this point, i'm officially dropping this as a blocker, i'm afraid. the impact is too limited. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Just tried this system again with the latest updates: kernel-2.6.32.9-67.fc12.x86_64 xorg-x11-drv-ati-6.13.0-0.21.20100219gite68d3a389.fc12.x86_64 No change in behavior. It doesn't believe it can do KMS on the system and the screwed up graphics are all still the same (KDE totally unusable, occasional popups screwed up in gnome).
Created attachment 407092 [details] Xorg.0.log Well, fedora 12 looks like the one brief shining (literally) moment for this ancient card. I just upgraded the system to fedora 13 and now "no signal" is the only thing my monitor will show if I try and start X. xorg-x11-drv-ati-6.13.0-1.fc13.x86_64 kernel-2.6.33.2-41.fc13.x86_64 I've attached the xorg log file for this attempt on fedora 13.
Switching Fedora version to 13. Tom, could you boot with radeon.modeset=1 drm.debug=15 into runlevel 5 and extract /var/log/dmesg and /var/log/Xorg.0.log from that attempt? -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Nope. I tried, but during boot, horrible kernel crashes happen and the system never gets far enough to write any log information to disk. If I let it sit around timing out udev operations it can eventually get slightly into interactive startup but hangs forever with the last thing on the screen being the "setting host name" message. (And in takes about 10 to 15 minutes to get that far).
This message is a reminder that Fedora 13 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 13. 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 '13'. 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 13'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 13 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 13 changed to end-of-life (EOL) status on 2011-06-25. Fedora 13 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.