2002-01-17 18:09:31

by Nick Martens

[permalink] [raw]
Subject: hangs using opengl

Hi,
I'm having some trouble with my box, at the time that i start an opengl
game in X sometimes the load of my machine gets really high (not in all
games Quake III runs just fine). when i try to move my mouse it won't
move, when i press CTRL-ALT-BACKSPACE nothing happens and I have to
reset my system. Is this kernel related or just an opengl problen ? if
it's kernel related I am running kernel 2.4.5 And my video-card is an
NVIDIA geforce 2 pro 450 from gainward. before this card i had a diamond
viper 770 ultra and the same problem occured. If this is not a kernel
issue: where can i go to solve this ????

Greets Nick



2002-01-17 19:06:03

by Nix N. Nix

[permalink] [raw]
Subject: Re: hangs using opengl

On Thu, 2002-01-17 at 13:37, Nix N. Nix wrote:
> On Thu, 2002-01-17 at 13:07, Nick Martens wrote:
> > Hi,
> > I'm having some trouble with my box, at the time that i start an opengl
> > game in X sometimes the load of my machine gets really high (not in all
> > games Quake III runs just fine). when i try to move my mouse it won't
> > move, when i press CTRL-ALT-BACKSPACE nothing happens and I have to
> > reset my system. Is this kernel related or just an opengl problen ? if
> > it's kernel related I am running kernel 2.4.5 And my video-card is an
> > NVIDIA geforce 2 pro 450 from gainward. before this card i had a diamond
> > viper 770 ultra and the same problem occured. If this is not a kernel
> > issue: where can i go to solve this ????
>
> First off, please forgive any non-compliance with linux-kernel posting
> protocol in the posting about to follow.
>
> Via has recently released a patch to Via-chipset based boards that
> addresses issues Windows XP users have been experiencing (BSODs and
> friends) while playing OpenGL games, especially with NVidia chips. The
> problem and the description of the fix (as taken from the Readme.txt
> from Via's patch) are as follow:
>
> "
> So what does it do? It closes the RX55 memory register in BIOS. The RX55
> register's official name and function is Memory Write Queue (MWQ) timer.
> The MWQ timer is actually a timing device included in the memory host
> controller to prevent write data being held in the memory queue too
> long. After the data has been in the queue too long it times out. This
> timed out data is then given a higher write request priority. Now that
> might sound nice a bit of extra performance BUT the procedure fails when
> overloaded. 3D games and Win XP put too much load on the memory queuing
> timer procedure. The nVidia new driver exaggerates the problem even more
> as the driver enables nVidia cards to use even more memory than previous
> driver versions.
>
> So in a nutshell it?s a memory timing problem that only happens when the
> RX55 register is opened. Some motherboard manufacturers have already
> released new BIOS that have the register closed. In other instances,
> this patch is needed.
> "
>
> I have an AMD Athlon 1200 CPU on an Asus board running the VIA KT266A
> North Bridge System Chipset and the VIA VT8233 South Bridge System
> Chipset. My video card is an NVidia GeForce2MX with the drivers from
> NVidia in place and working (OpenGL /is/ accelerated).
>
> I have experienced the same problem as Nick in that, whenever I run an
> OpenGL screensaver or Unreal Tournament, the computer will freeze at
> some unpredictable time (usually when I'm leading the game ;o) ). If I
> ssh in and kill the X server, it freezes completely and has to be
> rebooted via Reset button.
>
> In light of VIAs discoveries, and the fact that the patch that they now
> have available for Windows is not available for Linux also, I was
> wondering if somebody on this list may be kind enough to help us with
> what may very well be the symptoms of the same problem, but on Linux.
> Could the code that accomplishes the above (turn off the RX55 register)
> be made into a patch that can be applied to the kernel, thus providing
> an equivalent patch for Linux systems ?
>
> Please keep in mind that VIA provides this patch strictly as a beta, and
> will most likely include it in their next release of the 4in1 drivers
> (which are available for Windows only - no Linux support "at this
> time"). They say that, after more testing, if this proves to be a fix,
> they will include it.
>
> For further info, please consult the followings:
> http://www.viaarena.com/?PageID=64
> http://www.theddrzone.com/news.asp?id=404
>
>
>
> Thanks.
> >
> > Greets Nick


2002-01-17 19:40:53

by Nick Martens

[permalink] [raw]
Subject: Re: hangs using opengl

Frank Dekervel wrote:

> op donderdag 17 januari 2002 18:09 , schreef Nick Martens in
> <[email protected]> :
>
>
>>Hi,
>>I'm having some trouble with my box, at the time that i start an opengl
>>game in X sometimes the load of my machine gets really high (not in all
>>games Quake III runs just fine). when i try to move my mouse it won't
>>move, when i press CTRL-ALT-BACKSPACE nothing happens and I have to
>>reset my system. Is this kernel related or just an opengl problen ? if
>>it's kernel related I am running kernel 2.4.5 And my video-card is an
>>NVIDIA geforce 2 pro 450 from gainward. before this card i had a diamond
>>viper 770 ultra and the same problem occured. If this is not a kernel
>>issue: where can i go to solve this ????
>>
>>Greets Nick
>>
>>

Ok thanx all Another thing when it crashes the hd load seems extremely
high. system config is Intel P3 1ghz, intel 815 chipset, kernel 2.4.5
,xf86 4.1, kde 2.2

i also checked my logs:
/var/log/debug contains:

Jan 17 20:15:09 nick kernel: CPU: Before vendor init, caps: 0387f9ff
00000000 00000000, vendor = 0
Jan 17 20:15:09 nick kernel: CPU: After vendor init, caps: 0387f9ff
00000000 00000000 00000000
Jan 17 20:15:09 nick kernel: CPU: After generic, caps: 0383f9ff
00000000 00000000 00000000
Jan 17 20:15:09 nick kernel: CPU: Common caps: 0383f9ff
00000000 00000000 00000000
Jan 17 20:15:23 nick kernel: agpgart: unsupported bridge
Jan 17 20:15:23 nick kernel: agpgart: no supported devices found.


2002-01-17 20:46:58

by Reid Hekman

[permalink] [raw]
Subject: Re: hangs using opengl

On Thu, 2002-01-17 at 13:38, Nick Martens wrote:
>
> Ok thanx all Another thing when it crashes the hd load seems extremely
> high. system config is Intel P3 1ghz, intel 815 chipset, kernel 2.4.5
> ,xf86 4.1, kde 2.2
...
> i also checked my logs:
> /var/log/debug contains:
...
> Jan 17 20:15:23 nick kernel: agpgart: unsupported bridge
> Jan 17 20:15:23 nick kernel: agpgart: no supported devices found.

You need a newer kernel for i815 agp support. There have been many
improvements since 2.4.5, but if it works otherwise and you're not
affected by the security issues, knock yourself out. If you don't go the
new kernel route, in your XF86Config:

Option "NvAgp" "1"

This forces Nvidia's internal AGP support.

In os-registry.c of the NVdriver module:

NVreg_EnableAGPSBA = 0;

was a requirement for stability on my system as well. As always, YMMV.

Good luck,
Reid

2002-01-17 21:39:50

by Nix N. Nix

[permalink] [raw]
Subject: Re: hangs using opengl

On Thu, 2002-01-17 at 18:26, Denis Vlasenko wrote:
> On 17 January 2002 17:03, Nix N. Nix wrote:
> > > Via has recently released a patch to Via-chipset based boards that
> > > addresses issues Windows XP users have been experiencing (BSODs and
> > > friends) while playing OpenGL games, especially with NVidia chips. The
> > > problem and the description of the fix (as taken from the Readme.txt
> > > from Via's patch) are as follow:
> > >
> > > So what does it do? It closes the RX55 memory register in BIOS. The RX55
> > > register's official name and function is Memory Write Queue (MWQ) timer.
> > > The MWQ timer is actually a timing device included in the memory host
> > > controller to prevent write data being held in the memory queue too
> > > long. After the data has been in the queue too long it times out. This
> > > timed out data is then given a higher write request priority. Now that
> > > might sound nice a bit of extra performance BUT the procedure fails when
> > > overloaded. 3D games and Win XP put too much load on the memory queuing
> > > timer procedure. The nVidia new driver exaggerates the problem even more
> > > as the driver enables nVidia cards to use even more memory than previous
> > > driver versions.
>
> [snip]
>
> > > In light of VIAs discoveries, and the fact that the patch that they now
> > > have available for Windows is not available for Linux also, I was
> > > wondering if somebody on this list may be kind enough to help us with
> > > what may very well be the symptoms of the same problem, but on Linux.
> > > Could the code that accomplishes the above (turn off the RX55 register)
> > > be made into a patch that can be applied to the kernel, thus providing
> > > an equivalent patch for Linux systems ?
>
> Athlon bug stomper is already in mainline. If latest kernel does not work for
> you, check that register (man lspci) and 0x95 also. Try to disable them (man

I did lspci -vv -xxx
Each entry is followed by a table of hex. Is it entries 0x55 and 0x95
in that table that you're referring to ? If so, well, they're both 0:

01:00.0 VGA compatible controller: nVidia Corporation NV11 (rev a1)
(prog-if 00 [VGA])
Subsystem: Asustek Computer, Inc.: Unknown device 4015
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: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 11
Region 0: Memory at ee000000 (32-bit, non-prefetchable)
[size=16M]
Region 1: Memory at f0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at efff0000 [disabled] [size=64K]
Capabilities: [60] 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-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
Command: RQ=31 SBA- AGP+ 64bit- FW- Rate=x2
00: de 10 10 01 07 00 b0 02 a1 00 00 03 00 f8 00 00
10: 00 00 00 ee 08 00 00 f0 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 15 40
30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 05 01
40: 43 10 15 40 02 00 20 00 17 00 00 1f 02 01 00 1f
50: 01 00 00 00 01 [00] 00 00 ce d6 23 00 0f 00 00 00
60: 01 44 02 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 [00] 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

> setpci). Report back - we may need to further improve stomper.
> --
> vda
>


2002-01-17 21:46:20

by Nix N. Nix

[permalink] [raw]
Subject: Re: hangs using opengl

On Thu, 2002-01-17 at 18:26, Denis Vlasenko wrote:
>
> Athlon bug stomper is already in mainline. If latest kernel does not work for
> you, check that register (man lspci) and 0x95 also. Try to disable them (man
> setpci). Report back - we may need to further improve stomper.

Uh-oh ! agpgart says I have an VIA Apollo Pro KT266 chipset, but
NVdriver says I have a VIA Apollo KT133 chipset. Is that OK ? Could
that be causing my problems ?



Thanks for all the help & info.

> --
> vda
>


2002-01-17 22:06:24

by Reid Hekman

[permalink] [raw]
Subject: Re: hangs using opengl

On Thu, 2002-01-17 at 15:31, J Sloan wrote:
> >Stability wise,
> >internal NvAGP worked better than agpgart on KX133 and 440BX.
> >
> OK - I am seeing no stability issues so
> I guess I don't have to worry about that
> bit -

Interesting, as I said before, YMMV. On this system (cheap Korean
mainboard), a previous BIOS rev completely hosed AGP altogether :-/.

>
> BTW I did notice some longish pauses
> during RtCW when using nv agp, so I
> am using the in-kernel agp....

Hmm, it's fine here. What chipset and video card are you using? I've
been looking at Athlon boards and I'm curious about issues showing up in
AGP, IDE, PCI among the various platforms -- specifically AMD and Via
(maybe SiS too).

I've heard some (dis?)information that AMD agpgart lacks errata
workarounds? SiS lacks support for more than ATA66? Are there still
problems with Via timers or PCI?

Just curious,
Reid

2002-01-18 00:18:52

by Alan

[permalink] [raw]
Subject: Re: hangs using opengl

> Ok thanx all Another thing when it crashes the hd load seems extremely
> high. system config is Intel P3 1ghz, intel 815 chipset, kernel 2.4.5
> ,xf86 4.1, kde 2.2

How old is your 815 chipset ? I had problems with high load crashes on
three 815 based boards all of which were the same (MX3S) and all of which
went back.

Intel has errata on the 815 where the SDRAM voltage drive is apparently
wrong and board level corrections to cope. I've never been able to find
out if the board had these.

> Jan 17 20:15:23 nick kernel: agpgart: unsupported bridge
> Jan 17 20:15:23 nick kernel: agpgart: no supported devices found.

How old is your kernel - and do you have both the 440BX and i81x AGP
included. The AGP on the i815 basically has two totally different worlds
1. The rather nice onboard 2D/3D (i810 alike)
2. When you plug in a video card (440 alike)

Alan

2002-01-19 19:15:19

by Nick Martens

[permalink] [raw]
Subject: Re: hangs using opengl

Nix N. Nix wrote:

> On Thu, 2002-01-17 at 18:26, Denis Vlasenko wrote:
>
>>On 17 January 2002 17:03, Nix N. Nix wrote:
>>
>>>>Via has recently released a patch to Via-chipset based boards that
>>>>addresses issues Windows XP users have been experiencing (BSODs and
>>>>friends) while playing OpenGL games, especially with NVidia chips. The
>>>>problem and the description of the fix (as taken from the Readme.txt
>>>>from Via's patch) are as follow:
>>>>
>>>>So what does it do? It closes the RX55 memory register in BIOS. The RX55
>>>>register's official name and function is Memory Write Queue (MWQ) timer.
>>>>The MWQ timer is actually a timing device included in the memory host
>>>>controller to prevent write data being held in the memory queue too
>>>>long. After the data has been in the queue too long it times out. This
>>>>timed out data is then given a higher write request priority. Now that
>>>>might sound nice a bit of extra performance BUT the procedure fails when
>>>>overloaded. 3D games and Win XP put too much load on the memory queuing
>>>>timer procedure. The nVidia new driver exaggerates the problem even more
>>>>as the driver enables nVidia cards to use even more memory than previous
>>>>driver versions.
>>>>
>>[snip]
>>
>>
>>>>In light of VIAs discoveries, and the fact that the patch that they now
>>>>have available for Windows is not available for Linux also, I was
>>>>wondering if somebody on this list may be kind enough to help us with
>>>>what may very well be the symptoms of the same problem, but on Linux.
>>>>Could the code that accomplishes the above (turn off the RX55 register)
>>>>be made into a patch that can be applied to the kernel, thus providing
>>>>an equivalent patch for Linux systems ?
>>>>
>>Athlon bug stomper is already in mainline. If latest kernel does not work for
>>you, check that register (man lspci) and 0x95 also. Try to disable them (man
>>
>
> I did lspci -vv -xxx
> Each entry is followed by a table of hex. Is it entries 0x55 and 0x95
> in that table that you're referring to ? If so, well, they're both 0:
>
> 01:00.0 VGA compatible controller: nVidia Corporation NV11 (rev a1)
> (prog-if 00 [VGA])
> Subsystem: Asustek Computer, Inc.: Unknown device 4015
> 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: 248 (1250ns min, 250ns max)
> Interrupt: pin A routed to IRQ 11
> Region 0: Memory at ee000000 (32-bit, non-prefetchable)
> [size=16M]
> Region 1: Memory at f0000000 (32-bit, prefetchable) [size=128M]
> Expansion ROM at efff0000 [disabled] [size=64K]
> Capabilities: [60] 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-
> Capabilities: [44] AGP version 2.0
> Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
> Command: RQ=31 SBA- AGP+ 64bit- FW- Rate=x2
> 00: de 10 10 01 07 00 b0 02 a1 00 00 03 00 f8 00 00
> 10: 00 00 00 ee 08 00 00 f0 00 00 00 00 00 00 00 00
> 20: 00 00 00 00 00 00 00 00 00 00 00 00 43 10 15 40
> 30: 00 00 00 00 60 00 00 00 00 00 00 00 0b 01 05 01
> 40: 43 10 15 40 02 00 20 00 17 00 00 1f 02 01 00 1f
> 50: 01 00 00 00 01 [00] 00 00 ce d6 23 00 0f 00 00 00
> 60: 01 44 02 00 00 00 00 00 00 00 00 00 00 00 00 00
> 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> 90: 00 00 00 00 00 [00] 00 00 00 00 00 00 00 00 00 00
> a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
> f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>
>
>>setpci). Report back - we may need to further improve stomper.
>>--
>>vda
>>


Mine sais:

01:00.0 VGA compatible controller: nVidia Corporation NV15 (Geforce2 GTS) (rev a
4) (prog-if 00 [VGA])
Subsystem: CardExpert Technology: Unknown device 012c
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Step
ping- SERR- FastB2B-
Status: Cap+ 66Mhz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
Latency: 248 (1250ns min, 250ns max)
Interrupt: pin A routed to IRQ 5
Region 0: Memory at e2000000 (32-bit, non-prefetchable) [size=16M]
Region 1: Memory at d0000000 (32-bit, prefetchable) [size=128M]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [60] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot
-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [44] AGP version 2.0
Status: RQ=31 SBA- 64bit- FW+ Rate=x1,x2
Command: RQ=31 SBA- AGP+ 64bit- FW- Rate=<none>
00: de 10 50 01 07 00 b0 02 a4 00 00 03 00 f8 00 00
10: 00 00 00 e2 08 00 00 d0 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 b0 10 2c 01
30: 00 00 00 00 60 00 00 00 00 00 00 00 05 01 05 01
40: b0 10 2c 01 02 00 20 00 17 00 00 1f 04 01 00 1f
50: 01 00 00 00 01 00 00 00 ce d6 23 00 0f 00 00 00
60: 01 44 01 00 00 00 00 00 00 00 00 00 00 00 00 00
70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
c0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
d0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
e0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
f0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

I am now going to test hat nvagp option,I can't download a new kernel from

here connection is far too slow





2002-01-19 19:36:05

by Nick Martens

[permalink] [raw]
Subject: Re: hangs using opengl

Alan Cox wrote:

>>Ok thanx all Another thing when it crashes the hd load seems extremely
>>high. system config is Intel P3 1ghz, intel 815 chipset, kernel 2.4.5
>>,xf86 4.1, kde 2.2
>>
>
> How old is your 815 chipset ? I had problems with high load crashes on
> three 815 based boards all of which were the same (MX3S) and all of which
> went back.
>
> Intel has errata on the 815 where the SDRAM voltage drive is apparently
> wrong and board level corrections to cope. I've never been able to find
> out if the board had these.
>
>
>>Jan 17 20:15:23 nick kernel: agpgart: unsupported bridge
>>Jan 17 20:15:23 nick kernel: agpgart: no supported devices found.
>>
>
> How old is your kernel - and do you have both the 440BX and i81x AGP
> included. The AGP on the i815 basically has two totally different worlds
> 1. The rather nice onboard 2D/3D (i810 alike)
> 2. When you plug in a video card (440 alike)
>
> Alan
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/

I have rebuilt my kernel a few days ago,and my board is about one year (?) old

one of the first series of the chaintech 6ojv boards