Date: Thu, 27 Mar 2003 17:53:24 +0200 From: John Hay <jhay@icomtek.csir.co.za> To: Orion Hodson <orion@freebsd.org> Cc: current@freebsd.org Subject: Re: AC97 sound problems with current Message-ID: <20030327155324.GA85091@zibbi.icomtek.csir.co.za> In-Reply-To: <200303270749.h2R7nEAT095067@puma.icir.org> References: <3E828F75.1000400@btc.adaptec.com> <200303270749.h2R7nEAT095067@puma.icir.org>
next in thread | previous in thread | raw e-mail | index | archive | help
> > | > There is a calibration step in the driver to determine the clock rate of th > | e > | > AC97 link. What you are seeing is the calibration step failing and setting > | a > | > bogus ac97 link rate. I took a cursory look a couple of weeks back and it > | > smelt like the timecounter initialization point changed, but haven't gotten > | > | > around to looking closer and fixing the driver. > > It's definitely nothing to do with the timecounter - quick test on other h/w > along similar lines. I don't access to an ich board to test on - it's > probably obvious, but I'm not seeing it just now with visual inspection... It doesn't look like it is the timecounters. I just added some printfs and it looks like this: pcm0: measured ac97 link rate at 512000000 Hz t1 1.098359, t2 1.098363 ociv 0, nciv 1, bytes 8192 tsc1 445813142, tsc2 445821922, diff 8780 The tsc values are just from rdtsc(), I added tsc1 = rdtsc() just above the first microtime() and tsc2 just after the last. My machine is a 1.8G P4 (ICH2), so the timecounter values seem correct. I have kernel around the middle of Feb that gets the value right and one from March 4 that gets it all wrong. John -- John Hay -- John.Hay@icomtek.csir.co.za / jhay@FreeBSD.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030327155324.GA85091>