From owner-freebsd-multimedia@FreeBSD.ORG Tue Feb 28 16:37:40 2006 Return-Path: X-Original-To: multimedia@FreeBSD.org Delivered-To: freebsd-multimedia@FreeBSD.ORG Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id B1E2B16A420; Tue, 28 Feb 2006 16:37:40 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from pooker.samsco.org (pooker.samsco.org [168.103.85.57]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6637D43D5F; Tue, 28 Feb 2006 16:37:38 +0000 (GMT) (envelope-from scottl@samsco.org) Received: from [10.10.3.185] ([69.15.205.254]) (authenticated bits=0) by pooker.samsco.org (8.13.4/8.13.4) with ESMTP id k1SGbQba055884; Tue, 28 Feb 2006 09:37:28 -0700 (MST) (envelope-from scottl@samsco.org) Message-ID: <44047C40.2080907@samsco.org> Date: Tue, 28 Feb 2006 09:37:20 -0700 From: Scott Long User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.12) Gecko/20060206 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Scott Long References: <20060227105017.77c18b20.ariff@FreeBSD.org> <200602271251.32890.mi+mx@aldan.algebra.com> <44034054.3090104@samsco.org> <200602271321.33055.mi+mx@aldan.algebra.com> <20060228025154.01db3dff.ariff@FreeBSD.org> <44035532.1060408@samsco.org> <20060228043735.33bddf5d.ariff@FreeBSD.org> <44036500.4090802@samsco.org> <20060228051140.31f56b4f.ariff@FreeBSD.org> <44039366.7080605@samsco.org> In-Reply-To: <44039366.7080605@samsco.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=0.0 required=3.8 tests=none autolearn=failed version=3.1.0 X-Spam-Checker-Version: SpamAssassin 3.1.0 (2005-09-13) on pooker.samsco.org Cc: mi+mx@aldan.algebra.com, re@FreeBSD.org, multimedia@FreeBSD.org, Ariff Abdullah Subject: Re: today's 6.1 would not boot here X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Feb 2006 16:37:40 -0000 Scott Long wrote: > Ariff Abdullah wrote: > >> On Mon, 27 Feb 2006 13:45:52 -0700 >> Scott Long wrote: >> >>> Ariff Abdullah wrote: >>> >>>> On Mon, 27 Feb 2006 12:38:26 -0700 >>>> Scott Long wrote: >>>> >>>> >>>>> Is this a problem with calibrating the sample rate on the chip? >>>>> There was a problem with snd_ich several years ago where the >>>>> calibration would fail or be unpredictable during boot. I fixed >>>> >>>> >>>> it >my moving the calibration code to a separate step that gets >>>> run via >the config_intrhook API. That made it work reliably >>>> during boot >and when loaded after boot. Is this new problem >>>> somehow related to >this? Since I was the one who fixed it in the >>>> past, I'd be happy to >help now. >>>> >>>> It seems related. From my naked eyes, I can sense that the >>>> interrupt was trigered during/before sampling rate calibration, >>>> and since the calibration expect to not trigger any interrupt, >>>> this will cause unexpected behaviour especially for this MPSAFEed >>>> driver *and* during boot. Besides, the pcm construction also done >>>> before the calibration, unlike snd_atiixp where the hook is use to >>>> bring everything alive after the necessary step is finished. >>>> >>>> >>>> I'll come up with something shortly. >>>> >>> >>> Maybe move the bus_setup_intr() call to after the calibration? If >>> the driver doesn't need interrupts until after calibration, I think >>> that this would cleanly solve the problem. >>> >> >> Good idea, or, simply ignore interrupt trigger until all has been >> calibrated. Pretty much like this: >> >> http://people.freebsd.org/~ariff/test/ich.c >> > > Yup, that looks good too. > > Scott > Actually, I'll ammend that. If the ich device is sharing an interrupt (increasingly common these days) then interrupts from those other devices will still cause the ich handler to run, and you catch that with the the calibration flag that you put in there. But even though you exit right away from the handler, you still have to wait while the other handlers run, block on mutexes, etc. At the very least this will still corrupt the calibration results. On the other hand, if you don't register an interrupt handler until after the calibration is done and you are ready to handle interrupts, then you are guaranteed to avoid these problems. Adding a critical section around the calibration loop would further guarantee this. Scott