Turned off monitor overnight, stays blank when I turn it back on next morning

[Fuzzball]

Twice now I've had a situation where I am running Spinrite on a drive that runs past bedtime, so I turn off the computer monitor to reduce light shining into the hallway, and when I turn it on in the morning it's blank and I can't get anything to show on screen.

This is using a new Zimaboard, some old and junky 3.5" Sata spinning drives, and Spinrite 6.1. I believe the first time was PR 5.01 and the second was PR 5.02. When testing with Spinrite during the day I can turn off and on the monitor briefly, and it doesn't seem to have any problems.

On the one occasion the hard drive seemed to be actively doing something, though it might have been death throws because the sound and vibration seemed non-uniform. The second time the drive (a different one) was powered on but didn't sound or feel like it was doing anything (other than spinning). Of course there was no way of knowing what their status was because the screen was blank.

Each time I played with the keyboard to no avail. I ended up having to power off the ZimaBoard, after which it behaved normally. I suppose it could be something with ZimaBoard. I'm using their Mini-DP to HDMI adapter, and an HDMI cable to a run of the mill monitor. Has anyone else run into something like this?

If it happens again I'll try to take note of the last logfile to see if there was anything useful.

Thanks!

 

[Steve]

Has anyone else run into something like this?

Yes. There does appears to be something a bit "off" about the ZimaBoard and its monitor interface. There have been similar reports of exactly what you are describing, where the monitor's display does not come back on after having been powered down.

 

[Fuzzball]

Thanks Steve. I'm setting up an old Crucial 500GB Windows 10 SSD backup drive on the ZimaBoard right now that came from my laptop when I swapped it out with a new 2TB drive. So it's a clean Windows 10, just finishing up about 2 hours of Windows Updates since it's been 2.5 years since it was last awake.

I'll leave it running with no screen saver active tonight, and turn off the monitor when I go to bed to see if the same thing happens to a Windows machine.

 

[Fuzzball]

Running Windows 10 overnight with the monitor turned off, the Zimaboard video worked fine this morning after turning on the monitor. Maybe tonight I'll try it with a different DOS program running on-screen to see what happens.

 

[Steve]

Maybe tonight I'll try it with a different DOS program running on-screen to see what happens.

Yes! My guess would be that this is about "text mode" being MUCH less common and supported these days than any graphics mode. I'm frankly very glad that system's still have text mode at all... Which I suppose they only do since they also have BIOSes. But as we know, that's all going away with the move to pure UEFI systems.

 

[Fuzzball]

Last night I left it with Xtree Gold running. This morning it was sitting at the CasaOS main screen, so obviously it had rebooted at some point. The test wasn't perfect though because yesterday I moved the ZimaBoard out to the living room and plugged it into a cheap (video only) KVM. I was playing with it running on the 4k big screen to see how well it did 4k. What I learned is that my internet bandwidth isn't up to snuff for watching 4k videos. But it was operating the TV at 4k, so... there's that.

After putting Xtree on the screen I KVM'd away and left it that way overnight. There's no telling though what sort of signal/info the KVM provided back to the ZimaBoard. It's a little disappointing that it rebooted seemingly without cause though.

I'll move it back into the office soon and put it back on its 1080p single monitor to try again.

 

[CSPea]

Thank you for your experiments here Fuzzball.

I'm still using the mini Displayport connection on my Zimaboard (model 432) and I'm in a situation where I cannot leave the monitor running overnight.

It's maddening to return the following day (when the SpinRite scan has finished overnight) to turn on the monitor and see only a blank screen, and -as you say - to have no way (yet) to nudge or reawaken the ZimaBoard.

I see from the ZimaBoard FAQ page "Upgrade motherboard BIOS version" that the version has had at least one increment since I obtained my board (see my next paragraph), but I'd be reluctant to apply a BIOS upgrade to my otherwise trouble-free board unless I knew for sure it would fix this unwelcome behaviour.

The 'latest' BIOS version when I obtained my ZimaBoard was APLR1204G.N06, and I see the latest version offered now is APLR1208G.N06, however I haven't yet found anything like a 'change list' for the upgrade(s).

(I'm not on Discord, where I admit is probably where I'd find any discussion on the BIOS changes.)

Anyway .... hopefully we can find a workaround for this "Zimaboard going dark" glitch.

 

[CSPea]

.. snip ... hopefully we can find a workaround for this "Zimaboard going dark" glitch.

'Replying' to my own post above ...

Feeling a bit silly that I hadn't already scrutinised my BIOS options to look for any existing 'wake up' related options, and I have just spotted this one below, which might possibly allow the Zimaboard (or its display?) to be nudged out of that odd inactive state we referred to above.

The setting is seen under :
Advanced | Power Management Configuration |
and is called:
"Wake up By KB/Mouse"

It is disabled by default, and naturally I have now changed mine to enabled.

I will run a test soon - deliberately to have a SpinRite scan run to completion while my monitor is powered off ... and see if I can shake the board awake from its (probable) slumber. And I'll report back here.

A question to other Zimaboard users:
Has anyone else already tried changing this KB/Mouse BIOS setting to 'enabled' in an attempt to avoid this 'blackout' problem?

In other words, it'd be good to know in advance if my own test here will be futile?

 

[Steve]

I suspect that pertains to awakening the machine from a "standby" state. Advanced Power Management (APM) is able to turn the machine off or put it to sleep. But at point something needs to awaken it. Naturally, SpinRite cannot put the machine to sleep while it's using it.

 

[CSPea]

Thank you Steve. I see your point ... and perhaps this monitor blackout glitch is after all not related to any of the Zimaboard's power states!

If that is true then it would surely (rhetorically speaking) be a bug deserving of attention from the ZimaBoard developers?!?!

Perhaps I should stop prevaricating about joining Discord ... and get over to their channel and ask for their thoughts on this?!

 

[CSPea]

Continuing from above ...

My overnight test (running SpinRite to completion with my monitor switched off) succeeded, but only in the sense that it reproduced the 'blank' Displayport screen and an unresponsive Zimaboard.

It was therefore impossible for me to see the final SpinRite page.

Again I tried to 'wake' the ZimaBoard by pressing multiple keys on my keyboard, but the only key combination that produced a 'response' was CNTRL+ALT+DELETE ... which resulted, naturally enough, in a reboot.

In case it is relevant: The keyboard I am using is a Cherry DW 3000 wireless Keyboard+Mouse kit, with its 2.4GHz radio dongle plugged into my Zimaboard's USB port. (The USB port that is positioned beneath the RJ45 Ethernet socket.)

Evidently this wireless keyboard continues to work OK even during these unresponsive / Displayport episodes.

Finally for now, one further diagnostic detail is that - during one of these 'blackout' episodes - when I restore power to my monitor, the monitor's auto-sensing Displayport circuitry sees no signal at all coming from the Zimaboard's mini-Displayport. In other words, the Zimaboard is not even 'displaying' a black screen. Its Displayport is effectively disconnected.

I strongly suspect that - on one or more other Zimaboard discussion sites which I haven't visited - all these same symptoms will have been aired and grumbled about by others ... nevertheless I still hope the Zimaboard developers have listened, and that we might hopefully get this fixed in a future BIOS upgrade.

... unless perhaps the 'blackout' problem is hardware-based ... such as a Displayport chip 'feature', out of reach of any software tweaks?!?!

 

[CSPea]

Yet more bad news ... for those of us who may need to run SpinRite on the current marque of Zimaboards, while turning off their monitors ...

My experience so far with this Displayport blanking problem was that I had been restoring power to my monitor at a time well after SpinRite had ended its scan (as verified by the relevant SpinRite LOG files which had been reliably written and closed during the SpinRite session.)

However, I now discover (and I'm surely not the first!?) that the Zimaboard Displayport signal will go absent when I turn off my monitor at any time during a SpinRite scan!!!

In other words, this Displayport blackout is not a consequence of an extended period of static / unchanging screen content, as I had so far assumed (such as at the end of a SpinRite scan).

Instead, if the Zimaboard's connected monitor is turned off at all, its Displayport signal will disappear regardless of what is being rendered on its graphics interface! A pretty cra&#y situation IMO.

I could conduct even more tests ... when I can find some time ... for example does it matter which type of Displayport cable is used?

And will I see this same 'monitor off' problem while I'm running my favoured openSUSE Linux on this Zimaboard (i.e. in a graphics mode)?

Or is there such a thing as a Displayport hub that would persuade the Zimaboard that its monitor is always powered on?

Meantime, disappointing and awkward!

 

[Steve]

Perhaps I should stop prevaricating about joining Discord ... and get over to their channel and ask for their thoughts on this?!

FWIW, I had a very good experience with doing that. I joined their Discord to ask about whether simply providing a beefier 12vdc power supply would allow two large 3.5" SATA drives to be powered by their ZimaBoard. (The answer was "yes".) And they replied quickly.

 

[Steve]

However, I now discover (and I'm surely not the first!?) that the Zimaboard Displayport signal will go absent when I turn off my monitor at any time during a SpinRite scan!!!

I'll explore this, too. Again, my guess is that this is a consequence of SpinRite running in text mode which is less well supported than graphics mode. It MIGHT be that I could have SpinRite re-initialize the display for the user — even during a SpinRite run.

 

[CSPea]

Thank you Steve.

And meantime I can confirm that - as you have tentatively deduced - while I'm running Linux, the board's Displayport circuitry stays active even with my monitor turned off.

 

[CSPea]

FWIW, I had a very good experience with doing that. I joined their Discord to ask about whether simply providing a beefier 12vdc power supply would allow two large 3.5" SATA drives to be powered by their ZimaBoard. (The answer was "yes".) And they replied quickly.

Thank you Steve.
I will get onto Discord very soon

 

[PHolder]

could have SpinRite re-initialize the display for the user — even during a SpinRite run

Could you start with an experiment where the user presses a specific key, like 'D' for display or one of the function keys, and that attempts to kick the display port in the head and wake it up?

 

[CSPea]

Yes, I agree that could be a good option ... a discreetly incorporated, single-key-press option that ZimaBoard users could use if/when needed and which non-ZimaBoard owners could simply ignore.

Hopefully too (if the graphics can actually be nudged in this manner) this single keystroke ploy might also need a minimum of new code by Steve - and the smallest possible impact / detour on the final release!

 

[Steve]

Could you start with an experiment where the user presses a specific key, like 'D' for display or one of the function keys, and that attempts to kick the display port in the head and wake it up?

Over in our GitLab, this has been happening:

DarkwinX found that unplugging and replugging his monitor worked. But if he plugged his monitor into another system that was running in a graphics mode, then returned that monitor to the ZimaBoard in text mode, the display did not come back.

But then, as I suggested, he blindly entered the DOS command "mode 80" — THAT reinitialized everything and his monitor came back online.

So I replied:

Okay. So now we need to come up with some way for a user to ask SpinRite to reinitialize the system's video while SpinRite is running.

We could double-purpose both SHIFT keys at once so that it both toggles sound and also reinitializes the system's video. The only trouble for toggling sound is that it does blank and screen until the screen gets itself going again. So it's intrusive for simply toggling sound.

Or we could have the user hit the ESC key three times in a row... or anything else.

So all we really need, now, is something that user can do on the keyboard to signal to SpinRite that they need a monitor reinitialization.

 

[Fuzzball]

I would shy away from keys that already can be used to interrupt Spinrite. How about a Function key?

Is the intent to allow the user to reinitialize the video while Spinrite is actively processing a hard drive, without interrupting the drive processing?