Interrupt Handlers and Driver to Driver Communication

[Kimberly Davis]

Yes, tried all that...
 
nm driver1.ko | grep driver_one_is_complete
00003274 T driver_one_is_complete
 
nm driver2.ko | grep driver_one_is_complete
U driver_one_is_complete
 
Undefined makes sense because it's not defined in the driver2 code. It's merely being called.
 
A more interesting development occurred yesterday when a colleague suggested that I write post codes to the LED on the board at different times in the driver so that we could tell how long it was lingering over certain executions and see where the driver was in its execution of the interrupt handler.
 
What I found during that exercise was that the driver interrupt handler gets stuck, unable to complete the interrupt handler call until driver2's call of the function driver_one_is_complete has finished executing. In other words, driver2's activities are preventing driver1's activities from finishing. This explains the erronenous value that I keep getting with driver_one_is_complete. 
 
I don't understand this at all. Have you ever encountered this problem?
 
KD

----- Original Message ----
From: Norbert Koch <NKoch at demig.de>
To: Kimberly Davis <kimblydavis at yahoo.com>; John Baldwin <jhb at freebsd.org>; freebsd-drivers at freebsd.org
Sent: Friday, January 20, 2006 12:24:55 AM
Subject: RE: Interrupt Handlers and Driver to Driver Communication


> The results of that test are as follows
>  
> >nm driver1.ko | grep g_status
> 00004239 B g_status
>  
> It doesn't make sense to do that for the client_driver (driver2) 
> since the variable isn't defined there or even externed there. I 
> use the API from driver1 (driver_one_is_complete) to find out the 
> value of g_status.

So, what about 'nm driver[12].ko | grep driver_one_is_complete' ?
Does driver_one_is_complete() do a test-and-reset operation on g_status?
Did you have a look at the assembly output of this function?
What are your compiler (optimization) settings?