Multiple DPC queues in one device object

Is it kosher to have more than one DPC queue in a device object?

I’m using 2 queues to process discrete events from the ISR. One queue
handles normal transfer events from the device, and the other queue handles
look ahead events. The ISR calls a handler for each interrupt type. Each
type will queue either the look ahead or the normal transfer queue.

What I’m trying to do is separate functionality and reduce the size of the
DPC routine.

Its fine to have multiple DPC queues. Note that they
can run concurrently (as one DPC routine can run
concurrently with itself on the same device object;
you can’t queue it twice, but once its dequeued, it can get
queued again (and run on a different CPU) while its running).

-DH
PS. At high interrrupt rates (>10K/sec), multiple DPCs are a bad idea,
because you want to amortize the overhead of the DPC queueing.
----- Original Message -----
From: “Gary Little”
To: “NT Developers Interest List”
Sent: Monday, May 01, 2000 2:52 PM
Subject: [ntdev] Multiple DPC queues in one device object

> Is it kosher to have more than one DPC queue in a device object?
>
> I’m using 2 queues to process discrete events from the ISR. One queue
> handles normal transfer events from the device, and the other queue handles
> look ahead events. The ISR calls a handler for each interrupt type. Each
> type will queue either the look ahead or the normal transfer queue.
>
> What I’m trying to do is separate functionality and reduce the size of the
> DPC routine.
>
>

As long as you handle any synchronization issues (remember, on an MP
machine, your various DPCs could literally be executing simultaneously), you
can have as many DPC queues as you can stand.

  • Matt

----- Original Message -----
From: “Gary Little”
Sent: Monday, May 01, 2000 2:52 PM

> Is it kosher to have more than one DPC queue in a device object?

[snip]

That’s what I thought. But I keep getting a BSOD every time I process the
second look ahead interrupts. The normal transfer DPC is not even being used
at this point, since it depends on the application running and attempting to
transfer a buffer. The ISR has handled a look ahead request and has called
the look ahead handler which then queued the DPC. The look ahead DPC
acquires the queue spinlock, sees that yes it is a look ahead request but no
there is not a request from the application, so release the spinlock and
exit. Sometime after the release, and before the next ISR is called again,
the system throws an exception and BSODs.

Just for grins, here is the stack trace I get. I at first thought it might
be the lookaside lists that I’m using, but when the BSOD happens the logic
paths that would use these lists are not even active, since again that
depends upon a transfer request from the user. As is the case in much KM
debugging, my driver is not even in the stack.

ChildEBP RetAddr Args to Child
f7447cac 801174c7 00000004 ffffffe7 8010a339
ntkrnlmp!RtlpBreakWithStatusInstruction
f7447e24 80143e8c 0000000a ffffffe7 00000002 ntkrnlmp!KeBugCheckEx+0x1e7
f7447e24 8010a339 0000000a ffffffe7 00000002 ntkrnlmp!KiTrap0E+0x284
f7447ec4 8010a23a 80151120 80151118 00000003
ntkrnlmp!ExpScanGeneralLookasideList+0x21
f7447ed4 8013f40f 00000000 00000000 f7447f1c
ntkrnlmp!ExAdjustLookasideDepth+0x18
f7447f4c 80139a1c 00000000 00000000 00000000
ntkrnlmp!KeBalanceSetManager+0xb3
f7447f7c 8014547e 8013f35c 00000000 00000000
ntkrnlmp!PspSystemThreadStartup+0x54
00000000 00000000 00000000 00000000 00000000 ntkrnlmp!KiThreadStartup+0x16
80152df0 0000000a ffffffe7 00000002 00000000
80152e00 8010a339

Hopefully, someone has seen a similar trace and can say “Hey fool, you be
connecting XYZ to ABC and they don’t bend that way!!” Hopefully …

In the mean time, the battle continues …

-----Original Message-----
From: Dave Harvey [mailto:xxxxx@syssoftsol.com]
Sent: Monday, May 01, 2000 12:02 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Multiple DPC queues in one
device object

Its fine to have multiple DPC queues. Note that they
can run concurrently (as one DPC routine can run
concurrently with itself on the same device object;
you can’t queue it twice, but once its dequeued, it can get
queued again (and run on a different CPU) while its
running).

-DH
PS. At high interrrupt rates (>10K/sec), multiple DPCs are a
bad idea,
because you want to amortize the overhead of the DPC
queueing.
----- Original Message -----
From: “Gary Little”
To: “NT Developers Interest List”
Sent: Monday, May 01, 2000 2:52 PM
Subject: [ntdev] Multiple DPC queues in one device object

> Is it kosher to have more than one DPC queue in a device
object?
>
> I’m using 2 queues to process discrete events from the
ISR. One queue
> handles normal transfer events from the device, and the
other queue handles
> look ahead events. The ISR calls a handler for each
interrupt type. Each
> type will queue either the look ahead or the normal
transfer queue.
>
> What I’m trying to do is separate functionality and reduce
the size of the
> DPC routine.
>
>


You are currently subscribed to ntdev as:
xxxxx@delphieng.com
To unsubscribe send a blank email to
$subst(‘Email.Unsub’)