Date: Sat, 17 Jun 95 18:23:03 MDT From: terry@cs.weber.edu (Terry Lambert) To: dennis@et.htp.com (dennis) Cc: freebsd-hackers@freebsd.org Subject: Re: Panics and such Message-ID: <9506180023.AA16472@cs.weber.edu> In-Reply-To: <199506172353.TAA22074@mail.htp.com> from "dennis" at Jun 17, 95 07:53:36 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> There are WAY too many panics in the BSD code. Somewhere along the line the > reason for a panic has been grossly expanded. I complained to BSDI (the > exact same code is in FreeBSD) when we discovered that an unrecognized ioctl > command to a raw socket will panic the machine. Of course they didn't write > the code..so they had no opinion (another story). Upon examination of the > code, there are many places where panics are used where an informational > display or logging would suffice (like trying to send an invalid ICMP > type...why panic, just don't do it). First off, they did write the code. The code is from CSRG, and the BSDI people are (largely) from CSRG. Second, if you can identify these problems as bug reports, they will be fixed. Third, I wasn't trying to imply that there were *no* gratuitous panics. The context of that posting was a claim that there were *no* panics in a particular OS, which could not be true. > These things really should be scrubbed, eventually. An emphatic YES here. Get them *logged* so we won't forget them! > As for the unrecoverable > stuff, there are machines that will never "panic" (like cisco routers). In > many cases you could just fail the operation or exit context, hoping that no > damage was done. You may just lose a buffer or send out a bogus packet. For > a commercial product, the "appearence" of indescructablity is > important....however if it happens often enough you will have a > non-functioning machine. On the cisco (2501) for example, if you send SABMs > (erroneously) on a serial link that the cisco has configured for frame > relay, you will get no error messages but in a few minutes all of the memory > in the machine will be consumed (probably by lost buffers). There's no panic > or crash, but the persistant problem eventually caused a system failure. The > thought behind it, I guess, is that in UNIX an isolated single event might > cause the system to go down, while on the cisco only 1 buffer would be lost > and the user would never know it. A system failure is a "panic", even if they don't put up the message. It's similar to the debugging philosophy on VMS and DOS, where you can't see the problem until after it has occureered, and then it is too late. A formal panic is a hell of a lot more debuggable than an eventual system crash with no reporting of the trigger situation to lead you back to the root of the problem. Oh, and I can kill a CISCO almost instantly. Just hook it upt to a large Novell network and wait for the SAP traffic to overrun memory. We could achieve the same effect in FreeBSD by changing the message from "PANIC:" to "SYSTEM FAILURE:" and have gained nothing. I'd much rather work to set up for a scrub. Terry Lambert terry@cs.weber.edu --- 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?9506180023.AA16472>