From owner-freebsd-hackers Mon Apr 1 23:27:07 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id XAA16344 for hackers-outgoing; Mon, 1 Apr 1996 23:27:07 -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 XAA16323 Mon, 1 Apr 1996 23:27:01 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id RAA01028; Tue, 2 Apr 1996 17:23:05 +1000 Date: Tue, 2 Apr 1996 17:23:05 +1000 From: Bruce Evans Message-Id: <199604020723.RAA01028@godzilla.zeta.org.au> To: Brett_Glass@ccgate.infoworld.com, bde@zeta.org.au, 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 >> wdunwedge() might fail because TIMEOUT is too short. It should be at >> least 31000000 (31 seconds). >Based on Michael's account of what's in the ATA spec (i.e. that the drive >can take 30 seconds to come ready), this is correct. But it shouldn't wait It should wait 1 second longer for the slave drive. >the whole 31 seconds always, as the current code would do. It should check >again and again and GIVE UP after 31 seconds (or slightly more). Note that long waits (> 10 usec) usually only occur in initialization and panic dump code when it can't even use timeouts. Most waits occur at interrupt time when it can't use tsleep. >Of course, pausing 30 seconds in the kernel could be catastrophic for some >applications, Perhaps more importantly, pausing 30 seconds outside the kernel may be catastrophic :-). There is probably little difference where the wait occurs except on multi-disk-controller systems where the IDE controller is little used. >so implementing some of those proprietary commands is still >useful. The modification I sent in covers Seagate's. It can't be used in the standard driver because its operation is unknown. It might format the drives... Bruce