physical console eventually goes blank?

rwv37

rwv37

Using 14.3-RELEASE-p5. Ports kept very close to up-to-date.

My typical way of starting up my machine (for literally decades now, and for several different computers) is this:
  1. While physically at the machine, power it on.
  2. Wait for FreeBSD to boot up and present me with a login prompt.
  3. Log in with a regular user.
  4. lock -np; clear
  5. Turn off my monitor.
With fairly rare exceptions, I then essentially never use the physical console again, until the next time I start up the machine. Like I said, I've done it this way for decades, and it's been fine.

I do, however, turn the monitor back on occasionally, while at the machine to do something like physically swapping external hard drives. I almost always umount and mount from another terminal, so I'm not really sure why I turn on the monitor, but I guess just out of force of habit. The monitor just shows the lock prompt (and maybe also whatever log stuff has gone to the console, I guess? Been a while since I've noticed this, so I'm not sure if I see it while lock is active or only after unlocking).

However, the last three times that I've done something like this, the monitor (after having been turned back on) just showed a blank screen.

I've tried things like just hitting return, or even entering the password to unlock, but nothing seems to happen. The machine otherwise seems to work fine.

I'm at a loss. Does anyone know what might cause this, or how I might be able to investigate further?

Thanks in advance for any help.
 
I'm having this same problem in the latest debian linux release. in text console mode the monitor goes to sleep and wont wake up. I can remotely log in, but the hdmi connection between monitor and gpu is inactive. I've futzed with DPMS but no joy. Wondering if by chance the OP machine is also using a nvidia with the vendor closed source driver as I am.

I wouldn't know if the problem exists in bsd because I currently only run bsd in VMs.

Will mention that if I leave the machine with X11 running then the monitor will stay on as I require. It's only in text console mode that the problem occurs.
 
A little further info that seems like it may be relevant:

The machine is in this state right now, and using ps, I was unable to find any lock process that does not have a parent of a tmux process. I do not use tmux at the physical console; like I described initially, I just log in there with a regular user and then lock -np; clear.

Upon first noticing this, I thought the lock -np must have died, and maybe that was because its parent did too, or something wacky like that? But then I realized that maybe lock had stopped because earlier (with the screen blank) I tried entering my password to unlock. Nothing seemed to happen (i.e. screen just stayed blank), but maybe lock was still running there, the keyboard was still useable, and entering my password really did accomplish the unlock.

So, I went to the machine, thinking I would type in something like touch ~/blahblahblah, then go to another machine and see if the file was created. But when I turned my monitor on, the screen was not blank. And it showed that my earlier (visionless) unlock attempt really did the unlock.

So then I thought maybe the monitor or the cable to it is just getting flaky? I should note that whenever I've tried turning the monitor on, its "I am on" LED has lit up, no matter whether it results in a blank screen or not.

Then I did my standard lock -np; clear thing in preparation for physically going away from the machine to think about how to proceed further. But as I did so, I noticed that the lock happened... but the clear did not.

Maybe it is just the monitor and/or cable, but... I feel virtually certain that lock -np; clear has always worked for me in the past (both the lock part and the clear part), soooooo... that's kinda weird, no?

Finally, just for the sake of completeness, one more little note that I'm not sure is relevant, but who knows: I then powered the monitor off, and was about to go away, but thought "I wonder what happens if I turn it back on now." Did so, and the expected screen was displayed (i.e. it was not blank).
 
kent_dorfman766 said:
I'm having this same problem in the latest debian linux release. in text console mode the monitor goes to sleep and wont wake up. I can remotely log in, but the hdmi connection between monitor and gpu is inactive. I've futzed with DPMS but no joy. Wondering if by chance the OP machine is also using a nvidia with the vendor closed source driver as I am.

I wouldn't know if the problem exists in bsd because I currently only run bsd in VMs.

Will mention that if I leave the machine with X11 running then the monitor will stay on as I require. It's only in text console mode that the problem occurs.
Click to expand...

Thanks. First, I'll note that I too am using text console mode; in fact I don't even have any X11 stuff or whatever installed on the machine.

With that said, I unfortunately have no idea what graphics card (or driver) I'm using. I'd love to check, but I don't know how (I mean, besides like taking the machine apart, or hunting for my original purchase info, but I figure there's got to be an easier way than that, like from the command line). I'm not really a hardware-attuned kinda guy. I'll try to figure it out, but could someone please tell me how to check?
 
kent_dorfman766 said:
what is the monitor connection? HDMI/DISPLAY-PORT, DVI, or PC/VGA? It makes a difference because each technology is different.
Click to expand...

I didn't know that either, so I just went there to check. The answer is VGA. However, while there checking that, I realized that all this might just be a "duh" issue (or, more exactly, a "omg duh lol@self" issue):

The monitor's front-facing buttons, including the power button, are all next to each other, and flush against each other. It's entirely possible that when powering it on, I simply fat-fingered without realizing it, and actually pushed not just the power button, but also its immediate neighbor, the "2" button - i.e. the button that switches the display to show the second computer that's hooked up to the monitor. Of which there is no such thing :P

Next time I run into the problem, I'll keep this in mind and see what happens if I then just push "1" to try to get it back to displaying the computer that's actually hooked up to it.
 
For future reference, the VGA protocol has no handshake so it should not turn off the port just because there is no monitor attached. The same cannot be said for HDMI though, as it is a bidirectional protocol with handshaking. Someone will argue with me and say VGA has EDID, but that isn't generally a reason for the host to quit sending signal.
 
rwv37 said:
Thanks. First, I'll note that I too am using text console mode; in fact I don't even have any X11 stuff or whatever installed on the machine.

With that said, I unfortunately have no idea what graphics card (or driver) I'm using. I'd love to check, but I don't know how (I mean, besides like taking the machine apart, or hunting for my original purchase info, but I figure there's got to be an easier way than that, like from the command line). I'm not really a hardware-attuned kinda guy. I'll try to figure it out, but could someone please tell me how to check?
Click to expand...
I cannot remember if bsd has such, but in linux there is the lspci command that displays all the devices in pci land. the vga would be listed. Alternately, the video hardware info should show up in the boot log.

OK just did a quick search and it is pciconf -lv under freebsd. the lspci command is under the supplemental package pciutils which you would have to install.
 
You must log in or register to reply here.
Back
Top