More Results --> Bus Master Write Problems

[Duncan Terry S Civ AFRL/DES <Terry.Duncan@plk.af.mil>]

To All,

I received several requests for more information about our problem and
resolution.  Below is a description of the condition that we encountered,
our device driver's actions, and results.  One person asked how we disabled
the Compaq Alerter.  We simply changed its startup setting in the Services
Control Panel to manual so that it does not start every time the system
initializes.  One confusing issue was that I used the phrase 

The description and debugging work associated with this problem is
attributable to our software engineer, Scott Newey, and the hardware
engineer for the board, Josh Voas.

-----------------------------
Description:

Since PCI busmasters can only transfer their data to contiguous blocks of
memory, my Device Driver does the following:

Initialization
1. It takes the pointer to memory allocated by my Application program.
2. This buffer is used by the Driver in a double buffer fashion, so an
additional pointer is set to the second half of the buffer.
3. The contiguous blocks are mapped for both halves of the buffer.
4. The board is then setup to busmaster to the first contiguous block of the
first buffer.  Our card is setup to interrupt upon completion of the
transfer.

On interrupt...
1. All real processing occurs as a Deferred Procedure Call, so the proper
call is executed to cause the execution of the DPC.
2. In the DPC, If there are more contiguous blocks of memory in the current
buffer the card is setup to busmaster to the next contiguous block of
memory.  Otherwise, the application program is notified that one of the
buffers is full, and the card is setup to busmaster to the first contiguous
block of memory in the second buffer.
3. The DPC exits, and the interrupt line is deasserted.

When looking at the PCI bus signals, we saw that there were ~2.7 millisec
chunks of time where our card stopped requesting access to the PCI bus.
Which meant that my Device Driver was being blocked from setting the card up
(step 2 in the On interrupt section).  This implied that the CPU was
executing at a higher interrupt level (or equal interrupt level) as my DPC
code, and thus was blocking my Driver.

We also noticed that during these blocks, that another process was
transferring data.  This data transfer was not initiated by a busmaster card
(we saw no bus request signals).  The transfer was completely handled by the
CPU.

We then noticed that these blocks occurred at a regular interval (once every
60 seconds), whether our capture code was running or not.  We also noticed
that it occurred even if we were logged out, which led us to believe that it
was a Service.  One by one we stopped suspect Services until the phenomenon
stopped when "Compaq Local Alerter" was stopped.

As far as a timeline goes, once per minute Local Alerter would do its thing
and for 2.7 msec my device driver would be blocked from setting up its next
transfer.  Once local alerter ended, my interrupt service code was executed
and once again we were transferring data.
--------------------------------------------------------

In addition and as a result of this investigation, we have a few new
questions:

What does "Compaq Local Alerter" do?
What does it do every minute?
What is the execution level (IRQL) of the code (the code that executes once
per minute)?
What is so important (critical) in the code that it elevates the processors
execution level to above standard ISR code?
If it is that important, why is it only executed once per minute?
Why is my card assigned IRQ 36?
Why doesn't the CMOS settings affect how NT assigns interrupt levels?

Any thoughts???

Thanks,

Terry S. Duncan
Engineering Coordinator
Computer Systems Manager
duncant@plk.af.mil
(505) 846-6783 voice
(505) 853-7243 pager 7103
(505) 846-2213 fax
AFRL/DES
3550 Aberdeen Ave SE
Kirtland AFB, NM 87117