Hey All,
Running an up to date Arch Linux install on a System76 Oryx Pro [NVIDIA Corporation GP106M [GeForce GTX 1060] (rev a1)]. Seemingly randomly, my mouse will disappear and my virtual consoles go blank. Everything still works. I can use the mouse if I am very careful and I can type in the virtual console, but the only solution I have found is restarting lightdm (or reboot the machine). After the error, I see MANY entries in dmesg which look like:
[code]
NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000001 000000c0 0001007c 00000007 00000000
[/code]
with variations in the last 5 columns. And,
[code]
nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.
[/code]
sprinkled in between. There are various posts floating around with similar problems. I tried:
[list]
[.]Switching between virtual console and GUI[/.]
[.]This section of ArchWiki (https://wiki.archlinux.org/index.php/NVIDIA#DRM_kernel_mode_setting)[/.]
[.]Opening xterm and running some commands[/.]
[/list]
Anyone have any suggestions?
Running an up to date Arch Linux install on a System76 Oryx Pro [NVIDIA Corporation GP106M [GeForce GTX 1060] (rev a1)]. Seemingly randomly, my mouse will disappear and my virtual consoles go blank. Everything still works. I can use the mouse if I am very careful and I can type in the virtual console, but the only solution I have found is restarting lightdm (or reboot the machine). After the error, I see MANY entries in dmesg which look like:
Additional details. This error only occurs with an external monitor attached. The mouse is still visible on the main laptop screen, but moves extremely slow. I think this is because every time it moves the NVRM messages in dmesg continually fill up.
Additional details. This error only occurs with an external monitor attached. The mouse is still visible on the main laptop screen, but moves extremely slow. I think this is because every time it moves the NVRM messages in dmesg continually fill up.
Thanks for the report. I haven't seen this, though I'm setting up a comparable configuration to see if I can trigger it.
Just to be clear, by "my virtual consoles go blank" do you mean a terminal emulator (such as xterm or gnome-terminal) run within the desktop is just a black window? Or, do you mean that after the mouse is no longer visible on the external monitor, you press, e.g., ctrl-alt-f1, and your monitor goes blank, instead of displaying a console? If the latter, does the console, when pressing ctrl-alt-f1, display correctly if you haven't already lost your mouse?
For when this happens, is the "Seemingly randomly" while the system is idle and not receiving input (e.g., could this be correlated to DPMS or another power management event happening), or does this happen randomly while you are actively interacting with the system? If the former, does turning off dpms and friends (`xset s off; xset s noblank; xset -dpms`) avoid the problem? That isn't a good work around, but it will help to know if that is what is triggering the problem.
Lastly, do you know if this is a new problem with 375.20, or can you reproduce this with older drivers?
Could you attach an nvidia-bug-report.log?
THanks.
Thanks for the report. I haven't seen this, though I'm setting up a comparable configuration to see if I can trigger it.
Just to be clear, by "my virtual consoles go blank" do you mean a terminal emulator (such as xterm or gnome-terminal) run within the desktop is just a black window? Or, do you mean that after the mouse is no longer visible on the external monitor, you press, e.g., ctrl-alt-f1, and your monitor goes blank, instead of displaying a console? If the latter, does the console, when pressing ctrl-alt-f1, display correctly if you haven't already lost your mouse?
For when this happens, is the "Seemingly randomly" while the system is idle and not receiving input (e.g., could this be correlated to DPMS or another power management event happening), or does this happen randomly while you are actively interacting with the system? If the former, does turning off dpms and friends (`xset s off; xset s noblank; xset -dpms`) avoid the problem? That isn't a good work around, but it will help to know if that is what is triggering the problem.
Lastly, do you know if this is a new problem with 375.20, or can you reproduce this with older drivers?
Andy,
I will try to add as much information at I can.
> Just to be clear, by "my virtual consoles go blank" do you mean a terminal emulator (such as xterm
> or gnome-terminal) run within the desktop is just a black window? Or, do you mean that after the
> mouse is no longer visible on the external monitor, you press, e.g., ctrl-alt-f1, and your monitor
> goes blank, instead of displaying a console? If the latter, does the console, when pressing ctrl-
> alt-f1, display correctly if you haven't already lost your mouse?
If I am on the main laptop display only, I don't lose (it works, but invisible) my mouse. Only on external displays. The issue happens without the external attached too, but is much less obvious (which is why I mentioned that above). For example, as I was typing this I tested ctrl-alt-f1 and the screen was blank. I went to ctrl-alt-f2, although blank, I typed carefully to restart lightdm. And yes, after I restarted lightdm I could ctrl-alt-f{1,2,7} etc.
> For when this happens, is the "Seemingly randomly" while the system is idle and not receiving
> input (e.g., could this be correlated to DPMS or another power management event happening), or
> does this happen randomly while you are actively interacting with the system? If the former, does
> turning off dpms and friends (`xset s off; xset s noblank; xset -dpms`) avoid the problem? That
> isn't a good work around, but it will help to know if that is what is triggering the problem.
I think it is while I am actively using it. The best example I have was when I was giving a presentation on an external projector and it happened. I did try `xset dpms force off` to restore my cursor from https://forum.xfce.org/viewtopic.php?id=10695 at one point. I can try to turn it off more permanently for debugging.
> Lastly, do you know if this is a new problem with 375.20, or can you reproduce this with older
> drivers?
I can try to install an older driver. Any suggestions? 367.57 seem reasonable?
> Could you attach an nvidia-bug-report.log?
I will let it fail again and attach the bug report, then try the next suggestions.
Thanks!
Barry
> Just to be clear, by "my virtual consoles go blank" do you mean a terminal emulator (such as xterm
> or gnome-terminal) run within the desktop is just a black window? Or, do you mean that after the
> mouse is no longer visible on the external monitor, you press, e.g., ctrl-alt-f1, and your monitor
> goes blank, instead of displaying a console? If the latter, does the console, when pressing ctrl-
> alt-f1, display correctly if you haven't already lost your mouse?
If I am on the main laptop display only, I don't lose (it works, but invisible) my mouse. Only on external displays. The issue happens without the external attached too, but is much less obvious (which is why I mentioned that above). For example, as I was typing this I tested ctrl-alt-f1 and the screen was blank. I went to ctrl-alt-f2, although blank, I typed carefully to restart lightdm. And yes, after I restarted lightdm I could ctrl-alt-f{1,2,7} etc.
> For when this happens, is the "Seemingly randomly" while the system is idle and not receiving
> input (e.g., could this be correlated to DPMS or another power management event happening), or
> does this happen randomly while you are actively interacting with the system? If the former, does
> turning off dpms and friends (`xset s off; xset s noblank; xset -dpms`) avoid the problem? That
> isn't a good work around, but it will help to know if that is what is triggering the problem.
I think it is while I am actively using it. The best example I have was when I was giving a presentation on an external projector and it happened. I did try `xset dpms force off` to restore my cursor from https://forum.xfce.org/viewtopic.php?id=10695 at one point. I can try to turn it off more permanently for debugging.
> Lastly, do you know if this is a new problem with 375.20, or can you reproduce this with older
> drivers?
I can try to install an older driver. Any suggestions? 367.57 seem reasonable?
> Could you attach an nvidia-bug-report.log?
I will let it fail again and attach the bug report, then try the next suggestions.
Thanks for the clarifications.
I sort of wonder if losing the mouse and the blank console symptoms are two separate bugs.
Our console restoration code had some big changes between 370.xx and 375.xx, so I'd be curious if you see the blank console problem with any 370.xx driver.
For losing the mouse, yes, I think testing something 367.xx vintage would be far enough back.
Thanks!
I sort of wonder if losing the mouse and the blank console symptoms are two separate bugs.
Our console restoration code had some big changes between 370.xx and 375.xx, so I'd be curious if you see the blank console problem with any 370.xx driver.
For losing the mouse, yes, I think testing something 367.xx vintage would be far enough back.
As I prepared to install the 367 driver, I replaced nvidia-libgl with mesa-libgl and I haven't run into the issue again. I am going to give it 2 days to be safe, then reinstall nvidia-libgl to get the bug report. Just want to keep this updated.
As I prepared to install the 367 driver, I replaced nvidia-libgl with mesa-libgl and I haven't run into the issue again. I am going to give it 2 days to be safe, then reinstall nvidia-libgl to get the bug report. Just want to keep this updated.
Thank you chiroptical for the tip,
your solution applied to me too. Since last 375.20-3 update SDDM became pretty irresponsive when locking Plasma session (plus other weird behaviors) and Gwenview was crashing each time I tried to display a picture fullscreen (call stack was ending somewhere in nvidia libraries). Replacing nvidia-libgl by mesa one seems to solve these two problems. I'm on an up to date Arch Linux too with a NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
Thank you chiroptical for the tip,
your solution applied to me too. Since last 375.20-3 update SDDM became pretty irresponsive when locking Plasma session (plus other weird behaviors) and Gwenview was crashing each time I tried to display a picture fullscreen (call stack was ending somewhere in nvidia libraries). Replacing nvidia-libgl by mesa one seems to solve these two problems. I'm on an up to date Arch Linux too with a NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
That is useful isolation; thanks.
However, it is curious if replacing NVIDIA's OpenGL with Mesa's OpenGL solved the problem. If NVIDIA's X driver and server-side GLX is being used but Mesa's client-side OpenGL is being used, that suggests the system is falling back to GLX indirect rendering, but most modern configurations disable GLX indirect rendering. In both the failing and working configurations, could you capture the output of:
`glxinfo | grep "vendor"`
and
`ldd /usr/bin/glxinfo`
?
However, it is curious if replacing NVIDIA's OpenGL with Mesa's OpenGL solved the problem. If NVIDIA's X driver and server-side GLX is being used but Mesa's client-side OpenGL is being used, that suggests the system is falling back to GLX indirect rendering, but most modern configurations disable GLX indirect rendering. In both the failing and working configurations, could you capture the output of:
`glxinfo | grep "vendor"`
and
`ldd /usr/bin/glxinfo`
Thanks, I have your log; you can remove it from google drive.
The particular Xids in the log indicate that the display engine of the GPU cannot translate the buffer handles provided by the driver to the video memory buffers described by those handles. I suspect an earlier error caused the display engine to lose its handle table. But, I can't find anything earlier in the log to suggest that sort of error.
The one other interesting I see is your use of the "composition pipeline":
Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"
Would you mind testing without ForceFullCompositionPipeline, to see if that makes a difference in reproducing the problem?
Thanks.
Thanks, I have your log; you can remove it from google drive.
The particular Xids in the log indicate that the display engine of the GPU cannot translate the buffer handles provided by the driver to the video memory buffers described by those handles. I suspect an earlier error caused the display engine to lose its handle table. But, I can't find anything earlier in the log to suggest that sort of error.
The one other interesting I see is your use of the "composition pipeline":
Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"
Would you mind testing without ForceFullCompositionPipeline, to see if that makes a difference in reproducing the problem?
linuxmint-18.3-mate-64bit, *4.13.0-39-lowlatency | *XG-C100C (*PnP) *2018-01 C.U. for Win 10 1709 x64 (KB4056892), 600084f | (EOL)SABERTOOTH 990FX R2.0 (UEFI 2901, 2016/08/05), FX-8370 (Wraith) fam15h, details, 600084f, CSM-->UEFI and **Legacy OpROM (**allows for the custom partitioning of SSDs & HDDs that will also work intact with up-to-date Vishera-capable PC-BIOS-based motherboards), no 'Secure' Boot or HPET | IOMMU Enabled (64-bit) | KVR16E11K4/32 (MBECI-0006) | STRIX-GTX960-DC2OC-4GD5 (nVidia 384.111). Resume from S3 works correctly in all regards. Hibernate does not. | GL2450HM, DVIDDMM10, ARMUNONB | 220-G2-0850-XR | GH22LP20 (LightScribe), USB2SATAIDE (JM20337) | DRW-24B1ST | PEXMSATA3422 (FW: 2.3.0.1065) with 2 x SMS200S3/120G in RAID 0 and 2 x ST3000DM001 in RAID 0 | 1 x SUV400S37240G, 1 x ST6000DM001, 1 x ST2000DM001 [Win 10 Pro 1709 x64] (SB950) | 1 x SUV400S37240G, 1 x ST6000DM001 (ASM1062) | JMS561-based S252BU33R (FW: 101.01.01.09, incompatible with the ASM1042A in all modes) with 2 x ST2000LM003 (RAID0), JU-P40511-S1 (uPD720201), JU-H40711-S1 (VIA VL811 ) | CM 690 II Advanced, 2 x HP-12 PWMs, 6 x HP-14 PWMs, 1 x FAN7X10TX3 (via a 70mm to 80mm AM2 CPU cooler bracket) | ST0026Z | PCE-AC55BT (Intel 7260) PnP, no suspend issues with or without ErP | Y-BF37 (Sleep key), SM50F76959
Running an up to date Arch Linux install on a System76 Oryx Pro [NVIDIA Corporation GP106M [GeForce GTX 1060] (rev a1)]. Seemingly randomly, my mouse will disappear and my virtual consoles go blank. Everything still works. I can use the mouse if I am very careful and I can type in the virtual console, but the only solution I have found is restarting lightdm (or reboot the machine). After the error, I see MANY entries in dmesg which look like:
with variations in the last 5 columns. And,
sprinkled in between. There are various posts floating around with similar problems. I tried:
Anyone have any suggestions?
Just to be clear, by "my virtual consoles go blank" do you mean a terminal emulator (such as xterm or gnome-terminal) run within the desktop is just a black window? Or, do you mean that after the mouse is no longer visible on the external monitor, you press, e.g., ctrl-alt-f1, and your monitor goes blank, instead of displaying a console? If the latter, does the console, when pressing ctrl-alt-f1, display correctly if you haven't already lost your mouse?
For when this happens, is the "Seemingly randomly" while the system is idle and not receiving input (e.g., could this be correlated to DPMS or another power management event happening), or does this happen randomly while you are actively interacting with the system? If the former, does turning off dpms and friends (`xset s off; xset s noblank; xset -dpms`) avoid the problem? That isn't a good work around, but it will help to know if that is what is triggering the problem.
Lastly, do you know if this is a new problem with 375.20, or can you reproduce this with older drivers?
Could you attach an nvidia-bug-report.log?
THanks.
Andy Ritger
NVIDIA Linux Graphics
I will try to add as much information at I can.
> Just to be clear, by "my virtual consoles go blank" do you mean a terminal emulator (such as xterm
> or gnome-terminal) run within the desktop is just a black window? Or, do you mean that after the
> mouse is no longer visible on the external monitor, you press, e.g., ctrl-alt-f1, and your monitor
> goes blank, instead of displaying a console? If the latter, does the console, when pressing ctrl-
> alt-f1, display correctly if you haven't already lost your mouse?
If I am on the main laptop display only, I don't lose (it works, but invisible) my mouse. Only on external displays. The issue happens without the external attached too, but is much less obvious (which is why I mentioned that above). For example, as I was typing this I tested ctrl-alt-f1 and the screen was blank. I went to ctrl-alt-f2, although blank, I typed carefully to restart lightdm. And yes, after I restarted lightdm I could ctrl-alt-f{1,2,7} etc.
> For when this happens, is the "Seemingly randomly" while the system is idle and not receiving
> input (e.g., could this be correlated to DPMS or another power management event happening), or
> does this happen randomly while you are actively interacting with the system? If the former, does
> turning off dpms and friends (`xset s off; xset s noblank; xset -dpms`) avoid the problem? That
> isn't a good work around, but it will help to know if that is what is triggering the problem.
I think it is while I am actively using it. The best example I have was when I was giving a presentation on an external projector and it happened. I did try `xset dpms force off` to restore my cursor from https://forum.xfce.org/viewtopic.php?id=10695 at one point. I can try to turn it off more permanently for debugging.
> Lastly, do you know if this is a new problem with 375.20, or can you reproduce this with older
> drivers?
I can try to install an older driver. Any suggestions? 367.57 seem reasonable?
> Could you attach an nvidia-bug-report.log?
I will let it fail again and attach the bug report, then try the next suggestions.
Thanks!
Barry
I sort of wonder if losing the mouse and the blank console symptoms are two separate bugs.
Our console restoration code had some big changes between 370.xx and 375.xx, so I'd be curious if you see the blank console problem with any 370.xx driver.
For losing the mouse, yes, I think testing something 367.xx vintage would be far enough back.
Thanks!
Andy Ritger
NVIDIA Linux Graphics
your solution applied to me too. Since last 375.20-3 update SDDM became pretty irresponsive when locking Plasma session (plus other weird behaviors) and Gwenview was crashing each time I tried to display a picture fullscreen (call stack was ending somewhere in nvidia libraries). Replacing nvidia-libgl by mesa one seems to solve these two problems. I'm on an up to date Arch Linux too with a NVIDIA Corporation GK107 [GeForce GTX 650] (rev a1)
However, it is curious if replacing NVIDIA's OpenGL with Mesa's OpenGL solved the problem. If NVIDIA's X driver and server-side GLX is being used but Mesa's client-side OpenGL is being used, that suggests the system is falling back to GLX indirect rendering, but most modern configurations disable GLX indirect rendering. In both the failing and working configurations, could you capture the output of:
`glxinfo | grep "vendor"`
and
`ldd /usr/bin/glxinfo`
?
Andy Ritger
NVIDIA Linux Graphics
and
I will be on vacation next week so I can try to recreate the issue and send you the report.
Thanks!
As soon as I can get the bug report I will attach. - Barry
Captured. Let me know when you have it. I would like to remove the link.
The particular Xids in the log indicate that the display engine of the GPU cannot translate the buffer handles provided by the driver to the video memory buffers described by those handles. I suspect an earlier error caused the display engine to lose its handle table. But, I can't find anything earlier in the log to suggest that sort of error.
The one other interesting I see is your use of the "composition pipeline":
Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"
Would you mind testing without ForceFullCompositionPipeline, to see if that makes a difference in reproducing the problem?
Thanks.
Andy Ritger
NVIDIA Linux Graphics
Arch Forum
https://www.linuxquestions.org/questions/arch-29/
linuxmint-18.3-mate-64bit, *4.13.0-39-lowlatency | *XG-C100C (*PnP) *2018-01 C.U. for Win 10 1709 x64 (KB4056892), 600084f | (EOL)SABERTOOTH 990FX R2.0 (UEFI 2901, 2016/08/05), FX-8370 (Wraith) fam15h, details, 600084f, CSM-->UEFI and **Legacy OpROM (**allows for the custom partitioning of SSDs & HDDs that will also work intact with up-to-date Vishera-capable PC-BIOS-based motherboards), no 'Secure' Boot or HPET | IOMMU Enabled (64-bit) | KVR16E11K4/32 (MBECI-0006) | STRIX-GTX960-DC2OC-4GD5 (nVidia 384.111). Resume from S3 works correctly in all regards. Hibernate does not. | GL2450HM, DVIDDMM10, ARMUNONB | 220-G2-0850-XR | GH22LP20 (LightScribe), USB2SATAIDE (JM20337) | DRW-24B1ST | PEXMSATA3422 (FW: 2.3.0.1065) with 2 x SMS200S3/120G in RAID 0 and 2 x ST3000DM001 in RAID 0 | 1 x SUV400S37240G, 1 x ST6000DM001, 1 x ST2000DM001 [Win 10 Pro 1709 x64] (SB950) | 1 x SUV400S37240G, 1 x ST6000DM001 (ASM1062) | JMS561-based S252BU33R (FW: 101.01.01.09, incompatible with the ASM1042A in all modes) with 2 x ST2000LM003 (RAID0), JU-P40511-S1 (uPD720201), JU-H40711-S1 (VIA VL811 ) | CM 690 II Advanced, 2 x HP-12 PWMs, 6 x HP-14 PWMs, 1 x FAN7X10TX3 (via a 70mm to 80mm AM2 CPU cooler bracket) | ST0026Z | PCE-AC55BT (Intel 7260) PnP, no suspend issues with or without ErP | Y-BF37 (Sleep key), SM50F76959