Thomas
Thu Apr 13 22:27:19 CDT 2006
"Alireza Dabagh [MS]" <alid@online.microsoft.com> wrote in message
news:443f0ba9$1@news.microsoft.com...
> Thomas, my point was to stress that NDIS -always- sterilizes requests to
> miniports.
>>The bug is in NDIS as you said.
> Was this a typo!? The bug would be in the miniport driver and not NDIS.
>
Surely the bug is in the miniport edge of the NDIS IM driver. However, when
the fault caused by this bug occurs the faulting driver is not in any stack
trace. So, it take a little time to track down.
> Point on testability taken. I believe we explicitly say having a reset
> handler is optional for NDIS 6 IM drivers. If not, please let me know and
> I will take care of document.
I will look at NDIS 6 in this area. Do remember that NDIS 5 will be around
for many years. If reset handler is optional for NDIS 5 IM driver (like the
Passthru driver implies...), then some errata may help developers over the
next few years.
Warmest regards,
Thomas F. Divine
>
> -ali
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>
> "Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
> news:e4w3EhyXGHA.5004@TK2MSFTNGP02.phx.gbl...
>> Ali,
>>
>> You are certainly correct about the situation where this crash occurs.
>>
>> Unfortunately, it is very easy to build a driver that will cause this
>> crash - rarely. So rarely that it is hardly noticed and difficult to
>> debug.
>>
>> For example, the Passthru NDIS IM driver sample (great sample!) does not
>> have a MPReset function. Because of this omission, the baseline Passthru
>> driver does not exhibit this problem.
>>
>> Unfortunately, the DDK specifies that NDIS IM drivers _MUST_ have a
>> MPReset callback. So, add a stub MPReset that simply reports
>> NDIS_STATUS_SUCCESS. All done? Requirement satisfied? Actually not...
>>
>> If you add a stub MPReset to Passthru it will _almost_ never have a
>> problem. Unfortunately, there is the crash that you mentioned when 1.)
>> MPReset is called and 2.) there is an uncompleted NDIS request pending.
>>
>> This crash is so rare that you can actually pass the NDIS Tester NDIS IM
>> tests _most_ of the time. In fact, you can almost certainly make a
>> successful NDSI IM test submission without hitting this bug. In normal
>> operation, a driver with this bug can operate for months since resets are
>> rare and resets with a pending query pending are even rarer.
>>
>> However, if you put NDIS Tester in a loop on the 1c_Reset test you will
>> see it. When it happens, it is not in the NDIS IM driver being tested.
>> The bug is in NDIS as you said. So, it is a little tough to track down -
>> especially for newbies.
>>
>> Thanks for your time on this list!
>>
>> Thomas
>>
>>
>> "Alireza Dabagh [MS]" <alid@online.microsoft.com> wrote in message
>> news:unZW3MtXGHA.4212@TK2MSFTNGP02.phx.gbl...
>>> Thomas, wasn't the query OID submitted before the reset and driver
>>> by -not- completing the request before completing the reset actually
>>> left it to NDIS to abort the request on behalf of the driver? (i.e.
>>> driver completed the request "implicitly" allowing NDIS to send the next
>>> one)
>>>
>>> For all I know NDIS will bugcheck if you ever complete a request that it
>>> does not expect which given NDIS 5.x semantics means it strictly has to
>>> serialize the requests.
>>>
>>> -ali
>>>
>>> --
>>> This posting is provided "AS IS" with no warranties, and confers no
>>> rights.
>>> "Thomas F. Divine [DDK MVP]" <tdivine@NOpcausaSPAM.com> wrote in message
>>> news:erakPlqWGHA.1192@TK2MSFTNGP04.phx.gbl...
>>>>
>>>> "Maxim S. Shatskih" <maxim@storagecraft.com> wrote in message
>>>> news:uamkcZqWGHA.404@TK2MSFTNGP05.phx.gbl...
>>>>> Only 1 OID request can be pending on a miniport instance, so, all
>>>>> is fine.
>>>>>
>>>>> (well, maybe you can have 1 query and 1 set OID request
>>>>> simultaneously, but
>>>>> I'm not sure of it)
>>>>>
>>>> Max,
>>>>
>>>> I have recently seen 1 query and one (maybe more) set simultaneously -
>>>> but only after MiniportReset is called and the MP returns
>>>> AddressingReset = TRUE.
>>>>
>>>> I _think_ that NDIS spawns a worker thread to restore addressing
>>>> information by making set calls to restore packet filter and multi-cast
>>>> list after MPReset returns. Ordinary serialized queries come in through
>>>> a different route. _Rarely_ I saw them concurently. I have only seen
>>>> this running NDIS Tester's Reset test. There the test passes most of
>>>> the time BUT occasionally can exhibit this 1 set/1 query behavior if
>>>> timing is just right.
>>>>
>>>> Thomas F. Divine
>>>>
>>>>
>>>
>>>
>>
>
>