Re: CE 5.0 PCMCIA ISR issue

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

OK, so I don't know how to write... "...use the Send Feedback link..."

Paul T.

"Paul G. Tobey [eMVP]" <p space tobey no spam AT no instrument no spam DOT
com> wrote in message news:OnsHXwmlIHA.3888@xxxxxxxxxxxxxxxxxxxxxxx
If you find pages in the docs which are unclear or misleading, using the
Send Feedback link that should exist on every page of the help. The
Windows CE documentation people read *all* of those reports, so it may get
better, if you tell them what's wrong.

Paul T.

"FoolBlah" <foolblah@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:71E553B0-6EFE-4BE2-8B4F-51170C0A9E26@xxxxxxxxxxxxxxxx
I have figured out what was going on here. There are multiple confusing
points about the correct way to implement the registry settings so that
the
PCMCIA driver uses the real hardware IRQ, none of which is very obvious
from
the docs.

First off, the "NoISR" value needs to be populated under the
[HKEY_LOCAL_MACHINE\Drivers\PCCARD\PCMCIA\TEMPLATE\PCMCIA] key. This
will
allow the "key" value under the Active key to locate the "NoISR" value
correctly.

The other pieces to this are as follows. The "ClientIrq" value needs to
be
set to the user defined SYSINTR value, which should be mapped to the IRQ
defined in the OAL. In addition to this, the SOCK_CAP_ONLY_SYSINTR bit
needs
to be set as part of the dwSocketCaps in the SS_SOCKET_INFO struct
defined in
pcmsock.cpp. This in itself is confusing in that one would expect the
MMD to
inspect the dwSocketIntrCaps value for this bit, but in actuality, it
inspects the general dwSocketCaps, which I personally feel is misleading
and
could be considered a bug. If this bit is NOT set correctly (which is
easy
to do), no matter how "NoISR" is set, this will cause the installable ISR
to
start and "ignore" the real hardware IRQ.

Also, it appears that there is no way to set the PCMCIA\ATADisk ISR
thread
priority, is this correct? Understood that only the status/CD ISR thread
priority is set via the "ThreadPriority" value.

Thanks.

"FoolBlah" wrote:

I have been working on a performance issue with our CE 5.0 platform.
There
is a problem I am having with the PCMCIA driver and the ISR (client/data
IRQ
not status IRQ or CD IRQ). What is happening is no matter what "NoISR"
is
set to under "HKEY_LOCAL_MACHINE\Drivers\BuiltIn\PCC_MAINSTONEII0" the
installable ISR is being loaded. What this does is causes the actual
hardware IRQ from the PCMCIA card to be ignored thus clobbering anything
else
that might be occuring throughout the system when an I/O transfer occurs
to/from the PCMCIA card. The goal is to priortize the IRQs via the 270
interrupt controller but I cannot due to the current issue.

The problem appears to be in the CPcmcia::PcmciaCardRequestIRQ() routine
located at \PUBLIC\COMMON\OAK\DRIVERS\PCCARD\PCMCIA\pcmcia.cpp. The
CPcmcia
class inherits from CRegistryEdit helper class to deal with registry
access.
When CPcmcia is initialized it passes the current active key path loaded
in
the registry. The "NoISR" flag in the registry that controls is being
looked
at based on the active registry path, which is not correct. This causes
in
all cases for the installable ISR to be loaded and run no matter how
"NoISR"
is set.

I can force the "NoISR" flag through the debugger, and when doing so the
code behaves as I expect it to. The ATADisk ISR is called when a
hardware
IRQ is recieved from the PCMCIA card, does some I/O, waits for another
IRQ,
etc. as it should.

Am I placing the "NoISR" in the wrong location, and if so, where does
the
flag need to be placed for it to appear in the active registry key when
the
driver is loaded? Since the "Active" key is dynamic based on what
drivers
are loaded/unloaded I didn't think there was a way to pass it a static
value
such as "NoISR".

Any insight is appreciated.

Thanks.




.

Relevant Pages

  • RE: CE 5.0 PCMCIA ISR issue
    ... PCMCIA driver uses the real hardware IRQ, none of which is very obvious from ... to do), no matter how "NoISR" is set, this will cause the installable ISR to ... class inherits from CRegistryEdit helper class to deal with registry access. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: CE 5.0 PCMCIA ISR issue
    ... PCMCIA driver uses the real hardware IRQ, none of which is very obvious ... set to the user defined SYSINTR value, which should be mapped to the IRQ ... to do), no matter how "NoISR" is set, this will cause the installable ISR ...
    (microsoft.public.windowsce.platbuilder)
  • Re: CE 5.0 PCMCIA ISR issue
    ... set to the user defined SYSINTR value, which should be mapped to the IRQ ... to do), no matter how "NoISR" is set, this will cause the installable ISR ... class inherits from CRegistryEdit helper class to deal with registry ...
    (microsoft.public.windowsce.platbuilder)
  • CE 5.0 PCMCIA ISR issue
    ... is a problem I am having with the PCMCIA driver and the ISR (client/data IRQ ... class inherits from CRegistryEdit helper class to deal with registry access. ...
    (microsoft.public.windowsce.platbuilder)
  • Re: Error 7023
    ... This helps a PC to map devices using IRQ ... HAL (Hardware Abstraction Layer) driver appropriate for the type ... So some of your issues are most definitely related to McAfee. ... The kind of errors you report can be the result of Registry ...
    (microsoft.public.windowsxp.general)