[wdmaudiodev] Re: question on DMUS UART

  • From: BlazeAudio Developer <developer@xxxxxxxxxxxxxx>
  • To: wdmaudiodev@xxxxxxxxxxxxx
  • Date: Fri, 28 Nov 2003 10:00:32 +0530

Philip,

I ran into a very similar problem (it also happens to be a 1394 device!!).

The way we worked around it was not to call GetMessage/PutMessage directly from our DPC, but to actually call the DMUS Port's Notify routine. Which in turn invokes the stream's SourceEvtsToPort method which does the real work.

You might still want to get the time-stamp from your DPC.

Hope this helps.

Thanks.
Devendra.

At 03:10 AM 11/27/2003, Philip Lukidis wrote:

Hi.  I have a DMUS UART capture miniport (over 1394), and it works great
with 1 CPU (on Win2k SP4 and WinXP
SP1).  The moment I switch to dual CPUs on either OS I the same problem.
The design is very simple.  I send only uncooked MIDI bytes up to the sink
as they become available, one at a time (when I buffer and send cooked data
I have the same issue, as described below).  Each time I call PutMessage on
the sink, I fill up the DMUS event as follows (error checking removed):

(called from a DPC, and after having acquired a spinlock):

status=pThis->m_AllocatorMXF->GetMessage(&pEvent);
memcpy(pEvent->uData.abData,pMessage,usLength);
pEvent->cbEvent=usLength;
pEvent->pNextEvt = NULL;
pEvent->usChannelGroup = 0;
pEvent->usFlags = DMUS_KEF_EVENT_INCOMPLETE; // uncooked
status=pThis->m_pMiniport->m_MasterClock->GetTime(&pEvent->ullPresTime100ns)
;
status=pThis->m_sinkMXF->PutMessage(pEvent);

Simple enough.  I always get the following bugcheck (see below for a trace
as well as the bugcheck).  Is
there a known issue here with DMUS ports/portcls, or, if not, can anyone
suggest anything?  Can I call the
allocator at DISPATCH?  Can I call PutMessage on the sink at DISPATCH?  I
tried doing this in a worker
thread, but got the same results.  If anyone has any ideas, please share.
Thanks.

Philip Lukidis

PS: I had Driver Verifier on, with all options except low resource
simulation, and verified portcls and my
own drivers.  With or without DV I had the same problem.


1: kd> !analyze -v
****************************************************************************
***
*
*
*                        Bugcheck Analysis
*
*
*
****************************************************************************
***

DRIVER_IRQL_NOT_LESS_OR_EQUAL (d1)
An attempt was made to access a pageable (or completely invalid) address at
an
interrupt request level (IRQL) that is too high.  This is usually
caused by drivers using improper addresses.
If kernel debugger is available get stack backtrace.
Arguments:
Arg1: 00000002, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000000, value 0 = read operation, 1 = write operation
Arg4: f7648de7, address which referenced memory

Debugging Details:
------------------


READ_ADDRESS:  00000002

CURRENT_IRQL:  2

FAULTING_IP:
portcls!CPackerMXF::ProcessQueues+64
f7648de7 0fb74a02         movzx   ecx,word ptr [edx+0x2]

DEFAULT_BUCKET_ID:  DRIVER_FAULT

BUGCHECK_STR:  0xD1

LAST_CONTROL_TRANSFER:  from 8042aa0f to 804564d0

STACK_TEXT:
eb427b58 8042aa0f 00000003 eb427ba0 00000002
nt!RtlpBreakWithStatusInstruction
eb427b88 8042b002 00000003 00000002 f7648de7 nt!KiBugCheckDebugBreak+0x31
eb427f14 8046987c 00000000 00000002 00000002 nt!KeBugCheckEx+0x390
eb427f14 f7648de7 00000000 00000002 00000002 nt!KiTrap0E+0x284
eb427fb8 f7648853 a6203fc4 a699fff0 f76487f4
portcls!CPackerMXF::ProcessQueues+0x64
eb427fc4 f76487f4 f764330e a698be90 820a8000
portcls!CPortPinDMus::ServeCapture+0x33
eb427fc8 f764330e a698be90 820a8000 aeda5f48
portcls!CPortPinDMus::RequestService+0x22
eb427fdc 80465728 a6203fa0 a6203f90 00000000
portcls!CServiceGroup::ServiceDpc+0x29
eb427ff4 8046ab4b eb447b18 00000000 00000000 nt!KiRetireDpcList+0x47


FOLLOWUP_IP:
portcls!CPackerMXF::ProcessQueues+64
f7648de7 0fb74a02         movzx   ecx,word ptr [edx+0x2]

FOLLOWUP_NAME:  MachineOwner

SYMBOL_NAME:  portcls!CPackerMXF::ProcessQueues+64

MODULE_NAME:  portcls

IMAGE_NAME:  portcls.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  3e9cd7ea

STACK_COMMAND:  kb

BUCKET_ID:  0xD1_portcls!CPackerMXF::ProcessQueues+64

Followup: MachineOwner
---------

******************

WDMAUDIODEV addresses:
Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx
Subscribe:    mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe
Unsubscribe:  mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
Moderator:    mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx

URL to WDMAUDIODEV page:
http://www.wdmaudiodev.de/
****************** WDMAUDIODEV addresses: Post message: mailto:wdmaudiodev@xxxxxxxxxxxxx Subscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=subscribe Unsubscribe: mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe Moderator: mailto:wdmaudiodev-moderators@xxxxxxxxxxxxx URL to WDMAUDIODEV page: http://www.wdmaudiodev.de/

Other related posts: