NetBSD Problem Report #45580

From jruohone@gmail.com  Sun Nov  6 16:10:39 2011
Return-Path: <jruohone@gmail.com>
Received: from mail.netbsd.org (mail.netbsd.org [204.152.190.11])
	by www.NetBSD.org (Postfix) with ESMTP id 3EC2363B8DB
	for <gnats-bugs@gnats.netbsd.org>; Sun,  6 Nov 2011 16:10:39 +0000 (UTC)
Message-Id: <20111106161029.DE1BD56C9@marx.bitnet>
Date: Sun,  6 Nov 2011 18:10:29 +0200 (EET)
From: Jukka Ruohonen <jruohonen@iki.fi>
Sender: a b <jruohone@gmail.com>
Reply-To: jruohonen@iki.fi
To: gnats-bugs@gnats.NetBSD.org
Subject: paths(3) test failures on sparc
X-Send-Pr-Version: 3.95

>Number:         45580
>Category:       port-sparc
>Synopsis:       paths(3) test failures on sparc
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    port-sparc-maintainer
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sun Nov 06 16:15:00 +0000 2011
>Last-Modified:  Thu Nov 10 16:05:01 +0000 2011
>Originator:     Jukka Ruohonen
>Release:        NetBSD 5.1_STABLE
>Organization:
-
>Environment:
>Description:

The test case (t_paths.c) timeouts on sparc/qemu. The test only uses
open(2) and stat(2) for files listed in <paths.h>.

>How-To-Repeat:

http://releng.netbsd.org/b5reports/sparc/build/2011.11.05.00.17.19/test.log

>Fix:

Unknown.

>Audit-Trail:
From: "Jukka Ruohonen" <jruoho@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc: 
Subject: PR/45580 CVS commit: src/tests/include
Date: Sun, 6 Nov 2011 16:18:27 +0000

 Module Name:	src
 Committed By:	jruoho
 Date:		Sun Nov  6 16:18:27 UTC 2011

 Modified Files:
 	src/tests/include: t_paths.c

 Log Message:
 Skip the test on sparc and point to PR port-sparc/45580.


 To generate a diff of this commit:
 cvs rdiff -u -r1.10 -r1.11 src/tests/include/t_paths.c

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

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: port-sparc-maintainer@netbsd.org, gnats-admin@netbsd.org,
	netbsd-bugs@netbsd.org
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Sun, 6 Nov 2011 17:43:36 +0100

 No, it does not fail on sparc, but only on QEMU emulating sparc.

 I'd suggest to re-enable the test case and file an upstream bug report.
 If we can't find somebody interested in fixing QEMU for sparc, we should
 stop the (for now) pointless b5 runs of that arch.

 Martin

From: Jukka Ruohonen <jruohonen@iki.fi>
To: Martin Husemann <martin@duskware.de>
Cc: gnats-bugs@NetBSD.org, port-sparc-maintainer@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Sun, 6 Nov 2011 18:52:12 +0200

 On Sun, Nov 06, 2011 at 05:43:36PM +0100, Martin Husemann wrote:
 > No, it does not fail on sparc, but only on QEMU emulating sparc.
 > 
 > I'd suggest to re-enable the test case and file an upstream bug report.
 > If we can't find somebody interested in fixing QEMU for sparc, we should
 > stop the (for now) pointless b5 runs of that arch.

 If this is a single case and we can identify qemu/sparc properly, we should
 bypass the test. There are many comparable issues on qemu/i386 and qemu/amd64
 too.

 - Jukka.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org, port-sparc-maintainer@NetBSD.org,
	gnats-admin@NetBSD.org, netbsd-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Sun, 6 Nov 2011 17:58:34 +0100

 On Sun, Nov 06, 2011 at 06:52:12PM +0200, Jukka Ruohonen wrote:
 > If this is a single case and we can identify qemu/sparc properly, we should
 > bypass the test. There are many comparable issues on qemu/i386 and qemu/amd64
 > too.

 I think most sparc test failures on b5 are in this category.

 Martin

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Sun, 6 Nov 2011 21:35:45 +0200

 On Sun, Nov 06, 2011 at 07:45:31PM +0100, Martin Husemann wrote:
 > hw.machine = sparc

 Wouldn't this mean that we can just use "sparc" as the identifier? It does
 not really matter whether an architecture skips a test case or two. We have
 3000 of those. But it does matter when these few cases prevent the whole
 test suite from completing.

 - Jukka.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Mon, 7 Nov 2011 07:18:46 +0100

 To be a bit more clear: the effect of the test case is not the test program
 hanging, but QEMU hanging completely.

 This can be reproduce (on QEMU running sparc) by:

  cd /usr/tests/include
  ./t_paths paths

 Martin

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Mon, 7 Nov 2011 14:47:23 +0200

 On Mon, Nov 07, 2011 at 06:20:04AM +0000, Martin Husemann wrote:
 >  To be a bit more clear: the effect of the test case is not the test
 >  program hanging, but QEMU hanging completely.
 >  
 >  This can be reproduce (on QEMU running sparc) by:
 >  
 >   cd /usr/tests/include
 >   ./t_paths paths

 As you seem to have qemu/sparc ready, can you check manually which device
 node in /dev causes this?

 - Jukka.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: jruohonen@iki.fi
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Mon, 7 Nov 2011 21:52:45 +0100

 On Mon, Nov 07, 2011 at 12:50:04PM +0000, Jukka Ruohonen wrote:
 >  As you seem to have qemu/sparc ready, can you check manually which device
 >  node in /dev causes this?

 Seems to be right away /dev/audio, but the same happens for /dev/audio0;
 you can reproduce it with

 	cat /dev/audio
 or
 	cat /dev/audio0

 as well. Anyone want to look at ad1848.c or cs4231.c and hunt for details?

 Martin

From: Jukka Ruohonen <jruohonen@iki.fi>
To: gnats-bugs@NetBSD.org
Cc: port-sparc-maintainer@NetBSD.org, gnats-admin@NetBSD.org,
	netbsd-bugs@NetBSD.org, Martin Husemann <martin@duskware.de>
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Thu, 10 Nov 2011 17:49:49 +0200

 On Sun, Nov 06, 2011 at 04:45:05PM +0000, Martin Husemann wrote:
 >  No, it does not fail on sparc, but only on QEMU emulating sparc.
 >  
 >  I'd suggest to re-enable the test case and file an upstream bug report.
 >  If we can't find somebody interested in fixing QEMU for sparc, we should
 >  stop the (for now) pointless b5 runs of that arch.

 We can bypass the test properly on qemu/sparc if something like "cpuctl
 identify 0 | grep QEMU" returns true? (AFAIR, it does on qemu/amd64.)

 - Jukka.

From: Martin Husemann <martin@duskware.de>
To: gnats-bugs@NetBSD.org
Cc: 
Subject: Re: port-sparc/45580: paths(3) test failures on sparc
Date: Thu, 10 Nov 2011 17:04:21 +0100

 On Thu, Nov 10, 2011 at 05:49:49PM +0200, Jukka Ruohonen wrote:
 > We can bypass the test properly on qemu/sparc if something like "cpuctl
 > identify 0 | grep QEMU" returns true? (AFAIR, it does on qemu/amd64.)

 No, that doesn't work for sparc. The ofctl -p | grep thing I mentionend
 earlier should work though.

 However, now that we nailed it down so far already, it should be easy to
 analyze further and then decide wether to work around it in the audiocs
 driver or talk to upstream.

 Martin

Home	PR Database Search