Good grief, please disregard this particular question! MmPrepareMdlForReuse
is merely a macro, and it is obvious that I don’t need to use it. Sorry for
the extra traffic for nothing.
Philip Lukidis
-----Original Message-----
From: Philip Lukidis
Sent: Monday, February 14, 2005 4:50 PM
To: ‘Windows System Software Devs Interest List’
Subject: RE: Re[4]: [ntdev] 1394 talk/listen DMA buffer alignment
requirem ents?
I do reuse my buffers and MDLs for both talk and listen, without problem
with the checked HAL/kernel/ohci1394.sys/1394bus.sys. Concerning the MDLs,
they describe buffers allocated via ExAllocatePool (NonPagedPool), with
MmBuildMdlForNonPagedPool called on them. Therefore, I don’t believe that I
need to use MmPrepareMdlForReuse when reusing these MDLs.
MmGetSystemAddressForMdlSafe is pretty much a nop for this, and just returns
the embedded system address (no mapping required). Can anyone confirm this,
that MmPrepareMdlForReuse is not required here for MDL reuse, under any
conceivable circumstances?
thanks,
Philip Lukidis
-----Original Message-----
From: Philip Lukidis
Sent: Monday, February 14, 2005 4:27 PM
To: Windows System Software Devs Interest List
Subject: RE: Re[4]: [ntdev] 1394 talk/listen DMA buffer alignment
requirem ents?
Hello again Robert, I had missed your post last week somehow…
Anyhow, I can confirm the “double bus reset” here for SP2, and not for SP1.
I believe that you’re right; it sounds like a bug, so let’s see if MS will
respond here. Perhaps you could try emailing xxxxx@microsoft.com for a quick
answer. In the past, xxxxx@microsoft.com did reply to questions, yet no one
has replied to my buffer alignment question (I did email that address). I
do understand that there is no guarantee of service via this avenue, but I
was merely hopeful due to past responses.
For my talk DMA stopping issue, it remains the case that this one user
reports that when I force page alignment, and no page boundary straddling,
his 96k streaming is much more robust, but perhaps this is only incidentally
related. Concerning the talk DMA stopping, I tried your suggestion of
starting talk on each attach, and in fact it makes the situation worse on my
test machine- the audio became quite grainy throughout. If you could
otherwise suggest why talk DMA could cease while buffers are still attached,
I’d appreciate it greatly. In either case, I wish you luck with your SP2
bus reset surprise removal issue (which I share!), and if I learn anything
about this, I will post ASAP to this list.
thanks for your reply,
Philip Lukidis
PS: I tested on SP2 with checked kernel + check HAL + check OHCI1394/1394BUS
drivers, but no further insights/ASSERTs yet.
-----Original Message-----
From: Robert Newton [mailto:xxxxx@telusplanet.net]
Sent: Thursday, February 10, 2005 5:43 PM
To: Windows System Software Devs Interest List
Subject: Re[4]: [ntdev] 1394 talk/listen DMA buffer alignment requirem
ents?
Philip,
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.
That is interesting. I have noted exactly the same problem, on
occation, with my device and SP2. This problem has generally occurred
when using a laptop but that is likely just coincidence. I’ve also had
lots of other problems and while I’m currently handling most of them
okay we are currently discouraging our users from moving to SP2 for
the time being. Another problem on SP2 is that after every bus reset
there is a second “echo” reset. This effectively makes it impossible
to have your driver force the host to be root (I think I will report
this as a bug as MS provides the interface to force the host to be
root and this interface is now essentially broken).
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 do it because it was difficult for me to know whether or not it was
required. It bothered me to be making a call that many times wouldn’t
be needed but I was lazy and wanted to avoid race conditions.
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
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