From owner-freebsd-stable Wed Jan 29 09:34:05 1997 Return-Path: Received: (from root@localhost) by freefall.freebsd.org (8.8.5/8.8.5) id JAA11431 for stable-outgoing; Wed, 29 Jan 1997 09:34:05 -0800 (PST) Received: from phaeton.artisoft.com (phaeton.Artisoft.COM [198.17.250.211]) by freefall.freebsd.org (8.8.5/8.8.5) with SMTP id JAA11406; Wed, 29 Jan 1997 09:34:00 -0800 (PST) Received: (from terry@localhost) by phaeton.artisoft.com (8.6.11/8.6.9) id KAA12138; Wed, 29 Jan 1997 10:15:23 -0700 From: Terry Lambert Message-Id: <199701291715.KAA12138@phaeton.artisoft.com> Subject: Re: Aic7xxx driver instability with the Quantum Atlas To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Date: Wed, 29 Jan 1997 10:15:23 -0700 (MST) Cc: terry@lambert.org, gibbs@narnia.plutotech.com, FreeBSD-current@freebsd.org, FreeBSD-stable@freebsd.org In-Reply-To: <14145.854528862@critter.dk.tfs.com> from "Poul-Henning Kamp" at Jan 29, 97 10:07:42 am X-Mailer: ELM [version 2.4 PL24] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-stable@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > >> >Is there any possibility of determining the firmware rev from > >> >software? Then when the queue full condition occurs, you could > >> >print a console log message that tells you to update the > >> >firmware.... or just print that message on a queue full, always, or > >> >for Quantums. > >> > >> This can be done with a tiny shell script that looks at /var/run/dmesg.boot. > >> > >> Nobody with their sanity still moderately intact would add stuff like > >> this to the kernel. > > > >I was thinking of the install code, not the kernel, actually. No > >reason a console message has to originate from the kernel (syslog, et al.). > > Come on Terry, why not just admit you blew it... > > There's no way you can claim that "...when the queue full condition > occurs, ..." would or could refer to the install program... "When the queue full condition occurs" is an event, regardless of where it is handled. The even should trigger a user interaction causing an upgrade to take place at install time, before the error can damage real data stored on the disk. The event is triggerable with user space code operating on the raw disk device before a disklabel has been applied. I exchanged email with Justin T. Gibbs discussing a user space implementation of rogue handling which predates your admonition. Justin, btw. favors kernel space handling because he has globbing in the SCSI code for exactly that sort of thing already; I was not aware the globbing was there, and so advocated user space code to him. Contact Justin if you don't believe me. > But by all means suggest it to the linux camp, they seem to love that > kind of trash in their kernel. Not to justify a kernel implementation, but how many people, relatively speaking, run Linux instead of FreeBSD for reasons of Linux's ease-of-use vs. purity tradeoffs? Anything which works is better than anything that doesn't. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.