[wdmaudiodev] Re: question on DMUS UART
- From: "Martin Puryear" <martinp@xxxxxxxxxxxxxxxxxxxxx>
- To: <wdmaudiodev@xxxxxxxxxxxxx>
- Date: Tue, 17 Feb 2004 09:18:24 -0800
I don't see any response here from anyone, so I believe we must just
have a synchronization error in the DMUS port.
Philip, if this is a blocking issue for you, you should contact Richard
Fricks (RichFr) to open up a service request (QFE).
We (MS) will also open up a bug to fix this in the next OS release (or
sooner in an XP Service Pack, if there is corroborating data in our
Online Crash Analysis database).
Thanks Philip, and sorry for the trouble,
MartinPuryear
Group Development Manager
Audio/Video Platform and Media Devices Framework
Windows Digital Media Division
________________________________
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.
----- Original Message -----
From: Philip Lukidis <mailto:pagefault0x0@xxxxxxxxxxx>
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 <mailto:pagefault0x0@xxxxxxxxxxx>
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
<mailto:developer@xxxxxxxxxxxxxx>
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->ullPresTime10
0ns)
;
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
<mailto:wdmaudiodev-request@xxxxxxxxxxxxx%3Fsubject=subscribe>
Unsubscribe:
mailto:wdmaudiodev-request@xxxxxxxxxxxxx?subject=unsubscribe
<mailto:wdmaudiodev-request@xxxxxxxxxxxxx%3Fsubject=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:
