Specifications

D
evice Driver Programming
15-6
Timing Errors 15
Timing errors occur when the driver code executes too quickly or too slowly for the device
being driven. For instance, the driver might read a status register on a device too soon after
sending the device a command. The device might not have had time to update the status
register, so the status register is perceived by the driver to be all 0 bits when, in fact, the
device might just be slow in posting the correct status register setting.
When testing the driver, it is useful to verify that a simple, single interrupt is being han-
dled properly. After this is confirmed, you should check that the interrupt handler can han-
dle a number of interrupts that happen at almost the same time.
Corrupted Interrupt Stack 15
If a driver's interrupt handler runs at an execution level lower than the corresponding IPL
for the device, the processing of one interrupt can be interrupted by a second interrupt
from the same device. This seriously corrupts the interrupt stack, which can cause the sys-
tem to panic with a stack fault or kernel address fault. Sometimes, however, it only causes
random operational irregularities, which can make this a difficult problem to detect. You
can identify this problem by looking at the interrupt stack in the system dump. If it is cor-
rupted, check the execution level of the driver's interrupt-handling routine.
Accessing Critical Data 15
Check the driver code for data structures that are accessible to both the base and interrupt
levels of the driver. Ensure that any section of the base-level code that accesses such struc-
tures cannot be interrupted during that access by using the appropriate spl(D3)
function.
Overuse of Local Driver Storage 15
If the driver routines use large amounts of local (automatic) storage, they can exceed the
bounds of the kernel stack, which in turn panics the system.
Incorrect DMA Address Mapping 15
Failure to set up address mapping for DMA transfers correctly is another common mis-
take.Onaread operation, a bad address map can cause data to be placed in the wrong
location in the main store, overwriting whatever is there including, for example, a portion
of the operating system text.
To check for this, write a simple user program that writes data to all possible memory
locations (including shared memory, stack, and text) and then reads it back and compares