From owner-freebsd-current@FreeBSD.ORG Wed Apr 21 18:20:43 2010 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CDB721065672 for ; Wed, 21 Apr 2010 18:20:43 +0000 (UTC) (envelope-from rdivacky@vlk.vlakno.cz) Received: from vlakno.cz (lev.vlakno.cz [77.93.215.190]) by mx1.freebsd.org (Postfix) with ESMTP id 85F6B8FC19 for ; Wed, 21 Apr 2010 18:20:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id F2E8C9CB084; Wed, 21 Apr 2010 20:18:17 +0200 (CEST) X-Virus-Scanned: amavisd-new at vlakno.cz Received: from vlakno.cz ([127.0.0.1]) by localhost (lev.vlakno.cz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDoDAQ+nh+mQ; Wed, 21 Apr 2010 20:18:14 +0200 (CEST) Received: from vlk.vlakno.cz (localhost [127.0.0.1]) by vlakno.cz (Postfix) with ESMTP id BA1819CB0E4; Wed, 21 Apr 2010 20:18:14 +0200 (CEST) Received: (from rdivacky@localhost) by vlk.vlakno.cz (8.14.3/8.14.3/Submit) id o3LIIDkd099215; Wed, 21 Apr 2010 20:18:13 +0200 (CEST) (envelope-from rdivacky) Date: Wed, 21 Apr 2010 20:18:13 +0200 From: Roman Divacky To: Alexander Best Message-ID: <20100421181813.GA97446@freebsd.org> References: <20100421152338.GA77210@freebsd.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Cc: freebsd-current@FreeBSD.org Subject: Re: [CFT]: ClangBSD is selfhosting, we need testers now X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Apr 2010 18:20:44 -0000 On Wed, Apr 21, 2010 at 07:22:00PM +0200, Alexander Best wrote: > Roman Divacky schrieb am 2010-04-21: > > On Wed, Apr 21, 2010 at 05:20:57PM +0200, Alexander Best wrote: > > > i might have stumbled upon a problem with clang. i've compiled a > > > kernel from > > > the clang branch using `make kernel INSTKERNNAME=clang` and booted > > > from it. > > > i'm now experiencing audio problems with mp3s and certain video > > > files. > > > playback is awfully slow and the audio output gets distorted > > > massively. `top` > > > however reports no high cpu load and `vmstat -i` doesn't report > > > anything > > > unusual either. > > > > this problem doesn't occur with a regular gcc-kernel. > > > > both kernels are running under a regular (gcc) world. > > > > i thought it might be a problem with acpi, but disabling acpi > > > (hint.acpi.0.disabled=1) gives me a system freeze. > > > I've heard about this problem but did not manage to reproduce that. > > > can you try to bisect what file is being miscompiled? ie. compile > > half of the kernel with gcc and half with clang and bisect this > > way to a single file. > > > we can work from there... > > i've identified the problem to be somewhere in sys/dev/sound. i've removed > "device sound" and "device hda_snd" from my kernel config and > rebuild/reinstalled both kernels (gcc and clang). i then booted the clang > kernel and loaded various sound.ko and snd_hda.ko combination. here're the > results: > > sound.ko (clang) snd_hda.ko (clang) => BROKEN > sound.ko (clang) snd_hda.ko (gcc) => BROKEN > sound.ko (gcc) snd_hda.ko (gcc) => OK > sound.ko (gcc) snd_hda.ko (clang) => OK great work! it looks like sound.ko is the culprit.. this is amd64 because my i386 kernel plays sound just fine. could you try to bisect the sound.ko ? you can do it this way: 1) cd modules/sound/sound && make CC=gcc 2) make -V SRCS | tr " " "\n" | grep -v \.h | sort | grep "^[a-m].*" | xargs touch ^^^^^ this is your bisect pattern 3) make CC=clang && make install 4) reload the module && test the sound 5) if the sound works you swap your bisect pattern (ie. [a-m] -> [n-z] etc.) if not you know that you that the miscompiled file is in you pattern and you can narrow it (ie. [a-m] -> [a-g] etc.) 6) goto 1 until you compile a single file I am pretty sure you can understand this and reduce this to a single file. once we get single file that is being miscompiled we can do some slightly \more educated guess on whats going on and structure our testing a little smarter... thnx! roman