RE: HEADS UP: new loader.rc stuff
> -Original Message- > From: Daniel C. Sobral [mailto:d...@newsguy.com] > Sent: 10 March 1999 03:47 > To: curr...@freebsd.org > Subject: HEADS UP: new loader.rc stuff > > Meanwhile, the new loader.rc stuff, for those who want it. It is > modeled after rc.conf files. We now have a > /boot/defaults/loader.conf, with all defaults (meaning it hardly > does anything, serving more as a template), which will also load > /boot/loader.conf and /boot/loader.conf.local, in that order, if > present. > > The idea is to leave /boot/loader.conf for sysinstall, > /boot/loader.conf.local for the user, and /boot/defaults/loader.conf > to installworld. > Hmm, feeling of deja-vu here :-) Why do we need three levels of config files? Can't we make do with two? Configuration of the system is becoming more and more of a horrible mess of spaghetti. I think /boot/defaults/loader.conf and /boot/loader.conf should be enough. It's just confusing otherwise, if I change something with sysinstall I may, or may not, cause an effect depending on whether I've twiddled the same knob in loader.conf.local. I see sysinstall as just an alternative user interface to vi or emacs for editing options. Is there something awkward about the way sysinstall works that requires it to have its own config file? Paul. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new loader.rc stuff
p...@originative.co.uk wrote: > > Hmm, feeling of deja-vu here :-) It was on purpose. :-) > Why do we need three levels of config files? Can't we make do with two? Yes, two are enough. > Configuration of the system is becoming more and more of a horrible mess of > spaghetti. That's an unavoidable trade off of flexibility. > I think /boot/defaults/loader.conf and /boot/loader.conf should be enough. > It's just confusing otherwise, if I change something with sysinstall I may, > or may not, cause an effect depending on whether I've twiddled the same knob > in loader.conf.local. Then don't use loader.conf.local. > I see sysinstall as just an alternative user interface to vi or emacs for > editing options. Is there something awkward about the way sysinstall works > that requires it to have its own config file? No. Well, sysinstall doesn't even touch these files yet, but I don't expect it to do anything strange. You can safely use just two files. If you don't want a third (or fourth, fifth, whatever) file, just do not create/use them. There are people who *really* prefer not to have their stuff touched by anything. That's why the support exists. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "FreeBSD is Yoda, Linux is Luke Skywalker." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
Matthew Dillon writes: > I would disagree with that. Invariants are for people who want > their data to be as safe as possible and don't mind eating a little > cpu doing extra sanity checks in the kernel. It is something I would > almost certainly enable in a production kernel. Uh, no. Invariants are for developers who want to make sure their code is correct. There is no reason why an end user would want to build a kernel with invariants enabled. Invariants will *not* increase data safety. If they have any effect at all (i.e. if they actually catch a bug), the result is a panic (whereas with a kernel without invariants, the bug might actually go unnoticed). You must be thinking of the FAILSAFE option. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: wchar.h?
On Tue, 9 Mar 1999, Archie Cobbs wrote: > The jikes Java compiler relies on an include file "whcar.h" being > on the system. However, even if it's not, it includes routines > to do what it needs... only about 40 lines or so for these functions: I was bitten by this one recently too, and there are quite a few messages in the mailing-list archives on the subject. If I remember right (without looking right now) the reason it hasn't been included was some sort of issue of 16bit vs 32bit. The short answer is you need write your own functions and header file that you need, or use the Xwchar library that came in the original X11R5/contrib distributions (with slight modifications to the header file to use FreeBSD's wchar_t type and specific includes). It looks like jikes does the 'right thing' just because there's not that much consistancy across platforms. Just FYI HP, linux, and solaris all include a wchar.h, but different systems are missing different wcs* type functions. --- Mark Atkinson Checkpoint Technologies' Metaip Group ma...@metaip.checkpoint.com !(wired)?(coffee++):(wired) To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
> Uh, no. Invariants are for developers who want to make sure their code > is correct. There is no reason why an end user would want to build a > kernel with invariants enabled. Invariants will *not* increase data > safety. If they have any effect at all (i.e. if they actually catch a > bug), the result is a panic (whereas with a kernel without invariants, > the bug might actually go unnoticed). So for the end user it's better to have the bug go unnoticed than to get a kernel panic and notice the bug? Please tell me I'm misunder- standing something here. Steinar Haug, Nethelp consulting, sth...@nethelp.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
On Wed, 10 Mar 1999 sth...@nethelp.no wrote: > > Uh, no. Invariants are for developers who want to make sure their code > > is correct. There is no reason why an end user would want to build a > > kernel with invariants enabled. Invariants will *not* increase data > > safety. If they have any effect at all (i.e. if they actually catch a > > bug), the result is a panic (whereas with a kernel without invariants, > > the bug might actually go unnoticed). > > So for the end user it's better to have the bug go unnoticed than to > get a kernel panic and notice the bug? Please tell me I'm misunder- > standing something here. I have to concur. I've never understood the "don't worry be happy" point of view on this issue. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
< said: > I have to concur. I've never understood the "don't worry be happy" > point of view on this issue. Do you always compile and install all your programs with debugging symbols? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
sth...@nethelp.no writes: > > Uh, no. Invariants are for developers who want to make sure their code > > is correct. There is no reason why an end user would want to build a > > kernel with invariants enabled. Invariants will *not* increase data > > safety. If they have any effect at all (i.e. if they actually catch a > > bug), the result is a panic (whereas with a kernel without invariants, > > the bug might actually go unnoticed). > So for the end user it's better to have the bug go unnoticed than to > get a kernel panic and notice the bug? Please tell me I'm misunder- > standing something here. No, it is not - not in the general case, and not in the long term. I was trying to point out that there may be extreme cases where an otherwise harmless bug would cause a panic with invariants enabled. Matt claimed that invariants increase data safety, which I find difficult to understand. The only possible value an end user could derive from a kernel with invariants is a backtrace to attach to a send-pr. DES -- Dag-Erling Smorgrav - d...@flood.ping.uio.no To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
On Wed, 10 Mar 1999, Garrett Wollman wrote: > < said: > > > I have to concur. I've never understood the "don't worry be happy" > > point of view on this issue. > > Do you always compile and install all your programs with debugging > symbols? No, but I didn't think that was what we were talking about. I thought we were talking about assertions. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
On Wed, 10 Mar 1999, Garrett Wollman wrote: > < said: > > > I have to concur. I've never understood the "don't worry be happy" > > point of view on this issue. > > Do you always compile and install all your programs with debugging > symbols? This is the DEVELOPMENT branch of the FreeBSD project, and you know that. > > -GAWollman > > -- > Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the > same > woll...@lcs.mit.edu | O Siem / The fires of freedom > Opinions not those of| Dance in the burning flame > MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > Brian Feldman_ __ ___ ___ ___ gr...@unixhelp.org _ __ ___ | _ ) __| \ http://www.freebsd.org/ _ __ ___ | _ \__ \ |) | FreeBSD: The Power to Serve! _ __ ___ _ |___/___/___/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
< said: > No, but I didn't think that was what we were talking about. I thought > we were talking about assertions. We were talking about invariants, which document the conditions which nearby code expect and/or cause. To actually check these conditions in a production system is a waste of CPU power; their function is to define for the developers precisely what the expected outcome of a particular operation is, so that new bugs are not introduced when code is modified. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same woll...@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
:We were talking about invariants, which document the conditions which :nearby code expect and/or cause. To actually check these conditions :in a production system is a waste of CPU power; their function is to :define for the developers precisely what the expected outcome of a :particular operation is, so that new bugs are not introduced when code :is modified. : :-GAWollman : :-- :Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same I would not characterize the use of invariants in production kernels as being a waste of cpu power... I'm sure there are many people who are more interested in data integrity then in performance. The use of inviariants can conceivably catch a problem early that might otherwise corrupt the system later. On the otherhand, the speeddaemons might not want either the invariants or the standard sanity checks, in which case they do not turn on invariant support and they do turn on MAX_PERF ( which gets rid of most of the standard sanity checks ). -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
:No, it is not - not in the general case, and not in the long term. I :was trying to point out that there may be extreme cases where an :otherwise harmless bug would cause a panic with invariants enabled. : :Matt claimed that invariants increase data safety, which I find :difficult to understand. : :DES There is no such thing as a harmless bug. If it's a bug, it needs to be fixed. Many 'harmless bugs' which are noted in source code come back to bite you later when some other programmer adds new code that uses a function in a legal but never-before-tested way. It is my considered opinion that one of the reasons why it has taken FreeBSD years to work out and fix serious bugs in the kernel is that there are simply not enough sanity checks being made in the kernel. The VM system is especially fragile in this regard, but most of the rest of the system has the same problem. For example, trying to block on a lockmgr lock inside an interrupt should result in an instantanious panic. But it doesn't. I can recall at least a dozen bugs that took months to locate because that sort of sanity check is not being made. It is *NOT* 'harmless', even if the occassional hit doesn't fry the system. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
:Uh, no. Invariants are for developers who want to make sure their code :is correct. There is no reason why an end user would want to build a :kernel with invariants enabled. Invariants will *not* increase data :safety. If they have any effect at all (i.e. if they actually catch a :bug), the result is a panic (whereas with a kernel without invariants, :the bug might actually go unnoticed). : :You must be thinking of the FAILSAFE option. : :DES :-- :Dag-Erling Smorgrav - d...@flood.ping.uio.no I would rather the system panic then corrupt a filesystem. Invariants are most useful to developers, but just because a developer's testing doesn't hit any invariants doesn't mean that the invariant won't get hit after the developer commits his code. I think what you are missing here is the fact that allowing bugs to go unnoticed draws out the debugging process. If we had more KASSERT's in the kernel 3 years ago, we would not still have a buggy kernel today. Sweeping bugs under the rug this way does not help anyone. It goes without saying that users catch almost as many bugs as developers, they simply can't fix them. When the a production kernel does not perform extra sanity checks, a bug can remain undetected for years. Therefore, my preference is to turn invariants on on all my production kernels as well as my development kernels. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
You two are basically discussing "overspecifying source code" vs "normal source code". It doesn't really matter much if the overspecifying consists of merging the TeX sources for a book or by adding invariants as part of design verification. The discussion itself has about as much merit as our recent style(9) discussions, split infinitives included or not: It is pointless. We already have one option in the kernel for "increased sanity checks", it's called "DIAGNOSTIC" and it is legal to add (even substantial) amounts of extra code under that option, as long as there is a sensible reason. Several of my kernels run with DIAGNOSTIC defined, and debug symbols and basic-block profiling to boot. And yes, I do find bugs that way. And no, I would hate to spend 50% of my performance on those options in production. Considering that I think a sensible approach here would be to define a global macro called "INVARIANT(condition, text)" as follows: #ifdef DIAGNOSTIC #define INVARIANT(condition, text) if (condition) ; else panic(text) #else #define INVARIANT(condition, text) do ; while (0) #endif In a suitably global kernel include file. Can everybody live with that as a compromise ? -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
I don't use DIAGNOSTIC because it's overly intrusive and cause cause panics or create bugs where none exist. At least that was true in 2.2.x. I remember trying to use it at BEST. The result was continually crashing machines due to bugs in the diagnostic code ( such as diagnostics that were using a blocking malloc() inside an interrupt ). Personally, I would be happier if DIAGNOSTIC were ripped out entirely and replaced with something less intrusive. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
In message <199903101944.laa57...@apollo.backplane.com>, Matthew Dillon writes: >I don't use DIAGNOSTIC because it's overly intrusive and cause cause >panics or create bugs where none exist. Then it should be fixed. >Personally, I would be happier if DIAGNOSTIC were ripped out entirely >and replaced with something less intrusive. I wouldn't. -- Poul-Henning Kamp FreeBSD coreteam member p...@freebsd.org "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
Brian Feldman wrote: > > On Wed, 10 Mar 1999, Garrett Wollman wrote: > > > < > said: > > > > > I have to concur. I've never understood the "don't worry be happy" > > > point of view on this issue. > > > > Do you always compile and install all your programs with debugging > > symbols? > > This is the DEVELOPMENT branch of the FreeBSD project, and you know that. Which would get back to my original (contested) statement: you shouldn't use INVARIANTS unless you are running blah, blah, blah, say, for example, -current. :-) -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "FreeBSD is Yoda, Linux is Luke Skywalker." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
MAGIC LINK EXCHANGE
Friend in the magic: My name is Eduardo Hernando, and I am devoted to maker of electronic effects for magicians, I would like if it is possible you to insert my link in your web. I would be pleased if you would agree to add my page to your website. If you would like to, let me know, and I will add your page to my website. My link: ELECTRONIC ILLUSIONS MAKER OF ELECTRONIC ILLUSIONS FOR MAGICIANS http://www.arrakis.es/~eduher/export.htm e. mailmagic...@arrakis.es To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: wchar.h?
On Tue, 9 Mar 1999, Archie Cobbs wrote: > wcslen() > wcscpy() > wcsncpy() > wcscat() > wcscmp() > wcsncmp() > > How come FreeBSD doesn't have these? Is there a complicated problem > preventing us from adding them? I have a start at all the wc functions in the NA1 of ANSI C which includes these and wide versions of most of the stdio functions (fgetwc, fputwc and the like) as well as wide iswxxx() ctype functions. Anybody who would like to finish the job is most welcome to what I have so far. (I've also got a Unicode UTF-8 local I'd like to bring in at some point...) -john To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
> I don't use DIAGNOSTIC because it's overly intrusive and cause cause > panics or create bugs where none exist. Then it should be fixed. I think DIAGNOSTIC is *supposed* to do everything you're arguing for and to scream for its removal in one breath and then call for a mechanism which does exactly what it was *supposed* to do in the next doesn't exactly advance the credibility of the argument, knowwhutahmean? - Jordan To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new loader.rc stuff
So this is actually just a general response to the whole thing--one of the things I actually dislike about rc.conf is its flexibility: the user can put anything script-wise they like into it. My temptation would be to reduce the flexibility: to have a simple name:value configuration file (with appropriate extensions for lists, quoted strings, etc) that is guaranteed to be readable by any third-party (or even first-party :) automated configuration programs. Depending on your mood, the name field could even be MIB-like (boot.runaway: yes). It just seems like sometimes scripts give too much flexibility :-); rather than providing useful increased functionality, they improve the chances that the user will screw themselves by taking advantage of it in ways that confuse automated utilities such as configuration checkers, managers, etc. Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
On Wed, 10 Mar 1999 sth...@nethelp.no wrote: > > Uh, no. Invariants are for developers who want to make sure their code > > is correct. There is no reason why an end user would want to build a > > kernel with invariants enabled. Invariants will *not* increase data > > safety. If they have any effect at all (i.e. if they actually catch a > > bug), the result is a panic (whereas with a kernel without invariants, > > the bug might actually go unnoticed). > > So for the end user it's better to have the bug go unnoticed than to > get a kernel panic and notice the bug? Please tell me I'm misunder- > standing something here. # Halt the system (panic) on discovering an unexpected kernel # inconsistency, in an attempt to prevent data corruption. Disabled # by default on production releases because of increased CPU load and that # these states "should never happen". Good on -CURRENT. # # Bugs: Does not stop on other kinds of failures (hardware, etc) # # options FAILSTOP Robert N Watson rob...@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: 03 01 DD 8E 15 67 48 73 25 6D 10 FC EC 68 C1 1C Carnegie Mellon Universityhttp://www.cmu.edu/ TIS Labs at Network Associates, Inc. http://www.tis.com/ Safeport Network Services http://www.safeport.com/ To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: aha0 Invalid CCB or SG list
Hi Warner! Sorry to intrude, but I just want to check that I didn't miss any messages in this thread. Have you found anything that might be causing this problem? I think it's related to the 100% CPU utilization while writing full speed to both the ahc2940uw on pci and the 1542CP on isa. I realize this is not the easiest thing to debug; I had to sit and watch the screen for 90 minutes before it happened... Drop me a mail if you find anything. Thanks! /Palle Warner Losh wrote: > > In message <36d4b092.8b076...@partitur.se> Palle Girgensohn writes: > : I've seen three crashes in the last couple of weeks, with a server > : box that's been running stable as a rock for two years, at least. It > : has an adaptec 2940UW with six disks, and an adaptec 1542CP that's > : connected to a seagate travan tape driver. > > OK. This card is known to be good. At least I've not had any > problems with it. > > : It's running STABLE-3.1 from Feb 19 1999, and since the last > : upgrade, I've seen three crashes, all related to dumping to > : tape. Since I got no info on what happened, I decided to sit down > : with the machine, run a backup sequence to tape, and wait for it to > : possibly crash. After 90 minutes, I was about to give up when > : suddenly, poof: > : panic: aha0 Invalid CCB or SG list. > : > : So, it's probably the 1540 driver (or hardware)? > > Ah. OK. I'm not doing tape stuff on my machine. How fast is that > seagate tr-4 that you are doing? > > : Can anybody shed some light on what to do? Is it software? That's my > : guess, since the machine never ONCE has crashed until the upgrade to > : 3.x. I had one crash when running current form beginning of January > : (soon after moving to 3.x), and now theese three in a week. The 1540 > : has been in the machine for about six months. > > Chances are really good that this is software. The invalid ccb or sg > list is due to either a race condition or something taht corrupts > these things. > > : If there's anything I can do to help debug I'll do it, but device > : drivers are a little above my level of expertise. > > If you can wait a day or three, I might be able to find something that > will help. However, I don't have a tape drive right now to test it > with. I'll see what I can beg, borrow or steal. > > Warner To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
problem with pccard.c cvsup'ed 3-10-99 15:00:54
After running cvsup today, and running my weekly make world (with no problems) re-compiling the kernel, I recieved this error. (after the original make all failed, I re-ran this to regenerate the error) porta# make all loading kernel pccard.o: In function `unregister_device_interrupt': pccard.o(.text+0x31c): undefined reference to `unregister_pcic_intr' pccard.o: In function `pccard_alloc_intr': pccard.o(.text+0x691): undefined reference to `register_pcic_intr' *** Error code 1 porta# current $Id in pccard.c is: *$Id: pccard.c,v 1.73 1999/03/10 15:00:54 roger Exp $ Running FreeBSD 4.0-CURRENT on a CTX 700E laptop (32 M ram) Until today, I've had no problems at all with the PCMCIA subsystem. (relevant line from the last successfull dmesg) pcic0: rev 0x01 int a irq 255... pcic1: (same as above), but "int b" Any suggestions? -Thanks Ryan Dewalt rdew...@meridianksi.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
Matthew Dillon wrote: >there are simply not enough sanity checks being made in the kernel. There is a trade off between the amount of sanity checking and performance. We need to make sure that any sanity checking we add doesn't make the system unusably slow or adversely impact interrupt response. It's up the the relevant developers to make sure that a `reasonable' level of sanity checking is done. And later >It goes without saying that users catch almost as many bugs as developers, Possibly more - there are more of them and they are likely to be stressing the system in unexpected (to the developer) ways. >Therefore, my preference is to turn invariants on on all my production >kernels as well as my development kernels. This means that invariants need to add relatively little overhead. Peter To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
: :>Therefore, my preference is to turn invariants on on all my production :>kernels as well as my development kernels. : :This means that invariants need to add relatively little overhead. : :Peter which they do. -Matt Matthew Dillon To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
On Wed, 10 Mar 1999, Matthew Dillon wrote: > : > :>Therefore, my preference is to turn invariants on on all my production > :>kernels as well as my development kernels. > : > :This means that invariants need to add relatively little overhead. > : > :Peter > > which they do. You know, guys, for programmers, wanting immediate panics on stuff like this is great, but there isn't one user in a thousand that wants this. If you make this kinda stuff default on a version *other than* current (current being by definition, for programmers/developers only) then you're going to hear bloody murder, and you guys will be doing vast damage to FreeBSD's reputation. Users don't want panics, and they don't care why, they just want things to work. Your reasons are great, and totally irrelevant, unless I misunderstood you and you meant to restrict it to current only. +--- Chuck Robey | Interests include any kind of voice or data chu...@glue.umd.edu | communications topic, C programming, and Unix. 213 Lakeside Drive Apt T-1 | Greenbelt, MD 20770 | I run picnic (FreeBSD-current) (301) 220-2114 | and jaunt (Solaris7). +--- To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: problem with pccard.c cvsup'ed 3-10-99 15:00:54
> "Ryan" == Ryan Dewalt writes: Ryan> re-compiling the kernel, I recieved this error. (after the Ryan> original make all failed, I re-ran this to regenerate the error) Ryan> porta# make all Ryan> loading kernel Ryan> pccard.o: In function `unregister_device_interrupt': Ryan> pccard.o(.text+0x31c): undefined reference to `unregister_pcic_intr' Ryan> pccard.o: In function `pccard_alloc_intr': Ryan> pccard.o(.text+0x691): undefined reference to `register_pcic_intr' Ryan> *** Error code 1 Ryan> porta# unregister_pcic_intr() and register_pcic_intr() are described in @sys/pccard/pcic.c but they are described as 'static' functions when APIC_IO is not defined ;-( I think it is better to delete 'static' at line 189 and line 194 in @sys/pccard/pcic.c than to chnage unregister_pcic_intr()/register_pcic_intr() to unregister_intr()/register_intr() in @sys/pccard/pccard.c. I fixed @sys/pccard/pcic.c and recompiled. and now I'm using new kernel on a VAIO 818. Thanks, --- YAMAMOTO ShigeruInternet Initiative Japan Inc. Network Engineering Div. To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: new loader.rc stuff
Robert Watson wrote: > > So this is actually just a general response to the whole thing--one of the > things I actually dislike about rc.conf is its flexibility: the user can > put anything script-wise they like into it. My temptation would be to > reduce the flexibility: to have a simple name:value configuration file > (with appropriate extensions for lists, quoted strings, etc) that is > guaranteed to be readable by any third-party (or even first-party :) > automated configuration programs. Depending on your mood, the name field > could even be MIB-like (boot.runaway: yes). > > It just seems like sometimes scripts give too much flexibility :-); rather > than providing useful increased functionality, they improve the chances > that the user will screw themselves by taking advantage of it in ways that > confuse automated utilities such as configuration checkers, managers, etc. Well, the idea behind loader.conf is *reducing* flexibility, in a way... :-) There are features in it that make it that still gives a lot of flexibility, to be able to deal with unexpected situations. But loader.conf syntax is ="", with # treated like bourne shell do. The loader.rc file contains commands in a very flexible language, making it virtually impossible for automated tools to modify it. So, loader.conf. -- Daniel C. Sobral(8-DCS) d...@newsguy.com d...@freebsd.org "FreeBSD is Yoda, Linux is Luke Skywalker." To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: problem with pccard.c cvsup'ed 3-10-99 15:00:54
Well, I went and removed "static" from both lines in pcic.c as noted below, did a make clean, make depend all, and recieved the same error. Unfortunately, I'm running out of ideas. I've tried commenting out the whole sections, replacing the register_pcic.init with "return(10);" (what my pcmcia was using for IRQ before) it compiles clean, however, my NIC does not work.. (which I assumed) Running out of ideas, coffee, and sleep... I'd rather not have to downgrade my source tree if necessary... -Ryan On Thu, 11 Mar 1999, [ISO-2022-JP] $B;3K\(B[ISO-2022-JP] $BLP(B wrote: > > > "Ryan" == Ryan Dewalt writes: > Ryan> re-compiling the kernel, I recieved this error. (after the > Ryan> original make all failed, I re-ran this to regenerate the error) > Ryan> porta# make all > Ryan> loading kernel > Ryan> pccard.o: In function `unregister_device_interrupt': > Ryan> pccard.o(.text+0x31c): undefined reference to `unregister_pcic_intr' > Ryan> pccard.o: In function `pccard_alloc_intr': > Ryan> pccard.o(.text+0x691): undefined reference to `register_pcic_intr' > Ryan> *** Error code 1 > Ryan> porta# > > unregister_pcic_intr() and register_pcic_intr() are described in > @sys/pccard/pcic.c > but they are described as 'static' functions when APIC_IO is not > defined ;-( > > I think it is better to delete 'static' at line 189 and line 194 in > @sys/pccard/pcic.c than to chnage > unregister_pcic_intr()/register_pcic_intr() to > unregister_intr()/register_intr() in @sys/pccard/pccard.c. > > I fixed @sys/pccard/pcic.c and recompiled. > and now I'm using new kernel on a VAIO 818. > > Thanks, > --- > YAMAMOTO Shigeru Internet Initiative Japan Inc. >Network Engineering Div. > > > To Unsubscribe: send mail to majord...@freebsd.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
:> : :> :This means that invariants need to add relatively little overhead. :> : :> :Peter :> :> which they do. : :You know, guys, for programmers, wanting immediate panics on stuff like :this is great, but there isn't one user in a thousand that wants this. :If you make this kinda stuff default on a version *other than* current :(current being by definition, for programmers/developers only) then :you're going to hear bloody murder, and you guys will be doing vast :damage to FreeBSD's reputation. : :Users don't want panics, and they don't care why, they just want things No no no... you are missing the whole point. *IF* we put these kinds of checks in by default, the result is a few more panics in the near term, but *NO* panics in the medium and long term. In otherwords, by putting the checks in now, the kernel gets debugged much more quickly --- to the point where a year down the line we no longer get kernel panics at all. If you are worried about FreeBSD's reputation, just think where we would be now if we had done this 3 years ago! When you push something under the rug, all you do is draw out the complaints into multiple years. This can't be ( and hasn't been ) good for our reputation. -Matt To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
Re: panic: zone: entry not free
> :> : > :> :This means that invariants need to add relatively little overhead. > :> : > :> :Peter > :> > :> which they do. > : > :You know, guys, for programmers, wanting immediate panics on stuff like > :this is great, but there isn't one user in a thousand that wants this. > :If you make this kinda stuff default on a version *other than* current > :(current being by definition, for programmers/developers only) then > :you're going to hear bloody murder, and you guys will be doing vast > :damage to FreeBSD's reputation. > : > :Users don't want panics, and they don't care why, they just want things > > No no no... you are missing the whole point. > > *IF* we put these kinds of checks in by default, the result is a > few more panics in the near term, but *NO* panics in the medium and > long term. > > In otherwords, by putting the checks in now, the kernel gets debugged > much more quickly --- to the point where a year down the line we no > longer get kernel panics at all. > Also, try commenting out a panic line in a known bug, and watch how quickly the kernel crashes anyway, in the same situation. Most of the time, the panic is dumping out (some) debugging information before crashing all over itself. Just taking out the diagnostic message is really just making crashes more obscure. If the error were recoverable, normally the system recovers from it. If it's not, it panic's and dies. Take out the panic, and all you've got left is a 'die', which probably will lead people on a wild goose chase as to where that section of memory really got trashed. Kevin To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
