Can interrupts occur in the middle of execution of a Driver Entry.
If so, then is the following the safest way to prevent interrupts from
occuring during driver entry execution ?
{
asm(“cli”);
/* Driver entry code */
asm(“sti”);
}
Thanx
Kiran
Make sure your hardware doesnt enable interrupts by default. Your driver
can enable the interrupts…
Thus no need to worry about interrupts in DriverEntry…
Your solution wont work on multiprocessor machines… (__asm cli and __asm
sti)
Hope this helps…!
Vijay
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 29, 2003 12:15 PM
Subject: [ntdev] Driver Entry Runlevel.
Can interrupts occur in the middle of execution of a Driver Entry.
If so, then is the following the safest way to prevent interrupts from
occuring during driver entry execution ?
{
asm (“cli”);
/* Driver entry code */
asm (“sti”);
}
Thanx
Kiran
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Hi Vijay
My driver entry routine looks like
{
// do some processing.
// Some critical processing that shud not be interrupted
doCritical();
// call IoInterruptConnect
// sets the uart register so that serial ports interrupts are enabled.
}
So can my doCritical() function get interrupted by any interrupt in the
system ?
If so whats the best way to prevent them assuming NO multiprocessor
architecture.
Thanx
Kiran
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vijay Anand
Sent: Monday, December 29, 2003 1:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Driver Entry Runlevel.
Make sure your hardware doesnt enable interrupts by default. Your driver
can enable the interrupts…
Thus no need to worry about interrupts in DriverEntry…
Your solution wont work on multiprocessor machines… (__asm cli and
__asm
sti)
Hope this helps…!
Vijay
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 29, 2003 12:15 PM
Subject: [ntdev] Driver Entry Runlevel.
Can interrupts occur in the middle of execution of a Driver Entry.
If so, then is the following the safest way to prevent interrupts from
occuring during driver entry execution ?
{
asm (“cli”);
/* Driver entry code */
asm (“sti”);
}
Thanx
Kiran
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> Can interrupts occur in the middle of execution of a Driver Entry.
Surely.
If so, then is the following the safest way to prevent interrupts from
occuring during driver entry execution ?
There is never any need in this. I can explain more if you want.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
> Make sure your hardware doesnt enable interrupts by default.
Such a hardware is extremely lame, and will nearly for such hang the machine on
awakening from standby/hibernate rather often.
The device must be in “all interrupts disabled” state on powering on.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Kiran,
I’m not sure what you want to achieve:
- No interrupts whatsoever (why?)
- No interrupts from your device (reasonable).
If it’s no interrupts whatsoever, why do you want to do that. It doesn’t
make sense to me (not saying that there wouldn’t be a good reason for it in
some circumstances). Also, if you’re writing a generic driver, you can’t
assume that there won’t be someone running this on a MP system. It’s very
likely that you may cause other problems in the system if you do this sort
of thing too, by the way. There aren’t many things in a PC the requires fast
response to interrupts, but if you’re preventing interrupts from happening,
it will possibly prevent other parts of the system form working correctly.
You may for instance find that you’re accessing a page that is pageable, and
it needs paging in. If you haven’t got interrupts enabled, then the reading
of the hard disk will fail, since no interrupt will tell the system that the
read has completed! (That’s just an example, and I understand that the
driverentry is non-paged).
If it’s no interrupts from your device(s), then it’s quite easy: The first
thing you do is to disable the devices interrupts. Then do your critical
work. Then enable interrupts again and do whatever else that can accept
interrupts.
If you’re only worried about your own interrupts, you could also have a
global variable… Something like this:
BOOLEAN initializedYet = FALSE;
int driverEntry()
{
HookInterrupts();
DoSomeInitialization();
DoSomeCriticalWork();
initializedYet = TRUE;
return STATUS_SUCCESS;
}
// This is set up to be the interrupt handler for XXXX in HookInterrupts().
int MyinterruptRoutine()
{
// Check if we have finished initializing…
if (!initializedYet)
return 0;
// Now we know that we’re initialized, we can get on with doing the
interrupt work.
… Do some interrupt handling …
return 1;
}
Hope this helps.
Kiran wrote:
Hi Vijay
My driver entry routine looks like
{
// do some processing.// Some critical processing that shud not be interrupted
doCritical();// call IoInterruptConnect
// sets the uart register so that serial ports interrupts
are enabled.}
So can my doCritical() function get interrupted by any
interrupt in the
system ?
If so whats the best way to prevent them assuming NO multiprocessor
architecture.Thanx
Kiran-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vijay Anand
Sent: Monday, December 29, 2003 1:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Driver Entry Runlevel.Make sure your hardware doesnt enable interrupts by default.
Your driver
can enable the interrupts…
Thus no need to worry about interrupts in DriverEntry…Your solution wont work on multiprocessor machines… (__asm cli and
__asm
sti)Hope this helps…!
Vijay
----- Original Message -----
From:
> To: “Windows System Software Devs Interest List”
> Sent: Monday, December 29, 2003 12:15 PM
> Subject: [ntdev] Driver Entry Runlevel.
>
>
> Can interrupts occur in the middle of execution of a Driver Entry.
>
> If so, then is the following the safest way to prevent interrupts from
> occuring during driver entry execution ?
>
> {
> asm (“cli”);
> /* Driver entry code */
> asm (“sti”);
> }
>
> Thanx
> Kiran
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@wipro.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@3dlabs.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
> My driver entry routine looks like
{
// do some processing.// Some critical processing that shud not be interrupted
doCritical();
Your device cannot interrupt it, since you will do this before you enable
interrupts on it. As about any other interrupts - just do not care.
Also note: you’re calling IoConnectInterrupt in DriverEntry. This means -
you’re writing and obsolete-NT4-style driver, which will disable all power
management on the machine.
Maybe you would reconsider writing a WDM driver?
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
The “official” way to achieve your goal is to raise the IRQL. The “serial” sample from the DDK uses :
KeRaiseIrql(
POWER_LEVEL,
&oldIrql
);
This works on multiprocessor systems too.
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 29, 2003 10:28 AM
Subject: [ntdev] Re: Driver Entry Runlevel.
> Hi Vijay
>
> My driver entry routine looks like
>
> {
> // do some processing.
>
> // Some critical processing that shud not be interrupted
> doCritical();
>
> // call IoInterruptConnect
> // sets the uart register so that serial ports interrupts are enabled.
>
> }
>
> So can my doCritical() function get interrupted by any interrupt in the
> system ?
> If so whats the best way to prevent them assuming NO multiprocessor
> architecture.
>
> Thanx
> Kiran
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Vijay Anand
> Sent: Monday, December 29, 2003 1:18 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Driver Entry Runlevel.
>
>
> Make sure your hardware doesnt enable interrupts by default. Your driver
> can enable the interrupts…
> Thus no need to worry about interrupts in DriverEntry…
>
> Your solution wont work on multiprocessor machines… ( asm cli and
> asm
> sti)
>
> Hope this helps…!
>
> Vijay
>
> ----- Original Message -----
> From:
> To: “Windows System Software Devs Interest List”
> Sent: Monday, December 29, 2003 12:15 PM
> Subject: [ntdev] Driver Entry Runlevel.
>
>
> Can interrupts occur in the middle of execution of a Driver Entry.
>
> If so, then is the following the safest way to prevent interrupts from
> occuring during driver entry execution ?
>
> {
> asm (“cli”);
> /* Driver entry code */
> asm (“sti”);
> }
>
> Thanx
> Kiran
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@wipro.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@compaqnet.be
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
Yes Maxim,
please explain the best way to make the doCritical() run without
getting interrupted.
DriverEntry Routine
{
// do some processing.
// Some critical processing that shud not be interrupted
doCritical();
// call IoInterruptConnect
// sets the uart register so that serial ports interrupts are enabled.
}
Thanx
Kiran
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
Sent: Monday, December 29, 2003 3:55 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Driver Entry Runlevel.
Can interrupts occur in the middle of execution of a Driver Entry.
Surely.
If so, then is the following the safest way to prevent interrupts from
occuring during driver entry execution ?
There is never any need in this. I can explain more if you want.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Depends on what your doCritical is supposed to do.
You might get better solutions if you can elaborate what you are trying to
do.
Does this driver load during booting?
DriverEntry executes in a system thread context (at IRQL_PASSIVE_LEVEL).
Better make sure is this the correct place to do your doCritical() stuff.
Vijay
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 29, 2003 2:58 PM
Subject: [ntdev] Re: Driver Entry Runlevel.
Hi Vijay
My driver entry routine looks like
{
// do some processing.
// Some critical processing that shud not be interrupted
doCritical();
// call IoInterruptConnect
// sets the uart register so that serial ports interrupts are enabled.
}
So can my doCritical() function get interrupted by any interrupt in the
system ?
If so whats the best way to prevent them assuming NO multiprocessor
architecture.
Thanx
Kiran
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vijay Anand
Sent: Monday, December 29, 2003 1:18 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Driver Entry Runlevel.
Make sure your hardware doesnt enable interrupts by default. Your driver
can enable the interrupts…
Thus no need to worry about interrupts in DriverEntry…
Your solution wont work on multiprocessor machines… ( asm cli and
asm
sti)
Hope this helps…!
Vijay
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 29, 2003 12:15 PM
Subject: [ntdev] Driver Entry Runlevel.
Can interrupts occur in the middle of execution of a Driver Entry.
If so, then is the following the safest way to prevent interrupts from
occuring during driver entry execution ?
{
asm (“cli”);
/* Driver entry code */
asm (“sti”);
}
Thanx
Kiran
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@wipro.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
—
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@hotmail.com
To unsubscribe send a blank email to xxxxx@lists.osr.com
Max,
His concern is about other interrupts…(not from his own hardware…)
Given this case, is it advisable to raise the IRQL to POWER_LEVEL from
a DriverEntry…? ( My assumption is, NO, it isn’t)
Vijay
----- Original Message -----
From: “Maxim S. Shatskih”
To: “Windows System Software Devs Interest List”
Sent: Monday, December 29, 2003 3:59 PM
Subject: [ntdev] Re: Driver Entry Runlevel.
> > My driver entry routine looks like
> >
> > {
> > // do some processing.
> >
> > // Some critical processing that shud not be interrupted
> > doCritical();
>
> Your device cannot interrupt it, since you will do this before you enable
> interrupts on it. As about any other interrupts - just do not care.
>
> Also note: you’re calling IoConnectInterrupt in DriverEntry. This means -
> you’re writing and obsolete-NT4-style driver, which will disable all power
> management on the machine.
>
> Maybe you would reconsider writing a WDM driver?
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hotmail.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
There is nothing wrong with raising IRQL in DriverEntry, it is just an
unusual requirement. Perhaps the need isn’t really there. Also this would
appear to be an NT4 (legacy) hardware driver, and that would be even more
unusual, as in wrong, unless the target platform OS is in fact NT4.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Vijay Anand
Sent: Monday, December 29, 2003 6:08 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Re: Driver Entry Runlevel.Max,
His concern is about other interrupts…(not from his
own hardware…) Given this case, is it advisable to raise the
IRQL to POWER_LEVEL from a DriverEntry…? ( My assumption is,
NO, it isn’t)Vijay
----- Original Message -----
From: “Maxim S. Shatskih”
> To: “Windows System Software Devs Interest List”
> Sent: Monday, December 29, 2003 3:59 PM
> Subject: [ntdev] Re: Driver Entry Runlevel.
>
>
> > > My driver entry routine looks like
> > >
> > > {
> > > // do some processing.
> > >
> > > // Some critical processing that shud not be interrupted
> > > doCritical();
> >
> > Your device cannot interrupt it, since you will do this
> before you enable
> > interrupts on it. As about any other interrupts - just do not care.
> >
> > Also note: you’re calling IoConnectInterrupt in
> DriverEntry. This means -
> > you’re writing and obsolete-NT4-style driver, which will
> disable all power
> > management on the machine.
> >
> > Maybe you would reconsider writing a WDM driver?
> >
> > Maxim Shatskih, Windows DDK MVP
> > StorageCraft Corporation
> > xxxxx@storagecraft.com
> > http://www.storagecraft.com
> >
> >
> > —
> > Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
> >
> > You are currently subscribed to ntdev as:
> xxxxx@hotmail.com
> > To unsubscribe send a blank email to xxxxx@lists.osr.com
> >
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@hollistech.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
The explanation of this doCritical() case follows.
Sane devices have interrupts off at power on.
OK, if the device is insane (this occurs :-)), then the first thing the
driver must do is - to disable its interrupts. This is done by the
device-specific interrupt control register.
Interrupts are enabled on the device - by means of the same device-specific
interrupt control register - only after IoConnectInterrupt. Otherwise, the very
first interrupt from a PCI device will hang the machine, since the APIC will
resubmit it again and again and again, and there is nobody to switch the
hardware off this interrupt-asserting state. The “native” ISR would do this,
but it is not connected yet.
So:
- device powers on with interrupts disabled by means of the device-specific
interrupt mask register - if the device can interrupt just after being powered on - it needs fixing
- you enable interrupts in this register only after IoConnectInterrupt.
Side note: the driver must disable the interrupts - using the same
register - on going low power, and re-enable on awaken. Otherwise, the stray
interrupt from your device during resume from hibernation (while the kernel is
not loaded, NTLDR loads the memory image and the kernel’s IDT is not active) -
will hang the machine in the same way as described above.
In the below code, doCritical() is called before IoConnectInterrupt, and
thus for sure before the interrupts are enabled. This means - it has a
guarantee that an ISR from this same device will not interrupt it.
As about interrupts from other devices - they are just not important. Just
let them fly by. Forget about them.
The thing is that any synchronization is with a purpose. The purpose of
synchronizing with interrupt is obvious - to access the in-memory state data
and the device registers, which are also accessed by the ISR for the device.
But what is the purpose of synchronizing with the ISR of the other device?
You have no shared data with its driver, and you will not access its hardware
registers. So, just forget its ISR, even if it will interrupt your
doCritical() - this is OK.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
----- Original Message -----
From:
To: “Windows System Software Devs Interest List”
Sent: Monday, December 29, 2003 1:54 PM
Subject: [ntdev] Re: Driver Entry Runlevel.
> Yes Maxim,
> please explain the best way to make the doCritical() run without
> getting interrupted.
>
> DriverEntry Routine
> {
> // do some processing.
>
> // Some critical processing that shud not be interrupted
> doCritical();
>
> // call IoInterruptConnect
> // sets the uart register so that serial ports interrupts are enabled.
>
> }
>
> Thanx
> Kiran
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S. Shatskih
> Sent: Monday, December 29, 2003 3:55 PM
> To: Windows System Software Devs Interest List
> Subject: [ntdev] Re: Driver Entry Runlevel.
>
>
> > Can interrupts occur in the middle of execution of a Driver Entry.
>
> Surely.
>
> > If so, then is the following the safest way to prevent interrupts from
> > occuring during driver entry execution ?
>
> There is never any need in this. I can explain more if you want.
>
> Maxim Shatskih, Windows DDK MVP
> StorageCraft Corporation
> xxxxx@storagecraft.com
> http://www.storagecraft.com
>
>
> —
> Questions? First check the Kernel Driver FAQ at
> http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@wipro.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
>
> You are currently subscribed to ntdev as: xxxxx@storagecraft.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> Max,
His concern is about other interrupts…(not from his own hardware…)
I would suggest him to relax and forget this very concern.
The only exception from this if is he does something to a CPU itself - like
accessing some MSRs or such. In this case, cli/sti seems to be a must.
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com