From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27612 invoked by alias); 7 Apr 2006 17:51:44 -0000 Received: (qmail 27600 invoked by uid 48); 7 Apr 2006 17:51:41 -0000 Date: Fri, 07 Apr 2006 17:51:00 -0000 Message-ID: <20060407175141.27599.qmail@sourceware.org> From: "joshua dot i dot stone at intel dot com" To: systemtap@sources.redhat.com In-Reply-To: <20060406181027.2525.joshua.i.stone@intel.com> References: <20060406181027.2525.joshua.i.stone@intel.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug translator/2525] NMI Watchdog lockup with gettimeofday and do_timer probe 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/msg00071.txt.bz2 ------- Additional Comments From joshua dot i dot stone at intel dot com 2006-04-07 17:51 ------- (In reply to comment #2) Many thanks Bibo for the detailed analysis! (In reply to comment #3) > Sigh, another printk-like situation. This would only be a partial solution, but > could the timer callback functions be made one more level indirect, by > interposing a level of work queing? The problem was discovered with a kprobe, not a timer probe - are you just extrapolating? Indeed, this will likely be a problem for timer.profile as well, but I think timer.ms and timer.jiffies run in a different context. I will try each variant and make sure though. Work queuing may be ok for ms and jiffies probes if needed, but for timer.profile I don't think that will work. Won't the trapframe be invalid if we delay the probe execution? > Alternately, is there a lower-level approximate gettimeofday equivalent that > does not putz with locks? I don't know of one - nothing in linux/time.h looks promising. The xtime_lock is exported though, so we should be able spin until read_seqretry returns 0, and we can limit it to MAXTRYLOCK and throw an error, just like we do for our own locks. If someone else comes along and locks it after we determine we're clear, that's ok because it won't be anyone in our callstack, so there won't be a deadlock. This should allow safely calling do_gettimeofday, and if we find a non-locking alternative we can use that as a fallback. I will implement this lock-test in timestamp.stp... -- What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|systemtap at sources dot |joshua dot i dot stone at |redhat dot com |intel dot com Status|NEW |ASSIGNED http://sourceware.org/bugzilla/show_bug.cgi?id=2525 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.