From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2257 invoked by alias); 6 Jun 2009 14:21:31 -0000 Received: (qmail 2175 invoked by uid 48); 6 Jun 2009 14:21:10 -0000 Date: Sat, 06 Jun 2009 14:21:00 -0000 Message-ID: <20090606142110.2173.qmail@sourceware.org> From: "fche at redhat dot com" To: systemtap@sources.redhat.com In-Reply-To: <20090528090535.10212.maranp@linux.vnet.ibm.com> References: <20090528090535.10212.maranp@linux.vnet.ibm.com> Reply-To: sourceware-bugzilla@sourceware.org Subject: [Bug testsuite/10212] System hangs on running check.exp in systemtap snapshot : 0.9.7/0.141 commit release-0.9.7-167-geee30f4 X-Bugzilla-Reason: AssignedTo Mailing-List: contact systemtap-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: systemtap-owner@sourceware.org X-SW-Source: 2009-q2/txt/msg00807.txt.bz2 ------- Additional Comments From fche at redhat dot com 2009-06-06 14:21 ------- I see signs of two different problems in the kernel bug list. First, the arch_arm_kprobe->"BUG: using smp_processor_id() in preemptible" path, it seems like a kernel kprobe-implementation bug, in that it calls get_kprobe_ctlblk() without an active disable_preempt(). Systemtap could conceivably work around this by wrapping our kprobe registration calls in a preempt_disable/enable. Second, the stp_strncpy_from_user->__might_sleep path, this could be a runtime bug, or perhaps the absence of a suitable s390x facility to atomically copy data out. In fact, runtime/copy.c says: #elif defined (__s390__) || defined (__s390x__) #define __stp_strncpy_from_user(dst,src,count,res) \ do { res = strncpy_from_user(dst, src, count); } while(0) #endif which includes a might_sleep(). So it seems the s390x kernel needs some more code. -- http://sourceware.org/bugzilla/show_bug.cgi?id=10212 ------- You are receiving this mail because: ------- You are the assignee for the bug, or are watching the assignee.