Bug 278721 - agpgart aperture checking fails with kernel 2.6.22.4-65.fc7 update
agpgart aperture checking fails with kernel 2.6.22.4-65.fc7 update
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
10
x86_64 Linux
medium Severity high
: ---
: ---
Assigned To: Dave Airlie
Fedora Extras Quality Assurance
: Reopened
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-05 12:06 EDT by Antti Huhtala
Modified: 2009-11-19 12:34 EST (History)
6 users (show)

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


Attachments (Terms of Use)
dmesg after kernel 2.6.22.4-65.fc7 was installed (20.04 KB, text/plain)
2007-09-05 12:06 EDT, Antti Huhtala
no flags Details
dmesg before kernel 2.6.22.4-65.fc7 was installed (19.85 KB, text/plain)
2007-09-05 12:12 EDT, Antti Huhtala
no flags Details
dmesg after installing kernel-2.6.22.6-81.fc7.x86_64 (19.89 KB, text/plain)
2007-09-19 08:04 EDT, Antti Huhtala
no flags Details
lsmod output with kernel 2.6.22.9-91 in use (3.32 KB, text/plain)
2007-10-02 12:59 EDT, Antti Huhtala
no flags Details
lsmod output with kernel 2.6.21-1.3228 in use (3.47 KB, text/plain)
2007-10-02 13:02 EDT, Antti Huhtala
no flags Details
/proc/iomem output for 2.6.22.9-91 kernel (1.18 KB, text/plain)
2007-10-03 16:07 EDT, Antti Huhtala
no flags Details
/proc/iomem output for 2.6.22.9-91 kernel when cold-booted (1.18 KB, text/plain)
2007-10-03 16:55 EDT, Antti Huhtala
no flags Details
dmidecode output when warm-booted (18.18 KB, text/plain)
2007-10-05 19:46 EDT, Antti Huhtala
no flags Details

  None (edit)
Description Antti Huhtala 2007-09-05 12:06:09 EDT
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:
Comment 1 Antti Huhtala 2007-09-05 12:06:09 EDT
Created attachment 187651 [details]
dmesg after kernel 2.6.22.4-65.fc7 was installed
Comment 2 Antti Huhtala 2007-09-05 12:12:59 EDT
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.
Comment 3 Antti Huhtala 2007-09-08 05:21:16 EDT
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.
Comment 4 Chuck Ebbert 2007-09-10 19:02:33 EDT
e820 mapping changed, there must be a bug in the backported changes.

Comment 5 Antti Huhtala 2007-09-19 08:04:13 EDT
Created attachment 199411 [details]
dmesg after installing kernel-2.6.22.6-81.fc7.x86_64
Comment 6 Antti Huhtala 2007-09-19 08:27:32 EDT
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.
Comment 7 Christopher Brown 2007-10-01 11:19:42 EDT
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.
Comment 8 Antti Huhtala 2007-10-01 13:24:02 EDT
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.
Comment 9 Christopher Brown 2007-10-02 07:12:11 EDT
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.
Comment 10 Antti Huhtala 2007-10-02 12:57:42 EDT
(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.
Comment 11 Antti Huhtala 2007-10-02 12:59:56 EDT
Created attachment 213711 [details]
lsmod output with kernel 2.6.22.9-91 in use
Comment 12 Antti Huhtala 2007-10-02 13:02:31 EDT
Created attachment 213721 [details]
lsmod output with kernel 2.6.21-1.3228 in use
Comment 13 Chuck Ebbert 2007-10-02 17:59:19 EDT
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...
Comment 14 Chuck Ebbert 2007-10-02 18:04:53 EDT
Oops wrong bug.
Comment 15 Antti Huhtala 2007-10-02 20:21:01 EDT
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.
Comment 16 Antti Huhtala 2007-10-02 20:30:38 EDT
Sorry, I meant ... /etc/grub.conf.
Comment 17 Chuck Ebbert 2007-10-03 11:46:39 EDT
We need to get this fixed properly.
Comment 18 Antti Huhtala 2007-10-03 13:38:28 EDT
(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.
Comment 19 Chuck Ebbert 2007-10-03 15:32:06 EDT
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?
Comment 20 Antti Huhtala 2007-10-03 16:07:46 EDT
Created attachment 215001 [details]
/proc/iomem output for 2.6.22.9-91 kernel
Comment 21 Antti Huhtala 2007-10-03 16:09:23 EDT
(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?
Comment 22 Antti Huhtala 2007-10-03 16:55:23 EDT
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.
Comment 23 Antti Huhtala 2007-10-04 18:13:48 EDT
(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...
Comment 24 Christopher Brown 2007-10-04 18:22:08 EDT
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.
Comment 25 Antti Huhtala 2007-10-04 18:55:40 EDT
(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.
Comment 26 Christopher Brown 2007-10-05 06:22:33 EDT
(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.
Comment 27 Antti Huhtala 2007-10-05 09:51:49 EDT
(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.
Comment 28 Christopher Brown 2007-10-05 16:26:44 EDT
Please could you attach dmidecode output (which you may need to install).
Comment 29 Antti Huhtala 2007-10-05 19:46:44 EDT
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...
Comment 30 Antti Huhtala 2007-10-05 20:31:31 EDT
(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.
Comment 31 Marco Adele 2008-01-01 09:18:48 EST
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


Comment 32 Christopher Brown 2008-01-13 17:57:19 EST
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
Comment 33 Antti Huhtala 2008-01-14 00:21:09 EST
(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.
Comment 34 Bug Zapper 2008-05-14 10:14:39 EDT
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
Comment 35 Antti Huhtala 2008-05-16 09:19:12 EDT
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.
Comment 36 Antti Huhtala 2008-05-16 16:05:38 EDT
(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.
Comment 37 Bug Zapper 2008-11-26 02:45:18 EST
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
Comment 38 Antti Huhtala 2008-11-26 23:01:02 EST
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.
Comment 39 Jack Tanner 2008-12-19 12:02:06 EST
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
Comment 40 Bug Zapper 2009-06-09 18:49:10 EDT
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
Comment 41 Antti Huhtala 2009-06-13 04:13:47 EDT
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.
Comment 42 Bug Zapper 2009-11-18 02:52:51 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 43 Antti Huhtala 2009-11-18 19:17:00 EST
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?
Comment 44 John Poelstra 2009-11-19 12:34:26 EST
Original reporter no longer has this problem.  Closing.

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