oops... forget it... cvsup.freebsd.org I/O error on my machine :-)
Oops. The I/O error is on my machine , not cvsup :-) -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
cvsup.freebsd.org I/O error
Not sure who to notify here... I tried twice, this looks like a real error. -Matt /usr/local/bin/cvsup -g -r 20 -L 2 -h cvsup.freebsd.org /usr/share/examples/cvsup/cvs-supfile SetAttrs ports/emulators/sim6811/distinfo,v SetAttrs ports/emulators/sim6811/files/patch-aa,v SetAttrs ports/emulators/sim6811/files/patch-ab,v SetAttrs ports/emulators/sim6811/pkg-comment,v SetAttrs ports/emulators/sim6811/pkg-descr,v SetAttrs ports/emulators/sim6811/pkg-plist,v TreeList failed: Read failure from "/usr/sup/ports-all/checkouts.cvs": Input/output error To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: FreeBSD/VAX anyone interested?
Gunther Schadow <[EMAIL PROTECTED]> writes: > I got some VAXen 6420, big machines. Mine has 6 CPUs. I was planning > to boot myself with Ultrix, and then go on with NetBSD. Even > NetBSD's port-vax needs some tweaking for my hardware, XMI and > BI bus support is blank. I am with FreeBSD forever and FreeBSD > has SMP which NetBSD has not. I want to run all of my 6 CPUs > not just one. So, I am thinking about taking the Alpha port and > reverse hacking it into a VAX port with lots of cheating with > the NetBSD code. all you want to know about vax should be there : http://www.vaxarchive.org/ http://minnie.tuhs.org/Quasijarus/ Cyrille. -- home: mailto:[EMAIL PROTECTED] UNIX is user-friendly; it's just particular work: mailto:[EMAIL PROTECTED] about who it chooses to be friends with. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
On Fri, 25 May 2001, Terry Lambert wrote: > So add an option to sysinstall called: > > "Fast and at least as reliable as Linux" > > and let them find out for themselves that that means that it's > really dangerous, and that after a crash for whatever reason (e.g. > your panic crash, or a power failure for anyone without a UPS in > California), they will have to manuall fsck, whereas without the > write caching, it wouldn't have been a problem. Ok, I've had some time to look through some other discussions on this issue, and ready to jump back in. :) First, ignore my comment about the manual fsck on current w/softupdates. Someone on -current just reported the same problem; it sounds like a newly added bug to current, which probably doesn't affect stable. As to technical arguments for enabling write caching under uncertain power conditions, I can't come up with any. (Until the BIO_ORDERED work is done; is anyone actually working on it?) The demonization of linux above is unwarranted; I checked the linux ata driver, and they don't touch the write cache setting at all; it's left at the default setting for the drive. FreeBSD, on the other hand, will always set the write cache status so that it's at a known value. In releases prior to 4.3, it was being set to enabled. Hence, you should be saying "Fast and at least as reliable as FreeBSD 4.0, 4.1, and 4.2". Clearly, write caching makes some drives (probably those which come with it enabled) much faster. Also clearly, write caching hasn't caused many problems, since we would have seen reports by now if it was happening. There seem to be two compromises which could be made: 1. Have the ata driver leave the write cache setting alone by default, providing a sysctl which can cause disabled or enabled if requested. When the default is allowed, put something in dmesg which says "Note: Write caching may be enabled. See ata(4) for the reliability implications of this." 2. Leave the default to be 0, but instead print "Please see ata(4) to choose your write cache preferences." Also, put something in the release notes or src/updating which mentions this. Note that in either case it's note FreeBSD's "fault" that write caching is enabled; it's the user's or the drive maker's. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
> I doubt FreeBSD would need to enable write caching in order > to be as fast as Linux (which doesn't have write caching i spoke too harshly. what i meant to show is that interactive performance is compromised under load with soft updates enabled (although soft updates clearly speed up some general tasks and accelerate some tasks considerably). i also i wanted to show that hw.ata.wc=0 has 3-7x impact on fast hardware, which is a much larger impact than almost any other single parameter. i had seen soft updates as a justification of turning ata.wc off (later education on my part by the memebers of hackers has broadened my understanding of the motivation). i suspect that this issue was well hashed out in this news group when i wasn't tracking the stream. i use freebsd to help design the chips that i work on, and i've always relied on and been impressed by its ability to perform well handling large cad programs - so i was just surprised at the sudden change in this default behavior re hw.ata.wc=0. clearly, this was just ignorance on my part, and i suspect had i looked more closely at the release notes i would have just turned this parameter on, kept soft-updates off and still been a happy camper. (much kudoo's to mr. dillons now timely tuning.7, btw). another note regarding hw.ata.wc=0 as the default - if i assume that i've been running effectively with hw.ata.wc=1 for the last couple of years, i would extrapolate that the likelyhood of a fbsd/ufs failure in this mode is small compared to the reliability problems of the rest of the system, and the same protection that covers those liabilities also cover my exposure to hw.ata.wc=1 problems (e.g., good backups, ups's, etc). given the huge impact that users (at least those like myself) see of this parameter, and the reliability impact that i think i understand, i am surprised by the choice of default. it feels like a recruiting attempt for linux. (btw, i do think that the freebsd project is probably the best working example of open source software, and its benefits, so i'm not trying to promote linux - but both have benefited from their coevolution). (system reliability: - i think hard drive failures are maybe #1 in occurance, motherboard and memory failures as #2, and pwr supply failures #3, and cpu failures last.) ok, i know the knobs to turn to solve my problems. i'm happy. i'll shutup. thanks again to all you hackers for a great os. i guess there really aren't evil space monsters invading the inner sanctum... -elh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preliminary Tuning man page (was Re: Benchmarking FreeBSD (w
: :On Fri, May 25, 2001 at 03:33:19PM -0700, John Baldwin wrote: :> Nice! One thing to note in the filesystem tuning is that newfs can :> turn on softupdates at newfs time now with -U, at least in -current. : :Stable too. ;-) : So as not to make a thousand little commits, I'll just put together a list of additional doc changes over this week and update the man pages next weekend! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Preliminary Tuning man page (was Re: Benchmarking FreeBSD (w
On Fri, May 25, 2001 at 03:33:19PM -0700, John Baldwin wrote: > Nice! One thing to note in the filesystem tuning is that newfs can > turn on softupdates at newfs time now with -U, at least in -current. Stable too. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
On Fri, May 25, 2001 at 11:21:06PM -0700, Ed Hudson wrote: > enclosed is a .jpeg of an xgraph of the following interactive test: Are you setup such that you could do the same test on a stock Red Hat 6.2, 7.0, and 7.1 box? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: technical comparison
On Sat, 26 May 2001, Peter Wemm wrote: > Which is more expensive? Maintaining an on-disk hashed (or b+tree) > directory format for *everything* or maintaining a simple low-cost > format on disk with in-memory hashing for fast lookups? I bet that for modest directory sizes the cost of disk IO outweighs the added CPU usage by so much that you may as well take the trouble of using the more scalable directory format. > For the small directory case I suspect the FFS+namecache way is more > cost effective. For the medium to large directory case (10,000 to > 100,000 entries), I suspect the FFS+namecache method isn't too shabby, > providing you are not starved for memory. For the insanely large > cases - I dont want to think about :-). The ext2 fs, which uses roughly the same directory structure as UFS and has a name cache which isn't limited in size, seems to bog down at about 10,000 directory entries. Daniel Phillips is working on a hash extension to ext2; not a replacement of the directory format, but a way to tack a hashed index after the normal directory index. This way the filesystem is backward compatible, older kernels will just use the old directory format and will clear a flag when they write to the directory, this can later be used by the new kernel to rebuild the hashed directory index. It also has the advantage of being able to keep using the tried&tested fsck utilities. Maybe this could be an idea to enhance UFS scalability for huge directories without endangering reliability ? regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: general speed differences between 4.1.1-RELEASE and 4.3-RELEASE
On Fri, 25 May 2001, Terry Lambert wrote: > So add an option to sysinstall called: > > "Fast and at least as reliable as Linux" I doubt FreeBSD would need to enable write caching in order to be as fast as Linux (which doesn't have write caching enabled in any distribution I'm aware of). ;)) The hole VM / FS write clustering thing is an area where Linux still has to catch up with FreeBSD (at least in theory FreeBSD's subsystem here is much more advanced). If, for some reason, FreeBSD _does_ turn out to be much slower than Linux (which I doubt), chances are something is just tuned wrong. All code I've seen indicates that Linux should be lagging FreeBSD in this area... (and no, reiser doesn't really count since it's not all that reliable yet ... like Matt wrote, it has a long way to go until it reaches reliability) regards, Rik -- Virtual memory is like a game you can't win; However, without VM there's truly nothing to lose... http://www.surriel.com/ http://distro.conectiva.com/ Send all your spam to [EMAIL PROTECTED] (spam digging piggy) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: technical comparison
On Sun, 27 May 2001, Doug Barton wrote: > Andrew Reilly wrote: > > > It is quite concievable that a performance tweak to the IMAP > > server could involve a header cache in a relational database of > > some sort, and that would certainly contain references to the > > individual files, which would then be accessed randomly. > > You might want to give mbox format a try. imap-uw will use this > format if you perform a few tweaks described in the documentation that > comes with it. Basically, instead of the mailbox being in plain text > it creates a type of database at the top of the file that describes > the contents. Makes access much faster for large (> 1k letters) > mailboxes. what you are suggesting sounds like something that Cyrus-IMAP already done, using Berkeley-DB ... loading up several thousand email's and sorting them takes no time ... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: technical comparison
Andrew Reilly wrote: > It is quite concievable that a performance tweak to the IMAP > server could involve a header cache in a relational database of > some sort, and that would certainly contain references to the > individual files, which would then be accessed randomly. You might want to give mbox format a try. imap-uw will use this format if you perform a few tweaks described in the documentation that comes with it. Basically, instead of the mailbox being in plain text it creates a type of database at the top of the file that describes the contents. Makes access much faster for large (> 1k letters) mailboxes. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
> As I remember, way back in the mists of 1990 when I first encountered a NeXT > box, one of the principal reasons for selecting the Mach 2.x micro kernel was > "mach messaging". This was a unified mechanism for almost all IPC both within > one host or distributed over a network, where eg. sockets (netork or unix > domain), pipes etc. were seen as abstractions of the core messaging function. > This fitted very well with the general OO design philosophy of the company. > If anyone has access to a copy of the socket(2) man page from any NeXTSTEP > version, I dimly remember there being an informative paragraph about this > point. This is mostly true, but the Mach kernel they shipped definately wasn't what I'd call a "micro kernel". It was based on the earlier CMU monolithic 4.3BSD Mach kernel. At the time, we had a source license for their kernel (at least most of; not device drivers, feh!), and this was very clear. > Whilst Mach messaging was not commonly used directly in the Unix userland > which was pretty much stock BSD 4.3, it was very important in the AppKit --- > NeXT's real stock in trade. In fact, the IPC between the appkik/user processes and the Display PostScript server really made use of this, could result in very high performance when moving large bitmapped images, etc. I would love to have a UI available these days; it was worlds better than X at the time, and frankly, still better than what we have today. The afterstep and WindowMaker guys have made some progress emulating the visual interface. But can you imagine trying to run GNOME or KDE on a 25Mhz 68030 today? louie To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Tuning, security, firewall man pages up for review
Matt Dillon <[EMAIL PROTECTED]> writes: > http://apollo.backplane.com/FreeBSD/tuning.html In the kernel config tuning section, you've misspelt NSFBUFS as NFSBUFS, which doesn't exist. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot time memory issue
Sat, May 26, 2001 at 22:03:34, barry (Barry Lustig) wrote about "Re: Boot time memory
issue":
> > > SMAP type=01 base= 0010 len= 13ef
[...]
> Did that and got the same error. I put a printf just before the
> pa_indx++ in machdep.c and watched it increment by 2's all the way up to
> 100.
>
> Any other ideas?
This code in machdep.c performs easy memory test for each page and adds
it to previous chunk or creates new one. The idea AFAIU is to test
declared memory regions for real ones. If you have >100 really different
regions in declared two memory regions, something bad happened with
your hardware: memory modules are broken, or chipset incorrectly detects
them, or yet another problem...
You can test its logic by adding following patch or similar one:
--- machdep.c.orig Sun May 27 11:12:19 2001
+++ machdep.c Sun May 27 11:13:57 2001
@@ -1785,10 +1785,12 @@
printf("Too many holes in the physical address
space, giving up\n");
pa_indx--;
break;
}
phys_avail[pa_indx++] = pa; /* start */
+ printf( "getmemsize: new chunk at %08lx\n",
+ (unsigned long) pa );
phys_avail[pa_indx] = pa + PAGE_SIZE; /* end */
}
physmem++;
}
}
/netch
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Boot time memory issue
> > > SMAP type=01 base= len= 0009f800 > > > SMAP type=02 base= 0009f800 len= 0800 > > > SMAP type=02 base= 000e8400 len= 00017c00 > > > SMAP type=01 base= 0010 len= 13ef > > > SMAP type=03 base= 13ff len= f800 > > > SMAP type=04 base= 13fff800 len= 0800 > > > SMAP type=02 base= fff8 len= 0008 > > > Too many holes in the physical address space, giving up > > > > Can you try changing the declaration of phys_avail at the top of > > sys/i386/i386/machdep.c from: > > > > vm_offset_t phys_avail[10]; > > > > to > > > > vm_offset_t phys_avail[100]; > > Did that and got the same error. I put a printf just before the > pa_indx++ in machdep.c and watched it increment by 2's all the way up to > 100. How many SMAP lines did it print? All the ones above look legitimate, and there are only 7 of them. What about the values of pa, i and physmap_idx? -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
