I want to apologize

2002-12-16 Thread Matt Dillon
Hey dudes, I want to apologize for being a total *asshole* wrt the ipfw thingie. Sorry. I know my patch was shit anyway, and that ipfw blows dead goats when compared to ipf, but even with that in mind, I had to pull a deraadt, sorry. I'm so sorry. I mean, I've had my commit bit taken away

C64 tinderbox failure

2002-12-17 Thread Matt Dillon
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree

Amiga 500 tinderbox failure

2002-12-17 Thread Matt Dillon
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree

pdp11 tinderbox failure

2002-12-17 Thread Matt Dillon
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree

VAX tinderbox failure

2002-12-17 Thread Matt Dillon
-- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree

I'm leaving the project

2002-12-17 Thread Matt Dillon
Thanks to my dear friend Warner Losh. I've decided to leave FreeBSD and flame in another project. Maybe I could join OpenBSD, the seem to share my views on how to deal with other people. I hereby give maintainership of all my code to Warner, or, whoever wants it, for that matter. Thank you,

Re: I'm leaving the project

2002-12-18 Thread Matt Dillon
On Tue, 17 Dec 2002 10:56:19 -0800 Does anyone know why this person is trying to (poorly) impersonate MD? Unfortunately not. We do not yet know who this fake Dillon is (the guy posting from that backplane.com address) I've been working hard on the new ipfw[2] patch for 5.0, the new patch is

Re: RE: Headsup! KSE Nay-sayers speak up!

2001-08-27 Thread Matt Dillon
Sheesh. Everyone is so negative! Well, I'm going to be too. I think compared to some of the other things that have been thrown into -current, the KSE stuff will be the LEAST disruptive. Don't go bashing Julian for coming up with a reasoned approach to adding them, discussing

Re: RE: Headsup! KSE Nay-sayers speak up!

2001-08-27 Thread Matt Dillon
:I'm not fundamentally opposed to KSE: I would like to see it in the system :as much as you, and am quite aware of the potential benefits. I just want :to make sure we don't go three years without a stable release to get :there. If the answer to the questions is either fine, or addressible,

Re: Headsup! KSE Nay-sayers speak up!

2001-08-27 Thread Matt Dillon
: and preferably on more than the i386 platform. If we are going to : be serious about supporting more hardware platforms, then we have : to start treating them more seriously when major changes like this : come along. If we can't get some broader testing of this done in : the next few weeks,

Re: More SIG4s during make world

2001-08-28 Thread Matt Dillon
:Hi, : :Just a quick note to say that my -current box has started dropping :cores during make world again. : :I have a kernel from August 11 that works ok, and had one from August :18 that was causing sig 4 at random places. I accidently overwrote :my Aug 18 kernel.old, but Aug 25, 27 and 28

My Recommended Development/Testing environment for -current

2001-08-28 Thread Matt Dillon
I'm posting this as an aid to everyone doing freebsd-current development and testing and may not realize how easy it is to setup a development environment. The number one thing is: Don't put the CVS tree or source code on the -current box itself, except for testing purposes.

Addendum to recommended dev/test env for -current

2001-08-28 Thread Matt Dillon
Oh, two addendums. /FreeBSD in my example is a big parition on my -stable box, not sitting on the root partition obviously. I recommend at least 3 GB. In my case I actually have the CVS tree itself, a broken-out -current source tree, a broken-out -stable source tree, NetBSD

heads-up - syscalls.master changes, MPSAFE comments, */*/trap.c:syscall()

2001-08-30 Thread Matt Dillon
(repost, it didn't like me cross-posting to the -alpha and -ia64 lists. sigh). I'm going to be comitting the following changes soon: syscalls.master: (going in now) Instead of having an MPSAFE keyword, existing keywords such as STD can be augmented with an

MFC request (was Re: symlink(2) [Was: Re: tcsh.cat])

2001-08-31 Thread Matt Dillon
This argument is just rehashing something that came up in June. Man you people have short memories! I comitted a fix to -current two months ago. It's still in my -stable tree... if Jordan gives the O.K., I will MFC it to -stable.

syscall wrapper for Giant - patch for review

2001-09-16 Thread Matt Dillon
This patch implements syscall wrappers for Giant around various subsystems. It is intended to allow more developers to work on -current, in the main tree, by allowing the various Giant pushdown works in progress to be comitted to the main tree. This patch implements sysctl

Re: FreeBSD-STABLE panics when playing DVD's

2001-09-29 Thread Matt Dillon
: :I just cvsupped to the latest stable (from a -STABLE of 2 months ago) and now :when I use vlc, or mplayer to play dvd's FreeBSD panics and reboots. I traced :the panic but since I don't have a whole lot of time to sit here on the :computer and trace kernel panics, I went the lazy man's

Re: panic: ffs_valloc: dup alloc

2001-09-26 Thread Matt Dillon
: :Hi, : :-current from Sep 23. : :After a hard power off (because the system hung while switching from X :to a virtual console) I got a panic while rebooting (background fsck :enabled): Disable background fsck. -Matt To Unsubscribe: send

Re: uucp user shell and home directory

2001-10-06 Thread Matt Dillon
In regards to UUCP as a port, I think it's a good idea. There is nothing preventing us from including the dist files in the CD distribution so network connectivity is not needed for someone to install it. If someone else puts together the port I would be happy to provide

Re: coredump() broken for nfs filesystems

2001-10-15 Thread Matt Dillon
: :coredump() now usually creates empty core files for nfs filesystems. :This seems to be caused by the changes in rev.1.132 (-current) and :rev.1.72.2.9 (RELENG_4), and braindamage in nfs_dolock(): I think if we change it to an flock() equivalent it should work. I'll play with it.

Re: Ugly, slow shutdown

2000-08-07 Thread Matt Dillon
: * Stephen McKay [EMAIL PROTECTED] [000805 08:49] wrote: : : Patch 2 is smaller and possibly controversial. Normally bufdaemon and : syncer are sleeping when they are told to suspend. This delays shutdown : by a few boring seconds. With this patch, it is zippier. I expect people : to

Re: Ugly, slow shutdown

2000-08-07 Thread Matt Dillon
Just a quick perusal of the kernel code shows a number of possible unexpected side effects from unexpected wakeups. I see several places where a 'WANTED' flag is set in a loop waiting for something and assumed to be cleared after the tsleep() returns. Some of these side effects

Congrats on the SMPng work!

2000-09-20 Thread Matt Dillon
Sniff! I feel so left out, I have so little time to play these days. You guys are all doing really exciting work, congratulations! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of

Re: entropy reseeding is totally broken

2000-10-26 Thread Matt Dillon
:In real life, machines don't always get rebooted in a completely :controlled fashion (panic, power failure, etc.). Anything that :makes a reboot longer or less reliable is a definite non-starter. : :I can guarantee you, if the current /dev/random code isn't fixed before :it makes STABLE, folks

Re: entropy reseeding is totally broken

2000-10-26 Thread Matt Dillon
:I like that, but I'd like to see more than one file. This avoids the race :where fsck may blat an incompletely written file after a (in)convenient :crash. : :We are really headed towards saving state in the first swap partition :(if there is one). :M :-- :Mark Murray :Join the anti-SPAM

Re: entropy reseeding is totally broken

2000-10-26 Thread Matt Dillon
: This would be trivial, you can use the swap allocation code (example: : see the VN device, dev/vn/vn.c) to reserve, read, and write the swap. : :Thanks! :-) : : However, I don't see much of a point in doing this. Not everyone : configures swap, so you can't count on it, and a

Re: RE: COMPAT_SVR4 broken after uipc_syscalls commit (1.77)

2000-11-23 Thread Matt Dillon
: :Okay, this time I'll even include the entire patch... : :-- Danny J. Zerkel :[EMAIL PROTECTED] Thanks Danny. I've comitted it. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: slight improvement in locore.s?

2000-11-23 Thread Matt Dillon
:might it be a very slight optimisation to change this to: :#define ALLOCPAGES(foo) \ :movlR(physfree), %esi ; \ :... :movl$((foo)*PAGE_SIZE), %eax ; \ ... but why? -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with

Re: slight improvement in locore.s?

2000-11-24 Thread Matt Dillon
My two cents: If it's assembly, and it works, and you didn't write it... then don't mess with it unless you absolutely have to. -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: current paging strategy

2000-12-04 Thread Matt Dillon
:On Mon, Dec 04, 2000 at 11:41:26PM +0100, Bernd Walter wrote: : On Mon, Dec 04, 2000 at 02:36:44PM -0700, [EMAIL PROTECTED] wrote: : what exacly do you mean with critical path, here? : : Performance critical. : Most RISC platforms are optimized for 32 and maybe 64 bit structures. : E.g. First

Re: __asm help..

2000-12-08 Thread Matt Dillon
:I'm trying to write some experimental mutex operations similar to those :in -current, but to do differnt things (e.g. a read/write lock) :however, I am having some problems with the __asm stuff. : :What I want to do is to define some operations that will :assemble down to: : pushfl :

Re: RE: __asm help..

2000-12-08 Thread Matt Dillon
:As long as gcc uses %ebp to address local variables and functoin parameters :rather than %esp you should be fine. %esp will be preserved, but if %esp is :for some odd reason used to address a variable during the C code, you are hosed. I strongly recommend against making assumptions about

Re: __asm help..

2000-12-08 Thread Matt Dillon
: : : Since all I WANT to do is : pushf : disable intr : fiddle : popf (chache hit) : : I am annoyed by the fact that I have all those extra bus cycles going on. : I can live with it for development but it still annoys me. : :You haven't yet explained how you plan to disable interrupts on the

Re: __asm help..

2000-12-08 Thread Matt Dillon
: :foo = save_intr(); disable_intr(); .. restore_intr() :has 4 extra memory accesses. UGh. I put my foot in it. Let me qualify my remark... memory accesses that cause an L1 cache miss are a problem. Memory accesses to locations written to by other cpu's are a problem. Memory

Re: Bootstrapping issues with groff(1)

2000-12-08 Thread Matt Dillon
:Ruslan Ermilov wrote: : : The attached patches (p4 and p5) try to solve this bootstrapping : problem with groff(1). : :Sorry, I missed this statement before. What exactly are the :bootstrapping problems you're seeing? : :-- :Marcel Moolenaar : mail: [EMAIL PROTECTED] / [EMAIL PROTECTED] :

Re: panic: vm_pageout_flush: partially dirty page

2000-12-10 Thread Matt Dillon
: Hi, : :ever since this commit: ... : :dillon 2000/11/18 15:06:27 PST : : Modified files: :sys/kern vfs_bio.c vfs_cluster.c vfs_subr.c :... When you created the filesystems on which the history and spool reside, did you use any custom parameters for blocksize,

fix for pageout_flush panic (was Re: panic: vm_pageout_flush: partially dirty page)

2000-12-10 Thread Matt Dillon
: : : Hi, : :ever since this commit: ... : :dillon 2000/11/18 15:06:27 PST : : Modified files: :sys/kern vfs_bio.c vfs_cluster.c vfs_subr.c Hmm. Very odd. It's catching a fully valid file page which is marked partially dirty, less then a kilobyte in size,

Re: panic: vm_pageout_flush: partially dirty page

2000-12-10 Thread Matt Dillon
Phillipp, could you do me a favor and try this patch instead of removing the KASSERT? That is, keep the original KASSERT, apply this patch to your -current instead, and see if you still get the panic. This patch is relative to -current. What it does is clear the dirty

Re: fix for pageout_flush panic (was Re: panic: vm_pageout_flush: partially dirty page)

2000-12-10 Thread Matt Dillon
I found a second issue... just a normal write-via-mmap issue, which I think INN does. If you mmap() a file fragment and write to it via the mmap(), m-dirty is set to VM_PAGE_BITS_ALL (0xFF). the normal buffer flush will only clear the dirty bits on the page associated with the

patch #3 (was Re: panic: vm_pageout_flush: partially dirty page)

2000-12-11 Thread Matt Dillon
Hi Phillipp. I couldn't find a quick fix so I recommend using the very first patch I sent you that changes the KASSERT that was causing the panic. I am comitting a slight variation of that patch to current now and stable in two days. The KASSERT was being a little too

Re: RE: __asm help..

2000-12-11 Thread Matt Dillon
: :But if gcc breaks that assumption, that implies it would break :alloca(), and presumably they wouldn't do that. : :Tony. :-- :f.a.n.finch[EMAIL PROTECTED][EMAIL PROTECTED] :"Dead! And yet there he stands!" alloca() is a GCC internal function, not a piece of __asm code.

Re: rpc.lockd and true NFS locks?

2000-12-14 Thread Matt Dillon
:I'm not going to take such an action w/o the blessing of -core. :) : :-- :David Cross | email: [EMAIL PROTECTED] :Lab Director | Rm: 308 Lally Hall In regards to Jordan's message just a moment ago... you know, I *total* forgot

Re: is it possible to have a NULL procp for an NFS request?

2000-12-22 Thread Matt Dillon
:Matthew Jacob [EMAIL PROTECTED] writes: : Hmm. The client wasn't following symlinks. : :You sure? What happens is when you queue up an nfs operation provoked :by following a symlink. I couldn't figure any other way of making :that happen. : : The patch seems simple enough, but it probably

Problem building -current kernel with read-only /usr/src.

2000-12-23 Thread Matt Dillon
While trying to run 'make depend' in /usr/src/sys/compile/BLAH I got: === 3dfx @ - /FreeBSD/FreeBSD-current/src/sys ln: @: Read-only file system *** Error code 1 Stop in /FreeBSD/FreeBSD-current/src/sys/modules/3dfx. *** Error code 1 It looks like it's trying to mess around with

Re: Problem building -current kernel with read-only /usr/src.

2000-12-23 Thread Matt Dillon
: :On Sat, Dec 23, 2000 at 12:24:51AM -0800, Matt Dillon wrote: : While trying to run 'make depend' in /usr/src/sys/compile/BLAH I got: : : === 3dfx : @ - /FreeBSD/FreeBSD-current/src/sys : ln: @: Read-only file system : *** Error code 1 : : :Wouldn't using the buildkernel/installkernel

Re: Problem building -current kernel with read-only /usr/src.

2000-12-23 Thread Matt Dillon
: : While trying to run 'make depend' in /usr/src/sys/compile/BLAH I got: : : === 3dfx : @ - /FreeBSD/FreeBSD-current/src/sys : ln: @: Read-only file system : *** Error code 1 : : Stop in /FreeBSD/FreeBSD-current/src/sys/modules/3dfx. : *** Error code 1 : : It looks like it's trying

found the fragger. Re: Problem building -current kernel with read-only /usr/src.

2000-12-23 Thread Matt Dillon
Ok, I found it. /usr/src/sys/conf/Makefile.i386 is broken. It looks like either you or David O'Brien (I'm guessing, your guys names are prominent in the CVS logs but I haven't tracked it down exactly) screwed up the object directory creation while trying to optimize it. It

Re: found the fragger. Re: Problem building -current kernel with read-only /usr/src.

2000-12-23 Thread Matt Dillon
:I will fix it today. : Thanks a lot Dave! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: Problem building -current kernel with read-only /usr/src.

2000-12-23 Thread Matt Dillon
: : Actually, last time I checked, I think stable did not install with a RO : /usr/src either. Anyone know if this is still the case? : :I have installed -stable many times with /usr/src mounted readonly :via NFS. : :Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] Yah, -stable is fine.

Re: Problem building -current kernel with read-only /usr/src.

2000-12-24 Thread Matt Dillon
:On Sat, Dec 23, 2000 at 11:24:50AM -0800, Matt Dillon wrote: : :I will fix it today. Works like a charm now, thanks! My -current source is broken out on my -stable machine, so the only way to compile it is via an NFS mount to a -current machine which, for obvious reasons, needs

Re: NFS/VM panic in current with INVARIANTS

2000-12-26 Thread Matt Dillon
:Hi Matt : :I'm getting a reliable panic on CURRENT (2000/12/26) with INVARIANTS :set. I suppose I could "fix" this by taking out INVARIANTS, but it :seems to make more sense to try to get it fixed. : :The panic() is "freeing free entry", and the traceback (minus most :of the numbers) is: :

Re: NFS/VM panic in current with INVARIANTS

2000-12-26 Thread Matt Dillon
:Do you have NFS compiled in to the kernel? I've had trouble using :INVARIANTS in the kernel and NFS as a module many times - it always :panics in the zone allocation stuff. : :(Either you always need to compile modules with the same INVARIENTS :options as the kernel, or we need to fix INVARIENTS

Re: NFS/VM panic in current with INVARIANTS

2000-12-26 Thread Matt Dillon
: :Matt Dillon [EMAIL PROTECTED] writes: : I think the only real solution is to rip out the externally visible : zalloc/zfree inlines and replace them with real routines. I will happily : do this, those inlines have always been an eyesore to me and the : performance benefit

Re: NFS/VM panic in current with INVARIANTS

2000-12-26 Thread Matt Dillon
:Matt Dillon [EMAIL PROTECTED] writes: : We can't just go do an end-run around the established API as a : hack around the problem. : :I fail too se how my suggestion would change the API at all, but in :case I was unclear, diffs are below. : :/assar : Well, yes... that's essentially

Re: NFS/VM panic in current with INVARIANTS

2000-12-26 Thread Matt Dillon
:--=-=-= : :Matt Dillon [EMAIL PROTECTED] writes: : Well, yes... that's essentially what I suggested. You didn't say : anything about removing the externalized inlines, which is what you : do in your patch. Looks like a fine patch to me. : :Except it didn't work. Now here's

Re: NFS/VM panic in current with INVARIANTS

2000-12-27 Thread Matt Dillon
: :It looks like you guys got it! What is currently checked in (by Assar) :is working fine! :-) : :M Excellent news! -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message

Re: Current hangs...

2000-12-28 Thread Matt Dillon
: :I'm seeing this kind of hang about twice a day on my build-box. : :Any clues ? insights ? When did this start occuring? I committed some pageout buffer-cache-related I/O pipelining a day or two ago to -current (which has been well tested under -stable and reasonably well tested

Re: Current hangs...

2000-12-28 Thread Matt Dillon
If possible, 'print *bp' from a gdb'd kernel dump if you can. I suspect this may be related to 'bp-b_xflags BX_BKGRDINPROG'. If a bitmap is undergoing a background write and is then dirtied a second time and bawrite()n, the bawrite() will be turned into a bdwrite() (because

Re: RE: Current stalls...

2000-12-29 Thread Matt Dillon
: :I'm getting these on NFS for loopback. Can you verify that it's the same as Poul's by breaking into DDB and doing a trace ? I have very little time, but what I think may be going on is that current may be exposing a bug in the specfs fsync code related to flushing dirty

Re: RE: Current stalls...

2000-12-29 Thread Matt Dillon
: : :I'll try- lots on plate to do. : :There's a lot of iffy stuff with ithreads on alpha. But this theory of yours :doesn't match the situation where I can then still log in and ping, but that :the NFS loopback mount is still hosed. : :I went back to building across NFS and that worked mucho

Re: Current hangs...

2000-12-30 Thread Matt Dillon
A bug in specfs's fsync dating back to Kirk's original softupdates work ( which required a similar mark/scan fix to the FFS fsync ) appears to have been exposed by recent pageout peformance commits I made. I've committed a mark/scan fix to specfs's fsync, which appears to

Re: Current hangs...

2000-12-31 Thread Matt Dillon
: :Why not this: : :s = splbio(); :TAILQ_FOREACH(bp, vp-v_dirtyblkhd, b_vnbufs) { First rule when making simple bug fixes by copying working code from one source file to another is: Dont try to optimize the code on the fly. Personally speaking, I don't find the FOREACH macros

Re: Core dumps on Current Make World this morning

2001-01-02 Thread Matt Dillon
:Ta-da! : : : In message [EMAIL PROTECTED] Matthew Jacob :writes: : : Same with me. : : This sounds like a job for Captain UPDATING: : : 20010101: : ex and vi were broken by some changes to sys/queue.h. If : you have a bad vi (and are getting core dumps when building :

Re: ** HEADS UP ** world build known broken

2001-01-03 Thread Matt Dillon
:The merging of our bits into GCC 2.95.3(RC#1) took a little longer than I :suspected. I've got to head to an appointment, so the world will be broken :for a little while. : ( sky starts to fall as David O takes a coffee break at the local starbucks, remarking merrily to other patrons

Re: proposed small change to .cshrc

2001-01-09 Thread Matt Dillon
:On Tue, Jan 09, 2001 at 09:45:14AM -0800, Archie Cobbs wrote: : : +if ( `basename $SHELL` == "tcsh" ) then : +bindkey ^W backward-delete-word : +endif : :I generally test for tcsh like this: : : if ( $?tcsh ) then : bindkey ^W backward-delete-word :

Re: proposed small change to .cshrc

2001-01-09 Thread Matt Dillon
:Matt Dillon writes: : if ( $?tcsh ) then : bindkey "^W" backward-delete-word : bindkey -k up history-search-backward : bindkey -k down history-search-forward : endif : :Why do you need the 'up' and 'down' ones.. doesn't it already do that :withou

Re: proposed small change to .cshrc

2001-01-10 Thread Matt Dillon
: :On Tue, Jan 09, 2001 at 04:52:29PM -0800, Matt Dillon wrote: : : If you just hit the up or down arrow without having partial text on the : line, it works just like normal history. Once you start using it, : you will never be able to go back. : :As a side note - this is usually

Re: Head's up: Yarrow-style periodic entropy saving

2001-01-11 Thread Matt Dillon
: : For the sake of those who don't follow commit messages (shame on you!), :here's your fair warning regarding this change. This is the promised update :that periodically (every 3 minutes by default) saves 2k of randomness to a Please make the default something more reasonable, like

Re: RE: Running Linux kernel modules.

2001-01-12 Thread Matt Dillon
:To handle the multiple open problem, I'm overloading the open and :close system calls. Upon open, I call the native open, then I grovel :around in the process' open file table looking for my special file. :When I find it, I mark fp-f_nextread with a magic number, then store :a pointer to the

Re: RE: Running Linux kernel modules.

2001-01-12 Thread Matt Dillon
: : Why not just track the opens independantly in the overloading code? : :I'm not sure I know what you mean. I don't just need to track :multiple open/closes, I need to be able to hang a pointer off of :something that I can get at durning an mmap() or ioctl() syscall so :that I can tell

Re: /boot/kernel/kernel: swap_pager_getswapspace: failed

2001-01-13 Thread Matt Dillon
on allocated-but-untouched address space. :Historically, MFS would waste time copying disk blocks twice on their :way to the user, but I think this may have been fixed by Matt Dillon. : :-GAWollman Both MFS and VN have the ability to dynamically allocate and free their swap backing store

Re: HEADS-UP: await/asleep removal imminent

2001-01-17 Thread Matt Dillon
:* Alfred Perlstein [EMAIL PROTECTED] [010117 09:24] wrote: : : I'm not going to axe it for a few days, this is a really amazing : API that Matt added, the problem is utility and useage over code : complexity. : : It's just a proposal. : :I found several places where it may be useful, but I'm

Re: HEADS-UP: await/asleep removal imminent

2001-01-17 Thread Matt Dillon
::... :: ::The lock must be unwound becasue we're calling MGETHDR with M_TRYWAIT. ::If wae used M_TRY'A'WAIT the code would probably look something like ::this: : : The basic premis of using asleep()/await() is to allow you to : propogate a 'blocking condition' back up to a higher level

Re: Debugging SMP instability (was Re: HEADS-UP: await/asleep removal imminent)

2001-01-17 Thread Matt Dillon
:I did some research on this and am convinced that at least some video cards :would work as memory buffers for KTR logs. Specifically, someone mentioned :to me yesterday that their Matrox Millennium II flashes the X desktop :during startup from a previous invocation across warm boots. (I

strong recommendation re: NFS

2001-01-21 Thread Matt Dillon
Guys, I've noticed that some of you have been making noises about cleaning up the NFS macros in current. I strongly recommend that you not do this, at least not unless you want to take on a man month (or two!) worth of work debugging! In fact, I would recommend that the NFS

Re: loopback nfs hangs now propagated to -stable...

2001-01-21 Thread Matt Dillon
: :The loopback nfs hangs that have been with us for a month have now propagated :to -stable. Can you break into DDB and get a 'ps' and a kernel core? There are a bunch of things it could be, including possibly my low-memory deadlock code (which concentrated more on UFS and not so

Re: loopback nfs hangs now propagated to -stable...

2001-01-22 Thread Matt Dillon
: : : :I would, except that several attempts to get this to work have failed. It :hangs syncing disks, I couldn't get into ddbI'll keep trying as I can, :but, you know, this is really really easy to reproduce- can't you do it? : :The best I can tell you at the moment is that objcopy is in

Re: strong recommendation re: NFS

2001-01-24 Thread Matt Dillon
: :On Sun, 21 Jan 2001, Matt Dillon wrote: : : Concentrate on making the general network stack (aka TCP) and : filesystems SMP aware. Leave NFS alone for now. Please. : :If I understand correctly another item on the wishlist is TI-RPC :(so that NFS can be made IPv6 aware). What

Re: /etc/shells #include syntax support patch

2001-01-28 Thread Matt Dillon
/etc/shells is such a simple file, I don't see much of point in polluting it. There is not much of difference having a port install: target edit /etc/shells verses editing /usr/local/etc/shells. It should just edit /etc/shells.

Re: HEADS UP: installworld gotchas

2001-02-11 Thread Matt Dillon
: The new libc is incompatible with some old applications, but I'm not : too sure why. The lock was added at the end of FILE... : :The size of FILE changed, thus the old application and the new library :no longer agree about the values for stdout and stderr: : : #define stdin (__sF[0])

Re: HEADS UP: installworld gotchas

2001-02-11 Thread Matt Dillon
: : This is a major change to libc. The library maj must be bumped if you : intend to change the sizeof(FILE), or every single third party application : that uses stdio will break. : : -Matt Oh wait, is libc already bumped in current verses 4.2? If

Re: HEADS UP: installworld gotchas

2001-02-11 Thread Matt Dillon
: :I cant help but wonder why on earth we didn't have it like this from the :start: : :Index: include/stdio.h :=== :... Yah. I say commit it. Might as well, it can't hurt any worse then changing the size of FILE.

Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)

2001-02-12 Thread Matt Dillon
:In message [EMAIL PROTECTED] Matt Dillon writes: ::Would compiling the tools -static help? : :No. The tools that are deployed today are not static, and it is those :that we copy. It will also delay discovery of the incompatibility :until after the installworld is complete. I'm not sure

Re: Any Ideas

2001-02-23 Thread Matt Dillon
:Are you aware of any recent changes that would have caused this :problem? I do not believe that the soft updates changes would :have caused this problem since they were all related to `under :stress' conditions which are not applicable here. : : ~Kirk I haven't made any commits

Re: some proposals about nfsd(8)

2001-02-25 Thread Matt Dillon
: : :Hi, : :nfsd.c has the following lines: : :(void)signal(SIGQUIT, SIG_IGN); :(void)signal(SIGTERM, SIG_IGN); : :So nfsd(8) can only be killed by -9. Does this make :sense ? Unregistering withing rpcbind or portmap is :not possible, so one has to kill portmap(8) or rpcbind(8) :and restart all

Re: some proposals about nfsd(8)

2001-02-25 Thread Matt Dillon
:ok, added a comment about this. : : nfsd -r is used if you already have nfsd's : running but somehow unregistered the nfs service : from the portmapper. For example, if you killed : the portmapper and restarted it. nfsd -r simply : reregisters the service that is already

Re: make(1) benchmarks [WAS: Re: cvs commit: src/gnu/usr.bin/binutils/ar Makefile src/gnu/usr.bin/binutils/as Makefile.inc0 ...]

2001-03-06 Thread Matt Dillon
: Any updates? My quick test involving running pkg_version on a system with 92 : installed ports, which is very make-intensive operation if ports have origin : recorded, as pkg_version(1) runs `make -V' for each port, shown that : statically-compiled make is about 15% faster than

Re: harvest_interrupt=YES slows down machine

2001-03-07 Thread Matt Dillon
: causes 7750 interrupts/sec here (on a Celeron 366 overclocked to : 522). The random task takes 100% of the available cpu cycles. This : slows down cpu-bound processes by a factor of about 3.5. With a block : size of 64k instead of the default of 512, this causes only 300 : interrupts/sec.

Re: harvest_interrupt=YES slows down machine

2001-03-07 Thread Matt Dillon
: I think it would be a much better idea to cap the number of interrupts : per second the reseeder accepts. e.g. have a sysctl to set the : max and default it to something reasonable, like 200. The seeder would : thus only run 200 times a second even if A person were getting :

Re: harvest_interrupt=YES slows down machine

2001-03-07 Thread Matt Dillon
:Hmm. Sounds doable. I'll play. : : A 1/10 second sleep and a ring limit of 32 still gives you an effective : 320 seeds per second. Still overkill, but at least not the massive : overkill that its doing now. : :Event != seed. I'll juggle numbers and see if I can come up with any

Re: Ethernet entropy harvesting seriously pessimizes performance

2001-03-12 Thread Matt Dillon
Please try this patch. This should solve all the random harvesting performance issues no matter how efficient or inefficient the hash function (untested as I do not have a -current box at the moment). -Matt Index: yarrow.c

Re: Ethernet entropy harvesting seriously pessimizes performance

2001-03-12 Thread Matt Dillon
Sorry, the last patch won't patch cleanly, I forget to update my -current source before diffing. A new patch is attached, and it also includes reducing the sdize of the entropy ring from 1024 to a more reasonable 64. Mark, what I said last month still holds... you need to

Re: Ethernet entropy harvesting seriously pessimizes performance

2001-03-12 Thread Matt Dillon
: : Please try this patch. This should solve all the random harvesting : performance issues no matter how efficient or inefficient the hash : function (untested as I do not have a -current box at the moment). : :Erm, you are behind :-) : :I have already committed something that does

Re: Ethernet entropy harvesting seriously pessimizes performance

2001-03-12 Thread Matt Dillon
:Matt, : :At it is very obvious to me that you have not even looked at the new :code, let alone run it, I suggest that you do both before further :engaging in this conversation. : :M :-- :Mark Murray :Warning: this .sig is umop ap!sdn I looked at it. I'm sorry, I don't see how your

Re: Ethernet entropy harvesting seriously pessimizes performance

2001-03-12 Thread Matt Dillon
: down and will work, SNAP, just like that? : :Because I need to make folks other than you happy. : :Lots of security minded people what _all_ the interrupt entropy :they can get, and this method gives them that while allowing others :to throttle the harvester back. : :M :-- :Mark Murray

Re: RE: Ethernet entropy harvesting seriously pessimizes performance

2001-03-12 Thread Matt Dillon
Let me be clear about what I mean by interrupt rate limiting: interrupt() { harvester(...) } harvester(...) { if (queue is not full) { ... add data to queue (reasonably sized queue, like 32 entries) } } queue-runner(...) {

Re: harvest_interrupt=YES slows down machine

2001-03-12 Thread Matt Dillon
:This effectively happens. : :The harvest ring is a limited length, and any overflows are discarded. : :M :-- :Mark Murray :Warning: this .sig is umop ap!sdn Are you resending this mail from 5 dats ago or is there a bounce occuring somewhere on the list? Currently the queue size

Re: Panic and filesystem corruption

2001-03-14 Thread Matt Dillon
:I was cvsupping the GNATS database (the *entire* GNATS database, that :is - I didn't already have a copy) when I got this panic: How old a kernel are you running? Kirk and I have been attempting to locate the filesystem bitmap corruption for months. We've fixed a number of bugs

Re: Panic and filesystem corruption

2001-03-14 Thread Matt Dillon
: :On Wed, Mar 14, 2001 at 04:39:53PM -0800, Matt Dillon wrote: : : fsck all of your filesystems from single-user to remove the possibility : of 'old' corruption (as in 'fsck', not 'fsck -p'). : :So if an fsck -f doesn't bomb out, the filesystem should be in an okay :state? : :- alex

Re: Panic and filesystem corruption

2001-03-17 Thread Matt Dillon
:Matt Dillon [EMAIL PROTECTED] writes: : To date nearly all the reported corruption has been to directories : and not to file contents. Does this hold for you as well? Only : the directory was corrupted and not any files? : :Umm, the end of the cvsup log was padded with zeroes

  1   2   >