Hello,
I have a strange problem concerning the 'kmem_cache_create' when it is called by 'vfs_cache_init'. During the boot procedure, 'kmem_cache_create' is called several times in order to check if the state of the initialisation is correct, and in my case it works correcly until 'vfs_cache_init'. Indeed, the problem is in_interrupt() returns a non-zero:
*********************************************************************
   /*
    2092         * Sanity checks... these are all serious usage bugs.
    2093         */
-    2094        if (!name ||* in_interrupt() *|| (size < BYTES_PER_WORD) ||
2095 (size > (1 << MAX_OBJ_ORDER) * PAGE_SIZE) || (dtor && !ctor)) { - 2096 printk(KERN_ERR "%s: Early error in slab %s\n", __FUNCTION__,
    2097                    name);
-    2098            BUG();
    2099        }
2100 *********************************************************************** Then the system enter in BUG() which creates a panic. in_interrupt calls preempt_count() which correponds to 'current_thread_info->preempt_count'. In order to check the value of preempt_count() (which is optimized in GDB) I have define the following volatile variable

volatile unsigned long test = current_thread_info()->preempt_count ;

From this point, the strange fact is that in_interrupt() return 0 and the system is not in panic anymore.

So perhaps the call of 'current_thread_info()->preempt_count' modified something. I don't really understand why the definition of a variable initialised with 'current_thread_info()->preempt_count' resolves my problem...

Any suggestion?

Thanks a lot in advance.

Stéphane Lambert
_______________________________________________
uClinux-dev mailing list
uClinux-dev@uclinux.org
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by uclinux-dev@uclinux.org
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev

Reply via email to