From owner-freebsd-hackers Mon Apr 1 17:20:58 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id RAA20127 for hackers-outgoing; Mon, 1 Apr 1996 17:20:58 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id RAA20122 Mon, 1 Apr 1996 17:20:57 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id SAA14908; Mon, 1 Apr 1996 18:11:01 -0700 From: Terry Lambert Message-Id: <199604020111.SAA14908@phaeton.artisoft.com> Subject: Re: Hacked kernel with option to disable "green" mode To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Date: Mon, 1 Apr 1996 18:11:01 -0700 (MST) Cc: terry@lambert.org, freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG In-Reply-To: <9603018284.AA828400543@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 02:26:29 pm X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > > Disabling "green" mode is probably not the cannonically correct > > soloution. > > No, but it's an important feature to have available. While it's necessary > to have the OS "deal with it" when the drive spins down, it's also > extremely useful (especially on a multitasking OS with virtual memory) to > be able to tell the drive NOT to spin down. Since this involves issuing > low-level disk controller commands, it's properly implemented either as a > kernel option or as a privileged utility. There's no ioctl to issue a > controller command (should there be?), so the code has to go in the kernel > for now. OK. I agree. There should be an ioctl to issue a controller command for WD controllers -- we have one for SCSI. > > The probably correct soloution would be to recognize > > the mode is active (spindle motor status query maybe?) and deal > > with it. > > This should be incorporated as well -- so that users COULD let the drive > spin down (e.g. on a laptop). The idea of clock-interrupt-driven polling is > a good one, since it would let other tasks run. With 2.0.1-RELEASE, you > can't even type on the keyboard while waiting for a drive to spin up. And > on this system, IP packets were being dropped, and the serial buffers on > the system were overflowing due to incoming PPP traffic! Not good. I would prefer to have a reschedulable one-shot than to directly use the timer interrupt. The distinction is that the interrupt can be scheduled as a one shot down to the hardware resoloution instead of being limited to the clock frequency. The win here is that I can have a hardware interrupt to cause timed service routines in the kernel without giving up RT. This lets you replace recurrening events with rescheduling the oneshot, and replace DELAY() with a one-shot scheduling. The hard part in implementing this would be keeping other things, like the PC speaker sound driver, operational. If all you wanted to solve was the long duration hang of the WDC, I *suppose* (he said reluctantly) you could hook the system clock ISR using a callback registration list of some kind. It would be rather simple to implement, knowing beforehand that your even will occur *after* rather than *when* the timer goes (useless for a floppy tape driver in the kernel to kill of the user space "ft" program). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.