From owner-freebsd-bugs Sat Dec 21 06:00:03 1996 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA10508 for bugs-outgoing; Sat, 21 Dec 1996 06:00:03 -0800 (PST) Received: (from gnats@localhost) by freefall.freebsd.org (8.8.4/8.8.4) id GAA10502; Sat, 21 Dec 1996 06:00:02 -0800 (PST) Date: Sat, 21 Dec 1996 06:00:02 -0800 (PST) Message-Id: <199612211400.GAA10502@freefall.freebsd.org> To: freebsd-bugs Cc: From: "Chad R. Larson" Subject: Re: kern/2248: Mitsumi CD-ROM driver has Reply-To: "Chad R. Larson" Sender: owner-bugs@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk The following reply was made to PR kern/2248; it has been noted by GNATS. From: "Chad R. Larson" To: freebsd-gnats-submit@freebsd.org, chad@anasazi.com Cc: Subject: Re: kern/2248: Mitsumi CD-ROM driver has Date: Sat, 21 Dec 1996 06:57:23 -0800 I turned on debugging for the driver. It reported that it was finding data with a delay of between 10 and 40. I believe that is the count of the number of times mcd_doread() scheduled itself via timeout() before the controller reported status. If so, the read delay value of 800 is more than enough. However, every dozen or so reads do not ever get data. Those ones are the ones that generate the timeout messages. The retrys always work. It is almost as though the controller doesn't see the read data command every so often. I'm going to reduce the delay value from 800 to maybe 200. It won't solve the read fails, but will get around to the retry much sooner which should increase the effective throughput on the drive. Other tidbits: Each completed read generates a "stray interrupt", which tells me that the strategy of mcd_doread() repeatedly scheduling itself wouldn't be necessary. Let the interrupt cause data to be collected. Also, putting the computer into and out of "turbo" mode (changing CPU clock rate from 133 MHz to 33MHz and back) doesn't seem to impact the behavior, so I don't think it's directly related to timing. I suppose it's possible that the controller itself is defective, but it was working perfectly in another machine. Any other ideas to try? -crl -- Chad R. Larson (CRL22) Brother, can you paradigm? 602-953-1392 CRL22@aol.com chad@dcfinc.com chad@anasazi.com DCF, Inc. - 14623 North 49th Place, Scottsdale, Az 85254-2207