Yes i have since figured out, what a thing not to say in the guides… !
So now out of curiosity if i was installing not in a VD, what line of code did i not do right?
And there is no way to use CUDA in VD ?
Thanks
Since the vm does not have any nvidia hardware, you can’t use anything nvidia related in the vm!
And btw, only with installing the great hacking distro Kali, you won’t be a hacker!
That’s why Kali makes not many sense for installing in a vm.
I would suggest, learn the linux basics!
I purely just want to know more on how to protect myself.
So what do you suggest i would have to change in the code to correctly patch the file and run it (outside a VM)…
Thanks
I see now that I have been able to compile and run 367.44 up thru kernel 4.6.5. But not with 4.6.6 or 4.6.7.
I am running fedora 23 on a Dell XPS8700 with the GT720 video adapter. I had run the nouveau drivers thru fedora 22 but when I upgraded my computer crashed several times each day. I landed on the drivers from nVidia which I have been running since June no problem until the upgrade to kernel 4.6.6
am I on the right thread? should I add log files? or should I be starting a new thread?
@Joev_MI, I’m not sure what the proper procedure is for submitting bug reports against the nvidia installer but I’m having the same issue on Fedora 24. Compiling the kernel module fails on 4.6.6 & above, including 4.7.1 and 4.7.2. I’ve also tried the latest beta driver, 370.23, but I get the same results.
Hi everyone. Just noticed this forum while doing our own driver updates in Ubuntu 16.10.
There was a change in get_user_pages() function declaration in mm.h in kernel 4.6+
The following arguments - the first two - were removed.
That is - struct task_struct *tsk, struct mm_struct *mm,
The function is now declared:
long get_user_pages(
unsigned long start,
unsigned long nr_pages,
int write,
int force,
struct page **pages,
struct vm_area_struct **vmas);
This information courtesy of the link below:
http://lxr.free-electrons.com/source/include/linux/mm.h
Hope this helps debug and resolve the issue.
Cheers!
I’ve seen very little to no chatter on this issue.
my configuration:
Dell XPS8700 desktop computer.
cpu: Intel(R) Core™ i5-4460 CPU @ 3.20GHz
graphics adapter: GK208 [GeForce GT 720]
OS: fedora 23, kernel: kernel-4.6.5-200.fc23.x86_64
note: OS has ranged up thru kernel 4.7.10 with varying results. With 4.7.10
I cannot get startx to succeed. with 4.7.9 I can run 367.44; with 4.6.5
I can run 3.67.57.
I have read the post by aplattner entitled, “If you have a problem, and would like assistance, please follow these steps” and generated/collected the debug information recommended but still I don’t understand where to submit them.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
This problem keeps coming back on me just when I think I’ve found a working work-around another version of kernel and/or nvidia driver comes out and breaks it again. On 11/3 about 11:20a I attempted to install nVidia driver version 367.57 running on kernel 4.7.9. I had been running version 367.44 successfully for several months over kernel versions 4.6.5 thru 4.7.9. When I upgraded kernel to 4.7.10 the nvidia driver again could not startx. I thought perhaps the newer version of the nvidia driver might work. on the latest version of kernel that was successfully running 367.44, ie 4.7.9. It too failed to complete the install by starting the X server. I am submitting the attached diagnostics including results from nvidia-bug-collector, dmesg on completion of the attempted install of 367.57 and from a later boot to kernel 4.7.9 with nvidia version 367.57 I am including dmidecode and Xorg.0.log. On the installation attempt of 367.57 eventually it fails when the stack is overflowed. At that point I can invoke a separate session via CTL-ALT-F2.
I then restored version 367.44 version of nvidia driver and booted to kernel version 4.7.9. I found that works only if I add the linux loader command qualifier ‘intel_idle.max_cstate=1’. (A work around I found on a Ubuntu blog.)
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
Some background on my experience
and refresh:
-
starting just before my upgrade from fedora 22 to 23 on May 1 I began
to see some issues with video display. I thought perhaps upgrade to
fc23 might clear that up. I was wrong. Once I upgraded to fc23 I began
having more trouble. The system would freeze from one to several times
per day. It was a hard freeze, a 13 on the Nouveau scale. Frankly, it
was not clear to me whether the issue was the kernel or the video driver. -
as much to sort that out I decided to switch from nouveau to the
proprietary version of the driver. Voila! I was good. that was under
kernel 4.4.8. Then came upgrade to kernel 4.6.6. It came up almost to
a complete boot but it didn’t quite complete. I tried switching from
gnome to xfce, no relief. I tried removing and re-installing. I tried
switching to rpm-fusion distribution. still no luck. -
finally, I tried restricting intel idle cstates, a recommended
work-around offered by Mr Smythies on the ubuntu discussion of a similar
problem. And that has worked (although it didn’t seem to help me when I
was still trying to make the Nouveau driver work). I have updated to
Kernel 4.7.4 with the proprietary (version 367.44) driver without issue
as long as I keep the cstate qualifier on linux loader.
I have yet to attempt an upgrade of the nVidia driver, however; I hope
to hang on to kernel 4.6.5 which I know supports installation of the
nVidia proprietary driver.
detail of workaround: add qualifier to linux boot loader in GRUB to
restrict the intel_idle.max_cstate to 1 as below:
GRUB_CMDLINE_LINUX=“rd.lvm.lv=vg_desktop/lv_swap
rd.lvm.lv=vg_desktop/lv_root SYSFONT=latarcyrheb-sun16
intel_idle.max_cstate=1 nomodeset”