mouse usage causes Xorg CPU usage to spike, and mouse pointer becomes less responsive

I get the same message as David in comment #36, then the stream of no space messages with jerky window and cursor behaviour.

Fully up-to-date F13,

kernel-2.6.33.5-124.fc13.x86_64
xorg-x11-drv-nouveau-0.0.16-6.20100423git13c1043.fc13.x86_64
xorg-x11-server-Xorg-1.8.0-17.fc13.x86_64

nVidia Corporation G84M [Quadro NVS 140M] (rev a1)

I started getting these messages yesterday, I suspect it was when I experienced a sudden very high load and non-responsiveness - I was running a windows machine inside virtualbox so that I could run gotomeeting, and I was given control of the meeting. When I would click on something in the vm nothing would happen until I moved the mouse out of the virtualbox.
But I've continued to get the messages at a lower rate even after suspending the windows machine.
kernel= 2.6.32.14-127.fc12.x86_64

I had this problem a while ago and rolled back nouveau and the problem went away (well it didn't happen again - but of course that's no certainty that the bug was not present in the earlier versions)

The old nouveau that appears to be OK is:
xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2ef
(that's the one I rolled back to when the mouse problem first showed itself)

5 days ago I did a full update that included:
kernel-2.6.32.16-141.fc12.x86_64 and
xorg-x11-drv-nouveau-0.0.15-21.20091105gite1c2efd.fc12.x86_64
and the problem has happened again today (for the first time since the rollback)

Xorg.0.log info:

First nVidia message is:
nVidia Corporation GeForce 8600 GTS rev 161, Mem @ 0xf6000000/16777216, 0xe0000000/268435456, 0xf4000000/33554432, I/O @ 0x0000b000/128, BIOS @ 0x????????/131072

I use a USB mouse, log says:
Microsoft Microsoft 5-Button Mouse with IntelliEye(TM)

I also have a USB Bamboo that the log finds BEFORE the mouse:
Wacom BambooFun 6x8
(I don't use the pen)

The rest of the log looks like status dumps without any error messages.

In my case it's a dual display and acts even stranger when the problem occurs (randomly?):
The left display shows the mouse correctly (but jerky)
In the right display (which has the menu bar) the mouse works but it is invisible
More strange: the mouse image is partially still shown on the edge of the left screen while using the right screen

When the screen saver comes on the mouse is still visible in the left screen
It doesn't fix the problem when the screen comes back
(thought I'd mention that because I've seen it said elsewhere)

It maybe happens when mplayer is playing fullscreen
(so a fullscreen app may be needed to activate the bug)
Of course when the problem wasn't there I was using the current mplayer version constantly also

The first dmesg error was:
[drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

followed by lots of the cursor messages (both 'hiding' and 'unhiding')

Minor updates on previous post:
I only boot runlevel 3 and thus always use startx
(as user "root")

Once the problem has occurred:
X menu System->"Log Out root..." fails to go back to the console
(the screen clears to just showing the backgrounds and then stops)

OS is of course unaffected by this - ssh login works fine
(I use that to "shutdown -r now")

I've rolled back to xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2ef
again (nothing else changed) and will report if it happens again with this
version

Logout messages of Xorg.0.log (before logout stops):

(II) AT Translated Set 2 keyboard: Close
(II) UnloadModule: "evdev"
(II) Macintosh mouse button emulation: Close
(II) UnloadModule: "evdev"
(II) UnloadModule: "wacom"
(II) UnloadModule: "wacom"
(II) UnloadModule: "wacom"
(II) Wacom BambooFun 6x8: removing automatically added devices.
(II) UnloadModule: "wacom"
(II) Microsoft Microsoft 5-Button Mouse with IntelliEye(TM): Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
(II) Power Button: Close
(II) UnloadModule: "evdev"
(II) NOUVEAU(0): NVLeaveVT is called.
(II) NOUVEAU(0): Closed GPU channel 2

No errors seem to be reported in that log

Also now had the same problem occur with the older RPM:
xorg-x11-drv-nouveau-0.0.15-17.20091105gite1c2ef

Also, the fullscreen app (mplayer) was not running when it occurred.

Had the same messages for dmesg, /var/log/messages, /var/log/Xorg.0.log as before.
(except no cursor hide/unhide messages)

This time I also got the extra shutdown message (after trying to logout)
dmesg:
[drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2
/var/log/messages:
Jul 30 12:34:08 ... kernel: [drm] nouveau 0000:01:00.0: nouveau_channel_free: freeing fifo 2

However, I have found another problem with my system that may have something to do with the nouveau bug presenting itself.
My USB mouse is possibly failing and switches on and off sometimes ... easy for me to see while dragging windows around, because it sometimes lets go of a window but I haven't released the left mouse button
(I only realised what was going on after my previous comments)

Created attachment 451152
Provide info on the Evo channel in debugfs

I was able to do some debugging on this issue today, and have a mosly reproducible test case (~90-95%) on my laptop (also using an external monitor). Here's nouveau's spiel about the card on boot of the 2.6.34.7-56.fc13.x86_64 kernel.

[drm] nouveau 0000:01:00.0: Detected an NV50 generation card (0x086900a2)
[drm] nouveau 0000:01:00.0: Attempting to load BIOS image from PRAMIN
[drm] nouveau 0000:01:00.0: ... appears to be valid
[drm] nouveau 0000:01:00.0: BIT BIOS found
[drm] nouveau 0000:01:00.0: Bios version 60.86.68.00
[drm] nouveau 0000:01:00.0: TMDS table revision 2.0 not currently supported
[drm] nouveau 0000:01:00.0: Found Display Configuration Block version 4.0
[drm] nouveau 0000:01:00.0: Raw DCB entry 0: 01000323 00010034
[drm] nouveau 0000:01:00.0: Raw DCB entry 1: 02011300 00000028
[drm] nouveau 0000:01:00.0: Raw DCB entry 2: 02022312 00010010
[drm] nouveau 0000:01:00.0: Raw DCB entry 3: 010333f1 00c0c070
[drm] nouveau 0000:01:00.0: Raw DCB entry 4: 0000000e 00000000
[drm] nouveau 0000:01:00.0: DCB connector table: VHER 0x40 5 14 2
[drm] nouveau 0000:01:00.0: 0: 0x00000041: type 0x41 idx 0 tag 0xff
[drm] nouveau 0000:01:00.0: unknown type, using 0x40
[drm] nouveau 0000:01:00.0: 1: 0x00000100: type 0x00 idx 1 tag 0xff
[drm] nouveau 0000:01:00.0: 2: 0x00001255: type 0x55 idx 2 tag 0x07
[drm] nouveau 0000:01:00.0: unknown type, using 0x31
[drm] nouveau 0000:01:00.0: 3: 0x00000310: type 0x10 idx 3 tag 0xff
[drm] nouveau 0000:01:00.0: 4: 0x00000311: type 0x11 idx 4 tag 0xff
[drm] nouveau 0000:01:00.0: 5: 0x00000313: type 0x13 idx 5 tag 0xff
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 0 at offset 0xC11C
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 1 at offset 0xC486
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 2 at offset 0xD0C7
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 3 at offset 0xD1B9
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table 4 at offset 0xD3B3
[drm] nouveau 0000:01:00.0: Parsing VBIOS init table at offset 0xD418
[drm] nouveau 0000:01:00.0: 0xD418: Condition still not met after 20ms, skipping following opcodes
[drm] nouveau 0000:01:00.0: 0xB1D6: parsing output script 0
[drm] nouveau 0000:01:00.0: 0xB34C: parsing output script 0
[drm] nouveau 0000:01:00.0: 0xA228: parsing output script 0
[drm] nouveau 0000:01:00.0: Detected 256MiB VRAM
[drm] nouveau 0000:01:00.0: 512 MiB GART (aperture)
[drm] nouveau 0000:01:00.0: DCB encoder 1 unknown
[drm] nouveau 0000:01:00.0: TV-1 has no encoders, removing
[drm] nouveau 0000:01:00.0: gpio tag 0xff not found
[drm] nouveau 0000:01:00.0: gpio tag 0xff not found
[drm] nouveau 0000:01:00.0: Allocating FIFO number 1
[drm] nouveau 0000:01:00.0: nouveau_channel_alloc: initialised FIFO 1
[drm] nouveau 0000:01:00.0: allocated 1920x1200 fb: 0x40230000, bo ffff8800790a2400
fbcon: nouveaufb (fb0) is primary device
[drm] nouveau 0000:01:00.0: 0xB083: parsing clock script 0
fb0: nouveaufb frame buffer device
[drm] Initialized nouveau 0.0.16 20090420 for 0000:01:00.0 on minor 0
[drm] nouveau 0000:01:00.0: 0xB199: parsing clock script 1
[drm] nouveau 0000:01:00.0: 0x1085: parsing clock s...

Wow, I'm impressed, many thanks for getting that. FWIW I always have at least 10 xterms open and "xlock -mode blank" is my screensaver, so I always saw the issue after a couple of days at most.

I'm adding a 'me too' to this bug under F13.

Dual Screens, when manifested cursor has issues drawing on left hand screen, appears ok on right hand screen.

lspci;
01:00.0 VGA compatible controller: nVidia Corporation GT216 [GeForce GT 220] (rev a2)

Driver;
xorg-x11-drv-nouveau-0.0.16-8.20100423git13c1043.fc13.i686

happens with 2 hours of a reboot under kernel-PAE-2.6.34.7-56.fc13.i686, can take several days with kernel-PAE-2.6.34.6-54.fc13.i686.

/var/log/messages
Oct 18 11:09:00 cbr-sjw-dt kernel: [drm] nouveau 0000:01:00.0: EvoCh 0 Mthd 0x0000 Data 0x00000400 (0x0002 0x01)

Happy to work with people on this one, it's making this workstation nearly unusable.

I have not seen the original behaviour I reported since long, but now that I switched to F14 I guess the best course of action is to close this report and let users on a different release (this was for F12, which is EOL in about one month anyway) or different cards from mine open more specific bug reports.

Same for me. Has not happened once in a very long time (more than 6 months).

Still happening every so often on F12
(I swapped the flaky mouse out long ago)

Current nouveau is:
xorg-x11-drv-nouveau-0.0.15-21.20091105gite1c2efd.fc12.x86_64

Really is annoying sometimes to have to kill everything and shut down to fix the problem

(I've ALWAYS booted 'init 3' on all Linux servers because I don't think graphics drivers should be needed to boot a server ... the drivers for a while now have been forced upon us even during an 'init 3' boot ... but I've also had 'init 3' on all my desktops too ... pity it doesn't help with this problem.
My other F12 desktop - dual screen LCD + TV connected - uses that 'other' driver - obviously due to TV-Out - and though I don't work on it much - just for playing DVD's or other videos - I've still never had this problem with it)

I still see the behavior I reported (see comment 35) on F-13 once in awhile. Steve Walsh (comment 44) appears to be seeing the same thing. I'll ask again: is this really the same bug? If not, perhaps bug 548545 should be revived.

This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12. 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 '12'.

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 12'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 12 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

I use Slackware, this has got nothing to do with Fedora 12, if this bug gets closed I'm giving up on this and switching to the closed nvidia driver.

Please respect the maintainer and dont be rude.

You should be aware of the fact that this bugzilla instance is to be used with RHEL and Fedora only not for everydistro out there so please file your report either to slackware bugzilla instance if they have one or directly upstream with the nouveau maintainers.

However you are welcome to download the latest Fedora release ( 14 ) install it and try to see if you still experience this problem and if so you can make note of that on this bug.

Thank you.

As the original reporter, I need to note this was for a specific version of nuoveau (the one in F12) with my specific card (with ID in the summary) and that I did not experience anymore mouse movement issues (now I'm on F14, no issues there as well)

If you are running any other combo, I advice to open another, separate report

Created attachment 457771
Band-aid patch that solves the problem for me

Continuing the work I started in comment 42, I was also seeing the "EvoCh 0 Mthd
0x0000 Data 0x00000400 (0x0002 0x01)" messages as everyone else. I did more investigation, and found that not using the last 32 bytes of the Evo ring buffer solved the issue for me -- I no longer get the EvoCh messages, which directly lead to the "no space" messages as seen by the original report and the jerky mouse movements reported by others. This bug is current as of F13, and is likely in F14 and rawhide, as the issue is not yet fixed upstream.

Prior to the patch, dma.max was getting the value 1022. &'ing with ~7 was equivalent to subtracting another 6 entries from that value. I also tried ~3, but that did not fix the issue. I was asked on IRC to try subtracting 5, 4 etc to narrow down the minimum value, and my testing confirmed that subtracting 6 (&= ~7) was minimal. I also tried changing some of the register settings above (NV50_PDISPLAY_CHANNEL_UNK2, etc) but was not successful in teasing out meaning or a fix using them. I have not tried playing with the RAMHT for Evo.

I don't like that my patch involves yet more magic numbers without explanation, but it has been stable for me for the past few weeks, and solves my cursor problem.

Created attachment 457773
Test program that provokes the problem

This program hides/unhides the cursor for the number of cycles given on the command line, default 1. I use this to push the Evo channel's index through the rewind and expose the EvoCh messages. It's much easier than moving the cursor from window to window for a while until things wrap. With my patch, this survives thousands of iterations.

Reassigning to 13 as suggested by Ben on IRC; that will avoid the auto-close.

(In reply to comment #54)
> Created attachment 457773 [details]
> Test program that provokes the problem
>
> This program hides/unhides the cursor for the number of cycles given on the
> command line, default 1. I use this to push the Evo channel's index through the
> rewind and expose the EvoCh messages. It's much easier than moving the cursor
> from window to window for a while until things wrap. With my patch, this
> survives thousands of iterations.

Can you give the list of libs needed to build the program ?

Thanks.

(In reply to comment #56)
> (In reply to comment #54)
> > This program hides/unhides the cursor for the number of cycles given on the
> > command line, default 1. I use this to push the Evo channel's index through the
> > rewind and expose the EvoCh messages. It's much easier than moving the cursor
> > from window to window for a while until things wrap. With my patch, this
> > survives thousands of iterations.
>
> Can you give the list of libs needed to build the program ?
>
> Thanks.

cc -o cycle_cursor -O3 -Wall cycle_cursor.c -lX11

David, I've been using your patch in comment 53 and it's resolved the issue for me too, thank you very much.

I experienced the same problem on Fedora 14: "no space while unhiding cursor".
This issue is very annoying because the system becomes so slow that I need to restart it.

I'd like to test the patch in comment 53, but I cannot find nv50_display.c.
I've installed the kernel sources (yum install kernel-devel) but the folder "/usr/src/kernels/2.6.35.6-48.fc14.x86_64/drivers/gpu/drm/nouveau" is empty.

I think that the Severity and Priority for this bug should be higher, because, when it occurs, the system becomes so slow that is almost unusable and on my laptop occurs every day.

My video card is:
01:00.0 VGA compatible controller: nVidia Corporation GT216 [Quadro FX 880M] (rev a2)

I'm having the invisible cursor issue and the cycle_cursor app doesn't help with that problem.

I'm not seeing ANY errors in either the .xsession_errors file or in /var/log/messages* .

00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev a2)

(In reply to comment #62)
> I'm having the invisible cursor issue and the cycle_cursor app doesn't help
> with that problem.
>
> I'm not seeing ANY errors in either the .xsession_errors file or in
> /var/log/messages* .
>
> 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev
> a2)

This one is actually a hardware bug, and not related in any way.

I don't know if my issue is related to this bug, but on my laptop (Compal JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no more sees the sound card (HDA Intel) and falls back to dummy audio output. No problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to report it, as the kernel changelog reads:

* Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
- nouveau: add quirk for iMac G4 (rhbz#505161)
- nouveau: add workaround for display hang on GF8+ (rhbz#537065)
- nouveau: don't reject 3D object creation on NVAF (MBA3)

but this seems the only one related to my hardware.
dmesg doesn't report anything suspicious, but I'm available for any further testing on this issue.

This on F14 x86_64.

(In reply to comment #63)
> (In reply to comment #62)
> > I'm having the invisible cursor issue and the cycle_cursor app doesn't help
> > with that problem.
> >
> > I'm not seeing ANY errors in either the .xsession_errors file or in
> > /var/log/messages* .
> >
> > 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev
> > a2)
>
> This one is actually a hardware bug, and not related in any way.

Odd, Since in Fedora 12 it worked fine (cursor showed up without any issues). It only seemed to happen after a certain point. Next time I have to reboot, I'll swap to an external card vs. the built in video).

(In reply to comment #64)
> I don't know if my issue is related to this bug, but on my laptop (Compal
> JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no
> more sees the sound card (HDA Intel) and falls back to dummy audio output. No
> problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to
> report it, as the kernel changelog reads:
>
> * Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
> - nouveau: add quirk for iMac G4 (rhbz#505161)
> - nouveau: add workaround for display hang on GF8+ (rhbz#537065)
> - nouveau: don't reject 3D object creation on NVAF (MBA3)
>
> but this seems the only one related to my hardware.
> dmesg doesn't report anything suspicious, but I'm available for any further
> testing on this issue.
>
> This on F14 x86_64.
What was your previous kernel? I don't see how these changes could possibly cause what you see.

(In reply to comment #65)
> (In reply to comment #63)
> > (In reply to comment #62)
> > > I'm having the invisible cursor issue and the cycle_cursor app doesn't help
> > > with that problem.
> > >
> > > I'm not seeing ANY errors in either the .xsession_errors file or in
> > > /var/log/messages* .
> > >
> > > 00:05.0 VGA compatible controller: nVidia Corporation C51G [GeForce 6100] (rev
> > > a2)
> >
> > This one is actually a hardware bug, and not related in any way.
>
> Odd, Since in Fedora 12 it worked fine (cursor showed up without any issues).
> It only seemed to happen after a certain point. Next time I have to reboot,
> I'll swap to an external card vs. the built in video).

I guess it's possible something in nouveau now triggers the hw bug more reliably. All previous reports indicate that it would usually come up find, and disappear randomly at some point until a reboot. I used to have the effected hardware (the machine has since died), and even the NVIDIA binary driver could not bring it back once it went.

(In reply to comment #66)
> (In reply to comment #64)
> > I don't know if my issue is related to this bug, but on my laptop (Compal
> > JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no
> > more sees the sound card (HDA Intel) and falls back to dummy audio output. No
> > problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to
> > report it, as the kernel changelog reads:
> >
> > * Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
> > - nouveau: add quirk for iMac G4 (rhbz#505161)
> > - nouveau: add workaround for display hang on GF8+ (rhbz#537065)
> > - nouveau: don't reject 3D object creation on NVAF (MBA3)
> >
> > but this seems the only one related to my hardware.
> > dmesg doesn't report anything suspicious, but I'm available for any further
> > testing on this issue.
> >
> > This on F14 x86_64.
> What was your previous kernel? I don't see how these changes could possibly
> cause what you see.

Previous kernel was 2.6.35-59, and audio still works if I boot it. Yeah I know, it's weird. I'm looking after getting some more info about it, but I doubt I'll have time today...

(In reply to comment #68)
> (In reply to comment #66)
> > (In reply to comment #64)
> > > I don't know if my issue is related to this bug, but on my laptop (Compal
> > > JFL92) with a 8600M GT card, kernel 2.6.35.8-60 killed my sound. Pulseaudio no
> > > more sees the sound card (HDA Intel) and falls back to dummy audio output. No
> > > problem at all with 2.6.35.8-59. I'm not sure if this is the right bug to
> > > report it, as the kernel changelog reads:
> > >
> > > * Fri Nov 19 2010 Ben Skeggs <email address hidden> 2.6.35.8-60
> > > - nouveau: add quirk for iMac G4 (rhbz#505161)
> > > - nouveau: add workaround for display hang on GF8+ (rhbz#537065)
> > > - nouveau: don't reject 3D object creation on NVAF (MBA3)
> > >
> > > but this seems the only one related to my hardware.
> > > dmesg doesn't report anything suspicious, but I'm available for any further
> > > testing on this issue.
> > >
> > > This on F14 x86_64.
> > What was your previous kernel? I don't see how these changes could possibly
> > cause what you see.
>
> Previous kernel was 2.6.35-59, and audio still works if I boot it. Yeah I know,
> it's weird. I'm looking after getting some more info about it, but I doubt I'll
> have time today...

Sorry disregard my bug report, I verified it's a problem with the new dracut update that triggers when a new initramfs is built, not a kernel problem. Coincidentally the two things overlapped on my system. Sorry for wasting your time.

As I already asked, how may I find nv50_display.c to try the patch in comment 53?

(In reply to comment #70)
> As I already asked, how may I find nv50_display.c to try the patch in comment
> 53?

You don't need to, it's in kernel-2.6.35.8-60.fc14 (http://koji.fedoraproject.org/koji/buildinfo?buildID=205566)

Okay, thanks a lot!
I still have the kernel 2.6.35.6-48.fc14.x86_64.

The kernel-2.6.35.8-60 is still a release candidate. May I install it simple by downloading the rpm or it's better that I wait for the official release (is there already a date?) and then updating with yum?

I've now installed the newer kernel (2.6.35.8-60). I let you known, if the problem ("no space while unhiding cursor") occurs again.

I'm using the newer kernel (2.6.35.8-60) for about one month and I haven't experienced the problem above ("no space while unhiding cursor") any more.

In my opinion this problem is fixed. Thanks a lot!

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.