I have a thread running at passive level that must respond to interrupts. Is there a way to signal that thread directly from an ISR? The MSDN documentation for KeSetEvent() indicates that it must be called at DISPATCH_LEVEL or less. Must I create a DPC routine just to call KeSetEvent() or is there a simpler, more efficient way?
You must queue a DPC to set the event
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@qualcomm.com
Sent: Tuesday, November 29, 2011 1:37 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] KeSetEvent() not permitted at DIRQL
I have a thread running at passive level that must respond to interrupts. Is there a way to signal that thread directly from an ISR? The MSDN documentation for KeSetEvent() indicates that it must be called at DISPATCH_LEVEL or less. Must I create a DPC routine just to call KeSetEvent() or is there a simpler, more efficient way?
NTDEV is sponsored by OSR
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
Yes.
The “just to” part of the sentence is noise, because you must queue a DPC
to do any operation that is not permitted at IRQL level but is permitted
at DPC level. Note that if your are doing something that requires passive
level, then you must do as you have done: queue up a DPC, the DPC sets the
event, and the thread processes it.
joe
I have a thread running at passive level that must respond to interrupts.
Is there a way to signal that thread directly from an ISR? The MSDN
documentation for KeSetEvent() indicates that it must be called at
DISPATCH_LEVEL or less. Must I create a DPC routine just to call
KeSetEvent() or is there a simpler, more efficient way?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Compared to a thread wakeup cost, queuing a DPC is very cheap.
Unless the thread in question is in a busy loop (highly not recommended) you
must interact with the scheduler; and this you cannot do from an ISR, so
yes, you must use a DPC
wrote in message news:xxxxx@ntdev…
Yes.
The “just to” part of the sentence is noise, because you must queue a DPC
to do any operation that is not permitted at IRQL level but is permitted
at DPC level. Note that if your are doing something that requires passive
level, then you must do as you have done: queue up a DPC, the DPC sets the
event, and the thread processes it.
joe
I have a thread running at passive level that must respond to interrupts.
Is there a way to signal that thread directly from an ISR? The MSDN
documentation for KeSetEvent() indicates that it must be called at
DISPATCH_LEVEL or less. Must I create a DPC routine just to call
KeSetEvent() or is there a simpler, more efficient way?
NTDEV is sponsored by OSR
For our schedule of WDF, WDM, debugging and other seminars visit:
http://www.osr.com/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
In Win8 it seems to be possible to start a work item directly from ISR:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439270(v=VS.85).aspx
– pa
Note this is not a general statement you can make for all interrupts, just those types listed on the doc page.
d
debt from my phone
From: Pavel A
Sent: 11/29/2011 3:44 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] KeSetEvent() not permitted at DIRQL
In Win8 it seems to be possible to start a work item directly from ISR:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439270(v=VS.85).aspx
– pa
NTDEV is sponsored by OSR
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
AFAIK, this new KMDF (and UMDF) feature is limited to low-speed serial busses on SoCs. Took me a while to get comfortable with an idea of say reading data synchronously right out of the ISR. 
Regards,
Ilya Faenson
Rockville, MD USA
In Win8 it seems to be possible to start a work item directly from ISR:
http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035(v=VS.85).aspx
http://msdn.microsoft.com/en-us/library/windows/hardware/hh439270(v=VS.85).aspx
– pa
>called at DISPATCH_LEVEL or less. Must I create a DPC routine just to call KeSetEvent()
Yes.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
This seems to be a wrapper around the usual way provided by KMDF.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Pavel A” wrote in message news:xxxxx@ntdev…
> In Win8 it seems to be possible to start a work item directly from ISR:
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035(v=VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/hh439270(v=VS.85).aspx
>
> – pa
>
>
>me a while to get comfortable with an idea of say reading data synchronously right out of the ISR.
This is what the serial port and PIO mode ATA do.
You can read data from the ISR, you cannot complete an IRP from there.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
> this feature is limited to low-speed serial busses on SoCs
Well, typically Simple Peripheral Buses (SPBs) on Win8, which would include SPI, GPIOs, and even high speed async devices.
This is what the serial port and PIO mode ATA do
LOL… sure. Or LOTS of devices. But this isn’t what Mr. Faenson is referring to, if I understand correctly. He’s talking about doing an actual READ, with an IRP or a system service or WdfRequestSend, directly from a Win8 PASSIVE_LEVEL ISR.
Or I’m completely over-reading and misunderstanding Mr. Faenson’s reply… but we WERE talking about PASSIVE_LEVEL ISRs (see the doc page pointer previously provided).
Peter
OSR
Max is speculating. This is not a wrapper around KMDF. It’s the kernel
queuing a DPC for you.
Jake Oshins
Windows Kernel Group
This post implies no warranties and confers no rights.
“Maxim S. Shatskih” wrote in message news:xxxxx@ntdev…
This seems to be a wrapper around the usual way provided by KMDF.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
“Pavel A” wrote in message news:xxxxx@ntdev…
> In Win8 it seems to be possible to start a work item directly from ISR:
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035(v=VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/hh439270(v=VS.85).aspx
>
> – pa
>
>
“Doron Holan” wrote in message
news:xxxxx@ntdev…
> Note this is not a general statement you can make for all interrupts, just
> those types listed on the doc page.
So it works only for the new passive level interrupts?
Are the passive level interrupts a new kernel construct or they exist only
in KMDF?
Thought that the amaizng kernel team found a way to queue work items from
DIRQL,
similar to how DPCs are queued…
– pa
________________________________
> From: Pavel A
> Sent: 11/29/2011 3:44 PM
> To: Windows System Software Devs Interest List
> Subject: Re:[ntdev] KeSetEvent() not permitted at DIRQL
>
> In Win8 it seems to be possible to start a work item directly from ISR:
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/hh451035(v=VS.85).aspx
>
> http://msdn.microsoft.com/en-us/library/windows/hardware/hh439270(v=VS.85).aspx
>
> – pa
>
>
> —
> NTDEV is sponsored by OSR
>
> 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
>
>
> > This is what the serial port and PIO mode ATA do
LOL… sure. Or LOTS of devices. But this isn’t what Mr. Faenson is referring
to, if I understand correctly. He’s talking about doing an actual READ, with an
IRP or a system service or WdfRequestSend, directly from a Win8 PASSIVE_LEVEL
ISR.Or I’m completely over-reading and misunderstanding Mr. Faenson’s reply… but
we WERE talking about PASSIVE_LEVEL ISRs (see the doc page pointer previously
provided).Peter
OSR
Peter is absolutely correct (as always), sorry about not being clear enough. I meant actually submitting the IOCTL_SPB_EXECUTE_SEQUENCE out of the ISR and waiting for its completion. Takes milliseconds on these slow busses. Refer to the SpbAccelerometer WDK sample. Needless to say, this interrupt line may not be shared with anything requiring prompt service.
So it works only for the new passive level interrupts?
Are the passive level interrupts a new kernel construct or they exist only
in KMDF?
Pavel,
Yes, indeed, to the first question. This is a new Win8 feature available in both KMDF and UMDF. I’m not aware of its WDM counterpart but nobody is developing these drivers in WDM anyway.
Regards,
Ilya Faenson
Rockville MD USA
Passive level interrupts are a kernel construct. KMDF and UMDF rely on that construct.
-p
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@hotmail.com
Sent: Thursday, December 01, 2011 5:15 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KeSetEvent() not permitted at DIRQL
> This is what the serial port and PIO mode ATA do
LOL… sure. Or LOTS of devices. But this isn’t what Mr. Faenson is
referring to, if I understand correctly. He’s talking about doing an
actual READ, with an IRP or a system service or WdfRequestSend,
directly from a Win8 PASSIVE_LEVEL ISR.Or I’m completely over-reading and misunderstanding Mr. Faenson’s
reply… but we WERE talking about PASSIVE_LEVEL ISRs (see the doc
page pointer previously provided).Peter
OSR
Peter is absolutely correct (as always), sorry about not being clear enough. I meant actually submitting the IOCTL_SPB_EXECUTE_SEQUENCE out of the ISR and waiting for its completion. Takes milliseconds on these slow busses. Refer to the SpbAccelerometer WDK sample. Needless to say, this interrupt line may not be shared with anything requiring prompt service.
So it works only for the new passive level interrupts?
Are the passive level interrupts a new kernel construct or they exist
only in KMDF?
Pavel,
Yes, indeed, to the first question. This is a new Win8 feature available in both KMDF and UMDF. I’m not aware of its WDM counterpart but nobody is developing these drivers in WDM anyway.
Regards,
Ilya Faenson
Rockville MD USA
NTDEV is sponsored by OSR
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
On 01-Dec-2011 20:31, Peter Wieland wrote:
Passive level interrupts are a kernel construct. KMDF and UMDF rely on that construct.
-p
These Win8 innovations are so confusing.
“Passive level interrupt” sounds IMHO like hot ice, or… like “threaded
DPC”
– pa
> Passive level interrupt" sounds IMHO like hot ice,
In fact, there is nothing particularly ridiculous about it, as long as the OS knows how to ensure that ISR cannot either re-enter itself or run concurrently on different CPUs. For certain interrupts on certain architectures doing so may be not the best solution in existence (ironically, according to Linux kernel sources, PCI interrupts that are vectored via IOAPIC on x86-based system happen to be the only ones that fall into this category), but for the other ones it may be just fine. Certainly, I am almost100% sure MSFT kernel guys will find a way to do something that defeats the purpose of the whole exercise the way they did it with threaded DPCs, but this is already a different story…
or… like “threaded DPC”
Well, threaded DPC is just their attempt to implement something known as “interrupt thread” on other systems.
They just screwed it up and made the whole thing worthless, from the developer’s perspective, because if you are told “this code may , probably, run in atomic context” you have to make it suitable for this, effectively avoiding anything that you can do in non-atomic one…
Anton Bassov
> These Win8 innovations are so confusing.
These Win8 innovations *are* confusing. For MOST developers, writing drivers for ordinary Windows systems, the good news is that they won’t have to be concerned with some of the strangest Win8 stuff such as passive level interrupts or devices that can’t be dynamically enumerated. Or – the one that really hurt my head initially – devices that get power from one place, interrupts from another, data from someplace else, and maybe even clock from a fourth place (who IS your parent then, eh? Sort of reminds one of the modern family). Ouch!
When you get into SoCs and such, things can get mighty interesting. Here at OSR we’ve been very kept pretty busy learning about all these new interesting things. You can look forward to discussions of some of these items in The NT Insider in the future. We love to share what we learn.
Peter
OSR
wrote in message news:xxxxx@ntdev…
>> These Win8 innovations are so confusing.
>
> These Win8 innovations are confusing. For MOST developers, writing
> drivers for ordinary Windows systems, the good news is that they won’t
> have to be concerned with some of the strangest Win8 stuff such as passive
> level interrupts or devices that can’t be dynamically enumerated. Or –
> the one that really hurt my head initially – devices that get power from
> one place, interrupts from another, data from someplace else, and maybe
> even clock from a fourth place (who IS your parent then, eh? Sort of
> reminds one of the modern family). Ouch!
>
> When you get into SoCs and such, things can get mighty interesting. Here
> at OSR we’ve been very kept pretty busy learning about all these new
> interesting things. You can look forward to discussions of some of these
> items in The NT Insider in the future. We love to share what we learn.
>
> Peter
> OSR
Am already in the embeded and SoC stuff, up to my ears.
This sort of systems and devices (low cost by all means, extreme “rush to
the market” design)
was previously addressed by WinCE - which has competely different kernel
and overall architecture appropriate to such projects.
So, does what we see now in Win8 look like a collision of these absolutely
different kernels?
Or, simply put , attempt to sit between two chairs?
– pa