Hello Robert.
Yes, it is perplexing, but WPP traces give me a hope in finding it, even if
the last trace session topped 12MB after uncompressing (at 96k that’s a lot
of traces). Without WPP traces it would be so much more daunting.
In answer to your question, no, rebooting is not necessary to get some
operation; restarting the streaming process can help (this is application
based, e.g. WMP, Cubase, etc).
I do thank you a lot for your suggestions. What I will do next is cease
reusing descriptors, IRPs, IRBs, MDLs and buffers, and/or check at each
isoch DMA callback that the fields of all these structures are still
properly initialized. Perhaps OHCI has overwritten them, which might
explain why callbacks cease (e.g. OHCI overwrites
PBUS_ISOCH_DESCRIPTOR_ROUTINE Callback field in ISOCH_DESCRIPTOR).
In any case, I do thank you for your suggestions, and if I hear anything
from MS about bus resets and SP2, or the explanation for this issue, I’ll
post ASAP.
thanks again,
Philip Lukidis
-----Original Message-----
From: Robert Newton
To: Windows System Software Devs Interest List
Sent: 02/15/2005 7:18 PM
Subject: Re[10]: [ntdev] 1394 talk/listen DMA buffer alignment requirem
ents?
Philip,
Bizarre problem. I’m afraid that I’m out of ideas. It is always
difficult to debug stuff on a customers machine when the problem can’t
be reproduced. I agree that the fact that it only turns up at 96k
would seem to indicate that the machine, itself, is not at fault.
When the problem occurs do you have to reboot to get back to proper
operation or do you reattach your device or can you simply restart the
user application?
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