When I attempt to acquire the spin lock, Driver Verifier generates a fault (DRIVER_IRQL_NOT_LESS_OR_EQUAL). Obviously, I am attempting to access paged data. Does the #pragma PAGEDCODE at the beginning of the DispatchControl make the entire function paged?
-----Original Message-----
From: xxxxx@winsystems.com Sent: August 05, 2010 3:58 PM To: Windows System Software Devs Interest List Subject: [ntdev] Paged Memory Error - IRQL_NOT_LESS_OR_EQUAL
I am new at driver development and have stumbles upon a bug.
My driver has the following code:
#pragma PAGEDCODE
NTSTATUS DispatchControl(PDEVICE_OBJECT fdo, PIRP Irp) { PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo->DeviceExtension; PUIO_WRITE_VALUE pUIOWriteValue; PUIO_CONFIG_INTERRUPT pUIOConfigInterrupt; PUCHAR memBaseAddress; PUCHAR pMemAddress; DWORD dwSanityRegValue; WORD wdIntPendingValue; BYTE byPortValue; BYTE byIOMask; int nPort; int nBitNumber; int nMaxBitNumber; int nMaxPortNumber; : : : case IOCTL_WIO_WAIT_ON_INT: KdPrint((DRIVERNAME " +IOCTL_WIO_WAIT_ON_INT.\r\n"));
if (cbout < static_cast(MAX_INT_PORTS)) { status = STATUS_INVALID_BUFFER_SIZE; } else if (FALSE == pdx->fInterruptsSupported) { status = STATUS_INVALID_DEVICE_REQUEST; } else { if (TRUE == pdx->fInterruptConfigured) { PUCHAR pIntBuffer = reinterpret_cast(pCopyBuffer); BOOLEAN fInterruptsPresent = FALSE;
When I attempt to acquire the spin lock, Driver Verifier generates a fault (DRIVER_IRQL_NOT_LESS_OR_EQUAL). Obviously, I am attempting to access paged data. Does the #pragma PAGEDCODE at the beginning of the DispatchControl make the entire function paged?
You made the code paged, so as soon as you raise IRQL your code could be
paged out and you will crash. Get rid of the pragma, or use a different
type of lock that can live with paged code.
I am new at driver development and have stumbles upon a bug.
My driver has the following code:
#pragma PAGEDCODE
NTSTATUS DispatchControl(PDEVICE_OBJECT fdo, PIRP Irp) {
PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo-
>DeviceExtension;
PUIO_WRITE_VALUE pUIOWriteValue;
PUIO_CONFIG_INTERRUPT pUIOConfigInterrupt;
PUCHAR memBaseAddress;
PUCHAR pMemAddress;
DWORD dwSanityRegValue;
WORD wdIntPendingValue;
BYTE byPortValue;
BYTE byIOMask;
int nPort;
int nBitNumber;
int nMaxBitNumber;
int nMaxPortNumber;
:
:
:
case IOCTL_WIO_WAIT_ON_INT:
KdPrint((DRIVERNAME " +IOCTL_WIO_WAIT_ON_INT.\r\n"));
if (cbout < static_cast(MAX_INT_PORTS)) > { > status = STATUS_INVALID_BUFFER_SIZE; > } > else if (FALSE == pdx->fInterruptsSupported) > { > status = STATUS_INVALID_DEVICE_REQUEST; > } > else > { > if (TRUE == pdx->fInterruptConfigured) > { > PUCHAR pIntBuffer = reinterpret_cast(pCopyBuffer); > BOOLEAN fInterruptsPresent = FALSE; > > KIRQL oldirql; > KeAcquireSpinLock(&pdx->LockPortInterruptMask, &oldirql); > > When I attempt to acquire the spin lock, Driver Verifier generates a fault > (DRIVER_IRQL_NOT_LESS_OR_EQUAL). Obviously, I am attempting to access paged > data. Does the #pragma PAGEDCODE at the beginning of the DispatchControl make > the entire function paged? > > > > > Information from ESET Smart Security, version of virus signature > database 5345 (20100805) > > The message was checked by ESET Smart Security. > > http://www.eset.com >
Or move the acquisition of the lock and the code running with the lock held to a different function which is not paged.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Don Burn
Sent: Thursday, August 05, 2010 4:01 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Paged Memory Error - IRQL_NOT_LESS_OR_EQUAL
You made the code paged, so as soon as you raise IRQL your code could be paged out and you will crash. Get rid of the pragma, or use a different type of lock that can live with paged code.
I am new at driver development and have stumbles upon a bug.
My driver has the following code:
#pragma PAGEDCODE
NTSTATUS DispatchControl(PDEVICE_OBJECT fdo, PIRP Irp) {
PDEVICE_EXTENSION pdx = (PDEVICE_EXTENSION) fdo-
>DeviceExtension;
PUIO_WRITE_VALUE pUIOWriteValue;
PUIO_CONFIG_INTERRUPT pUIOConfigInterrupt;
PUCHAR memBaseAddress;
PUCHAR pMemAddress;
DWORD dwSanityRegValue;
WORD wdIntPendingValue;
BYTE byPortValue;
BYTE byIOMask;
int nPort;
int nBitNumber;
int nMaxBitNumber;
int nMaxPortNumber;
:
:
:
case IOCTL_WIO_WAIT_ON_INT:
KdPrint((DRIVERNAME " +IOCTL_WIO_WAIT_ON_INT.\r\n"));
if (cbout < static_cast(MAX_INT_PORTS)) > { > status = STATUS_INVALID_BUFFER_SIZE; > } > else if (FALSE == pdx->fInterruptsSupported) > { > status = STATUS_INVALID_DEVICE_REQUEST; > } > else > { > if (TRUE == pdx->fInterruptConfigured) > { > PUCHAR pIntBuffer = reinterpret_cast(pCopyBuffer); > BOOLEAN fInterruptsPresent = FALSE; > > KIRQL oldirql; > KeAcquireSpinLock(&pdx->LockPortInterruptMask, &oldirql); > > When I attempt to acquire the spin lock, Driver Verifier generates a fault > (DRIVER_IRQL_NOT_LESS_OR_EQUAL). Obviously, I am attempting to access paged > data. Does the #pragma PAGEDCODE at the beginning of the DispatchControl make > the entire function paged? > > > > > Information from ESET Smart Security, version of virus signature > database 5345 (20100805) > > The message was checked by ESET Smart Security. > > http://www.eset.com >
That is not true, you can see visible results with every page that is no longer non paged.
d
dent from a phpne with no keynoard
-----Original Message-----
From: xxxxx@broadcom.com Sent: August 09, 2010 3:26 PM To: Windows System Software Devs Interest List Subject: RE:[ntdev] Paged Memory Error - IRQL_NOT_LESS_OR_EQUAL
Or better NEVER use PAGED code. It only gives you headache, and there is no savings whatsoever.
“That is not true, you can see visible results with every page that is no longer
non paged.”
Doron,
You can always say that with one more page available one can have that many more handles open in the system, or that many more IRPs outstanding, etc. These are the metrics that you can proudly proclaim on your yearly review. But in reality, if a system hits kernel resource limit, it’s ill-configured. Or (MUCH more likely) it suffers memory leak that someone has to fix. There are (were) more important problems in the kernel than saving (even 10 or 20 MB) non-paged code pages. There is not even 20 MB of paged code in the whole kernel, after all. It’s 1% of a typical desktop system. And everyday XP desktop performance problems have never been caused by insufficient nonpaged pool. Therey were caused by its strange memory manager discard policies (ever watched a process falling into crazy page-in thrashing, while other process is doing large cached file operation?). And by lack of runaway thread de-prioritization.
And paged code can cause so obscure deadlocks. Now that non-storport drivers may get in the paging path, these deadlocks may come from very unexpected places.
This is not about hitting limits of paged or NP pool. It is about availability of memory throughout they entire system. For every page of NP pool you save, that is one more page of code that can remain resident in UM (or KM). that means the OS is more responsive and has more resources to redistribute as it needs. Then, multiply this on N over committed VMs. The issue is even more paramount.
d
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Tuesday, August 10, 2010 2:27 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Paged Memory Error - IRQL_NOT_LESS_OR_EQUAL
“That is not true, you can see visible results with every page that is no longer non paged.”
Doron,
You can always say that with one more page available one can have that many more handles open in the system, or that many more IRPs outstanding, etc. These are the metrics that you can proudly proclaim on your yearly review. But in reality, if a system hits kernel resource limit, it’s ill-configured. Or (MUCH more likely) it suffers memory leak that someone has to fix. There are (were) more important problems in the kernel than saving (even 10 or 20 MB) non-paged code pages. There is not even 20 MB of paged code in the whole kernel, after all. It’s 1% of a typical desktop system. And everyday XP desktop performance problems have never been caused by insufficient nonpaged pool. Therey were caused by its strange memory manager discard policies (ever watched a process falling into crazy page-in thrashing, while other process is doing large cached file operation?). And by lack of runaway thread de-prioritization.
And paged code can cause so obscure deadlocks. Now that non-storport drivers may get in the paging path, these deadlocks may come from very unexpected places.
“Doron Holan” wrote in message news:xxxxx@ntdev… > This is not about hitting limits of paged or NP pool. It is about > availability of memory throughout they entire system. For every page of NP > pool you save, that is one more page of code that can remain resident in > UM (or KM). that means the OS is more responsive and has more resources to > redistribute as it needs. Then, multiply this on N over committed VMs. > The issue is even more paramount. > > d
MS did fantastic job optimizing win7, very impressive. So you’ve saved some memory and CPU cycles for us users - now we can afford being sloppy and waste more Thanks.
– pa
> -----Original Message----- > From: xxxxx@lists.osr.com > [mailto:xxxxx@lists.osr.com] On Behalf Of > xxxxx@broadcom.com > Sent: Tuesday, August 10, 2010 2:27 PM > To: Windows System Software Devs Interest List > Subject: RE:[ntdev] Paged Memory Error - IRQL_NOT_LESS_OR_EQUAL > > “That is not true, you can see visible results with every page that is no > longer non paged.” > > Doron, > > You can always say that with one more page available one can have that > many more handles open in the system, or that many more IRPs outstanding, > etc. These are the metrics that you can proudly proclaim on your yearly > review. But in reality, if a system hits kernel resource limit, it’s > ill-configured. Or (MUCH more likely) it suffers memory leak that someone > has to fix. There are (were) more important problems in the kernel than > saving (even 10 or 20 MB) non-paged code pages. There is not even 20 MB of > paged code in the whole kernel, after all. It’s 1% of a typical desktop > system. And everyday XP desktop performance problems have never been > caused by insufficient nonpaged pool. Therey were caused by its strange > memory manager discard policies (ever watched a process falling into crazy > page-in thrashing, while other process is doing large cached file > operation?). And by lack of runaway thread de-prioritization. > > And paged code can cause so obscure deadlocks. Now that non-storport > drivers may get in the paging path, these deadlocks may come from very > unexpected places. > > Note that I’m not palking about paged pool. > > > > — > 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 > >
> And paged code can cause so obscure deadlocks. Now that non-storport
drivers may get in the paging path, these deadlocks may come from very
unexpected places.
Good reminder to folks that if you’re iSCSI booted, YOUR network component
(like your filter or IM driver) may essentially be in the paging path. It
seems like for iSCSI there is a little more wiggle room on things like the
paging path requirement to always make forward progress. If there were no
resources, you could drop a packet, as packets do get dropped, although you
better not drop too many or the system dies. The normal storage stack is
unforgiving and if you can’t complete a single disk i/o (the last retry) in
the paging path, your system may die.
Speaking of the paging path and networking, if I only have say a single
10GbE nic and would like to be iSCSI booted and running Hyper-V, is the VM
switch compatible with the paging path? I assume the parent partition iSCSI
initiator would need to send its traffic though the parent virtual nic and
VM switch to the physical nic? Even if this configuration works, installing
it seems problematic as during setup you need to unbind the TCPIP protocol
from the physical nic and insert the VM switch and bind to the parent
virtual nic. This would interrupt paging, although if you temporarily had 2
nics, you might configure the iSCSI initiator to use multiple paths. This
might allow building an image that would run on single nic systems.
> And paged code can cause so obscure deadlocks. Now that non-storport
> drivers may get in the paging path, these deadlocks may come from
very
> unexpected places.
Good reminder to folks that if you’re iSCSI booted, YOUR network
component
(like your filter or IM driver) may essentially be in the paging path.
It
seems like for iSCSI there is a little more wiggle room on things like
the
paging path requirement to always make forward progress. If there were
no
resources, you could drop a packet, as packets do get dropped,
although you
better not drop too many or the system dies. The normal storage stack
is
unforgiving and if you can’t complete a single disk i/o (the last
retry) in
the paging path, your system may die.
Thanks for posting that Jan. I’d always wondered about iSCSI and AoE
boot drivers - if they use the network driver then presumably they do
get put in the paging path but had never seen anything documented (I’d
never gone looking though - I’d just wondered
As a general rule, is hibernation and crash dump supported on iSCSI boot
devices or is it a bit hit and miss depending on the quality of the
network adapter?
iSCSI easily survives short interruptions in connectivity. To really cause paging error, the link has to drop for quite a while. That said, if a component is injected to the paging path, it better don’t require page-in (or registry access outside Class or Services) during bring-up. This is where L2 iSCSI with Vswitch may be problematic. Or not. It depends on whether all drivers are marked with boot start or with special value in the service that MSiSCSI is using.
>With proper discipline, paged code causes zero issues.
In an ideal world, we know which code inside MS provided modules is paged, because in the ideal world everybody can see MS source code. In the ideal world, everybody knows that IoAllocateDmaAdapter code path is paged, no need to document it in DDK. Also everybody knows that AllocateCommonBuffer code path is also paged.
In the real world, you have to find that because the customer reports a deadlock from the field.
With proper discipline, user’s systems have enough memory and we wouldn’t be having this discussion.
Look… I *get* Doron’s point. And I think it’s especially important for in-box drivers not to just arbitrarily make all their memory non-paged.
But I’ve often said: “The land of device drivers is one where all memory is non-paged and all locks are spin.” Perhaps a bit of hyperbole there (from ME? Never!), but I think it’s the right policy for most people and most drivers. Does it “waste” memory? Maybe… but if the device is present, do we really want to incur paging I/O overhead in the device’s request processing paths? I don’t think we usually do. It’s silly. Let some application suffer the slings and arrows of too little memory.
OTOH, I would not be happy if a driver that was rarely used… such as the serial or parallel port drivers… was entirely non-paged. That would be bad design.
So, like everything else in kernel driver development, there’s no “one size fits all.” The answer is “It depends.” But by DEFAULT, I encourage folks to START with limiting all their functions and pool allocations to non-paged. Get it to work first… THEN get it to work fast. THEN get it to work smaller.
