[wdmaudiodev] Re: question on DMUS UART
- From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Wed, 18 Feb 2004 08:19:57 -0500
When I have time I'll dig into my source control and recompile my MIDI and
bus drivers to what they were at the time of my incident. At best, I would
expect to not have a *deadlock* by releasing my spinlock before calling
PutMessage (correct me if I'm wrong please). I have not experienced any
deadlocks in my SMP testing. I'm certainly not defending my mistake, it is
clearly wrong to call a DDI while holding a spin lock (as well as deadlock
possibilities, I'm guessing that it violates the 25 us rule also). I'm just
not sure how this could cause a BSOD in the port driver. Also, the patch I
made to the port driver's DPC to force it to run on 1 CPU (see my other post
below) by calling KeSetTargetProcessorDpc when the port called
KeInitializeDpc still has me wondering about what is going on. However, I
also must also acknowledge that no one else has been having any problems.
Unfortunately I am extremely busy now, so I'm not sure when I could get to
testing this on my side. I'll post the results when I do.
Philip Lukidis
----- Original Message -----
From: "Philip Lukidis" <pagefault0x0@xxxxxxxxxxx>
To: <wdmaudiodev@xxxxxxxxxxxxx>
Sent: Tuesday, February 17, 2004 5:38 PM
Subject: [wdmaudiodev] Re: question on DMUS UART
> FWIW, I took a quick look at my old code. It appears that I did hold my
> spinlock while calling PutMessage. This was a DpcLevel spin lock which
> would not touch the IRQL. In any case, I should not have done this,
> clearly. I'm not sure my old DMUS driver would work anymore for testing,
as
> my bus driver below it has changed a fair bit since I last tested this.
>
> Philip Lukidis
>
> ----- Original Message -----
> From: "Matt Gonzalez" <matt@xxxxxxxxxxxxx>
> To: <wdmaudiodev@xxxxxxxxxxxxx>
> Sent: Tuesday, February 17, 2004 3:02 PM
> Subject: [wdmaudiodev] Re: question on DMUS UART
>
>
> > For what it's worth, our PCI cards use a DMUS miniport for MIDI I/O. It
> > works fine on dual processor 2000 & XP.
> >
> > I remember that there was a minor bug in the DDK sample with handling
> > PutMessage, but that was for MIDI output. That was a few years ago; I
> > don't remember the specifics. It's in the mailing list archive
somewhere.
> >
> > Reading through my code, I did notice that I don't hold my spinlock
> > during the call to PutMessage. That might make a difference.
> >
> > For what it's worth, here's the code. This is just a modified DDK
> > sample, so I don't think I'm giving away any trade secrets.
> >
> > STDMETHODIMP_(NTSTATUS)
> > CMiniportDMusStreamEcho::SourceEvtsToPort()
> > {
> > NTSTATUS ntStatus;
> > ECHOSTATUS Status;
> > DWORD dwMidiByte;
> > LONGLONG llNewTimestamp,llLastTimestamp;
> >
> > ASSERT(KeGetCurrentIrql() == DISPATCH_LEVEL);
> > //DOUT(DBG_PRINT, ("SourceEvtsToPort"));
> >
> > if (m_fCapture) // is capture running?
> > {
> > PDMUS_KERNEL_EVENT aDMKEvt,eventTail,eventHead;
> >
> > aDMKEvt = NULL;
> > eventTail = NULL;
> > eventHead = NULL;
> > ntStatus = STATUS_SUCCESS;
> > llLastTimestamp = 0;
> >
> > KeAcquireSpinLockAtDpcLevel(m_pMiniport->m_pSpinLock);
> >
> > do
> > {
> > //
> > // Get the next MIDI byte
> > //
> > Status =
> > m_pMiniport->m_pEG->ReadMidiByte(dwMidiByte,llNewTimestamp);
> >
> > if (ECHOSTATUS_OK == Status)
> > {
> > //
> > // Get another event from the allocator if necessary
> > //
> > if ( (NULL == eventHead) ||
> > (MAX_BYTES_PER_EVENT == aDMKEvt->cbEvent) ||
> > (llNewTimestamp != llLastTimestamp) )
> > {
> > //
> > // Get the new event & put it at the end of
> > // the linked list of capture events
> > //
> > (void) m_AllocatorMXF->GetMessage(&aDMKEvt);
> > if (!aDMKEvt)
> > {
> > DOUT(DBG_ERROR, ("SourceEvtsToPort can't
> > allocate DMKEvt"));
> > ntStatus = STATUS_INSUFFICIENT_RESOURCES;
> > break;
> > }
> >
> > // put this event at the end of the list
> > aDMKEvt->pNextEvt = NULL;
> > if (!eventHead)
> > {
> > eventHead = aDMKEvt;
> > }
> > else
> > {
> > eventTail = eventHead;
> > while (eventTail->pNextEvt)
> > {
> > eventTail = eventTail->pNextEvt;
> > }
> > eventTail->pNextEvt = aDMKEvt;
> > }
> >
> > aDMKEvt->cbEvent = 0;
> > aDMKEvt->usChannelGroup = 1;
> > aDMKEvt->usFlags = DMUS_KEF_EVENT_INCOMPLETE;
> > aDMKEvt->ullPresTime100ns = llNewTimestamp;
> >
> > llLastTimestamp = llNewTimestamp;
> > }
> >
> > //
> > // Put the MIDI byte into the current event
> > //
> > if (aDMKEvt)
> > {
> > aDMKEvt->uData.abData[aDMKEvt->cbEvent] = (BYTE)
> > dwMidiByte;
> > aDMKEvt->cbEvent++;
> > }
> > }
> >
> > } while (ECHOSTATUS_OK == Status);
> >
> > KeReleaseSpinLockFromDpcLevel(m_pMiniport->m_pSpinLock);
> >
> > //
> > // Dump the event queue back to the allocator
> > //
> > if (NULL != eventHead)
> > {
> > (void)m_sinkMXF->PutMessage(eventHead);
> > }
> >
> > }
> > else // render stream
> > {
> > DOUT(DBG_ERROR,("SourceEvtsToPort called on render stream"));
> > ntStatus = STATUS_INVALID_DEVICE_REQUEST;
> > }
> > return ntStatus;
> > }
> >
> > Hope that helps-
> >
> > Matt
> >
> > >From: wdmaudiodev-bounce@xxxxxxxxxxxxx
> > >[mailto:wdmaudiodev-bounce@xxxxxxxxxxxxx] On Behalf Of Philip Lukidis
> > >Sent: Friday, November 28, 2003 7:22 AM
> > >To: wdmaudiodev@xxxxxxxxxxxxx
> > >Subject: [wdmaudiodev] Re: question on DMUS UART
> > >
> > >
> > >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.
> > >
> > >
> > >
> >
> > ******************
> >
> > 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:
