Earlier quoted context omitted.
Is... this not how your WoL works? Hitting the NIC is equivalent to pressing the on button, boots the OS, etc. I've been using this for years to wake hosts at home when I'm abroad. It's invaluable.
For the sake of the argument, I think it's more of a shared capability of the motherboard _and_ the NIC, rather than the sole responsibility of the NIC. I wonder if that could be implemented solely by the motherboard. After all, it could supply a small amount of power to the NIC while shutdown and embed a minimal NIC driver to monitor incoming packets without the need for the NIC to do the monitoring itself.
How to programmatically find out if computer is on
141–150 of 197 posts
Re: How to programmatically find out if computer is on
#142I’d like to see the unit tests for the non-true return state.
Result is undefined if computer isn't on, so any value is OK, no tests necessary.
Re: How to programmatically find out if computer is on
#143I'm curious if there's any significance in number 0.63739 in this implementation double is_computer_on_fire(void) { return 0.63739; } https://github.com/haiku/haiku/blob/8f16317a5b6db5c672f33181...
Re: How to programmatically find out if computer is on
#144Earlier quoted context omitted.
I've often wondered why WOL is so poorly designed. WOL should be a function of the NIC, completely independent of the OS and capable of returning status codes even if the computer is "off".
Is... this not how your WoL works? Hitting the NIC is equivalent to pressing the on button, boots the OS, etc. I've been using this for years to wake hosts at home when I'm abroad. It's invaluable.
Re: How to programmatically find out if computer is on
#145While it is clearly a joke, it has a legitimate use as a syscall that does nothing so can be used to test the syscall process itself [1]. (Its cousin `is_computer_on_fire` is not a syscall.) [1] https://github.com/haiku/haiku/commit/ccaac177f64038c160de6f...
I was thinking the same thing, although in reverse: Imagine putting a few of these in as a joke and then you take it out and your parallelized code doesn't work anymore. Not sure how all that's handled on Haiku specifically.
Re: How to programmatically find out if computer is on
#146Re: How to programmatically find out if computer is on
#147Re: How to programmatically find out if computer is on
#148> is_computer_on() How does this relate to computer being in Halt state, which is quite valid state for servers (there could be even a dedicated Halt button)? Technically computer hardware is ON. I remember that in such state it shows a "carrot" prompt (>>>) from the SRE console. By the way, there is also HCF instruction (Halt and Catch Fire). https://en.wikipedia.org/wiki/Halt_and_Catch_Fire_(computing...
I admire for how you nerdsniped several other comments without anyone noticing the platform, or how "halt" would drop you into console monitor on said platform. My standing ovation to you :D (The platform is Alpha, right? Given the prompt and name for the console, though it was SRM, not SRE) :)
(Alpha) System Reference Manual:
https://en.wikipedia.org/wiki/System_Reference_Manual
Funny thing, for some historic reason, the system terminal attached to cabinet with those memorable Alpha Servers was of the monochrome lineage, but the phosphors color was orange. So the >>> prompt was unmistakably a carrot one! However it would rarely be seen, as bulk of the time the console would busily beep and boop with operator messages, as any respectful Alphas would be on 24/7/365 duty.
The only forced interruption I witnessed was when the attached storage controller froze. Literally. Someone left a window open in the server room, with -20C outdoors. So with all that circulation there was ICE accumulation on one side of storage controler cabinet. Apparently that put it beyond service temp range. Well, thawed it out - back to bizznizz, so to speak.
It that case, should've been is_system_iced() system call, it could've saved us the trip on such a freezing night. We would've just called HCF... briefly :)
Re: How to programmatically find out if computer is on
#149Earlier quoted context omitted.
Is... this not how your WoL works? Hitting the NIC is equivalent to pressing the on button, boots the OS, etc. I've been using this for years to wake hosts at home when I'm abroad. It's invaluable.
Now I'm almost curious if every PCI slot has a pin equivalent to the power button pin on the mainboard and also feed some basic background power to the cards even when turnt off. I doubt it actually is this simple though, the industry rarely chooses KISS.
https://en.wikipedia.org/wiki/PCI_Express#Pinout
The main difference is that WAKE# signal only restores power to the system but it does not change the system's power state, after using it the card needs to send an interrupt to the motherboard to properly wake it up. Power button does both things.
Re: How to programmatically find out if computer is on
#150Earlier quoted context omitted.
Is... this not how your WoL works? Hitting the NIC is equivalent to pressing the on button, boots the OS, etc. I've been using this for years to wake hosts at home when I'm abroad. It's invaluable.
Now I'm almost curious if every PCI slot has a pin equivalent to the power button pin on the mainboard and also feed some basic background power to the cards even when turnt off. I doubt it actually is this simple though, the industry rarely chooses KISS.
however, an ATX PSU supplies only 5V (5Vsb) when the system is off (S5) which is not available on the PCIe connector which only has 12V and 3.3V. so when the system is off (S5), the PCIe cards are unpowered and thus cannot turn the system on.
but if you mean off in the Microsoft "Modern Standby" (S0i) then yes, the PCIe cards are powered and the WAKE# pin can "turn on" the system.