1.0-7667 for Linux x86 released

[davemoore]

lyceel, according to the log you posted, you have problems with "Cache Aliasing". Look in your /var/log/messages file and observe all the error messages. The log advises you to read the section of the README file concerning "Cache Aliasing".

In short: the kernel you are using from RHEL is probably buggy. Update to the latest version if one is available. If not, you may have to compile your own kernel or use a different Linux distribution.

[lyceel]

Originally Posted by davemoore

lyceel, according to the log you posted, you have problems with "Cache Aliasing". Look in your /var/log/messages file and observe all the error messages. The log advises you to read the section of the README file concerning "Cache Aliasing".

In short: the kernel you are using from RHEL is probably buggy. Update to the latest version if one is available. If not, you may have to compile your own kernel or use a different Linux distribution.

Thanks, I just noticed that myself. I don't think this was showing up with earlier drivers. We'll look into it.

[lyceel]

Well, I downloaded and compiled kernel 2.6.12.1 and I'm not seeing much improvement. Still get lock-ups within 5 minutes or so while running an OpenGL app (glxgears in this case).

Here's a new bug report. Note that the only relevant messages are after about 16:30 on June 23. Everything before that was running with kernel 2.6.9-11.ELsmp. Also note that there was a lock-up between the last two NVRM messages in the report. That is, nothing out of the ordinary was logged before the last lock-up.

I haven't gotten any cache aliasing errors since updating the kernel, so there must be something going on besides cache aliasing.

[davemoore]

Yeah, looks like you solved the cached aliasing problem only to get bitten by something else. In some other threads, various people had success upgrading their Video BIOS in order to solve the Xid crashes. The manufacturers don't usually provide upgrades, but you can usually find a newer BIOS for your card at http://www.mvktech.net/

There was also discussion in other threads that instability was caused by a mismatch between 2d and 3d clock rates (as specified by the video BIOS). You might try enabling the "coolbits" option as described in the README, and tweaking these clocks by hand.

Another interesting test would be to try the cards in Windows. Usually, when a BIOS or clock mismatch is to blame, the instability will be present in Windows as well.

Good luck.

[kcrudup]

Originally Posted by metamatics

I want fixes for crashes, not for "problem with certain flatpanels running at 1600x1200."

Heh. YOU say that 'cause you don't have a 1600x1200 flatpanel like I do!

I hope that fix was the VT-switching bug in 7664 that made me have to revert back to (edit) 7174. Trying it now ....

[lyceel]

Originally Posted by davemoore

Yeah, looks like you solved the cached aliasing problem only to get bitten by something else. In some other threads, various people had success upgrading their Video BIOS in order to solve the Xid crashes. The manufacturers don't usually provide upgrades, but you can usually find a newer BIOS for your card at http://www.mvktech.net/

There was also discussion in other threads that instability was caused by a mismatch between 2d and 3d clock rates (as specified by the video BIOS). You might try enabling the "coolbits" option as described in the README, and tweaking these clocks by hand.

Updated Video BIOS, no luck, though judging by the numbers, it wasn't much of an update (05.43.02.16.51 to 05.43.02.16.52).

Adjusted the 3D clock down to 300MHz to match the 2d clock. Also slowed the memory down to 600MHz. No luck there either.

Mobo bios upgrade didn't work, kernel upgrade didn't work, disabling 2nd processor and hyperthreading and running a non-smp kernel didn't work, kneeling and praying really hard didn't work.

NVIDIA, we're at your mercy.

BTW, here's the latest bug report log. Again, the syslog entries before 16:30 on Jun 23 are with kernel 2.6.9-11.ELsmp. After that, they're with kernel 2.6.12.1 (also smp).

[kcrudup]

Originally Posted by kcrudup

I hope that fix was the VT-switching bug in 7664

It was! Thanks, NVidia!

[arokh]

Originally Posted by lyceel

I haven't gotten any cache aliasing errors since updating the kernel, so there must be something going on besides cache aliasing.

Have you tried one of the 6600GT's on a different system running the same software? Could it be heat issues? PSU issue? Weird chipset? BIOS settings? Just throwing some wild guesses here, but don't be too quick to judge the nvidia drivers, they are pretty solid from my experience.

One other thing you could try, set CONFIG_REGPARM=n in your kernel config. I've had problems with that in the past, it can certainly cause similar problems to what you are seeing.

[kcrudup]

Originally Posted by kcrudup

It was! Thanks, NVidia!

... and soon afterwards, switching VTs results in garbage on the screen. Ah well, back to 7174!

"Two steps forward, one step back" again.

[lyceel]

Originally Posted by arokh

Have you tried one of the 6600GT's on a different system running the same software? Could it be heat issues? PSU issue? Weird chipset? BIOS settings? Just throwing some wild guesses here, but don't be too quick to judge the nvidia drivers, they are pretty solid from my experience.

I think it was mentioned before that we have a lab full of nearly identical machines that all have the same problem. I don't think Dell is in the habit of using weird chipsets. The PSU is capable of handling high-end Quadro and FireGL cards, I don't think a little 6600GT should be a problem. The BIOS settings on Dell Precisions don't allow a lot of adjustment. I did update the BIOS yesterday (as well as the video BIOS on the card), no change.

It's not like we have systems that we built ourselves full of odd combinations of components. These are Dell Precision 670's. We're certainly not rushing to judgement here. We've tried a lot of things before blaming the drivers.

Originally Posted by arokh

One other thing you could try, set CONFIG_REGPARM=n in your kernel config. I've had problems with that in the past, it can certainly cause similar problems to what you are seeing.

Trying it now...

[kcrudup]

Originally Posted by kcrudup

... switching VTs [still] results in garbage on the screen.

I hope this helps the NVidia developers:

I use "Software Suspend 2" (swsusp.sf.net; pointer to the real site whose name I don't recall). Anyway, since approx. 6629, we've had to add the following to .../usr/src/nv/nv.c to get it to work with swsusp2:

--- nv.c.orig   Mon Jun 20 14:03:54 2005
+++ nv.c        Mon Jun 20 14:03:54 2005
@@ -3424,6 +3424,8 @@
 
     switch (state)
     {
+        case PM_SUSPEND_STANDBY:
+           nv_printf(NV_DBG_INFO, "NVRM: ACPI: recieved PM_SUSPEND_STANDBY\n");
         case PM_SUSPEND_MEM:
             nv_printf(NV_DBG_INFO, "NVRM: ACPI: received suspend event\n");
             status = rm_power_management(nv, 0, NV_PM_ACPI_STANDBY);

... as I guess swsusp2 emits "PM_SUSPEND_STANDBY". 6629 and 7174 work perfectly with swsusp2, and are rock solid (kernels 2.6.9-2.6.11.12 for me).

However, with 7664 and 7667, after a resume the screen will become corrupted if you switch from the X VT to any text VT. Switching back to the X VT restores the X screen OK. The effect is if it never returns back to a "text" mode; it stays in a graphical mode and you can see a corrupted version of my X background on the screen. (This is, of course, with the above patch applied. Leaving the patch out means I can't resume- I get a black screen that I have to "SysRq-S/N/B" to restart my system to get out of; perhaps that patch should go into future NVidia driver releases?)

Dell Inspiron 8200, NV11 [GeForce2 Go] (rev 178), 32MB video memory, 1600x1200x32bpp LCD, XFree86 4.4

[Stephen-I-am]

Just a note to say thanks for this release. I just purchased a 1600x1200 flat panel that wasn't working with my 5600FX, but it works now!

Stephen