Date: Tue, 28 Feb 2006 09:37:20 -0700 From: Scott Long <scottl@samsco.org> To: Scott Long <scottl@samsco.org> Cc: mi+mx@aldan.algebra.com, re@FreeBSD.org, multimedia@FreeBSD.org, Ariff Abdullah <ariff@FreeBSD.org> Subject: Re: today's 6.1 would not boot here Message-ID: <44047C40.2080907@samsco.org> In-Reply-To: <44039366.7080605@samsco.org> References: <20060227105017.77c18b20.ariff@FreeBSD.org> <200602271251.32890.mi%2Bmx@aldan.algebra.com> <44034054.3090104@samsco.org> <200602271321.33055.mi%2Bmx@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>
next in thread | previous in thread | raw e-mail | index | archive | help
Scott Long wrote: > Ariff Abdullah wrote: > >> On Mon, 27 Feb 2006 13:45:52 -0700 >> Scott Long <scottl@samsco.org> wrote: >> >>> Ariff Abdullah wrote: >>> >>>> On Mon, 27 Feb 2006 12:38:26 -0700 >>>> Scott Long <scottl@samsco.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44047C40.2080907>