Hi Robert, thanks for your feedback. All my descriptor buffers, talk and
listen are integral multiples of my packet sizes. All my buffers now start
on a page boundary, and do not (for now) cross page boundaries, though your
note is encouraging. I was doubtful whether I faced a DMA buffer alignment
issue, because initially talk callbacks are called, and I reuse all of my
buffers, talk and listen.
Bus resets are dealt with fine in my driver in SP1, but *sometimes* in SP2,
a bus reset causes the PnP manager to unload my driver. Perhaps the device
did not respond quickly enough to the async read requests from the host
after the reset? Is this the issue to which you were alluding? IIRC, in
this case my busreset routine was not even called, but I would have to
confirm this. There were no problems whatsoever in WinXP SP1 in dealing
with bus resets.
However no bus resets were logged in the WPP traces when the user was
playing the audio file (a 96k sampled sin wave) which produces the issue.
Perhaps I should try to REQUEST_ISOCH_TALK after I attach each buffer (like
you do for listen), although I don’t understand why this would be necessary,
because at no time was there a period during which no talk buffers were
attached. Do you call REQUEST_ISOCH_LISTEN after each attach because you
know there was a period during which no listen buffers were attached?
I will try this on my end.
thanks for your feedback,
Philip Lukidis
-----Original Message-----
From: Robert Newton [mailto:xxxxx@telusplanet.net]
Sent: Thursday, February 10, 2005 4:44 PM
To: Windows System Software Devs Interest List
Subject: Re[2]: [ntdev] 1394 talk/listen DMA buffer alignment
requirements?
Philip,
Hi Robert, thanks for your reply. Out of curiosity, did any of your
buffers
ever cross page boundaries? If so, were there issues with that?
My buffers are usually 188928 bytes long so yes they cross page
boundaries and no this has never caused a problem. I did, in the past,
have problems when they didn’t start on page boundaries. As I
mentioned I have no recent testing of this.
I have absolutely no problem with listen, but with talk. Of course, it
only
occurs on one customer’s machine (laptop, WinXP Prof. SP2), and only at
one
sample rate (96k). The symptom exposed by WPP traces is that talk
callbacks
stop being called (DMA simply stop?), and eventually the maximum number of
talk packets are attached, with no talk callbacks being called. There are
no errors in attach/detach completion routines at all. Of course, I have
never seen this on any of my test machines, UP, SMP, or HT; it would be
too
easy.Do you have any idea why DMA on talk would just stop? For sure it is not
being starved; WPP traces confirm this, buffers are being attached. The
only reason I could think of was a buffer_alignment/page_boundary_crossing
issue, but this itself seems fairly unlikely, because I reuse all of my
talk/listen descriptors/MDLs/buffers, and initially talk callbacks are
being
called. Any ideas?
I’ve done talk but very little and only for test purposes. When
attaching buffers for listening I always follow the operation with a
REQUEST_ISOCH_LISTEN to ensure no starvation problems.
When doing a listen I did discover that if the buffer size does not
divide into an integral number of packets it would be filled okay but
I would receive no callback when the buffer was full but this doesn’t
seem to relate to your problem.
I have had lots of issues with XP sp2 especially with regard to bus
resets. A spurious bus reset may possibly stop things if it is not
handled correctly. Are you tracking and dealing with resets?
Robert Newton
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@guillemot.com
To unsubscribe send a blank email to xxxxx@lists.osr.com