I am experiencing the following problem : each time there is a virtual terminal change (which includes going to sleep mode), the NVidia drivers fails with
nvidia-modeset: ERROR: GPU:0: Display engine push buffer channel allocation failed: 0x65 (Call timed out [NV_ERR_TIMEOUT])
nvidia-modeset: ERROR: GPU:0: Failed to allocate display engine core DMA push buffer
This renders the computer unusable except by ssh-ing into it from another one (and rebooting).
As suggested elsewhere, I tried activating
options nvidia_drm modeset=1
but then the same problem happens immediately when booting to graphical mode (sddm cannot properly start because of this).
Very strangely, this problem is mitigated if I either :
- configure my BIOS to enable non-UEFI booting, or
- start a
```
mokutil
```
operation, which will activate a specific interface at next boot (even without actually doing anything).
In each case, from the very early stages of booting, the display will be initialized differently. This is visible because the resolution of the GRUB menu screen will be much lower.
This is on KUbuntu 18.04 with kernel 5.0.21-050021-generic. It has happened with earlier versions of both the kernel and the Nvidia driver.
journalctl.log (225 KB)
nvidia-bug-report.log.gz (886 KB)
You should know from the previous threads about this issue, it is still unknown to which extent grub has an influence on this. Did you try to take it out of the equation by doing a plain kernel efi stub boot?
I do not think that Grub has much of an influence on this ; I am mentioning the point about Grub appearance/resolution being different as a symptom, not a cause. The same happens if I boot Linux from an UEFI shell :
- if legacy boot is enabled in the BIOS, the UEFI shell will have a small resolution and after booting, changing VT will not cause a problem ;
- if legacy boot is disabled in the BIOS, the UEFI shell gets a much higher resolution and changing VT after booting is not feasible
I suspect that from a very early stage, the graphics card is initialized or used differently and this has both the benign effect on the early console resolution and the blocking effect described above.
Ok, that’s some new data. Sounds like the driver relies on something being set some card’s vbioses only do when the old vga bios is initialized and not by the efi gop alone (pure speculation, of course). Doesn’t really help in finding a real solution, though.
The workaround with mokutil (which causes the next boot to happen differently graphics-wise) enabled me to discover that this difference in the initialization process (GOP vs. VGA) has long lasting effects.
Indeed, if I boot that way, then hibernate, then boot again without resorting to this trick, then the early displays indicate a GOP-only boot (logically) but upon resuming from hibernation I can still switch VT without a problem. So it seems that restoring the memory state of the software is enough to avoid the problem.
I have the same problem on Late 2008 Macbook. mokutil tells "This system doesn’t support Secure Boot’ and the system does not have BIOS AFAIK. Also booting in recovery mode does not work with the nvidia-340 driver.