Date: Mon, 1 Apr 1996 12:47:02 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: Brett_Glass@ccgate.infoworld.com (Brett Glass) Cc: freebsd-hardware@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Hacked kernel with option to disable "green" mode Message-ID: <199604011947.MAA14012@phaeton.artisoft.com> In-Reply-To: <9603018283.AA828371297@ccgate.infoworld.com> from "Brett Glass" at Apr 1, 96 02:14:11 am
next in thread | previous in thread | raw e-mail | index | archive | help
> Tonight, I bit the bullet and hacked the FreeBSD kernel (specifically, the > wdc driver) to disable "green" mode on LARIAT.ORG's ST5660A IDE hard drive. > As reported in earlier messages, the drive was retracting its heads and > spinning down during periods of inactivity, which caused FreeBSD's disk > routines to time out and complain. The system would splatter the screen > with kernel error messages and freeze for seconds at a time. (I haven't > tried FreeBSD on a laptop, but this must occur frequently in that > environment if the same kind of drive is used.) Disabling "green" mode is probably not the cannonically correct soloution. The probably correct soloution would be to recognize the mode is active (spindle motor status query maybe?) and deal with it. The big thing about that is that the retriesand everything would have to be hidden, by class, at a common layer for a clean implementation that didn't care about particular hardware (like yours). > I'm not a UNIX kernel hacker (or I wasn't, anyway), and was utterly > unfamiliar with all the conventions used in FreeBSD, so the source in > wd.c took quite a while to analyze. (It's much more complex than it needs > to be, and uses -- Aargh! -- uninterruptible busy-waits at the kernel > level. THIS is why the entire OS freezes for seconds at a time.) After > much staring at the code, I figured out how to get an existing > function to do most of the work. The increase in kernel size was therefore > negligible. That's a very different problem. Basically, the kernel needs some event level driver preeemptability. You could do this by changing the busy waits to one-shot driven polls... but this would need a one shot facility, and would require significantly reworking the timer code to get that capability. > [Aside: Maybe, at the same time, someone could tell me what the SLEEPHACK > configuration bit does. It looks as if it's supposed to make the driver > more tolerant of drive spindowns on laptops, but I'm not sure that it will > work as advertised. On this machine, the unwedge() function, which it > calls, also complains when the disk spins down.] The unwedge can be a problem -- this was discussed in detail before on the lists -- it had to do with a tiemout while unwedging and the disk spinning up-dow-up-down in yo-yo mode as a result of drive reset. I thought that that had been handled. Anyway, it's better to have a soloution than to just be screwed. 8-). 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?199604011947.MAA14012>