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 @@ EXPORT_SYMBOL(agp_backend_release); 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; #ifdef CONFIG_AGP_HP_ZX1 if (hp_zx1_gart_init() == 0) return 0; #endif - 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;
I'll take ownership of this, appears to be related to bug 104388 which I'm working on.
*** 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 function agp_init_one?
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 conditionalization.
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 Dave's court.
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 boat.
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.
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 RHEL3 U3
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: ftp://partners.redhat.com/d4d233100e21cbde6f83e8afe9219865/2.4.21-15.5.EL/ 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. http://rhn.redhat.com/errata/RHBA-2004-433.html