Arch Linux on nvidia 375.20-3 driver: mouse disappears, virtual consoles blank.

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?

chiroptical

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:

NVRM: Xid (PCI:0000:01:00): 56, CMDre 00000001 000000c0 0001007c 00000007 00000000

with variations in the last 5 columns. And,

nvidia-modeset: WARNING: GPU:0: Lost display notification (0:0x00000000); continuing.

sprinkled in between. There are various posts floating around with similar problems. I tried:

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

Anyone have any suggestions?

#1

Posted 12/02/2016 03:41 PM

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.

chiroptical

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.

#2

Posted 12/05/2016 05:37 PM

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.

aritger

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.

Andy Ritger
NVIDIA Linux Graphics

#3

Posted 12/08/2016 08:54 PM

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

chiroptical

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

#4

Posted 12/08/2016 09:20 PM

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!

aritger

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!

Andy Ritger
NVIDIA Linux Graphics

#5

Posted 12/08/2016 09:36 PM

More information will be on the way. Thanks Andy!

chiroptical

More information will be on the way. Thanks Andy!

#6

Posted 12/08/2016 09:50 PM

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.

chiroptical

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.

#7

Posted 12/12/2016 10:14 PM

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)

molaux

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)

#8

Posted 12/14/2016 03:17 PM

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` ?

aritger

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`

?

Andy Ritger
NVIDIA Linux Graphics

#9

Posted 12/20/2016 05:53 AM

Working Configuration: [code][chiroptical ~]$ glxinfo | grep "vendor" server glx vendor string: SGI client glx vendor string: Mesa Project and SGI OpenGL vendor string: VMware, Inc.[/code] and [code][chiroptical ~]$ ldd /usr/bin/glxinfo linux-vdso.so.1 (0x00007fffbcf9b000) libGL.so.1 => /usr/lib/libGL.so.1 (0x00007fca54b2e000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fca547ef000) libc.so.6 => /usr/lib/libc.so.6 (0x00007fca54451000) libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fca54227000) libxcb-dri3.so.0 => /usr/lib/libxcb-dri3.so.0 (0x00007fca54024000) libxcb-present.so.0 => /usr/lib/libxcb-present.so.0 (0x00007fca53e21000) libxcb-sync.so.1 => /usr/lib/libxcb-sync.so.1 (0x00007fca53c1a000) libxshmfence.so.1 => /usr/lib/libxshmfence.so.1 (0x00007fca53a17000) libglapi.so.0 => /usr/lib/libglapi.so.0 (0x00007fca537e8000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fca535d6000) libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007fca533d3000) libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fca531cd000) libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x00007fca52fcb000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fca52da2000) libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0x00007fca52b86000) libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0x00007fca52981000) libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007fca5277b000) libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007fca5256b000) libm.so.6 => /usr/lib/libm.so.6 (0x00007fca52267000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fca5204a000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fca51e46000) /lib64/ld-linux-x86-64.so.2 (0x00007fca54da0000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fca51c42000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fca51a3c000) [/code] I will be on vacation next week so I can try to recreate the issue and send you the report. Thanks!

chiroptical

Working Configuration:

[chiroptical ~]$ glxinfo | grep "vendor"

server glx vendor string: SGI

client glx vendor string: Mesa Project and SGI

OpenGL vendor string: VMware, Inc.

and

[chiroptical ~]$ ldd /usr/bin/glxinfo 

	linux-vdso.so.1 (0x00007fffbcf9b000)

	libGL.so.1 => /usr/lib/libGL.so.1 (0x00007fca54b2e000)

	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007fca547ef000)

	libc.so.6 => /usr/lib/libc.so.6 (0x00007fca54451000)

	libexpat.so.1 => /usr/lib/libexpat.so.1 (0x00007fca54227000)

	libxcb-dri3.so.0 => /usr/lib/libxcb-dri3.so.0 (0x00007fca54024000)

	libxcb-present.so.0 => /usr/lib/libxcb-present.so.0 (0x00007fca53e21000)

	libxcb-sync.so.1 => /usr/lib/libxcb-sync.so.1 (0x00007fca53c1a000)

	libxshmfence.so.1 => /usr/lib/libxshmfence.so.1 (0x00007fca53a17000)

	libglapi.so.0 => /usr/lib/libglapi.so.0 (0x00007fca537e8000)

	libXext.so.6 => /usr/lib/libXext.so.6 (0x00007fca535d6000)

	libXdamage.so.1 => /usr/lib/libXdamage.so.1 (0x00007fca533d3000)

	libXfixes.so.3 => /usr/lib/libXfixes.so.3 (0x00007fca531cd000)

	libX11-xcb.so.1 => /usr/lib/libX11-xcb.so.1 (0x00007fca52fcb000)

	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007fca52da2000)

	libxcb-glx.so.0 => /usr/lib/libxcb-glx.so.0 (0x00007fca52b86000)

	libxcb-dri2.so.0 => /usr/lib/libxcb-dri2.so.0 (0x00007fca52981000)

	libXxf86vm.so.1 => /usr/lib/libXxf86vm.so.1 (0x00007fca5277b000)

	libdrm.so.2 => /usr/lib/libdrm.so.2 (0x00007fca5256b000)

	libm.so.6 => /usr/lib/libm.so.6 (0x00007fca52267000)

	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007fca5204a000)

	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007fca51e46000)

	/lib64/ld-linux-x86-64.so.2 (0x00007fca54da0000)

	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007fca51c42000)

	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007fca51a3c000)

I will be on vacation next week so I can try to recreate the issue and send you the report.

Thanks!

#10

Posted 12/20/2016 07:19 PM

Not working configuration: [code][chiroptical ~]$ glxinfo | grep "vendor" server glx vendor string: NVIDIA Corporation client glx vendor string: NVIDIA Corporation OpenGL vendor string: NVIDIA Corporation [chiroptical ~]$ ldd /usr/bin/glxinfo linux-vdso.so.1 (0x00007ffdec3d4000) libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f31a3879000) libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f31a353a000) libc.so.6 => /usr/lib/libc.so.6 (0x00007f31a319c000) libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007f31a2f6b000) libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f31a2d59000) libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007f31a2a83000) libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f31a287f000) libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f31a2662000) libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f31a2439000) /lib64/ld-linux-x86-64.so.2 (0x00007f31a3af1000) libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f31a2235000) libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f31a202f000)[/code] As soon as I can get the bug report I will attach. - Barry

chiroptical

Not working configuration:

[chiroptical ~]$ glxinfo | grep "vendor"

server glx vendor string: NVIDIA Corporation

client glx vendor string: NVIDIA Corporation

OpenGL vendor string: NVIDIA Corporation

[chiroptical ~]$ ldd /usr/bin/glxinfo 

	linux-vdso.so.1 (0x00007ffdec3d4000)

	libGL.so.1 => /usr/lib/libGL.so.1 (0x00007f31a3879000)

	libX11.so.6 => /usr/lib/libX11.so.6 (0x00007f31a353a000)

	libc.so.6 => /usr/lib/libc.so.6 (0x00007f31a319c000)

	libGLX.so.0 => /usr/lib/libGLX.so.0 (0x00007f31a2f6b000)

	libXext.so.6 => /usr/lib/libXext.so.6 (0x00007f31a2d59000)

	libGLdispatch.so.0 => /usr/lib/libGLdispatch.so.0 (0x00007f31a2a83000)

	libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f31a287f000)

	libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f31a2662000)

	libxcb.so.1 => /usr/lib/libxcb.so.1 (0x00007f31a2439000)

	/lib64/ld-linux-x86-64.so.2 (0x00007f31a3af1000)

	libXau.so.6 => /usr/lib/libXau.so.6 (0x00007f31a2235000)

	libXdmcp.so.6 => /usr/lib/libXdmcp.so.6 (0x00007f31a202f000)

As soon as I can get the bug report I will attach. - Barry

#11

Posted 12/24/2016 08:59 PM

https://drive.google.com/file/d/0B3k9IViw0wE_a1MwNVpBWklxU0U/view?usp=sharing Captured. Let me know when you have it. I would like to remove the link.

chiroptical

https://drive.google.com/file/d/0B3k9IViw0wE_a1MwNVpBWklxU0U/view?usp=sharing

Captured. Let me know when you have it. I would like to remove the link.

#12

Posted 12/24/2016 10:17 PM

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.

aritger

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.

Andy Ritger
NVIDIA Linux Graphics

#13

Posted 12/29/2016 07:04 PM

This should already be on. I believe I found that in the Arch Wiki. [code] [chiroptical ~]$ cat /etc/X11/xorg.conf.d/20-nvidia.conf Section "Device" Identifier "NVIDIA GPU" Driver "nvidia" Option "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }" EndSection [chiroptical ~]$ nvidia-settings -q CurrentMetaMode Attribute 'CurrentMetaMode' (wilder:0.0): id=50, switchable=yes, source=RandR :: DPY-1: nvidia-auto-select @1920x1080 +0+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0, ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DPY-3: nvidia-auto-select @1680x1050 +1920+0 {ViewPortIn=1680x1050, ViewPortOut=1680x1050+0+0} [/code]

chiroptical

This should already be on. I believe I found that in the Arch Wiki.

[chiroptical ~]$ cat /etc/X11/xorg.conf.d/20-nvidia.conf 

Section "Device"                                                                 

	Identifier "NVIDIA GPU"                                                      

	Driver "nvidia"                                                              

	Option  "metamodes" "nvidia-auto-select +0+0 { ForceFullCompositionPipeline = On }"

EndSection



[chiroptical ~]$ nvidia-settings -q CurrentMetaMode



  Attribute 'CurrentMetaMode' (wilder:0.0): id=50, switchable=yes, source=RandR :: DPY-1: nvidia-auto-select @1920x1080 +0+0 {ViewPortIn=1920x1080, ViewPortOut=1920x1080+0+0,

  ForceCompositionPipeline=On, ForceFullCompositionPipeline=On}, DPY-3: nvidia-auto-select @1680x1050 +1920+0 {ViewPortIn=1680x1050, ViewPortOut=1680x1050+0+0}

#14

Posted 12/30/2016 06:40 PM

OP, have you posted a thread here as well? Arch Forum [url]https://www.linuxquestions.org/questions/arch-29/[/url]

JGB123321

OP, have you posted a thread here as well?

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

#15

Posted 12/31/2016 03:13 AM

Email
Password

Sign In
Remember Me	Forgot Password?

New Private Message

Add Poll

Report Comment

Use Forum Credentials