Description of problem: Kernel.x86_64 2.6.22.4-65.fc7 update on 25th Aug, 2007 broke agpgart aperture checking in my AMD Athlon64 3000+ desktop with ASUS K8N MB, Nvidia nForce3 chipset and ATI RV280 [RADEON 9200 PRO] controller. It was not fixed in recent kernel 2.6.22.5-71.fc7 update. The problem manifests itself in that computer restart (warm boot) is no longer possible. When tried, booting process freezes right after "Booting the kernel." message is printed on screen. If, on the other hand, a cold boot is performed, the following error messages are printed (after 'Booting the kernel.'): agpgart: Aperture pointing to RAM agpgart: Aperture too small (0 MB) agpgart: No usable aperture found. agpgart: Consider rebooting with iommu=memaper=2 to get a good aperture However, this time booting is continued in normal fashion and it finishes with a working system. I've tried to correct the problem by: 1) downloading and installing latest K8N motherboard BIOS firmware (1011) to replace the original version (1003) 2) editing /boot/grub/grub.conf by adding alternately "iommu=memaper=2", "agp=no" and "noagp". None of these have corrected the problem. I'm attaching dmesg reports of 25th Aug and of 1st Aug. The latter dmesg was generated while kernel 2.6.22.1-33.fc7 was in use, but later kernels (-41 and -57) still found the aperture until kernel -65 was installed. My Smolt UUID: feed8339-bcc2-4000-ad71-5a14f2af6492 Version-Release number of selected component (if applicable): kernel.x86_64 2.6.22.4-65.fc7 AND kernel.x86_64 2.6.5-71.fc7 How reproducible: Every time Steps to Reproduce: 1. Perform a computer restart (warm boot) 2. 3. Actual results: Expected results: Additional info:
Created attachment 187651 [details] dmesg after kernel 2.6.22.4-65.fc7 was installed
Created attachment 187661 [details] dmesg before kernel 2.6.22.4-65.fc7 was installed Sorry, I forgot to fill in 'Expected results' and 'Actual results'. I expect to be able to restart (warm boot) the computer. Actual result is that I cannot.
In addition, when I run the newest kernel updates (-71 and -76) my computer sometimes (once or twice a day) inexplicably totally paralyzes. IIRC, this has never happened before in Fedora (I've been using Fedora since FC4, June 2005). Usually this freezing happens when I'm browsing Internet with Firefox-32. Mouse pointer disappears and even system monitor in my lower panel freezes. Restart button doesn't have any effect; I have to press "main switch" for 4 secs to restart the machine. I downloaded and installed (from koji.fedoraproject.org) kernel-2.6.22.2-57.fc7, which had already been replaced with newer kernels in my box. Not only does kernel -57 detect AGP aperture correctly, it also hasn't frozen once in the twelve hours I've been running it.
e820 mapping changed, there must be a bug in the backported changes.
Created attachment 199411 [details] dmesg after installing kernel-2.6.22.6-81.fc7.x86_64
Today's updates included kernel-2.22.6-81.fc7.x86_64. The new kernel did not provide any improvement with regard to either agpgart aperture checking or restart capability of my computer. On the contrary: if I try to restart my computer using kernel -81 the box goes into an endless loop of restarts. Each time I get as far as splash screen and its 5 sec timeout, and immediately after that the box restarts. The only way to get the computer up and running is cold boot. During boot I see agpgart complaining "No usable aperture found", but that doesn't prevent the box from getting up and running. However, the computer still inexplicably freezes especially when browsing the Internet. In fact, I had to cold boot the box once while writing this comment because my computer froze when I tried to search other agpgart bugs in this RedHat bugzilla with Firefox-32.
Hello, I'm reviewing this bug as part of the kernel bug triage project, an attempt to isolate current bugs in the fedora kernel. http://fedoraproject.org/wiki/KernelBugTriage I am CC'ing myself to this bug and will try and assist you in resolving it if I can. I'm re-assigning this to the relevant maintainer but in the meantime could you test with the latest kernel to see if there has been any change. As this is preventing your computer from booting I have changed the severity status to reflect this. If the problem no longer exists however then please close this bug CURRENTRELEASE indicating what you believe solved the problem for you.
Hello Cristopher, and thank you for taking an interest in this bug. For a while it looked like I was left with my own devices... I have tried the newest kernel (2.6.22.9-91) but it offered no improvement over earlier kernels since 2.6.22.4-65 as far as agpgart aperture check is concerned. However, I'd like to clarify one point before going further: ALL newer kernels (after and including kernel 2.6.22.4-65) allow me to _boot_ my computer (cold boot). NONE of them allow me to _reboot_ my computer (warm boot). All of them also fail to detect AGP aperture (128M) reserved in a BIOS setting. During cold boot agpgart error messages (in full in my original bug opening) are printed. Nevertheless the boot continues and the system gets up and running, but failure in AGP aperture detection while booting manifests itself in poor performance of graphics-intensive programs. Consequently e.g. GoogleEarth is painfully slow, and FireFox inexplicably freezes several times a day (the latter problem may or may not be related). I've done a bit of more testing, and the following may provide some help in isolating the problem: 1) If I COLD BOOT the computer, all four agpgart error messages are ALWAYS printed no matter which one of the five kernels I currently keep is selected. The kernels are (2.6.) 21-1.3228, 22.5-76, 22.6-81, 22.7-85 and 22.9-91. AGP aperture isn't detected in any case. 2) However, if I have chosen kernel 2.6.21-1.3228 and REBOOT the computer (warm boot), this time AGP aperture WILL be detected with consequent fast operation of GoogleEarth and no freezes in FireFox. Please note that the 21-1.3228 kernel is the only one of the five that WILL allow me to reboot; all others either freeze with screen full of gibberish or go into an endless loop of restarts right after splash screen 5 sec. timeout has elapsed. I'm sorry that I can only provide descriptive bug information. Firefox freezes leave nothing in dmesg or /var/log/messages. If any other logs or other data are needed, I'll be happy to supply them.
Does changing the aperture size in the BIOS setting help? Although this worked for you previously, it might be worth investigating if there is an update for your BIOS which resolves this - it seems to be reporting the wrong size and a previous workaround is no longer working around it. It might also be helpful to generate an lsmod output as well if you can.
(In reply to comment #9) > Does changing the aperture size in the BIOS setting help? No. This was one of the first things I tried after observing the problem with kernel 2.6.22.4-65 update. I've tried setting the aperture to 64M (and 32M, IIRC). Something goes wrong in detecting the BIOS AGP aperture setting, and it doesn't seem to matter what number is inserted there. > Although this worked > for you previously, it might be worth investigating if there is an update for > your BIOS which resolves this - it seems to be reporting the wrong size and a > previous workaround is no longer working around it. > As I say in my original bug report, I've replaced the original ASUS K8N mb BIOS flash firmware (1003) with their latest version (1011). This was done in an effort to correct the problem introduced by kernel 2.6.22.4-65 update. I'm not sure what you mean by 'workaround' here. I haven't written any scripts nor used any other tricks to make previous kernels work. They just worked - at least when rebooted after kernel updates. I very seldom switched the computer completely off - until I was forced to do so after kernel -65 update which refused to reboot. > It might also be helpful to generate an lsmod output as well if you can. No problem. Attached please find two lsmod output files. lsmod-1.3228.txt was generated while kernel 2.6.21-1.3228 was in use, and lsmod9-91.txt while using the newest -91 kernel. Please note that lsmod-1.3228.txt was produced only after kernel 3228 had been RESTARTED (warm boot). If, on the other hand, kernel 3228 is COLD BOOTED, its lsmod output is rather similar to that of kernel -91. Perhaps I should attach the lsmod output of a cold-booted 3228 kernel, too? The dmesg of cold-booted 3228 kernel contains an agpgart error message line that I haven't seen in other kernels' dmesg: "agpgart: Aperture conflicts with PCI mapping." However, when I _restart_ kernel 3228, this (and other agpgart error messages) disappear, and AGP aperture is both found and used.
Created attachment 213711 [details] lsmod output with kernel 2.6.22.9-91 in use
Created attachment 213721 [details] lsmod output with kernel 2.6.21-1.3228 in use
It is printing the MAC header from the packet: src address, dest address, and protocol ID. And wireless uses very large addresses in its headers internally...
Oops wrong bug.
I did some more testing and found a solution: Noting the similarity of RH BZ bugs 249174 and 251555, I decided to try one of the tricks mentioned: mem=510M in /etc/grub.boot. ˇˇˇˇˇˇˇˇ Not only did this allow warm boot of kernel 2.6.22.9-91, but AGP aperture was properly detected as well: [andie@cs78238023 ~]$ uname -r 2.6.22.9-91.fc7 [andie@cs78238023 ~]$ dmesg | grep agpgart agpgart: Detected AGP bridge 0 agpgart: Setting up Nforce3 AGP. agpgart: AGP aperture is 128M @ 0xf0000000 Linux agpgart interface v0.102 (c) Dave Jones agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V3 device at 0000:00:00.0 into 4x mode agpgart: Putting AGP V3 device at 0000:01:00.0 into 4x mode [andie@cs78238023 ~]$ Therefore I consider my problem solved and close it as WORKSFORME.
Sorry, I meant ... /etc/grub.conf.
We need to get this fixed properly.
(In reply to comment #17) > We need to get this fixed properly. I'm all for that. The fact remains that when I cold boot the computer, AGP aperture detection initially does not work irrespective of the kernel chosen. I have to reboot the computer to make it work. Then any of my five kernels can be used - provided the newer kernels (-76 and later) are rebooted with mem=510M kernel option.
Can you post the contents of /proc/iomem for the working and non-working kernels? Also, can you please try the Fedora8 Test3 Live CD when it's released tomorrow to see if the bug is in kernel 2.6.23-rc8?
Created attachment 215001 [details] /proc/iomem output for 2.6.22.9-91 kernel
(In reply to comment #19) > Can you post the contents of /proc/iomem for the working and non-working > kernels? All five kernels I have (-1.3228,5-76,6-81,7-85 and 9-91) work when rebooted. The only one *not* needing 'mem=510M' kernel option is -1.3228. None of the kernels work properly when cold-booted. I'm attaching /proc/iomem for the kernel I'm using now (9-91). I'll post the corresponding file for -1.3228 kernel after rebooting. Also, can you please try the Fedora8 Test3 Live CD when it's released > tomorrow to see if the bug is in kernel 2.6.23-rc8? Sure. Will it be in fedora-testing repo?
Created attachment 215061 [details] /proc/iomem output for 2.6.22.9-91 kernel when cold-booted On second thought you probably meant this: /proc/iomem output when cold-booted AND /proc/iomem output when rebooted (warm boot). Therefore I'm attaching another kernel 9-91 /proc/iomem output, this time the cold-booted version of it. I've also generated both cold and warm-booted versions of /proc/iomem output for the -1.3228 kernel, but I won't post them unless I'm asked to do so.
(In reply to comment #19) > > Also, can you please try the Fedora8 Test3 Live CD when it's released > tomorrow to see if the bug is in kernel 2.6.23-rc8? Sorry. Cold-booted F8-Test-3-Live shows this: [fedora@localhost ~]$ uname -r 2.6.23-0.214.rc8.git2.fc8 [fedora@localhost ~]$ dmesg | grep agpgart agpgart: Detected AGP bridge 0 agpgart: Aperture pointing to RAM agpgart: Aperture from AGP @ f0000000 size 4096 MB agpgart: Aperture too small (0 MB) agpgart: No usable aperture found. agpgart: Consider rebooting with iommu=memaper=2 to get a good aperture. Linux agpgart interface v0.102 [fedora@localhost ~] I'll try F8 Test 3 Live warm-booted later...
From your dmesg: Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup Can you enter your BIOS, hit Ctrl+F1 and enable this setting then re-test.
(In reply to comment #24) > > Your BIOS doesn't leave a aperture memory hole > Please enable the IOMMU option in the BIOS setup > I think it does. There has been an AGP aperture setting of 128 M in my BIOS since this computer was new (in June 2005). On the other hand, I haven't found a place in BIOS where I could set the IOMMU option. > Can you enter your BIOS, hit Ctrl+F1 and enable this setting then re-test. OK, I'll try this later. I didn't know of Ctrl+F1 having an effect in BIOS. Anyway, when I _warm-booted_ F8-Test-3-Live, I got the following: [fedora@localhost ~]$ uname -r 2.6.23-0.214.rc8.git2.fc8 [fedora@localhost ~]$ dmesg |grep agpgart agpgart: Detected AGP bridge 0 agpgart: Setting up Nforce3 AGP. agpgart: AGP aperture is 128M @ 0xf0000000 Linux agpgart interface v0.102 agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0. agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode [fedora@localhost ~]$ This looks definitely better - not only because no kernel options were necessary - but because AGP is now in 8x mode instead of the previous 4x. The problem of failing aperture check appears _always_ when I cold-boot the machine. I'm starting to think it is a timing problem, not an error in the code itself.
(In reply to comment #25) > (In reply to comment #24) > I think it does. There has been an AGP aperture setting of 128 M in my BIOS > since this computer was new (in June 2005). On the other hand, I haven't found a > place in BIOS where I could set the IOMMU option. > > Can you enter your BIOS, hit Ctrl+F1 and enable this setting then re-test. > OK, I'll try this later. I didn't know of Ctrl+F1 having an effect in BIOS. Hidden option on nForce3 boards apparently. Would be good to know if this is the case for you.
(In reply to comment #26) > (In reply to comment #25) > > (In reply to comment #24) > > > I think it does. There has been an AGP aperture setting of 128 M in my BIOS > > since this computer was new (in June 2005). On the other hand, I haven't found a > > place in BIOS where I could set the IOMMU option. > > > Can you enter your BIOS, hit Ctrl+F1 and enable this setting then re-test. > > OK, I'll try this later. I didn't know of Ctrl+F1 having an effect in BIOS. > > Hidden option on nForce3 boards apparently. Would be good to know if this is the > case for you. Sorry, this is a plain-vanilla K8N motherboard. I've been checking a few times all BIOS options, and IOMMU setting is _not_ one of them. Ctrl-F1 has no effect either, mere F1 gives General Help, such as: "Press ENTER to select". Ever since I first saw the agpgart error message: "Consider rebooting with iommu=memaper=2 to get a good aperture". I've been wondering why agpgart writer Dave Jones is so sure IOMMU is part of every BIOS - or kernel boot option.
Please could you attach dmidecode output (which you may need to install).
Created attachment 218191 [details] dmidecode output when warm-booted Attached please find... This file may look slightly different if/when the computer is cold-booted. I'm in the middle of doing some tests with boot_delay=N, so each boot is a long process. Let me know if you need a cold-boot version of this file...
(In reply to comment #4) > e820 mapping changed, there must be a bug in the backported changes. > It looks like you are on the right track here. I've done some testing with boot_delay=N option in the grub (with rhgb quiet removed), and I've seen something I didn't notice before. See below for details. In addition, /var/log/messages contain some interesting lines. If I COLD-BOOT the box (kernel 9-91), /var/log/messages has these lines: Oct 6 00:35:26 cs78238023 kernel: Checking aperture... Oct 6 00:35:26 cs78238023 kernel: CPU 0: aperture @ 9ef0000000 size 128 MB Oct 6 00:35:26 cs78238023 kernel: Aperture beyond 4GB. Ignoring. On the other hand, when I WARM-BOOT the box (kernel 9-91), messages reads: Oct 6 02:05:39 cs78238023 kernel: Checking aperture... Oct 6 02:05:39 cs78238023 kernel: CPU 0: aperture @ f0000000 size 128 MB Oct 6 02:05:39 cs78238023 kernel: Memory: 505540k/522240k available (2362k kernel code, 16312k reserved, 1400k data, 312k init) The question is, why would the kernel want to put aperture at 9ef0000000, well beyond the BIOS-provided physical RAM map upper limit of 100000000, when the box is cold-booted? And why does it put aperture at f0000000 when the box is warm-booted? One clue might be this: with boot option boot_delay=1200 I've noticed that during COLD BOOT screen reads: "aperture at 9ef0000000 128 MB" whereas during WARM BOOT the corresponding line reads: "aperture at 0xf0000000 128 MB". Whether the fact that '0x' prefix is missing in cold-boot message is significant, is beyond my knowledge. Even if it isn't, the address is clearly above reserved memory space. Small wonder the aperture setting is ignored. Complete /var/log/messages are available if needed.
Hello. I'm actually a xubuntu user but I'm experiencing a similar problem on my machine. Warm boots work correctly, but whenever I do a cold boot the "aperture size too small" message appears. Booting with IOMMU options doesn't help, while the aperture preference is correctly set in the bios setup. My box: AMD Sempron 3100+ ASUS K8N (bios ver. is 1011 beta 5) nForce3 250Gb chipset ATI Radeon 9600
It has been a while and one kernel release since the original reporter updated this bug therefore I'm putting this back into NEEDINFO state. Please could the kernel version in the summary be updated if you are still having issues. Cheers Chris
(In reply to comment #32) > It has been a while and one kernel release since the original reporter updated > this bug therefore I'm putting this back into NEEDINFO state. Please could the > kernel version in the summary be updated if you are still having issues. > > Cheers > Chris Yes, it's still the same problem - and now I'm using kernel 2.6.23.9-85.fc8. This issue has been with me since kernel 2.6.22.4-65.fc7, and *no* subsequent kernel update has rectified it. On the basis of comment #31 I assume the culprit is either the ASUS K8N mobo or some kernel module that doesn't cope with it. May I remind of the fact that prior to kernel 2.6.22.4-65.fc7 I had the same agpgart version (0.102) and all was well with it? Therefore I don't think it's the agpgart program itself. As far as I know IOMMU is not an option in K8N BIOS - any version of the latter.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. 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 '7'. 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 7'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 7 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. 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. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
My present kernel is 2.6.24.7-92.fc8 and the problem persists. As requested, I've changed Fedora version number to 8 which I've been using since December 2007. I've tried Fedora-9-x86_64-Live and didn't see apgart error messages but that probably doesn't mean the problem is fixed in Fedora 9.
(In reply to comment #35) > My present kernel is 2.6.24.7-92.fc8 and the problem persists. As requested, > I've changed Fedora version number to 8 which I've been using since December 2007. > I've tried Fedora-9-x86_64-Live and didn't see apgart error messages but that > probably doesn't mean the problem is fixed in Fedora 9. ...and indeed, when I COLD-BOOT the F9-x86_64-Live CD and execute the following commands in Gnome terminal window: [fedora@localhost ~]$ uname -r 2.6.25-14.fc9.x86_64 [fedora@localhost ~]$ dmesg | grep aperture Checking aperture... Node 0: aperture @ 7ef0000000 size 128 MB Your BIOS doesn't leave a aperture memory hole Mapping aperture over 65536 KB of RAM @ 4000000 agpgart: No usable aperture found. agpgart: Consider rebooting with iommu=memaper=2 to get a good aperture. [fedora@localhost ~]$ dmesg | grep agpgart agpgart: Detected AGP bridge 0 agpgart: Aperture pointing to RAM agpgart: Aperture from AGP @ f0000000 size 4096 MB agpgart: Aperture too small (0 MB) agpgart: No usable aperture found. agpgart: Consider rebooting with iommu=memaper=2 to get a good aperture. Linux agpgart interface v0.103 [fedora@localhost ~]$ ..nothing has changed since agpgart aperture detection first broke in F7 last August - except for the fact that now the kernel does not crash like it did then. Kernel crash was however caused by improper memory allocation for my 512M of RAM, not as a result of failed aperture detection.
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. 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 '8'. 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 8'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 8 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
Well, things have gradually improved since my initial report of a F7 problem. Since "Linux agpgart interface v0.102" was replaced with "Linux agpgart interface v0.103" at some recent update, my AGP V3 device is now controlled by 'agpgart-amd64'. This means I now have at least 32M of AGP aperture regardless of whether the box is cold-booted or warm-booted. I have updated this bug report first to deal with F8 and now with F9. The remaining problem seems to be of minor significance: if the box is cold-booted I get only 32M of AGP aperture though the BIOS setting is 128M. Only if the box is warm-booted, the full 128M is reserved for AGP aperture. The problem seems to persist in placing the aperture at an improper address when the box is cold-booted. From dmesg when cold-booted: "Aperture beyond 4GB. Ignoring. . . Checking aperture... Node 0: aperture @ 1ef0000000 size 128 MB agpgart-amd64 0000:00:00.0: AGP aperture is 32M @ 0xf0000000" whereas the corresponding lines when warm-booted are: "Checking aperture... Node 0: aperture @ f0000000 size 128 MB agpgart-amd64 0000:00:00.0: AGP aperture is 128M @ 0xf0000000" Though little harm seems to result from aperture being only 32M after a cold boot, I'd like to see this problem solved. There are other K8N mobos around.
I have a NODUS3 mobo, which is an HP-branded ASUS A8M2N-LA. Like the OP, I have an Athlon 64 (mine is 4600+ stepping 02) with an nVidia chipset. On boot, I get a similar message under F10: Checking aperture... No AGP bridge found Node 0: aperture @ 20000000 size 32 MB Aperture pointing to e820 RAM. Ignoring. Your BIOS doesn't leave a aperture memory hole Please enable the IOMMU option in the BIOS setup This costs you 64 MB of RAM Mapping aperture over 65536 KB of RAM @ 20000000 My BIOS does not have any IOMMU-related options. This is kernel-2.6.27.9-163.fc10.x86_64
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
I had Fedora 10 installed for about 3 months, and the agpgart performance was similar to that in Fedora 9 (comment #38): when cold-booted the aperture is 32M and when warm-booted, it is the 128M set in BIOS. Now that I upgraded F10 to F11, I am no longer able to test this bug in F10. My F11 installation is not yet working properly so I cannot comment on it. Anyway, I changed the version from F9 to F10.
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
Since I've got Fedora 11 now working and this bug does not appear in it, I think it is time to close this bug. Will someone please do it for me?
Original reporter no longer has this problem. Closing.