Bug 108648 - No AGP support on Tyan 2885 K8W
No AGP support on Tyan 2885 K8W
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
x86_64 Linux
medium Severity medium
: ---
: ---
Assigned To: John Dennis
: 108733 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2003-10-30 16:32 EST by Mark Langsdorf
Modified: 2007-11-30 17:06 EST (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-09-02 00:30:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
scan all the bridges looking for agp (449 bytes, patch)
2003-12-23 17:39 EST, John Dennis
no flags Details | Diff
scan all buses on all arches (652 bytes, patch)
2004-03-12 16:51 EST, John Dennis
no flags Details | Diff

  None (edit)
Description Mark Langsdorf 2003-10-30 16:32:52 EST
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):

How reproducible:
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`
Actual results:
agpgart: Maximum main memory to use for agp memory: 2423M
agpgart: No supported devices found

Expected results:
agpgart: Maximum main memory to use for agp memory: 2423M
agpgart: Detected AMD 8151 chipset
agpgart: AGP aperture is 512M @ 0xc0000000

Additional info:

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)
 		return 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)
+			break;
+	} 
+	return ret;
+static int __init agp_init_one(struct pci_dev *dev)
+	u8 cap_ptr = 0x00;
 	agp_bridge.dev = dev;
Comment 1 John Dennis 2003-10-31 10:49:59 EST
I'll take ownership of this, appears to be related to bug 104388 which I'm
working on.
Comment 2 Bill Nottingham 2003-10-31 16:38:39 EST
*** Bug 108733 has been marked as a duplicate of this bug. ***
Comment 3 John Dennis 2003-11-14 16:33:23 EST
Ahh... is it me or is this patch incomplete? Where is the body of the
function agp_init_one?
Comment 4 Mark Langsdorf 2003-11-17 12:29:24 EST
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. 
Comment 7 John Dennis 2003-12-23 17:39:26 EST
Created attachment 96685 [details]
scan all the bridges looking for agp
Comment 8 John Dennis 2003-12-23 17:43:53 EST
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.
Comment 9 John Dennis 2004-01-05 13:17:32 EST
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
Comment 10 Mike A. Harris 2004-02-29 23:52:03 EST
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.
Comment 11 John Dennis 2004-03-01 12:22:29 EST
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
Dave's court. 
Comment 12 Mike A. Harris 2004-03-01 22:53:03 EST
John:  Actually... you reopened it.  ;o)

Click on the link at the bottom of the page "View Bug Activity".  ;o)
Comment 14 John Dennis 2004-03-08 14:56:07 EST
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
Comment 15 Mark Langsdorf 2004-03-08 15:04:22 EST
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).  
Thank you.
Comment 16 Mark Langsdorf 2004-03-12 13:01:53 EST
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).
Comment 19 John Dennis 2004-03-12 15:42:03 EST
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.
Comment 20 John Dennis 2004-03-12 16:51:10 EST
Created attachment 98500 [details]
scan all buses on all arches

same patch as before but no longer conditionalized on architecture
Comment 21 John Dennis 2004-03-12 16:52:24 EST
new patch that does not conditionalize for architecture submitted for
Comment 26 Ernie Petrides 2004-05-04 00:19:50 EDT
A fix for this problem has just been committed to the RHEL3 U3
patch pool (in kernel version 2.4.21-15.1.EL).
Comment 27 Donald Zoch 2004-05-07 15:18:19 EDT
This fix does not work for x86 kernels on the K8W
Comment 28 John Dennis 2004-05-07 15:34:08 EDT
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?
Comment 29 Donald Zoch 2004-05-07 15:55:12 EDT
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?
Comment 30 John Dennis 2004-05-07 16:26:08 EDT
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.
Comment 31 Ernie Petrides 2004-05-07 18:25:14 EDT
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
Comment 32 Rainer Koenig 2004-05-26 08:26:28 EDT
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. 
Comment 33 Ernie Petrides 2004-06-02 21:00:38 EDT
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.
Comment 34 John Flanagan 2004-09-02 00:30:56 EDT
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.


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