1.0-5328 released.

[zander]

Those of you who experience X server hangs with this release and newer Via chipsets could give the 1.0-5328 Linux 2.6 patch/installer at http://www.minion.de/nvidia.html a try, they work around this problem.

[Soul-Crusher]

Originally posted by silversun
Hi NVIDIA,

the infamous problem with the samsung x10 laptop still exists. Since the windows driver works nice, are there any ideas or plans to fix this for linux?

Cheers

Since this problem seems to occur with Samsung x10 laptops only and not other laptops that use nVidia graphics, perhaps you should start by contacting Samsung?

[wopr]

I had to revert back to the 4620, since these new drivers 5328 conflict with either my internal 3COM card, or the pppoe connection that it's on , causing pppoe to drop connection at random times (1min - 10min intervals). Using both Usermode and Kernel mode pppoe on 2.6.0. had the same effect.

Hardware in general:

Asus A7N8X-deluxe
Linux 2.6.0
ASUS GeForce FX 5200


UPDATE:

Problem solved. Bad patch on the 5328 driver on my end. All is well. ps NVIDIA let's see some 2.6 support.

[Papol]

Originally posted by Andy Mecham
http://www.nvidia.com/object/linux_d..._ia32_1.0-5328

Go forth and download.

--andy

Well, I hate to break the string of grevious gripes, but I've got to. These things actually seem like an improvement over the 4496's. I was never very impressed with the 4620's but games like ut2003, and all of the usual linux garbage appears to be quite a bit smoother and quicker. Totally subjective and useless observation, I know

I'm using 2.6.0 + Nick's latest .27 scheduler patch + my own 'get rid of pci badness' patch + minion's latest. This is on an nf7 mobo with fedora core 1 1/2 (all from fc2 development alpha/beta whatever).

Again, I apologize for liking them, but, oh well, I do.

Then again, maybe I'm the only person left without a samsung x10.

[argasso]

Yeah - a set of non-properly-working drivers after months. Great.

The last good release I remember was 3123. After switching to GF FX, I had to change them.

Switched to ATi - although drivers aren't 100% bug-free and installation process might seem to be somewhat tricky, my overall impression is much better. My advice - do the same if You are able to.

[GmeP]

ggnvidia,

I'm seeing similar things on my AMD Athlon 2000+, A7V333, GF4 Ti4200. Do you also have

NVRM: Could not find pre-fetched memory

Please try the following and tell me if it works for you:

- boot level 3

- modify XF86Config and add

Option "NvAGP" "1"

to your Section "Device"

- go to level 5. The X server will very likely crash

- use <CTRL><ALT><F1> to return to console and go back to level 3

- modify XF86Config to set

Option "NvAGP" "3"

- go to level 5 again

Now OpenGL should work (run glxgears or whatever). This is the only way it works for me However, no matter whether it works or not there will still be ooops and probably things like

(WW) NVIDIA(0): Failed to verify AGP usage

in XFree86.0.log and probably other messages concerning AGP from dmesg. I was sure that came because of my hardware (AMD Athlon and VIA KT333 chipset) that is not really supported by nVIDIA

-> /usr/share/doc/NVIDIA_GLX-1.0/README

but I'm experiencing weird AGP problems even on Xeon, Intel SE7505VB2 with both GF FX 5600 and Quadro FX1000

[Prommy]

Hi.
When I tried the new driver the following happened: First the screen went black. It continued to be black for about half a minute (and during that time i couldn't even change back to tty1) and then the computer rebooted.

I've never had any problems whatsoever with any of the previous drivers (using it since couple of years). I'm running kernel 2.6.0 on a GForce2 (I have used the 2.6.0-test series since about half a year, using minion.de patches).

So now I'm back to 4620 again...

/Daniel

[redmac5]

Originally posted by adnans
Did you try the following parameter combination for the nvidia module?

NVreg_SoftEDIDs=0 NVreg_Mobile=3

Just tried that, without any changes however...

Independent from that, pressing Fn+F4 however made the screen work somewhat as stated in the Samsung X10 thread. The screen then looks a bit like using the interlaced mode on old graphics cards with CRT monitors.

[bwkaz]

Originally posted by bwkaz
I'll run mine through ksymoops in the near future too, and post the results; we should probably compare them.

Looks almost exactly the same as yours, ggnvidia. I would put the differing addresses up to small differences in the kernel compilation, probably. The offsets inside the nVidia module are mostly the same, though.

Unable to handle kernel NULL pointer dereference at virtual address 00000010

>>EIP; c01b808f <pci_read_config_dword+2f/50>   <=====

>>edi; effec000 <_end+2fcfb308/30a12388>
>>ebp; e85c3780 <_end+282d2a88/30a12388>
>>esp; e85c3750 <_end+282d2a58/30a12388>

Trace; c010e42c <pci_conf1_read_config_dword+4c/50>
Trace; f0d8e3a9 <[nvidia]os_pci_read_dword+20/27>
Trace; f0d9d4ae <[nvidia]_nv001370rm+2e/cc>
Trace; f0da805d <[nvidia]_nv001241rm+11/18>
Trace; f0da0676 <[nvidia]_nv000171rm+22a/268>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0da3f47 <[nvidia]_nv001749rm+167/50c>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0dac3d6 <[nvidia]rm_update_agp_config+e/14>
Trace; f0d8cf4c <[nvidia]nv_agp_init+78/fb>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0f69e4c <[nvidia]_nv000443rm+180/12b3>
Trace; f0f69e70 <[nvidia]_nv000443rm+1a4/12b3>
Trace; f0f69e88 <[nvidia]_nv000443rm+1bc/12b3>
Trace; f0f69de0 <[nvidia]_nv000443rm+114/12b3>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0f69de0 <[nvidia]_nv000443rm+114/12b3>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0da9dec <[nvidia]_nv001274rm+7c/b8>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0f69e4c <[nvidia]_nv000443rm+180/12b3>
Trace; f0f69e70 <[nvidia]_nv000443rm+1a4/12b3>
Trace; f0f69e88 <[nvidia]_nv000443rm+1bc/12b3>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0dacf99 <[nvidia]_nv000899rm+7e9/f70>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0d9dd35 <[nvidia]_nv001338rm+1d/24>
Trace; f0dc8400 <[nvidia]_nv004805rm+88/d8>
Trace; f0da7fa8 <[nvidia]_nv001212rm+10/14>
Trace; f0f178f1 <[nvidia]_nv000406rm+4d1/17a0>
Trace; f0da996b <[nvidia]_nv001016rm+3b/64>
Trace; f0f178f1 <[nvidia]_nv000406rm+4d1/17a0>
Trace; f0f178f1 <[nvidia]_nv000406rm+4d1/17a0>
Trace; f0da99bc <[nvidia]_nv001228rm+28/78>
Trace; f0f41f20 <[nvidia]_nv000797rm+0/3e>
Trace; f0e73a6b <[nvidia]_nv001532rm+1f/28>
Trace; f0dc0668 <[nvidia]_nv004240rm+180/18c>
Trace; f0dcdefd <[nvidia]_nv003333rm+10ed/1100>
Trace; f0e73a6b <[nvidia]_nv001532rm+1f/28>
Trace; f0e74251 <[nvidia]_nv003619rm+19/20>
Trace; f0d9dbaa <[nvidia]_nv001344rm+22/6c>
Trace; f0d8e925 <[nvidia]_nv005601rm+d/34>
Trace; f0d8f0eb <[nvidia]_nv005593rm+13/34>
Trace; f0d8efc0 <[nvidia]_nv005594rm+14/58>
Trace; f0d9dd35 <[nvidia]_nv001338rm+1d/24>
Trace; f0da9512 <[nvidia]_nv001223rm+12/18>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0e3adb7 <[nvidia]_nv003847rm+173/1b0>
Trace; f0e73ecf <[nvidia]_nv001535rm+1f/28>
Trace; f0e73a6b <[nvidia]_nv001532rm+1f/28>
Trace; f0e74251 <[nvidia]_nv003619rm+19/20>
Trace; f0e73a6b <[nvidia]_nv001532rm+1f/28>
Trace; f0e74251 <[nvidia]_nv003619rm+19/20>
Trace; f0ebc864 <[nvidia]_nv001823rm+2c/38>
Trace; f0e67a14 <[nvidia]_nv002280rm+8c/98>
Trace; f0e55fc3 <[nvidia]_nv003832rm+117/12c>
Trace; f0da9512 <[nvidia]_nv001223rm+12/18>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0e57c11 <[nvidia]_nv003785rm+5d/6c>
Trace; f0e86755 <[nvidia]_nv003612rm+1c5/1fc>
Trace; f0dadb19 <[nvidia]_nv006208rm+39/44>
Trace; f0e57ad5 <[nvidia]_nv003831rm+65/a8>
Trace; c014d540 <alloc_inode+c0/140>
Trace; c014e365 <get_new_inode+145/160>
Trace; c014e621 <iget4+e1/f0>
Trace; c0156d4f <proc_get_inode+3f/120>
Trace; c0158eeb <proc_lookup+8b/e0>
Trace; f0dac381 <[nvidia]rm_ioctl+19/20>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; f0d8bc23 <[nvidia]nv_kern_ioctl+2c5/301>
Trace; f0f408a0 <[nvidia]nv_linux_devices+0/580>
Trace; c01118d4 <mtrr_ioctl+434/5e0>
Trace; c014c24c <dput+cc/150>
Trace; c0139f55 <fput+d5/130>
Trace; f0d8b95e <[nvidia]nv_kern_ioctl+0/301>
Trace; c014764c <sys_ioctl+bc/240>
Trace; c01073bf <system_call+33/38>

Code;  c01b808f <pci_read_config_dword+2f/50>
00000000 <_EIP>:
Code;  c01b808f <pci_read_config_dword+2f/50>   <=====
   0:   8b 46 10                  mov    0x10(%esi),%eax   <=====
Code;  c01b8092 <pci_read_config_dword+32/50>
   3:   8b 50 30                  mov    0x30(%eax),%edx
Code;  c01b8095 <pci_read_config_dword+35/50>
   6:   89 34 24                  mov    %esi,(%esp,1)
Code;  c01b8098 <pci_read_config_dword+38/50>
   9:   89 4c 24 04               mov    %ecx,0x4(%esp,1)
Code;  c01b809c <pci_read_config_dword+3c/50>
   d:   8b 44 24 20               mov    0x20(%esp,1),%eax
Code;  c01b80a0 <pci_read_config_dword+40/50>
  11:   89 44 24 00               mov    %eax,0x0(%esp,1)

(I like kksymoops' output much better, personally...)

See if this patch helps anybody:

--- NVIDIA-Linux-x86-1.0-5328-pkg1/usr/src/nv/os-interface.c    2003-12-17 17:54:59.000000000 -0500
+++ old/usr/src/nv/os-interface.c       2003-12-23 09:49:33.000000000 -0500
@@ -624,6 +624,13 @@
 ) 
 {
     U032 value;
+
+       if(!handle) {
+               printk(KERN_ERR "handle is NULL in os_pci_read_dword!\n");
+
+               return 0;
+       }
+
     pci_read_config_dword( (struct pci_dev *) handle, offset, (u32 *) &value);
     return value;
 }

Save this into a patch file, and run the installer with --extract-only. Change into the newly created directory, and "patch -Np1 -i /path/to/patchfile" (the N is not strictly necessary but I use it all the time anyway since it doesn't hurt anything). Then either cd into usr/src/nv and "make", or just run "./nvidia-installer" from where you're at. This patch ought to be independent of the ones at minion.de.

Note, though, that it's conceivable that this might cause hardware problems -- I really don't know whether 0 is the right value to return! -EINVAL might be better, but I haven't tried it. Returning 0 does allow X to start, for me at least.

Of course, my problem is that I get a blank console when starting X, and when I return to tty1, I see that X has aborted (due to this oops sending it a SIGSEGV). For the people that are getting oopses but X still loads, I don't know if this patch will help or not.

The real fix, of course, is to change one of _nv001370rm, _nv001241rm, or _nv000171rm to not pass a NULL handle in the first place. But we don't get access to that code...

[zander]

You will want to replace the NULL handle with a handle to the AGP graphics card, instead (if you're interested in details, look at the 1.0-5326 Linux 2.6 patch).

[bwkaz]

Originally posted by zander
You will want to replace the NULL handle with a handle to the AGP graphics card, instead

But how to get that?

Oh, I see. Simply re-enumerate the PCI bus, looking for a VGA class device!

It's all good though, at least for now. Thanks!

[zander]

You need to look for an AGP capable PCI device of that class - there will be only one. Since the problem seems to occur with both AGPGART and the internal NVIDIA AGP GART driver, the problem seems to come from the code that applies AGP overrides after the GART driver has been initialized; whether or not your proposed patch works as expected depends on the configuration of the system the code is executed on.