Bug 466695 - Unstable opengl with xorg-x11-drv-ati and r300
Unstable opengl with xorg-x11-drv-ati and r300
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-ati (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-12 19:02 EDT by David Andersson
Modified: 2009-12-18 01:33 EST (History)
14 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-12-18 01:33:37 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Xorg.0.log without xorg.conf and with nomodeset (1.99 MB, text/plain)
2008-11-25 02:36 EST, David Andersson
no flags Details
etracer > etracer.log 2>&1 (459 bytes, text/plain)
2008-11-25 02:53 EST, David Andersson
no flags Details

  None (edit)
Description David Andersson 2008-10-12 19:02:21 EDT
Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:
Every time I use opengl or compositing

Steps to Reproduce:
1. Start an opengl program
2. Watch it crash and burn within seconds to a couple of minutes
3.
  
Actual results:
Crash, hard lockup

Expected results:


Additional info:
Comment 1 David Andersson 2008-10-12 19:03:53 EDT
Nexuiz lock ups the computer within 1-2 minutes giving
[driAllocateTexture:635] unable to allocate texture
Ouch! vram_validate failed
nexuiz-glx: r300_mem.c:820: bufmgr_classic_post_submit: Assertion `!batch_bo->pending_count' failed.
Comment 2 David Andersson 2008-10-12 19:12:21 EDT
Extreme Tuxracer crasches, but does not lock up the system, with:
Internal error or hardware lockup: bo_map: buffer is still pending.
Comment 3 Mads Kiilerich 2008-10-23 13:19:04 EDT
This could be a duplicate of Bug 465760 ...
Comment 4 Matěj Cepl 2008-10-24 09:11:47 EDT
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) 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.
Comment 5 Matěj Cepl 2008-11-24 11:11:28 EST
Reporter, could you please reply to the previous question? If you won't reply in one month, I will have to close this bug as INSUFFICIENT_DATA. Thank you.
Comment 6 David Andersson 2008-11-25 02:35:59 EST
Ok, here comes the Xorg.0.log; This is with nomodeset passed to the kernel and no xorg.conf.
Nexuiz seems to be much more stable now as does compiz. Extreme tux racer still locks up hard (se attached log).
Comment 7 David Andersson 2008-11-25 02:36:58 EST
Created attachment 324569 [details]
Xorg.0.log without xorg.conf and with nomodeset
Comment 8 David Andersson 2008-11-25 02:53:35 EST
Created attachment 324570 [details]
etracer > etracer.log 2>&1

No clues in this one i'm afraid
Comment 9 Bug Zapper 2008-11-25 22:49:16 EST
This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle.
Changing version to '10'.

More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Steven Côté 2008-12-12 07:44:07 EST
There hasn't been any movement on this bug for a while, so I thought I'd add my experiences.

I'm finding anything that uses OpenGL will lock the entire computer up (no mouse, no keyboard, no ssh connections). I've tried several apps including compiz, glxgears, and a couple different games, including tux racer. All with the same result; a total lock after just a couple seconds.

I've tried booting with nomodeset, but had the same result.

I'm using a R480 with xorg-x11-drv-ati-6.9.0-61.fc10.x86_64
Comment 11 Sean E. Millichamp 2008-12-29 20:15:43 EST
(In reply to comment #10)
> There hasn't been any movement on this bug for a while, so I thought I'd add my
> experiences.
> 
> I'm finding anything that uses OpenGL will lock the entire computer up (no
> mouse, no keyboard, no ssh connections). I've tried several apps including
> compiz, glxgears, and a couple different games, including tux racer. All with
> the same result; a total lock after just a couple seconds.
> 
> I've tried booting with nomodeset, but had the same result.
> 
> I'm using a R480 with xorg-x11-drv-ati-6.9.0-61.fc10.x86_64

I am seeing that too.  Hard and immediate system locks.  I must use the reset button to recover.  It is likely going to drive me back to Fedora 9 soon since it seems to happen at least once per day when I invoke something OpenGL without meaning to.

xorg-x11-drv-ati-6.9.0-63.fc10.x86_64

# lspci -vv
05:00.0 VGA compatible controller: ATI Technologies Inc R480 [Radeon X850XT Platinum (PCIE)] (prog-if 00 [VGA controller])
	Subsystem: ATI Technologies Inc Device 0b12
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 16 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 2: Memory at dffe0000 (64-bit, non-prefetchable) [size=64K]
	Region 4: I/O ports at e000 [size=256]
	Expansion ROM at dffc0000 [disabled] [size=128K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
			ExtTag+ AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop+
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <2us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
	Capabilities: [80] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
		Address: 0000000000000000  Data: 0000
	Kernel modules: radeon

05:00.1 Display controller: ATI Technologies Inc R480 [Radeon X850XT Platinum (PCIE)] (Secondary)
	Subsystem: ATI Technologies Inc Device 0b13
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0, Cache Line Size: 16 bytes
	Region 0: Memory at dfff0000 (64-bit, non-prefetchable) [size=64K]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [58] Express (v1) Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0, Latency L0s <256ns, L1 <4us
			ExtTag- AttnBtn- AttnInd- PwrInd- RBE- FLReset-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr- TransPend-
		LnkCap:	Port #0, Speed 2.5GT/s, Width x16, ASPM L0s L1, Latency L0 <256ns, L1 <2us
			ClockPM- Suprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- Retrain- CommClk+
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x16, TrErr- Train- SlotClk+ DLActive- BWMgmt- ABWMgmt-
Comment 12 Roland Pallai 2009-01-01 17:51:31 EST
(In reply to comment #10)
> I'm finding anything that uses OpenGL will lock the entire computer up (no
> mouse, no keyboard, no ssh connections). I've tried several apps including
> compiz, glxgears, and a couple different games, including tux racer. All with
> the same result; a total lock after just a couple seconds.
> 
> I've tried booting with nomodeset, but had the same result.

My problem is exactly like he described. glxgears locks up after a few seconds. I came from Fedora 8, that worked well. I've a clean Fedora 10 install, no /etc/X11/xorg.conf

I'm using R480 [Radeon X800 GTO (PCIE)] with xorg-x11-drv-ati-6.9.0-63.fc10.i386
Comment 13 Klaasjan Brand 2009-01-02 04:39:33 EST
Same problem here with glxgears (and other GL apps).

Using xorg-x11-drv-ati-6.9.0-63.fc10.i386 on an ATI Radeon X800 XL (R430) (PCIE) card in an Athlon64-based system with nforce4 chipset.

Logs show nothing strange, but system locks up hard.
Comment 14 Dag 2009-01-28 04:48:23 EST
Same problem here with ATI redeon X700 Mobility, up to date Fedora 10 i386.
PCIE / 64MB
Pentium M740 + Centrino

Laptop reference: Acer Aspire 5502WXMi

xorg-x11-drv-ati-6.9.0-63.fc10.i386
I have no xorg.conf.
I tried with a Xorg.conf from my previously working F9 (upgrade from F9 to F10) to force radeon driver and get the same lock up.
Then tried a fresh install of F10 without xorg.conf and with my working F9 xorg.conf: same lock up.

Logs show nothing, but running a GLX app (ie glxgears or enabling desktop effects) locks up the computer after 2 or 3 seconds of working time.

The lock up is total: no keyboard/mouse/input device working, no ping response, no ssh, no HDD light anymore.
Only a hard reset or power off "fixes" the issue.
It used to work like charm until I upgraded from Fedora9 to Fedora10 2 days ago.

Note that I never use GLX apps, I just wanted to try the Desktop Effects on F10, so I don't know if the issue was happening on F9 just before upgrading:
I'm sure that it used to work a month or so ago on F9.

I found several other maybe-related-bugs:
https://bugzilla.redhat.com/show_bug.cgi?id=476590
https://bugzilla.redhat.com/show_bug.cgi?id=474963

http://bugs.freedesktop.org/show_bug.cgi?id=19008
Comment 15 Dag 2009-01-28 04:54:33 EST
forgot about my kernel:
2.6.27.12-170.2.5.fc10.i686
Comment 16 Dag 2009-01-30 04:08:53 EST
I did some testing and comparison with an up-to-date Fedora9 installation (xorg-x11-drv-ati-6.8.0-19.fc9.i386 with kernel-2.6.27.9-73.fc9.i686 ) yesterday on the same computer and found out:
- 2D movie watching on F10 is slower than F9: watching a movie gets really annoying because of many frame dropping and glitches (video and sound stops for half a second) just as if computer was overloaded but it's not the case (just a display issue)
- moving windows is slow on F10 and it takes time to redraw screen (not much time but you can see it)
- 3D is 10 times slower on F10 than on F9: glxgears displays 200fps before freezing the computer (2000fps on F9)

So 3D definitely works on F9 (up-to-date fresh install) and all is OK with Video and 2D display.
So I downgraded to F9 for now and will install F10 on a new partition on my HDD to make some testing from time to time.

Hope those informations will be useful.
Comment 17 François Cami 2009-02-02 17:58:53 EST
Davis, Dag,
Could you try with nomodeset in the kernel command-line ?
Alternatively, could you try the latest xorg-x11-drv-ati build in Koji :
http://koji.fedoraproject.org/koji/buildinfo?buildID=80819
Thanks in advance
Comment 18 Dag 2009-02-05 08:18:08 EST
Hi François,
I tried "nomodeset" at boot, and:
- it deactivated the 'graphical "solar" boot'
- 2D is faster
- 3D is only 2 times slower than on Fedora9 (so it's much better but still it sometimes hangs for a few 1/10th of a second (lag) )
- glxgears doesn't freeze the computer (at least for 5 minutes) when the window is at it's normal startup size (which may be 200x200), I tried to hide/unhide, move the window, minimize, etc... no freeze.
- BUT: glxgears freezes the computer if its window is maximized (not fullscreen) and you hide/unhide the glxgears' window with some other software (I used a Firefox maximized window to hide/unhide the glxgears' maximized window): after a few hide/unhide the computer completely freezes everytime, sometimes displaying a completely black screen. This issue is not reproducible on Fedora 9 (same computer, with versions I've already given).
- I did not test fullscreen glx app

So, nomodeset definitely improves stability and speed of the 2D and 3D display with radeon driver for me.

I'll try the Koji driver later this week-end probably.
bye for now
Comment 19 Dag 2009-02-06 09:43:22 EST
Hi again!
I tried the Koji package (xorg-x11-drv-ati-6.10.0-2.fc10.i386.rpm) and (without nomodeset):
- glxgears freezes the computer "only" after the mouse or a window gets over it (partially or completely) so it's kind of an "improvement"
- no improvement on speed (2D or 3D)

with nomodeset, it's the same as the F10 official radeon driver (see my post above this one).

So, it's a bit better than the official driver without nomodeset, but it's still unusable.

bye for now.
Comment 20 ufa 2009-03-04 07:38:19 EST
Hello,

I am having a hard time too with the ati open driver in Fedora 10 - AMD64. My card is a ati x600. When I boot the system, it goes somewhat normal (a little slow but usable). But as time and use goes (15 minutes or less sometimes) it begins to lock the system up (mouse freezes and returns). Sometimes the freezes lasts over a minute, and return. Nothing wrong in logs. When the machine is "freezed", I can ssh there, and nothing seems wrong, so I suppose the bug is in Xorg only.

Here is my excellent glxgears  results: 

374 frames in 5.0 seconds = 74.653 FPS
925 frames in 5.0 seconds = 184.671 FPS
364 frames in 5.0 seconds = 72.698 FPS
359 frames in 5.0 seconds = 71.771 FPS
189 frames in 7.0 seconds = 26.899 FPS
113 frames in 6.9 seconds = 16.416 FPS
7 frames in 6.0 seconds =  1.160 FPS
4 frames in 6.0 seconds =  0.666 FPS
11 frames in 6.1 seconds =  1.804 FPS
5 frames in 6.0 seconds =  0.829 FPS
6 frames in 6.0 seconds =  0.998 FPS

With a ubuntu live cd I can get over 1300 fps as a glxgears result.

Is there anything I can do?
Comment 21 François Cami 2009-03-04 16:25:07 EST
ufa, 

this is probably a different bug, please file it separatedly.

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 22 ufa 2009-05-01 12:47:24 EDT
Maybe, but I am having unstability too, i.e., I just launch some opengl game and in about 20 seconds it freezes my X or reboots the machine :(
Comment 23 ufa 2009-05-06 13:35:55 EDT
Just upgraded to F11 and the issues keep on.
Comment 24 Sami Juvonen 2009-06-07 16:31:36 EDT
I have the same problem on F11.

Starting Google Earth crashes with the splash page still showing with this message on the terminal:

CS section size missmatch start at (r300_cmdbuf.c,emit_cb_offset,254) 16 vs 7
CS section end at (r300_cmdbuf.c,emit_cb_offset,264)

interesting about ...offset,254 and offset,264 above - typo somewhere?

kernel 2.6.29.4-167.fc11.x86_64
xorg-x11-drv-ati-6.12.2-14.fc11.x86_64

Card is:
(--) PCI:*(0@1:0:0) ATI Technologies Inc RV505 CE [Radeon X1550 64-bit] rev 0, Mem @ 0xd0000000/268435456, 0xfe9f0000/65536, I/O @ 0x0000b000/256, BIOS @ 0x????????/131072

This is a fresh install, no xorg.conf. I upgraded from F10 because GE (and Second Life) had a different problem...
Comment 25 Sami Juvonen 2009-06-07 16:36:31 EDT
Ah, got this:

BUG: unable to handle kernel NULL pointer dereference at 00000000000003da
IP: [<ffffffffa005d5d2>] radeon_gem_ib_free+0x21/0xc4 [radeon]
PGD cccf7067 PUD ccd7a067 PMD cccd7067 PTE 0
Oops: 0000 [#1] SMP 
last sysfs file: /sys/devices/virtual/net/virbr0/statistics/collisions
CPU 0 
Modules linked in: vfat fat fuse ipt_MASQUERADE iptable_nat nf_nat rfcomm bridge stp llc bnep sco l2cap sunrpc ip6t_REJECT nf_conntrack_ipv6 ip6table_filter ip6_tables ipv6 cpufreq_ondemand acpi_cpufreq freq_table dm_multipath kvm_intel kvm uinput snd_hda_codec_realtek snd_hda_intel snd_ice1712 snd_ice17xx_ak4xxx snd_ak4xxx_adda snd_hda_codec snd_cs8427 snd_hwdep snd_ac97_codec snd_pcm snd_timer ac97_bus snd_i2c snd_mpu401_uart snd_rawmidi snd_seq_device snd i2c_i801 r8169 iTCO_wdt iTCO_vendor_support pata_pdc2027x soundcore snd_page_alloc btusb bluetooth pcspkr usb_storage mii ata_generic pata_acpi radeon drm i2c_algo_bit i2c_core [last unloaded: microcode]
Pid: 3036, comm: googleearth-bin Not tainted 2.6.29.4-167.fc11.x86_64 #1 G33T-M2
RIP: 0010:[<ffffffffa005d5d2>]  [<ffffffffa005d5d2>] radeon_gem_ib_free+0x21/0xc4 [radeon]
RSP: 0018:ffff8800ccd1bcc8  EFLAGS: 00210246
RAX: 0000000000000010 RBX: 000000000000000a RCX: 0000000000000000
RDX: ffff8800ccd1bdd8 RSI: 00000000fffffff2 RDI: ffff8800ccd1bd28
RBP: ffff8800ccd1bcf8 R08: ffff880028029af0 R09: 0000000000000000
R10: 0000000000000000 R11: 0000000000000000 R12: ffff88012cc70800
R13: ffff8800ccd1bd28 R14: 0000000000000000 R15: ffff88012cc70e38
FS:  0000000000000000(0000) GS:ffffffff817b7000(0063) knlGS:00000000f7fa6700
CS:  0010 DS: 002b ES: 002b CR0: 0000000080050033
CR2: 00000000000003da CR3: 00000000ccc99000 CR4: 00000000000026e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process googleearth-bin (pid: 3036, threadinfo ffff8800ccd1a000, task ffff8800ccda5c00)
Stack:
 ffff88012cc70800 ffff88012d0ad000 0000000000000000 ffff88012cc70800
 00000000fffffff2 ffff880105c99800 ffff8800ccd1bdb8 ffffffffa005fb29
 ffff8800ccd1bd38 0000000000000004 0000000000000524 ffff8800ccc86000
Call Trace:
 [<ffffffffa005fb29>] radeon_cs_ioctl+0x35e/0x3ad [radeon]
 [<ffffffff811828b7>] ? avc_has_perm+0x5c/0x71
 [<ffffffff810b3b5f>] ? unmap_vmas+0x826/0x83b
 [<ffffffffa005f7cb>] ? radeon_cs_ioctl+0x0/0x3ad [radeon]
 [<ffffffffa0012b7e>] drm_ioctl+0x20e/0x2c1 [drm]
 [<ffffffff810c0239>] ? free_pages_and_swap_cache+0x26/0x80
 [<ffffffff810cb93f>] ? virt_to_head_page+0xe/0x31
 [<ffffffff811843a7>] ? file_has_perm+0x83/0x8e
 [<ffffffffa00727ed>] radeon_compat_ioctl+0x6c/0x83 [radeon]
 [<ffffffff81109f85>] compat_sys_ioctl+0xc8/0x367
 [<ffffffff810dca60>] ? path_put+0x22/0x26
 [<ffffffff81088462>] ? audit_syscall_entry+0x11e/0x14a
 [<ffffffff813ab88d>] ? trace_hardirqs_off_thunk+0x3a/0x6c
 [<ffffffff81034bb7>] sysenter_dispatch+0x7/0x4b
 [<ffffffff813ab851>] ? trace_hardirqs_on_thunk+0x3a/0x3c
Code: 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 56 41 55 41 54 53 48 83 ec 10 0f 1f 44 00 00 48 8b 1f 48 8b 57 30 45 31 f6 49 89 fd <4c> 8b a3 d0 03 00 00 49 8b 84 24 28 06 00 00 48 8b 08 48 39 51 
RIP  [<ffffffffa005d5d2>] radeon_gem_ib_free+0x21/0xc4 [radeon]
 RSP <ffff8800ccd1bcc8>
CR2: 00000000000003da
---[ end trace a689487942536e2c ]---
Comment 26 François Cami 2009-06-07 17:16:26 EDT
Sami,

Could you file a bug against xorg-x11-drv-ati on F11 ?
Please include me in CC.

Thanks

---
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers
Comment 27 Sami Juvonen 2009-06-08 11:08:36 EDT
Opened bug 504631 against xorg-x11-drv-ati on F11.
Comment 28 Bug Zapper 2009-11-18 03:33:48 EST
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10.  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 '10'.

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 10'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 10 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 29 Bug Zapper 2009-12-18 01:33:37 EST
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 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.