Date: Sun, 2 Feb 1997 17:17:39 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: davem@jenolan.rutgers.edu (David S. Miller) Cc: terry@lambert.org, smp@csn.net, michaelh@cet.co.jp, netdev@roxanne.nuclecu.unam.mx, roque@di.fc.ul.pt, freebsd-smp@FreeBSD.org, smpdev@roxanne.nuclecu.unam.mx Subject: Re: SMP Message-ID: <199702030017.RAA09824@phaeton.artisoft.com> In-Reply-To: <199702022334.SAA19878@jenolan.caipgeneral> from "David S. Miller" at Feb 2, 97 06:34:37 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> What do you have to say about treating the cache line coherency? > Is it necessary, or is it automatic? > > I'm curious about Alan's theory about the situation as well. > > But on the whole, if a machine cannot pass the simple test you have > described here, and there is no side explanation for it, chuck the > machine because it is surely broken. > > If you start trying to code for such behavior, it will be more trouble > than it's worth. Claim it broken hardware and be done with it, ahhh > life is sweet again ;-) My initial reaction was to code to avoid triggering this class of error, and then ignoring the issue totally. The code will work whether or not the error exists. You may be right that it would be more trouble than it's worth. In the other hand, it is very tempting to make the code inherently "ruggedized" against terrible hardware. By the same argument as you are using, I could claim that most IDE hardware should be unsupported (for example). 8-). > But I think this will be explained away by something else, I can't let > myself believe that Intel would mess something so basic and necessary > like this these days. Well, I hope you are right, but given a choice between evils... 8-(. 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?199702030017.RAA09824>