A couple of years ago, I decided that I should track down all the entries in DEVICE_CAPABILITIES and explain where they come from, at least for PCI and/or ACPI devices. (USB is still somewhat mysterious to me, as I’ve never written a full driver for a USB device.) At the time I was trying to help one of the ARM vendors bring up their chip running Windows RT and they were highly confused in this area. My plan was to put the result on Doron’s blog.
The problem was that, as I started collecting the material for the topic, I realized that it was so vastly complex that there wasn’t an easy way to explain it. The topic you’re interested in came down to statements like this:
“If the OS, which is to say the ACPI driver in conjunction with the bus driver, can’t convince themselves that the wake signals will actually be delivered, then it will set SystemWake to PowerSystemWorking and DeviceWake to PowerDeviceD0 to indicate that the device shouldn’t even be expected to trigger a wake signal. If the miniport reports that it supports wake signals, NDIS will send IRP_MN_WAIT_WAKE through the stack and arm the device for wake when the miniport is started. (And even that is truly historical behavior, not what we’d do if we were starting fresh in this area.)”
Of course, that just begs the question “what does it take to convince the ACPI and PCI drivers that wake signals will be delivered?” That’s where it became impossible to contain this in a blog post. To properly cover the topic, I’d have to write a book about ACPI and the way it interacts with Windows, and that book would be a huge time suck and a commercial failure.
There are about five different ways within ACPI (which is a fully general language, probably Turing Complete) to express the concept of wake signals. Sometimes they come through “General Purpose Event” pins, which are enumerated through the _GPE part of the namespace. Sometimes they come through an “Embedded Controller” and are surfaced more or less as device interrupts which then reflect back into ACPI through the control methods under the embedded controller device, surfaced as a “Notify” statement (and sometimes BIOS guys get the “Notify (devicepath, 2)” statement wrong and use a “Notify (devicepath, 1)” so there’s special case code in the OS to try to figure that out and deal with it. Sometimes they arrive as GPIO interrupts, described as a secondary interrupt resource on the devices that might trigger the signal. Sometimes they come in through a third party driver for completely custom logic on the board which then invokes a control method which then does the “Notify”.
All of this is modulated by a lot of other objects in the ACPI namespace. Some of those say things like “wake will be enabled when this power rail is turned on, and you should look for the list of devices which will depend on this power rail.” Others say things like “the wake signal can only be triggered through these S-states, and these D-states,” and there are an oddly large number of variations on the way that this is expressed.
There’s more to the ACPI topic, but I’m going to stop here.
All of this is bent around the bus driver, too. For instance, the PCI bus driver has two very distinct modes, one where the BIOS keeps control of PCI Express and one where it gives that over to the OS. When it gives that over to the OS, we can be certain that wake signals will actually work when the machine is in S0, and so that is reflected in DEVICE_CAPABILITIES. When it keeps it, there really isn’t a machine in the world where the wake signals work in S0, so we leave that as DevicePowerD0.
So the short answer to your question, Sathish, is that your problem is with your BIOS or your motherboard. Either the motherboard itself wasn’t designed to actually deliver wake signals and the BIOS is properly reflecting that to the OS, or the BIOS vendor and/or OEM decided not to expose this feature of the motherboard because they didn’t feel like testing it or they didn’t feel that the market required it, or the BIOS is simply busted.
Try a different machine. For these purposes, I suggest that you contact Intel and get a “Software Development Platform” or “SDP” machine from them. These are machines where every possible configuration and option is exposed and you get to turn each on and off separately, using a single machine to test lots of situations. We work with them to ensure that the BIOSes in these machines more or less work. Other machines tend to have these features turned off, either intentionally or accidentally.
- Jake Oshins
(former ACPI guy)
Windows Kernel Team
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Jeffrey Tippet
Sent: Thursday, May 23, 2013 8:22 PM
To: Windows System Software Devs Interest List
Subject: RE: RE:[ntdev] DEVICE_CAPABILITIES values for Ethernet device
I’m not sure myself - the PCI logic is quite complex, since it depends on ACPI and a large amount of compatibility code in the PCI bus driver. Maybe somebody else would know?
NTDEV is sponsored by OSR
OSR is HIRING!! See http://www.osr.com/careers
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer