* RE: PROBLEM: memory corruption with i815 chipset variant
@ 2002-05-24 23:15 Steve Kieu
0 siblings, 0 replies; 9+ messages in thread
From: Steve Kieu @ 2002-05-24 23:15 UTC (permalink / raw)
To: kernel
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!
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PROBLEM: memory corruption with i815 chipset variant
2002-05-27 8:56 ` Nicolas Aspert
@ 2002-05-27 10:17 ` Alan Cox
0 siblings, 0 replies; 9+ messages in thread
From: Alan Cox @ 2002-05-27 10:17 UTC (permalink / raw)
To: Nicolas Aspert; +Cc: Alessandro Morelli, linux-kernel
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);
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PROBLEM: memory corruption with i815 chipset variant
2002-05-27 8:11 ` Nicolas Aspert
@ 2002-05-27 9:51 ` Alan Cox
2002-05-27 8:56 ` Nicolas Aspert
0 siblings, 1 reply; 9+ messages in thread
From: Alan Cox @ 2002-05-27 9:51 UTC (permalink / raw)
To: Nicolas Aspert; +Cc: Alessandro Morelli, linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PROBLEM: memory corruption with i815 chipset variant
2002-05-27 9:51 ` Alan Cox
@ 2002-05-27 8:56 ` Nicolas Aspert
2002-05-27 10:17 ` Alan Cox
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Aspert @ 2002-05-27 8:56 UTC (permalink / raw)
To: Alan Cox; +Cc: Alessandro Morelli, linux-kernel
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PROBLEM: memory corruption with i815 chipset variant
[not found] ` <fa.gciunnv.cnaf99@ifi.uio.no>
@ 2002-05-27 8:11 ` Nicolas Aspert
2002-05-27 9:51 ` Alan Cox
0 siblings, 1 reply; 9+ messages in thread
From: Nicolas Aspert @ 2002-05-27 8:11 UTC (permalink / raw)
To: Alan Cox; +Cc: Alessandro Morelli, linux-kernel
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)
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PROBLEM: memory corruption with i815 chipset variant
2002-05-21 12:54 ` Alan Cox
@ 2002-05-22 8:47 ` Alessandro Morelli
0 siblings, 0 replies; 9+ messages in thread
From: Alessandro Morelli @ 2002-05-22 8:47 UTC (permalink / raw)
To: linux-kernel
>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
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: PROBLEM: memory corruption with i815 chipset variant
@ 2002-05-21 13:00 Alessandro Morelli
0 siblings, 0 replies; 9+ messages in thread
From: Alessandro Morelli @ 2002-05-21 13:00 UTC (permalink / raw)
To: linux-kernel
> 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!
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: PROBLEM: memory corruption with i815 chipset variant
2002-05-21 11:44 Alessandro Morelli
@ 2002-05-21 12:54 ` Alan Cox
2002-05-22 8:47 ` Alessandro Morelli
0 siblings, 1 reply; 9+ messages in thread
From: Alan Cox @ 2002-05-21 12:54 UTC (permalink / raw)
To: Alessandro Morelli; +Cc: linux-kernel
> 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 ?
^ permalink raw reply [flat|nested] 9+ messages in thread
* PROBLEM: memory corruption with i815 chipset variant
@ 2002-05-21 11:44 Alessandro Morelli
2002-05-21 12:54 ` Alan Cox
0 siblings, 1 reply; 9+ messages in thread
From: Alessandro Morelli @ 2002-05-21 11:44 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2002-05-27 9:14 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-05-24 23:15 PROBLEM: memory corruption with i815 chipset variant Steve Kieu
[not found] <fa.mm4ng1v.vmenaj@ifi.uio.no>
[not found] ` <fa.gciunnv.cnaf99@ifi.uio.no>
2002-05-27 8:11 ` Nicolas Aspert
2002-05-27 9:51 ` Alan Cox
2002-05-27 8:56 ` Nicolas Aspert
2002-05-27 10:17 ` Alan Cox
-- strict thread matches above, loose matches on Subject: below --
2002-05-21 13:00 Alessandro Morelli
2002-05-21 11:44 Alessandro Morelli
2002-05-21 12:54 ` Alan Cox
2002-05-22 8:47 ` Alessandro Morelli
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®