On 05-Feb-18 13:36, Clem Cole wrote: > > > Point taken, but DEC used the SPD as its primary defense for exactly > this type of problem. It was the 'legal' definition of what was and > was not allowed. But as you point out, that behavior does not always > make for happy customers or sr managers. > I started in the field, and consulted with the corporate flying squads. The SPDs' value as legal definition was of more interest to lawyers & junior product managers than to those at the sharp end of the spear. Happiness, even at expense above and beyond legal technicalities brought more business than sticking to the letter of the law. Unhappiness was very, very expensive. I have stories that run both ways... > > > The truth is in at least Tru64 (I think is was Feed Knight - Mr. > SCSI) had code that detect when your SCSI bus was being shared. > It would have been easy to add add a side look up to check the > control being used and if it was not in the official table, > produce a boot message saying -- "/shared bus with unsupported > SCSI controller, please remove sharing or replace controller and > reboot."/ > > > But I could never get marketing to accept that. > I wish it were that simple. In this case, Marketing's intuition covered some technical challenges. I had many a talk with Fred when I was in the Tru64 group. That 'table' would have to deal not only with controller types, but with compatibility of firmware versions for every device on the bus. And the permutations of what worked (and didn't) weren't static. The sys_check maintainer made some efforts, as did the SPEAR folks in CSSE. But everything was a moving target.
The trivial case of "don't ever use this controller in a cluster" isn't all that hard to blacklist. Of course, when the foobar-plus comes out with a different device ID, but the same bug, you have to blacklist it too. Before any customer finds one a "American Used Computers" (Kenmore Square, before e-bay:-) And don't forget that to find another controller on the bus, you have to enumerate the bus. This can have side-effects with "bad" controllers. The bugs weren't all limited to fail-over. IIRC tagging and command queuing had issues; at least one controller created parity errors (and some undetected one). But maintaining a useful whitelist - with all the churn in the SCSI space - would be a nightmare. Disks have firmware & HW revs. Controllers too. Blocking all 3rd party disks (despite the frequent firmware issues) isn't viable. Don't forget CD/DVD, tape, and even ethernet. Even getting customers to install patches was hard (patch quality and interactions was one of my issues); patching to keep up with hardware/firmware revs wasn't going to fly. And you need this information before you have a file system; preferably in the boot driver. So no, not a config file. Maybe SRM console environment variables... Even in the relatively controlled environment that DEC was able to impose, SCSI should have been called CHAOSnet - except that name was taken. Worse, once you produce one error message in a problem space (e.g. invalid HW config), suddenly NOT producing errors for all other cases that don't work become bugs. > My point was that if we detected it (which was not not that hard), > then we could have at least said something. And in practice if you > still ignored it and it was in all those system logs, it would have > been pretty easy to say to the end customer, /we told you not to do that/. By the time it's in a system log, it's too late. The logging disk is probably on the SCSI bus. "I told you so" - not a happy strategy. For the simple case of only two machines sharing a bus: what do you mean by "at boot time"? The first machine powers up, and is "alone" with a "good" controller. Two weeks later, the owner of the second machine (with a "bad" one) returns from vacation and turns his on. His dog brought him a magazine article on clusters, so why not jump in? It might, maybe, manage to boot to the point of noticing the first one without polluting its transfers. Note that at this point, the first machine is undoubtedly doing disk writes; packet corruption is not as "harmless" as when you have a ROFS. And the second machine has to touch the first's controller to query it's versions. And to find it, it enumerates the entire bus. Meantime, does the first machine repeat the boot-time check? How does it notice? As I said, when something's wrong, logging to disk with an invalid hardware configuration isn't going fly. Above the hardware level, you're not in the cluster (yet), so how are you going to get the disk bitmaps (and locks)? And write to a ROFS? Normally, these are queued in memory (and retrieved for syslog by dmesg). But with this misconfiguration, the last thing you want to do is join the cluster & remount the logging disk R/W. So you can't log to disk. You might want to try to send to a network syslog - but that means you've gotten a LOT further into kernel initialization; you have a file system, network configuration, know where to send it, etc. Besides the fact that your network chip may be on the same SCSI bus, you've done a whole lot more I/O to get this far. With this kind of error, you want to make the test and panic very, very early in initialization to minimize collateral damage. There are many more cases to cover. This is one of the simpler. It's really not that simple to verify hardware configurations, once you dig in to the problem space. Fred's test was undoubtedly useful for logging & cluster initialization - with supported controllers. It might have been a good reminder for engineering experiments. I'd need to be convinced that it could solve the issue that you wanted to address. "For every problem, there is a solution that is simple, obvious, and ... wrong". You're correct that some simple check at driver initialization that stuck with console logging could probably be 80-90% effective. But getting the rest right, while an interesting engineering project, would be a P.roject. Sunshine with a slight chance of data corruption just wasn't the DEC way :-) As I said, a lot of fun for the engineers, but hard to justify in order to save a few customers $100.
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ Simh mailing list Simh@trailing-edge.com http://mailman.trailing-edge.com/mailman/listinfo/simh