[wdmaudiodev] Re: question on DMUS UART

  • From: "Martin Puryear" <martinp@xxxxxxxxxxxxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Wed, 26 Nov 2003 14:06:02 -0800

Yes, this could be the case.  
If a defect is found in the sample or miniport (especially if you have a
fix in hand!), please let RichFr and HakonS know, and we can get the DDK
updated.    You should also include whether you experience this problem
on HyperThreaded uniproc systems.

Also, Philip could you send HakonS and RichFr a kernel-mode dump file of
this crash?  That way we can correlate this problem to crash counts in
OCA, to lend credence when we lobby to include a fix in XPSP2 (or
whenever).

-----Original Message-----
From: wdmaudiodev-bounce@xxxxxxxxxxxxx
[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Matt Gonzalez
Sent: Wednesday, November 26, 2003 1:56 PM
To: wdmaudiodev@xxxxxxxxxxxxx
Subject: [wdmaudiodev] Re: question on DMUS UART

I think there's a problem with the sample code and PutMessage.  Look
back through the archives on the list; this was discussed at some
length.

Matt

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->ullPresTime1
>00ns)
>;
>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/

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

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: