From mboxrd@z Thu Jan 1 00:00:00 1970 From: wink@saville.com (Wink Saville) Date: Tue, 10 Apr 2012 17:58:44 -0700 Subject: IRQs and memory consistency In-Reply-To: <18680507ce5fe185f8355a813376bd26@basementcode.com> References: <18680507ce5fe185f8355a813376bd26@basementcode.com> Message-ID: To: kernelnewbies@lists.kernelnewbies.org List-Id: kernelnewbies.lists.kernelnewbies.org 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 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 at kernelnewbies.org > http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.kernelnewbies.org/pipermail/kernelnewbies/attachments/20120410/885355e9/attachment.html