PROBLEM: memory corruption with i815 chipset variant

PROBLEM: memory corruption with i815 chipset variant

[Alessandro Morelli]

Greetings to all,

1. Memory corruption tied to use of agpgart module with variant of
Intel i815

2. Loading the agpgart module causes memory corruption in presence of
an Intel i815 AGP Bridge (PCI ID 0x1131, specifically). Command
"memtest all" reports failures in writing to addresses throughout
entire memory space, filesystem opertions start to fail, albeit in
limited manner, memory intensive applications eventually generate
oopses lamenting NULL pointer exceptions, invalid pages, invalid EIP
in apparently unrelated sections of the kernel (VM, VFS, networking
layer, SMP, et cetera)

3. AGP, modules, kernel, memory, corruption, instability

4. Version currently under test:
Linux version 2.4.19-pre8-ac5 (root@anduril) (gcc version 2.95.4 20010810 (Debian prerelease)) #1 Tue May 21 11:24:29 CEST 2002

5. N/A. Oopses were seen in non-exactly-repeatable conditions
(although memory intensive tasks increased frequency)

6. Not really applicable, however...
	modprobe agpgart

7. Machine under test: ASUS L8400L
7.1
Linux palantir 2.4.19-pre8-ac5 #1 Tue May 21 11:24:29 CEST 2002 i686 unknown

Gnu C				2.95.4
Gnu make			3.79.1
util-linux			2.11h
mount				2.10q
modutils			2.4.11
e2fsprogs			1.27
reiserprogs			3.x.0j
PPP				2.4.0
Linux C Library			2.2.5
Dynamic linker (ldd)		2.2.5
Procps				2.0.6
Net-tools			1.54
Console-tools			0.2.3
Sh-utils			2.0
Modules Loaded			agpgart pcmcia_core lp irnet ppp_generic slhc irlan irtty irport i2c-philips-par parport i2c-velleman i2c-proc i2c-dev i2c-algo-pcf i2c-algo-bit i2c-core ircomm-tty ircomm irda ospm_processor ospm_button ospm_battery ospm_ac_adapter ospm_system ospm_busmgr 8139too mii rtc

7.2
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 11
model name      : Intel(R) Pentium(R) III CPU             1133MHz
stepping        : 1
cpu MHz         : 1135.944
cache size      : 256 KB
fdiv_bug        : no
hlt_bug         : no
f00f_bug        : no
coma_bug        : no
fpu             : yes
fpu_exception   : yes
cpuid level     : 2
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat pse36 mmx fxsr sse
bogomips        : 2267.54
 
7.3
agpgart		       29632   0 (unused)
pcmcia_core            35392   0
lp                      6976   0 (autoclean) (unused)
irnet                  27360   0 (unused)
ppp_generic            19820   0 [irnet]
slhc                    4368   0 [ppp_generic]
irlan                  18560   0 (unused)
irtty                   5472   0 (unused)
irport                  4664   0 (unused)
i2c-philips-par         1928   0 (unused)
parport                22944   0 [lp i2c-philips-par]
i2c-velleman            1408   0 (unused)
i2c-proc                6240   0 (unused)
i2c-dev                 3840   0 (unused)
i2c-algo-pcf            4864   0 (unused)
i2c-algo-bit            7084   1 [i2c-philips-par i2c-velleman]
i2c-core               12800   0 [i2c-proc i2c-dev i2c-algo-pcf i2c-algo-bit]
ircomm-tty             18880   0 (unused)
irlan                  18560   0 (unused)
irtty                   5472   0 (unused)
irport                  4664   0 (unused)
i2c-philips-par         1928   0 (unused)
parport                22944   0 [lp i2c-philips-par]
i2c-velleman            1408   0 (unused)
i2c-proc                6240   0 (unused)
i2c-dev                 3840   0 (unused)
i2c-algo-pcf            4864   0 (unused)
i2c-algo-bit            7084   1 [i2c-philips-par i2c-velleman]
i2c-core               12800   0 [i2c-proc i2c-dev i2c-algo-pcf i2c-algo-bit]
ircomm-tty             18880   0 (unused)
ircomm                  7068   0 [ircomm-tty]
irda                   80396   0 [irnet irlan irtty irport ircomm-tty ircomm]
ospm_processor          5464   0 (unused)
ospm_button             3136   0 (unused)
ospm_battery            5540   0 (unused)
ospm_ac_adapter         2004   0 (unused)
ospm_system             5836   0 (unused)
ospm_busmgr            11392   0 [ospm_processor ospm_button ospm_battery ospm_ac_adapter ospm_system]
8139too                14816   1
mii                     1088   0 [8139too]
rtc                     5916   0 (autoclean)

7.4
0000-001f : dma1
0020-003f : pic1
0040-005f : timer
0060-006f : keyboard
0070-007f : rtc
0080-008f : dma page reg
00a0-00bf : pic2
00c0-00df : dma2
00f0-00ff : fpu
01f0-01f7 : ide0
0290-0297 : PnPBIOS PNP0c02
02f8-02ff : serial(set)
0378-037f : i2c (Vellemann adapter)
03c0-03df : vga+
03f0-03f1 : PnPBIOS PNP0c02
03f6-03f6 : ide0
03f8-03ff : serial(set)
0cf8-0cff : PCI conf1
a400-a41f : Intel Corp. 82801BA/BAM USB (Hub #1)
  a400-a41f : usb-uhci
a800-a80f : Intel Corp. 82801BA IDE U100
  a800-a807 : ide0
  a808-a80f : ide1
b000-bfff : PCI Bus #02
  b000-b0ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C
    b000-b0ff : 8139too
  b400-b4ff : ESS Technology ESS Modem
  b800-b8ff : ESS Technology ES1988 Allegro-1
d000-dfff : PCI Bus #01
  d800-d8ff : ATI Technologies Inc Radeon Mobility M6 LY
e400-e47f : PnPBIOS PNP0c02
ec00-ec3f : PnPBIOS PNP0c02

00000000-0009fbff : System RAM
0009fc00-0009ffff : reserved
000a0000-000bffff : Video RAM area
000c0000-000c7fff : Video ROM
000f0000-000fffff : System ROM
00100000-0ffebfff : System RAM
  00100000-002c18ba : Kernel code
  002c18bb-0036509f : Kernel data
0ffec000-0ffeefff : ACPI Tables
0ffef000-0fffefff : reserved
0ffff000-0fffffff : ACPI Non-volatile Storage
ee800000-eeffffff : PCI Bus #02
  ee800000-ee8000ff : Realtek Semiconductor Co., Ltd. RTL-8139/8139C
    ee800000-ee8000ff : 8139too
  ee801000-ee801fff : Ricoh Co Ltd RL5c476 II
  ee802000-ee802fff : Ricoh Co Ltd RL5c476 II (#2)
ef000000-efefffff : PCI Bus #01
  ef000000-ef00ffff : ATI Technologies Inc Radeon Mobility M6 LY
eff00000-f7ffffff : PCI Bus #01
  f0000000-f7ffffff : ATI Technologies Inc Radeon Mobility M6 LY
f8000000-fbffffff : Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub
fffc0000-ffffffff : reserved

7.5
00:00.0 Host bridge: Intel Corp. 82815 815 Chipset Host Bridge and Memory Controller Hub (rev 04)
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Region 0: Memory at f8000000 (32-bit, prefetchable) [size=64M]
	Capabilities: [88] #09 [e104]
	Capabilities: [a0] AGP version 2.0
		Status: RQ=31 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA- AGP- 64bit- FW- Rate=<none>

00:01.0 PCI bridge: Intel Corp.: Unknown device 1131 (rev 04) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: ef000000-efefffff
	Prefetchable memory behind bridge: eff00000-f7ffffff
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:1e.0 PCI bridge: Intel Corp. 82820 820 (Camino 2) Chipset PCI (rev 05) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=32
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: ee800000-eeffffff
	Prefetchable memory behind bridge: eff00000-efefffff
	BridgeCtl: Parity- SERR+ NoISA+ VGA- MAbort- >Reset- FastB2B-

00:1f.0 ISA bridge: Intel Corp. 82820 820 (Camino 2) Chipset ISA Bridge (ICH2) (rev 05)
	Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0

00:1f.1 IDE interface: Intel Corp. 82820 820 (Camino 2) Chipset IDE U100 (rev 05) (prog-if 80 [Master])
	Subsystem: Asustek Computer, Inc.: Unknown device 1567
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Region 0: [virtual] I/O ports at 01f0
	Region 1: [virtual] I/O ports at 03f4
	Region 2: [virtual] I/O ports at 0170
	Region 3: [virtual] I/O ports at 0374
	Region 4: I/O ports at a800 [size=16]

00:1f.2 USB Controller: Intel Corp. 82820 820 (Camino 2) Chipset USB (Hub A) (rev 05) (prog-if 00 [UHCI])
	Subsystem: Asustek Computer, Inc.: Unknown device 1567
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin D routed to IRQ 9
	Region 4: I/O ports at a400 [size=32]

01:00.0 VGA compatible controller: ATI Technologies Inc Radeon Mobility M6 LY (prog-if 00 [VGA])
	Subsystem: Asustek Computer, Inc.: Unknown device 1491
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping+ SERR- FastB2B-
	Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 64 (2000ns min), cache line size 08
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at f0000000 (32-bit, prefetchable) [size=128M]
	Region 1: I/O ports at d800 [size=256]
	Region 2: Memory at ef000000 (32-bit, non-prefetchable) [size=64K]
	Expansion ROM at effe0000 [disabled] [size=128K]
	Capabilities: [58] AGP version 2.0
		Status: RQ=47 SBA+ 64bit- FW- Rate=x1,x2
		Command: RQ=0 SBA+ AGP- 64bit- FW- Rate=<none>
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:01.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1 (rev 12)
	Subsystem: Asustek Computer, Inc.: Unknown device 1049
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (500ns min, 6000ns max)
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at b800 [size=256]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA PME(D0-,D1+,D2+,D3hot+,D3cold-)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:01.1 Communication controller: ESS Technology ESS Modem (rev 12)
	Subsystem: Asustek Computer, Inc.: Unknown device 1049
	Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 5
	Region 0: I/O ports at b400 [size=256]
	Capabilities: [c0] Power Management version 2
		Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=100mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:03.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
	Subsystem: Asustek Computer, Inc.: Unknown device 1045
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 32 (8000ns min, 16000ns max)
	Interrupt: pin A routed to IRQ 9
	Region 0: I/O ports at b000 [size=256]
	Region 1: Memory at ee800000 (32-bit, non-prefetchable) [size=256]
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0-,D1+,D2+,D3hot+,D3cold+)
		Status: D0 PME-Enable- DSel=0 DScale=0 PME-

02:05.0 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
	Subsystem: Asustek Computer, Inc.: Unknown device 1564
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin A routed to IRQ 11
	Region 0: Memory at ee801000 (32-bit, non-prefetchable) [disabled] [size=4K]
	Bus: primary=02, secondary=03, subordinate=06, sec-latency=0
	Memory window 0: 00000000-00000000 [disabled] (prefetchable)
	Memory window 1: 00000000-00000000 [disabled] (prefetchable)
	I/O window 0: 00000000-00000003 [disabled]
	I/O window 1: 00000000-00000003 [disabled]
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
	16-bit legacy interface ports at 0001

02:05.1 CardBus bridge: Ricoh Co Ltd RL5c476 II (rev 80)
	Subsystem: Asustek Computer, Inc.: Unknown device 1564
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin B routed to IRQ 11
	Region 0: Memory at ee802000 (32-bit, non-prefetchable) [disabled] [size=4K]
	Bus: primary=02, secondary=07, subordinate=0a, sec-latency=0
	Memory window 0: 00000000-00000000 [disabled] (prefetchable)
	Memory window 1: 00000000-00000000 [disabled] (prefetchable)
	I/O window 0: 00000000-00000003 [disabled]
	I/O window 1: 00000000-00000003 [disabled]
	BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt- PostWrite+
	16-bit legacy interface ports at 0001

7.6 N/A

7.7 None

8. Graphic card has 16MB of memory: Region 0 is reported to be 128M
(AFAIK, it could be correct).
ASUS has used the i815 chipset without the CGC, using a Radeon
Mobility M6 LY instead.  All problems seem to stem from the agpgart
module: since at least 2.4.9 (after the VM change, IIRC) the kernel
has shown fundamental instability on this machine.

The problem has somewhat diminished during kernel evolution, from fast
death to slow death (i.e., with this kernel in particular, kernel
oopses are rare, compared to previous kernels, which were most
efficient in producing oopses).

Without agpgart module, kernel seems stable.  A naive (totally naive,
I admit it) interpretation suggests a problem in setting the AGP aperture.

Good work to all,
Alessandro Morelli
AlphaC srl

P.S.: Feel free to contact me anytime

Re: PROBLEM: memory corruption with i815 chipset variant

[Alan Cox]

> 8. Graphic card has 16MB of memory: Region 0 is reported to be 128M
> (AFAIK, it could be correct).

Quite probably

> ASUS has used the i815 chipset without the CGC, using a Radeon
> Mobility M6 LY instead.  All problems seem to stem from the agpgart
> module: since at least 2.4.9 (after the VM change, IIRC) the kernel
> has shown fundamental instability on this machine.

That means its actually using the same GART code as the 440BX and friends
if I remember rightly (the i815 special stuff is for on board video)

> Without agpgart module, kernel seems stable.  A naive (totally naive,
> I admit it) interpretation suggests a problem in setting the AGP aperture.

Does the ram survive memtest86 overnight with no errors logged if you boot
memtest86 and just leave it ?

RE: PROBLEM: memory corruption with i815 chipset variant

[Alessandro Morelli]

 > Does the ram survive memtest86 overnight with no errors logged if you 
boot memtest86 and just leave it ?
Survived 2hrs (couldn't test it more right now: the laptop is my work 
machine [sigh]).

memtest with agpgart loaded (either static or module) started to report 
errors in MUL, DIV, XOR and others since the first run, never the same 
locations, never the same count. Without agpgart, it produced a joyously 
boring stream of Test nn...passed.

memtest86 loaded from the boot diskette did the same...

However I'll test it more: tonight (here in Italy, it's 15:00) I'll leave 
the thing running...

I need AGP...XFree won't talk to the Radeon without it...

Furthermore, I noted another small problem: first time I tried 
2.4.19-pre8-ac5 I compiled the DRM statically along with agp, later I made 
both of them modules and depmod starts complaining about vmalloc_to_page 
not being defined...

Anyone has experienced same problems with other PCs?

Good work to all,
Alessandro Morelli
AlphaC srl

P.S.: Mr. Cox, I'm impressed: you must be a very busy person and yet you 
answered an out-of-nowhere email in no time flat...Many thanks!

Re: PROBLEM: memory corruption with i815 chipset variant

[Alessandro Morelli]

>Does the ram survive memtest86 overnight with no errors logged if you boot
>memtest86 and just leave it ?

It did survive for a whole night (7pm through 8am).

Insmoding agpgart makes it fail after 35 seconds.

Sigh.

Good work to all,
Alex

RE: PROBLEM: memory corruption with i815 chipset variant

[Steve Kieu]

Hi,

I think it might be related to the OOPS I reported .
With 2.4.19-preX where X=8  with ac or not, with aa,
what ever... my machine oop after exiting X. See the
trace log some one told me to run memtest but it is
all OK,  the culprit is in drm unlocking page
somewhere, 

 My box is i810 chipset. Now I only can use
2.4.19-pre2 :-)
If I do not use dri , oop did not happen.

Regard,


=====
Steve Kieu

http://briefcase.yahoo.com.au - Yahoo! Briefcase
- Save your important files online for easy access!

Re: PROBLEM: memory corruption with i815 chipset variant

[Nicolas Aspert]

Alan Cox wrote:

> 
> That means its actually using the same GART code as the 440BX and friends
> if I remember rightly (the i815 special stuff is for on board video)


Alessandro reported the problem to me also. I went through the i815 
specs and found 2 'strange' things (maybe they are not but...)
1) No 'ERRSTS' register (well... a bus that does no error should be a 
feature ;-)
2) The ATTBASE register to which the *_configure functions write is 
different from other Intel chipsets. In the i815, the ATT base adress 
should be written between bits 12 and 28, whereas in all other Intel 
chipsets, it should be written between bits 12 and 31 (don't ask me why 
Intel feels like changing the adresses/specs for registers at each new 
chipsets....) .
Alan, do you think this could cause all those troubles ?

> 
>>Without agpgart module, kernel seems stable.  A naive (totally naive,
>>I admit it) interpretation suggests a problem in setting the AGP aperture.
> 
> 
> Does the ram survive memtest86 overnight with no errors logged if you boot
> memtest86 and just leave it ?

 From what Alessandro reported, it seems clear that the 'insmod agpgart' 
triggers the mayhem, including memtest failures.

Best regards

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

Re: PROBLEM: memory corruption with i815 chipset variant

[Nicolas Aspert]

Alan Cox wrote:

> 
> It certainly could be. If bits 29-31 maybe control things like memory
> timings then it could do quite horrible things. Fixing it to leave the
> ERRSTS register alone and keep bits 29-31 is definitely worth trying. If
> that fixes it then its going to be easy enough to drop a fix into the
> mainstream code
> 

OK, I have a patch almost ready to do that except, I am not sure about 
what to do for those 3 bits...

The *usual* call is :
	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE,
			       agp_bridge.gatt_bus_addr);

Where 'gatt_bus_addr' is returned from a 'virt_to_phys' on 
'gatt_table_real'.

Should I mask those three bits out when writing or write
'gatt_bus_addr >> 3' instead ? I am not too sure about the assumptions 
that can be made about what returns 'virt_to_phys' ...

Thanks in advance.

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

[PATCH,CFT] Tentative fix for mem. corruption caused by intel 815 AGP

[Nicolas Aspert]

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

Hi all

Thanks Alan's advice, here is a patch that aims at fixing the mem. 
corruption problems encountered by some users, when trying to use 
agpgart with intel 815 chipsets.
The patch is against 2.4.19-pre8-ac5

Alessandro, could you please test whether this patch improves things or 
not ?

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


[-- Attachment #2: patch-intel_815-2.4.19-pre8-ac5 --]
[-- Type: text/plain, Size: 3768 bytes --]

Only in agp: Makefile
diff -u agp.orig/agp.h agp/agp.h
--- agp.orig/agp.h	Fri May 24 15:08:37 2002
+++ agp/agp.h	Mon May 27 11:26:55 2002
@@ -293,6 +293,10 @@
 /* This one is for I830MP w. an external graphic card */
 #define INTEL_I830_ERRSTS          0x92
 
+/* intel 815 register */
+#define INTEL_815_APCONT        0x51
+#define INTEL_815_ATTBASE_MASK  0x1FFFFFFF
+
 /* intel i820 registers */
 #define INTEL_I820_RDCR     0x51
 #define INTEL_I820_ERRSTS   0xc8
diff -u agp.orig/agpgart_be.c agp/agpgart_be.c
--- agp.orig/agpgart_be.c	Fri May 24 15:08:44 2002
+++ agp/agpgart_be.c	Mon May 27 11:28:07 2002
@@ -1490,6 +1490,42 @@
 	return 0;
 }
 
+static int intel_815_configure(void)
+{
+	u32 temp, addr;
+	u8 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 */
+        /* the Intel 815 chipset spec. says that bits 29-31 in the
+         * ATTBASE register are reserved -> try not to write them */
+        if (agp_bridge.gatt_bus_addr & (~ INTEL_815_ATTBASE_MASK))
+		panic("gatt bus addr too high");
+	addr = agp_bridge.gatt_bus_addr & INTEL_815_ATTBASE_MASK;
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, &addr);
+
+	/* agpctrl */
+	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000); 
+
+	/* apcont */
+	pci_read_config_byte(agp_bridge.dev, INTEL_I815_APCONT, &temp2);
+	pci_write_config_byte(agp_bridge.dev, INTEL_I815_APCONT,
+			      temp2 | (1 << 1));
+	/* clear any possible error conditions */
+        /* Oddness : this chipset seems to have no ERRSTS register ! */
+	return 0;
+}
+
 static void intel_820_tlbflush(agp_memory * mem)
 {
   return;
@@ -1724,6 +1760,12 @@
 	{0x00000017, 0}
 };
 
+static aper_size_info_8 intel_815_sizes[2] =
+{
+	{64, 16384, 4, 0},
+	{32, 8192, 3, 8},
+};
+
 static aper_size_info_8 intel_8xx_sizes[7] =
 {
 	{256, 65536, 6, 0},
@@ -1787,7 +1829,38 @@
 	(void) pdev; /* unused */
 }
 
+static int __init intel_815_setup (struct pci_dev *pdev)
+{
+	agp_bridge.masks = intel_generic_masks;
+	agp_bridge.num_of_masks = 1;
+	agp_bridge.aperture_sizes = (void *) intel_815_sizes;
+	agp_bridge.size_type = U8_APER_SIZE;
+	agp_bridge.num_aperture_sizes = 2;
+	agp_bridge.dev_private_data = NULL;
+	agp_bridge.needs_scratch_page = FALSE;
+	agp_bridge.configure = intel_815_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;
+	agp_bridge.suspend = agp_generic_suspend;
+	agp_bridge.resume = agp_generic_resume;
+	agp_bridge.cant_use_aperture = 0;
 
+	return 0;
+	
+	(void) pdev; /* unused */
+}
 
 static int __init intel_820_setup (struct pci_dev *pdev)
 {
@@ -3929,7 +4002,7 @@
 		INTEL_I815,
 		"Intel",
 		"i815",
-		intel_generic_setup },
+		intel_815_setup },
 	{ PCI_DEVICE_ID_INTEL_820_0,
 		PCI_VENDOR_ID_INTEL,
 		INTEL_I820,
Only in agp: agpgart_fe.c

Re: PROBLEM: memory corruption with i815 chipset variant

[Alan Cox]

On Mon, 2002-05-27 at 09:11, Nicolas Aspert wrote:
> Alessandro reported the problem to me also. I went through the i815 
> specs and found 2 'strange' things (maybe they are not but...)
> 1) No 'ERRSTS' register (well... a bus that does no error should be a 
> feature ;-)
> 2) The ATTBASE register to which the *_configure functions write is 
> different from other Intel chipsets. In the i815, the ATT base adress 
> should be written between bits 12 and 28, whereas in all other Intel 
> chipsets, it should be written between bits 12 and 31 (don't ask me why 
> Intel feels like changing the adresses/specs for registers at each new 
> chipsets....) .
> Alan, do you think this could cause all those troubles ?

It certainly could be. If bits 29-31 maybe control things like memory
timings then it could do quite horrible things. Fixing it to leave the
ERRSTS register alone and keep bits 29-31 is definitely worth trying. If
that fixes it then its going to be easy enough to drop a fix into the
mainstream code

Alan

Re: [PATCH,CFT] Tentative fix for mem. corruption caused by intel 815 AGP

[Nicolas Aspert]

Alan Cox wrote:
> On Mon, 2002-05-27 at 10:32, Nicolas Aspert wrote:
> p 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 */
>>+        /* the Intel 815 chipset spec. says that bits 29-31 in the
>>+         * ATTBASE register are reserved -> try not to write them */
>>+        if (agp_bridge.gatt_bus_addr & (~ INTEL_815_ATTBASE_MASK))
>>+		panic("gatt bus addr too high");
>>+	addr = agp_bridge.gatt_bus_addr & INTEL_815_ATTBASE_MASK;
> 
> 
> You need to add  + temp&~INTEL_815_ATTBASE_MASK ..
> 
> 

I am not sure to understand... Do you really mean mixing 'APBASE' which 
is the AGP base aperture adress along with the *gatt* which is the 
translation table adress ? If yes, I think I need a supplementary 
explanation...

Best regards.
-- 
Nicolas Aspert      Signal Processing Institute (ITS)
Swiss Federal Institute of Technology (EPFL)

Re: PROBLEM: memory corruption with i815 chipset variant

[Alan Cox]

On Mon, 2002-05-27 at 09:56, Nicolas Aspert wrote:
> OK, I have a patch almost ready to do that except, I am not sure about 
> what to do for those 3 bits...
> 
> The *usual* call is :
> 	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE,
> 			       agp_bridge.gatt_bus_addr);
> 
> Where 'gatt_bus_addr' is returned from a 'virt_to_phys' on 
> 'gatt_table_real'.
> 
> Should I mask those three bits out when writing or write
> 'gatt_bus_addr >> 3' instead ? I am not too sure about the assumptions 
> that can be made about what returns 'virt_to_phys' ...

virt_to_phys returns you the CPU physical (after the MMU) address of the
memory in question. You'd want to check the documentation but assuming
the base is still written as an address in bytes then you'd want to do 
something like

	if(agp_bridge.gatt_bus_addr & ~0x1FFFFFFF)
		panic("gatt bus addr too high");
	pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &addr);
	addr&=~0x1FFFFFFF;
	addr|=agp_bridge.gatt_bus_addr;
	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, &addr);

Re: [PATCH,CFT] Tentative fix for mem. corruption caused by intel 815 AGP

[Alan Cox]

On Mon, 2002-05-27 at 10:32, Nicolas Aspert wrote:
p 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 */
> +        /* the Intel 815 chipset spec. says that bits 29-31 in the
> +         * ATTBASE register are reserved -> try not to write them */
> +        if (agp_bridge.gatt_bus_addr & (~ INTEL_815_ATTBASE_MASK))
> +		panic("gatt bus addr too high");
> +	addr = agp_bridge.gatt_bus_addr & INTEL_815_ATTBASE_MASK;

You need to add  + temp&~INTEL_815_ATTBASE_MASK ..

Re: [PATCH,CFT] Tentative fix for mem. corruption caused by intel 815 AGP

[Nicolas Aspert]

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

Alan Cox wrote:

> Your code isnt reading the top bits from the register and anding them
> back into it with the address.
> 
> 

OK I got it now... I was confused by the 'temp' thing but I should have 
read more carefully your initial suggestion (doing 2 things at the same 
time seems beyond my possibilities today ;-)
Anyway, here is take 2 of the patch, hopefully correct this time...

Just another quick thought... in all intel chipsets datasheets, the bits 
0-11 of the ATTBASE register are also marked as 'reserved'. So far, all 
the intel_*_configure routines are writing shamelessly on these bits. 
Shouldn't we mask those bits out too (though it seems this has not 
caused any trouble so far) ?

Best regards

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

[-- Attachment #2: patch-intel_815-2.4.19-pre8-ac5 --]
[-- Type: text/plain, Size: 3791 bytes --]

diff -u agp.orig/agp.h agp/agp.h
--- agp.orig/agp.h	Fri May 24 15:08:37 2002
+++ agp/agp.h	Mon May 27 13:00:27 2002
@@ -293,6 +293,10 @@
 /* This one is for I830MP w. an external graphic card */
 #define INTEL_I830_ERRSTS          0x92
 
+/* intel 815 register */
+#define INTEL_815_APCONT        0x51
+#define INTEL_815_ATTBASE_MASK  ~0x1FFFFFFF
+
 /* intel i820 registers */
 #define INTEL_I820_RDCR     0x51
 #define INTEL_I820_ERRSTS   0xc8
diff -u agp.orig/agpgart_be.c agp/agpgart_be.c
--- agp.orig/agpgart_be.c	Fri May 24 15:08:44 2002
+++ agp/agpgart_be.c	Mon May 27 13:00:10 2002
@@ -1490,6 +1490,44 @@
 	return 0;
 }
 
+static int intel_815_configure(void)
+{
+	u32 temp, addr;
+	u8 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 */
+        /* the Intel 815 chipset spec. says that bits 29-31 in the
+         * ATTBASE register are reserved -> try not to write them */
+        if (agp_bridge.gatt_bus_addr &  INTEL_815_ATTBASE_MASK)
+		panic("gatt bus addr too high");
+	pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &addr);
+	addr &= INTEL_815_ATTBASE_MASK;
+	addr |= agp_bridge.gatt_bus_addr;
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, &addr);
+
+	/* agpctrl */
+	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000); 
+
+	/* apcont */
+	pci_read_config_byte(agp_bridge.dev, INTEL_I815_APCONT, &temp2);
+	pci_write_config_byte(agp_bridge.dev, INTEL_I815_APCONT,
+			      temp2 | (1 << 1));
+	/* clear any possible error conditions */
+        /* Oddness : this chipset seems to have no ERRSTS register ! */
+	return 0;
+}
+
 static void intel_820_tlbflush(agp_memory * mem)
 {
   return;
@@ -1724,6 +1762,12 @@
 	{0x00000017, 0}
 };
 
+static aper_size_info_8 intel_815_sizes[2] =
+{
+	{64, 16384, 4, 0},
+	{32, 8192, 3, 8},
+};
+
 static aper_size_info_8 intel_8xx_sizes[7] =
 {
 	{256, 65536, 6, 0},
@@ -1787,7 +1831,38 @@
 	(void) pdev; /* unused */
 }
 
+static int __init intel_815_setup (struct pci_dev *pdev)
+{
+	agp_bridge.masks = intel_generic_masks;
+	agp_bridge.num_of_masks = 1;
+	agp_bridge.aperture_sizes = (void *) intel_815_sizes;
+	agp_bridge.size_type = U8_APER_SIZE;
+	agp_bridge.num_aperture_sizes = 2;
+	agp_bridge.dev_private_data = NULL;
+	agp_bridge.needs_scratch_page = FALSE;
+	agp_bridge.configure = intel_815_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;
+	agp_bridge.suspend = agp_generic_suspend;
+	agp_bridge.resume = agp_generic_resume;
+	agp_bridge.cant_use_aperture = 0;
 
+	return 0;
+	
+	(void) pdev; /* unused */
+}
 
 static int __init intel_820_setup (struct pci_dev *pdev)
 {
@@ -3929,7 +4004,7 @@
 		INTEL_I815,
 		"Intel",
 		"i815",
-		intel_generic_setup },
+		intel_815_setup },
 	{ PCI_DEVICE_ID_INTEL_820_0,
 		PCI_VENDOR_ID_INTEL,
 		INTEL_I820,

[PATCH,CFT] Tentative fix for agpgart (writing on 'reserved' bits)

[Nicolas Aspert]

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

Alan Cox wrote:
> 
> We ought to mask and copy the original yes. The number of times we've
> had Linux driver breakages by not masking and avoiding writes to
> reserved bits is small but it does happen occasionally.

That sounds reasonable. I attached a patch that should do this. 
According to what was done before (i.e. writing on the reserved bits), 
the 12 LSB of ATTBASE should be discarded...
The patch is against 2.4.19-pre8-ac5

Please test

Best regards

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

[-- Attachment #2: patch-agp_fix_attbase-2.4.19-pre8-ac5 --]
[-- Type: text/plain, Size: 8592 bytes --]

diff -u agp.orig/agp.h agp/agp.h
--- agp.orig/agp.h	Fri May 24 15:08:37 2002
+++ agp/agp.h	Mon May 27 16:06:09 2002
@@ -274,6 +274,9 @@
 #define INTEL_NBXCFG    0x50
 #define INTEL_ERRSTS    0x91
 
+/* mask to preserve the 12 LSB of the ATTBASE register */
+#define INTEL_ATTBASE_MASK 0x00000FFF
+
 /* intel i830 registers */
 #define I830_GMCH_CTRL             0x52
 #define I830_GMCH_ENABLED          0x4
@@ -293,6 +296,10 @@
 /* This one is for I830MP w. an external graphic card */
 #define INTEL_I830_ERRSTS          0x92
 
+/* intel 815 register */
+#define INTEL_815_APCONT        0x51
+#define INTEL_815_ATTBASE_MASK  0xE0000FFF
+
 /* intel i820 registers */
 #define INTEL_I820_RDCR     0x51
 #define INTEL_I820_ERRSTS   0xc8
diff -u agp.orig/agpgart_be.c agp/agpgart_be.c
--- agp.orig/agpgart_be.c	Fri May 24 15:08:44 2002
+++ agp/agpgart_be.c	Mon May 27 16:04:05 2002
@@ -1475,8 +1475,10 @@
 	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);
+	pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp);
+        temp &= INTEL_ATTBASE_MASK;
+        temp |= agp_bridge.gatt_bus_addr & (~ INTEL_ATTBASE_MASK);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
 
 	/* agpctrl */
 	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x2280);
@@ -1490,6 +1492,46 @@
 	return 0;
 }
 
+static int intel_815_configure(void)
+{
+	u32 temp;
+	u8 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 */
+        /* the Intel 815 chipset spec. says that bits 29-31 in the
+         * ATTBASE register are reserved -> try not to write them */
+        if ((agp_bridge.gatt_bus_addr & INTEL_815_ATTBASE_MASK) & 
+            ~ INTEL_ATTBASE_MASK)
+          panic("gatt bus addr too high");
+	pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp);
+	temp &= INTEL_815_ATTBASE_MASK;
+	temp |= agp_bridge.gatt_bus_addr & (~ INTEL_815_ATTBASE_MASK);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
+
+	/* agpctrl */
+	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000); 
+
+	/* apcont */
+	pci_read_config_byte(agp_bridge.dev, INTEL_I815_APCONT, &temp2);
+	pci_write_config_byte(agp_bridge.dev, INTEL_I815_APCONT,
+			      temp2 | (1 << 1));
+
+	/* clear any possible error conditions */
+        /* Oddness : this chipset seems to have no ERRSTS register ! */
+	return 0;
+}
+
 static void intel_820_tlbflush(agp_memory * mem)
 {
   return;
@@ -1526,8 +1568,10 @@
 	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); 
+	pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp); 
+        temp &= INTEL_ATTBASE_MASK;
+        temp |= agp_bridge.gatt_bus_addr & (~ INTEL_ATTBASE_MASK);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
 
 	/* agpctrl */
 	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000); 
@@ -1560,8 +1604,10 @@
        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);
+       pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp);
+       temp &= INTEL_ATTBASE_MASK;
+       temp |= agp_bridge.gatt_bus_addr & (~ INTEL_ATTBASE_MASK);
+       pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
 
        /* agpctrl */
        pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000);
@@ -1570,6 +1616,7 @@
        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;
@@ -1594,8 +1641,10 @@
 	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); 
+	pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp); 
+        temp &= INTEL_ATTBASE_MASK;
+        temp |= agp_bridge.gatt_bus_addr & (~ INTEL_ATTBASE_MASK);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
 
 	/* agpctrl */
 	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000); 
@@ -1604,6 +1653,7 @@
 	pci_read_config_word(agp_bridge.dev, INTEL_I840_MCHCFG, &temp2);
 	pci_write_config_word(agp_bridge.dev, INTEL_I840_MCHCFG,
 			      temp2 | (1 << 9));
+
 	/* clear any possible error conditions */
 	pci_write_config_word(agp_bridge.dev, INTEL_I840_ERRSTS, 0xc000); 
 	return 0;
@@ -1626,8 +1676,10 @@
 	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); 
+	pci_read_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp); 
+        temp &= INTEL_ATTBASE_MASK;
+        temp |= agp_bridge.gatt_bus_addr & (~ INTEL_ATTBASE_MASK);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
 
 	/* agpctrl */
 	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000); 
@@ -1658,8 +1710,10 @@
 	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); 
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp); 
+        temp &= INTEL_ATTBASE_MASK;
+        temp |= agp_bridge.gatt_bus_addr & (~ INTEL_ATTBASE_MASK);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
 
 	/* agpctrl */
 	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000); 
@@ -1690,8 +1744,10 @@
 	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);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, &temp);
+        temp &= INTEL_ATTBASE_MASK;
+        temp |= agp_bridge.gatt_bus_addr & (~ INTEL_ATTBASE_MASK);
+	pci_write_config_dword(agp_bridge.dev, INTEL_ATTBASE, temp);
 
 	/* agpctrl */
 	pci_write_config_dword(agp_bridge.dev, INTEL_AGPCTRL, 0x0000);
@@ -1724,6 +1780,12 @@
 	{0x00000017, 0}
 };
 
+static aper_size_info_8 intel_815_sizes[2] =
+{
+	{64, 16384, 4, 0},
+	{32, 8192, 3, 8},
+};
+
 static aper_size_info_8 intel_8xx_sizes[7] =
 {
 	{256, 65536, 6, 0},
@@ -1787,7 +1849,38 @@
 	(void) pdev; /* unused */
 }
 
+static int __init intel_815_setup (struct pci_dev *pdev)
+{
+	agp_bridge.masks = intel_generic_masks;
+	agp_bridge.num_of_masks = 1;
+	agp_bridge.aperture_sizes = (void *) intel_815_sizes;
+	agp_bridge.size_type = U8_APER_SIZE;
+	agp_bridge.num_aperture_sizes = 2;
+	agp_bridge.dev_private_data = NULL;
+	agp_bridge.needs_scratch_page = FALSE;
+	agp_bridge.configure = intel_815_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;
+	agp_bridge.suspend = agp_generic_suspend;
+	agp_bridge.resume = agp_generic_resume;
+	agp_bridge.cant_use_aperture = 0;
 
+	return 0;
+	
+	(void) pdev; /* unused */
+}
 
 static int __init intel_820_setup (struct pci_dev *pdev)
 {
@@ -3929,7 +4022,7 @@
 		INTEL_I815,
 		"Intel",
 		"i815",
-		intel_generic_setup },
+		intel_815_setup },
 	{ PCI_DEVICE_ID_INTEL_820_0,
 		PCI_VENDOR_ID_INTEL,
 		INTEL_I820,

Re: [PATCH,CFT] Tentative fix for mem. corruption caused by intel 815 AGP

[Alan Cox]

On Mon, 2002-05-27 at 12:11, Nicolas Aspert wrote:
> Just another quick thought... in all intel chipsets datasheets, the bits 
> 0-11 of the ATTBASE register are also marked as 'reserved'. So far, all 
> the intel_*_configure routines are writing shamelessly on these bits. 
> Shouldn't we mask those bits out too (though it seems this has not 
> caused any trouble so far) ?

We ought to mask and copy the original yes. The number of times we've
had Linux driver breakages by not masking and avoiding writes to
reserved bits is small but it does happen occasionally.

Alan

Re: [PATCH,CFT] Tentative fix for agpgart (writing on 'reserved' bits)

[Nicolas Aspert]

Alessandro Morelli wrote:

> 
> Hello
> I managed to get rid of customers, in order to test the patches....
> Bad news...no change...

At least it is not worse (I hope ...) ;-)


> I'm starting to believe I'm mad...my PC works like charm without AGP and 
> gets all mixed when I enabled it...

Does it start messing right after you enable it, or only after you write 
to it (starting X...) ?

> What kind of information can I provide (/proc readings, tests, etc.) to 
> shed some light?
 >
> Could this be a case of interaction between AGP and VM?
> 
> tlb-flush weirdness?
> 

Apart from this kinda usual write-on-reserved-bits in the AGP 
initialization, which has been done before on various chipsets and 
almost never caused any trouble, I saw no blatant errors that may lead 
to such things... In fact, we have several PCs with i815 chipsets in the 
lab. People are using AGP without any troubles. The only difference is 
that we run an old kernel version (2.4.3-13, thanks the sysadmin for 
never upgrading....), and we have a different graphic card (Matrox).

Alan, do you have any idea about this one ?

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