Solved Display sleeps immediately when dropping out of X

I am having a video issue with FreeBSD 11. I have new video hardware and prior to getting the new hardware I did not have this issue. Hardware is an Nvidia GTX 1050Ti card, which powers a single Dell U3415W monitor using a mini display port cable. This is in an HP z800 workstation. When in X, all is well, not using a display manager, just running startx and x11-wm/fluxbox. DPMS works perfectly while in X: monitor goes to sleep when it is supposed to, wakes with either mouse or keyboard input, no other issues. Running the latest x11/nvidia-driver (384.90). When I drop out of X, the monitor immediately goes into DPMS mode and this is unrecoverable. Switching to any other tty does not wake the screen. Hitting the power button triggers a shutdown and this is the only way to get out of this. I have installed the x11/nvidia-driver using ports. I do not have a single /usr/local/etc/X11/xorg.conf file but instead have two separate files: one for the monitor and one for the card under /usr/local/etc/X11/xorg.conf.d/. This set up works fine while X is running.

No X log entries are generated that would indicate an issue. I would provide the log but currently not running FreeBSD because this behavior is a show stopper and I need my workstation functional.

Sorry I am not able to provide any "evidence" to help troubleshoot but I was hoping someone may be able to lend a hand using just a description of the problem. Thanks in advance.
 
Just clicking the fluxbox "exit" menu item . Have not tried ctrl+alt+del, which on my Linux install exits fluxbox.
 
Good suggestion, will see what I can do about that. I did try two other configurations: implementing vt(4) and a /boot/loader.conf param called
Code:
 hw.vga.textmode=1
This initially worked but then failed after updating x11/nvidia-driver to 384. I may do a reinstall on another drive to see if I can troubleshoot further.

I would really like to have my BSD desktop back.
 
Note that the vt(4) console driver is the default. You may want to try and use the 'old' console driver sc(4) instead. But I have a couple of machines with NVidia cards, all running the latest NVidia driver and all using vt(4) without problems. I can exit out of X and I can switch consoles.
 
Ah ok, good to know. Thanks sirdice. I wonder if it has something to do with how displayport communicates. I went from dvi to dp. Worked fine under dvi. Have read dp uses a completely different method to communicate between the card and monitor. More testing is needed...
 
Have read dp uses a completely different method to communicate between the card and monitor.
That's definitely possible but this shouldn't have an impact. It doesn't change how the card is driven by the driver. Similar to TCP/IP, which Layer 1 you use is irrelevant (Fiber, Coax, UTP, etc.), TCP/IP running on top of it is still the same and doesn't change.
 
It worked under v11 with my old hardware (Nvidia GTX 560 Ti and low-end Asus monitor using DVI. Problem began when I moved to the new hardware. Happened in Linux as well with the Nouveau drivers but not with Nvidia.

I am going to install again on a spare drive so I can keep investigating this. Would love to solve.

I have fluxbox configs I can share but those are not the issue. The behavior is the same regardless of desktop or wm. Unless that's not you asked :)
 
Well, back in FreeBSD again, happily I might add, however my "can't leave X" issues still remains, even a year later. After trying everything suggested in this thread and many others on the Internet, I am throwing in the towel. Not leaving FreeBSD, just living with not being able to go back to a tty...bad part is if I have an issue, all I can do is "ctl+alt+del" to bounce the machine. :(.

I really don't want to see if different hardware fixes the issue because that's expensive and newer hardware may make things worse. Along these lines, what is the newest "on cpu" video graphics chip by Intel that FreeBSD supports? I do have some of the parts to build another box with a gen 7 i7 CPU, onboard video (Intel HD Graphics 630). Is this supported natively by FreeBSD?

Other options include using a display manager and just never leaving x. Is shutting down from a terminal while in x an issue? Does the system cleanly shut down this way?

sudo poweroff

If the power off option is the only thing I can do, I can live with it. Alternatively, since I really don't like display managers, my tty is still active when I leave my window manager so I can just type blind and power off from there. Doesn't help if I have an issue though..

Thanks in advance.

EDIT: This at least answers one of my questions Intel Graphics. Might be time to build a new box...
 
Along these lines, what is the newest "on cpu" video graphics chip by Intel that FreeBSD supports?
If I remember correctly graphics/drm-next-kmod should support everything that's currently available.
I do have some of the parts to build another box with a gen 7 i7 CPU, onboard video (Intel HD Graphics 630). Is this supported natively by FreeBSD?
I'm not entirely sure where the "tipping point" is, I'm quite lost when it comes to Intel or AMD GPU models (mainly the order, which model came before the other model), so you might need graphics/drm-stable-kmod in this case.
 
Thank you SirDice - my current (no tty ;)) set up is working fine until I can get the rest of the pieces together to build a new machine. I may have to tackle UEFI at that time because I have never owned a machine with that technology - will cross that bridge when I come to it!
 
So...I keep looking at this and just found this thread on Nvidia's DevTalk site: VGA BIOS Save State

What does this mean: "loading nvidia-drm with the "modeset=1" parameter. "

Because the OP in the referenced thread stated this, which is my problem:

"> Are you trying to suspend and resume at the console?
On computers without xorg, there is only console.
Suspend/resume then always results in no signal from the Nvidia card.
This indicates that the state save/restore BIOS functions do not do what they should do. "

I am not suspending/resuming, simply dropping out of X, BUT, based on my monitor's reaction, it loses signal and simply goes to sleep. This does not happen when xorg is running: with DPMS set, the display sleeps and happily wakes up when I move the mouse or hit a key.

FreeBSD bug report: Bug 224069

I probably should just give up on this but I hate giving up :p
 
This thread might be moot: pulled the trigger on new hardware and should have the new box up and running this Sunday. If all works well, I'll close the thread as the old machine where the problem was will be a headless build server.
 
Just for the note: I'm seeing similar behavior on P51 with NVIDIA Quadro M2200 when I'm connecting through the dock station DP port; if I use the one on laptop itself (mini-DP), there are no issues with switching from/to X, and exiting X server session. This really drove me mad :) so I'm using it for Windows stuff now, and looking for a system with Intel GPU, just as you did.
 
I hope this resolves my issue - I never see anything odd in the logs, it just sleeps...based on the research I did and the existing FreeBSD bug, it's probably a combination of my video card and the the proprietary driver. I will report back and flag the thread resolved if this fixes the issue. Heck, I needed to upgrade hardware anyway ;)
 
I am having the exact same issue with my ThinkPad P71. yuripv wrote here that he had no issue with 12.0-ALPHA9. Well, I tried 12.0-BETA3 and... I am still getting a black screen when exiting my X session. :confused:
 
An interesting datapoint would be the output of $ xset q (yes, in X) from your machine.

As requested:


[paul@bigzbox]~> xset -q
Keyboard Control:
auto repeat: on key click percent: 0 LED mask: 00000002
XKB indicators:
00: Caps Lock: off 01: Num Lock: on 02: Scroll Lock: off
03: Shift Lock: off 04: Group 2: off 05: Mouse Keys: off
auto repeat delay: 660 repeat rate: 25
auto repeating keys: 00feffffdffffbbf
fadfffffffdfe5ef
ffffffffffffffff
ffffffffffffffff
bell percent: 50 bell pitch: 400 bell duration: 100
Pointer Control:
acceleration: 2/1 threshold: 4
Screen Saver:
prefer blanking: yes allow exposures: yes
timeout: 300 cycle: 600
Colors:
default colormap: 0x20 BlackPixel: 0x0 WhitePixel: 0xffffff
Font Path:
/usr/local/share/fonts/misc/,/usr/local/share/fonts/TTF/,/usr/local/share/fonts/OTF/,/usr/local/share/fonts/Type1/,/usr/local/share/fonts/100dpi/,/usr/local/share/fonts/75dpi/,built-ins
DPMS (Energy Star):
Standby: 0 Suspend: 0 Off: 600
DPMS is Enabled
Monitor is On
Font cache:
Server does not have the FontCache Extension
 
volatilevoid as it turns out, that depends on which port I connect; if it's mini-DP on laptop itself - everything's fine; if it's DP on dock station -- then yes, I'm getting black screen too :(
 
volatilevoid as it turns out, that depends on which port I connect; if it's mini-DP on laptop itself - everything's fine; if it's DP on dock station -- then yes, I'm getting black screen too :(
Hm, I have nothing connected to my laptop and the internal display shuts off. Do you have the same problem when there is no external display connected?
 
Interesting - I thought it might be cable related as well and/or DP vice mini-DP so I bought a "certified" DP cable (hype maybe?) and it made zero diff. At least it wasn't expensive...my set up is simply Nvidia card, DP cable to full size DP into the monitor.
 
volatilevoid TBH, I just stopped wasting my time on issues I can't fix (and looks like no one reads nvidia forums) and installed Windows (as I need it anyway) on that laptop. Now running FreeBSD on proper hardware with Intel graphics that can switch to/from X, exit from X, and flawlessly suspend/resume.
 
Back
Top