by using memory barriers.
I'm guessing that the IRQ is taken on a different thread and possibly
a different processor and the value needs to be flushed. You might
try having devid be an atomic_t and then use atomic_set
and atomic_read so that the "proper" memory barriers are used.
-- Wink
On Tue, Apr 10, 2012 at 1:22 PM, Christopher Harvey <chris@xxxxxxxxxxxxxxxx> wrote:
This is a high level question about how IRQs work in the kernel.
I have a struct that was kmalloc'd into ram. Within this struct there
is an int, called devid. When I set this devid to a number that isn't
0, I print the following:
checking devid value....327683 in 0xcb6953d4
where 327683 is the value of the int and 0xcb6953d4 is the address of
the struct that the devid value is in.
Then an interrupt happens and when I print this value again at the
beginning of the interrupt handler I get the following printed text:
checking devid value....0 in 0xcb6953d4
notice that the devid has been set to 0. I can't find any code on my
end that would do this. Is there something, maybe related to memory
address spaces in IRQ handlers that I don't know about?
The IRQ and the setting of the devid value happen fairly close to
each other in time. (like less than a second, or closer)
Any ideas or guesses are appreciated.
-Chris
_______________________________________________
Kernelnewbies mailing list
Kernelnewbies@xxxxxxxxxxxxxxxxx
http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
