331.17 BETA drivers feedback thread
  1 / 3    
Again, no recent kernels compatibility. Sad. This time updates are [url=https://devtalk.nvidia.com/default/topic/625178]truly minor[/url]. I guess the next stable release will also be incompatible with =>3.11 - and speaking frankly I don't recognize NVIDIA any more.
Again, no recent kernels compatibility. Sad.

This time updates are truly minor.

I guess the next stable release will also be incompatible with =>3.11 - and speaking frankly I don't recognize NVIDIA any more.

#1
Posted 10/22/2013 06:02 PM   
Anyway, 3.12 compatibility was improved - nv_drm patch doesn't needed anymore. Only NV_NUM_PHYSPAGES. Old 325.15 patch still works.
Anyway, 3.12 compatibility was improved - nv_drm patch doesn't needed anymore. Only NV_NUM_PHYSPAGES.
Old 325.15 patch still works.

#2
Posted 10/22/2013 08:46 PM   
[quote="VadimLinux"]Anyway, 3.12 compatibility was improved - nv_drm patch doesn't needed anymore. Only NV_NUM_PHYSPAGES. Old 325.15 patch still works.[/quote] It's not quite so, we still need to patch more files than just one nv-linux.h. However, the 331.17 works well with linux 3.12-rc6 with appropriate patching ;)
VadimLinux said:Anyway, 3.12 compatibility was improved - nv_drm patch doesn't needed anymore. Only NV_NUM_PHYSPAGES.
Old 325.15 patch still works.

It's not quite so, we still need to patch more files than just one nv-linux.h. However, the 331.17 works well with linux 3.12-rc6 with appropriate patching ;)

#3
Posted 10/23/2013 01:54 AM   
[quote="LinuxHater"]we still need to patch more files than just one nv-linux.h. However, the 331.17 works well with linux 3.12-rc6 with appropriate patching ;)[/quote] Can you be more specific, please? I also on 3.12-rc6 and didn't notice any problems despite I patched only NV_NUM_PHYSPAGES define. What do you mean by "appropriate patching"? Can you post patch or link to it?
LinuxHater said:we still need to patch more files than just one nv-linux.h. However, the 331.17 works well with linux 3.12-rc6 with appropriate patching ;)

Can you be more specific, please? I also on 3.12-rc6 and didn't notice any problems despite I patched only NV_NUM_PHYSPAGES define.
What do you mean by "appropriate patching"? Can you post patch or link to it?

#4
Posted 10/23/2013 10:20 AM   
nvidia 331.17 (didn't test 331.13) breaks vmware 10 on linux 3.11 x86_64. It's odd that windows guests runs ok, while linux guests won't start, giving error "Cannot find a valid peer process to connect to". Downgrading nvidia driver to 325.15 solved issue.
nvidia 331.17 (didn't test 331.13) breaks vmware 10 on linux 3.11 x86_64.
It's odd that windows guests runs ok, while linux guests won't start, giving error "Cannot find a valid peer process to connect to".
Downgrading nvidia driver to 325.15 solved issue.

#5
Posted 10/24/2013 08:50 PM   
@vladdraco That's really weird and shouldn't be happening.
@vladdraco

That's really weird and shouldn't be happening.

#6
Posted 10/25/2013 06:35 AM   
edit: dkms.conf from uvm is named dkms.conf.fragment (i use --extract-only flag) howto add uvm/dkms.conf.fragment into dkms.conf? greetings edit2: with little hacky: cat uvm/dkms.conf.fragment >> dkms.conf solve my problem
edit: dkms.conf from uvm is named dkms.conf.fragment (i use --extract-only flag)

howto add uvm/dkms.conf.fragment into dkms.conf?

greetings

edit2: with little hacky:

cat uvm/dkms.conf.fragment >> dkms.conf

solve my problem

#7
Posted 10/25/2013 03:22 PM   
Nvidia has included uvm support in the 331 branch, and I couldn't compile it without patching. "Appropriate patching" means one has to apply all patches that are required to compile the driver :) And the most important thing is that such a patching is possible.
Nvidia has included uvm support in the 331 branch, and I couldn't compile it without patching.
"Appropriate patching" means one has to apply all patches that are required to compile the driver :) And the most important thing is that such a patching is possible.

#8
Posted 10/26/2013 04:45 AM   
[quote="LinuxHater"]Nvidia has included uvm support in the 331 branch, and I couldn't compile it without patching. "Appropriate patching" means one has to apply all patches that are required to compile the driver :) And the most important thing is that such a patching is possible.[/quote] Well, I have no any problems with building nvidia-uvm for 3/12-rc6. So, it seems, "appropriate patching" isn't as necessary as you think. What exact error you got? And what patch you have applied?
LinuxHater said:Nvidia has included uvm support in the 331 branch, and I couldn't compile it without patching.
"Appropriate patching" means one has to apply all patches that are required to compile the driver :) And the most important thing is that such a patching is possible.

Well, I have no any problems with building nvidia-uvm for 3/12-rc6. So, it seems, "appropriate patching" isn't as necessary as you think. What exact error you got? And what patch you have applied?

#9
Posted 10/26/2013 06:14 PM   
331.17 built fine for me on 3.11.0-12 doing a manual get_num_physpages patch. Seems to work on my GeForce GTX 560 Ti except X still crashes just as IntelliJIDEA starts drawing a fancy progressbar. Here's the backtrace from the core if anyone cares to have a look and can make sense of it: [code] #0 0x00007ff1d08bff77 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 resultvar = 0 pid = 2743 selftid = 2743 #1 0x00007ff1d08c35e8 in __GI_abort () at abort.c:90 save_stage = 2 act = {__sigaction_handler = {sa_handler = 0x7ff1d0a0d53d, sa_sigaction = 0x7ff1d0a0d53d}, sa_mask = {__val = {3, 140735124411323, 5, 140676564042868, 1, 140676564053896, 3, 140735124411300, 12, 140676564053900, 2, 140676564053900, 2, 140735124412112, 9, 140735124413872}}, sa_flags = 85, sa_restorer = 0x7} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007ff1d08fd4fb in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x7ff1d0a11240 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/unix/sysv/linux/libc_fatal.c:199 ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fff73191dc0, reg_save_area = 0x7fff73191cd0}} ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7fff73191dc0, reg_save_area = 0x7fff73191cd0}} fd = 2 on_2 = <optimized out> list = <optimized out> nlist = <optimized out> cp = <optimized out> written = <optimized out> #3 0x00007ff1d0909996 in malloc_printerr (ptr=0x7ff1d5b909b0, str=0x7ff1d0a11328 "double free or corruption (!prev)", action=3) at malloc.c:4923 buf = "00007ff1d5b909b0" cp = <optimized out> #4 _int_free (av=<optimized out>, p=0x7ff1d5b909a0, have_lock=0) at malloc.c:3779 size = <optimized out> fb = <optimized out> nextchunk = <optimized out> nextsize = <optimized out> nextinuse = <optimized out> prevsize = <optimized out> bck = <optimized out> fwd = <optimized out> errstr = <optimized out> locked = <optimized out> __func__ = "_int_free" #5 0x00007ff1d2bc4964 in doListFontsWithInfo () No symbol table info available. #6 0x00007ff1d2bc8521 in ProcessWorkQueue () No symbol table info available. #7 0x00007ff1d2d0e4c9 in WaitForSomething () No symbol table info available. #8 0x00007ff1d2bc3d61 in ?? () No symbol table info available. #9 0x00007ff1d2bb356a in ?? () No symbol table info available. #10 0x00007ff1d08aade5 in __libc_start_main (main=0x7ff1d2bb31a0, argc=9, ubp_av=0x7fff73192408, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff731923f8) at libc-start.c:260 result = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -1565336356066467123, 140676599330950, 140735124415488, 0, 0, 1565045756824871629, 1559775948132147917}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x7ff1d2d202f0 <__libc_csu_init>, 0x7fff73192408}, data = {prev = 0x0, cleanup = 0x0, canceltype = -757988624}}} not_first_call = <optimized out> #11 0x00007ff1d2bb38af in _start () No symbol table info available. [/code]
331.17 built fine for me on 3.11.0-12 doing a manual get_num_physpages patch.

Seems to work on my GeForce GTX 560 Ti except X still crashes just as IntelliJIDEA starts drawing a fancy progressbar. Here's the backtrace from the core if anyone cares to have a look and can make sense of it:
#0  0x00007ff1d08bff77 in __GI_raise (sig=sig@entry=6)
at ../nptl/sysdeps/unix/sysv/linux/raise.c:56
resultvar = 0
pid = 2743
selftid = 2743
#1 0x00007ff1d08c35e8 in __GI_abort () at abort.c:90
save_stage = 2
act = {__sigaction_handler = {sa_handler = 0x7ff1d0a0d53d,
sa_sigaction = 0x7ff1d0a0d53d}, sa_mask = {__val = {3, 140735124411323, 5,
140676564042868, 1, 140676564053896, 3, 140735124411300, 12, 140676564053900,
2, 140676564053900, 2, 140735124412112, 9, 140735124413872}}, sa_flags = 85,
sa_restorer = 0x7}
sigs = {__val = {32, 0 <repeats 15 times>}}
#2 0x00007ff1d08fd4fb in __libc_message (do_abort=do_abort@entry=2,
fmt=fmt@entry=0x7ff1d0a11240 "*** Error in `%s': %s: 0x%s ***\n")
at ../sysdeps/unix/sysv/linux/libc_fatal.c:199
ap = {{gp_offset = 40, fp_offset = 48, overflow_arg_area = 0x7fff73191dc0,
reg_save_area = 0x7fff73191cd0}}
ap_copy = {{gp_offset = 16, fp_offset = 48, overflow_arg_area = 0x7fff73191dc0,
reg_save_area = 0x7fff73191cd0}}
fd = 2
on_2 = <optimized out>
list = <optimized out>
nlist = <optimized out>
cp = <optimized out>
written = <optimized out>
#3 0x00007ff1d0909996 in malloc_printerr (ptr=0x7ff1d5b909b0,
str=0x7ff1d0a11328 "double free or corruption (!prev)", action=3) at malloc.c:4923
buf = "00007ff1d5b909b0"
cp = <optimized out>
#4 _int_free (av=<optimized out>, p=0x7ff1d5b909a0, have_lock=0) at malloc.c:3779
size = <optimized out>
fb = <optimized out>
nextchunk = <optimized out>
nextsize = <optimized out>
nextinuse = <optimized out>
prevsize = <optimized out>
bck = <optimized out>
fwd = <optimized out>
errstr = <optimized out>
locked = <optimized out>
__func__ = "_int_free"
#5 0x00007ff1d2bc4964 in doListFontsWithInfo ()
No symbol table info available.
#6 0x00007ff1d2bc8521 in ProcessWorkQueue ()
No symbol table info available.
#7 0x00007ff1d2d0e4c9 in WaitForSomething ()
No symbol table info available.
#8 0x00007ff1d2bc3d61 in ?? ()
No symbol table info available.
#9 0x00007ff1d2bb356a in ?? ()
No symbol table info available.
#10 0x00007ff1d08aade5 in __libc_start_main (main=0x7ff1d2bb31a0, argc=9,
ubp_av=0x7fff73192408, init=<optimized out>, fini=<optimized out>,
rtld_fini=<optimized out>, stack_end=0x7fff731923f8) at libc-start.c:260
result = <optimized out>
unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -1565336356066467123,
140676599330950, 140735124415488, 0, 0, 1565045756824871629,
1559775948132147917}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0,
0x7ff1d2d202f0 <__libc_csu_init>, 0x7fff73192408}, data = {prev = 0x0,
cleanup = 0x0, canceltype = -757988624}}}
not_first_call = <optimized out>
#11 0x00007ff1d2bb38af in _start ()
No symbol table info available.

#10
Posted 10/28/2013 11:13 AM   
nvidia 331.17 modules also can be built for 3.12-rc7 without errors after single NV_NUM_PHYSPAGES patch.
nvidia 331.17 modules also can be built for 3.12-rc7 without errors after single NV_NUM_PHYSPAGES patch.

#11
Posted 10/28/2013 04:49 PM   
[quote="VadimLinux"]nvidia 331.17 modules also can be built for 3.12-rc7 without errors after single NV_NUM_PHYSPAGES patch.[/quote] Yes, but what and where? The one define I see is:- #if !defined(NV_VMWARE) #define NV_NUM_PHYSPAGES num_physpages #define NV_GET_CURRENT_PROCESS() current->tgid
VadimLinux said:nvidia 331.17 modules also can be built for 3.12-rc7 without errors after single NV_NUM_PHYSPAGES patch.


Yes, but what and where?
The one define I see is:-

#if !defined(NV_VMWARE)
#define NV_NUM_PHYSPAGES num_physpages
#define NV_GET_CURRENT_PROCESS() current->tgid

#12
Posted 10/28/2013 11:53 PM   
Change "num_physpages" to "get_num_physpages" and it should build. Discussions elsewhere suggest that while it builds, it is not entirely correct.
Change "num_physpages" to "get_num_physpages" and it should build. Discussions elsewhere suggest that while it builds, it is not entirely correct.

#13
Posted 10/29/2013 08:10 AM   
Thanks, that worked. To get the kernel module to build "./nvidia-installer --no-unified-memory".
Thanks, that worked.
To get the kernel module to build "./nvidia-installer --no-unified-memory".

#14
Posted 10/29/2013 11:40 AM   
Not really 331-specific, but it looks like NVIDIA decided to block out browsing of the release tree for some reason? I remember specifically that we could browse for new releases and see links to documentation with each release via this site: http://us.download.nvidia.com/XFree86/ Anyone know why that was changed and how we can get equivalent access? As part of my profession, I switch between nvidia driver releases quite often and I've had to refer to this site a lot in the past.
Not really 331-specific, but it looks like NVIDIA decided to block out browsing of the release tree for some reason? I remember specifically that we could browse for new releases and see links to documentation with each release via this site:


http://us.download.nvidia.com/XFree86/


Anyone know why that was changed and how we can get equivalent access? As part of my profession, I switch between nvidia driver releases quite often and I've had to refer to this site a lot in the past.

#15
Posted 10/29/2013 05:49 PM   
  1 / 3    
Scroll To Top