Date: Mon, 27 Feb 2006 17:03:50 -0700 From: Scott Long <scottl@samsco.org> To: Ariff Abdullah <ariff@FreeBSD.org> Cc: mi+mx@aldan.algebra.com, re@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: today's 6.1 would not boot here Message-ID: <44039366.7080605@samsco.org> In-Reply-To: <20060228051140.31f56b4f.ariff@FreeBSD.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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44039366.7080605>