Hi folks! I'm sorry to bother you, guys, but neither the mailing list 'kpreempt-tech@lists.sourceforge.net' nor Robert's address 'rml@tech9.net' exist anymore. If I have to address someone else, pls let me know. We're currently investigating the locking of data structures in the Linux Kernel -- namely 3.16. Doing so, we've been logging every call to *lock() or *unlock(). For further analysis, we log the preempt count as well. Although we use a voluntary preemptive kernel (defined(CONFIG_PREEMPT_VOLUNTARY) && !defined(CONFIG_PREEMPT) && !defined(CONFIG_PREEMPT_COUNT), the actual preemption count, the first eight bits, aren't zero all time. I'd expect the kernel to not touch those bits, because the preempt_{enable,disable} functions do nearly nothing in my case. They actually insert a memory barrier, but nothing more. As you can see in the file (query.txt) attached to this mail, there are several occasions where the preemption count is above zero. I'm a bit puzzled why this happens... The format is as follows: The first three columns donate the position within the source code where a lock has been acquired. The fourth column is the preemption count, as returned by preemption_count(), after acquiring the lock. The last column tells how often this happens. I attached my kernel config as well. Can you please tell why this happens? Have I missed something? Might this be a bug? Thanks! Regards, Alex -- Technische Universität Dortmund Alexander Lochmann PGP key: 0xBC3EF6FD Otto-Hahn-Str. 16 phone: +49.231.7556141 D-44227 Dortmund fax: +49.231.7556116 http://ess.cs.tu-dortmund.de/Staff/al