Date: Mon, 27 Feb 2006 12:38:26 -0700 From: Scott Long <scottl@samsco.org> To: Ariff Abdullah <ariff@FreeBSD.org> Cc: Mikhail Teterin <mi+mx@aldan.algebra.com>, re@FreeBSD.org, multimedia@FreeBSD.org Subject: Re: today's 6.1 would not boot here Message-ID: <44035532.1060408@samsco.org> In-Reply-To: <20060228025154.01db3dff.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>
next in thread | previous in thread | raw e-mail | index | archive | help
Ariff Abdullah wrote: > On Mon, 27 Feb 2006 13:21:32 -0500 > Mikhail Teterin <mi+mx@aldan.algebra.com> wrote: > >>ΠΟΞΕΔ¦ΜΟΛ 27 ΜΐΤΙΚ 2006 13:09, Scott Long χΙ ΞΑΠΙΣΑΜΙ: >> >>>I've lost track here, sorry. What are the problems with audio? >> >>6.1-PRERELEASE (as of yesterday) hangs solid on boot on the same >>system, where 6.0 (as of end of November) booted fine. >> >>Disabling the AC97 audio in the PC's BIOS allows booting to >>succeed... >> >>Ariff is aware of problems with the ich driver, but I'm not sure, >>whether he is planning to fix them before 6.1. IMHO, that is a must >>from -- at least -- the advocacy point of view... >> > > Problems within ich driver does exist since eon (especially the DMA > part). It was hidden until the recent improvement against the upper > layer which trying to promote loud failure in case a bug within > specific driver is triggered. > > My suggestions: > 1) Enable full debugging support (INVARIANTS, WITNESS, DIAGNOSTIC) > 2) Don't compile the driver within kernel, use the module instead. > 3) Don't load the module during boot. Do it manually *after* finish > booting (kldload sound ; kldload snd_ich) > 4) I need your pciconf -lv ;) > > In case all above failed, try to revert your ich.c to revision 1.53 . > > -- > Ariff Abdullah > FreeBSD 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. Scott
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?44035532.1060408>