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

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 Bondmailto:xxxxx
Sent: ?8/?11/?2014 4:54 PM
To: Windows System Software Devs Interest Listmailto:xxxxx
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 sharmamailto:xxxxx
Sent: ?Monday?, ?August? ?11?, ?2014 ?2?:?09? ?PM
To: Windows System Software Devs Interest Listmailto:xxxxx

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</mailto:xxxxx></mailto:xxxxx></mailto:xxxxx></mailto:xxxxx>