LAN91C111 driver

We are experiencing a problem with the LAN91C111 similar to what would be
expected of an intermediate driver that invokes the NdisMSetAttributes method
rather than the NdisMSetAttributesEx method passing in the flag
INTERMEDIATE_DRIVER, that is a rare but intermittent hang in NDIS. What
exactly is meant by the term intermediate? We pulled the source code off the
internet.

Thanks

I found a ridiculous comment that indicates to me that the developer was
somewhat clueless:

In the meantime, I suggest using lots of caution if you need
to modify the mini-port handler as it seems awfully touchy.

That tells me the developer never really figured out what was causing the
problem to begin with, but just tried a bunch of different things, and
figured that as long as his executable doesn't break, it is fixed.

Valter
Mon Feb 04 09:16:41 PST 2008

=?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
news:C97A115A-1ADA-4059-BED2-1A69EC419A34@microsoft.com:

> We are experiencing a problem with the LAN91C111 similar to what
> would be expected of an intermediate driver that invokes the
> NdisMSetAttributes method rather than the NdisMSetAttributesEx
> method passing in the flag INTERMEDIATE_DRIVER, that is a rare but
> intermittent hang in NDIS. What exactly is meant by the term
> intermediate? We pulled the source code off the internet.
[...]

IIRC that device uses level-based IRQs and you may have problems if
your processor handles only (or is configured to handle) edge-based
IRQs.



--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Dan
Mon Feb 04 11:15:05 PST 2008

That's interesting because the documentation specifies that The Ethernet
interrupt is conceptually equivalent to the LAN91C94 which specifies in its
COR
register that it is level based, however, the hang does not occur in
miniport code. It occurs some time between when it exits the miniport ISR and
when it invokes the Miniport HandleInterrupt method. It is rare, but the
system does indeed lock up intermittently. We currently detect both rising
edge and falling edge on the GPIO that goes to the LAN IRQ line, and it works
for a few hundred attempts, before crashing.

Thanks

"Valter Minute" wrote:

> =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
> news:C97A115A-1ADA-4059-BED2-1A69EC419A34@microsoft.com:
>
> > We are experiencing a problem with the LAN91C111 similar to what
> > would be expected of an intermediate driver that invokes the
> > NdisMSetAttributes method rather than the NdisMSetAttributesEx
> > method passing in the flag INTERMEDIATE_DRIVER, that is a rare but
> > intermittent hang in NDIS. What exactly is meant by the term
> > intermediate? We pulled the source code off the internet.
> [...]
>
> IIRC that device uses level-based IRQs and you may have problems if
> your processor handles only (or is configured to handle) edge-based
> IRQs.
>
>
>
> --
> Valter Minute
> www.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)
>

Dean
Mon Feb 04 11:27:28 PST 2008

Rising and falling edge isn't good enough for this part. It will fail if
you don't handle level interrupts...

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Dan" <Dan@discussions.microsoft.com> wrote in message
news:E9CD7259-6840-403A-9A60-110285EE5EC1@microsoft.com...
> That's interesting because the documentation specifies that The Ethernet
> interrupt is conceptually equivalent to the LAN91C94 which specifies in
> its
> COR
> register that it is level based, however, the hang does not occur in
> miniport code. It occurs some time between when it exits the miniport ISR
> and
> when it invokes the Miniport HandleInterrupt method. It is rare, but the
> system does indeed lock up intermittently. We currently detect both rising
> edge and falling edge on the GPIO that goes to the LAN IRQ line, and it
> works
> for a few hundred attempts, before crashing.
>
> Thanks
>
> "Valter Minute" wrote:
>
>> =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
>> news:C97A115A-1ADA-4059-BED2-1A69EC419A34@microsoft.com:
>>
>> > We are experiencing a problem with the LAN91C111 similar to what
>> > would be expected of an intermediate driver that invokes the
>> > NdisMSetAttributes method rather than the NdisMSetAttributesEx
>> > method passing in the flag INTERMEDIATE_DRIVER, that is a rare but
>> > intermittent hang in NDIS. What exactly is meant by the term
>> > intermediate? We pulled the source code off the internet.
>> [...]
>>
>> IIRC that device uses level-based IRQs and you may have problems if
>> your processor handles only (or is configured to handle) edge-based
>> IRQs.
>>
>>
>>
>> --
>> Valter Minute
>> www.fortechembeddedlabs.it
>> Training, support and development for Windows CE
>> (the reply address of this message is invalid)
>>

Dan
Mon Feb 04 12:09:00 PST 2008

Good. That's a step in the right direction. Out of curiosity, what would the
nature of that failure look like? I couldn't trace the deadlock to any of the
miniport methods, where I would expect such a failure to have an impact. NDIS
stops invoking the miniport CheckForHang method whenever the system freezes
up. I would expect such a failure to cause the system to hang, the first time
it reaches a while loop that reads from the LAN chip.

Thanks,


"Dean Ramsier" wrote:

> Rising and falling edge isn't good enough for this part. It will fail if
> you don't handle level interrupts...
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "Dan" <Dan@discussions.microsoft.com> wrote in message
> news:E9CD7259-6840-403A-9A60-110285EE5EC1@microsoft.com...
> > That's interesting because the documentation specifies that The Ethernet
> > interrupt is conceptually equivalent to the LAN91C94 which specifies in
> > its
> > COR
> > register that it is level based, however, the hang does not occur in
> > miniport code. It occurs some time between when it exits the miniport ISR
> > and
> > when it invokes the Miniport HandleInterrupt method. It is rare, but the
> > system does indeed lock up intermittently. We currently detect both rising
> > edge and falling edge on the GPIO that goes to the LAN IRQ line, and it
> > works
> > for a few hundred attempts, before crashing.
> >
> > Thanks
> >
> > "Valter Minute" wrote:
> >
> >> =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
> >> news:C97A115A-1ADA-4059-BED2-1A69EC419A34@microsoft.com:
> >>
> >> > We are experiencing a problem with the LAN91C111 similar to what
> >> > would be expected of an intermediate driver that invokes the
> >> > NdisMSetAttributes method rather than the NdisMSetAttributesEx
> >> > method passing in the flag INTERMEDIATE_DRIVER, that is a rare but
> >> > intermittent hang in NDIS. What exactly is meant by the term
> >> > intermediate? We pulled the source code off the internet.
> >> [...]
> >>
> >> IIRC that device uses level-based IRQs and you may have problems if
> >> your processor handles only (or is configured to handle) edge-based
> >> IRQs.
> >>
> >>
> >>
> >> --
> >> Valter Minute
> >> www.fortechembeddedlabs.it
> >> Training, support and development for Windows CE
> >> (the reply address of this message is invalid)
> >>
>
>
>

Dean
Mon Feb 04 12:45:00 PST 2008

I don't recall anymore. I do remember that until level interrupts were
properly handled the driver was not reliable. Doesn't help you though ...

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Dan" <Dan@discussions.microsoft.com> wrote in message
news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com...
> Good. That's a step in the right direction. Out of curiosity, what would
> the
> nature of that failure look like? I couldn't trace the deadlock to any of
> the
> miniport methods, where I would expect such a failure to have an impact.
> NDIS
> stops invoking the miniport CheckForHang method whenever the system
> freezes
> up. I would expect such a failure to cause the system to hang, the first
> time
> it reaches a while loop that reads from the LAN chip.
>
> Thanks,
>
>
> "Dean Ramsier" wrote:
>
>> Rising and falling edge isn't good enough for this part. It will fail if
>> you don't handle level interrupts...
>>
>> --
>> Dean Ramsier - eMVP
>> BSQUARE Corporation
>>
>>
>> "Dan" <Dan@discussions.microsoft.com> wrote in message
>> news:E9CD7259-6840-403A-9A60-110285EE5EC1@microsoft.com...
>> > That's interesting because the documentation specifies that The
>> > Ethernet
>> > interrupt is conceptually equivalent to the LAN91C94 which specifies in
>> > its
>> > COR
>> > register that it is level based, however, the hang does not occur in
>> > miniport code. It occurs some time between when it exits the miniport
>> > ISR
>> > and
>> > when it invokes the Miniport HandleInterrupt method. It is rare, but
>> > the
>> > system does indeed lock up intermittently. We currently detect both
>> > rising
>> > edge and falling edge on the GPIO that goes to the LAN IRQ line, and it
>> > works
>> > for a few hundred attempts, before crashing.
>> >
>> > Thanks
>> >
>> > "Valter Minute" wrote:
>> >
>> >> =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
>> >> news:C97A115A-1ADA-4059-BED2-1A69EC419A34@microsoft.com:
>> >>
>> >> > We are experiencing a problem with the LAN91C111 similar to what
>> >> > would be expected of an intermediate driver that invokes the
>> >> > NdisMSetAttributes method rather than the NdisMSetAttributesEx
>> >> > method passing in the flag INTERMEDIATE_DRIVER, that is a rare but
>> >> > intermittent hang in NDIS. What exactly is meant by the term
>> >> > intermediate? We pulled the source code off the internet.
>> >> [...]
>> >>
>> >> IIRC that device uses level-based IRQs and you may have problems if
>> >> your processor handles only (or is configured to handle) edge-based
>> >> IRQs.
>> >>
>> >>
>> >>
>> >> --
>> >> Valter Minute
>> >> www.fortechembeddedlabs.it
>> >> Training, support and development for Windows CE
>> >> (the reply address of this message is invalid)
>> >>
>>
>>
>>

Valter
Tue Feb 05 01:18:30 PST 2008

=?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com:

> Good. That's a step in the right direction. Out of curiosity, what
> would the nature of that failure look like?

Usually the device is requesting an interrupt and the processor is not
servicing it because the front it occourred while the interrupt was
disabled and so it was not reported.
If you service the interrupt and then re-enable edge detect on the pin
you may miss an interrupt if the interrupt is signaled after you
checked the interrupts register of the device and before you re-enable
edge detect.


--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Dan
Tue Feb 05 07:33:03 PST 2008

Then I guess we'll have to get the hardware engineer to replace this chip
with one that uses edge detection IRQs. It's either that or replace the
microcontroller (we use XScale PXA270) with one that has this level based
detection capability. I have a feeling management is more likely to approve
replacing the LAN chip.

Thanks

"Valter Minute" wrote:

> =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
> news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com:
>
> > Good. That's a step in the right direction. Out of curiosity, what
> > would the nature of that failure look like?
>
> Usually the device is requesting an interrupt and the processor is not
> servicing it because the front it occourred while the interrupt was
> disabled and so it was not reported.
> If you service the interrupt and then re-enable edge detect on the pin
> you may miss an interrupt if the interrupt is signaled after you
> checked the interrupts register of the device and before you re-enable
> edge detect.
>
>
> --
> Valter Minute
> www.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)
>

Paul
Tue Feb 05 07:47:28 PST 2008

Some of the newer SMC chips have the ability to do things that will work
with edge-based interrupt processors. Take a look at the datasheets and I
think you might even find one that's close to pin-compatible, which your
hardware guy will certainly appreciate.

Paul T.

"Dan" <Dan@discussions.microsoft.com> wrote in message
news:6882CC86-3BA1-412E-961C-E5BF3CCF63EE@microsoft.com...
> Then I guess we'll have to get the hardware engineer to replace this chip
> with one that uses edge detection IRQs. It's either that or replace the
> microcontroller (we use XScale PXA270) with one that has this level based
> detection capability. I have a feeling management is more likely to
> approve
> replacing the LAN chip.
>
> Thanks
>
> "Valter Minute" wrote:
>
>> =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
>> news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com:
>>
>> > Good. That's a step in the right direction. Out of curiosity, what
>> > would the nature of that failure look like?
>>
>> Usually the device is requesting an interrupt and the processor is not
>> servicing it because the front it occourred while the interrupt was
>> disabled and so it was not reported.
>> If you service the interrupt and then re-enable edge detect on the pin
>> you may miss an interrupt if the interrupt is signaled after you
>> checked the interrupts register of the device and before you re-enable
>> edge detect.
>>
>>
>> --
>> Valter Minute
>> www.fortechembeddedlabs.it
>> Training, support and development for Windows CE
>> (the reply address of this message is invalid)
>>

Valter
Tue Feb 05 09:41:19 PST 2008

=?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
news:6882CC86-3BA1-412E-961C-E5BF3CCF63EE@microsoft.com:

> Then I guess we'll have to get the hardware engineer to replace
> this chip with one that uses edge detection IRQs. It's either that
> or replace the microcontroller (we use XScale PXA270) with one
> that has this level based detection capability. I have a feeling
> management is more likely to approve replacing the LAN chip.

Usually such a massive rework isn't required. You can put in some
"glue logic" to generate an edge when a level is in the same state for
more than a few uSeconds or work around the problem in software re-
enabling the edge detect before you clean the interrupt on the device
or using a timer to generate an interrupt after you re-enable the edge
detect to check that the interrupt pin is not already stuck in the
interrupt level.
In both cases you will lose some performance but if you don't need
full ethernet troughput, that could be better than a re-enginering of
your board.

--
Valter Minute
www.fortechembeddedlabs.it
Training, support and development for Windows CE
(the reply address of this message is invalid)

Dan
Tue Feb 05 11:27:01 PST 2008

The hardware engineer wants to know why it was working before we included MDD
interrupts. We never experienced a failure, when that interrupt was disabled,
and we do not disable edge detect when handling the MDD. I still don't
understand why missing an interrupt would cause the system to hang. Worst
case scenario, I would expect the miniport checkforhang method to return true
and the miniport reset method would then be fired. CheckForHang is getting
invoked every 2 seconds until the system deadlocks. That is NDIS's
responsibility, and I don't understand how any problems with handling the
interrupts would cause this kind of lockup. BTW, MDD interrupts are still
fired every twenty seconds, even after the lockup.

"Dan" wrote:

> Then I guess we'll have to get the hardware engineer to replace this chip
> with one that uses edge detection IRQs. It's either that or replace the
> microcontroller (we use XScale PXA270) with one that has this level based
> detection capability. I have a feeling management is more likely to approve
> replacing the LAN chip.
>
> Thanks
>
> "Valter Minute" wrote:
>
> > =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
> > news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com:
> >
> > > Good. That's a step in the right direction. Out of curiosity, what
> > > would the nature of that failure look like?
> >
> > Usually the device is requesting an interrupt and the processor is not
> > servicing it because the front it occourred while the interrupt was
> > disabled and so it was not reported.
> > If you service the interrupt and then re-enable edge detect on the pin
> > you may miss an interrupt if the interrupt is signaled after you
> > checked the interrupts register of the device and before you re-enable
> > edge detect.
> >
> >
> > --
> > Valter Minute
> > www.fortechembeddedlabs.it
> > Training, support and development for Windows CE
> > (the reply address of this message is invalid)
> >

Dean
Tue Feb 05 13:14:21 PST 2008

Different traffic during the test scenarios? Maybe it wasn't working as
well as you thought?

The bottom line is this device has a level sensitive interrupt. The PXA270
doesn't support level interrupts in hardware. In order to make the two
compatible you have to either change the hardware to artificially create
edges or change the software (OAL) to detect that another interrupt is
necessary and somehow generate one.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Dan" <Dan@discussions.microsoft.com> wrote in message
news:4B216E77-1208-4E20-AEE3-BC57279B64E1@microsoft.com...
> The hardware engineer wants to know why it was working before we included
> MDD
> interrupts. We never experienced a failure, when that interrupt was
> disabled,
> and we do not disable edge detect when handling the MDD. I still don't
> understand why missing an interrupt would cause the system to hang. Worst
> case scenario, I would expect the miniport checkforhang method to return
> true
> and the miniport reset method would then be fired. CheckForHang is getting
> invoked every 2 seconds until the system deadlocks. That is NDIS's
> responsibility, and I don't understand how any problems with handling the
> interrupts would cause this kind of lockup. BTW, MDD interrupts are still
> fired every twenty seconds, even after the lockup.
>
> "Dan" wrote:
>
>> Then I guess we'll have to get the hardware engineer to replace this chip
>> with one that uses edge detection IRQs. It's either that or replace the
>> microcontroller (we use XScale PXA270) with one that has this level based
>> detection capability. I have a feeling management is more likely to
>> approve
>> replacing the LAN chip.
>>
>> Thanks
>>
>> "Valter Minute" wrote:
>>
>> > =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
>> > news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com:
>> >
>> > > Good. That's a step in the right direction. Out of curiosity, what
>> > > would the nature of that failure look like?
>> >
>> > Usually the device is requesting an interrupt and the processor is not
>> > servicing it because the front it occourred while the interrupt was
>> > disabled and so it was not reported.
>> > If you service the interrupt and then re-enable edge detect on the pin
>> > you may miss an interrupt if the interrupt is signaled after you
>> > checked the interrupts register of the device and before you re-enable
>> > edge detect.
>> >
>> >
>> > --
>> > Valter Minute
>> > www.fortechembeddedlabs.it
>> > Training, support and development for Windows CE
>> > (the reply address of this message is invalid)
>> >

Dean
Tue Feb 05 13:20:51 PST 2008

By the way, it's a simple enough check. Look at the interrupt line after
the lockup; if it's active you missed an edge. Since the interrupt is
waiting to be serviced, it will not de-assert and you will never again get
another interrupt from the device.

--
Dean Ramsier - eMVP
BSQUARE Corporation


"Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
news:OLOY7uDaIHA.4180@TK2MSFTNGP06.phx.gbl...
> Different traffic during the test scenarios? Maybe it wasn't working as
> well as you thought?
>
> The bottom line is this device has a level sensitive interrupt. The
> PXA270 doesn't support level interrupts in hardware. In order to make the
> two compatible you have to either change the hardware to artificially
> create edges or change the software (OAL) to detect that another interrupt
> is necessary and somehow generate one.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "Dan" <Dan@discussions.microsoft.com> wrote in message
> news:4B216E77-1208-4E20-AEE3-BC57279B64E1@microsoft.com...
>> The hardware engineer wants to know why it was working before we included
>> MDD
>> interrupts. We never experienced a failure, when that interrupt was
>> disabled,
>> and we do not disable edge detect when handling the MDD. I still don't
>> understand why missing an interrupt would cause the system to hang. Worst
>> case scenario, I would expect the miniport checkforhang method to return
>> true
>> and the miniport reset method would then be fired. CheckForHang is
>> getting
>> invoked every 2 seconds until the system deadlocks. That is NDIS's
>> responsibility, and I don't understand how any problems with handling the
>> interrupts would cause this kind of lockup. BTW, MDD interrupts are still
>> fired every twenty seconds, even after the lockup.
>>
>> "Dan" wrote:
>>
>>> Then I guess we'll have to get the hardware engineer to replace this
>>> chip
>>> with one that uses edge detection IRQs. It's either that or replace the
>>> microcontroller (we use XScale PXA270) with one that has this level
>>> based
>>> detection capability. I have a feeling management is more likely to
>>> approve
>>> replacing the LAN chip.
>>>
>>> Thanks
>>>
>>> "Valter Minute" wrote:
>>>
>>> > =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
>>> > news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com:
>>> >
>>> > > Good. That's a step in the right direction. Out of curiosity, what
>>> > > would the nature of that failure look like?
>>> >
>>> > Usually the device is requesting an interrupt and the processor is not
>>> > servicing it because the front it occourred while the interrupt was
>>> > disabled and so it was not reported.
>>> > If you service the interrupt and then re-enable edge detect on the pin
>>> > you may miss an interrupt if the interrupt is signaled after you
>>> > checked the interrupts register of the device and before you re-enable
>>> > edge detect.
>>> >
>>> >
>>> > --
>>> > Valter Minute
>>> > www.fortechembeddedlabs.it
>>> > Training, support and development for Windows CE
>>> > (the reply address of this message is invalid)
>>> >
>
>

Dan
Tue Feb 05 14:28:09 PST 2008

I spoke with the hardware engineer, and he informs me that we are using a
form of "glue logic", using a 25MHz clock and an AND gate with the IRQ to
feed into the microcontroller.

Thanks

"Valter Minute" wrote:

> =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
> news:6882CC86-3BA1-412E-961C-E5BF3CCF63EE@microsoft.com:
>
> > Then I guess we'll have to get the hardware engineer to replace
> > this chip with one that uses edge detection IRQs. It's either that
> > or replace the microcontroller (we use XScale PXA270) with one
> > that has this level based detection capability. I have a feeling
> > management is more likely to approve replacing the LAN chip.
>
> Usually such a massive rework isn't required. You can put in some
> "glue logic" to generate an edge when a level is in the same state for
> more than a few uSeconds or work around the problem in software re-
> enabling the edge detect before you clean the interrupt on the device
> or using a timer to generate an interrupt after you re-enable the edge
> detect to check that the interrupt pin is not already stuck in the
> interrupt level.
> In both cases you will lose some performance but if you don't need
> full ethernet troughput, that could be better than a re-enginering of
> your board.
>
> --
> Valter Minute
> www.fortechembeddedlabs.it
> Training, support and development for Windows CE
> (the reply address of this message is invalid)
>

Dan
Thu Feb 07 09:53:01 PST 2008

Nope. Not active.

"Dean Ramsier" wrote:

> By the way, it's a simple enough check. Look at the interrupt line after
> the lockup; if it's active you missed an edge. Since the interrupt is
> waiting to be serviced, it will not de-assert and you will never again get
> another interrupt from the device.
>
> --
> Dean Ramsier - eMVP
> BSQUARE Corporation
>
>
> "Dean Ramsier" <ramsiernospam@nospam.com> wrote in message
> news:OLOY7uDaIHA.4180@TK2MSFTNGP06.phx.gbl...
> > Different traffic during the test scenarios? Maybe it wasn't working as
> > well as you thought?
> >
> > The bottom line is this device has a level sensitive interrupt. The
> > PXA270 doesn't support level interrupts in hardware. In order to make the
> > two compatible you have to either change the hardware to artificially
> > create edges or change the software (OAL) to detect that another interrupt
> > is necessary and somehow generate one.
> >
> > --
> > Dean Ramsier - eMVP
> > BSQUARE Corporation
> >
> >
> > "Dan" <Dan@discussions.microsoft.com> wrote in message
> > news:4B216E77-1208-4E20-AEE3-BC57279B64E1@microsoft.com...
> >> The hardware engineer wants to know why it was working before we included
> >> MDD
> >> interrupts. We never experienced a failure, when that interrupt was
> >> disabled,
> >> and we do not disable edge detect when handling the MDD. I still don't
> >> understand why missing an interrupt would cause the system to hang. Worst
> >> case scenario, I would expect the miniport checkforhang method to return
> >> true
> >> and the miniport reset method would then be fired. CheckForHang is
> >> getting
> >> invoked every 2 seconds until the system deadlocks. That is NDIS's
> >> responsibility, and I don't understand how any problems with handling the
> >> interrupts would cause this kind of lockup. BTW, MDD interrupts are still
> >> fired every twenty seconds, even after the lockup.
> >>
> >> "Dan" wrote:
> >>
> >>> Then I guess we'll have to get the hardware engineer to replace this
> >>> chip
> >>> with one that uses edge detection IRQs. It's either that or replace the
> >>> microcontroller (we use XScale PXA270) with one that has this level
> >>> based
> >>> detection capability. I have a feeling management is more likely to
> >>> approve
> >>> replacing the LAN chip.
> >>>
> >>> Thanks
> >>>
> >>> "Valter Minute" wrote:
> >>>
> >>> > =?Utf-8?B?RGFu?= <Dan@discussions.microsoft.com> wrote in
> >>> > news:D01DF3B5-7C9A-4877-9252-0FAC44B15A18@microsoft.com:
> >>> >
> >>> > > Good. That's a step in the right direction. Out of curiosity, what
> >>> > > would the nature of that failure look like?
> >>> >
> >>> > Usually the device is requesting an interrupt and the processor is not
> >>> > servicing it because the front it occourred while the interrupt was
> >>> > disabled and so it was not reported.
> >>> > If you service the interrupt and then re-enable edge detect on the pin
> >>> > you may miss an interrupt if the interrupt is signaled after you
> >>> > checked the interrupts register of the device and before you re-enable
> >>> > edge detect.
> >>> >
> >>> >
> >>> > --
> >>> > Valter Minute
> >>> > www.fortechembeddedlabs.it
> >>> > Training, support and development for Windows CE
> >>> > (the reply address of this message is invalid)
> >>> >
> >
> >
>
>
>