[wdmaudiodev] Re: question on DMUS UART

  • From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
  • To: <wdmaudiodev@xxxxxxxxxxxxx>
  • Date: Fri, 28 Nov 2003 10:21:50 -0500

OK...I patched portcls's call to KeInitializeDpc with my driver's routine, 
which called KeInitializeDpc with the passed parameters, and then called 
KeSetTargetProcessorDpc, making sure to pass a mask of 0.  So far it works fine 
(previously it would crash right away or in less than 1 minute or so).

This would seem to point to some synchronization problem on the part of the 
DMUS port.  So again I ask did anyone get DMUSUART to work on multiple CPUs?  
Thanks.

Philip Lukidis

PS: I'll run it over the weekend here with driver verifier verifying 
portcls.sys, with all options except low resources and DMA checking.
  ----- Original Message ----- 
  From: Philip Lukidis 
  To: wdmaudiodev@xxxxxxxxxxxxx 
  Sent: Friday, November 28, 2003 8:56 AM
  Subject: [wdmaudiodev] Re: question on DMUS UART


  Thanks Devendra for your advice, but unfortunately I still have the issue.  
My DPC buffers the MIDI data onto a spinlock protected list, and calls notify, 
which calls PutMessage on my capture stream, which then calls GetMessage on the 
allocator, fills up the event with the buffered MIDI data, and calls PutMessage 
on the sink with the newly filled event.  Works fine with 1 CPU enabled.  I get 
the same BSOD with 2 CPUs, namely portcls's DPC which processes the lists 
BSODs.  

  Devendra (or anyone), if you got DMUSUART working on SMP (not HT) machines, 
then I would start to wonder if *I* am committing some error.  Please confirm 
that you got it working under dual CPU (not HT) machines.

  Thanks very much for your reply,

  Philip Lukidis

    ----- Original Message ----- 
    From: Philip Lukidis 
    To: wdmaudiodev@xxxxxxxxxxxxx 
    Sent: Friday, November 28, 2003 7:51 AM
    Subject: [wdmaudiodev] Re: question on DMUS UART


    Devendra, thanks very much for your insight.  Since I used a different 
source base than the DDK sample, I'll check it out to see how it would map to 
my case.

    Again, thanks very much for your reply.  I'll post the results here.  I had 
actually started porting over to IMiniportMidi, but now I'll try this out first.

    Philip Lukidis

    ----- Original Message ----- 
      From: BlazeAudio Developer 
      To: wdmaudiodev@xxxxxxxxxxxxx 
      Sent: Thursday, November 27, 2003 11:30 PM
      Subject: [wdmaudiodev] Re: question on DMUS UART


      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: