DPC/ISR synchronization (windows ce)

Discussion in 'Windows Vista Drivers' started by anonymous, Jun 28, 2005.

  1. anonymous

    anonymous Guest

    I haven't had a lot of response in the platform builder newsgroups, so I'll
    try here.

    In Windows CE 4.1, I had no problem with a NDIS ISR (miniportISR)
    interrupting the DPC(MiniportHandleInterrupt). In upgrading to Windows CE
    5.0, I'm seeing that the ISR is getting held off by the DPC. I've tried
    serialized/deserialized. I've verified that the interrupt is not disabled in
    the kernel and can see with independent means that kernel is seeing the
    interrupt and setting the interrupt event in time with the hardware, but the
    ISR waits until the DPC finishes until it is run.

    Does anyone have visibility into what has changed between the CE 4.x and 5.x
    NDIS implementation ? The driver registers as an NDIS 5.0 miniport.
     
    anonymous, Jun 28, 2005
    #1
    1. Advertisements

  2. Does the DPC raise IRQL, and if so what does it raise it to? The DPC is
    nromally at DISPATCH_LEVEL in XP, and given the common use of terms, I would
    expect that to be the same. If the DPC raises IRQL to a level higher than the
    DIRQL causing the intterupt, the yeah ... the ISR will wait till IRQL drops.

    The personal opinion of
    Gary G. Little
     
    Gary G. Little, Jun 29, 2005
    #2
    1. Advertisements

  3. anonymous

    anonymous Guest

    Thanks,

    That is the issue. Previously, the ISR was two priority levels above the
    DPC. In 5.0, they are both at the same level.

    So, the next question is why were they changed ?
     
    anonymous, Jun 29, 2005
    #3
  4. anonymous

    anonymous Guest

    Well, it appears they are actually running in the same thread now.
     
    anonymous, Jun 29, 2005
    #4
  5. anonymous

    Pavel A. Guest

    Hi,
    First of all, could you please explain why your ISR occurs while the DPC
    is scheduled?
    When interrupt occurs and the ISR queues a DPC, it should normally prevent
    the device from generating more interrupts.
    Then the DPC runs and re-enables the interrupts just before returning.
    Why this design isn't good for you?

    Regards,
    --PA
     
    Pavel A., Jun 29, 2005
    #5
  6. anonymous

    anonymous Guest

    My problem is that my NIC has four buffers for receive and transmit. Assuming
    I'm full duplex and one is going out, then I've room for three packets.

    Three packets at 100Mbit, is approximately 1024(header)+64byte*8 = 1536 bit
    times + interpacket delay of 960ns = 16.32us * 3 = 48.96us

    By the time fourth packet posts at 65.28us, I'm dropping packets.

    A call into NdisMIndicateReceivePacket is taking much longer than 65us even
    with just one packet. If I have to wait around for that indication to return
    before I can service the hardware, I'm just dropping too many packets too
    frequently.

    Thanks!
     
    anonymous, Jun 30, 2005
    #6
  7. Not necessarily. I have dealt with drivers that could not diasble interrupts
    and then let the DPC re-enable them. Done properly, there is no reason why
    the device's interrupt should be disabled in the ISR and enabled in the DPC.
    You do have to sync access to resources that are shared between the two.

    The personal opinion of
    Gary G. Little
     
    Gary G. Little, Jun 30, 2005
    #7
  8. anonymous

    Pavel A. Guest

    You're correct, but as you see, this design is not quite portable to WinCE.
    How exactly hardware interrupts behave on CE depends on the
    manufacturer of the CE device.
    I'm not sure about CE 5, but in previous CE versions
    installable drivers could not receive hardware interrupts at all, and thus
    did not have real ISRs. What they get is callbacks in context of a high
    priority user mode threads. DPCs are emulated with usermode
    threads with lesser priority.
    So the different behavior in CE5 could be caused by mistake of
    somebody who configured it for the specific platform
    (assigned wrong priorities to interrupt and DPC threads, etc).

    Regards,
    --PA
     
    Pavel A., Jun 30, 2005
    #8
  9. Pavel !
    Just a little addition : that's try that CE model is similar to vxWorks
    InterruptHandler ( ISR ) just set event for usermode servicethread
    ( IST ) thus excluding DCP at all , but for NDIS in CE that still emulate(d)
    the same DPC behavious as in big windows , so maybe
    some general concept changed in the last CE , because OP pointed that they
    run on the same thread which wasn't possible in previous versions of little
    window for any driver especially for network ( NDIS ).
    Arkady
     
    Arkady Frenkel, Jul 1, 2005
    #9
  10. anonymous

    Pavel A. Guest

    The number and priorities of ISTs vary by platform, this is why
    I suspected that the CE build the OP works with, is misconfigured.
    This could be just because of some changes in CE5
    config options and PB.

    Regards,
    --PA
     
    Pavel A., Jul 2, 2005
    #10
  11. But windows CE open source is not so open to change NDIS behaviour by OEM.
    They can't run on the same thread unless MSFT want it so
    Arkady
     
    Arkady Frenkel, Jul 3, 2005
    #11
  12. Pavel ! That IMHO ( possible to say I'm sure it in :) ) will be interesting
    for you , look at the answer of Soemin Tjong [MSFT] on that question of OP
    on microsoft.public.windowsce.platbuilder .
    Arkady
     
    Arkady Frenkel, Jul 4, 2005
    #12
  13. Additionally : I heard that they rewrite TCP stack , but thought that only
    in connection with LSP they added into the chain , I see now that really
    they re-write much more :)
    Arkady

     
    Arkady Frenkel, Jul 4, 2005
    #13
  14. anonymous

    Pavel A. Guest

    Thanks.
    --PA
     
    Pavel A., Jul 4, 2005
    #14
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.