Bug 522970 - UMS:R100:7200 Mesa GNOME 'slider'-themed notifications and many KDE 4 interface elements corrupted
Summary: UMS:R100:7200 Mesa GNOME 'slider'-themed notifications and many KDE 4 interfa...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati
Version: 13
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Jérôme Glisse
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: card_R100/c
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-09-12 22:04 UTC by Tom Horsley
Modified: 2013-01-10 05:28 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2011-06-27 14:22:47 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)
Xorg log file (86.38 KB, text/plain)
2009-09-14 20:53 UTC, Tom Horsley
no flags Details
screen dump showing firefox download finished popup (743.98 KB, image/png)
2009-11-03 22:16 UTC, Tom Horsley
no flags Details
panel and windecos in KDE not displayed (220.65 KB, image/png)
2009-11-05 03:00 UTC, Jon VanAlten
no flags Details
X log without nomodeset (36.43 KB, text/plain)
2009-11-05 03:02 UTC, Jon VanAlten
no flags Details
X log with nomodeset for comparison (37.11 KB, text/plain)
2009-11-05 17:30 UTC, Jon VanAlten
no flags Details
/var/log/dmesg (34.44 KB, text/plain)
2009-11-05 22:10 UTC, Tom Horsley
no flags Details
/boot/grub/grub.conf (1.30 KB, text/plain)
2009-11-05 22:14 UTC, Tom Horsley
no flags Details
/var/log/messages (718.84 KB, text/plain)
2009-11-05 22:17 UTC, Tom Horsley
no flags Details
radeontool regs output (519 bytes, text/plain)
2009-11-05 22:19 UTC, Tom Horsley
no flags Details
Xorg.0.log (47.35 KB, text/plain)
2010-04-16 13:07 UTC, Tom Horsley
no flags Details

Description Tom Horsley 2009-09-12 22:04:04 UTC
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.

Comment 1 Tom Horsley 2009-09-14 20:53:19 UTC
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

Comment 2 Tom Horsley 2009-09-14 20:58:22 UTC
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).

Comment 3 Adam Williamson 2009-09-14 21:25:49 UTC
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

Comment 4 Tom Horsley 2009-09-26 16:35:04 UTC
Noticed another message box that comes up mostly black: The firefox
"All downloads have completed" message box.

Comment 5 Tom Horsley 2009-09-26 20:42:26 UTC
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.

Comment 6 Jesse Keating 2009-10-21 23:15:36 UTC
Is this still happening?  There have been some updates recently.

Comment 7 Tom Horsley 2009-10-22 00:18:46 UTC
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).

Comment 8 Adam Williamson 2009-10-23 17:15:52 UTC
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

Comment 9 Adam Williamson 2009-10-23 21:00:37 UTC
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

Comment 10 Tom Horsley 2009-10-23 21:13:08 UTC
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).

Comment 11 Jérôme Glisse 2009-10-24 11:00:25 UTC
Please try booting your kernel with option: radeon.agpmode=-1 added to kernel boot line cmd.

Comment 12 Tom Horsley 2009-10-24 12:22:06 UTC
Well, the popup was mostly black again instead of gray, but other than
that the radeon.agpmode=-1 kernel option made no difference.

Comment 13 Tom Horsley 2009-10-30 21:33:01 UTC
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

Comment 14 Adam Williamson 2009-10-31 05:21:06 UTC
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

Comment 15 Jérôme Glisse 2009-11-03 17:31:37 UTC
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.

Comment 16 Adam Williamson 2009-11-03 17:58:46 UTC
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

Comment 17 Tom Horsley 2009-11-03 18:06:28 UTC
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.

Comment 18 Jérôme Glisse 2009-11-03 19:46:30 UTC
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)

Comment 19 Tom Horsley 2009-11-03 22:16:56 UTC
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.

Comment 20 Jérôme Glisse 2009-11-04 10:58:17 UTC
Do you have compiz enabled or desktop effect ?

Comment 21 Tom Horsley 2009-11-04 11:41:12 UTC
Nope. In fact, if I bring up the Preferences>Desktop Effects item, it
just shows a dialog that says desktop effects are not available.

Comment 22 Adam Williamson 2009-11-04 16:22:13 UTC
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

Comment 23 Jérôme Glisse 2009-11-04 16:47:13 UTC
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.

Comment 24 Adam Williamson 2009-11-04 17:21:24 UTC
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

Comment 25 Adam Williamson 2009-11-04 17:22:08 UTC
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

Comment 26 Jon VanAlten 2009-11-04 17:30:38 UTC
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.

Comment 27 Dan Williams 2009-11-05 02:30:04 UTC
(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.

Comment 28 Adam Williamson 2009-11-05 02:44:03 UTC
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

Comment 29 Jon VanAlten 2009-11-05 03:00:58 UTC
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.

Comment 30 Jon VanAlten 2009-11-05 03:02:41 UTC
Created attachment 367562 [details]
X log without nomodeset

Comment 31 Tom Horsley 2009-11-05 03:05:16 UTC
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).

Comment 32 Adam Williamson 2009-11-05 03:16:58 UTC
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

Comment 33 Dan Williams 2009-11-05 05:02:12 UTC
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' ?

Comment 34 Adam Williamson 2009-11-05 06:30:01 UTC
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

Comment 35 Adam Williamson 2009-11-05 08:35:17 UTC
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

Comment 36 Tom Horsley 2009-11-05 12:24:14 UTC
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.

Comment 37 Adam Williamson 2009-11-05 16:54:51 UTC
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

Comment 38 Jérôme Glisse 2009-11-05 17:28:03 UTC
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

Comment 39 Jon VanAlten 2009-11-05 17:30:59 UTC
Created attachment 367672 [details]
X log with nomodeset for comparison

Comment 40 Jon VanAlten 2009-11-05 17:48:50 UTC
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.

Comment 41 Adam Williamson 2009-11-05 17:50:36 UTC
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

Comment 42 Tom Horsley 2009-11-05 22:10:49 UTC
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.

Comment 43 Tom Horsley 2009-11-05 22:14:17 UTC
Created attachment 367742 [details]
/boot/grub/grub.conf

Here's the grub.conf which, as you can see, has no weird kernel args.

Comment 44 Tom Horsley 2009-11-05 22:17:01 UTC
Created attachment 367744 [details]
/var/log/messages

Throwing in /var/log/messages for good measure.

Comment 45 Tom Horsley 2009-11-05 22:19:27 UTC
Created attachment 367745 [details]
radeontool regs output

Finally, here is the output from running
radeontool regs

Comment 46 Adam Williamson 2009-11-06 01:57:05 UTC
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

Comment 47 Jon VanAlten 2009-11-06 02:26:14 UTC
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

Comment 48 Tom Horsley 2009-11-06 03:05:59 UTC
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 :-).

Comment 49 Adam Williamson 2009-11-06 03:14:53 UTC
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

Comment 50 Bug Zapper 2009-11-16 12:19:23 UTC
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

Comment 51 Tom Horsley 2010-03-07 00:10:13 UTC
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).

Comment 52 Tom Horsley 2010-04-16 13:07:58 UTC
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.

Comment 53 François Cami 2010-05-04 05:51:15 UTC
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

Comment 54 Tom Horsley 2010-05-04 22:11:21 UTC
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).

Comment 55 Bug Zapper 2011-06-02 17:45:25 UTC
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

Comment 56 Bug Zapper 2011-06-27 14:22:47 UTC
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.


Note You need to log in before you can comment on or make changes to this bug.