3

I have some unique hardware where the onboard NIC's WoL output is wired to cause a system reset, I believe by NMI, instead of causing a power-on.

It was made like this, I think, to facilitate remote reboot without incurring the cost of a switched PDU or IPMI.

But it looks like the WoL capability is suppressed once an OS loads. I noticed that memtest 86 doesn't surpress it, but linux does. I tried ethtool -s wol a/u/m/b/a/g/s

Am I on the right track? How can I get WoL to stay awake while the OS is running?

/ # lspci -nn | grep -i net
01:00.0 Ethernet controller [0200]: Intel Corporation 82574L Gigabit Network Connection [8086:10d3]
/ # ethtool -i 
ethtool -i  eth0
driver: e1000e
version: 2.3.2-k
firmware-version: 2.1-0
bus-info: 0000:01:00.0
/ # uname -a
Linux (none) 3.19.0 #1 SMP Mon Oct 19 15:48:25 CDT 2015 x86_64 GNU/Linux
/ #

Target Kernels are latest CentOS, Ubuntu, Debian, Windows, Proxmox(Debian) and VMware.

My hope was that WoL would function 'outside' of the OS. I would accept that the OS might be able to disable it if it wanted to, but that by default, it would not, and that if WoL was simply enabled in bios and supported by hardware, it would work consistently no matter what the OS was doing.

Improve this question
3
  • 1
    That might require reading the NIC driver source code to see if it's even possible to do that with that particular NIC. So, what's the lspci -nn line of that NIC? The driver used by the NIC can be identified with ethtool -i. You might also identify the version of the Linux kernel you're using or planning to use in this hardware. – telcoM Feb 20 at 15:20
  • @telcoM I've added driver.chipset info. I'm hoping driver is unimportant because I'd ideally like the solution to be independent from OS in use. Or I'd like to understand how and why OSes interrupt WoL functionality while they are running. It would make sense of course that WoL typically is moot if the OS is already running. But I don't know why the PHY would stop listening just because the OS was up, and even more perplexing is that when the "OS" memtest86 is "running", it doesn't stop WoL from working. I almost think I need to pursue the schematic/diagram/spec of the Intel 82574L chip – Billy C. Feb 21 at 18:29
  • "WoL output is wired to cause a system reset, I believe by NMI (...) it looks like the WoL capability is suppressed": you don't seem to be very positive about WoL being wired to NMI. It would be good to be sure how it is wired exactly. Can you add in your question how you figured out memtest86 allows this to work whereas Linux doesn't? What makes you think this is WoL that is not working, and not the NMI that is caught by its interrupt handler? The number of NMI interrupts is not incrementing when the card receives network traffic? – xhienne Feb 22 at 11:22
1

Intel seems to currently want you to register in order to see the NIC chip datasheets, but Google found the 82574 family datasheet here: https://docs.rs-online.com/96e8/0900766b81384733.pdf

As far as I could determine, the datasheet does not actually say whether or not the NIC can actually transmit & receive normally when it is waiting for a Wake-on-LAN packet. But the datasheet talks about applying filters to incoming packets - perhaps those filters interfere with normal received traffic?

My first guess would be that the exact time the WoL functionality gets interrupted is either when the PCI(e) bus is reset, or when the NIC driver is loaded. The fact that memtest86 does not stop WoL would suggest that it might be the latter. If so, then you have one (possibly unhelpful) answer - simply block the NIC driver from loading and you'll have your WoL-as-reset functionality... but then you'll need another NIC if the system also needs network connectivity :-(

The Linux e1000e driver also seems to do the actual enabling of the WoL functionality only when the driver is shutting down. To me, this also suggests the WoL being enabled probably interferes with the normal functionality of the NIC somehow.

Improve this answer
3
  • excellent. Thank you for discovering this! So I guess next I need to test customizing the driver to turn on wol at driver startup not at driver shutdown, and 'see what breaks'. This hardware was used before and I'm pretty sure WoL was used to reboot locked up systems. I found some documenation that referred to it as "Reboot on Lan" on this type of mobo, though it didn't say more than that. This was open-compute hardware in use by some large company for a very custom use case. Custom to the point it's got NO video output whatsoever and a non 1/2/3/4u case. more like a tray. – Billy C. Feb 24 at 12:57
  • If it's got no video output, then see if it's got any serial ports. Linux can work well with a console on a serial port. You might also want to contact the maintainer(s) of the e1000e driver: you'll find their email addresses in the MAINTAINERS file in any Linux kernel source package (won't list them here for anti-spam reasons). They just might be able to give you the exact information you'll need. – telcoM Feb 24 at 13:18
  • We can add a pcie card to debug things. and I use netconsole during OS loads. No serial port either. at least there's no obvious headers for it. I haven't searched with an osciliscope on every exposed pin but it doesn't look likely. linux shows ttyS0 through S3 in /dev/though, but I think those are always present. Good idea on the maintainers. Will report back what I find out. – Billy C. Feb 25 at 1:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.