On Tue, Jan 12, 2010 at 9:51 AM, Yu, Luming <luming.yu@xxxxxxxxx> wrote: > Let me check if I can get access to an HP rx8640 to re-spin the patch. > > > -----Original Message----- > From: Alex Chiang [mailto:achiang@xxxxxx] > Sent: Tuesday, January 12, 2010 3:58 AM > To: Yu, Luming; Luck, Tony > Cc: linux-ia64@xxxxxxxxxxxxxxx > Subject: lockdep support caused an MCA > > This patch 2f02b4a12b24c9f077c6d739ac23c9b90840ccca: > > Author: Luming Yu <luming.yu@xxxxxxxxx> 2009-12-04 09:14:30 > > [IA64] lockdep support > > Basic functionality for lockdep on ia64. > > Known issues: > 0. dynamic allocate per CPU area in lockdep. > 1. lock held in leave kernel. > 2. enabling CONFIG_DEBUG_LOCKDEP triggers the lockdep warning. > 3. Need to implement save_stack functions > 4. Replace some cpp macros with inline functions > 5. Add nmi_enter/nmi_exit > > Signed-off-by: Bob Picco <bob.picco@xxxxxx> > Signed-off-by: Yu Luming <luming.yu@xxxxxxxxx> > Signed-off-by: Tony Luck <tony.luck@xxxxxxxxx> > > causes a very early MCA on an HP rx8640. > > Unfortunately, even with early_printk turned on, the machine > encounters the MCA and reboots before any output occurs, so I > don't have any further information. > > I haven't done any other triage on this as the patch has already > been dropped from Tony's tree, but I'd be happy to test the next > go-around. I have managed to get the patch run on a HP rx8640 system with latest next tree + ia64-lockdep patch. The following is the part of boot log with lockdep footprints..The interesting thing is lockdep code seems to have detected possible recursive locking with the kernel on the platform. Kernel command line: BOOT_IMAGE=scsi0:EFI\redhat\vmlinuz-2.6.33-rc3-next-20100113 root=/dev/VolGroup00/LogVol00 ro PID hash table entries: 4096 (order: 1, 32768 bytes) Memory: 33235200k/33370096k available (8346k code, 171728k reserved, 10446k data, 2400k init) Hierarchical RCU implementation. RCU-based detection of stalled CPUs is enabled. NR_IRQS:1024 ============================================= [ INFO: possible recursive locking detected ] 2.6.33-rc3-next-20100113 #1 --------------------------------------------- swapper/0 is trying to acquire lock: (&(&parent->list_lock)->rlock){......}, at: [<a0000001001e9450>] kmem_cache_free+0x2f0/0x560 but task is already holding lock: (&(&parent->list_lock)->rlock){......}, at: [<a0000001001ea490>] kfree+0x470/0x620 other info that might help us debug this: 2 locks held by swapper/0: #0: (cache_chain_mutex){+.+...}, at: [<a000000100acf350>] kmem_cache_init_late+0x30/0x240 #1: (&(&parent->list_lock)->rlock){......}, at: [<a0000001001ea490>] kfree+0x470/0x620 stack backtrace: Call Trace: [<a000000100015fb0>] show_stack+0x50/0xa0 sp=a000000100f07bc0 bsp=a000000100f01ec0 [<a000000100016030>] dump_stack+0x30/0x60 sp=a000000100f07d90 bsp=a000000100f01ea0 [<a0000001000f3d10>] validate_chain+0x1010/0x2660 sp=a000000100f07d90 bsp=a000000100f01e28 [<a0000001000f6880>] __lock_acquire+0x1520/0x1660 sp=a000000100f07de0 bsp=a000000100f01d90 [<a0000001000f6b50>] lock_acquire+0x190/0x200 sp=a000000100f07de0 bsp=a000000100f01d30 [<a00000010081ba50>] _raw_spin_lock+0x50/0xe0 sp=a000000100f07df0 bsp=a000000100f01cf8 [<a0000001001e9450>] kmem_cache_free+0x2f0/0x560 sp=a000000100f07df0 bsp=a000000100f01ca8 [<a0000001001e97a0>] slab_destroy+0xe0/0x100 sp=a000000100f07e00 bsp=a000000100f01c70 [<a0000001001e9a20>] free_block+0x260/0x2e0 sp=a000000100f07e10 bsp=a000000100f01c10 [<a0000001001ea4b0>] kfree+0x490/0x620 sp=a000000100f07e10 bsp=a000000100f01bb8 [<a0000001001eafb0>] do_tune_cpucache+0x450/0xba0 sp=a000000100f07e20 bsp=a000000100f01b40 [<a0000001001ebbb0>] enable_cpucache+0x110/0x1e0 sp=a000000100f07e20 bsp=a000000100f01b08 [<a000000100acf380>] kmem_cache_init_late+0x60/0x240 sp=a000000100f07e20 bsp=a000000100f01ae0 [<a000000100aa92b0>] start_kernel+0x570/0x980 sp=a000000100f07e20 bsp=a000000100f01a60 [<a0000001007eaa00>] start_ap+0x760/0x780 sp=a000000100f07e30 bsp=a000000100f019c0 Console: colour dummy device 80x25 Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 48 ... MAX_LOCKDEP_KEYS: 1023 ... CLASSHASH_SIZE: 512 ... MAX_LOCKDEP_ENTRIES: 16384 ... MAX_LOCKDEP_CHAINS: 32768 ... CHAINHASH_SIZE: 16384 memory used by lock dependency info: 2839 kB per task-struct memory footprint: 2688 bytes ---------------------------------- | Locking API testsuite disabled | ---------------------------------- caught one possbile recurive locking -- To unsubscribe from this list: send the line "unsubscribe linux-ia64" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
![]() |