Created attachment 68979 [details]
NVIDIA RIVA TNT2 M64 and VIA Technologies Apollo MVP3 log files from Ubuntu 10.04.4 LTS 32-bit

Hi,

The archive file uploaded are collection of log files from Ubuntu 10.04.4 LTS 32-bit's ubuntu-bug.
Because I can upload only one file at a time, I decided to zip it into an archive file.
Because of the severe instability of the system, I was able to collect this only once.
It is very difficult to collect the system data with these two combinations.
If I don't use NVIDIA RIVA TNT2 M64, the system runs much better, although I do get a sudden mysterious freeze once in a while for some reason.

Regards,

fpgahardwareengineer

To be honest it sounds like your motherboard is dying, not an issue caused by nouveau

Nevertheless there are a few thing you can try

* Try the proprietary driver (aka the blob)? Do you have similar issue with it?
Note: Not too sure if your card is supported


Ubuntu 10.04 uses quite (almost 3 years) old kernel - 2.6.32
* Can you try a distro based on a newer kernel. The best choice would be a Fedora LiveCD

If you're still having those issues with nouveau and not with the blob

Issue 1. Take an image of the boot messages, during bootup if your system crashes and the logs are not retrieveable

Issue 2. Try and tiangulate what causes the freeze, specific program, suspend/resume cycle etc.

In either case retrieve the logs [1] when the issue occurs (ssh/serialconsole may help)


[1] http://nouveau.freedesktop.org/wiki/Bugs

(In reply to comment #3)

Hi Emil,

I have done a little more testing with 3 NVIDIA RIVA TNT2 64-based graphics cards and 1 Vanta-based graphics card.
Before I share that information, I will respond to your comments.


> To be honest it sounds like your motherboard is dying, not an issue caused
> by nouveau

I have tested this mainboard with many many, NVIDIA, ATI Technologies, Matrox, and SiS graphics cards, and they all boot fine with FIC VA-503+ mainboard.
I honestly don't think that the mainboard is dying based on this observation.
I don't have another mainboard with Apollo MVP3 chipset to do comparison, either.


> 
> Nevertheless there are a few thing you can try
> 
> * Try the proprietary driver (aka the blob)? Do you have similar issue with
> it?
> Note: Not too sure if your card is supported

You are right that NVIDIA binary device driver doesn't exist for Linux this new.
Nouveau is the only choice I have for RIVA TNT2 64.


> 
> 
> Ubuntu 10.04 uses quite (almost 3 years) old kernel - 2.6.32

Yes, I do understand that.
But Canonical still supports Ubuntu 10.04 LTS so I am trying to get the bug fixes incorporated before support goes out.
I also don't like the views many Linux developers have, which is that old code is useless, and it is okay to keep the bugs there.
Even if the kernel is old, and cannot support the lastest hardware, I still want the bugs in the older software to be fixed.


> * Can you try a distro based on a newer kernel. The best choice would be a
> Fedora LiveCD
> 

Strangely, FIC VA-503+ mainboard doesn't even boot with Ubuntu 12.04 LTS due to some new bug of their boot loader code.
I assume it has some issue with VIA Technologies Apollo MVP3 chipset and its southbridge VT82C586B.
I did have to install a non-PAE version of the 32-bit kernel to a hard driver even be able to have a chance to boot with this mainboard, and it won't currently boot.
The same hard drive will boot with another ASUS mainboard with VIA Technologies chipset (ASUS A7V266-E mainboard with VIA Technologies KT266A chipset) without any issues.
I am planning to file a bug report regarding this issue soon.


> If you're still having those issues with nouveau and not with the blob
> 
> Issue 1. Take an image of the boot messages, during bootup if your system
> crashes and the logs are not retrieveable
> 

I believe I attached a .tar.gz file to this bug report.
I had to do it this way because there are 12+ log files in there, and it was impractical to upload that many log files to Bugzilla.
It just takes too much time to upload that many log files.
If you want me to upload individual log files to Bugzilla, I will do it, but I don't want to.
That's why I put all of them into 1 archive file.
If you can download that and analyze it, I will appreciate.


> Issue 2. Try and tiangulate what causes the freeze, specific program,
> suspend/resume cycle etc.
> 

The mainboard is so old that its ACPI doesn't support S3 State.
I am not even sure it even supports S1 State.
Although VIA Technologies "claims" to support Suspend to RAM in Apollo MVP3 and VT82C586B Southbridge (Refer to Apollo MVP3 and VT82C586B datasheet floating around the Internet.), I don't know any company that ever bothered to support this nice feature.
This is typical of mainboards made around 1998 to 2001.
I believe I have done enough testing to be able to reproduce the freeze very reliably.


> In either case retrieve the logs [1] when the issue occurs
> (ssh/serialconsole may help)
> 
> 
> [1] http://nouveau.freedesktop.org/wiki/Bugs

I let Ubuntu's ubuntu-bug upload number of log files for a bug report I reported to its launchpad.net bug report site.
If you don't want to open a .tar.gz file, you can view the log files here.

https://bugs.launchpad.net/ubuntu/+source/xorg/+bug/1065300


Note that I do put a lot of effort writing these bug reports, trying to get Linux developers to fix bugs, and I do my best with my current limited knowledge of Linux to provide whatever information the developer needs.

Regards,

fpgahardwareengineer

Hi Emil,

I have done a little more testing with NVIDIA RIVA TNT2 64-based graphics cards since I now have 4 of them available for testing.
Here are my test results.

Compaq desktop computer pulled PWA-G4000PRO:

- NV5M64
- Revision 15 (from lspci -vvv)
- 16 MB SDRAM
- VGA BIOS Version: Unknown at this point
- Manufacturer unknown
- Likely pulled out of Compaq desktop computer (Compaq spare number on the back)
- Booted fine 3 consecutive times with FIC VA-503+ mainboard without any freezes or crashes

ASUS AGP-3800 COMBAT/16M:

- NV6
- Revision 15 (from lspci -vvv)
- 16 MB
- VGA BIOS Version: V 2.05.13
- Booted fine 3 consecutive times with FIC VA-503+ mainboard without any freezes or crashes

VisionTek RIVA TNT2 64-based graphics card (official graphics card name unknown):

- NV5M64
- Revision 15 (from lspci -vvv)
- 16 MB SDRAM
- VGA BIOS Version: V 2.05.13.04
- Will almost always crash during boot screen (occasionally, will get past the boot screen) with FIC VA-503+ mainboard

Dell desktop computer pulled RIVA TNT2 64-based graphics card (official graphics card name unknown):

- NV5M64
- Revision 15 (from lspci -vvv)
- 16 MB SDRAM (I think)
- Manufacturer unknown
- VGA BIOS Version: Unknown at this point
- Will almost always crash during boot screen (occasionally, will get past the boot screen) with FIC VA-503+ mainboard

Please note that all of these NVIDIA RIVA TNT2 64 and Vanta cards will work fine with other systems.
Regarding the freeze pattern, the Ubuntu startup screen's red dots will stop flashing when the freeze occurs.
However, interestingly, if I press buttons on the keyboard like Esc key often, it sometimes doesn't freeze during boot.
Note that the mainboard is somewhat stable since these AGP graphics cards work fine with FIC VA-503+ mainboard.

- NVIDIA
  * GeForce 2 MX
  * GeForce 4 MX
  * GeForce FX 5200
  * GeForce FX 5700
  * GeForce FX 5950 Ultra (probably one of the most powerful graphics card that can be mated with this old mainboard)

- ATI Technologies
  * Rage Pro Turbo
  * Rage 128
  * Rage 128 Pro
  * Radeon
  * Radeon 9250
  * Radeon 9800 Pro

- SiS
  * 305
  * 315

- Matrox
  * G200
  * G400

Since all of these graphics cards will work fine, I don't think you can honestly say that it is on its last leg.
Also note that one RIVA TNT2 64 and one Vanta card work fine whereas two others RIVA TNT2 64 cards will often freeze during boot.
The one that I managed to file a bug report (the system used to collect all the log files) had the VisionTek version of the RIVA TNT2 64 graphics card in it.
Again, all of these cards will work fine in other mainboards, including the 2 that tend to cause the freeze with FIC VA-503+ mainboard.
Regarding the reason for the freeze, I can think of the following.

- Is Nouveau is accessing the VGA BIOS of the card during boot, and the VGA BIOS is a little buggy?
- Does the VGA BIOS's initialization code configuring RIVA TNT2 64 in a certain way that contributes to the freeze with Apollo MVP3 chipset?


Regards,

fpgahardwareengineer

(In reply to comment #4)
> (In reply to comment #3)
...
> I have tested this mainboard with many many, NVIDIA, ATI Technologies,
> ...
> I don't have another mainboard with Apollo MVP3 chipset to do comparison,
> either.
> 
Point taken

...
> But Canonical still supports Ubuntu 10.04 LTS so I am trying to get the bug
> ...
> want the bugs in the older software to be fixed.
> 
There has been approx 1630 commits since then, some of which may have sorted your issue(s). Despite the fact that bugs for older kernels should be fixed, atm nouveau does not have enough manpower do so.
iirc, we are trying to get 3.x kernels into decent shape 

If you insist on getting this bug sorted as part of your support contract with Ubuntu, refer to them for further assistance

...
> > * Can you try a distro based on a newer kernel. The best choice would be a
> > Fedora LiveCD
> > 
>
> Strangely, FIC VA-503+ mainboard doesn't even boot with Ubuntu 12.04 LTS due
> ...
> I am planning to file a bug report regarding this issue soon.
> 
I have explicitly mentioned the Fedora images rather than Ubuntu
* You do not need an LTS distro for this
* It serves to find out if the issue is fixed or not, rather than replacing your setup

General rule of thumb is, the newer the better

...
> > Issue 1. Take an image of the boot messages, during bootup if your system
> > crashes and the logs are not retrieve-able
> > 
> 
> I believe I attached a .tar.gz file to this bug report.
> ...
> If you can download that and analyze it, I will appreciate.
> 
The tar.gz is present but the logs do not indicate when they were retrieved
* Before, during or after the boot issue
* If the system freezes and cannot start X, consider using serial console/taking a picture of the issue

...
> > Issue 2. Try and triangulate what causes the freeze, specific program,
> > suspend/resume cycle etc.
> > 
> 
> The mainboard is so old that its ACPI doesn't support S3 State.
> 
For the sake of me I cannot list all the things that can cause your issue

...
> I believe I have done enough testing to be able to reproduce the freeze very
> reliably.
> 
This would be useful. Consider using this format

ex.
1. Open up Firefox
2. Go to bbc.co.uk
3. Observe crash as the flash content is loaded
4. describe the crash, attach Xorg.log/picture if applicable

...
> If you don't want to open a .tar.gz file, you can view the log files here.
> 
OMG you got me

...
> Note that I do put a lot of effort writing these bug reports, trying to get
> Linux developers to fix bugs, and I do my best with my current limited
> knowledge of Linux to provide whatever information the developer needs.
> 
Thanks for taking the time

A few friendly notes
* Try to divide and concour - simplify the complex situation you're into
* Spend a couple of minutes reading through the link [1] provided. It indicated what is relevant and what is not
* If you provide alot more or not enough information your chances and decreasing rapidly. Skim through some Resolved/Fixed bugs, to get the general idea

(In reply to comment #5)
> Regarding the reason for the freeze, I can think of the following.
> 
> - Is Nouveau is accessing the VGA BIOS of the card during boot, and the VGA
> BIOS is a little buggy?
> - Does the VGA BIOS's initialization code configuring RIVA TNT2 64 in a
> certain way that contributes to the freeze with Apollo MVP3 chipset?

I would suspect the latter - these old VIA AGP implementations were notoriously unstable and problematic even in Windows and it's not unlikely that different BIOS versions may configure the card differently (AGP 2X/4X, AGP fast writes on/off, etc.)

You can also try updating the motherboard BIOS and try playing with any AGP-related BIOS settings to see if they change the situation.

(In reply to comment #7)

Hi Robert,

Yes, I do understand the "reputation" of VIA Technologies chipset with AGP from 1998 to around 2002 or so.
I remember that ALi was probably even worse at the time (i.e., ALi Alladin V chipset for Socket 7).
Yet, to my surprise, almost all AGP graphics cards I tried were able to at least boot Ubuntu with Apollo MVP3 chipset.
Since this NVIDIA RIVA TNT2 64 AGP graphics card from VisionTek does work fine with other systems, including newer VIA Technologies chipsets, I suspect there might be something wrong inside agpgart-via module specifically that causes issues with Apollo MVP3 chipset.
I will try to obtain kern.log from this system so that someone can analyze it further.

Regards,

fpgahardwareengineer


> (In reply to comment #5)
> > Regarding the reason for the freeze, I can think of the following.
> > 
> > - Is Nouveau is accessing the VGA BIOS of the card during boot, and the VGA
> > BIOS is a little buggy?
> > - Does the VGA BIOS's initialization code configuring RIVA TNT2 64 in a
> > certain way that contributes to the freeze with Apollo MVP3 chipset?
> 
> I would suspect the latter - these old VIA AGP implementations were
> notoriously unstable and problematic even in Windows and it's not unlikely
> that different BIOS versions may configure the card differently (AGP 2X/4X,
> AGP fast writes on/off, etc.)
> 
> You can also try updating the motherboard BIOS and try playing with any
> AGP-related BIOS settings to see if they change the situation.

(In reply to comment #7)

Hi Robert,

A few more things I wanted to add.
I believe I updated the BIOS to the last version I was able to obtain from FIC.
FIC has now put their BIOS image behind a password protected FTP site so I no longer have access to it.
I believe Version JE439 is the last version BIOS they released, and I got it off their site a few years ago.
The BIOS itself is dated from Year 2000.
I also believe I have changed some of the BIOS settings related to AGP for this mainboard, but it has made no difference in terms of freeze behavior.
Again, this is a strange problem considering that some NVIDIA RIVA TNT2 64 cards do work fine with the FIC VA-503+ mainboard, but the VisionTek one in particular doesn't work well (Also, the Dell pulled one doesn't work well, either.).
        Actually, I should also add that I remember seeing an error message that said something like this with the VisionTek RIVA TNT2 64 graphics card right before a freeze,

"GPU crash: switching to ShadowFB instead"

What does this type of an error message mean?
I will try to obtain a kern.log file that confirms this error message.

Regards,

fpgahardwareengineer


> (In reply to comment #5)
> > Regarding the reason for the freeze, I can think of the following.
> > 
> > - Is Nouveau is accessing the VGA BIOS of the card during boot, and the VGA
> > BIOS is a little buggy?
> > - Does the VGA BIOS's initialization code configuring RIVA TNT2 64 in a
> > certain way that contributes to the freeze with Apollo MVP3 chipset?
> 
> I would suspect the latter - these old VIA AGP implementations were
> notoriously unstable and problematic even in Windows and it's not unlikely
> that different BIOS versions may configure the card differently (AGP 2X/4X,
> AGP fast writes on/off, etc.)
> 
> You can also try updating the motherboard BIOS and try playing with any
> AGP-related BIOS settings to see if they change the situation.

Hi,

Based on Robert's suggestions, I went back and fiddled with some of the BIOS settings.
In the past testing, I didn't see too much difference in system stability, but this time around, I turned on and off one BIOS setting at a time.
I can now say that turning off AGP 2X Mode and using AGP 1X Mode does stabilize the system.
This is despite using aggressive memory and PCI related system parameters from the BIOS setup.
Turning off AGP 2X Mode is the only setting the makes or breaks the system.
Because of this, I am writing this comment from the very same system (AMD K6-2 450 MHz, FIC VA-503+ mainboard, 512 MB SDRAM, VisionTek RIVA TNT2 64 16MB AGP graphics card) that used to crash most of the time during boot.
By the way, I was also able to capture the error message on my digital camera, and I will upload that a little later.
If I activated AGP 2X Mode, I do get the following error message right before the freeze.

 . . . GPU lockup - switching to software fbcon

Sorry, the picture quality is not the best one can get, hence, I am not able to transcribe the message 100% correctly, but this is the error message that got displayed if I pressed Esc key during Ubuntu's bootup.
Again, if I don't use AGP 2X Mode (using AGP 1X Mode), it won't display this message.
I guess the question now is why does Nouveau display this error message in the first place if I use AGP 2X Mode, but not in AGP 1X Mode?

Regards,

fpgahardwareengineer

Most likely in 2X mode some of the data transfers to/from the card are getting corrupted somehow, causing the GPU to not respond as expected and causing the lockup detection.

I believe that for AGP problems on VIA chipsets, some people had luck with playing with the "AGP Driving Value" setting in the BIOS, if you have such an option you can try using different settings for this. (As I recall, most AGP chipsets would handle this setting automatically but the crappy VIA AGP implementation used a BIOS setting which sometimes required the user to enter a different value in the hope it would get the card to work properly.)

(In reply to comment #11)

Hi Robert,

Yeah, I will speculate that VIA Technologies screwed up their AGP related timings like setup time in their actual silicon.
I believe NVIDIA has mentioned in their binary Linux device driver documentation that ALi Alladin V chipset's AGP suffers from timing and signal integrity issues.
They also mentioned that Apollo Pro133A (VT82C694X) and KT266 chipsets' AGP 4X Mode is quite buggy, and their device driver turn off AGP 4X Mode, but they never mentioned issues with Apollo MVP3 chipset.
I still remember from 1998 to 1999 that many computer enthusiasts complained about Apollo MVP3 and Alladin V chipsets' AGP were buggy, especially when AGP specific features get utilized (i.e., Side Band Addressing) during 3D games.
Considering that, I guess I should not be too surprised that turning off AGP 2X Mode stabilized the problem.
Still, I am surprised that many newer generation graphics cards like GeForce FX (see my previous post) have worked with this somewhat buggy chipset's AGP, and I believe AGP 2X Mode was on.
        Robert, you are right that some VIA Technologies chipset do have AGP driving value that can be altered in the BIOS setup.
If I remember correctly, I have seen this in several Apollo Pro133A/P4M266A/KT266A-based mainboards.
NVIDIA also mentions this in their aforementioned documentation.
The FIC VA-503+ mainboard doesn't have this feature in their BIOS setup.
Anyway, do you know if there is a way to obtain a log file from Nouveau itself?
Whenever FIC VA-503+ crashes due to this instability of AGP 2X Mode, the previously mentioned GPU lockup error message doesn't seem to get recorded inside kern.log.
I did managed to take somewhat low quality digital camera screen shot of the error message, but it doesn't get recorded inside kern.log.

Regards,

fpgahardwareengineer


> Most likely in 2X mode some of the data transfers to/from the card are
> getting corrupted somehow, causing the GPU to not respond as expected and
> causing the lockup detection.
> 
> I believe that for AGP problems on VIA chipsets, some people had luck with
> playing with the "AGP Driving Value" setting in the BIOS, if you have such
> an option you can try using different settings for this. (As I recall, most
> AGP chipsets would handle this setting automatically but the crappy VIA AGP
> implementation used a BIOS setting which sometimes required the user to
> enter a different value in the hope it would get the card to work properly.)

Hi,

A few more updates.
I have obtained Creative Labs Graphics Blaster TNT 16 MB AGP and Diamond Multimedia Viper 770 32 MB AGP.
They both boot Ubuntu 10.04 LTS 32-bit fine with AGP 2X mode enabled.
In the case of 2 of my NVIDIA RIVA TNT2 M64 cards that cause the freezes, from time to time, they do get through the boot process if I switch to text display mode during boot (as opposed to Ubuntu logo with red dots flashing), but it is not perfect (meaning, I do still get freezes even with this workaround).
Based on this, I think the bug is not hardware in nature, and it appears to be device driver bug (i.e., software) related.
Please note that Creative Labs Graphics Blaster TNT is based on RIVA TNT (NV4), and is older than RIVA TNT2 M64.

Regards,

fpgahardwareengineer

As I mentioned on your other bug report, you'll need to use a much more recent kernel in order for us to be able to really look at it. Please try 3.10 or later.

Note that there's also a nouveau.agpmode configuration variable that you can use to force the agp mode to 1x if that's more stable.

(In reply to comment #14)

Again, since this mainboard is a Socket 7 mainboard, I am not able to run this system on Linux 3.x kernel.
That being said, what I said in comment #13 still holds.
Occasionally, I can get through the Ubuntu boot process, but most of the, I will encounter a freeze.
If I set the system to AGP 1X mode in the BIOS setup, the system will never freeze.
The problem is when I use AGP 2X mode.
Note that these 2 cards are the ONLY AGP card that have issues with Ubuntu when AGP 2X mode is turned on.
I have tested this mainboard with literally all kinds of AGP 3.3V signaling mode supporting cards (including NVIDIA GeForce 7300 GT, GeForce 6200, GeForce 5950 Ultra, GeForce 4 MX, GeForce 2 MX, GeForce 256, RIVA TNT2, RIVA TNT, ATI Technologies Radeon 9700, Radeon 9250, Rage 128 Pro, Rage 128, Matrox G400, 3DLabs Wildcat VP, S3 Graphics Savage4, SiS 305, 315, and many more), and only these 2 NVIDIA RIVA TNT2 M64 have issues when I turn on AGP 2X mode.
This bug does not affect FIC KA-6110 mainboard despite the AGP similarities of VIA Technologies Apollo MVP3 chipset and Apollo Pro133 chipset.

Regards,

fpgahardwareengineer

It's not really clear that there is a driver issue even though some other models of graphics cards don't have this problem in these motherboards. It's quite possible that there is some issue where the card's AGP bus timing is more marginal, etc. and combined with this motherboard/chipset it causes problems. Given all the known issues with VIA AGP and that the TNT2 M64 boards were really low-end boards even when new, with likely not the greatest components/build quality, it seems a reasonable explanation.

(In reply to comment #15)
> (In reply to comment #14)
> 
> Again, since this mainboard is a Socket 7 mainboard, I am not able to run
> this system on Linux 3.x kernel.

For posterity, I'll reply here as well -- that is a complete falsehood. Linux 3.10 should support any 486 or later CPU.

Hi,

I think I have a hard drive with multiple installations of Ubuntu (10.04 LTS and 12.04 LTS, 2 partitions for each releases).
While ago, I put Linux 3.7 into the experimental partitions of this hard drive because someone at launchpad asked me to do so.
Perhaps, I can use this hard drive to install Linux 3.10 and see what will happen.
I will report back in a few days of the results.
I will be using FIC KA-6110 mainboard for this since it can run Ubuntu 12.04 LTS with 32-bit PAE kernel.

Regards,

fpgahardwareengineer

You can use a livecd as well. I think Arch's tend to be pretty up-to-date. Also, as you yourself have pointed out on other bugs, VIA's AGP implementation back in the day left something to be desired. Does booting with nouveau.agpmode=0 fix it? How about agpmode=1? agpmode=2?

No response in a year. If this still happens with the latest software and disabling AGP doesn't help, feel free to re-open.

For the record, I have a TNT2 M64 (PCI) and it works just fine.