Driver Problems? Questions? Issues?
Put OSR's experience to work for you! Contact us for assistance with:
  • Creating the right design for your requirements
  • Reviewing your existing driver code
  • Analyzing driver reliability/performance issues
  • Custom training mixed with consulting and focused directly on your specific areas of interest/concern.
Check us out. OSR, the Windows driver experts.

Monthly Seminars at OSR Headquarters

East Coast USA
Windows Internals and SW Drivers, Dulles (Sterling) VA, 13 November 2017

Kernel Debugging & Crash Analysis for Windows, Nashua (Amherst) NH, 4 December 2017

Writing WDF Drivers I: Core Concepts, Nashua (Amherst) NH, 8 January 2018

WDF Drivers II: Advanced Implementation Techniques, Nashua (Amherst) NH, 15 January 2018


Go Back   OSR Online Lists > ntdev
Welcome, Guest
You must login to post to this list
  Message 1 of 34  
18 May 17 12:38
PBD
xxxxxx@winsystems.com
Join Date: 03 May 2010
Posts To This List: 71
Holding off ISR Execution

I have the following code where I buffer some packets that are to be transferred in the ISR. I have an issue where the ISR occurs between when the message data is buffered and the buffer pointers are updated. Is there any way to hold off the ISR execution while a few instructions are completed? else if ((ReadReg(pcmcanDevContext, channel, SJA1000_IER) & IRQ_TI) && // irq enabled (pcmcanDevContext->fXmitBufferFull[channel - 1] == WdfFalse)) // space in buffer { // place request in buffer for processing when irq occurs pcmcanDevContext->xmitBuffer[channel - 1][pcmcanDevContext->xmitInPtr[channel-1]].FrameInfo = ((rwDatagramParams->type << 6) & (SJA1000_FI_FF | SJA1000_FI_RTR)) | (rwDatagramParams->length & SJA1000_FI_DLC); // tx id + data pcmcanDevContext->xmitBuffer[channel - 1][pcmcanDevContext-xmitInPtr[channel - 1]].ID.EFF_ID[0] = (UCHAR)(rwDatagramParams->id >> 21) & 0xff; pcmcanDevContext->xmitBuffer[channel - 1][pcmcanDevContext->xmitInPtr[channel - 1]].ID.EFF_ID[1] = (UCHAR)(rwDatagramParams->id >> 13) & 0xff; pcmcanDevContext->xmitBuffer[channel - 1][pcmcanDevContext->xmitInPtr[channel - 1]].ID.EFF_ID[2] = (UCHAR)(rwDatagramParams->id >> 5) & 0xff; pcmcanDevContext->xmitBuffer[channel - 1][pcmcanDevContext->xmitInPtr[channel - 1]].ID.EFF_ID[3] = (UCHAR)(rwDatagramParams->id << 3) & 0xf8; for (UINT8 i = 0; i < rwDatagramParams->length; i++) pcmcanDevContext->xmitBuffer[channel - 1][pcmcanDevContext->xmitInPtr[channel - 1]].Data[i] = (UCHAR)rwDatagramParams->msg[i]; ----> interrupt occurs here // increment xmit input pointer pcmcanDevContext->xmitInPtr[channel - 1]++; // reset if at end if (pcmcanDevContext->xmitInPtr[channel - 1] == XMIT_BUFFER_SIZE) pcmcanDevContext->xmitInPtr[channel - 1] = 0; // clear empty flag pcmcanDevContext->fXmitBufferEmpty[channel - 1] = WdfFalse; // set full flag if necessary if (pcmcanDevContext->xmitInPtr[channel - 1] == pcmcanDevContext->xmitOutPtr[channel - 1]) pcmcanDevContext->fXmitBufferFull[channel - 1] = WdfTrue; ----> would like to delay ISR processing until here }
  Message 2 of 34  
18 May 17 12:43
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

Look at KeSynchronizeExecution or KeRaiseIrql .
  Message 3 of 34  
18 May 17 13:00
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

If you decide to use KeRaiseIrql you need to call it on each CPU for example from a DPC scheduled by KeGenericCallDpc , this routine is not documented but you can google for its usage examples. I presume that for some reasons you can't modify a driver that registers ISR routine .
  Message 4 of 34  
18 May 17 13:01
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4019
Holding off ISR Execution

KeRaiseIrql is the wrong answer. KeSynchronizeExecution or KeAcquireInterruptSpinLock will do what you want. Mark Roddy On Thu, May 18, 2017 at 12:44 PM, <xxxxx@hotmail.com> wrote: > Look at KeSynchronizeExecution or KeRaiseIrql . > > --- > NTDEV is sponsored by OSR > > Visit the list online at: <http://www.osronline.com/ > showlists.cfm?list=ntdev> > > MONTHLY seminars on crash dump analysis, WDF, Windows internals and > software drivers! <...excess quoted lines suppressed...> --
  Message 5 of 34  
18 May 17 13:05
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> KeRaiseIrql is the wrong answer. </QUOTE> It is a right answer if you know how to do this on each CPU. KeGenericCallDpc does the trick.
  Message 6 of 34  
18 May 17 13:18
PBD
xxxxxx@winsystems.com
Join Date: 03 May 2010
Posts To This List: 71
Holding off ISR Execution

Can KeAcquireInterruptSpinLock be used from within an IoDeviceControl function?
  Message 7 of 34  
18 May 17 13:26
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> Can KeAcquireInterruptSpinLock be used from within an IoDeviceControl function? </QUOTE> It can be called anywhere if IRQL is less or equal to ISR/Interrupt IRQL.
  Message 8 of 34  
18 May 17 13:32
PBD
xxxxxx@winsystems.com
Join Date: 03 May 2010
Posts To This List: 71
Holding off ISR Execution

Thanks for the assistance. If I obtain the interrupt lock and release it, will I miss an interrupt that could occur while locked or will it be delayed until I release the lock?
  Message 9 of 34  
18 May 17 13:37
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> Thanks for the assistance. If I obtain the interrupt lock and release it, will I miss an interrupt that could occur while locked or will it be delayed until I release the lock? </QUOTE> Delayed. Either APIC keeps it and triggers as soon as it is enabled OR the system holds another CPU in a loop until a spinlock released.
  Message 10 of 34  
18 May 17 14:10
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4019
Holding off ISR Execution

Ok, seriously, this is a forum for providing sensible advice on how to do things. That is a ridiculous way to synchronize with your device isr. It remains the wrong answer. Corralling the cpus is the right answer for some problems, not for "how do I keep this data structure coherent with my isr?". Mark Roddy On Thu, May 18, 2017 at 1:05 PM, <xxxxx@hotmail.com> wrote: > <QUOTE> > KeRaiseIrql is the wrong answer. > </QUOTE> > > It is a right answer if you know how to do this on each CPU. > KeGenericCallDpc does the trick. > > --- > NTDEV is sponsored by OSR > <...excess quoted lines suppressed...> --
  Message 11 of 34  
18 May 17 14:13
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4019
Holding off ISR Execution

No you aren't going to miss an interrupt. But of course you are delaying your interrupt processing, and that can have consequences. Mark Roddy On Thu, May 18, 2017 at 1:32 PM, <xxxxx@winsystems.com> wrote: > Thanks for the assistance. If I obtain the interrupt lock and release it, > will I miss an interrupt that could occur while locked or will it be > delayed until I release the lock? > > --- > NTDEV is sponsored by OSR > > Visit the list online at: <http://www.osronline.com/ > showlists.cfm?list=ntdev> > <...excess quoted lines suppressed...> --
  Message 12 of 34  
18 May 17 14:22
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> It remains the wrong answer. </QUOTE> LOL. Keep trying.
  Message 13 of 34  
18 May 17 15:06
PBD
xxxxxx@winsystems.com
Join Date: 03 May 2010
Posts To This List: 71
Holding off ISR Execution

Everybody play nice. The interrupt spin lock fixed my problem. Thanks. The small delay on the interrupt service shouldn't be a problem.
  Message 14 of 34  
18 May 17 15:33
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4019
Holding off ISR Execution

If you insist. Do you seriously think that "corral all the processors at DIRQL" is a good way to serialize access to data between some arbitrary thread and an isr? Mark Roddy On Thu, May 18, 2017 at 2:22 PM, <xxxxx@hotmail.com> wrote: > <QUOTE> > It remains the wrong answer. > </QUOTE> > > LOL. Keep trying. > > > > > --- <...excess quoted lines suppressed...> --
  Message 15 of 34  
18 May 17 15:40
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> Do you seriously think that "corral all the processors at DIRQL" is a good way to serialize access to data between some arbitrary thread and an isr? </QUOTE> No. But it solves the task if nothing else available, e.g. ISR is registered by a third party driver.
  Message 16 of 34  
18 May 17 18:44
ntdev member 172838
xxxxxx@outlook.com
Join Date:
Posts To This List: 28
Holding off ISR Execution

>this routine is not documented but you can google for its usage examples. Great idea ! I can’t imagine a dev making that kind of proposition in a professional environment. He would be fired. You are fired Slava. J. S.
  Message 17 of 34  
18 May 17 19:07
ntdev member 172838
xxxxxx@outlook.com
Join Date:
Posts To This List: 28
Holding off ISR Execution

----> would like to delay ISR processing until here Well, you need the interrupt lock because : 1. Either you write to iospace (device register) to ask the device to stop interrupting and you must acquire the interrupt lock to do this. 2. Or, you simply acquire the interrupt lock just to be sure the Isr doesn’t compete with you. KMDF drivers use WdfInterruptAcquireLock. J. S.
  Message 18 of 34  
19 May 17 00:04
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> I can?t imagine a dev making that kind of proposition in a professional environment. He would be fired. You are fired Slava. </QUOTE> You have a bad imagination or never worked in a professional environment. This routine is used in many products. BTW you will have to fire Alex Ionescu who used this routine in the SimpleVisor hypervisor.
  Message 19 of 34  
19 May 17 09:32
Mark Roddy
xxxxxx@gmail.com
Join Date: 25 Feb 2000
Posts To This List: 4019
Holding off ISR Execution

It seems that this particular dead horse sadly deserves more beatings. It would have simpler to just say "oops. my bad" instead, but who does that? Instead almost all of us just keep maintaining that our position is the correct one no matter how glaringly wrong it was. Mark Roddy On Fri, May 19, 2017 at 12:05 AM, <xxxxx@hotmail.com> wrote: > <QUOTE> > I can?t imagine a dev making that kind of proposition in a professional > environment. He would be fired. > > You are fired Slava. > </QUOTE> > > You have a bad imagination or never worked in a professional environment. > This routine is used in many products. > <...excess quoted lines suppressed...> --
  Message 20 of 34  
19 May 17 09:43
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

Yes. Just believe me that raising IRQL on all CPUs is a solution for some cases.
  Message 21 of 34  
19 May 17 12:00
Shane Corbin
xxxxxx@hotmail.com
Join Date: 14 Jun 2007
Posts To This List: 199
Holding off ISR Execution

<QUOTE> Just believe me that raising IRQL on all CPUs is a solution for some cases. </QUOTE> Now that can't be argued. However, "some cases" is very clearly not THIS case. As Mr. Roddy pointed out, this forum is a great resource for sensible advice. It'd be unfortunate for future readers to come along and see this as the first response and apply your advice without understanding the "normal" pattern. Your proposed solution should be amended to point out that although feasible, it's a heavy handed approach that should only be considered in specific scenarios. The "normal" pattern (or idiom) for synchronizing with your ISR would be exactly what Mr. Roddy proposed.
  Message 22 of 34  
19 May 17 12:24
ntdev member 172858
xxxxxx@outlook.com
Join Date:
Posts To This List: 27
Holding off ISR Execution

Yes a device driver writer should be focused on the device, not on the machine or on the CPU. W. N.
  Message 23 of 34  
19 May 17 12:33
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> it's a heavy handed approach that should only be considered in specific scenarios. </QUOTE> These scenarios have been outlined( e.g. third party ISR) with KeSynchronizeExecution as the first solution . Somebody is just too impatient to deliver preaching on "sensible advice". The problem with Mr Roddy's "sensible advice" that he ruled out IRQL raising marking it as "the wrong".
  Message 24 of 34  
19 May 17 13:04
ntdev member 172838
xxxxxx@outlook.com
Join Date:
Posts To This List: 28
Holding off ISR Execution

>Yes. Just believe me that raising IRQL on all CPUs is a solution for some cases. Isn’t that called a bugcheck ? And how do you achieve this ? With an undocumented API used for hotpatching ? Hotpatching raises the IRQL to the highest level to prevent anyone from running on the computer. This masks timer interrupts as well and you clearly behave like you were the OS and not a device driver. If every driver behaves like this, would the clock be reliable ? J. S.
  Message 25 of 34  
19 May 17 13:39
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> Isn?t that called a bugcheck ? </QUOTE> Google what "bugcheck" stands for before using it. <QUOTE> And how do you achieve this ? With an undocumented API used for hotpatching ? ... Hotpatching raises the IRQL to the highest level ... </QUOTE> I would advise you to take some introductory courses on NT design ( look for OSR ones ) as DPC is not a hotpatching technology and raising IRQL doesn't necessary disables all interrupts. <QUOTE> If every driver behaves like this, would the clock be reliable ? </QUOTE> Firs of all there was no suggestion to use it for every driver. Second, I would advise you to take some general OS design courses( CS162 e.g.). The timer interrupt in modern OS is used mainly for threads scheduling and not for time keeping, except the case when a reliable time source is missing. The time keeping on x86 is done by RTC hardware that doesn't require OS to process timer interrupt. Modern kernels use dynamic timers to not waste energy to process timer interrupts, they schedule the timer interrupt to be fired when the current thread need to be rescheduled. Third, Windows is not an RT system to provide a reliable time keeping through the timer interrupt.
  Message 26 of 34  
19 May 17 14:09
ntdev member 172838
xxxxxx@outlook.com
Join Date:
Posts To This List: 28
Holding off ISR Execution

You can’t blame peoples because they don’t know about undocumented things but you can be blamed for breaking a machine with undocumented things. You may be an OS expert but, just imagine, on a 128 CPUs machine, you would hold 128 CPUS just to write somewhere while holding one CPU would be sufficient. Isn’t that ridiculous for an OS expert ? J. S.
  Message 27 of 34  
19 May 17 14:14
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

<QUOTE> You can?t blame peoples because they don?t know about undocumented things </QUOTE> Nobody blames you. BTW, DPC and IRQL are documented. <QUOTE> You may be an OS expert but, just imagine, on a 128 CPUs machine, you would hold 128 CPUS just to write somewhere while holding one CPU would be sufficient. Isn?t that ridiculous for an OS expert ? </QUOTE> Again, this was not suggested as a universal solution.
  Message 28 of 34  
19 May 17 14:26
ntdev member 172858
xxxxxx@outlook.com
Join Date:
Posts To This List: 27
Holding off ISR Execution

<quote> BTW, DPC and IRQL are documented. </quote> But KeGenericCallDpc is not so give up, this is a bad idea. You have to admit when you are wrong that … you are wrong. It is not a shame. Just say « sorry guys, forget about that… ». W. N.
  Message 29 of 34  
19 May 17 14:33
Slava Imameev
xxxxxx@hotmail.com
Join Date: 13 Sep 2013
Posts To This List: 207
Holding off ISR Execution

I am not wrong. You are extending the cases I outlined to every design which is your problem. If you have a problem with KeGenericCallDpc or any undocumented function do not use it, but stop preaching. People have used undocumented APIs for decades. Some of these APIs have been eventually documented by MS.
  Message 30 of 34  
19 May 17 14:47
ntdev member 172838
xxxxxx@outlook.com
Join Date:
Posts To This List: 28
Holding off ISR Execution

I misunderstood an article that explains how hotpatching « locks » the machine with KeGenericCallDpc. So hotpatching raises the IRQL to CLOCK_INTERRUPT but KeGenericCallDpc does not. Now it’s clear. J. S.
  Message 31 of 34  
19 May 17 15:38
ntdev member 172858
xxxxxx@outlook.com
Join Date:
Posts To This List: 27
Holding off ISR Execution

>So hotpatching raises the IRQL to CLOCK_INTERRUPT… You mean CLOCK_IRQL, don’t you ? You are tired. Try to have a sleep. W. N.
  Message 32 of 34  
19 May 17 17:31
ntdev member 172838
xxxxxx@outlook.com
Join Date:
Posts To This List: 28
Holding off ISR Execution

You don't need to go undocumented to achieve the goal. "Each processor in a multiprocessor system has its own DPC queue. KeSetTargetProcessorDpcEx specifies which processor's queue the system should use when the driver calls the KeInsertQueueDpc or IoRequestDpc routine to queue a DPC to be run later." https://msdn.microsoft.com/en-us/library/windows/hardware/ff553279(v=vs.85).aspx J. S.
  Message 33 of 34  
19 May 17 18:53
Peter Viscarola (OSR)
xxxxxx@osr.com
Join Date:
Posts To This List: 5949
List Moderator
Holding off ISR Execution

Wow... what is WRONG with people these days? Is there some virus going around that causes people to make stupid statements and then stand by them. Mr. Imameev... cut it out. Your solution is viable for special purposes, but it's a tremendously bad answer to the OP. You know that. I know that, Mr Roddy knows that. Shit, poor old Doctor Joe who never comes so here anymore even would agree with that.. So STFU. Let it rest. We get that you understand how Windows works. Everyone else... please just let it drop. Peter OSR @OSRDrivers
  Message 34 of 34  
21 May 17 12:30
anton bassov
xxxxxx@hotmail.com
Join Date: 16 Jul 2006
Posts To This List: 4399
Holding off ISR Execution

<quote> Mr. Imameev... cut it out. Your solution is viable for special purposes, but it's a tremendously bad answer to the OP. You know that. I know that, Mr Roddy knows that. Shit, poor old Doctor Joe who never comes so here anymore even would agree with that.. </quote> <ironical (or, probably,even semi-trolling)mode> To be honest,I am kind of frustrated - I would normally expect lots of shouting in capitals, multiple requests to Mr. Imameev to disclose the name of his company so that its products could be avoided, and many other "exciting" things that you would normally see on a thread like that. What happened to "TELL US YOUR NAME ...(etc)" folks??? If things keep on going this way.....well, I am afraid those who plan to use Bo Branten's Filedisk (or whatever it is called) may be left unadvised of possible legal ramifications of such a bold move... </ironical (or, probably,even semi-trolling)mode> Anton Bassov
Posting Rules  
You may not post new threads
You may not post replies
You may not post attachments
You must login to OSR Online AND be a member of the ntdev list to be able to post.

All times are GMT -5. The time now is 04:20.


Copyright ©2015, OSR Open Systems Resources, Inc.
Based on vBulletin Copyright ©2000 - 2005, Jelsoft Enterprises Ltd.
Modified under license