Bug 175003 - AGP rates are mis-reported in dmesg when starting X
AGP rates are mis-reported in dmesg when starting X
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
x86_64 Linux
medium Severity low
: ---
: ---
Assigned To: Brian Maly
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-12-05 13:13 EST by Lonni J Friedman
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-04-27 15:10:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
fix for the bug (1011 bytes, patch)
2005-12-05 13:14 EST, Lonni J Friedman
no flags Details | Diff

  None (edit)
Description Lonni J Friedman 2005-12-05 13:13:58 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

Description of problem:
AGP: Found AGPv3 capable device at 0:0:0 
AGP: Found AGPv3 capable device at 1:0:0 
When starting X on a system with an AGP-8x controller and videocard, 

AGP: Enough AGPv3 devices found, setting up... 
AGP: Setting up AGPv3 capable device at 0:0:0 
AGP: Putting device into 4x mode 
AGP: Setting up AGPv3 capable device at 1:0:0 
AGP: Putting device into 4x mode 
AGP: Found AGPv3 capable device at 0:0:0 
AGP: Found AGPv3 capable device at 1:0:0 
AGP: Enough AGPv3 devices found, setting up... 
AGP: Setting up AGPv3 capable device at 0:0:0 
AGP: Putting device into 4x mode 
AGP: Setting up AGPv3 capable device at 1:0:0 
AGP: Putting device into 4x mode 

Version-Release number of selected component (if applicable):
2.4.21-37.EL

How reproducible:
Always

Steps to Reproduce:
1. start X on a system that has an AGP 8x card & controller (such as Sun's W2100Z)
2. look at dmesg output and you'll see that it claims to be putting the device into a 4x mode
3.
  

Actual Results:  look at dmesg output and you'll see that it claims to be putting the device into a 4x mode, even though its actually in 8x.

This is most easily verified while using an nvidia graphics card and nvidia's X driver.  Load the nvidia kernel modules with the NVreg_ReqAGPRate=8 parameter.  Then look at dmesg, and you'll see:
 
NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module  1.0-8174  Tue Nov 22 17:48:37 PST 2005 
AGP: Found AGPv3 capable device at 0:0:0 
AGP: Found AGPv3 capable device at 1:0:0 
AGP: Enough AGPv3 devices found, setting up... 
AGP: Setting up AGPv3 capable device at 0:0:0 
AGP: Putting device into 4x mode 
AGP: Setting up AGPv3 capable device at 1:0:0 
AGP: Putting device into 4x mode 
AGP: Found AGPv3 capable device at 0:0:0 
AGP: Found AGPv3 capable device at 1:0:0 
AGP: Enough AGPv3 devices found, setting up... 
AGP: Setting up AGPv3 capable device at 0:0:0 
AGP: Putting device into 4x mode 
AGP: Setting up AGPv3 capable device at 1:0:0 
AGP: Putting device into 4x mode 
 
[root@localhost root]# cat /proc/driver/nvidia/agp/status 
Status:          Enabled 
Driver:          AGPGART 
AGP Rate:        8x 
Fast Writes:     Disabled 
SBA:             Enabled 

Expected Results:  dmesg reports 8x

Additional info:

 the kernel has its rate reporting logic backwards:

 
                        if (!((command & 2) && (scratch & 2) && (mode & 2))) { 
                                command &= ~2;          /* 8x */ 
                                printk (KERN_INFO "AGP: Putting device into 8x mode\n"); 
                        } 
 
                        if (!((command & 1) && (scratch & 1) && (mode & 1))) { 
                                command &= ~1;          /* 4x */ 
                                printk (KERN_INFO "AGP: Putting device into 4x mode\n"); 
                        } 


Per the AGP 3.0 specification, bit 1 is the 8x data transfer mode, bit 0 is the 4x data transfer mode. In 1.0-8174, we ensure that if 8x operation is requested, bit 1 is set in the requested mode mask passed to AGPGART, while bit 0 is not. I guess the kernel's logic should be:

 
                        if ((command & 2) && (scratch & 2) && (mode & 2)) { 
                                command &= ~3;          /* 8x */ 
                                printk (KERN_INFO "AGP: Putting device into 8x mode\n"); 
                        } 
 
                        if ((command & 1) && (scratch & 1) && (mode & 1)) { 
                                command &= ~1;          /* 4x */ 
                                printk (KERN_INFO "AGP: Putting device into 4x mode\n"); 
                        } 


 'command' is used later on, so I guesss the logic should be:

 
                        if (!((command & 2) && (scratch & 2) && (mode & 2))) { 
                                command &= ~6;          /* 4x */ 
                                printk (KERN_INFO "AGP: Putting device into 4x mode\n"); 
                        } 
 
                        if (!((command & 1) && (scratch & 1) && (mode & 1))) { 
                                command &= ~5;          /* 8x */ 
                                printk (KERN_INFO "AGP: Putting device into 8x mode\n"); 
                        }
Comment 1 Lonni J Friedman 2005-12-05 13:14:56 EST
Created attachment 121858 [details]
fix for the bug

Attaching a patch which fixes this bug.

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