Date: Wed, 29 Jan 1997 10:15:23 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: phk@critter.dk.tfs.com (Poul-Henning Kamp) Cc: terry@lambert.org, gibbs@narnia.plutotech.com, FreeBSD-current@freebsd.org, FreeBSD-stable@freebsd.org Subject: Re: Aic7xxx driver instability with the Quantum Atlas Message-ID: <199701291715.KAA12138@phaeton.artisoft.com> In-Reply-To: <14145.854528862@critter.dk.tfs.com> from "Poul-Henning Kamp" at Jan 29, 97 10:07:42 am
next in thread | previous in thread | raw e-mail | index | archive | help
> >> >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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199701291715.KAA12138>