Re: freebsd-stable Digest, Vol 134, Issue 5
At 8:05 AM -0500 2005-11-04, Mike O'Dell wrote: Brett is too polite, so i'll say it for him. I don't think that Brett has ever been accused of being "too polite" by anyone ever before, so this would definitely be a first. Brett Glass was sweating problems like this when many people on this list were still in diapers. True. I wasn't in diapers at the time he was doing this kind of stuff, but I probably was still in college at that point, and we are talking fifteen to twenty years ago. Dismissive condescending responses like this one are *way* outa line. Not necessarily true. Brett does get a lot of crap sent his way that he may not deserve in that particular instance, but his overall attitude and response pattern over the past several years has earned him that kind of treatment. As a general rule, he usually gets what he deserves. He has certainly earned a great deal of disrespect from me. There is a well-worked example of this "shit/noshit" approach to config management and it's cisco ios configs. anyone who believes this works well has clearly not done enough of it. For Brett, the old approach works just fine, because it's what he has been using for the past twenty years (or so), and that's what he's used to. Problem is, we have demonstrated repeatedly that many newbies come along and delete stuff from their kernel config that they don't understand and they shoot themselves in the foot. When they do that, they come to this mailing list (and other related mailing lists), and ask all sorts of ignorant questions -- not necessarily stupid questions, but definitely ignorant. Worse, many others just call FreeBSD a bunch of crap and never give it another try. We have no alternative. We know the old approach isn't working for the newbies, and we need to do something else that works better for them and helps avoid as much foot-shooting as possible. The current "option/nooption" approach may not be the best solution to this problem, but it is a reasonably well understood solution, and is certainly better than a lot of other alternatives. Yes, the option/nooption solution may make life a little more difficult for the greybeards (or anyone else wanting a somewhat more complex kernel configuration where the built-in defaults are not necessarily desirable), but there are relatively few greybeards around, at least compared to the newbies. Moreover, the greybeards are more likely to be able to come up with alternative solutions that may be better than either the old approach or the new one, and may be in a position to help implement their improved solution. So, while I don't qualify as a greybeard myself, I don't have that much sympathy for anyone who just wishes that the clock would roll back and everything would go back to the way it was. If the new solution isn't working for you and you've been in this business long enough to be a greybeard, then you should have enough experience to help us work out a better solution. From where I sit, Brett is just bitching and not providing any useful contribution. let me be very clear here: we have a worked example of the approach and it sucks flaming red bugs It has it's problems, yes. But large sites like AOL that use automated configuration management tools for their thousands and tens of thousands of cisco routers is proof that it can be made to work reasonably well on even the largest scales. Been there, saw that, and even you aren't going to be able to convince me otherwise. No, it's not perfect. Sometimes you get nineteen hour downtimes that causes all e-mail across the entire Internet to break down. But it does work most of the time, and the reliability/uptime factor has been pushed out to several nines. No, the Department of Snarky Replies doesn't even want to discuss the matter given their authoritative experience across all time and space. Brett is not a good person to throw stones here. His "works fine here" is just as useless as Kris's response. As such, I would recommend that maybe you might want to avoid throwing stones on Brett's behalf. When everything is said and done, past technical accomplishments mean little if you can't play nice with others. Brett has earned a great deal of disrespect from me, because of his previous anti-social behaviour, and remarkable lack of useful contributions in recent history. On those same criteria, I've definitely got a lot more respect for Kris than many other people who are currently associated with the project. Where you want to place yourself on that spectrum is your choice, but the best thing would be if everyone would stop attacking everyone else, and get down to the real issue of trying to find a better
Re: Disk 100% busy
At 2:06 PM -0600 2005-11-03, Dan Nelson wrote: The biggest reason for going RAID-5 is that you only get 50% useable capacity out of RAID 10, and at least 75% out of a RAID 5 (with a 3+1 layout. With an 8+1 layout you get 88%). If you don't need fast writes, or your controller has sufficient cache to mask the write penalty, RAID 5 sure holds a lot more data on the same disks. However, with RAID-5 you're in seriously bad shape when one of the disks dies. You really need to add a hot spare to that list. And intelligent controllers can be used with other RAID types, too. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disk 100% busy
At 2:35 PM -0500 2005-11-03, Francisco Reyes wrote: If you're using maildir, that is one of the situations which works pretty well with RAID-5, although RAID-10 is also (always? :-) a good choice. How about for database? In particular postgresql. How bad would RAID 5 be for it? RAID-5 is usually about the worst case for most database applications, since you have to read and write entire blocks across all disks just to change a single bit. You have to wait for all disks to read or write their respective data, before you can return. Some RAID arrays will have intelligent controllers that allow you to cache writes and return before the data is actually written, but then intelligent controllers can be used with all RAID types. The only thing that would be worse would be RAID-3, where you'd have a hot parity disk, whereas RAID-5 spreads the parity bits around the array of disks. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disk 100% busy
At 1:34 PM -0500 2005-11-03, Francisco wrote: On Mon, 17 Oct 2005, Brad Knowles wrote: Note that RAID-1 is the second worst-case for mail server performance -- it accelerates reads (if you have mirror load-balancing), but all writes are required to be held until complete on both disks. The only worse case would be RAID-5, where you have to write (or re-write) an entire RAID block at once, plus the parity information. Coming late into the thread... What is a good raid level for a maildir IMAP server? RAID 10 (or 0+1 as others call it). Yes, RAID 1+0 is generally considered to be the best. But keep in mind that you always want to stripe the mirrors and not mirror the stripes. If you do the former, then if one of the disks die then the mirror is broken but the stripe is still okay. If you do the latter, then if a disk dies then the stripe is broken, and then the mirror is also broken. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GENERIC and DEFAULTS
At 12:01 PM +0200 2005-10-31, Danny Braniss wrote: > you probably know many scenarios that i - thankfully - am no > aware of, but by creating the magic DEFAULTS file the problem > still exits! What will prevent from Joe Shootmyfoot to comment out > the lines in DEFAULTS? chflags schg DEFAULTS yes if it's you, but not if im Joe Shootmyfoot! At least it will slow them down. They road to shooting themselves in the foot will dead-end, and they'll be forced to turn left or right before they can continue towards that goal. Put a big enough roadblock there, and most of those idiots will probably manage to avoid shooting themselves in the foot. Not all, of course. But most. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: GENERIC and DEFAULTS
At 11:18 AM +0200 2005-10-31, Danny Braniss wrote: you probably know many scenarios that i - thankfully - am no aware of, but by creating the magic DEFAULTS file the problem still exits! What will prevent from Joe Shootmyfoot to comment out the lines in DEFAULTS? chflags schg DEFAULTS -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network performance 6.0 with netperf
At 9:57 AM -0500 2005-10-20, Karl Denninger wrote: Other than that, I've been pretty happy with their stuff. Sure beats a lot of other "PC" vendors out there in terms of reliability, heat management, BIOS updates, etc. Have you tried Rackable or IronSystems? I've heard that they've been pretty successful at building servers to compete pretty well on price with Dell, while also providing much better customer service, including custom-building servers to your precise requirements. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Network performance 6.0 with netperf
At 10:49 PM +1000 2005-10-20, Michael VInce wrote: The 4 ethernet ports on the Dell server are all built-in so I am assuming they are on the best bus available. In my experience, the terms "Dell" and "best available" very rarely go together. Dell has made a name for themselves by shipping the absolutely cheapest possible hardware they can, with the thinnest possible profit margins, and trying to make up the difference in volume. Issues like support, ease of management, freedom from overheating, etc... get secondary or tertiary consideration, if they get any consideration at all. But maybe that's just me. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: Disk 100% busy
At 1:53 PM -0400 2005-10-16, Will Saxon wrote: I completely forgot that I had the partition mounted 'sync'. That might explain things a bit, huh. Perhaps. I am using qmail - the author indicates that softupdates is not recommended. However, I am going to give it a shot and see if I start losing mail as he suggests may happen. Soft Updates is only guaranteed to keep your filesystem in a consistent state, and does not guarantee that you won't lose a few messages. There are MTAs designed for use on filesystems that use Soft Updates, but I don't think qmail is one of them. Moreover, qmail was not designed for scalability when handling lots of back-end processes such as anti-spam/anti-virus scanning, and I believe that it tends to perform badly in those roles. You can configure either postfix or sendmail to be considerably more scalable in those kinds of situations than qmail. Indeed, with a little careful configuration, with sendmail you can avoid virtually all synchronous meta-data updates as far as the daemon itself is concerned, and when combined with milter-savvy scanning programs, you can pretty much completely avoid them all the way up to the point where you have to make final delivery to a user mailbox. That makes for a much more scalable mail system than qmail is capable of. But then, I'm probably a bit biased since I gave what I believe were the first public talks on the subject of building scalable mail systems involving such features (see <http://www.shub-internet.org/brad/papers/dihses/> and <http://www.shub-internet.org/brad/papers/sistpni/>). -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Disk 100% busy
At 9:16 AM -0400 2005-10-16, Will Saxon wrote: In this case, my mail gateway is is a dual 3.06GHz Xeon with 1GB of ram and 2 36GB 15krpm drives in a raid-1 on a smart array 6i (cciss) controller. I am running FreeBSD 5.4-RELEASE-p1. Systat -vmstat reports the disk mirror is 100% busy at all times on this machine, with an average of around 300 tps at 15KB/t. Note that RAID-1 is the second worst-case for mail server performance -- it accelerates reads (if you have mirror load-balancing), but all writes are required to be held until complete on both disks. The only worse case would be RAID-5, where you have to write (or re-write) an entire RAID block at once, plus the parity information. For mail servers, you really want to watch your synchronous meta-data updates. FreeBSD is a good choice here, if you've got Soft Updates enabled (I think that FreeBSD 5.x does that by default). But, you also want to watch your directory sizes. If the directory size gets too large, then it takes too long to lock the directory against any other updates, scan through the entire directory to make sure there aren't any collisions, create/delete the file, then unlock the directory -- a process which has to be done every time a file is created or deleted. This is why most modern mail servers use a "hashed queue" scheme, so that you can greatly increase the chances of multiple processes working simultaneously without stepping all over each others toes. However, with regards to directory size issues, keep in mind that even if the directory does not currently have 100,000 files in it, if it ever had 100k files in it in the past, it's still got all those empty directory slots laying around and that still slows things down a lot. If you suspect that this may have happened in the past, you need to stop the offending program, move the old directories aside, create new directories with the same ownership/permissions, then restart the program. And don't forget to make sure to clean out the old directories you had moved aside, either by creating some manual queue runners, or whatever. In your case, while the MTA may be configured in a way to avoid most of these issues, the anti-virus scanning solution may not. So, you may need to find a way to go in and deal with this. If you want to find out how all these issues affect the MTA, you need to read the book "sendmail Performance Tuning" by Nick Christenson (see <http://www.jetcafe.org/npc/book/sendmail/>). Once you read this book, you will hopefully have a better idea of how these same issues may affect your anti-virus scanning solution, and what you may need to do about it. I also recommend the slides from Nick's "Performance Tuning Sendmail Systems" paper at <http://www.jetcafe.org/npc/doc/performance_tuning.pdf>, as well as my own slides on the same general subject at <http://www.shub-internet.org/brad/papers/sendmail-tuning/>. This seems wrong to me, as these numbers are maintained even when the system doesn't otherwise appear busy. We don't seem to be swamped by log writes. How can you be sure? How are you logging information today? Is that being logged to a separate filesystem on a separate disk system? How can I tell what's generating these disk writes? At the moment the 100% disk utilization is the only thing I can see that would cause the scanning delay. The machine overall is sluggish with file operations. You have a certain amount of information available to you from tools like vmstat and iostat, as well as systat. However, in order to understand how to use them to see where your problems really lie, you need information such as provided in Nick's book. You should also read other books on overall system performance tuning. The O'Reilly book on this subject (see <http://www.oreilly.com/catalog/spt2/>) is a good start, even though it is a few years old. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new FreeBSD-webpage
At 11:02 AM +1000 2005-10-08, jonathan michaels wrote: i've offten made (tried to) point that if you make a page accessible to a disabled peron that all teh (so called) not so disabled people will find the pages far easier to use and a sight more easier on teh eye. I've felt this way for a long time. I am not disabled myself, but I've known some people who are, and I've seen some of the things that they've had to deal with. Generally speaking, if you can make something easy enough for them to use, then it's easier for everyone else to use, too. But then, I guess I'm the choir that you're preaching to. The problem is that we need to convince the rest of the world. i've always laboured in teh view that the internet is supposed to be an inclusive medium .. not teh now rapidly becoming devisively exclusive LogIn/JoinHere/SignUpNow/GetYourAutherisedId etc etc etc kind of space exclusionary sphere/space/world/system and so on on on. Yup. And stupid crap like JavaScript and Flash tend to be more exclusive. And everyone and their friggin' brother seems to want to make their website dependant on these kinds of technologies. I think maybe we need a few more ADA lawsuits filed against companies (and other organizations) for the crimes they are committing with their websites. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: new FreeBSD-webpage
At 7:04 PM +0200 2005-10-07, Oliver Fromme wrote: > Scrolling is always preferable to clicking since it requires less > effort and has a better response time. I'm afraid I have to disagree. Moving the mouse pointer to the scroll bar, clicking it and dragging it is definitely more effort than simply clicking a link. It depends on how much bandwidth you have, and how bad the latency is between you and the web server response. If you have infinite bandwidth and the latency is virtually zero, then clicking a link is faster. If you have lower bandwidth and/or higher latency, then scrolling is likely to be better. Who are you going to try to optimize the web pages for? -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Advice sought on upgrading from 4.11-R to 5.4...
At 4:15 PM -0700 2005-09-28, Doug Barton wrote: Ah, I misread the original message. Usually people are complaining about the CVS Ids in the comments, as opposed to the comments themselves. The CVS Ids are part of the issue, yes. But not the whole problem. I disagree that ignoring comments in the files is a good idea. There is no way for mergemaster to know for sure if the comment is material or not, that's the admin's job. Which is why I was hoping to be able to have a command-line option to control this function. Upgrading across a major version is a difficult task, no matter how its approached. IIRC, the original example was upgrading from 4.x to 5.x, which, like most major version upgrades, should be done by backing up your data and doing a fresh install anyway. This is particularly important over the 4 -> 5 change, since by upgrading from source you're missing the UFS2 update. In my case, I don't want the UFS2 update. I have not been able to get FreeBSD-5.x CD-ROMs that are bootable on my machine, so I am forced to do a software upgrade. Moreover, I want to make sure that the filesystem remains readable to FreeBSD-4.x bootable CD-ROMs -- just in case there is a disaster. I saw all the comments that were pointed out by mergemaster, and many of them seemed to be mere changes in whitespace (could we at least automatically apply those?), some were correcting a minor typo, and there were a few that were a bit more extensive -- spread over a couple of lines or more. But every single one of them was relatively minor and I would have been very happy to have all of them automatically applied. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Advice sought on upgrading from 4.11-R to 5.4...
At 3:49 PM -0700 2005-09-28, Doug Barton wrote: What would be nice is if people actually read the man page for mergemaster, which has had this example in it for a long time now. I checked the man page. There is no direct "ignore" option, although there is a "strict" option. If you set up an /etc/mergemaster.rc, you can set up "DIFF_OPTIONS=" value, and there is an example of how to do that so that it ignores FreeBSD CVS Id tags. However, I was talking about ignoring all differences that occur only in comments (not just FreeBSD CVS Id tags), and it's not obvious as to how to modify the "DIFF_OPTIONS=" setting to suit. Moreover, I was hoping for a command-line option to control this setting, and that it might be set by default -- no /etc/mergemaster.rc required. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Advice sought on upgrading from 4.11-R to 5.4...
At 9:42 PM +0200 2005-09-21, Brad Knowles wrote: I've seen the migration guide at <http://www.freebsd.org/releases/5.4R/migration-guide.html>, and the thread at <http://lists.freebsd.org/pipermail/freebsd-stable/2005-September/018151.html>, but I was wondering about the specific sequence of the upgrade process. Okay, well I've completed this part of the processing, going from 4.11-R to releng_5_4, and everything seems to be okay. I now need to make a custom kernel and to do a portupgrade, but unless something goes horribly wrong it would appear that this process was relatively painless. However, it would be nice if mergemaster could be made to automatically accept changes that occur only in the comments of the files it is trying to merge. That way, many fewer "fluff" changes would be presented during the merge process, and people would be left with needing to confirm changes regarding only actual functional code. Anyway, thanks again everyone! -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Advice sought on upgrading from 4.11-R to 5.4...
At 4:56 PM -0700 2005-09-21, Kevin Oberman wrote: Check in the CVS repository: http://www.freebsd.org/cgi/cvsweb.cgi/src/UPDATING?annotate=1.342.2.24&only_with_tag=RELENG_5_4 Thanks for the pointer! One down side of an upgrade in-place is that you don't get the larger root partition that is now default and you don't get UFS2 file systems on your partitions. I almost never take the default installation options whenever I'm building a system. They almost always result in the root filesystem being laughably small, or whatever. In my case, I've got a 256MB root filesystem with 150MB free, so I think I'm okay there. I did get burned with /usr being too small, even at 2GB. With all the ports and stuff I've installed, I had to move /usr/local to a separate filesystem (which I already had), and put a symlink in place. As for UFS2, since I can't get this machine to boot off CD-ROM with the 5.x images (at least, not the ones I've tried in the past), I would like to keep the system in UFS1 anyway, just in case I need to reboot off the 4.x CD-ROMs and try to do some recovery things. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Advice sought on upgrading from 4.11-R to 5.4...
At 11:34 PM +0200 2005-09-21, Erik Trulsson wrote: And you should of course also read /usr/src/UPDATING as usual. That's the current version of the file from the 5.x tree, right? Is there any obvious way to see what this is without going ahead and downloading all the source anyway? Maybe there's something I'm missing, but this seems to be one of the really important files that is not easily available via the web interface on freebsd.org -- they've got the RELEASE_NOTES and a number of others, but not this one. Of course, the officially recommended upgrade path is to backup all data (a very good idea in any case), reformat the disk, install the new system from scratch, and restore datafiles from the backup - but upgrading via source is certainly possible as well. I had originally tried installing 5.x on this machine, but I could never get it to boot from the 5.x media. I did get it to boot from the 4.11-R media (both sets of media written by the same computer with the same CD-Writer and software), so that is what I installed. I'd like to be able to take the backup/wipe/re-install path, but I don't think that's going to be possible for me. -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Advice sought on upgrading from 4.11-R to 5.4...
Folks, I've seen the migration guide at <http://www.freebsd.org/releases/5.4R/migration-guide.html>, and the thread at <http://lists.freebsd.org/pipermail/freebsd-stable/2005-September/018151.html>, but I was wondering about the specific sequence of the upgrade process. In particular, I'm wondering if I should go from RELENG_4_11_0_RELEASE direct to RELENG_5_4, or if I should instead go first to RELENG_5_0_0_RELEASE then to RELENG_5_4? I think the individual steps to follow and commands to execute during the upgrade are clear enough. But it's not obvious to me as to which precise CVSup targets should be used to pull down the source that would be compiled, etc -- Brad Knowles, <[EMAIL PROTECTED]> "Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety." -- Benjamin Franklin (1706-1790), reply of the Pennsylvania Assembly to the Governor, November 11, 1755 SAGE member since 1995. See <http://www.sage.org/> for more info. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Problems with corrupted vinum devices...
At 5:44 PM +0100 2001/1/5, [EMAIL PROTECTED] wrote: > diff -ru /tmp/vinum/vinumvar.h ./vinumvar.h > --- /tmp/vinum/vinumvar.hMon May 22 18:21:37 2000 > +++ ./vinumvar.h Thu Jan 4 19:12:01 2001 > @@ -158,15 +158,15 @@ >* probably too small. >*/ > > -INITIAL_DRIVES = 4, > +INITIAL_DRIVES = 16, > INITIAL_VOLUMES = 4, > INITIAL_PLEXES = 8, > INITIAL_SUBDISKS = 16, > -INITIAL_SUBDISKS_IN_PLEX = 4, /* number of >subdisks to allocate to a plex */ > +INITIAL_SUBDISKS_IN_PLEX = 16, /* number of >subdisks to allocate to a plex */ > INITIAL_SUBDISKS_IN_DRIVE = 4, /* number of >subdisks to allocate to a drive */ > INITIAL_DRIVE_FREELIST = 16,/* number of entries >in drive freelist */ > PLEX_REGION_TABLE_SIZE = 8, /* number of >entries in plex region tables */ > -INITIAL_LOCKS = 256,/* number of locks to >allocate to a plex */ > +INITIAL_LOCKS = 4096, /* number of locks to >allocate to a plex */ > MAX_REVIVE_BLOCKSIZE = MAXPHYS, /* maximum revive >block size */ > DEFAULT_REVIVE_BLOCKSIZE = 65536, /* default >revive block size */ > VINUMHOSTNAMELEN = 32, /* host name field in >label */ Let's look again at the full comment block before this segment of code: | /* | * the number of object entries to cater for initially, and also the | * value by which they are incremented. It doesn't take long | * to extend them, so theoretically we could start with 1 of each, but | * it's untidy to allocate such small areas. These values are | * probably too small. | */ Theoretically, changing the initial values should have no impact whatsoever on the ability (or lack thereof) to create devices, so long as you're not exceeding the specified maximums. Vinum should automatically extend the necessary data structures beyond these initial defaults, if the need should arise. If vinum isn't doing this, then the code to do those extensions is faulty and it should be fixed instead. The more I think about this, the less I think that this has anything at all to do with either the problems you experienced, or the problems we're having. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Problems with corrupted vinum devices...
At 5:44 PM +0100 2001/1/5, [EMAIL PROTECTED] wrote: > I suggest increasing INITIAL_DRIVES in vinumvar.h to avoid array > resize and the associated race conditions. When I tried to configure > vinum to use 14 disks yesterday, the machine immediately crashed with > a trap 12 in response to 'vinum create'. I bumped INITIAL_DRIVES to > 16 to avoid the drive array resize that caused the problem. I bumped > INITIAL_SUBDISKS_IN_PLEX too, just to be safe. IIRC, there is a hard limit of 32 physical disks that you can define, but I've only defined eight. So, I'm below both the absolute limit I am aware of, and the limit you apparently ran into. We haven't had any problems with vinum create, so I don't think that increasing INITIAL_DRIVES or INITIAL_SUBDISKS_IN_PLEX is going to help. > To avoid similar races with RAID-5 under high load or with > softupdates, I had to bump INITIAL_LOCKS to avoid a fatal range lock > array resize. We're not using RAID-5, but we are using softupdates. I'll have to look into the code and see if this patch makes sense for us, and I may end up doing a "make update" to bring us up to the latest OS sources, etc... before I try much of anything else. Thanks! -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Problems with corrupted vinum devices...
g configuration from /dev/da3s1e Jan 5 15:53:34 baloo /BALOO: vinum_scandisk: /dev/da3s1e is down Jan 5 15:53:34 baloo /BALOO: vinum: Can't read device /dev/da3s1e, error 5 Jan 5 15:53:34 baloo /BALOO: vinum: updating configuration from /dev/da3s2e Jan 5 15:53:35 baloo /BALOO: vinum_scandisk: /dev/da3s2e is down Jan 5 15:53:35 baloo /BALOO: vinum: Can't read device /dev/da3s2e, error 5 Jan 5 15:53:35 baloo /BALOO: vinum: updating configuration from /dev/da4s1e Jan 5 15:53:35 baloo /BALOO: vinum_scandisk: /dev/da4s1e is down Jan 5 15:53:35 baloo /BALOO: vinum: Can't read device /dev/da4s1e, error 5 Jan 5 15:53:35 baloo /BALOO: vinum: updating configuration from /dev/da4s2e Jan 5 15:53:35 baloo /BALOO: vinum_scandisk: /dev/da4s2e is down Jan 5 15:53:35 baloo /BALOO: vinum: Can't read device /dev/da4s2e, error 5 Jan 5 15:53:35 baloo /BALOO: vinum: updating configuration from /dev/da5s1e Jan 5 15:53:35 baloo /BALOO: vinum_scandisk: /dev/da5s1e is down Jan 5 15:53:35 baloo /BALOO: vinum: Can't read device /dev/da5s1e, error 5 Jan 5 15:53:35 baloo /BALOO: vinum: updating configuration from /dev/da2s1e Jan 5 15:53:35 baloo /BALOO: vinum_scandisk: /dev/da2s1e is down Jan 5 15:53:35 baloo /BALOO: vinum: Can't read device /dev/da2s1e, error 5 Jan 5 15:53:35 baloo /BALOO: vinum: couldn't read configuration Unfortunately, I'm at a loss as to understand where to go next in terms of debugging this matter. Any and all help you can provide is appreciated. Thanks! -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: rawio 1.1 on FreeBSD 4.2-BETA?
At 11:08 AM +1030 2000/11/24, Greg Lehey wrote: > At this point, of course, you have your patch-ac again. Remove it > again, do a make clean and start again. I checked that before I responded. There is no patch-ac file in the directory. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: rawio 1.1 on FreeBSD 4.2-BETA?
At 3:14 PM +1030 2000/11/19, Greg Lehey wrote: > There is a PR. I'm not sure under what circumstances it fails. This > is, in fact, a bug in the port, not in rawio: it's in files/patch-ac. > It should work fine if you delete this patch and then make clean and > rebuild. I tried deleting patch-ac, then did a "make distclean", followed by a "make". Unfortunately, it still dies: make >> rawio-1.1.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from ftp://ftp.lemis.com/pub/. Receiving rawio-1.1.tar.gz (191472 bytes): 100% 191472 bytes transferred in 59.4 seconds (3.15 kBps) ===> Extracting for rawio-1.1 >> Checksum OK for rawio-1.1.tar.gz. ===> Patching for rawio-1.1 ===> Applying FreeBSD patches for rawio-1.1 ===> Configuring for rawio-1.1 ===> Building for rawio-1.1 cc -O -pipe -g mkrandom.c -o mkrandom mkrandom.c:57: random.h: No such file or directory *** Error code 1 Stop in /usr/ports/benchmarks/rawio/work. *** Error code 1 Stop in /usr/ports/benchmarks/rawio. *** Error code 1 Stop in /usr/ports/benchmarks/rawio. *** Error code 1 Stop in /usr/ports/benchmarks/rawio. Do you have any other suggestions as to what I could do? Thanks! -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: rawio 1.1 on FreeBSD 4.2-BETA?
At 3:14 PM +1030 2000/11/19, Greg Lehey wrote: > There is a PR. I'm not sure under what circumstances it fails. This > is, in fact, a bug in the port, not in rawio: it's in files/patch-ac. > It should work fine if you delete this patch and then make clean and > rebuild. Ahh, okay. I'll give that a shot. Thanks! Just curious -- IIRC, rawio is specific to FreeBSD, so why does there need to be a FreeBSD port for it? -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Sendmail 8.11/TLS
At 4:05 PM -0700 2000/10/12, Gregory Neil Shapiro wrote: > _FFR_'s are not documented. FFR stands for for-future-release. Understood. > Yes, BSD systems can use STARTTLS without sfio. Cool. I was not aware that sendmail was capable of using multiple different stdio libraries and still able to support STARTTLS on top of that. > 8.12 will not require sfio, nor a BSD stdio library. Excellent! This is wonderful news! Now, I don't suppose you can give us any hints of a projected shipping date, can you? ;-) -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Adaptec/DPT SmartRAID V under FreeBSD 4.x-STABLE [was: Re: Mylex adapters with 2.x firmware and "couldn't map register window"]
At 2:00 PM +0200 2000/9/22, Brad Knowles wrote: > So, I've just rebooted the machine, moved the DPT-enabled kernel > off to the side, re-named the old kernel back into place, and now > I'm going to pull the side off the machine so that I can remove > the SCSI connector for the internal drive from the DPT card and > plug it back into the on-board AIC-7890, so that I can then do a > succesful "make update", etc..., before reversing the whole > process all over again. Okay, I'm trying the "make update" in /usr/src, after having gotten the internal drive plugged back into the on-board AIC-7890 controller. However, "make update" dies: # make update -- >>> Running /usr/local/bin/cvsup -- Parsing supfile "/usr/local/cvsup/stable-supfile" Connecting to cvsup.uk.FreeBSD.org Connected to cvsup.uk.FreeBSD.org Server software version: REL_16_1 Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection src-all/cvs Shutting down connection to server Finished successfully Parsing supfile "/usr/local/cvsup/ports-supfile" Connecting to cvsup.uk.FreeBSD.org Connected to cvsup.uk.FreeBSD.org Server software version: REL_16_1 Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running TreeList failed: Error in "/usr/sup/ports-astro/checkouts.cvs:.": 1: Invalid escape sequence. Delete it and try again. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. I'm hoping that this is just the ports stuff, and that I don't really have to worry about it. I'm going to give it a try, just in case. -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Adaptec/DPT SmartRAID V under FreeBSD 4.x-STABLE [was:Re: Mylex adapters with 2.x firmware and "couldn't map registerwindow"]
At 1:38 PM -0700 2000/9/21, Mike Smith wrote: > Ok. I've just made all that (hopefully) unnecessary by MFC'ing the code > from -current, which has a fix for a dangerous race in the driver kit. I think I just found that race condition. I was trying a "make update" in /usr/src, when the system panic'ed and crashed. Unfortunately, it died badly enough that I don't think it was able to save the dump. So, I've just rebooted the machine, moved the DPT-enabled kernel off to the side, re-named the old kernel back into place, and now I'm going to pull the side off the machine so that I can remove the SCSI connector for the internal drive from the DPT card and plug it back into the on-board AIC-7890, so that I can then do a succesful "make update", etc..., before reversing the whole process all over again. Sigh Oh, well -- I guess that's the price I pay for playing with beta drivers. ;-) -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Adaptec/DPT SmartRAID V under FreeBSD 4.x-STABLE [was: Re:Mylex adapters with 2.x firmware and "couldn't map register window"]
At 12:34 AM -0700 2000/8/4, Mike Smith wrote: > The fix for this has been committed to -stable, and there's a kit for > 4.1-RELEASE users wanting to install on these adapters at > http://people.freebsd.org/~msmith/RAID/mylex/mlx2_patchkit.tar.gz Okay, with your notes, I have gotten a 4.1-STABLE kernel to build and install with this driver, and I've plugged in a PM2654U2 controller into the machine, and connected it to the external enclosure for the drives. However, while the DPT card appears to come up okay and recognize the RAID-5 volume that was left over from the previous configuration, I can't get it to load SMOR -- it comes up and says "Cards are not configurable". Worse, whether or not I try to reconfigure the array, it gets to the Dell PowerEdge 1300 prompt "Alert! Cover was previously removed", and then the boot process hangs. I'm going to try going into the BIOS and configuring it so that it does not consider the DPT card to be bootable, and if that doesn't work I'll try hanging the internal hard drive off the DPT controller instead of the built-in AIC-7890 controller chip. However, if anyone else has any insights into this problem, I'd appreciate it. Thanks! -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Vinum (was: RAID)
At 12:29 AM -0400 2000/9/6, Mike Tancsa wrote: > I will certainly take a look at it. However, for now, I have been > using a number of bonnie processes simultaneously. The box I am > building is going to be just a pop3 server. So at any given time, a > number of popper processes running scanning through a users mailbox > to see how many messages they have seems to be well enough > approximated by a number of disk intensive processes like bonnie at once. For simulating the performance of mail-related disk subsystems, so far I have been pretty happy with what I've been doing with postmark. See my postmark benchmarking page at <http://www.shub-internet.org/brad/FreeBSD/postmark.html>. And now that the SmartRAID V/VI drivers are available for FreeBSD 4.2, I will be repeating my previous vinum/SmartRAID/rawio benchmarks (see <http://www.shub-internet.org/brad/FreeBSD/vinum.html>) to see how things have changed. On our POP3 mail systems, we're seeing average message sizes around 70KB, so I will be doing further bonnie++ 1.00b (see <http://www.coker.com.au/bonnie++/>) tests averaging about that, of course using multiple processes in parallel, and making sure that I move at least multiple GB of data per test to try and make sure that we eliminate as much buffer cache effect as we can. I'm also going to be testing Sun Solaris UFS against UFS Logging (both DiskSuite trans meta devices as well as using the "logging" keyword in the mount options) against Veritas VxVM and VxFS, and in single disk, mirrored pairs, striped pairs, mirrored+striped pairs (four disks), and four pure striped disks. > The only problem I have run into so far is creating a 3 disk RAID5 > array. Is this not possible ? While possible (three disks is the minimum number required to make a RAID-5 volume), it wastes 1/3 your disk space, it is very costly in terms of I/O, and generally is not that great of an idea. > Am I better off in the end going with 4 drives in a RAID 10 config instead ? If that is possible, in my experience you will find that it will perform much, much better, and it should be more reliable. Myself, I'd be inclined to throw in a fifth disk as a hot spare, and run the remaining four in RAID 0+1 mode (of course, if at all possible you want to stripe the mirrors and not mirror the stripes, since if you do the former and you lose a disk, then only that submirror is degraded and the stripe is fine, while if you do the latter, then the entire stripe is degraded which then causes the mirror to be degraded too). -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: affordable wireless
At 9:11 AM -0700 2000/9/5, Kevin Oberman wrote: > Even at 128 bits, WEP encryption is, at best, rather weak. The right > answer is to use strong encryption for everything. If I'm not mistaken, this is actually using Triple DES at 128 bits, so this is still decently strong. The problem is that the normal WEP key is only 40 bits long, which we know can be cracked in a matter of only a few seconds. > OpenSSH is now a standard part of FreeBSD. Use it and stop sending > clear passwords over the net. Then you don't care about the security > of the link, only the end nodes. OpenSSH is good, and I certainly use it (and other ssh products) where possible. However, it is not a panacea, it cannot be used everywhere, and if you can enable additional encryption at the link level, then you should certainly do that. -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target tomake yer kernels
At 10:39 AM -0400 2000/7/11, Vivek Khera wrote: > So the final result of the discussion seems to be: > > 1) after upgrading sources (ie, make buildworld of any sort) use "make > buildkernel" to build your kernel > > 2) any other times, you can use the traditional build process > > Correct? Right. I'm trying to get the exact set of steps (and related comments, such as "don't report errors if you fed '-j4' to make", etc...) consolidated and fed to [EMAIL PROTECTED], for use in updating the Handbook. -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: HEADS UP! Always use the 'make buildkernel' target tomake your kernels
At 1:29 PM +0200 2000/7/11, Peter van Heusden wrote: > My only (minor) concern, from a useability point of view, is that there is > no default BUILDKERNEL value - shouldn't it default to GENERIC if nothing > else is specified? That way you won't actually be able to do a > 'buildkernel' without building a kernel. Hmm. Good idea. Until then, this needs to be mentioned in the documentation. -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Cant build 3.5-stable?
At 8:42 AM -0400 2000/7/6, Adam wrote: > I am trying to build 3.5-stable on a 3.4-stable system of about two > months old. /usr/src/UPDATING is empty. Can anyone throw a clue or patch > my way? You're running into the same "fetch" problem that I reported on Wed, 5 Jul 2000 18:41:55 +0200. I still haven't heard anything, either. -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
regcomp(3) acting weird?
Folks,
I'm trying to use spegla 1.1p4 to mirror a particular site, and
up until now I've not had any trouble. However, now I want to skip a
particular subdirectory, and regcomp(3) looks to me like it's acting
really weird. I would normally take this issue up just with the
author, but it seems to me that the problem is with regcomp(3) and
not spegla, so I figured I'd ask here as well.
Here's the section of code (as it originally looked) that is
calling regcomp(3):
/* init the sp_skip struct */
struct sp_skip *
sps_init(const char *arg)
{
size_t len;
int cflags;
struct sp_skip *sps;
len = strlen(arg);
if ((sps = calloc((size_t)1, sizeof(*sps) + len + 1)) == NULL)
return NULL;
/* LINTED save us from one calloc */
sps->sps_name = (char *)(sps + 1);
(void) strcpy(sps->sps_name, arg);
cflags = 0;
cflags |= REG_EXTENDED; /* extended RE's */
cflags |= REG_NOSUB;/* only report match or no match */
sps->sps_reg_errno = regcomp(&sps->sps_reg, sps->sps_name, cflags);
if (sps->sps_reg_errno != 0) {
free(sps);
return NULL;
}
return sps;
}
Here is the configuration file I'm using:
version = 1.1
minfree = 102400
loglevel = 10
localdir = /home/ftp/mirror/interplay
dodelete = yes
remotedir = /pub
skip = ^/movies
username = anonymous
password = [EMAIL PROTECTED]
host = ftp.interplay.com
timeout = 120
retries = 300 # busy ftp server and lots of files.
# Takes lots of hours to complete
# and don't want to quit when we are
# almost finished.
retrytime = 120 # if network goes down don't consume
# all retries to fast.
logfile = /var/log/ftpd/interplay.log
lockfile = /var/run/interplay.lock
However, spegla dies while trying to parse it:
$ /usr/local/bin/spegla -f /usr/local/etc/spegla/interplay.conf
spegla: sps_init: Undefined error: 0
The section of spegla.c that is calling this routine is:
/* ARGSUSED */
static void
add_param_sps(int option, const char *arg, struct cl_sps_que **q)
{
struct sp_skip *sps;
option = 0; /* quiet gcc */
if (*q == NULL && ((*q = cl_sps_init()) == NULL))
e_err(1, "cl_sps_init");
if ((sps = sps_init(arg)) == NULL)
e_err(1, "sps_init");
if (sps_error(sps))
e_errx(1, "sps_init: %s", sps_strerror(sps));
(void) cl_sps_push(*q, sps);
}
However, looking at this problem further, it appears that the
error number regcomp(3) is returning is not *remotely* anywhere close
to any of the standard REG_* error codes. I put in some stupid
fprintf commands, and found the following values being set after the
call to regcomp(3):
sps->sps_name = ^/movies
(int) &sps->sps_reg = 135192588
(int) &sps->sps_reg.re_endp = 135192596
sps->sps_reg_errno = 135196672
These are the definitions I can find for REG_* in /usr/include/regex.h:
#define REG_BASIC
#define REG_EXTENDED0001
#define REG_ICASE 0002
#define REG_NOSUB 0004
#define REG_NEWLINE 0010
#define REG_NOSPEC 0020
#define REG_PEND0040
#define REG_DUMP0200
#define REG_NOMATCH 1
#define REG_BADPAT 2
#define REG_ECOLLATE 3
#define REG_ECTYPE 4
#define REG_EESCAPE 5
#define REG_ESUBREG 6
#define REG_EBRACK 7
#define REG_EPAREN 8
#define REG_EBRACE 9
#define REG_BADBR 10
#define REG_ERANGE 11
#define REG_ESPACE 12
#define REG_BADRPT 13
#define REG_EMPTY 14
#define REG_ASSERT 15
#define REG_INVARG 16
#define REG_ATOI255 /* convert name to number (!) */
#define REG_ITOA0400/* convert number to name (!) */
#define REG_NOTBOL 1
#define REG_NOTEOL 2
#define REG_STARTEND4
#define REG_TRACE 00400 /* tracing of execution */
#define REG_LARGE 01000 /* force large representation */
#define REG_BACKR 02000 /* force use of backref code */
But none of these numbers looks remotely like what
sps->sps_reg_errno is being set to!
I'm completely and totally stumped. I've gotten to the point
where it looks like regcomp(3) is doing something totally whacked-out
in response to the input, but I can't figure out how to proceed from
here.
Any and all assistance would be appreciated!
--
These are my opinions -- not to be taken as official Skynet policy
=
Re: Weird NSLOOKUP output...
At 3:25 PM +0200 2000/6/22, laurens van alphen (craxx) wrote: > BB (big brother) has reported some nameserver problems with our > upstream. > > - Maybe NSLOOKUP is broken (FreeBSD 4.0-STABLE #4: Sun Jun 18 00:32:25 CEST > 2000) because DIG works fine. It is normal for nslookup to try to lookup the name of the nameserver it is told to be using, according to the IP address listed in /etc/resolv.conf. If there is a temporary DNS problem and there are no other servers listed in /etc/resolv.conf (or that was the last one), this can cause nslookup to abort. It is my understanding that the current version of nslookup is unlikely to live much longer. BIND-knowledgeable people I know of strongly recommend that you use "dig" instead, and in fact I've heard rumours that future versions of nslookup may in fact simply be another interface to the "dig" program, or may be a script of some sort that simply calls dig. -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: SSH failed on 4.0-S
At 12:25 PM +0200 2000/6/19, Alessandro de Manzano wrote: >>> Jun 19 10:48:27 gandalf sshd[438]: fatal: rsa_private_decrypt() failed >> >>This means the key could not be processed for some reason. Are you certain >>you are using an sshd from 4.0-STABLE? The most common cause of this error > > well, I think yes, because I upgraded all via CVSUP using this supfile: Yup. The RSAREF library can't handle keys longer than 1024 bits. If you upgrade with the /usr/ports/security/rsaintl library, that should solve the problem (unless you're in the US, in which case you can't do that for copyright reasons that will require that you continue to use the RSAREF library instead). -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: How good is AMI MegaRAID support?
At 1:19 PM -0400 2000/5/3, Charles N. Owens wrote: > Do you have any pointers to such information (ideally, something like a > "how-to")? Greg is the one who told me about it, and this was the kicker behind my finally getting off my butt and giving 4.0 a try, although I have yet to actually try to do anything with this particular functionality. > I do know that Greg Lehey has been investigating such functionality... Greg would be the man to ask. ;-) -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: How good is AMI MegaRAID support?
At 12:31 PM -0400 2000/4/29, Brandon D. Valentine wrote: > I can definitely appreciate that. The RAID solution of choice for > FreeBSD appears to be SCSI-SCSI RAID adapters as utilized on > wcarchive.cdrom.com and ftp.freesoftware.org -- the two busiest ftp > archives around and consequently the two busiest disk subsystems around. The testing I've done so far confirms what Greg Lehey and everyone else has been telling me all this time -- dedicated RAID controllers just really can't keep up with a good software solution (such as vinum, or even ccd) and modern hardware. It takes a lot longer to develop all the custom hardware to put into a RAID controller, and main CPU speeds have been increasing so fast, that it's quicker and easier to do it all in software these days. Even the megabuck Comparex/Hitachi mainframe-style RAID array that I've been pounding the snot out of for weeks doesn't reach the performance levels of the software RAID configuration that Joe Greco built on top of Adaptec controller and bare 50GB 7200 RPM drives (for his 1.8TB news spool server), and I have 10kRPM drives and can throw as much as 4GB of on-board controller RAM at the problem. I can get reasonably close to his levels of performance, but I haven't been able to equal them. In fact, to come anywhere *close* to the levels of performance that Joe has previously mentioned, I've had to add software RAID 0+1 (in the form of vinum) on top of the hardware RAID-5 (we tested the other forms of RAID, there doesn't seem to be any noticeable speed improvement), so that you are striped both horizontally and vertically. -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Kudos to all!
Folks, I'd like to extend my thanks and give kudos to all who have been involved in the process of creating FreeBSD 4.0, from -CURRENT up through -STABLE, and beyond to wherever that might take us. We had a new Dell PowerEdge 6350/500 server that arrived here yesterday, and although the machine was bought to run Windows NT as a games server, the admin of the machine wanted to install and run Linux on it first, just to play around. Well, Slackware, Debian, and RedHat all seriously bombed out in one way or another. He even tried OpenBSD, but again no luck. They were convinced that there was a very serious hardware problem, and that they'd have to ship the machine back. On a lark, I slipped in a FreeBSD 4.0-RELEASE kernel floppy, and began what is clearly the easiest and simplest boot & installation procedure that they appear to have ever seen. It worked the first time without a single hiccup, it installed in *way* less time than anything else they've ever done before, and I think I pretty seriously embarrassed them. ;-) I don't know if this will win us any converts from the die-hard Linux camp, but I think it certainly demonstrates the quality of the product that this project has produced. Oh, and the machine did get very quickly wiped -- it's running NT now. However, I don't think they'll ever bother to try to run Linux on it again. ;-) -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make world failed
At 10:42 AM -0600 2000/4/4, Warner Losh wrote: > Yes. Also, for -current's UPDATING I specifically keep things short > and to the point, lest I encourage people to follow -current who don't > have the skills, time or patience that is required of -current. Unfortunately, this may come back to bite you when -CURRENT becomes -STABLE. Funny, it's always the edge conditions that tend to cause the most problems. ;-) -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Off-topic News: WAS: Re: 3.4-Stable crashes..(heavydiskio+networking)
At 5:24 PM -0700 2000/3/22, Forrest W. Christian wrote: > Has there been any progress made on a decent news CACHE software? > > I'd love to try something the likes of nntpcache, but hopefully something > that works better than nntpcache did a couple of years ago. In this role, I think Diablo/dreaderd actually works pretty good. You do have to take a header-only feed from the server that assigns the article ids, but from there the dreaderd servers can pull a copy of the article from any server they know about, and it only needs to support the standard "ARTICLE " command format (which I think all current news spool server software can handle), and then they hand out overview and history from local disk, as well as locally cached articles. I'd encourage you to come to SANE 2000 and attend Joe Greco's presentation that will be describing the large-scale USENET news server system he has built/is building, its architecture, etc See <http://www.nluug.nl/sane/> in general, and <http://www.nluug.nl/sane/daily/25/greco.html> in particular. You might also be interested in Poul-Henning Kamp's presentation "Confining the Omnipotent root", which is going to be describing the new jail() facility in FreeBSD 4.0-STABLE. See <http://www.nluug.nl/sane/daily/24/kamp.html> for more details. Disclaimer: I am on the Program Committee for SANE 2000, and I am the sponsoring committee member for Joe's presentation as well as Jon Lasser's "Bastille Linux: Security through Transparency" presentation (see <http://www.nluug.nl/sane/daily/24/lasser.html> for details). -- These are my opinions -- not to be taken as official Skynet policy == Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: dot-0 releases
At 3:40 PM -0800 2000/3/21, Jordan K. Hubbard wrote: > Actually, those our outdated statements and I'm going to ask the > Walnut Creek CDROM postmaster to remove them. They only send a > confusing message. Thanks for the reminder. :) So, you're saying that it's perfectly safe for me to replace the one and only news peering server that we have (currently running 3.x) with one running 4.0-RELEASE, and if we have any problems then you'll personally fly out here to fix it? ;-) I hope you'll forgive me if I tend to be slightly more conservative than this, and if I recommend that others do the same. We're not all clones of David Greenman, Jordan K. Hubbard, or Mike O'Dell. ;-) -- These are my opinions -- not to be taken as official Skynet policy ========== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Voxware is toast. Get used to it. (Re: Suggestions forimproving newpcm performance?)
At 11:25 AM -0800 2000/3/21, Jordan K. Hubbard wrote: > Which areas are these? Again, please be specific so that I can > actually respond to this rather than going "What the hell is this man > even talking about?" :-) Alright, as I get first-hand details of problems that I am personally experiencing with 4.0-STABLE, I will post them here or in -current, as I feel more appropriate. In fact, you may want to look at a message I just posted on -current with regards to vinum and rawio, although at this stage I'm at the "what the hell did I do wrong?" stage, and can't do much more than identify that there is some sort of problem. -- These are my opinions -- not to be taken as official Skynet policy ====== Brad Knowles, <[EMAIL PROTECTED]>|| Belgacom Skynet SA/NV Systems Architect, Mail/News/FTP/Proxy Admin || Rue Colonel Bourg, 124 Phone/Fax: +32-2-706.13.11/12.49 || B-1140 Brussels http://www.skynet.be || Belgium To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Weirdest crash I ever saw...
At 7:23 PM +0100 2000/3/10, Brad Knowles wrote: > As soon as I can, I'll gdb the crash dump, and post the trace back here. Okay, here's the traceback with debugging symbols: $ gdb -k kernel /var/crash/vmcore.1 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... IdlePTD 2846720 initial pcb at 24337c panicstr: page fault panic messages: --- panic: rslock: cpu: 1, addr: 0xc02601d0, lock: 0x0101 mp_lock = 0101; cpuid = 1; lapic.id = boot() called on cpu#1 sc0: sc_switch_scr() 1 syncing disks... kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a41a4 stack pointer = 0x10:0xff804bf0 frame pointer = 0x10:0xff804bf4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = boot() called on cpu#1 sc0: sc_switch_scr() 1 dumping to dev 30401, offset 262144 dump 1024 1023 1022 1021 1020 1019 1018 1017 1016 1015 1014 1013 1012 1011 1010 1009 1008 1007 1006 10 05 1004 1003 1002 1001 1000 999 998 997 996 995 994 993 992 991 990 989 988 987 986 985 984 983 982 98 1 980 979 978 977 976 975 974 973 972 971 970 969 968 967 966 965 964 963 962 961 960 959 958 957 956 955 954 953 952 951 950 949 948 947 946 945 944 943 942 941 940 939 938 937 936 935 934 933 932 931 93 0 929 928 927 926 925 924 923 922 921 920 919 918 917 916 915 914 913 912 911 910 909 908 907 906 905 904 903 902 901 900 899 898 897 896 895 894 893 892 891 890 889 888 887 886 885 884 883 882 881 880 87 9 878 877 876 875 874 873 872 871 870 869 868 867 866 865 864 863 862 861 860 859 858 857 856 855 854 853 852 851 850 849 848 847 846 845 844 843 842 841 840 839 838 837 836 835 834 833 832 831 830 829 82 8 827 826 825 824 823 822 821 820 819 818 817 816 815 814 813 812 811 810 809 808 807 806 805 804 803 802 801 800 799 798 797 796 795 794 793 792 791 790 789 788 787 786 785 784 783 782 781 780 779 778 77 7 776 775 774 773 772 771 770 769 768 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751 750 749 748 747 746 745 744 743 742 741 740 739 738 737 736 735 734 733 732 731 730 729 728 727 72 6 725 724 723 722 721 720 719 718 717 716 715 714 713 712 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694 693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 67 5 674 673 672 671 670 669 668 667 666 665 664 663 662 661 660 659 658 657 656 655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 62 4 623 622 621 620 619 618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599 598 597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 581 580 579 578 577 576 575 574 57 3 572 571 570 569 568 567 566 565 564 563 562 561 560 559 558 557 556 555 554 553 552 551 550 549 548 547 546 545 544 543 542 541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525 524 523 52 2 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 47 1 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 42 0 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 36 9 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 31 8 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 26 7 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 21
Re: Weirdest crash I ever saw...
At 6:44 PM +0100 2000/3/10, Brad Knowles wrote: > Nevermind. With a bit more searching, I found > <http://www.freebsd.org/handbook/x10359.html>. My serial cable > wasn't a cross-over, and I hadn't enabled certain other options. Okay, here's the crash dump traceback (yes, I just noticed that I hadn't built the kernel with -g, so I'm rebuilding it now): root@audrey:/sys/compile/AUDREY$ gdb -k kernel /var/crash/vmcore.1 GNU gdb 4.18 Copyright 1998 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-unknown-freebsd"... (no debugging symbols found)... IdlePTD 2846720 initial pcb at 24337c panicstr: page fault panic messages: --- panic: rslock: cpu: 1, addr: 0xc02601d0, lock: 0x0101 mp_lock = 0101; cpuid = 1; lapic.id = boot() called on cpu#1 sc0: sc_switch_scr() 1 syncing disks... kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a41a4 stack pointer = 0x10:0xff804bf0 frame pointer = 0x10:0xff804bf4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = boot() called on cpu#1 sc0: sc_switch_scr() 1 dumping to dev 30401, offset 262144 dump 1024 1023 1022 1021 1020 1019 1018 1017 1016 1015 1014 1013 1012 1011 1010 1009 1008 1007 1006 10 05 1004 1003 1002 1001 1000 999 998 997 996 995 994 993 992 991 990 989 988 987 986 985 984 983 982 98 1 980 979 978 977 976 975 974 973 972 971 970 969 968 967 966 965 964 963 962 961 960 959 958 957 956 955 954 953 952 951 950 949 948 947 946 945 944 943 942 941 940 939 938 937 936 935 934 933 932 931 93 0 929 928 927 926 925 924 923 922 921 920 919 918 917 916 915 914 913 912 911 910 909 908 907 906 905 904 903 902 901 900 899 898 897 896 895 894 893 892 891 890 889 888 887 886 885 884 883 882 881 880 87 9 878 877 876 875 874 873 872 871 870 869 868 867 866 865 864 863 862 861 860 859 858 857 856 855 854 853 852 851 850 849 848 847 846 845 844 843 842 841 840 839 838 837 836 835 834 833 832 831 830 829 82 8 827 826 825 824 823 822 821 820 819 818 817 816 815 814 813 812 811 810 809 808 807 806 805 804 803 802 801 800 799 798 797 796 795 794 793 792 791 790 789 788 787 786 785 784 783 782 781 780 779 778 77 7 776 775 774 773 772 771 770 769 768 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751 750 749 748 747 746 745 744 743 742 741 740 739 738 737 736 735 734 733 732 731 730 729 728 727 72 6 725 724 723 722 721 720 719 718 717 716 715 714 713 712 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694 693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 67 5 674 673 672 671 670 669 668 667 666 665 664 663 662 661 660 659 658 657 656 655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 62 4 623 622 621 620 619 618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599 598 597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 581 580 579 578 577 576 575 574 57 3 572 571 570 569 568 567 566 565 564 563 562 561 560 559 558 557 556 555 554 553 552 551 550 549 548 547 546 545 544 543 542 541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525 524 523 52 2 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 47 1 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 42 0 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 36 9 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 31 8 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284
Re: Weirdest crash I ever saw...
At 6:44 PM +0100 2000/3/10, Brad Knowles wrote: > Nevermind. With a bit more searching, I found > <http://www.freebsd.org/handbook/x10359.html>. My serial cable > wasn't a cross-over, and I hadn't enabled certain other options. Well, I tried to drop into DDB for the first time (by sending a "BREAK" from the serial console that was finally working), and got the crash shown at the bottom. As soon as I can, I'll gdb the crash dump, and post the trace back here. Thanks! -Brad panic: rslock: cpu: 1, addr: 0xc02601d0, lock: 0x0101 mp_lock = 0101; cpuid = 1; lapic.id = boot() called on cpu#1 sc0: sc_switch_scr() 1 syncing disks... kernel trap 12 with interrupts disabled Fatal trap 12: page fault while in kernel mode mp_lock = 0102; cpuid = 1; lapic.id = fault virtual address = 0x30 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01a41a4 stack pointer = 0x10:0xff804bf0 frame pointer = 0x10:0xff804bf4 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= resume, IOPL = 0 current process = Idle interrupt mask = bio <- SMP: XXX trap number = 12 panic: page fault mp_lock = 0102; cpuid = 1; lapic.id = boot() called on cpu#1 sc0: sc_switch_scr() 1 dumping to dev 30401, offset 262144 dump 1024 1023 1022 1021 1020 1019 1018 1017 1016 1015 1014 1013 1012 1011 1010 1009 1008 1007 1006 10 05 1004 1003 1002 1001 1000 999 998 997 996 995 994 993 992 991 990 989 988 987 986 985 984 983 982 98 1 980 979 978 977 976 975 974 973 972 971 970 969 968 967 966 965 964 963 962 961 960 959 958 957 956 955 954 953 952 951 950 949 948 947 946 945 944 943 942 941 940 939 938 937 936 935 934 933 932 931 93 0 929 928 927 926 925 924 923 922 921 920 919 918 917 916 915 914 913 912 911 910 909 908 907 906 905 904 903 902 901 900 899 898 897 896 895 894 893 892 891 890 889 888 887 886 885 884 883 882 881 880 87 9 878 877 876 875 874 873 872 871 870 869 868 867 866 865 864 863 862 861 860 859 858 857 856 855 854 853 852 851 850 849 848 847 846 845 844 843 842 841 840 839 838 837 836 835 834 833 832 831 830 829 82 8 827 826 825 824 823 822 821 820 819 818 817 816 815 814 813 812 811 810 809 808 807 806 805 804 803 802 801 800 799 798 797 796 795 794 793 792 791 790 789 788 787 786 785 784 783 782 781 780 779 778 77 7 776 775 774 773 772 771 770 769 768 767 766 765 764 763 762 761 760 759 758 757 756 755 754 753 752 751 750 749 748 747 746 745 744 743 742 741 740 739 738 737 736 735 734 733 732 731 730 729 728 727 72 6 725 724 723 722 721 720 719 718 717 716 715 714 713 712 711 710 709 708 707 706 705 704 703 702 701 700 699 698 697 696 695 694 693 692 691 690 689 688 687 686 685 684 683 682 681 680 679 678 677 676 67 5 674 673 672 671 670 669 668 667 666 665 664 663 662 661 660 659 658 657 656 655 654 653 652 651 650 649 648 647 646 645 644 643 642 641 640 639 638 637 636 635 634 633 632 631 630 629 628 627 626 625 62 4 623 622 621 620 619 618 617 616 615 614 613 612 611 610 609 608 607 606 605 604 603 602 601 600 599 598 597 596 595 594 593 592 591 590 589 588 587 586 585 584 583 582 581 580 579 578 577 576 575 574 57 3 572 571 570 569 568 567 566 565 564 563 562 561 560 559 558 557 556 555 554 553 552 551 550 549 548 547 546 545 544 543 542 541 540 539 538 537 536 535 534 533 532 531 530 529 528 527 526 525 524 523 52 2 521 520 519 518 517 516 515 514 513 512 511 510 509 508 507 506 505 504 503 502 501 500 499 498 497 496 495 494 493 492 491 490 489 488 487 486 485 484 483 482 481 480 479 478 477 476 475 474 473 472 47 1 470 469 468 467 466 465 464 463 462 461 460 459 458 457 456 455 454 453 452 451 450 449 448 447 446 445 444 443 442 441 440 439 438 437 436 435 434 433 432 431 430 429 428 427 426 425 424 423 422 421 42 0 419 418 417 416 415 414 413 412 411 410 409 408 407 406 405 404 403 402 401 400 399 398 397 396 395 394 393 392 391 390 389 388 387 386 385 384 383 382 381 380 379 378 377 376 375 374 373 372 371 370 36 9 368 367 366 365 364 363 362 361 360 359 358 357 356 355 354 353 352 351 350 349 348 347 346 345 344 343 342 341 340 339 338 337 336 335 334 333 332 331 330 329 328 327 326 325 324 323 322 321 320 319 31 8 317 316 315 314 313 312 311 310 309 308 307 306 305 304 303 302 301 300 299 298 297 296 295 294 293 292 291 290 289 288 287 286 285 284 283 282 281 280 279 278 277 276 275 274 273 272 271 270 269 268 26 7 266 265 264 263 262 261 260 259 258 257 256 255 254 253 252 251 250 249 248 247 246 245 244 243 242 241 240 239 238 237 236 235 234 233 232 231 230 229 228 227 226 225 224 223 222 221 220 219 218 217 21 6 215 214 213 212 211 210 209 208 207 206 205 204 203 202 201 200 199 198 197 196 195 194 193 192 191 190 189 188 187 186 185 184 183 182 181 180 179 178 177 1
Re: Weirdest crash I ever saw...
At 6:07 PM +0100 2000/3/10, Brad Knowles wrote: > Also, although I've got DDB compiled into the kernel, it doesn't > seem to be recognizing the serial cable I've got attached, which > would allow me to cut-n-paste error messages. Is there anything > more I need to do -- maybe remove the keyboard and reboot again? Nevermind. With a bit more searching, I found <http://www.freebsd.org/handbook/x10359.html>. My serial cable wasn't a cross-over, and I hadn't enabled certain other options. -- These are my opinions and should not be taken as official Skynet policy ========= Brad Knowles, <[EMAIL PROTECTED]> Sys. Arch., Mail/News/FTP/Proxy Admin Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result. See <http://i-want-a-website.com/about-microsoft/twelve-step.html> for details. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Weirdest crash I ever saw...
At 1:58 PM +0100 2000/3/10, Brad Knowles wrote: > PL 0, pres 1, def32 1, gran 1 processor eflags= i > nterrupt enabled, resume, IOPL = 0 current process = 0 >(swapper) interrupt mask = n > et tty <- SMP: XXX trap number = 1 For those who are interested, at the bottom of this message is the output of dmesg on this machine, after a more verbose boot. Interestingly, when I cold booted the machine (hit the reset button), it came back up okay, so that I could make the necessary changes in /boot/defaults/loader.conf so that I could get this information, and then when I did another soft reboot (using `shutdown -r`), it came back up again okay as well. Also, although I've got DDB compiled into the kernel, it doesn't seem to be recognizing the serial cable I've got attached, which would allow me to cut-n-paste error messages. Is there anything more I need to do -- maybe remove the keyboard and reboot again? Anyway, it sure beats the hell out of me why this machine seriously flaked out a couple of boots ago. -Brad $ dmesg Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-STABLE #0: Fri Mar 10 13:34:36 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/AUDREY Calibrating clock(s) ... TSC clock: 448607251 Hz, i8254 clock: 1193146 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter "i8254" frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method CPU: Pentium III (686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbff> real memory = 1073741824 (1048576K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x002bd000 - 0x3ffd, 1070739456 bytes (261411 pages) avail memory = 1042726912 (1018288K bytes) Programming 24 pins in IOAPIC #0 SMP: CPU0 apic_initialize(): lint0: 0x0700 lint1: 0x00010400 TPR: 0x0010 SVR: 0x01ff FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 1, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 0, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Found BIOS32 Service Directory header at 0xc00ffe80 Entry = 0xffe90 (0xc00ffe90) Rev = 0 Len = 1 PCI BIOS entry at 0xc86e SMIBIOS header at 0xc00fac00 Version 2.2 Table at 0xfac20, 83 entries, 2776 bytes, largest entry 175 bytes DMI header at 0xc00fac10 Version 2.2 Table at 0xfac20, 83 entries, 2776 bytes Other BIOS signatures found: ACPI: $PnP: 000fe2d0 Preloaded elf kernel "kernel" at 0xc02a5000. Pentium Pro MTRR support enabled Math emulator present SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x0010 SVR: 0x01ff pci_open(1):mode 1 addr port (0x0cf8) is 0x8090 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) Probing for devices on PCI bus 0: found-> vendor=0x8086, dev=0x7190, revid=0x03 class=06-00-00, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 3, range 32, base f000, size 26 chip0: rev 0x03 on pci0.0.0 found-> vendor=0x8086, dev=0x7191, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=1secondarybus=1 chip1: rev 0x03 on pci0.1.0 found-> vendor=0x1011, dev=0x0024, revid=0x03 class=06-04-00, hdrtype=0x01, mfdev=0 subordinatebus=2secondarybus=2 chip2: rev 0x03 on pci0.2.0 found-> vendor=0x8086, dev=0x7110, revid=0x02 class=06-01-00, hdrtype=0x00, mfdev=1 subordinatebus=0secondarybus=0 chip3: rev 0x02 on pci0.7.0 found-> vendor=0x8086, dev=0x7111, revid=0x01 class=01-01-80, hdrtype=0x00, mfdev=0 subordinatebus=0secondarybus=0 map[0]: type 4, range 32, base ffa0, size 4 ide_pci0: rev 0x01 on pci0.7.1 intel_piix_status: primary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: primary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled intel_piix_status: primary master/slave sample = 5, master/slave recovery = 4 intel_piix_status: primary slave fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampling disabled, intel_piix_status: fast PIO disabled ide_pci: busmaster 0 status: 04 from port: ffa2 intel_piix_status: secondary master/slave sample = 3, master/slave recovery = 1 intel_piix_status: secondary master fastDMAonly disabled, pre/post disabled, intel_piix_status: IORDY sampl
Re: Error: "Maximum file descriptors exceeded"...
At 11:46 AM -0500 2000/2/29, Sean O'Connell wrote: > So for the matter at hand, I would suppose that stopping and restarting > innd would be all that is needed. Sigh The problem turns out to have been a hard-coded limit in Diablo. I've recompiled/stopped/restarted and I'll wait to see if the problem recurs Sean, when you're done with it, would you please pass the pointy hat over this way? Thanks everyone! -- These are my opinions and should not be taken as official Skynet policy ===== Brad Knowles, <[EMAIL PROTECTED]> Sys. Arch., Mail/News/FTP/Proxy Admin Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result. See <http://i-want-a-website.com/about-microsoft/twelve-step.html> for details. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Error: "Maximum file descriptors exceeded"...
At 11:46 AM -0500 2000/2/29, Sean O'Connell wrote: > So for the matter at hand, I would suppose that stopping and restarting > innd would be all that is needed. My problem is with Diablo (not innd), and I've already stopped and restarted it several times. No change. Anyone got any other ideas? -- These are my opinions and should not be taken as official Skynet policy ========= Brad Knowles, <[EMAIL PROTECTED]> Sys. Arch., Mail/News/FTP/Proxy Admin Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result. See <http://i-want-a-website.com/about-microsoft/twelve-step.html> for details. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Error: "Maximum file descriptors exceeded"...
At 11:16 AM -0500 2000/2/29, James Housley wrote:
> housley@cat:~/work/monitors {34} sysctl -a | grep -i file
Any my results:
$ sysctl -a | grep -i file
kern.maxfiles: 32768
kern.bootfile: /kernel
kern.maxfilesperproc: 16384
kern.corefile: %N.core
p1003_1b.mapped_files: 0
> It looks like updating kern.maxfiles and/or kern.maxfilesperproc should
> do the trick. What are the limits set in /etc/login.conf??
I would think so too, but this doesn't seem to be the case. The
non-comment lines from my /etc/login.conf were previously posted, and
don't set any limits for any user that are any different from what
root gets.
--
These are my opinions and should not be taken as official Skynet policy
=========
Brad Knowles, <[EMAIL PROTECTED]> Sys. Arch., Mail/News/FTP/Proxy Admin
Note: No Microsoft programs were used in the creation or distribution of
this message. If you are using a Microsoft program to view this message,
be forewarned that I am not responsible for any harm you may encounter as
a result.
See <http://i-want-a-website.com/about-microsoft/twelve-step.html> for
details.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
Re: Error: "Maximum file descriptors exceeded"...
At 11:34 AM -0500 2000/2/29, Sean O'Connell wrote: > % sysctl kern.maxfiles > kern.maxfiles: 4096 > % sysctl kern.maxfilesperproc > kern.maxfilesperproc: 4096 > > However, limit -h (tcsh builtin) and limits -H still report > > descriptors 2088 > openfiles2088 Have you started a new tcsh since the sysctl? I think that these sorts of things tend to be set by the program when it starts up, and it does not interactively detect an increase. So, you'd need to stop and restart whatever program it is that needs the increased limits. This isn't a problem in my case, since I have repeatedly stopped and restarted the daemon in question. -- These are my opinions and should not be taken as official Skynet policy ===== Brad Knowles, <[EMAIL PROTECTED]> Sys. Arch., Mail/News/FTP/Proxy Admin Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result. See <http://i-want-a-website.com/about-microsoft/twelve-step.html> for details. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Error: "Maximum file descriptors exceeded"...
At 8:12 AM -0800 2000/2/29, Tom wrote: > Beware of per-user limits. You don't mention what user you ran "limit" > as, or what user the news server process runs as. Each could have very > different limits. See /etc/login.conf. It might even depend on how the > server server process is started. Processes started at boot run under the > "daemon" class, for instance. In theory, this is true. However, my /etc/login.conf does not appear to be configured this way: $ grep -v '^#' /etc/login.conf default:\ :copyright=/etc/COPYRIGHT:\ :welcome=/etc/motd:\ :setenv=MAIL=/var/mail/$,BLOCKSIZE=K:\ :path=~/bin /bin /usr/bin /usr/local/bin /usr/X11R6/bin:\ :nologin=/var/run/nologin:\ :cputime=unlimited:\ :datasize=unlimited:\ :stacksize=unlimited:\ :memorylocked=unlimited:\ :memoryuse=unlimited:\ :filesize=unlimited:\ :coredumpsize=unlimited:\ :openfiles=unlimited:\ :maxproc=unlimited:\ :priority=0:\ :ignoretime@:\ :umask=022: standard:\ :tc=default: xuser:\ :tc=default: staff:\ :tc=default: daemon:\ :tc=default: news:\ :tc=default: dialer:\ :tc=default: root:\ :ignorenologin:\ :tc=default: russian:Russian Users Accounts:\ :charset=KOI8-R:\ :lang=ru_RU.KOI8-R:\ :tc=default: > BTW, the system wide file limit is not static. You don't need to > re-compile to change it, or even reboot. Just use sysctl. I guess I'm going to have to read up on that Thanks! -- These are my opinions and should not be taken as official Skynet policy ===== Brad Knowles, <[EMAIL PROTECTED]> Sys. Arch., Mail/News/FTP/Proxy Admin Note: No Microsoft programs were used in the creation or distribution of this message. If you are using a Microsoft program to view this message, be forewarned that I am not responsible for any harm you may encounter as a result. See <http://i-want-a-website.com/about-microsoft/twelve-step.html> for details. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Multiple Adaptec 2940U2W controllers?
At 4:47 PM +0100 2000/2/24, Brad Knowles wrote: > Blargh. It does appear to hurt. After having received positive feedback on these reports from several people, I will continue posting updates. Thanks, folks. I can really use the support right now. > I'm trying the two 2940U2W > controllers on the primary PCI bus with the on-board AIC-7890 > controller hard-wired to the secondary PCI bus. Bugger. That doesn't work, either. I guess I should have paid more attention to the clue silk-screened on the motherboard near the first slot in the secondary PCI bus that says "RAID Upgradeable PCI slot", and another clue silk-screened elsewhere close by that said something like "Insert NICs into primary PCI bus only". Sigh I guess we get to buy a couple of 3950U2Ws, and maybe hold on to these 2940U2Ws and see if they can ever be useful in another project sometime. It looks like the PCI bridge chip is a real issue with this particular hardware configuration, and so far as I can tell, using SMP doesn't seem to make a difference. After confirming that everything is working okay again, we get to go back to reconfiguring the RAID array, doing horizontal striping across the logical units, seeing what happens when I add softupdates, etc I'll post results here when I've got 'em. Thanks everyone! -- These are my opinions and should not be taken as official Skynet policy _____ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Multiple Adaptec 2940U2W controllers?
At 4:04 PM +0100 2000/2/24, Brad Knowles wrote: > Now that the problem has been fixed, initial preliminary test > results indicate that I do actually see almost 2x speedup using > two host SCSI controllers to the two different drive array > controllers. I'm now moving one of the host SCSI adaptors back > to the other PCI bus, to see if that helps, hurts, or makes no > difference to the performance. > > If it doesn't hurt, I plan on leaving them on separate PCI busses. Blargh. It does appear to hurt. I'm trying the two 2940U2W controllers on the primary PCI bus with the on-board AIC-7890 controller hard-wired to the secondary PCI bus. If that doesn't work (and I don't suspect it will, but I want to test it for the sake of completeness), then for this machine the only solution appears to be to put SCSI controllers on the secondary PCI bus and everything else on the primary PCI bus. If that's the case, I'm going to be quite annoyed. That will mean that I cannot expand the number of SCSI busses in this machine by just adding more controllers. Instead, I will be forced to increase the number of SCSI channels by swapping out the current controllers and using 3950U2W controllers instead. Blargh. Double blargh. Blargh, say I. BTW, is anybody at all actually interested in this stuff, or am I just talking to myself? -- These are my opinions and should not be taken as official Skynet policy _________ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Multiple Adaptec 2940U2W controllers?
At 11:11 PM +0100 2000/2/23, Brad Knowles wrote: > I have switched to a non-SMP kernel (otherwise identical to what > I was previously running), I have tried moving both of the 2940U2W > controllers to either the primary or secondary PCI busses (on the > primary, one of them shared IRQs with the AIC-7890 controller, but > on the secondary although they share the PCI bus with the AIC-7890 > controller they all at least have different IRQs and I/O Base > Addresses). So far, nothing has worked. After working with the experts from Germany and the local field engineers, it appears that the problem was within the drive array configuration. It has two controllers (with one UltraSCSI 2 LVD interface each), and the two logical units on the array are accessible via both of them and visible to the host as two different devices. Although I was mounting only one each of the two logical units, it appears that control over these LUs was ping-ponging back and forth between the two controllers, thus trashing my throughput. Now that the problem has been fixed, initial preliminary test results indicate that I do actually see almost 2x speedup using two host SCSI controllers to the two different drive array controllers. I'm now moving one of the host SCSI adaptors back to the other PCI bus, to see if that helps, hurts, or makes no difference to the performance. If it doesn't hurt, I plan on leaving them on separate PCI busses. Afterwards, we're going to delete and recreate the logical units on the controller, so that we have a separate device for each column of disks (half of which will be made available through each controller), and then we're going to try software striping across the columns. This ought to be fun! ;-) -- These are my opinions and should not be taken as official Skynet policy _____ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Multiple Adaptec 2940U2W controllers?
At 7:46 PM +0100 2000/2/23, Brad Knowles wrote: > The machine in question is a Dell 1300 with two 450Mhz processors > (512KB L2 cache each) and 1GB ECC RAM. In addition to the on-board > Adaptec AIC-7890 controller (to which the system disk is attached, > a Quantum Atlas IV 9GB), I have two Adaptec 2940U2W controllers. I've gotten a couple of people that have responded with somewhat different advice. One thought it was likely to be a problem with the PCI bridge chip, the other with SMP. I have switched to a non-SMP kernel (otherwise identical to what I was previously running), I have tried moving both of the 2940U2W controllers to either the primary or secondary PCI busses (on the primary, one of them shared IRQs with the AIC-7890 controller, but on the secondary although they share the PCI bus with the AIC-7890 controller they all at least have different IRQs and I/O Base Addresses). So far, nothing has worked. I can't do it tonight, but maybe tomorrow sometime I can dig up one of those bloody Pentium III terminator cards and actually physically remove one of the CPUs to see if that makes a difference. Anyway, here's the latest dmesg output (with all three SCSI controllers on the secondary PCI bus): $ dmesg Copyright (c) 1992-1999 FreeBSD Inc. Copyright (c) 1982, 1986, 1989, 1991, 1993 The Regents of the University of California. All rights reserved. FreeBSD 3.4-STABLE #0: Wed Feb 23 20:12:27 CET 2000 [EMAIL PROTECTED]:/usr/src/sys/compile/ONECPU Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 448622884 Hz CPU: Pentium III (448.62-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x673 Stepping = 3 Features=0x383fbff> real memory = 1073741824 (1048576K bytes) avail memory = 1042796544 (1018356K bytes) Preloaded elf kernel "kernel" at 0xc0297000. Pentium Pro MTRR support enabled Probing for devices on PCI bus 0: chip0: rev 0x03 on pci0.0.0 chip1: rev 0x03 on pci0.1.0 chip2: rev 0x03 on pci0.2.0 chip3: rev 0x02 on pci0.7.0 ide_pci0: rev 0x01 on pci0.7.1 chip4: rev 0x02 on pci0.7.3 fxp0: rev 0x05 int a irq 14 on pci0.16.0 fxp0: Ethernet address 00:90:27:99:13:1a Probing for devices on PCI bus 1: vga0: rev 0x7a on pci1.0.0 Probing for devices on PCI bus 2: ahc0: rev 0x00 int a irq 11 on pci2.9.0 ahc0: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc1: rev 0x00 int a irq 10 on pci2.10.0 ahc1: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs ahc2: rev 0x01 int a irq 14 on pci2.11.0 ahc2: aic7890/91 Wide Channel A, SCSI Id=7, 16/255 SCBs Probing for devices on the ISA bus: sc0 on isa sc0: VGA color <16 virtual consoles, flags=0x0> atkbdc0 at 0x60-0x6f on motherboard atkbd0 irq 1 on isa psm0 not found sio0 at 0x3f8-0x3ff irq 4 flags 0x10 on isa sio0: type 16550A sio1 at 0x2f8-0x2ff irq 3 on isa sio1: type 16550A fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa fdc0: FIFO enabled, 8 bytes threshold fd0: 1.44MB 3.5in wdc0 not found at 0x1f0 scd0 not found at 0x230 ppc0 at 0x378 irq 7 flags 0x40 on isa ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold vga0 at 0x3b0-0x3df maddr 0xa msize 131072 on isa npx0 on motherboard npx0: INT 16 interface IP Filter: initialized. Default = pass all, Logging = enabled Waiting 5 seconds for SCSI devices to settle changing root device to da0da1 at ahc0 bus 0 target 0 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da1: 136470MB (279490560 512 byte sectors: 255H 63S/T 17397C) da3 at ahc1 bus 0 target 0 lun 0 da3: Fixed Direct Access SCSI-2 device da3: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da3: 136470MB (279490560 512 byte sectors: 255H 63S/T 17397C) da2 at ahc0 bus 0 target 0 lun 1 da2: Fixed Direct Access SCSI-2 device da2: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da2: 136470MB (279490560 512 byte sectors: 255H 63S/T 17397C) da4 at ahc1 bus 0 target 0 lun 1 da4: Fixed Direct Access SCSI-2 device da4: 80.000MB/s transfers (40.000MHz, offset 15, 16bit), Tagged Queueing Enabled da4: 136470MB (279490560 512 byte sectors: 255H 63S/T 17397C) da0 at ahc2 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 80.000MB/s transfers (40.000MHz, offset 31, 16bit), Tagged Queueing Enabled da0: 8683MB (17783249 512 byte sectors: 255H 63S/T 1106C) Thanks! -- These are my opinions and should not be taken as official Skynet policy _________ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels
Multiple Adaptec 2940U2W controllers?
Folks, I've got a machine I'm working on, and I'm seeing some unusual problems, so I wanted to get a sanity check. The machine in question is a Dell 1300 with two 450Mhz processors (512KB L2 cache each) and 1GB ECC RAM. In addition to the on-board Adaptec AIC-7890 controller (to which the system disk is attached, a Quantum Atlas IV 9GB), I have two Adaptec 2940U2W controllers. Each of these two controllers is attached to a different interface on a Hitachi/Comparex D1400 mainframe-style refrigerator-size drive array, with twenty 18GB Seagate 10kRPM "Cheetah" disks (plus one hot spare not currently being used) spread across five internal SCSI channels, and with 1GB ECC battery backed-up write-back cache (mirrored between the two controllers, so effective size is halved). On this machine, I have installed FreeBSD 3.4-STABLE (I cvsup'ed late last week, so it should be fairly up-to-date). Needless to say, we would expect this system to pretty much scream at disk I/O. Of course, this is precisely what it is not doing. Fortunately, all the work I have been doing over the last few days is in preparation for a Hitachi/Comparex performance expert to come in tomorrow and help us tune this thing for maximum performance from their perspective, but I'm seeing something weird from the host side and I'd like to ask if anyone else has seen anything similar. In particular, when we run the "postmark" benchmark on a single filesystem, we get some decent results (although not nearly as good as we'd like). When we run the same benchmark on two different filesystems mounted through two different controllers, well, performance really goes into the toilet -- the result is about 1/10th as fast as the single filesystem test. But, when we test the same two filesystems mounted through the same Adaptec controller, we see each test get almost exactly half the performance of the single filesystem test. This just doesn't make any sense to me. If anything, I would expect the dual controller configuration to result in each postmark benchmark getting nearly as much throughput as the single filesystem test, so that the aggregate is almost twice as much. But instead, it's ten times as slow?!? This just boggles my mind, and I don't have the first clue where to go looking to see what the problem might be. Is there any additional information I could provide that might prove helpful? Could there be conflicts of some sort between the two Adaptec 2940U2W controllers? Thanks for any and all advice, observations, and assistance you can provide! -- These are my opinions and should not be taken as official Skynet policy _____ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Popper
At 7:57 AM -1000 2000/2/10, Clifton Royston wrote: > What rev of qpopper do you use? The version we're using has serious > performance problems on large mail spools, which seem to be inherent in > its algorithm design. Try using one of the three supported mailbox hashing schemes that are shared between QPopper & procmail. -- These are my opinions and should not be taken as official Skynet policy _____ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Popper
At 8:42 PM +0200 2000/2/10, Yiorgos Adamopoulos wrote: > You can use UW-IMAPD which comes with an IMAP and a POP3 server (imapd and > ipop3d). If you want better performance than that of using the standard unix > mbox format, then you should convert to the mbx format. Where would one find out information regarding the differences between mbox format, mbx format, MH format, and Maildir format? I've heard of three of these (mbx is new to me), and I think I'm familiar enough with at least two of them, but I'm curious. In particular, I'm interested in finding out more about performance of the various formats, and what kind of evidence there is to back those claims up. Thanks! -- These are my opinions and should not be taken as official Skynet policy _____ |o| Brad Knowles, <[EMAIL PROTECTED]> Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: 4.4 BSD forever?
At 11:21 PM -0500 2000/1/8, Snuffles on Sonata wrote: > Some of us remember 4.1 and 4.2 as well. :-) Some of us remember 2.9BSD on a PDP 11/70 with two banks of 64KB RAM. ;-) And some of remember the day we saw a 15% performance increase on that machine, when one of the local hacker/admins installed a new kernel where the machine code (not assembly) had been hand-tuned. ;-) ;-) Of course, I'm sure that some of us remember much further back than that. Me, I can only go back so far as my freshman year of 1984. Also, this no longer has anything to do with -stable. This thread should either be killed or moved to -chat. -- These are my opinions -- not to be taken as official Skynet policy ____ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: Sendmail, 3.3-STABLE, relaying
At 2:00 PM -0700 2000/1/6, Nate Williams wrote: > Ok, how do you do something like 206.17.79.128/25? You list all the individual IP addresses that are in this CIDR block. Unfortunately, the method used by sendmail doesn't understand CIDR notation, and I don't think there's any way to make it understand CIDR notation short of some relatively significant source code modifications. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Temperature Findings
At 10:27 PM -0800 1999/12/30, Mike Smith wrote: > The difference has already been explained as a different instruction mix. > This should be obvious to anyone that has been in the industry for as > long as you have. It seems to me that you guys are all talking past each other: 1. He's mentioned that he runs the same instruction mix (i.e., two seti@home clients) under both Linux and FreeBSD 2. He's mentioned that he's run FreeBSD in both uniprocessor and SMP modes 3. He's mentioned that he's run FreeBSD SMP with 3.3 without problems 4. He's mentioned that the overclocking is a recent introduction to the issue and the system was overheating before then 5. He's also mentioned that this is a chipset which we now know is not directly supported by the measurement interface, and therefore the temperature multiples might (or might not) be off Now, I don't recall seeing which version of the Linux kernel he was talking about -- I'd be guessing that might have some effect. If it was a 2.0.x kernel, then obviously he's not getting more than one processor under Linux anyway. Depending on which 2.1.x or 2.2.x kernel he runs, he should be getting SMP under Linux (if he's built the kernel to support SMP), although he might not have very good SMP (2.2.13+, from all reports I've heard). I'd be real surprised if they found some way to HLT the processor under Linux in SMP, but I wouldn't rule it out as impossible. I do still find it suspicious that the temperature difference is 14 or 26 degrees, and that it rises much more quickly than would appear to be possible, given the thermal mass, etc I also find it suspicious that this works fine under FreeBSD in SMP in version 3.3 (even with all the overclocking, etc...) and that this only breaks in 3.4. Of course, the fact that everyone is talking past each other is not surprising, seeing as many of the correspondents are spread around the globe. If I might make a suggestion based on my own recent introduction to this mailing list -- it really helps if the new poster provides as much detail as possible and doesn't make any assumptions about how much they know about the problem based on their decade-plus (or more) experience, and it really helps if the other people involved give the guy at least half a break while he tries to explain what weirdo whacked out thing he's seeing. Myself, I think I've permanently pissed-off some of the important contributors to the FreeBSD project (and perhaps even some of the core members) by coming in too strong. I hope that one day I'll manage to be able to erase that deficit either by patching things up with the parties in question, or by making enough of my own positive contributions that the past can be forgiven, if not forgotten. Ghu help me if I'm actually the voice of reason in this case, but I felt like something needed to be said before this got too far out of hand. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Route table leaks
At 3:00 PM -0800 1999/12/9, Julian Elischer wrote: > so can it be committed? In -CURRENT, I would say that this could probably be committed, if John feels safe. I am not yet convinced that it should be committed to -STABLE, although things do look good so far. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Route table leaks
At 8:56 PM +0100 1999/12/9, Brad Knowles wrote: > So far, it looks like it might have fixed the problem. At least, > the "InUse" count goes down when a route goes away: Things continue to look good: Thu Dec 9 20:59:15 CET 1999 netstat -ran | wc -l 122 vmstat -m | grep routetbl | grep K routetbl 24834K 35K 40960K 2600 0 16,32,64,128,256 uptime 8:59PM up 2:08, 0 users, load averages: 2.13, 2.11, 2.16 Thu Dec 9 21:00:16 CET 1999 netstat -ran | wc -l 121 vmstat -m | grep routetbl | grep K routetbl 24634K 35K 40960K 2600 0 16,32,64,128,256 uptime 9:00PM up 2:09, 0 users, load averages: 3.18, 2.50, 2.31 [ ... deletia ... ] Thu Dec 9 21:56:40 CET 1999 netstat -ran | wc -l 121 vmstat -m | grep routetbl | grep K routetbl 24634K 35K 40960K 2600 0 16,32,64,128,256 uptime 9:56PM up 3:05, 0 users, load averages: 2.79, 2.87, 3.08 Thu Dec 9 21:57:40 CET 1999 netstat -ran | wc -l 120 vmstat -m | grep routetbl | grep K routetbl 24434K 35K 40960K 2600 0 16,32,64,128,256 uptime 9:57PM up 3:06, 0 users, load averages: 2.90, 2.93, 3.09 -- These are my opinions -- not to be taken as official Skynet policy ____ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Route table leaks
At 10:29 AM -0800 1999/12/9, John Polstra wrote: > Thanks for helping me test it! So far, it looks like it might have fixed the problem. At least, the "InUse" count goes down when a route goes away: Thu Dec 9 20:14:03 CET 1999 netstat -ran | wc -l 123 vmstat -m | grep routetbl | grep K routetbl 25035K 35K 40960K 2600 0 16,32,64,128,256 uptime 8:14PM up 1:23, 1 user, load averages: 1.67, 2.34, 3.27 Thu Dec 9 20:15:03 CET 1999 netstat -ran | wc -l 122 vmstat -m | grep routetbl | grep K routetbl 24834K 35K 40960K 2600 0 16,32,64,128,256 uptime 8:15PM up 1:24, 1 user, load averages: 1.60, 2.19, 3.15 I'll let you know if/when I get any more results. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: speaking of 3.4...
At 1:51 PM -0500 1999/11/23, Mikhail Teterin wrote: > Then, may be, that's not what's needed? The > 64Mb problems, AFAIR, was only addressed after some magazine benchmarked > FreeBSD against Linux on a 128Mb machine and we sucked because we were > only using 64Mb... You mean this problem has actually been fixed? Can I remove the MAXMEM definitions on the kernel configurations for my Dell PowerEdge 1300 servers? Cool! -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Roasting Newbies
At 10:08 AM -0700 1999/10/14, Doug wrote: > It is cabable of that, but managing this on the scale we're > talking about with the FreeBSD lists is just not an easy task. This idea > has been proposed often, and always rejected by the very people you claim > to want to help. I can't speak for whether or not it is practical in the context of the FreeBSD lists (I'm not the postmaster, after all), but I can speak within my experience. [0] > As much as I applaud any efforts to increase the level of user > education, I have to say that I think an automated response just will not > do. IMO, if it's not an automated response, the rules won't be implemented with any regularity, and the inappropriate questioners will not learn. You've got to set things up so that it is impossible for humans to screw up this task, because they're not real good at following precise recipes for exactly how to act, and reliably applying those rules each and every time. However, computers *are* real good at precisely these sorts of things. If you don't automate it, it won't happen. [0] I've been running mailing lists for a number of years, mostly small ones with Majordomo, but also some larger ones with industrial-strength tools such as Listserv. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make world failing because of missing unroff
At 1:39 PM +0200 1999/10/13, Sheldon Hearn wrote: > The doc tree isn't the src tree at all. Just because the source tree is > supplied with source for all the programs used to build it doesn't mean > it should be supplied with the source for the programs needed to build > the doc tree. So, what's required to build the programs to support the doc/ tree? If all they need is unroff, I'd suspect that all you'd need in the source tree is gcc/egcs, which should already be there, right? If nothing has to be added to the source tree to support the doc tree, and the doc tree includes all the tools it will need to support itself, then we're fine and we haven't added any unnecessary dependancies, right? > What's next, adding a web server to the src tree to support the www > tree? No, the web server should be a part of the www tree, but the programs to build the web server should be part of the source tree, at least the way I understand things. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: make world failing because of missing unroff
At 1:28 PM +0200 1999/10/13, Sheldon Hearn wrote: > If you want tools distributed with the sources which they support, you > should incorporate the tools into the doc/ tree. But then you'd still > need non-doc tools to build _those_. That's fine, but you shouldn't need anything outside of the normal source tree to support those tools, right? In other words, you wouldn't be dependant on yet another program from the ports system, right? I'm trying to understand just precisely what depends on what, and to help ensure that there are no circular dependancies. I'm also trying to help suggest a path whereby we don't have more important things (like the doc/ tree) dependant on lesser things (like the ports system). -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
RE: make world failing because of missing unroff
At 1:17 PM -0700 1999/10/12, Kris Kennaway wrote: > Documentation building has ample precedent for external dependencies - the > entire doc/ tree needs several ports installed to build. I'm sure there > are other examples in the tree. If I may make a suggestion then? If doc/ needs a particular tool, then that tool should be moved from the ports subsystem to the main source tree. -- These are my opinions -- not to be taken as official Skynet policy ____ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: vinum experiences (not as documented, at least).
At 11:49 AM -0400 1999/9/29, David Gilbert wrote: > Well... firstly, the design of the system was to put everything (even > swap) on the RAID drive. The root is outside, of course... and this > took some doing, but that's how the system is currently configured. > I'm not confident that dumping to the raid-swap would be correct. Hmm. Since crash dumps are written by a process that I do not believe is vinum aware, I'd be willing to bet that they won't properly be written. Even if that did work, I'm not sure where the crash dump recovery process is fired up, but I'd be willing to guess that it's before vinum gets started, so you'd have to also make some modifications there. > I may be able to find another drive to dump to, but that will take > several days. Swap and dump is not something that I would tend to be inclined to put on vinum. At least not until we can get to the point where we can put all filesystems under vinum, including the root filesystem. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: problems with adaptec 2940 cards on 3.3-STABLE
At 10:11 PM -0400 1999/9/28, Alok K. Dhir wrote: > I'd suspect the external SCSI cable if disconnecting it (and presumably > enabling termination on the card) fixed the problem... I wouldn't rule > out cables just because you have 2 machines with the same hardware... I wouldn't be surprised if the cables were marginally okay for UW use, but fail miserably for U2W LVD use. They may not even be differential SCSI cables, and in that case I would expect major problems in trying to use them with U2W LVD drives. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Vinum performance testing...
At 7:11 PM -0500 1999/9/15, Jeffrey J. Mountin wrote: > Well Greg considers it a "release" anyway and no longer alpha. Surely it > may be "under development" still, but then isn't -stable? My apologies. I was under the impression that it was still considered alpha code, but then I guess if it was it probably wouldn't have migrated to the -STABLE tree, now would it? Anyone have any more recent statements from Greg (or Matt, or anyone else that has previously expressed an opinion on the subject) with regards to whether or not they suggest using vinum on production systems yet? I know Greg is really busy trying to un-bury himself from thousands of mail messages, so I figure there's not much sense in me asking him directly. > Hopefully the searching would turn up the more significant number of > successes and minor problems that Greg usually responds very quickly to. True, very true. Greg has always been very responsive to my bug reports, once I understood enough about what kind of information he wanted to see. Thanks everyone! -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: [Q] HotPlug HDD & vinum
At 12:45 AM +0400 1999/9/16, =?koi8-r?Q?=E1=CE=D4=CF=CE=20=E1=CE=C1=D4=CF=CC=D8=C5=D7=C9=DE wrote: > I planning to build new intranet server based of 3-STABLE. > Buying of hardware RAID is a bit expensive for me and AFAIK, vinum is > the best solution for me. > Is it possible to use HotPlug HDD feature under vinum, and if "yes" - > HowTo? The equipment I'm aware of supporting a hot swap feature is expensive, and requires support from the OS and/or the drivers to enable the hot swap features. I do not believe that this support can be found in vinum, nor do I believe that it can be found in FreeBSD 3.x-STABLE. If you're going to spend that kind of money for hot swap drives, then I think the cost of a hardware RAID controller would be a relatively minimal addition. There's no sense trying to do this on the cheap for the controller, when you're then going to go out and spend all that much money on the hot swap drives. -- These are my opinions -- not to be taken as official Skynet policy ____ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Vinum performance testing...
At 1:43 PM -0700 1999/9/15, Jamie Norwood wrote: > No offense, but you are wrong and he is right. A 'still under developement' > product should NOT be used for critical production machines. You're absolutely right. I believe that even with the latest code, Greg does not recommend that it be used for production systems, and I recall relatively recent comments by Matt Dillon to the same effect. Anyone who is brave enough (or stupid enough) to use it on a production system gets what they deserve. While very promising, it's still not production-grade code. That said, I still think I'm going to give it a serious go on our Diablo/dreaderd news reader servers. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: softupdates in latest build?
At 11:29 AM -0700 1999/9/6, Mike Smith wrote: > I'll say it again; read what has already been said. Most of us are > heartily sick of your side of the argument, and you're not likely to > get many useful responses while you continue to display basic ignorance > of the issues involved. I think I'm beginning to understand the attitude problem that Linux advocates have accused the FreeBSD camp of. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: softupdates in latest build?
At 1:21 PM -0500 1999/9/6, David Scheidt wrote: > The cvsupfile that is linked from > http://www.freebsd.org/handbook/stable.html is one that properly tracks > RELENG_3. You must have done something silly. Yup. It wasn't obvious to me that the default supfile would not be the same as <ftp://ftp.FreeBSD.org/pub/FreeBSD/FreeBSD-current/src/share/examples/ cvsup/stable-supfile>. I have since learned this lesson, and while I can assure you that I will make trillions of mistakes in the future, and I'll probably even ultimately forget about this one and make it again, I probably won't be making this same mistake again any time soon. Thanks again! -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: softupdates in latest build?
At 7:56 PM +0200 1999/9/6, Dag-Erling Smorgrav wrote: > Please stop spreading such disinformation. It only comes across as an > infantile attempt to cover up the fact that you didn't do your > homework, and it damages the project's reputation as well as your own. I read the web page. It was not self-evident to me that the supfile that would be created by default was not the same supfile that was referenced on the web page. As to your use of the word "infantile", I'd have to say that this says more about your thought processes than mine. I've been perfectly willing all along to acknowledge my lack of experience in this area, which is the entire reason why I came to this mailing list to try to get help -- obviously from people other than the omniscient types such as yourself that can't be bothered to actually be helpful to anyone who has less than your own perfect knowledge of every single line of code throughout the entire OS. I'm more than happy to RTFM (I've written some in my time, and I've told more than a few to RTFM myself), if I'm told which section of which FM I should R. I don't usually ask for assistance unless I've checked out everything I can think of, and when I do ask questions, I usually try to make it abundantly clear what resources I've already used, what instructions I've tried to follow, and what problems I'm having. -- These are my opinions -- not to be taken as official Skynet policy |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: softupdates in latest build?
At 10:41 AM -0700 1999/9/6, Mike Smith wrote: > By the time an attacker has enough access rights on > your system to make use of the packet filter, they have enough access > rights to add it if it's not there. That's certainly true. However, if this feature is disabled by default, this throws just one more roadblock in front of some script kiddie that might want to break into your system. It won't stop a determined cracker (nothing will), and it won't stop someone with half an ounce of intelligence (they can just rebuild the kernel), but if you at least turn this off by default then they're forced to rebuild the kernel in order to enable this feature, and that would require a reboot. That might just make the system that much more noticable if someone tries to crack into it and install a password sniffer, and that much less easy to compromise security at that site. -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Does vinum actually currently build under 3.2-STABLE?
At 8:38 AM +0930 1999/7/8, Greg Lehey wrote: > Vinum builds under 3.2-STABLE. I don't know why you're trying to use > the wrong version. Yes, I once said that, at that moment, the > -CURRENT version would build under -STABLE. That was quite some time > ago, and it no longer applies. I apologize if I have offended you. I had not heard that vinum 4.0-CURRENT was no longer the version that I should be attempting to apply to FreeBSD 3.2-STABLE. The last time I had tried to do anything with vinum, you had recommended that I grab your -CURRENT and start over from there, and when I started working with vinum again, I tried to largely pick up where I left off before. I did carefully check the source trees to ensure that what you had did actually appear to be later code before I manually installed it (mv'ing each original affected file or directory to .orig, before copying your "new" code into place). It would help me (if no one else) if the documentation you had on your web site would be kept a bit more up-to-date as to which versions are suitable for use with which versions of FreeBSD, and if we're supposed to be using the version that ships with the package, says that too. Speaking only for myself, I'm not subscribed to all of the freebsd- mailing lists (heck, I'm not subscribed to any of them), and although I do active searching of the archives of the mailing lists before I post any questions, my searches might not be fully sufficient to dig up all the relevant information, or the archives might not yet have caught up to the absolute last-second state of the moment. > I did? Which one? I have not yet been able to locate the exact name of the file, but the most relevant messages of yours that I've found so far in the archives of the -current mailing list are at <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=431564+0+archive/1999/fr eebsd-current/19990704.freebsd-current> and <http://docs.freebsd.org/cgi/getmsg.cgi?fetch=532152+0+archive/1999/fr eebsd-current/19990704.freebsd-current>. Note that they are dated only five days ago. > It's supposed to build out of the box. Vinum is included in -STABLE. > The last modification was 11 May (sys/dev/vinum/vinumparser.c). The problem turned out to be that I had not managed to fully restore all the .orig files and directories I had manually mv'ed. Once I restored the one problem directory that had remained (/usr/src/sys/dev/vinum, as I recall), the build went cleanly. I'm now doing further benchmarks with rawio against a bare IBM UltraStar 9LZX 10KRPM drive connected through an Adaptec 3950U2, to add to the previous benchmarks I had done (and reported to you) on the DPT SmartRAID IV w/ 64MB cache and 128KB stripe size across four 9LZX drives. Once this test is complete, I'll do another test with a vinum one drive concat device on the same disk (to see what overhead vinum adds), then a two-way, three-way, and four-way stripe with identical disks. Since this is a pretty honkin' machine (PIII@450Mhz w/ 1GB RAM), it will be interesting to compare the performance of the older DPT SmartRAID IV card against vinum. I'll then go in and throw bonnie and perhaps some other tools at the 4-way striped disk arrays (both vinum and SmartRAID IV) and see what kind of difference 1GB of buffer cache can make. ;-) -- Brad Knowles <[EMAIL PROTECTED]> <http://www.shub-internet.org/brad/> <http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0xE38CCEF1> Your mouse has moved. Windows NT must be restarted for the change to take effect. Reboot now? [ OK ] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: OpenSSH for -STABLE?
At 8:58 AM -0600 1999/11/19, Jim King wrote: > Have you tried building the OpenSSH port on -stable? I built > and installed it last night (on a -stable x86 box, and a > -current Alpha box), and it appears to be working just fine. I tried that on my machine before I did anything else ;-), and although it pulled down the source, when it came to building OpenSSL, I got: To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
OpenSSH for -STABLE?
Folks, I know that OpenSSH is relatively new, and that a port for it was recently incorporated into -CURRENT. However, I can't find any information that would tell me whether or not it's been back-ported to -STABLE (the port for -CURRENT appears to depend on crypto.1, a library that does not appear to be found on -STABLE). Can anyone clear this up? Alternatively, can anyone point me at the official OpenSSH tarball? I found <http://www.freebsd.org/ports/security.html>, but the information on OpenSSH from this page is limited, and the web page at <http://www.openssh.com/> appears to be just another virtual host on the OpenBSD site, but without a corresponding OpenSSH-specific source tree, etc I also searched the online archives of -questions and -stable for "openssh", but no hits were returned. Thanks! -- These are my opinions -- not to be taken as official Skynet policy ________ |o| Brad Knowles, <[EMAIL PROTECTED]>Belgacom Skynet NV/SA |o| |o| Systems Architect, News & FTP Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.11.11/12.49 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
