Booting 3.0.4 + rt12 on a quadcore workstation (running fc14) gave me this: ---- ============================================= [ INFO: possible recursive locking detected ] 3.0.4-1.rt12.1.fc14.ccrma.i686.rtPAE #1 --------------------------------------------- swapper/0 is trying to acquire lock: (&parent->list_lock){+.+...}, at: [] __cache_free.clone.27+0x45/0xc4 but task is already holding lock: (&parent->list_lock){+.+...}, at: [] do_tune_cpucache+0xf0/0x2b0 other info that might help us debug this: Possible unsafe locking scenario: CPU0 ---- lock(&parent->list_lock); lock(&parent->list_lock); *** DEADLOCK *** May be due to missing lock nesting notation 3 locks held by swapper/0: #0: (cache_chain_mutex){+.+...}, at: [] kmem_cache_init_late+0x15/0x61 #1: (&per_cpu(slab_lock, __cpu).lock){+.+...}, at: [] __local_lock_irq+0x1e/0x5b #2: (&parent->list_lock){+.+...}, at: [] do_tune_cpucache+0xf0/0x2b0 stack backtrace: Pid: 0, comm: swapper Not tainted 3.0.4-1.rt12.1.fc14.ccrma.i686.rtPAE #1 Call Trace: [] ? printk+0x2d/0x2f [] __lock_acquire+0x8b3/0xc2f [] ? rt_spin_lock_slowlock+0x67/0x170 [] ? mark_lock+0x26/0x1bb [] ? __cache_free.clone.27+0x45/0xc4 [] lock_acquire+0xde/0x11d [] ? __cache_free.clone.27+0x45/0xc4 [] rt_spin_lock+0x3d/0x43 [] ? __cache_free.clone.27+0x45/0xc4 [] __cache_free.clone.27+0x45/0xc4 [] ? test_ti_thread_flag+0x8/0x10 [] kmem_cache_free+0x73/0xe1 [] slab_destroy+0x4f/0x53 [] free_block+0x94/0xc5 [] do_tune_cpucache+0x109/0x2b0 [] enable_cpucache+0x7b/0xa7 [] kmem_cache_init_late+0x26/0x61 [] start_kernel+0x24f/0x367 [] ? loglevel+0x1a/0x1a [] ? reserve_ebda_region+0x70/0x72 [] i386_start_kernel+0xb2/0xba Console: colour VGA+ 80x25 console [tty0] enabled Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS: 8191 ... CLASSHASH_SIZE: 4096 ... MAX_LOCKDEP_ENTRIES: 32768 ... MAX_LOCKDEP_CHAINS: 65536 ... CHAINHASH_SIZE: 32768 ---- I started working and a little while later the machine froze (jack + heavy prioritized udp traffic in eth1 - with the r8169 driver). It recognized alt-sysrq boot so it was not completely dead. Nothing left on the logs to see. Full config attached. -- Fernando