From owner-freebsd-hackers Mon Apr 1 11:11:00 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA18554 for hackers-outgoing; Mon, 1 Apr 1996 11:11:00 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA18533 Mon, 1 Apr 1996 11:10:51 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id FAA00611; Tue, 2 Apr 1996 05:06:24 +1000 Date: Tue, 2 Apr 1996 05:06:24 +1000 From: Bruce Evans Message-Id: <199604011906.FAA00611@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, freebsd-hackers@freebsd.org, freebsd-hardware@freebsd.org Subject: Re: Hacked kernel with option to disable "green" mode Sender: owner-hackers@freebsd.org X-Loop: FreeBSD.org Precedence: bulk >ftp://ftp.seagate.com/techsuppt/misc/no_idle.zip >on Seagate's Web site. Essentially, to turn off the "green mode" >inactivity timer, one issues controller command 0xFB for the relevant >drive, with a 0 in the controller's sector count register, during >initialization. (A number larger than zero sets the timer to that number of >milliseconds.) 0xFB is vendor specific according to the (old) ata-r4c draft. That standard has a lot about sleep, standby and idle modes, but only host- controlled modes. >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 It's much less complex than it needs to be :-). >[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.] It just forces a wdunwedge() call if the drive is unexpectedly busy in wdcommand(). wdunwedge() might fail because TIMEOUT is too short. It should be at least 31000000 (31 seconds). Bruce