Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Nicolas Aspert]

>                         if (i810_dev == NULL) {
>                                 printk(KERN_ERR PFX "agpgart: Detected an "
>                                        "Intel i815, but could not find the"
>                                        " secondary device. Assuming a "
>                                        "non-integrated video card.\n");
>                                 break;
> 
> 
> This leads me to believe the "secondary device"  could be the integrated
> graphics component on the i810/815.
> 
> As the i830M doesn't have one (the i830MG does), I suppose this could
> lead to the aforementioned error message, and hence failure of the
> agpgart modprobe ?
> 
> Could it be that one has to differentiate between i830MG (secondary
> device, and hence analoguous to i810/i815) and i830M (no secondary
> device, and possibly analoguous to i830/i840/i845/... : no check for 2nd
> device needed ) ?
> 
> 
> Offcourse, I could be utterly wrong.
> 

Hello

It seems like you have pointed out the problem... From what you had sent 
previously (the output of 'lspci' on your machine), and what the Intel 
doc says, it looks to me like the code for i830 initialization is not 
correct for your version of the chipset. But I am not too sure of what 
is to be done in that case... should we switch back to a 'classic' AGP 
initialization, similar to the other i8xx chipsets (820/840/860...) ? 
Robert (or somebody else), any clue about this one ?
I'll try to figure out where the 'i830_configure' performs call on the 
secondary device...

Best regards
-- 
Nicolas Aspert      Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Robert Love]

On Mon, 2001-11-26 at 06:47, Nicolas Aspert wrote:

> It seems like you have pointed out the problem... From what you had sent 
> previously (the output of 'lspci' on your machine), and what the Intel 
> doc says, it looks to me like the code for i830 initialization is not 
> correct for your version of the chipset. But I am not too sure of what 
> is to be done in that case... should we switch back to a 'classic' AGP 
> initialization, similar to the other i8xx chipsets (820/840/860...) ? 
> Robert (or somebody else), any clue about this one ?

It looks like you got it right ... at any rate, you know as much as me
about a chipset neither of us have (ie, we have docs), so its all a
guess.

Has the user tried your patch?  Results?

	Robert Love

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Didier Moens]

Dear Robert, Nicolas, Stephan,   :)


Robert Love wrote:

> On Mon, 2001-11-26 at 06:47, Nicolas Aspert wrote:
> 
> 
>>It seems like you have pointed out the problem... From what you had sent 
>>previously (the output of 'lspci' on your machine), and what the Intel 
>>doc says, it looks to me like the code for i830 initialization is not 
>>correct for your version of the chipset. But I am not too sure of what 
>>is to be done in that case... should we switch back to a 'classic' AGP 
>>initialization, similar to the other i8xx chipsets (820/840/860...) ? 
>>Robert (or somebody else), any clue about this one ?
>>
> 
> It looks like you got it right ... at any rate, you know as much as me
> about a chipset neither of us have (ie, we have docs), so its all a
> guess.
> 
> Has the user tried your patch?  Results?

I got two patches :


1. From Stephan, to test whether my assumption about the secondary 
device was right :

Stephan wrote :

But if you want you can check that out pretty simple: just add a "break" 
right
after the case :

                 case PCI_DEVICE_ID_INTEL_830_M_0:
---> break;

                         i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,


This patch left me with a loaded agpgart, and accelerated X (DRM/DRI). 
The acceleration is still not up to par with an ATI Mobility-128 (30% 
lower, while it should be at least 200% faster), but I suspect an X 
CVS-problem here.

Quitting and restarting X leaves me with a locked black screen.


2. And the one from Nicolas, in which I changed all references from 
830MG to 830M.


Results :

1a. Nicolas' patches yielded an oops, which was corrected by 
implementing Stephan's first patch :

+                       if(i810_dev && ( PCI_FUNC(i810_dev->devfn) != 0) ) {
-                       if(PCI_FUNC(i810_dev->devfn) != 0) {

1b. After Stephan's firsat patch, Nicolas' code loaded the agpgart, but 
left me with a messed-up X (XFree86 CVS 4.1.99.1 2001/11/26) : only a 
cursor, locked black screen, restart to ssh session.


(I need the CVS-version of X : standard 4.1.0 doesn't detect the LCD 
panel size, and bugs out).


Conclusion : Stephan's break-patch loads agpgart, loads X, and locks 
when reloading X ; Nicolas' patch (when combined with Stephan's first 
patch) loads agpgart and locks X hard.


FYI : Dell has an i830M-design (the new i8100, together with a NVidia 
Mobile), and Gateway, Compaq, ... should have them too, I guess.




The requested "lspci -vn" :


00:00.0 Class 0600: 8086:3575 (rev 02)
	Subsystem: 1014:021d
	Flags: bus master, fast devsel, latency 0
	Memory at d0000000 (32-bit, prefetchable) [size=256M]
	Capabilities: [40] #09 [0105]
	Capabilities: [a0] AGP version 2.0

00:01.0 Class 0604: 8086:3576 (rev 02)
	Flags: bus master, 66Mhz, fast devsel, latency 96
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
	I/O behind bridge: 00003000-00003fff
	Memory behind bridge: c0100000-c01fffff
	Prefetchable memory behind bridge: e0000000-e7ffffff

00:1d.0 Class 0c03: 8086:2482 (rev 01)
	Subsystem: 1014:0220
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1800 [size=32]

00:1d.1 Class 0c03: 8086:2484 (rev 01)
	Subsystem: 1014:0220
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1820 [size=32]

00:1d.2 Class 0c03: 8086:2487 (rev 01)
	Subsystem: 1014:0220
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1840 [size=32]

00:1e.0 Class 0604: 8086:2448 (rev 41)
	Flags: bus master, fast devsel, latency 0
	Bus: primary=00, secondary=02, subordinate=08, sec-latency=64
	I/O behind bridge: 00004000-00008fff
	Memory behind bridge: c0200000-cfffffff
	Prefetchable memory behind bridge: e8000000-f00fffff

00:1f.0 Class 0601: 8086:248c (rev 01)
	Flags: bus master, medium devsel, latency 0

00:1f.1 Class 0101: 8086:248a (rev 01) (prog-if 8a [Master SecP PriP])
	Subsystem: 1014:0220
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 01f0 [size=8]
	I/O ports at 03f4
	I/O ports at 0170 [size=8]
	I/O ports at 0374
	I/O ports at 1860 [size=16]
	Memory at 20000000 (32-bit, non-prefetchable) [size=1K]

00:1f.3 Class 0c05: 8086:2483 (rev 01)
	Subsystem: 1014:0220
	Flags: medium devsel, IRQ 11
	I/O ports at 1880 [size=32]

00:1f.5 Class 0401: 8086:2485 (rev 01)
	Subsystem: 1014:0222
	Flags: bus master, medium devsel, latency 0, IRQ 11
	I/O ports at 1c00 [size=256]
	I/O ports at 18c0 [size=64]

00:1f.6 Class 0703: 8086:2486 (rev 01)
	Subsystem: 1014:0227
	Flags: medium devsel, IRQ 11
	I/O ports at 2400 [size=256]
	I/O ports at 2000 [size=128]

01:00.0 Class 0300: 1002:4c59
	Subsystem: 1014:0235
	Flags: bus master, stepping, fast Back2Back, 66Mhz, medium devsel, 
latency 66, IRQ 11
	Memory at e0000000 (32-bit, prefetchable) [size=128M]
	I/O ports at 3000 [size=256]
	Memory at c0100000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at <unassigned> [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
	Capabilities: [50] Power Management version 2

02:00.0 Class 0607: 1180:0478 (rev a0)
	Subsystem: 1014:0184
	Flags: bus master, medium devsel, latency 168, IRQ 11
	Memory at c0202000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=02, secondary=03, subordinate=05, sec-latency=176
	Memory window 0: e8000000-e83ff000 (prefetchable)
	Memory window 1: c0400000-c07ff000
	I/O window 0: 00004000-000040ff
	I/O window 1: 00004400-000044ff
	16-bit legacy interface ports at 0001

02:00.1 Class 0607: 1180:0478 (rev a0)
	Subsystem: 1014:0184
	Flags: bus master, medium devsel, latency 168, IRQ 11
	Memory at c0203000 (32-bit, non-prefetchable) [size=4K]
	Bus: primary=02, secondary=06, subordinate=08, sec-latency=176
	Memory window 0: e8400000-e87ff000 (prefetchable)
	Memory window 1: c0800000-c0bff000
	I/O window 0: 00004800-000048ff
	I/O window 1: 00004c00-00004cff
	16-bit legacy interface ports at 0001

02:00.2 Class 0c00: 1180:0522 (prog-if 10)
	Subsystem: 1014:01cf
	Flags: bus master, medium devsel, latency 64, IRQ 11
	Memory at c0201000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: [dc] Power Management version 2

02:02.0 Class 0280: 1260:3873 (rev 01)
	Subsystem: 1668:0406
	Flags: bus master, medium devsel, latency 64, IRQ 11
	Memory at f0000000 (32-bit, prefetchable) [size=4K]
	Capabilities: [dc] Power Management version 2

02:08.0 Class 0200: 8086:1031 (rev 41)
	Subsystem: 1014:0209
	Flags: bus master, medium devsel, latency 66, IRQ 11
	Memory at c0200000 (32-bit, non-prefetchable) [size=4K]
	I/O ports at 8000 [size=64]
	Capabilities: [dc] Power Management version 2



-[00]-+-00.0  8086:3575
       +-01.0-[01]----00.0  1002:4c59
       +-1d.0  8086:2482
       +-1d.1  8086:2484
       +-1d.2  8086:2487
       +-1e.0-[02-08]--+-00.0  1180:0478
       |               +-00.1  1180:0478
       |               +-00.2  1180:0522
       |               +-02.0  1260:3873
       |               \-08.0  8086:1031
       +-1f.0  8086:248c
       +-1f.1  8086:248a
       +-1f.3  8086:2483
       +-1f.5  8086:2485
       \-1f.6  8086:2486




Kind regards,

Didier



Didier Moens
-----
RUG/VIB - Dept. Molecular Biology - Core IT
tel ++32(9)2645309 fax ++32(9)2645348
http://www.dmb.rug.ac.be

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Nicolas Aspert]

[-- Attachment #1: Type: text/plain, Size: 1765 bytes --]

Didier Moens wrote:

 > Dear Robert, Nicolas, Stephan,   :)
 >
 >
 > I got two patches :
 >
 >
 > 1. From Stephan, to test whether my assumption about the secondary
 > device was right :
 >
 > Stephan wrote :
 >
 > But if you want you can check that out pretty simple: just add a "break"
 > right
 > after the case :
 >
 >                 case PCI_DEVICE_ID_INTEL_830_M_0:
 > ---> break;
 >
 >                         i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
 >


What is the result if you place the 'break' a few lines below, just
before the 'agp_bridge.type = NOT_SUPPORTED;' ? Does the module still
loads ?


 > This patch left me with a loaded agpgart, and accelerated X (DRM/DRI).
 > The acceleration is still not up to par with an ATI Mobility-128 (30%
 > lower, while it should be at least 200% faster), but I suspect an X
 > CVS-problem here.
 >
 > Quitting and restarting X leaves me with a locked black screen.
 >


The origin of the problem is not obvious... as you said, it could be a
DRI/DRM/X related problem (-> hard to trace). In order to be sure AGP is 
functioning correctly, I suggest that you run this good old test program 
(attached) after loading the AGP module (but before starting X). I 
buried out this little fellow from the utah-glx project. All it does is 
trying to write some data to the agp memory. Try it with both flavors of 
the module (mine+your fix and the one from Stephan), and share the 
output with us ;-)

Good luck


 > Conclusion : Stephan's break-patch loads agpgart, loads X, and locks
 > when reloading X ; Nicolas' patch (when combined with Stephan's first
 > patch) loads agpgart and locks X hard.
 >



-- 
Nicolas Aspert      Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)


[-- Attachment #2: testgart.c --]
[-- Type: text/plain, Size: 6977 bytes --]

#include <stdio.h>
#include <unistd.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <sys/mman.h>
#include <sys/time.h>
#include <linux/types.h>
#include <linux/agpgart.h>
#include <asm/mtrr.h>
#include <errno.h>

unsigned char *gart;
int gartfd;
int mtrr;

int usec( void ) {
  struct timeval tv;
  struct timezone tz;
  
  gettimeofday( &tv, &tz );
  return (tv.tv_sec & 2047) * 1000000 + tv.tv_usec;
}

int MemoryBenchmark( void *buffer, int dwords ) {
  int             i;
  int             start, end;
  int             mb;
  int             *base;
  
  base = (int *)buffer;
  start = usec();
  for ( i = 0 ; i < dwords ; i += 8 ) {
    base[i] =
      base[i+1] =
      base[i+2] =
      base[i+3] =
      base[i+4] =
      base[i+5] =
      base[i+6] =
      base[i+7] = 0x15151515;         /* dmapad nops */
  }
  end = usec();
  mb = ( (float)dwords / 0x40000 ) * 1000000 / (end - start);
  printf("MemoryBenchmark: %i mb/s\n", mb );
  return mb;
}

int insert_gart(int page, int size)
{
   agp_allocate entry;
   agp_bind bind;
   
   entry.type = 0;
   entry.pg_count = size;
#ifdef DEBUG
   printf("Using AGPIOC_ALLOCATE\n");
#endif
   if(ioctl(gartfd, AGPIOC_ALLOCATE, &entry) != 0)
    {
      perror("ioctl(AGPIOC_ALLOCATE)");
      exit(1);
    }
   
   bind.key = entry.key;
   bind.pg_start = page;
#ifdef DEBUG
   printf("Using AGPIOC_BIND\n");
#endif
   if(ioctl(gartfd, AGPIOC_BIND, &bind))
     {
	perror("ioctl(AGPIOC_BIND)");
	exit(1);
     }
   
   printf("entry.key : %i\n", entry.key);
   
   return(entry.key);
}

int unbind_gart(int key)
{
   agp_unbind unbind;
   
   unbind.key = key;
#ifdef DEBUG
   printf("Using AGPIOC_UNBIND\n");
#endif
   if(ioctl(gartfd, AGPIOC_UNBIND, &unbind) != 0)
     {
	perror("ioctl(AGPIOC_UNBIND)");
	exit(1);
     }
   
   return(0);
}

int bind_gart(int key, int page)
{
   agp_bind bind;
   
   bind.key = key;
   bind.pg_start = page;
#ifdef DEBUG
   printf("Using AGPIOC_BIND\n");
#endif
   if(ioctl(gartfd, AGPIOC_BIND, &bind) != 0)
     {
	perror("ioctl(AGPIOC_BIND)");
	exit(1);
     }
   
   return(0);
}

int remove_gart(int key)
{
#ifdef DEBUG
   printf("Using AGPIOC_DEALLOCATE\n");
#endif
  if(ioctl(gartfd, AGPIOC_DEALLOCATE, key) != 0)
    {
      perror("ioctl(GARTIOCREMOVE)");
      exit(1);
    }
   
   return(0);
}

void openmtrr(void) 
{
   if ((mtrr = open("/proc/mtrr", O_WRONLY, 0)) == -1) 
     {
	if (errno == ENOENT) {
	   perror("/proc/mtrr not found: MTRR not enabled\n");
	}  else {
	   perror("Error opening /proc/mtrr:");
	   perror("MTRR not enabled\n");
	   exit(1);
	}
	return;
     }
}

int CoverRangeWithMTRR( int base, int range, int type )
{
   int          count;   
      
   /* set it if we aren't just checking the number */
   if ( type != -1 ) {
      struct mtrr_sentry sentry;
      
      sentry.base = base;
      sentry.size = range;
      sentry.type = type;
      
      if ( ioctl(mtrr, MTRRIOC_ADD_ENTRY, &sentry) == -1 ) {
	 perror("mtrr");
	 exit(1);
      }
   }
   
}

int init_agp(void)
{
   agp_info info;
   agp_setup setup;

#ifdef DEBUG
   printf("Using AGPIOC_ACQUIRE\n");
#endif
   if(ioctl(gartfd, AGPIOC_ACQUIRE) != 0)
     {
	perror("ioctl(AGPIOC_ACQUIRE)");
	exit(1);
     }
#ifdef DEBUG
   printf("Using AGPIOC_INFO\n");
#endif
   if(ioctl(gartfd, AGPIOC_INFO, &info) != 0)
     {
	perror("ioctl(AGPIOC_INFO)");
	exit(1);
     }
   
   printf("version: %i.%i\n", info.version.major, info.version.minor);
   printf("bridge id: 0x%lx\n", info.bridge_id);
   printf("agp_mode: 0x%lx\n", info.agp_mode);
   printf("aper_base: 0x%lx\n", info.aper_base);
   printf("aper_size: %i\n", info.aper_size);
   printf("pg_total: %i\n", info.pg_total);
   printf("pg_system: %i\n", info.pg_system);
   printf("pg_used: %i\n", info.pg_used);

   openmtrr();
   if (mtrr != -1) { 
     CoverRangeWithMTRR(info.aper_base, info.aper_size * 0x100000, 
       MTRR_TYPE_WRCOMB);
   }

   gart = mmap(NULL, info.aper_size * 0x100000, PROT_READ | PROT_WRITE, MAP_SHARED, gartfd, 0);

   if(gart == (unsigned char *) 0xffffffff)
     {
	perror("mmap");
	close(gartfd);
	exit(1);
     }	
   
   setup.agp_mode = info.agp_mode;
#ifdef DEBUG
   printf("Using AGPIOC_SETUP\n");
#endif
   if(ioctl(gartfd, AGPIOC_SETUP, &setup) != 0)
     {
	perror("ioctl(AGPIOC_SETUP)");
	exit(1);
     }
   
   return(0);
}

int xchangeDummy;

void FlushWriteCombining( void ) {
	__asm__ volatile( " push %%eax ; xchg %%eax, %0 ; pop %%eax" : : "m" (xchangeDummy));
	__asm__ volatile( " push %%eax ; push %%ebx ; push %%ecx ; push %%edx ; movl $0,%%eax ; cpuid ; pop %%edx ; pop %%ecx ; pop %%ebx ; pop %%eax" : /* no outputs */ :  /* no inputs */ );
}

void BenchMark()
{
  int i, worked = 1;

  i = MemoryBenchmark(gart, (1024 * 1024 * 4) / 4) +
    MemoryBenchmark(gart, (1024 * 1024 * 4) / 4) +
    MemoryBenchmark(gart, (1024 * 1024 * 4) / 4);
  
  printf("Average speed: %i mb/s\n", i /3);
  
  printf("Testing data integrity (1st pass): ");
  fflush(stdout);
   
  FlushWriteCombining();
  
  for (i=0; i < 8 * 0x100000; i++)
    {
      gart[i] = i % 256;
    }
   
  FlushWriteCombining();
   
  
  for (i=0; i < 8 * 0x100000; i++)
    {
       if(!(gart[i] == i % 256))
	 {
#ifdef DEBUG
	    printf("failed on %i, gart[i] = %i\n", i, gart[i]);
#endif
	    worked = 0;
	 }
    }
  
  if (!worked)
    printf("failed on first pass!\n");
  else
    printf("passed on first pass.\n");
   
   unbind_gart(0);
   unbind_gart(1);
   bind_gart(0, 0);
   bind_gart(1, 1024);

   worked = 1;
   printf("Testing data integrity (2nd pass): ");
   fflush(stdout);
   
   for (i=0; i < 8 * 0x100000; i++)
    {
       if(!(gart[i] == i % 256))
	 {
#ifdef DEBUG
	    printf("failed on %i, gart[i] = %i\n", i, gart[i]);
#endif
	    worked = 0;
	 }
    }

   if (!worked)
    printf("failed on second pass!\n");
  else
    printf("passed on second pass.\n");
}

int main()
{
   int i;
   int key;
   int key2;
   agp_info info;
  
   gartfd = open("/dev/agpgart", O_RDWR);
   if (gartfd == -1)
     {	
	perror("open");
	exit(1);
     }
   
   init_agp();
   
   key = insert_gart(0, 1024);
   key2 = insert_gart(1024, 1024);
   
#ifdef DEBUG
   printf("Using AGPIOC_INFO\n");
   if(ioctl(gartfd, AGPIOC_INFO, &info) != 0)
     {
	perror("ioctl(AGPIOC_INFO)");
	exit(1);
     }
   
   printf("version: %i.%i\n", info.version.major, info.version.minor);
   printf("bridge id: 0x%lx\n", info.bridge_id);
   printf("agp_mode: 0x%lx\n", info.agp_mode);
   printf("aper_base: 0x%lx\n", info.aper_base);
   printf("aper_size: %i\n", info.aper_size);
   printf("pg_total: %i\n", info.pg_total);
   printf("pg_system: %i\n", info.pg_system);
   printf("pg_used: %i\n", info.pg_used);
#endif
   
   printf("Allocated 8 megs of GART memory\n");
   
   BenchMark();
   
   remove_gart(key);
   remove_gart(key2);

#ifdef DEBUG   
   printf("Using AGPIOC_RELEASE\n");
#endif
   if(ioctl(gartfd, AGPIOC_RELEASE) != 0)
     {
	perror("ioctl(AGPIOC_RELEASE)");
	exit(1);
     }
   
   close(gartfd);
}

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Abraham vd Merwe]

[-- Attachment #1: Type: text/plain, Size: 1931 bytes --]

Hi Didier!

I misunderstood. I thought you have an on-board 830M video card :P

So you have an 830M motherboard, with a Radeon display card?

> >
> >
> >     VideoRam "65536"
> >
> 
> Are you sure about this ? I only have 32 MB.

As I said, I misunderstood. I thought you were using the i810 display driver
and I wanted to see what happens if you force the GART module to allocate
some additional system memory.

> Should this be tested with both patches ? I'm getting several 
> suggestions about this problem : the possible permutations are 
> augmenting, and I have some work to do too ... :)

If you have a Radeon display card and an 830M motherboard chipset, it might
be that the agpgart module is trying to use the 830M display chipset code.
that would definitely cause problems.

Before applying any patches, make sure that you have selected the following

[*]   Intel 440LX/BX/GX and I815/I830M/I840/I850 support

(i.e. CONFIG_AGP_INTEL=y)

when compiling the kernel, but NOT!!!!! the following:

[ ]   Intel I810/I815/I830M (on-board) support

(i.e. CONFIG_AGP_I810=n)

If the agpgart module then crashes when you load it, there is a bug and you
should send me/kernel mailinglist the oops.

As for display problems, you should ask on the dri-devel mailinglist which
is the proper place to post display driver bugs. (If it we're the i810
display driver I could help you)

-- 

Regards
 Abraham

Don't drink when you drive -- you might hit a bump and spill it.

__________________________________________________________
 Abraham vd Merwe - 2d3D, Inc.

 Device Driver Development, Outsourcing, Embedded Systems

  Cell: +27 82 565 4451         Snailmail:
   Tel: +27 21 761 7549            Block C, Antree Park
   Fax: +27 21 761 7648            Doncaster Road
 Email: abraham@2d3d.co.za         Kenilworth, 7700
  Http: http://www.2d3d.com        South Africa


[-- Attachment #2: Type: application/pgp-signature, Size: 232 bytes --]

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Didier Moens]

Abraham vd Merwe wrote:


> Hi Didier!
> 
> I misunderstood. I thought you have an on-board 830M video card :P
> 
> So you have an 830M motherboard, with a Radeon display card?



Seems like I'm having some egg on my face here. Argh !

According to http://developer.intel.com/design/chipsets/mobile/830.htm :

830MP : supports external AGP2X/4X graphics
830M  : includes Intel's next generation performance oriented integrated 
graphics controller, featuring Intel® Graphics Technology, as well as 
external AGP2X/4X graphics support
830MG : supports value oriented integrated graphics for value priced 
notebook segments


To sum up : this is an IBM A30p, with an "external" Radeon Mobility LY 
(32 MB), and an 830MP instead of an 830M. The 830MP is common for both 
IBM A30 and A30p models.


Sorry about wasting your time this way : I should get my facts straight 
in the first place. I did have oopses, though.  ;)


No mention of the 830MP in the kernel sources ; patches are welcome.  :)




> If you have a Radeon display card and an 830M motherboard chipset, it might
> be that the agpgart module is trying to use the 830M display chipset code.
> that would definitely cause problems.




Regards,

Didier

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Nicolas Aspert]

[-- Attachment #1: Type: text/plain, Size: 735 bytes --]


> 
> 
> To sum up : this is an IBM A30p, with an "external" Radeon Mobility LY 
> (32 MB), and an 830MP instead of an 830M. The 830MP is common for both 
> IBM A30 and A30p models.
> 
> 

OK ! so you _do_ have an external graphic card (that's what looked unclear to me), 

for which AGP should work in the same way it does for other Intel chipsets...

So why not trying the little patch I attach below, which should make 
your stuff work, without breaking too much the i830 support for on-board 
adapters... The patch is for 2.4.16, but is likely to be applied easily 
on another recent kernel. Keep me informed...

Best regards
-- 
Nicolas Aspert      Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)


[-- Attachment #2: patch-agp_i830mp-2.4.16 --]
[-- Type: text/plain, Size: 4642 bytes --]

diff -Nru linux-2.4.16.clean/drivers/char/agp/agp.h linux-2.4.16.dirty/drivers/char/agp/agp.h
--- linux-2.4.16.clean/drivers/char/agp/agp.h	Fri Nov  9 23:01:21 2001
+++ linux-2.4.16.dirty/drivers/char/agp/agp.h	Mon Nov 26 13:25:56 2001
@@ -276,6 +276,8 @@
 #define I830_RDRAM_ND(x)           (((x) & 0x20) >> 5)
 #define I830_RDRAM_DDT(x)          (((x) & 0x18) >> 3)
 
+#define INTEL_I830_ERRSTS          0x92
+
 /* intel i820 registers */
 #define INTEL_I820_RDCR     0x51
 #define INTEL_I820_ERRSTS   0xc8
diff -Nru linux-2.4.16.clean/drivers/char/agp/agpgart_be.c linux-2.4.16.dirty/drivers/char/agp/agpgart_be.c
--- linux-2.4.16.clean/drivers/char/agp/agpgart_be.c	Fri Nov 16 19:11:22 2001
+++ linux-2.4.16.dirty/drivers/char/agp/agpgart_be.c	Tue Nov 27 11:00:39 2001
@@ -1705,6 +1705,38 @@
 	return 0;
 }
 
+static int intel_830mp_configure(void)
+{
+	u32 temp;
+	u16 temp2;
+	aper_size_info_8 *current_size;
+
+	current_size = A_SIZE_8(agp_bridge.current_size);
+
+	/* aperture size */
+	pci_write_config_byte(agp_bridge.dev, INTEL_APSIZE,
+			      current_size->size_value);
+
+	/* address to map to */
+	pci_read_config_dword(agp_bridge.dev, INTEL_APBASE, &temp);
+	agp_bridge.gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
+
+	/* attbase - aperture base */
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE,
+			       agp_bridge.gatt_bus_addr);
+
+	/* agpctrl */
+	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000);
+
+	/* gmch */
+	pci_read_config_word(agp_bridge.dev, INTEL_NBXCFG, &temp2);
+	pci_write_config_word(agp_bridge.dev, INTEL_NBXCFG,
+			      temp2 | (1 << 9));
+	/* clear any possible AGP-related error conditions */
+	pci_write_config_word(agp_bridge.dev, INTEL_I830_ERRSTS, 0x1c);
+	return 0;
+}
+
 static unsigned long intel_mask_memory(unsigned long addr, int type)
 {
 	/* Memory type is ignored */
@@ -1745,6 +1777,14 @@
 	{4, 1024, 0, 63}
 };
 
+static aper_size_info_8 intel_830mp_sizes[4] = 
+{
+  {256, 65536, 6, 0},
+  {128, 32768, 5, 32},
+  {64, 16384, 4, 48},
+  {32, 8192, 3, 56}
+};
+
 static int __init intel_generic_setup (struct pci_dev *pdev)
 {
 	agp_bridge.masks = intel_generic_masks;
@@ -1809,6 +1849,35 @@
        (void) pdev; /* unused */
 }
 
+static int __init intel_830mp_setup (struct pci_dev *pdev)
+{
+       agp_bridge.masks = intel_generic_masks;
+       agp_bridge.num_of_masks = 1;
+       agp_bridge.aperture_sizes = (void *) intel_830mp_sizes;
+       agp_bridge.size_type = U8_APER_SIZE;
+       agp_bridge.num_aperture_sizes = 4;
+       agp_bridge.dev_private_data = NULL;
+       agp_bridge.needs_scratch_page = FALSE;
+       agp_bridge.configure = intel_830mp_configure;
+       agp_bridge.fetch_size = intel_8xx_fetch_size;
+       agp_bridge.cleanup = intel_8xx_cleanup;
+       agp_bridge.tlb_flush = intel_8xx_tlbflush;
+       agp_bridge.mask_memory = intel_mask_memory;
+       agp_bridge.agp_enable = agp_generic_agp_enable;
+       agp_bridge.cache_flush = global_cache_flush;
+       agp_bridge.create_gatt_table = agp_generic_create_gatt_table;
+       agp_bridge.free_gatt_table = agp_generic_free_gatt_table;
+       agp_bridge.insert_memory = agp_generic_insert_memory;
+       agp_bridge.remove_memory = agp_generic_remove_memory;
+       agp_bridge.alloc_by_type = agp_generic_alloc_by_type;
+       agp_bridge.free_by_type = agp_generic_free_by_type;
+       agp_bridge.agp_alloc_page = agp_generic_alloc_page;
+       agp_bridge.agp_destroy_page = agp_generic_destroy_page;
+
+       return 0;
+
+       (void) pdev; /* unused */
+}
 
 static int __init intel_840_setup (struct pci_dev *pdev)
 {
@@ -3557,7 +3626,7 @@
 		INTEL_I830_M,
 		"Intel",
 		"i830M",
-		intel_generic_setup },
+		intel_830mp_setup },
 	{ PCI_DEVICE_ID_INTEL_840_0,
 		PCI_VENDOR_ID_INTEL,
 		INTEL_I840,
@@ -3879,18 +3948,20 @@
 			i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
 									   PCI_DEVICE_ID_INTEL_830_M_1,
 									   NULL);
-			if(PCI_FUNC(i810_dev->devfn) != 0) {
+			if(i810_dev && PCI_FUNC(i810_dev->devfn) != 0) {
 				i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
 										   PCI_DEVICE_ID_INTEL_830_M_1,
 										   i810_dev);
 			}
 
 			if (i810_dev == NULL) {
-				printk(KERN_ERR PFX "Detected an "
+				printk(KERN_INFO PFX "Detected an "
 					   "Intel 830M, but could not find the"
-					   " secondary device.\n");
-				agp_bridge.type = NOT_SUPPORTED;
-				return -ENODEV;
+ 				           " secondary device.\n");
+				printk(KERN_INFO PFX "Trying the "
+					   "Intel 830MP stuff\n");
+				agp_bridge.type = INTEL_I830_M;
+				break;
 			}
 			printk(KERN_INFO PFX "Detected an Intel "
 				   "830M Chipset.\n");

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Didier Moens]

Nicolas Aspert wrote:

> 
>>
>>
>> To sum up : this is an IBM A30p, with an "external" Radeon Mobility LY 
>> (32 MB), and an 830MP instead of an 830M. The 830MP is common for both 
>> IBM A30 and A30p models.
>>
>>
> 
> OK ! so you _do_ have an external graphic card (that's what looked 
> unclear to me),
> for which AGP should work in the same way it does for other Intel 
> chipsets...
> 
> So why not trying the little patch I attach below, which should make 
> your stuff work, without breaking too much the i830 support for on-board 
> adapters... The patch is for 2.4.16, but is likely to be applied easily 
> on another recent kernel. Keep me informed...


1. modprobe agpgart loads OK :

Nov 27 11:34:47 localhost kernel: Linux agpgart interface v0.99 (c) Jeff 
Hartmann
Nov 27 11:34:47 localhost kernel: agpgart: Maximum main memory to use 
for agp memory: 439M
Nov 27 11:34:47 localhost kernel: agpgart: Detected an Intel 830M, but 
could not find the secondary device.
Nov 27 11:34:47 localhost kernel: agpgart: Trying the Intel 830MP stuff
Nov 27 11:34:47 localhost kernel: agpgart: Detected Intel i830M chipset
Nov 27 11:34:47 localhost kernel: agpgart: AGP aperture is 256M @ 0xd0000000


[root@localhost agp]# /home/didier/repository/kernel/testgart
version: 0.99
bridge id: 0x35758086
agp_mode: 0x1f000217
aper_base: 0xd0000000
aper_size: 256
pg_total: 112384
pg_system: 112384
pg_used: 0
entry.key : 0
entry.key : 1
Allocated 8 megs of GART memory
MemoryBenchmark: 858 mb/s
MemoryBenchmark: 876 mb/s
MemoryBenchmark: 890 mb/s
Average speed: 874 mb/s
Testing data integrity (1st pass): passed on first pass.
Testing data integrity (2nd pass): passed on second pass.




2. compared to Stephan's original patches ("if i830m_dev ..." and 
"break;") :

Nov 27 11:37:07 localhost kernel: Linux agpgart interface v0.99 (c) Jeff 
Hartmann
Nov 27 11:37:07 localhost kernel: agpgart: Maximum main memory to use 
for agp memory: 439M
Nov 27 11:37:07 localhost kernel: agpgart: Detected Intel i830M chipset
Nov 27 11:37:07 localhost kernel: agpgart: AGP aperture is 256M @ 0xd0000000

[root@localhost agp]# /home/didier/repository/kernel/testgart
version: 0.99
bridge id: 0x35758086
agp_mode: 0x1f000217
aper_base: 0xd0000000
aper_size: 256
pg_total: 112384
pg_system: 112384
pg_used: 0
entry.key : 0
entry.key : 1
Allocated 8 megs of GART memory
MemoryBenchmark: 859 mb/s
MemoryBenchmark: 887 mb/s
MemoryBenchmark: 876 mb/s
Average speed: 874 mb/s
Testing data integrity (1st pass): passed on first pass.
Testing data integrity (2nd pass): passed on second pass.



Is the 8 megs of GART OK ?
Is the memory benchmark comparable to equally equipped machines (1.2G 
P-III(M), i830(MP), ATI Radeon(M)) ? (I'm trying to differentiate my 
performance problem between agpgart and X DRI/DRM).



Kind regards,

Didier

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Stephan von Krawczynski]

On Tue, 27 Nov 2001 11:48:35 +0100
Didier Moens <Didier.Moens@dmb.rug.ac.be> wrote:

> 2. compared to Stephan's original patches ("if i830m_dev ..." and 
> "break;") :
> 
> Nov 27 11:37:07 localhost kernel: Linux agpgart interface v0.99 (c) Jeff 
> Hartmann
> Nov 27 11:37:07 localhost kernel: agpgart: Maximum main memory to use 
> for agp memory: 439M
> Nov 27 11:37:07 localhost kernel: agpgart: Detected Intel i830M chipset
> Nov 27 11:37:07 localhost kernel: agpgart: AGP aperture is 256M @ 0xd0000000
> 
> [root@localhost agp]# /home/didier/repository/kernel/testgart
> version: 0.99
> bridge id: 0x35758086
> agp_mode: 0x1f000217
> aper_base: 0xd0000000
> aper_size: 256
> pg_total: 112384
> pg_system: 112384
> pg_used: 0
> entry.key : 0
> entry.key : 1
> Allocated 8 megs of GART memory
> MemoryBenchmark: 859 mb/s
> MemoryBenchmark: 887 mb/s
> MemoryBenchmark: 876 mb/s
> Average speed: 874 mb/s
> Testing data integrity (1st pass): passed on first pass.
> Testing data integrity (2nd pass): passed on second pass.

Ok, since performance and detection seems just ok, I would suggest the attached
patch as a fix. Unlike Nicolas I don't see a need for an additional i830MP
patch, its only the correct detection of the different i830 setups that needs
to be done IMHO.
If there are no further complaints we should submit the patch. What do you
think Nicolas?

Regards,
Stephan


--- agpgart_be.c-orig   Tue Nov 27 12:07:14 2001
+++ agpgart_be.c        Tue Nov 27 12:07:02 2001
@@ -3879,6 +3879,10 @@
                        i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
                                                                          
PCI_DEVICE_ID_INTEL_830_M_1,
                                                                          
NULL);
+                       /* If we cannot find secondary, we probably have i830MP
+                          which is detected later on */
+                       if (i810_dev == NULL) 
+                               break;
                        if(PCI_FUNC(i810_dev->devfn) != 0) {
                                i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
                                                                               
  PCI_DEVICE_ID_INTEL_830_M_1,

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Nicolas Aspert]

> 
> Ok, since performance and detection seems just ok, I would suggest the attached
> patch as a fix. Unlike Nicolas I don't see a need for an additional i830MP
> patch, its only the correct detection of the different i830 setups that needs
> to be done IMHO.
> If there are no further complaints we should submit the patch. What do you
> think Nicolas?
> 

Well, I prefer my version on the patch (of course :-), and I find it 
cleaner. Let me explain why : by just adding the 'break', you will fall 
back to the generic initialization routines, which work in most of the 
cases. However, if you look deeper the code & the specs, they are not 
really that good. Esp., you will see that the APSIZE register is 
accessed through 16bit reads/writes, whereas the spec says this is a 8 
bit register. I have been taught not to write where it is not 
explicitely allowed to. Moreover, the 'tlbflush' mechanism also writes 
over reserved bits when using the generic routine. My patch is just a 
adaptation of what had been done for the Intel 8xx routines (to which I 
have contributed), so my way is more consistent with what was previously 
done.
However, before submitting the patch, I would like to hear from Didier 
about the X server stuff.
Does it still hard-locks when you start it ? If testgart works (which 
seems to be the case... btw, yes the 8MB alloced by the program are 
normal) and X locks, this would look more like a DRI/X problem (I saw 
some problems w. Radeon cards on the dri-devel list, which do not seem 
to be fully solved yet)

Best regards
-- 
Nicolas Aspert      Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Stephan von Krawczynski]

On Tue, 27 Nov 2001 12:43:47 +0100
Nicolas Aspert <Nicolas.Aspert@epfl.ch> wrote:

> > If there are no further complaints we should submit the patch. What do you
> > think Nicolas?
> > 
> 
> Well, I prefer my version on the patch (of course :-), 

Guess what: I expected that :-)

>and I find it 
> cleaner. Let me explain why : by just adding the 'break', you will fall 
> back to the generic initialization routines, which work in most of the 
> cases. However, if you look deeper the code & the specs, they are not 
> really that good.

I re-read the code according to your notes. Since I do not have the docs at
hand I am going to trust your word and indeed believe your patch is cleaner.
Only a personal add-on: make it a bit less verbosely talking to the user ;-) I
think we do not need to tell him three times he has i830. One line should be
sufficient. But obviously thats nothing of real importance.


> However, before submitting the patch, I would like to hear from Didier 
> about the X server stuff.
> Does it still hard-locks when you start it ? If testgart works (which 
> seems to be the case... btw, yes the 8MB alloced by the program are 
> normal) and X locks, this would look more like a DRI/X problem (I saw 
> some problems w. Radeon cards on the dri-devel list, which do not seem 
> to be fully solved yet)

This really looks like an X issue to me and not related to agp.

Thanks for your support, Nicolas.

Regards,
Stephan

PS: you propose the patch to l & m :-) we killed yet another oops.

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Didier Moens]

Nicolas Aspert wrote:

> 
>>
>> Ok, since performance and detection seems just ok, I would suggest the 
>> attached
>> patch as a fix. Unlike Nicolas I don't see a need for an additional 
>> i830MP
>> patch, its only the correct detection of the different i830 setups 
>> that needs
>> to be done IMHO.
>> If there are no further complaints we should submit the patch. What do 
>> you
>> think Nicolas?
>>
> 
> Well, I prefer my version on the patch (of course :-), and I find it 
> cleaner. Let me explain why : by just adding the 'break', you will fall 
> back to the generic initialization routines, which work in most of the 
> cases. However, if you look deeper the code & the specs, they are not 
> really that good. Esp., you will see that the APSIZE register is 
> accessed through 16bit reads/writes, whereas the spec says this is a 8 
> bit register. I have been taught not to write where it is not 
> explicitely allowed to. Moreover, the 'tlbflush' mechanism also writes 
> over reserved bits when using the generic routine. My patch is just a 
> adaptation of what had been done for the Intel 8xx routines (to which I 
> have contributed), so my way is more consistent with what was previously 
> done.
> However, before submitting the patch, I would like to hear from Didier 
> about the X server stuff.
> Does it still hard-locks when you start it ? If testgart works (which 
> seems to be the case... btw, yes the 8MB alloced by the program are 
> normal) and X locks, this would look more like a DRI/X problem (I saw 
> some problems w. Radeon cards on the dri-devel list, which do not seem 
> to be fully solved yet)


No more X hard locks.

Compiled & installed latest CVS X (20011127), which includes a Radeon 
DGA 2.0 patch : everything fine and dandy (except for my 3D performance 
problem).

Kudos to the developer community.


Kind regards,
Didier


Didier Moens
-----
RUG/VIB - Dept. Molecular Biology - Core IT
tel ++32(9)2645309 fax ++32(9)2645348
http://www.dmb.rug.ac.be

Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Stephan von Krawczynski]

On Mon, 26 Nov 2001 23:16:33 +0100
Didier Moens <moensd@xs4all.be> wrote:

> Dear Robert, Nicolas, Stephan,   :)
> 
> I got two patches :
> 
> 
> 1. From Stephan, to test whether my assumption about the secondary 
> device was right :
> 
> Stephan wrote :
> 
> But if you want you can check that out pretty simple: just add a "break" 
> right
> after the case :
> 
>                  case PCI_DEVICE_ID_INTEL_830_M_0:
> ---> break;
> 
>                          i810_dev = pci_find_device(PCI_VENDOR_ID_INTEL,
> 
> 
> This patch left me with a loaded agpgart, and accelerated X (DRM/DRI). 
> The acceleration is still not up to par with an ATI Mobility-128 (30% 
> lower, while it should be at least 200% faster), but I suspect an X 
> CVS-problem here.
> 
> Quitting and restarting X leaves me with a locked black screen.

Can you provide the output provided by the agp module at load time, please?
This mini-patch of mine should indeed be technically sufficient. Of course I
will provide a "real-world" patch working for all i830 agp-chipsets (M or MG)
as soon as it is clear, that the detection still works.
I am a bit bothered by your X setup. Can you stabilize this somehow? Maybe
using some known-to-work (older) X version for your graphics card.

It looks solvable.

Regards,
Stephan

[PATCH]Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Nicolas Aspert]

[-- Attachment #1: Type: text/plain, Size: 553 bytes --]

Hello again


Here is a patch that _might_ improve things wrt. agp support for i830 
chipsets. I do not have a i830 box at hand, so it has not been tested 
(well, it compiles ok. ;-). If you feel like crashing your PC once more, 
try the patch (against 2.4.15) and tell me whether things became 
better/worse.
I assumed that the i830mg without secondary device was working in a way 
that is similar to other Intel chipsets.

Good luck :-)

Nicolas.
-- 
Nicolas Aspert      Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)

[-- Attachment #2: patch-agp_i830mg-2.4.15 --]
[-- Type: text/plain, Size: 4154 bytes --]

diff -Nru linux-2.4.15.clean/drivers/char/agp/agp.h linux-2.4.15.dirty/drivers/char/agp/agp.h
--- linux-2.4.15.clean/drivers/char/agp/agp.h	Fri Nov  9 23:01:21 2001
+++ linux-2.4.15.dirty/drivers/char/agp/agp.h	Mon Nov 26 13:25:56 2001
@@ -276,6 +276,8 @@
 #define I830_RDRAM_ND(x)           (((x) & 0x20) >> 5)
 #define I830_RDRAM_DDT(x)          (((x) & 0x18) >> 3)
 
+#define INTEL_I830_ERRSTS          0x92
+
 /* intel i820 registers */
 #define INTEL_I820_RDCR     0x51
 #define INTEL_I820_ERRSTS   0xc8
diff -Nru linux-2.4.15.clean/drivers/char/agp/agpgart_be.c linux-2.4.15.dirty/drivers/char/agp/agpgart_be.c
--- linux-2.4.15.clean/drivers/char/agp/agpgart_be.c	Fri Nov 16 19:11:22 2001
+++ linux-2.4.15.dirty/drivers/char/agp/agpgart_be.c	Mon Nov 26 13:35:29 2001
@@ -1705,6 +1705,38 @@
 	return 0;
 }
 
+static int intel_830mg_configure(void)
+{
+	u32 temp;
+	u16 temp2;
+	aper_size_info_8 *current_size;
+
+	current_size = A_SIZE_8(agp_bridge.current_size);
+
+	/* aperture size */
+	pci_write_config_byte(agp_bridge.dev, INTEL_APSIZE,
+			      current_size->size_value);
+
+	/* address to map to */
+	pci_read_config_dword(agp_bridge.dev, INTEL_APBASE, &temp);
+	agp_bridge.gart_bus_addr = (temp & PCI_BASE_ADDRESS_MEM_MASK);
+
+	/* attbase - aperture base */
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE,
+			       agp_bridge.gatt_bus_addr);
+
+	/* agpctrl */
+	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000);
+
+	/* gmch */
+	pci_read_config_word(agp_bridge.dev, INTEL_NBXCFG, &temp2);
+	pci_write_config_word(agp_bridge.dev, INTEL_NBXCFG,
+			      temp2 | (1 << 9));
+	/* clear any possible AGP-related error conditions */
+	pci_write_config_word(agp_bridge.dev, INTEL_I830_ERRSTS, 0x1c);
+	return 0;
+}
+
 static unsigned long intel_mask_memory(unsigned long addr, int type)
 {
 	/* Memory type is ignored */
@@ -1745,6 +1777,14 @@
 	{4, 1024, 0, 63}
 };
 
+static aper_size_info_8 intel_830mg_sizes[4] = 
+{
+  {256, 65536, 6, 0},
+  {128, 32768, 5, 32},
+  {64, 16384, 4, 48},
+  {32, 8192, 3, 56}
+};
+
 static int __init intel_generic_setup (struct pci_dev *pdev)
 {
 	agp_bridge.masks = intel_generic_masks;
@@ -1809,6 +1849,35 @@
        (void) pdev; /* unused */
 }
 
+static int __init intel_830mg_setup (struct pci_dev *pdev)
+{
+       agp_bridge.masks = intel_generic_masks;
+       agp_bridge.num_of_masks = 1;
+       agp_bridge.aperture_sizes = (void *) intel_830mg_sizes;
+       agp_bridge.size_type = U8_APER_SIZE;
+       agp_bridge.num_aperture_sizes = 4;
+       agp_bridge.dev_private_data = NULL;
+       agp_bridge.needs_scratch_page = FALSE;
+       agp_bridge.configure = intel_830mg_configure;
+       agp_bridge.fetch_size = intel_8xx_fetch_size;
+       agp_bridge.cleanup = intel_8xx_cleanup;
+       agp_bridge.tlb_flush = intel_8xx_tlbflush;
+       agp_bridge.mask_memory = intel_mask_memory;
+       agp_bridge.agp_enable = agp_generic_agp_enable;
+       agp_bridge.cache_flush = global_cache_flush;
+       agp_bridge.create_gatt_table = agp_generic_create_gatt_table;
+       agp_bridge.free_gatt_table = agp_generic_free_gatt_table;
+       agp_bridge.insert_memory = agp_generic_insert_memory;
+       agp_bridge.remove_memory = agp_generic_remove_memory;
+       agp_bridge.alloc_by_type = agp_generic_alloc_by_type;
+       agp_bridge.free_by_type = agp_generic_free_by_type;
+       agp_bridge.agp_alloc_page = agp_generic_alloc_page;
+       agp_bridge.agp_destroy_page = agp_generic_destroy_page;
+
+       return 0;
+
+       (void) pdev; /* unused */
+}
 
 static int __init intel_840_setup (struct pci_dev *pdev)
 {
@@ -3886,11 +3955,13 @@
 			}
 
 			if (i810_dev == NULL) {
-				printk(KERN_ERR PFX "Detected an "
+				printk(KERN_INFO PFX "Detected an "
 					   "Intel 830M, but could not find the"
-					   " secondary device.\n");
-				agp_bridge.type = NOT_SUPPORTED;
-				return -ENODEV;
+ 				           " secondary device.\n");
+				printk(KERN_INFO PFX "Trying the "
+					   "Intel 830MG stuff\n");
+				agp_bridge.type = INTEL_I830_M;
+				return intel_830mg_setup(dev);
 			}
 			printk(KERN_INFO PFX "Detected an Intel "
 				   "830M Chipset.\n");

Re: [PATCH]Re: [Fwd: Re: OOPS in agpgart (2.4.13, 2.4.15pre7)]

[Nicolas Aspert]

Nicolas Aspert wrote:

> Hello again
> 
> 
> Here is a patch that _might_ improve things wrt. agp support for i830 
> chipsets. I do not have a i830 box at hand, so it has not been tested 
> (well, it compiles ok. ;-). If you feel like crashing your PC once more, 
> try the patch (against 2.4.15) and tell me whether things became 
> better/worse.
> I assumed that the i830mg without secondary device was working in a way 
> that is similar to other Intel chipsets.
> 

It seems that I made a (silly) confusion between i830M and i830MG. 
Anyway, take my previous patch and replace MG by M wherever it may be 
relevant, and it may do the trick. Anyway, I am not quite sure about the 
differences between those two versions.... (the Intel specs are not 
clear at all about this.)

a+
-- 
Nicolas Aspert      Signal Processing Laboratory (LTS)
Swiss Federal Institute of Technology (EPFL)