Interrupt Handlers and Driver to Driver Communication

John Baldwin jhb at
Thu Jan 19 10:15:24 PST 2006

On Thursday 19 January 2006 10:57, Kimberly Davis wrote:
> Norbert, thanks for responding.
> I provide answers to your questions and a little more information below.
> In driver 2, I call the function driver_one_is_operation_complete, which is
> part of an API provided by driver 1.
> Yes, I have reason to believe that the context becomes active. In other
> words, I believe that the condition CERTAIN_CONDITION_OCCURRED does in fact
> become true at some point. Driver 1 is a dma driver, and I can actually see
> that the driver completes a transaction, which triggers an interrupt. When
> I check the status variable from within driver1 the status does equal 1,
> letting me know that the condition occurred.
>     g_status = 1;
> My drivers are definitely in different source files, and they are being 
loaded with different invokations of kldload. For example:
> >kldload driver1.o
> >kldload driver2.o
> >kldunload driver2
> >kldunload driver1
> Driver2 is dependent on driver1. I use the MODULE_DEPEND macro to ensure
> this dependency. Driver1 is actually composed of two .c files.
> Here is the layout for driver1:
> dma.c:
> uint32_t g_status
> dma_client_api.c:
> extern uint32_t g_status
> The code for driver_one_is_operation_complete is in this file and there is
> a dma_api.h file which contains the function protype.
> Here is the file layout for driver2:
> client_driver.c
> In driver2's attach function, I call driver_one_is_operation_complete.
> I have tried a volatile delcaration, and it doesn't work. I have checked,
> checked, and re-checked to make certain that I haven't declared the status
> variable twice accidentally.
> Also, I should say that I have a uniprocessor system, and the processor is
> not multi-core, so none of the typical questions about hyper-threading, SMP
> syncing issues, or multi-core difficulties seem particularly relevant,
> although I won't rule some sort of phantom issue out. I am using FreeBSD
> 6.0. I've also tried making this variable a part of the softc structure.
> That does not help either.
> Obviously I am having some sort of module communication problem, but what?
> I can't seem to nail it down.

Can you provide 'nm driver1.ko | grep g_status' and 'nm driver2.ko | grep 
g_status' output?

John Baldwin <jhb at>  <><
"Power Users Use the Power to Serve"  =

More information about the freebsd-drivers mailing list