Date: Wed, 03 Apr 96 13:40:51 PST From: "Brett Glass" <Brett_Glass@ccgate.infoworld.com> To: Terry Lambert <terry@lambert.org>, jkh@freebsd.org Cc: terry@lambert.org, bde@zeta.org.au, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: It isn't easy being "green"... Message-ID: <9603038285.AA828564378@ccgate.infoworld.com>
next in thread | raw e-mail | index | archive | help
> And since the usefulness of disabling the mode is limited to people > with a burning need to run down the batteries in their laptops as > quickly as possible, > or people with "green desktop machines" that they really didn't want to > be green. There are a lot in the latter category! The machine on which I am installing is *not* a laptop. It's a perfectly ordinary Zeos Pantera 486DX/100 desktop. More than a hundred thousand of this make and model alone were sold. Right after the EPA announced its "Energy Star" program, MANY vendors incorporated these drives into desktop machines. And did not provide any way of turning off the "green" features -- on purpose, so that employees of corporations that purchased the machines couldn't do it on their own. By the way, "Nate and the Nomads" is a cool name. What is the status on their APM code? > I think graceful recovery from spindown is absolutely necessary, Agree 100%. > and ability to disable features that you have to go out of your way to > find in a computer (so presumably you wanted them to work instead of > being disabled) ought to be a controllable option. Again, for about a year, you almost couldn't avoid getting these "features," especially if you bought from certain big mail-order houses. > I think the primary use is for employees of companies trying to get > the EPA tax incentive for energy conservation by putting unreasonably > performant green machines on their employees desks. 8-). Yep. > As a workaround to making the drivers robust (which is something I > strongly think should *not* be worked around to incent a real fix), > you might be able to convince Jordan to call the utility as part of > the install. This should be sufficient to kludge around the bad > driver code, which is the problem that originally bit you in the > first place, without making it "standard practice". This would require three things. First, the ioctl to issue arbitrary ATA commands would need to be added to the disk driver. (This is not hard.) Second, the "disable spindown" utility would need to be called for each IDE drive during the install (it would gracefully exit if it did not recognize the hard drive). Finally, if a drive WAS found that the code worked on (the installation could determine this via an exit code), the command would need to go into rc.local during install. Jordan, would you be willing to add this logic to the install? I'd be glad to add the ioctl, just so someone checked my work to make sure I wasn't unknowingly stepping on anything. --Brett
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9603038285.AA828564378>