Red Hat Bugzilla – Bug 131907
agpgart broken for i810E chipset
Last modified: 2015-01-04 17:09:28 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.7)
Description of problem:
In kernel 2.4.21-20.EL a change was made to
drivers/char/agp/agpgart_be.c which forced the call of
agp_check_supported_device on every possible device, unlike the
previous behaviour where just pci_find_class was checked for being not
NULL. Unfortunately, agp_check_supported_device checks against
agp_bridge_info table which does not contain all the supported
(working?) devices. In particular Intel i810E chipset that used to
work with 2.4.21-15.0.4.EL kernel now doesn't work.
Relevant lspci entries:
00:00.0 Host bridge: Intel Corp. 82810E DC-133 GMCH [Graphics Memory
Controller Hub] (rev 03)
00:01.0 VGA compatible controller: Intel Corp. 82810E DC-133 CGC
[Chipset Graphics Controller] (rev 03)
00:00.0 Class 0600: 8086:7124 (rev 03)
00:01.0 Class 0300: 8086:7125 (rev 03)
Note that 8086:7124 is present in agp.h (PCI_DEVICE_ID_INTEL_810_E_0),
it's only missing from agp_bridge_info table.
Solution - either populate the agp_bridge_info table or else remove
the patch that broke it... Thanks!
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try to load agpgart on a i810E equipped motherboard
Actual Results: Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 320M
agpgart: no supported devices found.
Expected Results: Linux agpgart interface v0.99 (c) Jeff Hartmann
agpgart: Maximum main memory to use for agp memory: 320M
agpgart: Detected an Intel i810 E Chipset.
agpgart: detected 4MB dedicated video ram.
agpgart: AGP aperture is 64M @ 0xf8000000
Note that there may be more broken chipsets (at least the i180DC100
variant should also be broken by this change).
Confirmed here at NCSU. I've got machine with this same video card
and have duplicated this same problem.
A little history, this patch was introduced by me on 12/23/2004 in
At that moment it was just for ia64 and x86_64, but I concluded,
apparently incorrectly, that it was safe for all arches. After the
patch was accepted AMD complained saying that ifdef'ing the patch for
x86_64 was insufficient because 32 bit kernels are built and installed
on their Tyan boxes as well, the pci topology is the same, but the
kernels will behave differently between 32 bit and 64 bit variants.
After some discussion it was felt the patch was safe for all arches
and that change was commited to U3.
I don't know the agpgart code in detail but I'll confess to being a
bit surprised that the agp code would initialize and properly drive an
unknown agp chipset.
Dave knows this code much better than I do and I'll defer judgement to
his expertise. We do have to scan all the buses, whether the call to
agp_check_supported_device is correct or if the table needs updating
I'll leave to Dave. Like I said, it does surprise me that failing a
check for a supported device produced the correct kernel runtime behavior.
Created attachment 103620 [details]
XF86 and kernel logs
Created attachment 103844 [details]
populate the agp_bridge_info table with missing entries
I'm not sure if this is correct for a fix... But based on my reading of the
problem from Josko this seems to be working with this patch on
several test systems I have here at NCSU with the intel i810E chipset.
Gary Gatling's patch seems to work ok for me on several (identical)
i810e based systems.
Created attachment 104078 [details]
Additional entry for i810 in agpgart_be.c
I just tested the patch (attachment from Gary Gatling above) on a box with an
i810 (not i810E) and it still didn't work. However, I added an extra entry for
PCI_DEVICE_ID_INTEL_810_0 and that's working fine for me now (see amended
*** Bug 132066 has been marked as a duplicate of this bug. ***
Adding X Development team to CC for tracking.
*** Bug 132619 has been marked as a duplicate of this bug. ***
I've used the patch in comment number 10, and it worked just fine for
me on an i810E. I know I'd appreciate it if this fix was in the next
errata kernel. I re-rolled the SRPM after adding that to the patch
list, and X started working after it hadn't worked with the
I have built a kernel with a patch proposed by Dave Jones, you can
find the kernels here:
kernel-2.4.21-21.jrd.i686.rpm and kernel-smp-2.4.21-21.jrd.i686.rpm
I do not have an i810E, would someone reporting the problem be kind
enough to install the kernel and test? Thanks.
Just tried it. Worked like a champ! Thanks for looking into this so
*** Bug 134352 has been marked as a duplicate of this bug. ***
BTW, it's also essential to test on HP IA64 systems as this patch
replaces an IA64 specfic solution AND it's essential to test with BOTH
32-bit and 64-bit kernals on AMD Tyan systems as it was failures on
these systems that caused the IA64 fix to be reworked for them.
Conventional i686 architectures which this bug was filed against were
unwittingly caught in the non-x86 cross fire. Thus testing only x86
would fall far short of proving robustness.
I tested only on a 32-bit Intel machine, so, yes, my quick test should
not be considered definitive by any means.
To John Dennis:
I installed the kernel on a Dell Optiplex GX110; it has the onboard
Intel 810 video. The kernel worked. Dell made lots of computers in
this product line. We have hundreds at Iowa State University.
This would be a great patch to put into production.
ISU Academic Information Technologies
A fix for this problem is on track for the next U4 respin.
*** Bug 135739 has been marked as a duplicate of this bug. ***
That would be great...
New RPM fix worked great on two Dell 110. Thx a lot!!
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-22.EL).
*** Bug 132935 has been marked as a duplicate of this bug. ***
*** Bug 140669 has been marked as a duplicate of this bug. ***
This bug is still present in kernel 2.4.21-20.0.1
agpgart fail to load on a Dell Workstation with an Intel 801E.
I will try using the posted patches and report.
The fix was applied to U4, which is *not* 2.4.21-20.0.1.EL. Please try
the U4 kernel (2.4.21-27.EL) when it is released next week. Thanks.
*** Bug 143159 has been marked as a duplicate of this bug. ***
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.