[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ms-smartcardddk
Subject:    How to make serial-port IRQs disappear!
From:       Malcolm Hannah <malc () MHANNAH ! CO ! UK>
Date:       2000-12-13 10:31:03
[Download RAW message or body]


Hello, I'm developing NT and 9x drivers for a serial reader which does not
use handshaking lines.

On NT, from DriverEntry, I build a WAIT_ON_MASK IRP, send it to serial.sys
and when my completion routine is called, I re-use the IRP to read the
received bytes.  When my completion routine is called again, I re-use the
IRP again to wait for subsequent bytes.  My IRP (and its completion
routine) are active throughout the life of the driver.

This works perfectly at 9600 baud.  But at 115200 baud, serial.sys reports
FIFO overrun errors.  I re-built serial.sys (from the DDK source) with
pin-toggling code inserted in the ISR (interrupt-service routine) so that I
could monitor activity on an oscilloscope.

I find that for a few milliseconds after the ISR queues a DPC, subsequent
interrupts do not reach the ISR.  If I cancel my IRP, no-one is waiting for
incoming bytes, no DPC is queued and the ISR is called regularly, every 8
bytes (the FIFO RxTrigger is set to 8).

[I see the same behaviour on 9x if I call Schedule_Global_Event rather than
deal with received bytes directly from a CommNotify procedure, which has
been called directly from serial.vxd's ISR.]

I know that Windows does not claim to be a real-time OS, but missing
interrupts is exactly the thing which DPC-queueing (and Event-Scheduling)
is supposed to prevent...

...So I conclude that I must be doing something wrong.
Does anyone know what it might be?
Has anyone else seen this behaviour?
Can anyone point me towards any Microsoft documentation explaining what
happens when a DPC is queued (or an Event Scheduled)?

I've been working on this for many weeks, so I'd appreciate any input
whatsoever.

Malcolm Hannah                   Malcolm Hannah Ltd, Glasgow, Scotland

[prev in list] [next in list] [prev in thread] [next in thread]