Windows System Software -- Consulting, Training, Development -- Unique Expertise, Guaranteed Results

Before Posting...
Please check out the Community Guidelines in the Announcements and Administration Category.

RE: Re: [ntdev] is it possible to know if a virtual address is unmapped or mapped at any moment?

Doron_HolanDoron_Holan Member - All Emails Posts: 10,435
I think that for number 2 you would clear the child isr pointer synchronized with the interrupt spin lock, interlocked exchange is not sufficient if the isr is running while you are trying to clear it

d

Bent from my phone
________________________________
From: Marion Bond
Sent: ?8/?11/?2014 4:54 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: [ntdev] is it possible to know if a virtual address is unmapped or mapped at any moment?

Your basic problem boils down to one of state sync between your parent and children. The suggestions here have been mostly about restructuring your approach to avoid the need for the sync (the best kind of synchronization is none needed) rather than about how to fix your problem with this design, but here are my suggestions for you:


1.
When your parent IRS detects which child caused the interrupt, you have an inherent race condition. This is caused by the hardware design, but you can reduce its effect in software. Always call all of the child ISRs and have each check its own register and status bit. You can still 'loose? interrupts, but if the HW will re-interrupt you will be okay
2.
When a child goes away, make sure that you remove the pointer to the child?s ISR in a manor that syncs with the parent ISR. In practice this means an InterlockedExchange call. This will prevent the parent from calling into a shutdown or otherwise inactive child



Sent from Surface Pro

From: jayanth sharma
Sent: ?Monday?, ?August? ?11?, ?2014 ?2?:?09? ?PM
To: Windows System Software Devs Interest List

I am not handling power transitions related stuff because my client requested me not to. The end system is never supposed to go to sleep or hibernate and hence there is no need to handle the sleep and wake up functionality in my driver.


It also makes sense (as already noted) to combine all functionality into a single binary. Present PDOs as raw devices (with an appropriate so called null INF).


This is prohibitive for me because we are already at the deadline of the project. This looks like a huge coding rework to me.

So do i have any chance of making my driver any more stable , if i enable the interrupts for the child devices and map the memory for child devices in the parent driver? I think this is really what i can afford at the most at this stage.

If this doesn't help , then i am in to biiiiig puddle of mess.


Would like to conclude this thread and stop bugging all of you by dragging this discussion further

.
J.S.R.Sarma.
9916109893.


On Mon, Aug 11, 2014 at 10:32 PM, > wrote:
Also, don't bother with the BAR mapping (MmMapIoSpace) in child devices. Have the parent map it at once during startup, and hand the base virtual addresses to the child devices.

It also makes sense (as already noted) to combine all functionality into a single binary. Present PDOs as raw devices (with an appropriate so called null INF).

---
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

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

--- NTDEV is sponsored by OSR Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev 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

---
NTDEV is sponsored by OSR

Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev

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
d
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Upcoming OSR Seminars
Developing Minifilters 29 July 2019 OSR Seminar Space
Writing WDF Drivers 23 Sept 2019 OSR Seminar Space
Kernel Debugging 21 Oct 2019 OSR Seminar Space
Internals & Software Drivers 18 Nov 2019 Dulles, VA