From owner-freebsd-hackers Sun Jan 16 17:56:48 2000 Delivered-To: freebsd-hackers@freebsd.org Received: from feral.com (feral.com [192.67.166.1]) by hub.freebsd.org (Postfix) with ESMTP id 641D7151C9 for ; Sun, 16 Jan 2000 17:56:45 -0800 (PST) (envelope-from mjacob@feral.com) Received: from semuta.feral.com (semuta [192.67.166.70]) by feral.com (8.9.3/8.9.3) with ESMTP id RAA24840; Sun, 16 Jan 2000 17:56:41 -0800 Date: Sun, 16 Jan 2000 17:56:41 -0800 (PST) From: Matthew Jacob Reply-To: mjacob@feral.com To: Chris Dillon Cc: hackers@FreeBSD.ORG Subject: Re: looking for victims, err, uh, 'volunteers' In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > Hmm... I guess I was confusing this with the S.M.A.R.T. stuff that is > supposed to give you a kind of pre-emptive warning that bad things are > going to happen (or have happened, rather... i.e. the drive starts > reallocating a bunch of blocks or senses some other kind of internal > problem). You should be able to get that via camcontrol right now for SCSI disks. If not, bug Ken. > Will what you've done at least allow the nifty "I'm OK" LED > to light up on the hot-swap disk tray like it does on the NT boxen? > *duck* :-) Well, following the lead of Unix as it has been, I've provided the tools- at least for SES/SAF-TE to do this. Because there's SMART and DTMF and LM78 and i4b busses all over the map, I haven't tackled the task of trying to unify this- nor should I in all probability- it's not my strength. But I waited basically a year for NetBSD/FreeBSD folks to move on this, so rather than waiting any longer I put in what I have 'coz *I* can use it. > > On a similar note, I guess, how exactly _would_ you query a drive > about its SMART status in FreeBSD? It would be neat to have the > status LEDs on the drive trays reflect the health of the drive. If I > read your description of the SAF-TE/SES stuff right, that is what > would be used to twiddle the LED off/on. Yes. There are several ways this can work, but the basic notion here is that the SES driver is a passive agent whose job it is to package stuff inbound and outbound. You have to have a user agent that monitors, periodically, for events. I did not, nor do I believe it's wise, make the SES driver do it's own polling. The user agent can notice events, and possibly respond to them (e.g., enabling an alarm if a power supply is detected bad). It's also possible that the agent can do correlative disk logging and set an enclosure's slot LED appropriately for a disk that has gone bad. This is a very hard problem to do without a lot of help from config files because physical topology is not incomplete. -matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message