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