Tomas Kalibera wrote:
 > Hi Gilles,
 > thanks for looking at it. Your analysis is correct, I don't indeed have 
 > CONFIG_PREEMPT_RT kernel, but only CONFIG_PREEMPT, sorry for the confusion.
 > I've put the kernel config, sources, and binary on the web, so that you 
 > can be sure you're really looking on the kernel that is crashing, 

After looking at the sources, it appears that kmap_atomic disables
preemption and kunmap_atomic reenables it. In short, the bug should
never happen. What could happen is that the preemption count is garbled,
or that a call to kmap_atomic is not paired with a kunmap_atomic.

To check if the problem comes from the preemption count, could you apply
the following patch ?


diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
index 1c3bf95..4bb9fc6 100644
--- a/arch/x86/mm/highmem_32.c
+++ b/arch/x86/mm/highmem_32.c
@@ -34,6 +34,7 @@ void *kmap_atomic_prot(struct page *page, enum km_type type, 
pgprot_t prot)
        /* even !CONFIG_PREEMPT needs this, for in_atomic in do_page_fault */
+       BUG_ON(type == KM_USER0 && !in_atomic());
        if (!PageHighMem(page))
                return page_address(page);
@@ -85,6 +86,7 @@ void *kmap_atomic_pfn(unsigned long pfn, enum km_type type)
+       BUG_ON(type == KM_USER0 && !in_atomic());
        idx = type + KM_TYPE_NR*smp_processor_id();
        vaddr = __fix_to_virt(FIX_KMAP_BEGIN + idx);
        set_pte(kmap_pte-idx, pfn_pte(pfn, kmap_prot));
Xenomai-core mailing list

Reply via email to