From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20846 invoked by alias); 5 Jun 2006 19:24:22 -0000 Received: (qmail 20823 invoked by uid 48); 5 Jun 2006 19:24:15 -0000 Date: Mon, 05 Jun 2006 19:24:00 -0000 Message-ID: <20060605192415.20822.qmail@sourceware.org> From: "wcohen at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20060601192814.2726.wcohen@redhat.com> References: <20060601192814.2726.wcohen@redhat.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug kprobes/2726] systemtap.base/probefunc.exp crash in kernel/module.c:2114 on RHEL4 X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2006-q2/txt/msg00564.txt.bz2 ------- Additional Comments From wcohen at redhat dot com 2006-06-05 19:24 ------- The variable being locked is modlist_lock, which is a static variable only visible within modules.c. It looks like a number of functions in module.c use that lock. Looking at the code in linux/include/linux/spinlock.h. The spin_lock_init() sets the babble field to 5. This is decremented by _raw_spin_lock(), and when it reaches 0 the message is printed out. However, there doesn't appear to be a place where the field babble is ever reset. Does this mean 5 tries at the lock? This is a UP kernel, so shouldn't the spinlocks be a no-op? Could voluntary preemption be affecting things? The kernel was built with: CONFIG_PREEMPT_VOLUNTARY=y -- http://sourceware.org/bugzilla/show_bug.cgi?id=2726 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.