display going to sleep after starting wm

I left my system on overnight and gnome put my monitor to sleep (which I thought I had turned off in settings). Now whenever I log in and startx, the screen is loading and black like normal, but then my monitor light starts blinking, and I can't get anything on the display. Doesn't seem to matter which wm I start, same thing. (tried with xfce). If I remove the .xinitrc from my home directory, and "$ startx", I get a display. I know it's not my nvidia driver, because it was working fine all day yesterday. Is this a saved state somewhere in a file I have to clear? How do I fix this?
 
Xorg itself doesn't keep the state as far as I know. But if you used x11/nvidia-settings, that does save some things. It may have saved some resolution/refresh rate combination that's out of range for your monitor. Most monitors nowadays will just switch off the display to protect it.
 
Some of the WMs/DEs use a screen saver program to do that, so double check any autostart items.
If by removing your .xinitrc, take a look for an "xset dpms" command in it.
My preferred method is to have this line in my .xinitrc
xset dpms 0 0 600

and not run any type of screensaver. That command uses the monitor power management stuff and after 5 minutes of inactivity, powers down the monitor.

Sorry, I'm answering "not your question".
 
I didn't use nvidia-settings. The only settings I changed was in the nvidia app, "performance max". What's the best way to resolve this? Tried removing xorg and nvidia-driver-340, and reinstalling. That didn't work.
 
What are the contents of your .xinitrc file? You say removing that you don't have the problem, but I agree that it sounds like command in there is trying to put the monitor in a state it doesn't like.
I think the nvidia app/nvidia-settings can create a save file of the settings (it may do it by default) so if there is a command in your .xinitrc to reload it, it could have bad input for your card/monitor.
 
and not run any type of screensaver. That command uses the monitor power management stuff and after 5 minutes of inactivity, powers down the monitor.

It's good to know for the future, but the only thing that was in my .xinitrc was "exec /usr/local/bin/gnome-session". I tried just a "startxfce4" with no .xinitrc file and the same thing happened. It looks like I'm going to have to do a clean install now because I've hit the power button on my desktop so many times to restart I'm getting a kernel panic every time I boot now. ->

"panic: ufs_dirbad /: bad dir ino 12900608 at ofset 48128: mangled entry"

next install I will be sure to turn off any screensavers / double check power management stuff. Thanks.
 
You have nividia, yes? At one point in time there were issues if you were in a graphical mode and then switched to a different console, the screen would be all just green blocks. A work around for that was to add the following line to your /boot/loader.conf file and reboot:

hw.vga.textmode="1"

I don't know if the problem was ever fixed or not, I don't know if it relates to your problem, but it at least doesn't hurt.
 
Doesn't seem to matter which wm I start, same thing. (tried with xfce). If I remove the .xinitrc from my home directory, and "$ startx", I get a display.
So, XFCE and Gnome fail, but TWM works. Both XFCE and Gnome have their own resolution settings (stored in your home directory along the other XFCE/Gnome settings). Those would be ignored by TWM.

Tried removing xorg and nvidia-driver-340, and reinstalling.
Removing and/or reinstalling applications isn't going to change or remove settings. Especially not settings that are stored in the user's home directory.

It looks like I'm going to have to do a clean install now because I've hit the power button on my desktop so many times to restart I'm getting a kernel panic every time I boot now.
Check your BIOS settings. Specifically power button settings. Set this to 4 second delay. Then a momentary (short) press of the power button will trigger a graceful shutdown via ACPI. Pressing the power button for 4 seconds will instantly power it off. Immediately turning the power off could result in a filesystem corruption. Another way would be to SSH into the machine and restart it remotely.

What happens if you create a new (test) user account and use that? If it works on the new test user then we can conclude the faulty setting is stored somewhere in your home directory.
 
At one point in time there were issues if you were in a graphical mode and then switched to a different console, the screen would be all just green blocks
Yes I have nvidia. What do you mean by switching to a different console? Like switching to a different text tty (ALT-F1) while inside a WM ? I didn't know you could do that, I thought you had to kill the x session first.

Immediately turning the power off could result in a filesystem corruption. Another way would be to SSH into the machine and restart it remotely.

Yes I should have tapped the power button instead of holding it down. I think I remember trying that a few times when I was having problems using the wrong nvidia driver, when my display was hanging,and it didn't work. Or maybe I just didn't wait long enough. I will double check my BIOS settings. Also I created a new user acccount and put "exec /usr/local/bin/gnome-session" in .xinitrc, and the same thing happened. I was looking in /usr/local/share/X11 at app-defaults and some other files, but that's all gone now. lol.
 
Answer to your question is "Yes, that's what I meant". When in an X session, "CTRL-ALT-F#" to switch to an alternate console.

I think SirDice is right with a local config file for XFCE/Gnome. I'm not sure where that would live, but a lot winds up under $HOME/.config Some applications do wind up creating their own directories under $HOME so you'll need to do "ls -a" to find them.
 
Yeah but why would GNOME/Xfce generate a default config file for a new user based off settings from another user ? My monitor blinking and the display not coming up correctly persisted across user accounts. I'm thinking it's some type of shared file / files somewhere in the filesystem and not in $HOME that it is reading from and loading these saved values / states.
 
After things have gone south, can you post the Xorg.0.log from that session?

Easy way to do that on the commandline: cat /var/log/Xorg.0.log | nc termbin.com 9999
 
Yeah but why would GNOME/Xfce generate a default config file for a new user based off settings from another user ? My monitor blinking and the display not coming up correctly persisted across user accounts.
Ahh, sorry, I missed that from post #9.
 
After things have gone south, can you post the Xorg.0.log from that session?

I can't. I get a kernel panic with the error msg I posted earlier every time I boot. I could possibly do it with recovery / single user mode ? But even then I'd have to reinstall for any fixes to work. Unless there is some way to repair the filesystem?
 
I could possibly do it with recovery / single user mode ?
Just don't start X after you rebooted. The logs would still be there after the panic/reboot. Only if you start X it would get overwritten with the 'new' session logs.

Unless there is some way to repair the filesystem?
Yeah, you probably want to fix those first. Boot to single user mode and run fsck -y there.
 
I can't. I get a kernel panic with the error msg I posted earlier every time I boot. I could possibly do it with recovery / single user mode ? But even then I'd have to reinstall for any fixes to work. Unless there is some way to repair the filesystem?
do you have any knowledge about vt and framebuffer? you may be able to troubleshoot and your monitor recognizes.
 
I'm getting a lot of "READ_DMA CAM ATA Status" errors while fsck is running. It's saying it could not read from certain blocks / sectors. Is this indicative of a failing hard drive? or just a corrupted filesystem? I had done a "smartctl" test on the drive a few days ago and I don't think there were any errors. No knowledge of vt or framebuffer, no.
 
My experience has been those types of errors are more hardware than software related. A software change can trigger them: think of a timeout that got changed. "Send a command, wait X, check for status" Maybe previous version X was a lot longer and it was changed down. That could lead to more errors being detected.

So double check cables: power down, unplug and replug both ends of data cables. Do one cable at a time so you don't look track of where they were. Also unplug and replug power cables to the drives.

sometimes the quick smartctl tests don't show anything but a longer test does.
 
Reading this alongside <https://forums.freebsd.org/posts/568325> and nearby posts: starting afresh will be a good idea (if you have not already done so), but only if you're certain that the storage is OK.

I'm getting a lot of "READ_DMA CAM ATA Status" errors while fsck is running. It's saying it could not read from certain blocks / sectors. Is this indicative of a failing hard drive?

Maybe.

or just a corrupted filesystem? I had done a "smartctl" test on the drive a few days ago and I don't think there were any errors. …

S.M.A.R.T self-tests, short and extended, are:
  • read-oriented
  • no substitute for a thorough write test.
Please see, for example steps 1–5 under <https://forums.freebsd.org/posts/529183>.

Ultimate Boot CD
  • does not include StressDisk
  • includes things such as HDAT2
<https://forums.freebsd.org/posts/530069>
<https://forums.freebsd.org/posts/547395>
 
I'll be mounting another hard drive in my case and installing 13.1-RELEASE on it. I'm pretty sure the hard drive I was using before is good, at least good enough to work for a while, but I'll go with ZFS instead of UFS this time, installing the nvidia driver from pkg instead of ports. Also I noticed that I can do "pkg install nvidia-driver-340' or 'pkg install nvidia-driver-390'. On my first attempt I did 'pkg install nvidia-driver', which installed the 470 driver. When that didn't work I built the nvidia-driver-390 from ports, never doing 'pkg install nvidia-driver-3xx'. I'm not too hopeful it will be stable because of all the reports of crashes with the 390 driver, but maybe I can move to something more lightweight, like e16. Also, what about setting up wayland instead of xorg?
 
Thanks,

… I'm pretty sure the hard drive I was using before is good, at least good enough to work for a while, …

My strongest possible recommendation is to stress-test the disk, in its entirety, before giving it to ZFS.

HDAT2, if you can. There exist many alternatives but (if UBCD and HDAT2 will work with your hardware) the result of HDAT2's most powerful test (pictured in post 530069) will be enlightening.
 
… wayland instead of xorg?

I never used Wayland (see <https://community.kde.org/FreeBSD/Setup#KDE_and_the_rest> point 5). More specifically, I never attempted to jump through the hoops that might be required for it to work for KDE Plasma.

This year's Wayland-oriented topics include:


 
It's more of a learning environment than anything. Not vital that the system is stable 100% of the time. All the data on the disk is expendable. Text only console mode, no X as a last resort. But I just read TCP/IP Illustrated Volume 2 so working with a BSD would be preferable. (I know the 4.4BSD-Lite code is old) I have other books as well like APUE so I need a UNIX/BSD.
 
Back
Top