NetBSD Problem Report #44387

From  Fri Jan 14 16:47:24 2011
Return-Path: <>
Received: from ( [])
	by (Postfix) with ESMTP id DD10E63B883
	for <>; Fri, 14 Jan 2011 16:47:23 +0000 (UTC)
Message-Id: <>
Date: Fri, 14 Jan 2011 16:47:22 +0000 (UTC)
Subject: some pthread mutex tests fail on ppc platforms
X-Send-Pr-Version: www-1.0

>Number:         44387
>Category:       port-powerpc
>Synopsis:       some pthread mutex tests fail on ppc platforms
>Confidential:   no
>Severity:       critical
>Priority:       high
>Responsible:    port-powerpc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 14 16:50:00 +0000 2011
>Last-Modified:  Thu May 19 01:45:00 +0000 2016
>Originator:     Jeff Rizzo
>Release:        5.99.43
NetBSD powerbookg4 5.99.43 NetBSD 5.99.43 (GENERIC) #1: Fri Jan 14 08:25:34 PST 2011  riz@hack.lan:/Users/riz/Documents/code/netbsd/obj/sys/arch/macppc/compile/GENERIC macppc

Using a kernel that is *not* build with "options DIAGNOSTIC", the
regression tests in /usr/tests/lib/libpthread/t_mutex fail on various
powerpc platforms.  The failing test basically creates two threads
which each increment a variable which is protected by a mutex; when it
fails (it doesn't fail 100% of the time), it looks like both threads
are in "parked" state.  (I have also seen one thread parked and one in

I confirmed this on two different macppc boxes I have, and I have at
least one test run from an ofppc box running 5.99.42 (without

For whatever reason, building the kernel with DIAGNOSTIC seems to hide
the problem.  I have not yet determined why; no additional output is

In case it matters: one machine has a PPC 7400, one has a 7447, and
one has a 750CX CPU.
On a machine with a GENERIC kernel:

cd /usr/tests/lib/libpthread
powerbookg4:riz  /usr/tests/lib/libpthread> ./t_mutex mutex2
1: Mutex-test 2
1: Thread 0xffe00000
2: Second thread (0xefa00000). Count is 10000000

<hang indefinitely>

Sometimes it does not hang - frequency of hang seems to vary by
machine and kernel.  You may also wish to run the entire pthread test
suite from that directory with "atf-run | atf-report".  It will take
about 10 minutes (because of the mutex test hangs).
None given.


From: "Jeff Rizzo" <>
Subject: PR/44387 CVS commit: src/tests/lib/libpthread
Date: Mon, 21 Feb 2011 21:43:42 +0000

 Module Name:	src
 Committed By:	riz
 Date:		Mon Feb 21 21:43:41 UTC 2011

 Modified Files:
 	src/tests/lib/libpthread: t_mutex.c

 Log Message:
 mutex2/mutex3 are expected to fail on powerpc because of
 PR port-powerpc/44387.

 XXX the ugly sleep at the end is because ATF will mark an un-triggered
 race condition (ie, the test passes unexpectedly) as a test failure otherwise.

 To generate a diff of this commit:
 cvs rdiff -u -r1.3 -r1.4 src/tests/lib/libpthread/t_mutex.c

 Please note that diffs are not public domain; they are subject to the
 copyright notices on the relevant files.

From: Valery Ushakov <>
Subject: Re: port-powerpc/44387: some pthread mutex tests fail on ppc
Date: Thu, 19 May 2016 04:43:31 +0300

 I did a bit of mixing and matching of normal and -DDIAGNOSTIC objects
 and apparently the bug does not manifest with -DDIAGNOSTIC kern_mutex.c

 So it's probably -DFULL that is enabled by -DDIAGNOSTIC, though I
 haven't tried narrowing it further down.



NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD:,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.