Sounds to me like there needs to be a flush of the processor cache 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. See: http://www.kernel.org/doc/Documentation/atomic_ops.txt -- Wink On Tue, Apr 10, 2012 at 1:22 PM, Christopher Harvey <ch...@basementcode.com>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@kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies >
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies