Date: Mon, 1 Apr 1996 18:11:01 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Cc: terry@lambert.org, freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Hacked kernel with option to disable "green" mode Message-ID: <199604020111.SAA14908@phaeton.artisoft.com> In-Reply-To: <9603018284.AA828400543@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 02:26:29 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199604020111.SAA14908>