Interrupt Handlers and Driver to Driver Communication

Kimberly Davis kimblydavis at
Thu Jan 19 07:57:07 PST 2006

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:
uint32_t g_status
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:
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.
----- Original Message ----
From: Norbert Koch <NKoch at>
To: Kimberly Davis <kimblydavis at>; freebsd-drivers at
Sent: Thursday, January 19, 2006 5:45:51 AM
Subject: RE: Interrupt Handlers and Driver to Driver Communication

>From which context/function in your driver 2 do you check g_status?
Does your debug output show, that this context really
becomes active?
Are your drivers in the same or different source files?
Or are they being loaded as different klds?
Have you tried if it makes any difference to declare
g_status as volatile?
Any interesting compiler warnings?
(Just for not forgetting to ask: You didn't by accident declare
g_status twice, once at global and once static at function scope?)

> -----Original Message-----
> From: owner-freebsd-drivers at
> [mailto:owner-freebsd-drivers at]On Behalf Of Kimberly Davis
> Sent: Wednesday, January 18, 2006 7:22 PM
> To: freebsd-drivers at
> Subject: Interrupt Handlers and Driver to Driver Communication
> I am having a very serious problem with a driver that I am
> writing. Specifically, my problem is related to driver to driver
> communication. I've tried to abstract the problem in my description below.
> I have a driver (let's call it Driver 1) in which I register the
> interrupt handler in this way:
> tsc->irqid = 0x0;
> tsc->irq_res = bus_alloc_resource(dev, SYS_RES_IRQ,&(tsc->irqid), 0, ~0,
> if(tsc->irq_res == NULL)
>     print_osal("Failed to allocate irq resource\n");
> else
> {
>        error = bus_setup_intr(dev, tsc->irq_res, INTR_TYPE_MISC ,
>        driver_one_interrupt_handler, tsc, &(tsc->handler));
> }
> My interrupt handler function is actually quite long, but there
> is nothing to be done about it. There is no really good way to
> make it shorter. Anyway, in Driver 2, I call a function (part of
> an API that I provide in driver 1) and it returns a value:
> status = driver_one_is_operation_complete(param, param);
> The driver_one_is_operation_complete function actually returns to
> Driver 2 a status variable that is set in the interrupt handler
> of driver 1.
> //global for status of an event.
> int g_status;
> void driver_one_interrupt_handler(void * arg)
> {
>     g_status = 0;
>         g_status = 1;
> }
> The problem is that I never, ever get the value from  the
> function driver_one_is_operation_complete that I would expect.
> The value returned is always 0 and never 1. However, when I check
> this value in driver one's detach function, right before the end
> of execution, the value is 1.
> driver_one_detach()
> {
>     print("g_status %x\n",g_status)
>     blah, blah, blah
> }
> Clearly, the interrupt handler has executed and the value has
> been set to one.
> In driver two, I've tried waiting 2 or 3 seconds (with the
> system's delay function) before calling
> driver_one_is_operation_complete, but this doesn't help either.
> Is there something weird going on in the Driver to Driver communication?
> Thanks in advance for any help or clues you may be able to provide,
> KD
> _______________________________________________
> freebsd-drivers at mailing list
> To unsubscribe, send any mail to "freebsd-drivers-unsubscribe at"

More information about the freebsd-drivers mailing list