Do you want me to use nomodeset this time?
Should I insert “video = vesa: off vga = normal” on the same linux line of grub where I add “nomodeset” at the end of the line?
When I try to use nomodeset in grub, I have done this only at boot by pressing the “e” key, without actually editing the grub file. Is it really necessary to edit the grub file?
Leave nomodeset out. Otherwise do as you like, press ‘e’ on boot and typing it in is sufficient for a one-time test for generating another bug-report.
After installing nVidia 375.26 driver, when I enter “video=vesa:off vga=normal” in grub at boot by typing “e”, the driver works and I can enter the graphical interface. But when I try to insert “video=vesa:off vga=normal” into the grub file and then save the file by typing “sudo update-grub” and reboot, I get black screen again and this time with weird white characters on top of screen.
When I try to use the command “sudo mv /usr/lib/systemd/system/nvidia-persistenced.service/usr/lib/systemd/system/nvidia-persistenced.service.old”, I get a file or directory not found message.
Ok, so no bug but a change in driver behaviour in a non-supported setup.
You can then forget about the persistenced and delete the blacklist file generated ealier.
Just focus on getting the kernel command line right. What file did you edit?
Edit: you can also post a new output of nvidia-bug-report.sh so I can see your kernel command line parameters.
Even using “video=vesa:off vga=normal” in the grub at boot by typing “e”, I got black screen once or 2, but trying again I ended up getting into the graphical interface.
Here is a bug report created in the graphical interface with Ubuntu loaded after installing the 375.26 driver made with the “video = vesa: off vga = normal” in grub at boot by typing “e”.
nvidia-bug-report.log.gz (80.2 KB)
The file I edited was “/etc/default/grub” and is attached.
I tried to change the place the order to insert “video=vesa:off vga=normal”, but it was useless.
grub.tar.gz (849 Bytes)
You put it in the right place and ran sudo update-grub afterwards, so you should be fine.
The problem is that despite your graphical login worked, the driver was still woeing when the nvidia-persistenced started. That might be the cause for X starting unreliably.
Please remove the file /etc/modprobe.d/00-nvidia-uvm.conf reboot and post a new bug report.
If it still shows driver errors the persistenced has to be disabled next.
I had already deleted the file “/etc/modprobe.d/00-nvidia-uvm.conf” long before the last nvidia-gub-report was created. What do I do now?
The correct comand for persistenced is
sudo mv /lib/systemd/system/nvidia-persistenced.service /lib/systemd/system/nvidia-persistenced.service.old
I will test the result now.
Ok, the uvm module is indeed loaded, didn’t recognise it since the error didn’t change, strange.
So on to disable the persistence daemon:
there should be a file /lib/udev/rules.d/71-nvidia.rules
As a makeshift, edit it as root and comment out the following lines (i.e. put a # at start of line)
# Start and stop nvidia-persistenced on power on and power off
# respectively
ACTION=="add" DEVPATH=="/bus/acpi/drivers/NVIDIA ACPI Video Driver" SUBSYSTEM=="drivers" RUN+="/bin/systemctl start --no-block nvidia-persistenced.service"
ACTION=="remove" DEVPATH=="/bus/acpi/drivers/NVIDIA ACPI Video Driver" SUBSYSTEM=="drivers" RUN+="/bin/systemctl stop --no-block nvidia-persistenced"
# Start and stop nvidia-persistenced when loading and unloading
# the driver
ACTION=="add" DEVPATH=="/module/nvidia" SUBSYSTEM=="module" RUN+="/bin/systemctl start --no-block nvidia-persistenced.service"
ACTION=="remove" DEVPATH=="/module/nvidia" SUBSYSTEM=="module" RUN+="/bin/systemctl stop --no-block nvidia-persistenced"
Then reboot and post a new bug-report
Edit: you were faster, both methods do the same
I was able to run the persistence command below:
Sudo mv /lib/systemd/system/nvidia-persistenced.service /lib/systemd/system/nvidia-persistenced.service.old
You had thought everything was inside the /usr/ directory, but it was in /lib/ as above, and now the command worked.
The result is that now, when restarting the PC, sometimes I can enter the graphical interface, sometimes not.
Here is the bug-report since I could not get in to graphical interface normally. It’s attached.
Is it still necessary to carry out this process that you have posted above?
nvidia-bug-report.log.gz (93 KB)
I left the Linux line of my grub file like this:
GRUB_CMDLINE_LINUX_DEFAULT=“video=vesa:off vga=normal quiet splash”
No need for further action. Persistence daemon is disabled and now the xserver triggers the error by itself:
[ 45.080] (EE) NVIDIA(GPU-0): Failed to initialize DMA.
[ 45.080] (EE) *** Aborting ***
[ 46.083] (EE) NVIDIA(0): Failed to allocate push buffer
[ 49.273] (EE)
Fatal server error:
[ 49.273] (EE) AddScreen/ScreenInit failed for driver 0
[ 49.273] (EE)
[ 49.273] (EE)
Now the next step is to find out why DMA init failes sometimes or takes so long.
Now is it only with you then? If you need me to do anything else, let me know, please.
Will the next driver version 375.xx or 378 xx I can expect some update that solves my problem?
When I have black screen at boot, the error message whose photo is attached is occasionally appearing.
Sooo…some quick googling brought up two possible solutions:
1.BIOS update (unlikely, but if there’s one, it’s worth a try)
2.most likely some faulty RAM module. Different drivers may use different RAM-regions for DMA, so the Win 10 driver and the earlier driver works.
You have (supposedly) 4GB, probably two modules? Try each one alone.
It is very unlikely that this will ever get fixed by a driver update as it points to a hw issue.
The last update for the BIOS of my PC was for the year 2010 and there is no longer support.
My PC has 4GB of RAM (2 x 2GB combs each - from different brands). My GT630 also has 4GB.
You said “You have (supposedly) 4GB, probably two modules? Try each one alone.” I’m not sure I understand. Are you telling me to take out 1 memory stick and turn on the computer and then retract the comb and call again to see if there is an error?
I ran the MEMTEST86 program for 13 hours straight, for 10 full passages, and no memory failure was found.
Sorry, but
memtest fail → defective ram
memtest pass → doesn’t mean anything
Sometimes when I start the system using nVidia driver 375, 378 and 381.09, the attached message appears, which says that my screen, graphics card and input settings could not be detected correctly. So I press CTRL+ALT+F1 and CTRL+ALT+F7 and I can enter the graphical interface. Does this information indicate another possible new cause of the problem?
