Description of problem:
SMP Opteron systems do not have to have the AGP controller assigned to PCI
position 0:0.0. The Tyan 2885 K8W is a system that has the 8151 AGP controller
assigned to PCI position 4:0.0. Changes made to the 2.4.21 kernel prevent the
AGP controller from being discovered.
Version-Release number of selected component (if applicable):
Boot RHEL3 AS on the Tyan 2885 K8W. `dmesg | grep agpgart`. The kernel should
create an AGP aperture.
Steps to Reproduce:
1. Install and boot RHEL3 AS on a Tyan 2885 K8W.
2. Open a System Terminal as root
3. Run `dmesg | grep agpgart`
agpgart: Maximum main memory to use for agp memory: 2423M
agpgart: No supported devices found
agpgart: Maximum main memory to use for agp memory: 2423M
agpgart: Detected AMD 8151 chipset
agpgart: AGP aperture is 512M @ 0xc0000000
Following patch should fix the problem:
diff -u -u -r1.39 agpgart_be.c
--- linux/drivers/char/agp/agpgart_be.c 2003/10/28 23:20:20 1.39
+++ linux/drivers/char/agp/agpgart_be.c 2003/10/28 23:26:02
@@ -67,6 +67,7 @@
static void flush_cache(void);
+static int agp_init_one(struct pci_dev *dev);
static struct agp_bridge_data agp_bridge;
static int agp_try_unsupported __initdata = 0;
@@ -6490,15 +6491,24 @@
static int __init agp_find_supported_device(void)
struct pci_dev *dev = NULL;
- u8 cap_ptr = 0x00;
+ int ret = -ENODEV;
if (hp_zx1_gart_init() == 0)
- if ((dev = pci_find_class(PCI_CLASS_BRIDGE_HOST << 8, NULL)) == NULL)
- return -ENODEV;
+ while ((dev = pci_find_class(PCI_CLASS_BRIDGE_HOST << 8, dev)) != NULL)
+ ret = agp_init_one(dev);
+ if (ret != -ENODEV)
+ return ret;
+static int __init agp_init_one(struct pci_dev *dev)
+ u8 cap_ptr = 0x00;
agp_bridge.dev = dev;
I'll take ownership of this, appears to be related to bug 104388 which I'm
*** Bug 108733 has been marked as a duplicate of this bug. ***
Ahh... is it me or is this patch incomplete? Where is the body of the
The body of agp_init_one() is the (old) body of the
agp_find_supported_device(). agp_init_one() is called
in a loop by agp_find_supported_device(), and does all
the detection that agp_find_supported_device() used to
do, but only for one device.
Created attachment 96685 [details]
scan all the bridges looking for agp
I'm not sure what the suggested patch was made against, doesn't look
like our RHEL 3 sources nor virgin 2.4.21 kernel sources. In our code
HP ZX1 was conditionalized to scan all the buses in a similar way so
the fix was just to add X86_64 to the conditional compilation.
Mark wrote in a private email that the fix is not sufficient because
the same problem will manifest itself with an i386 kernel when run on
a Tyan system.
I believe the code change is safe for all architectures, I'm not sure
why it had been conditionalized only for ia64 other than as a safety
to minimize risk exposure on architectures that located AGP on bus 0.
If we made this change for i386 also (actually it would make most
sense not to conditionalize against any architecture) then that change
would effect our largest installed base at the last minute before U1
freezes (tonight). Our preference is to leave the fix conditionalized
against x86_64 for U1 and remove the conditionalization for U2 when we
have more time for testing. With that in mind I'm going to re-open the
bug for U2 and make a new patch which remove the architecture
Actually, it is probably a better idea to include the patch ASAP,
and flag it as build_rawhide, so that it gets widespread Fedora
Core 2 development testing. That way if it majorly whacks anything
we've got a better chance of finding out sooner.
Did you re-open this Mike?
The patch is against 2.4 kernel for RHEL3. FC2 is a 2.6 kernel, with
as I understand it a new AGP implementation. RHEL4 will also be based
on a 2.6 kernel. Dave Jones is maintaining the 2.6 agp driver. I'm not
even sure if this issue exists in the the 2.6 agpgart driver, I
haven't looked at the new code, but in any event I think this is in
John: Actually... you reopened it. ;o)
Click on the link at the bottom of the page "View Bug Activity". ;o)
With respect to comment #9, we never did do any testing prior to U2
with the fix applied to all architectures, there have been no systems
identified since which might need the patch applied, RHEL4 will move
to a 2.6 kernel which has a new agpgart implementation. I'm going to
close this (again), I see no prudent reason at this point to rock the
With respect to comment #9, this problem can occur on x86
installations running on the Opteron based Tyan 2885 board. Please
enable it for all AMD Opteron supported architectures (AMD64, x86).
NTSI of Germany has been emailing me, trying to get AGP support on a
Tyan 2885 with RHEL3 for x86. Obviously, they can't, because even
with the 2.4.21-11 kernel, this fix is not enabled for x86 systems.
Please enable this fix for all Opteron systems (x86 and AMD64).
RHEL3 U2 is the next release vehicle, it is for all practical purposes
frozen. The change being suggested would impact the vast majority of
systems we install on with little or no opportunity to test on the
extensive array of systems RHEL3 U2 will be installed on, the risk is
too great to consider for U2. It will however be folded into our next
quarterly update, U3.
Created attachment 98500 [details]
scan all buses on all arches
same patch as before but no longer conditionalized on architecture
new patch that does not conditionalize for architecture submitted for
A fix for this problem has just been committed to the RHEL3 U3
patch pool (in kernel version 2.4.21-15.1.EL).
This fix does not work for x86 kernels on the K8W
Are you saying only x86 kernels on the K8W are failing? Does the x86
kernel work on other tyan systems? Are these failures occuring in the
kernel specificed in comment #26?
Yes, only x86 kernels are failing to recognize agp on the K8W.
I haven't tried it on other tyan boards. I'll boot it up on my
K7 based tyan tiger and see what happens. I haven't tried
2.4.21-15.1.EL, but I have tried 2.4.21-13-EL with the suggested fix.
I also tried the patch at the beginning of this bug post as well with
the agp_init_one. Where can I download the 2.4.21-15.1.EL source to try?
The patch in the bug report is not what we are using. Our fix went
into RHEL U2 but only for x86_64 kernels NOT x86. The generalized fix
which will work for both x86 and x86_64 is what Ernie was referring to
in comment #26, or so I believe. You will have to ask Ernie or whoever
is managing your partner relationship to get this kernel.
Donald, the 2.4.21-15.1.EL kernel version is a Red Hat internal
Engineering build along the way towards U3 (*not* in U2). The
U3 code stream has just begun and has not received any Q/A. If
you would like to test this kernel (in non-production use, and
with the understanding that the kernel is unsupported), then I
can make a particular kernel RPM available to you (if you send
me the exact arch/config info). Alternatively, if you prefer to
build from source, I could send you the patch that I applied, and
you could apply it to the official U2 kernel-source-* RPM (which
should be available via RHN after Monday night) for testing.
Just let me know what you'd like to do. -ernie
Regarding Comment #31 I really would like to get a RPM with the
kernel, even if beta and not yet released. One of our customers
(German car vendor Volkswagen) is suffering from the non-functionality
of agpgart on x86 platform and if I could tell him that with U3 he
gets a solution he would be very happy of course.
Here's where a *pre-beta* U3 kernel (-15.5.EL) can be found:
Note that this kernel has not been through Q/A and it is not supported.
An errata has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.