computer reliability
in [Design]
|
Prev: Dumbed down consumer electronics: Adding DTV channels
Next: Can I run a "brushless DC FAN" backwards?
From: Paul Keinanen on 3 Aug 2010 07:18 On Mon, 2 Aug 2010 16:47:25 -0700, "Joel Koltner" <zapwireDASHgroups(a)yahoo.com> wrote: ><krw(a)att.bizzzzzzzzzzzz> wrote in message >news:qgie565q4vlml8igptmv351sr7539qie36(a)4ax.com... >> On Mon, 2 Aug 2010 11:12:26 -0700 (PDT), JeffM <jeffm_(a)email.com> wrote: >> No. The OS must not be *able* to be crashed by an application. *WHATEVER* >> mischief the application tries to get into. > >BSODs are usually caused by a bug in the OS itself -- some user mode >application makes a system call, and some driver or other part of the OS >doesn't check parameters or whatever and -- poof! -- a bug causes a critical >bit of memory to be overwritten or some important process table trashed. In Windows NT 3.5x most of the graphic interface was handled in user mode, causing a lot of slow user/kernel/user mode changes. To improve speed, in NT 4.0, most of the GUI code was moved into kernel mode, but they forgot to add the parameter cheks :-). Just calling some innocent looking GUI routine and passing a null pointer by mistake, where a valid pointer was required could cause the BSOD :-). NT4.0 SP1 at least added parameter checks. The situation with NT4 service packs was as bad as with the base operating system version, only every other service pack was usable, since it patched the bugs introduced by the previous SP :-). Regarding the kernel mode overwriting problems, part of the blame goes to Intel, since the 386+ family only contained write protection on the segment register level, but not on virtual memory page level. Super minicomputers in the 1970's had page level write protection, so this was nothing new when the 386 was created. If the OS had used sensible code and data virtual address mapping, even the limited segment based protection would have helped a lot to catch bugs. While handling exceptions caused by kernel mode access is risky in a production system, at least a lot of kernel driver bugs could have been detected during during driver testing, if the driver address space could be limited. Fortunately, the most recent versions of the x86 architecture will provide some page level protection against illegal memory access.
From: Jan Panteltje on 3 Aug 2010 09:01 On a sunny day (Mon, 02 Aug 2010 17:45:43 -0500) it happened "krw(a)att.bizzzzzzzzzzzz" <krw(a)att.bizzzzzzzzzzzz> wrote in <qgie565q4vlml8igptmv351sr7539qie36(a)4ax.com>: >On Mon, 2 Aug 2010 11:12:26 -0700 (PDT), JeffM <jeffm_(a)email.com> wrote: > >>>Richard Henry wrote: >>>>[USS] Yorktown[...] >>>>http://gcn.com/articles/1998/07/13/software-glitches-leave-navy-smart-ship-dead-in-the-water.aspx >>>> >>Robert Baer wrote: >>>Whoever wrote the data entry program >>>should be strung up buy the balls for NOT checking >>>the validity of EVERY parameter entered during entry! >>>There is absolutely NO excuse! >>> >> The Rules of Operating System Design >>#1 Applications must never crash the OS. >>#2 APPLICATIONS MUST NEVER CRASH THE OS. > >No. The OS must not be *able* to be crashed by an application. *WHATEVER* >mischief the application tries to get into. That is a bit difficult, maybe too high a bar, how about 'as a normal user'. A program running with root rights can destroy anything with a few lines.
From: Joel Koltner on 3 Aug 2010 12:59 miso(a)sushi.com wrote: > On Aug 2, 5:27 pm, "k...(a)att.bizzzzzzzzzzzz" <k...(a)att.bizzzzzzzzzzzz> >> Creative has always ignored reliability. Their products have >> *always* sucked as badly as M$, or worse. I'm surprised they've >> survived. > Creative survives because everyone else is just as bad. Yeah, I figured Creative survives becaue their marketing guys are the one above-average thing in the company: "Soundblaster" is a catchy name, and they took a cue from the home stereo audio designer crowd in making their packaging look "slick."
From: Joel Koltner on 3 Aug 2010 13:03 Grant wrote: > USB is simply a souped up keyboard and mouse clocked serial data > interface: 5V, clock, data, 0V down only just so far of shielded > cable. At the hardware level, sure, but what really makes USB useful is all the "standard" device class protocols so that all keyboards, mice, memory sticks/hard drives, etc. work regardless of the manufacturer. *Many* sound cards and webcams also use a standard protocol, so no special drivers are needed either. Interestingly, I've been told that there is a USB device class for "USB to RS-232-type serial ports," but that no one uses it. Apparently this hasn't been that big of a problem with the "big three" of FTDI, Prolific, and Keyspan making up the vast majority of all USB to serial converter dongles out there. ---Joel
From: Joel Koltner on 3 Aug 2010 13:04
Jim Thompson wrote: > And slew-rate controls to keep the EMI in check... what I have the > patents for (Intel only knows fast, zippo on analog :-) Bah. I bet that when the Chinese manufacturers started building their own USB driver ICs, they didn't bother with any of that. :-) |