Bug 160009 - agpgart will not load for kernel 2.4.21-32 on tyan S2885 motherboard with AMD-8151 agp tunnel
agpgart will not load for kernel 2.4.21-32 on tyan S2885 motherboard with AMD...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Brian Maly
Brian Brock
:
Depends On:
Blocks: 168424
  Show dependency treegraph
 
Reported: 2005-06-09 19:34 EDT by Daniel Crandall
Modified: 2007-11-30 17:07 EST (History)
3 users (show)

See Also:
Fixed In Version: RHSA-2006-0144
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-15 11:04:24 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmesg right after boot (13.75 KB, text/plain)
2005-06-15 16:45 EDT, Daniel Crandall
no flags Details
dmesg after trying to load agpgart (13.89 KB, text/plain)
2005-06-15 16:46 EDT, Daniel Crandall
no flags Details
Patch to detect AGP bus bus (i386 kernel) for Tyan S2885MB (432 bytes, patch)
2005-07-14 16:42 EDT, Brian Maly
no flags Details | Diff

  None (edit)
Description Daniel Crandall 2005-06-09 19:34:44 EDT
Description of problem:

This appears to be pretty much identical to the bug that was supposedly fixed
for kernel 2.4.21-20.

modprobe agpgart: 

/lib/modules/2.4.21-32.0.1.ELsmp/kernel/drivers/char/agp/agpgart.o: init_module:
No such device
Hint: insmod errors can be caused by incorrect module parameters, including
invalid IO or IRQ parameters.
      You may find more information in syslog or the output from dmesg
/lib/modules/2.4.21-32.0.1.ELsmp/kernel/drivers/char/agp/agpgart.o: insmod
/lib/modules/2.4.21-32.0.1.ELsmp/kernel/drivers/char/agp/agpgart.o failed
/lib/modules/2.4.21-32.0.1.ELsmp/kernel/drivers/char/agp/agpgart.o: insmod
agpgart failed

lspci does not list the AMD-8151 agp tunnel:

lspci
00:06.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8111 PCI (rev 07)
00:07.0 ISA bridge: Advanced Micro Devices [AMD] AMD-8111 LPC (rev 05)
00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE (rev 03)
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0 (rev 02)
00:07.3 Bridge: Advanced Micro Devices [AMD] AMD-8111 ACPI (rev 05)
00:07.5 Multimedia audio controller: Advanced Micro Devices [AMD] AMD-8111 AC97
Audio (rev 03)
00:0a.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00:0b.0 PCI bridge: Advanced Micro Devices [AMD] AMD-8131 PCI-X Bridge (rev 12)
00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X APIC (rev 01)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
00:19.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
HyperTransport Technology Configuration
00:19.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address Map
00:19.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM
Controller
00:19.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron]
Miscellaneous Control
01:06.0 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 08)
01:06.1 SCSI storage controller: LSI Logic / Symbios Logic 53c1030 PCI-X
Fusion-MPT Dual Ultra320 SCSI (rev 08)
02:07.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet
Controller (rev 04)
02:08.0 Ethernet controller: Intel Corporation 82545GM Gigabit Ethernet
Controller (rev 04)
02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5703X Gigabit
Ethernet (rev 02)
03:00.0 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
03:00.1 USB Controller: Advanced Micro Devices [AMD] AMD-8111 USB (rev 0b)
03:0a.0 Serial controller: NetMos Technology PCI 9835 Multi-I/O Controller (rev 01)
05:00.0 VGA compatible controller: nVidia Corporation NV40GL [Quadro FX 4000]
(rev a1)

but scanpci does:

pci bus 0x0004 cardnum 0x00 function 0x00: vendor 0x1022 device 0x7454
 Advanced Micro Devices [AMD] AMD-8151 System Controller
pci bus 0x0004 cardnum 0x01 function 0x00: vendor 0x1022 device 0x7455
 Advanced Micro Devices [AMD] AMD-8151 AGP Bridge

/proc/drivers/nvidia/agp/status as well as /proc/drivers/nvidia/agp/host-bridge
are both empty, suggesting to me that the problem is not simply that agp support
is disabled, but non existant.

Obviously I have agpgart built as a module, and it does have AMD-8151 support:
grep -i agp /boot/config-2.4.21-32.0.1.ELsmp
CONFIG_AGP=m
CONFIG_AGP_INTEL=y
CONFIG_AGP_I810=y
CONFIG_AGP_VIA=y
CONFIG_AGP_AMD=y
CONFIG_AGP_AMD_8151=y
CONFIG_AGP_SIS=y
CONFIG_AGP_ALI=y
CONFIG_AGP_SWORKS=y
CONFIG_AGP_NVIDIA=y

Seems like it just can find the agp tunnel at pci 04

Version-Release number of selected component (if applicable): 2.4.21-32


How reproducible: very


Steps to Reproduce:
1. Install RHEL3 U5 on Tyan S2885 motherboard with AMD-8151 agp tunnel
2. modprobe agpgart, or configure nvidia driver to use agpgart and start x
3.
  
Actual results:
No agp support for agp graphics card.

Expected results:
Expect agpgart driver to load and to see something like the following:
cat /proc/drivers/nvidia/agp/status
Status:          Enabled
Driver:          AGPGART
AGP Rate:        8x
Fast Writes:     Enabled
SBA:             Enabled


Additional info: Seems identical to a bug for kernel 2.4.21-15 i believe
relating to agpgart and the Tyan S2885.
Comment 1 Brian Maly 2005-06-10 11:46:09 EDT
devel ACK for U6 (conditional: assumes we get a tyan to test with in time)
Comment 2 Daniel Crandall 2005-06-10 12:24:20 EDT
Hi,
Sorry, I forgot to mention that this is for 32 bit 2.4.21-32

-dc
Comment 3 Brian Maly 2005-06-14 15:14:13 EDT
A little more research on this issue has uncovered a patch for this issue:

ftp://ftp.tyan.com/drivers_linux/s2885/tyan_agp.RHEL3.patch1

This patch was recently included in the RHEL3 kernel (and should included be in
U6), but since we dont have any Tyan hardware on-site I am unable to reproduce
the issue, or verify this fix resolves the problem.

also, booting with "pci=noacpi" may be a workaround (but this is also untested).
This problem seems to appear when using a 32 bit kernel, while AGP bus #4 seems
to be detected properly using a 64 bit kernel.

Comment 4 Daniel Crandall 2005-06-15 10:42:06 EDT
The tyan patch does not apply properly to redhat 3 update 4 or 5.  I have a
feeling that this patch is for the 2.4.21-15 or earlier, as it appears to have
been released in early 2004.

I did try booting wiht pci=noapci.  dmesg reports that this is not a valid boot
option, so I tried booting with apci=off, and that did not have any effect
except to cause my nvidia card to share an irq with my ethernet adapter.

Yes the 64bit kernel works fine.  I have loaded the x86_64 version and it seed
the agp bridge at pci address 04.  

My belief is that whatever patches were rolled into the 64bit kernel need to be
implemented and tested in the 32 bit version.  I'm not able to write a patch
myself.  But I would be more than happy to test patches.
Comment 5 Daniel Crandall 2005-06-15 10:53:06 EDT
A previous bug, 108648, reported the same problem.  

I tried to apply several of the patches that were submitted, but they did not
patch properly on 2.4.21-32 or 2.4.21-27.  Indeed you can see that in that
thread that the submitted patches for 32bit were not working right.
  
Then the Redhat resolution seemed to only fix the 64bit kernel.  My guess is
that the fix for 32bit kernel never really happened.
Comment 6 Brian Maly 2005-06-15 14:01:05 EDT
looking for some more debug info here:

cat we get a 'dmesg' output from after the system boots? 

also a 'dmesg' output from when the agpgart module fails to load (log level set
to kern.* being that some usefull debug messages only show up under KERNEL_DEBUG)? 

also worth noting is that there is some AMD-8151 and nVidia code in agpgart_be
that gets executed only when "agp_try_unsupported=1" is passed to the kernel at
boot time. not sure if this will help.

Comment 7 Daniel Crandall 2005-06-15 16:45:24 EDT
Created attachment 115510 [details]
dmesg right after boot
Comment 8 Daniel Crandall 2005-06-15 16:46:04 EDT
Created attachment 115511 [details]
dmesg after trying to load agpgart
Comment 9 Daniel Crandall 2005-06-15 16:48:28 EDT
Attached requested dmesg output.

I have actually tried booting with "agp_try_unsupported=1" based on some
information that I found, but alas, that was ineffective.
Thanks for the tip though

Dan
Comment 10 Daniel Crandall 2005-06-20 14:26:19 EDT
Any progress on this issue?
Comment 11 Brian Maly 2005-06-22 11:37:06 EDT
Posted a test kernel for Tyan to test on some of their systems.

http://people.redhat.com/bmaly/linux-2.4.21-32.9.EL.tar.gz
Comment 12 Daniel Crandall 2005-06-23 11:16:46 EDT
Great.  
I've downloaded this as well.  I'm short one tyan box due to hardware failure,
but I will test this kernel when I get it back.

Thanks for your time and efforts.
Comment 13 Brian Maly 2005-06-27 17:58:54 EDT
Tyan did some testing on a S2885 and confirmed the problem exists in our RHEL3
pre-u6 32bit kernel. Tyan now intends to send us a S2885 motherboard so we can
diagnose this issue. 
Comment 14 Daniel Crandall 2005-06-29 11:13:08 EDT
That's good news.  
Hopefully a fix can be developed in time to make it into u6
Comment 15 Brian Maly 2005-07-06 11:14:30 EDT
just a quick note that we received the hardware from tyan. we should be able to
replicate this issue now.
Comment 16 Brian Maly 2005-07-14 16:42:14 EDT
Created attachment 116768 [details]
Patch to detect AGP bus bus (i386 kernel) for Tyan S2885MB

this patch forces a peer bus scan so that the AMD-8151 AGP bridge is found
Comment 17 Brian Maly 2005-07-14 16:44:37 EDT
A patch has been submitted to rhkernel for inclusion in U6 (pending approval).

Diagnosis:

 The RHEL3 kernel doesnt detect all PCI peer bridges like some AMD-8151
AGP bridges in arch/i386/kernel/pci-pc.c but does in
arch/x86_64/kernel/pci-pc.c. As a  result agpgart.o loads with
a x86_64 kernel but fails to load with an i386 kernel. Additionally
the AGP bridge is absent from lspci output on i386 but shows up on
x86_64.
 This minimalistic patch includes the same x86_64 functionality on i386,
and forces a scan to detect peer host bridges in pcibios_fixup_peer_bridges().
On x86_64 pcibios_last_bus gets set to 0xfe if no mptable is found (this
happens pci_scan_mptable, before pcibios_fixup_peer_bridges() gets called).

Tested this patch on a tyan S2885 board... the AMD-8151 is detected
at boot under i386 (just like x86_64). agpgart.o loads fine as well.
Comment 18 Daniel Crandall 2005-07-15 16:01:17 EDT
This is great news.  Thanks for your attention and work on this issue.  I really
appreciate it.  I'm assuming that approval of your patch won't be a problem.
When is U6 estimated to be released?
Thanks again
Comment 20 Ernie Petrides 2005-11-02 20:46:37 EST
A fix for this problem has just been committed to the RHEL3 U7
patch pool this evening (in kernel version 2.4.21-37.8.EL).
Comment 21 Daniel Crandall 2005-11-22 13:23:50 EST
Can you give me a estimated release date for U7?  I really need this fix - was
expecting it in U6...
Thank you
Comment 22 Ernie Petrides 2005-11-22 15:21:26 EST
Hi, Daniel.  The U7 public beta period is not scheduled to start until
early January.  We're near the end of the development cycle now.
Comment 25 Red Hat Bugzilla 2006-03-15 11:04:25 EST
An advisory 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/RHSA-2006-0144.html

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