I am working with an old piece of hardware on a custom motherboard. The IO ports and the interrupt are hardwired and reserved in the BIOS. If I use a LogConfig parameter in my INX file, the driver fails to get any resources assigned to it. That is, the Preparehardware callback is never invoked and in the Setup log it indicates the LogConfig section will be ignored. If I remove the LogConfig section from my INX file, I get a PrepareHardware callback with no resources but I am able to simply access the IO ports via the READ/WRITE_PORT_UCHAR() etc. routines. I can read/write them without issue and get correct data back. But the interrupt does not work. If I create an interrupt object via a successful call to WdfInterruptCreate(), my InterruptEnable callback is never invoked nor is my registered ISR ever called. So I tried to call WdfInterruptEnable() but still no interrupts.
I am guessing that KMDF is just not passing the interrupts along to my registered ISR callback? I considered trying to call the IoReportResourceForDetection() but other threads have indicated problems with this within a KMDF driver.
Does anyone have any suggestions for this very specific scenario?
Hi Don, thank you for responding. I have done the same as well. And I should clarify - this exact driver/INX works fine on a “normal” system, i.e. the resources are assigned as dictated by the LogConfig param. But on the client’s system, with the reserved-in-BIOS IRQ, the usage of the LogConfig param fails to be effective - nothing is assigned. Therefore I’m searching for a way of manually connecting the interrupt at runtime vs install time.
Ok, after some more experimenting I got the interrupt working within my KMDF driver but it uses the legacy approach to connecting. That is, it reports the resources via a call to IoReportResourceUsage() then calls the HAL routine HalGetInterruptVector() to retrieve the pieces of data about the interrupt and finally calls IoConnectInterrupt() to establish everything.
So the key question becomes, is this a viable and future-supported way to go about connecting to this reserved interrupt? I have not found an alternate way to get the interrupt to fire within the KMDF ISR and this approach does seem to work without issue, at least currently.
is this a viable and future-supported way to go about connecting to this reserved interrupt
In a word: No.
I’m surprised that _IoReportResourceUsage _and HalGetInterruptVector still work at all. So, if I were you I’d just count myself lucky.
You’re “subverting” the OS to do what you want/need to do. I don’t mean that necessarily in a negative way… You being very clever in how you’re doing it (bravo for that), but no matter how you look at it, that’s what you’re doing. I assume you’re not doing this for nefarious purposes, but still… you’re “working around” what the OS wants you to do.
I get it. Sometimes you have to do that. But when you go that route, I think the best you’re going to be able to hope for is “It works on all the machines and all the versions of Windows I’ve tested it on so far” – particularly given that we (all, jointly) don’t know why these resources are apparently being withheld from your driver in the first place.
Thanks for weighing in, Peter. I can assure you the purpose is not nefarious. I simply have a customer who has a legacy hardware device and a custom PC which hosts it and they have a (completely reasonable) requirement to run a modern OS. I totally get that ISA hardware in general is on life support in some regard, but the LogConfig resource approach has worked thus far. The unexpected wrinkle this time around was their motherboard’s BIOS having the IRQ which this device uses marked as “Reserved”. It seems understandable, then, that Windows may balk at any LogConfig entry which references this same resource.
Furthermore, you are quite right that I do feel lucky to have found a workaround. And given the circumstances I don’t expect any official blessing of this technique, but I was slightly hopeful that a Microsoft dev might be able to comment here and at least give a nod that “if it works today, it should keep working for the foreseeable future”. Or, if it’s truly my lucky day, advise some cleaner way to do this.
@“Jason_T.” Who’s marking the interrupt as “reserved”? Who’s using it?
Can you tell? Look in the Registry? See it in Device Manager?
Did the system vendor just screw-up the BIOS? If I were you, I hink I’d be tempted to dump the ACPI tables and see what I could deduce, sort of as a last resort.
I was slightly hopeful that a Microsoft dev might…
Even the Dev Owner couldn’t answer your question or give you that guarantee, I’m afraid. The interface is deprecated AND the real answer lies with your systems configuration.
If we can figure out why it’s “reserved” we can probably figure out how to get it to give up the IRQ for your LogConfig.
My understanding of the history is that for over 20 years a legacy driver and OS have been running this device. With the old driver, the IRQ was just a reg value that was directly fed into HalGetInterruptVector/IoConnectInterrupt. I wasn’t involved with the motherboard manufacturer, but I’d say it certainly wasn’t a screw-up, or at least not an accident, but rather somebody seemed to think that by reserving this IRQ in the BIOS they were ensuring that it would be available for this particular driver/device to use.
As well, an ACPI dump does not show this IRQ at all so that leads me to believe there is nothing that can be done in software to “unreserve” it. In any case, I don’t want to take any more of your time on this. It does appear to be working, and if that changes in the future (due to an OS udpate) we’ll likely just need to have a hardware change made to the BIOS to resolve it.