Re: disklabel differences FreeBSD, DragonFly

2006-07-28 Thread Matthew Dillon
. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail

Re: disklabel differences FreeBSD, DragonFly

2006-07-30 Thread Matthew Dillon
: :* Matthew Dillon ([EMAIL PROTECTED]) wrote: : : felt that 8 partitions is restrictive. My main home server has 10 : and the main DragonFly box has 11. : : There is another solution for FreeBSD folks, however. You *DO* have : four slices to play with. You can put

Re: disklabel differences FreeBSD, DragonFly

2006-07-30 Thread Matthew Dillon
: : Dmitry == Dmitry Marakasov [EMAIL PROTECTED] writes: : :Dmitry * Matthew Dillon ([EMAIL PROTECTED]) wrote: : felt that 8 partitions is restrictive. My main home server has 10 : and the main DragonFly box has 11. : : There is another solution for FreeBSD folks, however. You *DO* : have four

Re: [patch] rm can have undesired side-effects

2006-11-04 Thread Matthew Dillon
scratching my head a bit. This may be just as broken as before, just in a different (and safer) way. -Matt Matthew Dillon [EMAIL PROTECTED

Re: Yet another magic symlinks implementation

2006-11-04 Thread Matthew Dillon
It is interesting to note that DragonFly has had variant symlnks for a long time, but we haven't actually found a use for them yet. No smoking killer app has presented itself. We use varsyms in our RC implementation kind of like uber-environment variables (rclist, rcstart,

Re: [patch] rm can have undesired side-effects

2006-11-04 Thread Matthew Dillon
:... :BSD behaviour: :- OpenBSD handles hardlinks since 3.3: : -P Overwrite regular files before deleting them. Files :are overwritten three times, first with the byte pattern :0xff, then 0x00, and then 0xff again, before they are :deleted. Files

Re: vn_fullpath question.

2006-11-28 Thread Matthew Dillon
. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail

Re: Syncing cpus on a multi-cpu, dual core system

2006-12-16 Thread Matthew Dillon
The TSCs for each individual cpu core can drift relative to each other, even on multi-core chips like AMD X2s. This only effects code which uses the TSC, which isn't a whole lot. They need to be synchronized with each other (by calculating the drift and correcting for it) when

Re: msleep() on recursivly locked mutexes

2007-04-27 Thread Matthew Dillon
The real culprit here is passing held mutexes to unrelated procedures in the first place because those procedures might have to block, in order so those procedures can release and reacquire the mutex. That's just bad coding in my view. The unrelated procedure has no clue as to

Re: GPT - (last) call for action

2007-06-09 Thread Matthew Dillon
I'm having to tackle this issue right now in DFly. With GPT having to start at sector 1 (no choice there), the compatible MBR in sector 0 presumably must have a slice (#1) which covers the entire disk. But do we have to make slice #1 bootable? Could we also create a slice #2

Re: GPT - (last) call for action

2007-06-10 Thread Matthew Dillon
. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo

Re: GPT - (last) call for action

2007-06-10 Thread Matthew Dillon
:No. :The first partition is the EFI GPT (0xee): : :% fdisk -1 :*** Working on device /dev/ad0 *** :... :parameters to be used for BIOS calculations are: :cylinders=116280 heads=16 sectors/track=63 (1008 blks/cyl) : :Media sector size is 512 :Warning: BIOS sector numbering starts with

Re: GPT - (last) call for action

2007-06-11 Thread Matthew Dillon
to point the MBR at sector 40. The more I think about it, the more sense it makes. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd

Re: Reason for doing malloc / bzero over calloc (performance)?

2007-06-14 Thread Matthew Dillon
for allocations up to and including PAGE_SIZE*2 bytes. Fun, eh? -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org

Re: rewrite src/sys/i386/i386/in_cksum.c

2007-07-11 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: add closefrom() call

2007-07-11 Thread Matthew Dillon
We added it basically because doing all the junk described in previous postings in this thread in userland is a ridiculously huge eyesore that doesn't scale and doesn't make sense when 5 minutes of programming nets you a shiny new system call which does it all for you. If you

Re: Tar output mode for installworld

2007-07-17 Thread Matthew Dillon
booting the live CD so those bits don't have to be re-read. Doing a direct copy has always felt 'faster' to me then unpacking split up tar files. -Matt Matthew Dillon

Re: [Re: [Re: coarse vs fine-grained locking in SMP systems]]

1999-06-27 Thread Matthew Dillon
Here's the basic problem: The kernel is currently designed for single-threaded operation plus interrupt handling. A piece of code in the kernel can temporarily disable certain interrupts with the spl*() codes to cover situations where a race on some system resource might

Re: restricted kernel threads implementation from NetBSD via newconfig

1999-06-28 Thread Matthew Dillon
test case for us because it will be fairly easy to port and fairly easy to measure performance under load. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send

Re: RE: Implementation of mmap() in FreeBSD

1999-06-28 Thread Matthew Dillon
: [ML] It is possible to handle these cases in VM code, by : trapping on any access to the partial page, and allowing only those : accesses which are withing the originally requested range. Performance : would suck without end, though. : :Well it would only suck for access to that page

Re: bug in latests NFS patches for -stable

1999-06-29 Thread Matthew Dillon
. -Matt Matthew Dillon [EMAIL PROTECTED] :Matt, :If you agree with this patch to your patch :I'll commit the NFS fixes to 3.x :(I'll also add this change to the 4.0 version.) : :*** hold/nfs_serv.cTue Jun 22 13:37

Re: Microsoft performance (was: All this and documentation too? (was: cvs commit: src/sys/isa sio.c))

1999-06-30 Thread Matthew Dillon
:[...] : :I guessed I freaked some people out when I declared that I wanted to :work on the VM system, discussions in the first few months went with :half of core talking to me like I didn't know jack when I do know at :least jack, but had to come up to speed on

Re: mmap question

1999-07-05 Thread Matthew Dillon
under the program's control. Thus most programs using mmap() simply map the file's full size and do not try to do anything fancy. : Kelly : ~[EMAIL PROTECTED]~ -Matt Matthew Dillon

Re: kern/11222

1999-07-06 Thread Matthew Dillon
that would cut NFS stat traffic in half. I find it rather humorous that I always spend hours testing things that other committers would commit without any testing whatsoever. -Matt Matthew Dillon

Re: Bursting at the seams (was: Heh heh, humorous lockup)

1999-07-08 Thread Matthew Dillon
. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Strange select/poll behaviour [EBADF inconsistancy]

1999-07-08 Thread Matthew Dillon
for one of those descriptors that should return EBADF! -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-ha

Re: Strange select/poll behaviour [EBADF inconsistancy]

1999-07-08 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: a BSD identd

1999-07-11 Thread Matthew Dillon
: 2. Most shell services do a good job of keeping ident reliable. They need : to do that because most IRC networks heavily penalize clients that don't : return any ident. : :This is changing. In the face of ${BIGNUM} Windoze boxes giving ident :answers like "HAX0r", there is little point, except

Re: a BSD identd

1999-07-11 Thread Matthew Dillon
:How in the world could my inetd ident service be exploited? I just fixed :the only problematic feature, fake id, to make it not read anything but a :regular file and not let you try to use someone else's name. I can't see :any way that any part of it could be exploited... Typically the

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
This topic has been rehashed a thousand times. What it comes down to is that if you want to disallow overcommit, you have to multiply the amount of swap space in the system relative to current levels in order to get the same performance limits as you had before. If you

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
:How hard would it be to add a sysctl variable that controlled whether or not :the system would overcommit memory? : :-Archie : :___ :Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com Archie,

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
: :On Tue, 13 Jul 1999 11:59:25 -0700 (PDT) : Matthew Dillon [EMAIL PROTECTED] wrote: : : We could have the ability to mark processes as being more or less : preferable as kill candidates. I'm not sure I really care anymore, : though... there is so much disk space available now

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
: : On Tue, 13 Jul 1999 11:13:49 -0700 (PDT), : Matthew Dillon [EMAIL PROTECTED] said: : : Doh! Even solaris doesn't overcommit - you think it actually : reserves data blocks for its file-backed swap? Bzzt! It uses : an overcommit model too. : :Unlike 4.4BSD derived VM

Re: more amd hangs: problem really in syslog?

1999-07-13 Thread Matthew Dillon
the lockup -- you could even try turning off all logging (but leaving syslog running, i.e. turning it into a sink-null) to see if that has an effect. -Matt Matthew Dillon

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
the kernel. :... :-Archie -Matt Matthew Dillon [EMAIL PROTECTED] :___ :Archie Cobbs * Whistle Communica

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
: :On Tue, 13 Jul 1999 14:27:54 -0700 (PDT) : Matthew Dillon [EMAIL PROTECTED] wrote: : : You are assuming that the situation actually occurs. In real life, : it will not occur unless the critical server is running away with : memory. : : I have never, ever run one

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
the UNIX libc builtins. The UNIX libc bulitins properly assume a more general machine configuration and it would not be appropriate to use them for embedded work if memory use is an issue. -Matt Matthew Dillon

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
:Jason Thorpe wrote: : : On Tue, 13 Jul 1999 14:14:52 -0700 (PDT) : Matthew Dillon [EMAIL PROTECTED] wrote: : : If you don't have the disk necessary for a standard overcommit model to : work, you definitely do not have the disk necessary for a non-overcommit : model to work

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
:On Tue, 13 Jul 1999 15:12:14 -0700 (PDT) : Matthew Dillon [EMAIL PROTECTED] wrote: : : The text size of a program is irrelevant, because swap is never : allocated for it. The data and BSS are only relevant when they : are modified. : :Bzzt. BSS is relevant when accessed

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
ctical. Heh heh. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
:On Tue, 13 Jul 1999 16:24:53 -0700 (PDT) : Matthew Dillon [EMAIL PROTECTED] wrote: : : I'm sure the feeling is mutual. More to the point, I really seriously : doubt that any of the core developers would consider this idea either : because it's been rejected in the past and, so

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-13 Thread Matthew Dillon
: :On Tue, 13 Jul 1999 16:56:26 -0700 (PDT) : Matthew Dillon [EMAIL PROTECTED] wrote: : : You have to consider the probability of an event occuring, not just : the possibility that the event might occur. If the probability is : one in a million years, then it is not something

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
e runaways are common enough to cause a problem. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hacke

Re: Replacement for grep(1) (part 2)

1999-07-13 Thread Matthew Dillon
: On Tue, 13 Jul 1999 17:25:21 -0700 (PDT), : Matthew Dillon [EMAIL PROTECTED] said: : : With today's modern high capacity disk drives, a properly configured : multi-user system will have enough swap that running it out is difficult : to say the least. : :That's wrong. :Please

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-13 Thread Matthew Dillon
? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-13 Thread Matthew Dillon
x datasize limit -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
but they would do a lot better with a watchdog script. It makes no sense to try to build it into the kernel. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send

Re: tcp windowsize query?

1999-07-14 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
resort mechanisms to keep your machines running. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
. If the system starts to page (which this person's system is obviously doing), then it is doubly a bad idea to allow a named to grow that large. -Matt Matthew Dillon

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Matthew Dillon
:On Tue, 13 Jul 1999 23:18:58 -0400 (EDT) : John Baldwin [EMAIL PROTECTED] wrote: : : What does that have to do with overcommit? I student administrate a undergrad : CS lab at a university, and when student's programs misbehaved, they generate a : fault and are killed. The only machines

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
principles. It would work as well in an overcommit system as it would in a non-overcommit system. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
: : Quite true. In the embedded world we preallocate memory and shape : the programs to what is available in the system. But if we run out : of memory we usually panic and reboot - because the code is designed : to NOT run out of memory and thus running out of memory is a

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
-Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Matthew Dillon
r whatever it is that has your shorts all tied :up in a knot. : :--- :Garance Alistair Drosehn = [EMAIL PROTECTED] :Senior Systems Programmer or [EMAIL PROTECTED] -Matt Matt

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-14 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit

1999-07-14 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Replacement for grep(1) (part 2)

1999-07-14 Thread Matthew Dillon
t close to using all available swap, the other subsystems would be up the creek anyway so, really, it doesn't make much sense hacking the source to allow the subsystem to run into the wall anyway. -Matt

Re: tcp windowsize query?

1999-07-15 Thread Matthew Dillon
in order to get better interactive performance. e.g. working over a remote connection while at the same time downloading a big tar file via ftp or a browser. -Matt Matthew Dillon

Re: Advice on deriving accurate time values from the kernel?

1999-07-15 Thread Matthew Dillon
loop and collect statistics that way. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
-Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
tially swappable space. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
occurs ). Do a pstat -s before, after the initial touch, and after the fork. If you do not see the reserved swap space jump by 32MB after the fork, it isn't what you thought it was. -Matt Matthew Dillon

Re: 650 MB MFS?

1999-07-15 Thread Matthew Dillon
at you can then mount and use normally. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hacke

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
doesn't change ). 439MB of swap verses 12MB of swap. In that scenario, the 512MB of swap I assigned to this machine would be dangerously low. -Matt Matthew Dillon

Re: Swap overcommit

1999-07-15 Thread Matthew Dillon
that are still running no longer being stable. As a sysop, I would reboot a system in such a state instantly. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
to disable overcommit. : :--lyndon If your machines aren't going to run out of swap, then the overcommit isn't going to hurt you in a million years. -Matt Matthew Dillon

Re: Swap overcommit

1999-07-15 Thread Matthew Dillon
and not set errno properly if errno was already set, but a perusal of the kernel code seems to indicate that this can't happen. Very weird. -Matt Matthew Dillon [EMAIL

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-15 Thread Matthew Dillon
files or swap partitions? Or is it that weird /tmp filesystem stuff? If it normally uses swap files and allows holes then that explains everything. -Matt Matthew Dillon

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-16 Thread Matthew Dillon
are certified for any of that stuff that I know of. What's next: A space shot? These what-if scenarios are getting ridiculous. -Matt Matthew Dillon [EMAIL PROTECTED

Re: Swap overcommit (was Re: Replacement for grep(1) (part 2))

1999-07-16 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] :take great care to gracefully handle these exceptions. All the C :programs that we've ever written also take great care in handling :NULL returns from malloc. : :I have no problem

Re: poor ethernet performance?

1999-07-16 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: poor ethernet performance?

1999-07-16 Thread Matthew Dillon
-Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: poor ethernet performance?

1999-07-16 Thread Matthew Dillon
. -Matt Matthew Dillon [EMAIL PROTECTED] :Cheers, :Vince - [EMAIL PROTECTED] - [EMAIL PROTECTED] __ To Unsubscribe: send mail to [EMAIL PROTECTED

Re: poor ethernet performance?

1999-07-16 Thread Matthew Dillon
: I know, I'm just wondering how did they get more frequency out of :wire of the same size. I can understand it if the wire was a larger :guage. For twisted pair, Less power == less crosstalk. Plus the higher bandwidth transceivers use better receivers and better pre-attenuation

Re: Replacement for grep(1) (part 2)

1999-07-17 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: softupdates on root partition, no floppy

1999-07-17 Thread Matthew Dillon
' and reboot. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: USFS (User Space File System)

1999-07-17 Thread Matthew Dillon
Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: USFS (User Space File System)

1999-07-19 Thread Matthew Dillon
difficult except for the mmap() piece. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" i

Re: RE: Overcommit and calloc()

1999-07-19 Thread Matthew Dillon
assume that the data buffer returned by malloc() is already clear. Since calloc() is not usually used to allocate large chunks of memory, this isn't a problem. -Matt Matthew Dillon

Re: speed of file(1)

1999-07-19 Thread Matthew Dillon
is different, but almost the same size. : :Why is FreeBSD's file so much slower? : :Leif : : : : :To Unsubscribe: send mail to [EMAIL PROTECTED] :with "unsubscribe freebsd-hackers" in the body of the message : Matt

Re: Anything special with kmem_map and mb_map?

1999-07-19 Thread Matthew Dillon
submaps? : :Thanks for any help. : :-Zhihui The kmem_map and mb_map's can be modified from interrupts. The other maps cannot. -Matt Matthew Dillon [EMAIL PROTECTED

Re: USFS (User Space File System)

1999-07-20 Thread Matthew Dillon
: :David, : : Unless I am misunderstanding you, mfs does what you are :describing. : : --John No, MFS runs in supervisor mode. That mfs process that you see hanging there is just placemarking the VM space. -Matt To

Re: RE: Overcommit and calloc()

1999-07-20 Thread Matthew Dillon
cpu-bound, there is no cost to the kernel to zero memory because it pre-zero's pages in its idle loop. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail

Re: USFS (User Space File System)

1999-07-20 Thread Matthew Dillon
: :Matthew Dillon [EMAIL PROTECTED] wrote: : : : No, MFS runs in supervisor mode. That mfs process that you see hanging : there is just placemarking the VM space. : : -Matt : : : Well, I think there is a little more to it than that. I

Re: USFS (User Space File System)

1999-07-20 Thread Matthew Dillon
store is being implemented by MFS as a dummy block device. MFS simply copies the data to and from the VM space of the mfs process. -Matt Matthew Dillon [EMAIL PROTECTED

Re: poor ethernet performance?

1999-07-21 Thread Matthew Dillon
:Perhaps I'm missing something obvious, but since switches forward packets :selectively per port, I would think it would be hard to sniff packets on :any port, w/o administrative access to the switch to tell it to mirror :data to a different port. : :ie, if I'm plugged into port 1, I can't see

Re: speed of file(1)

1999-07-21 Thread Matthew Dillon
Nice rundown of the problem! I presume someone is going to commit this... -Matt Matthew Dillon [EMAIL PROTECTED] :*** file/apprentice.c Wed Jan 28 07:36:21 1998

Re: understanding code related to forced COW for debugger

1999-07-21 Thread Matthew Dillon
more about it. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Anyone know how to dim and SGI flat panel?

1999-07-21 Thread Matthew Dillon
dandy - except it's so bright it's burning holes in my eyes at night :-( Anyone who has one of these things know how its done? Thanks! -Matt Matthew Dillon

Re: FreeBSD: the stealth OS?

1999-07-22 Thread Matthew Dillon
-Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

Re: Anyone know how to dim and SGI flat panel?

1999-07-22 Thread Matthew Dillon
. Ah, the XFree ftp finished. Hmm. the DPMS stuff looks promising but I don't see an I128 port yet. Shoot. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail

Re: Squid - a bug in src/sys/kern/uipc_socket.c

1999-07-22 Thread Matthew Dillon
-then-full-sized TCP packet occassionally in a stream but that's about it. I think committing this would be beneficial. Would someone w/ commit privs care to review and then commit this bit? -Matt Matthew

Re: Proposal for new syscall to close files

1999-07-22 Thread Matthew Dillon
:Hi, : : I like this approach. I have a number of often spawned daemon :processes that could benefit from this. One of the last process :we debugged where we had unwanted open filedescriptors was in :programs invoked by the cvs loginfo script. : : For naming convention considerations, I might

Re: RE: Squid - a bug in src/sys/kern/uipc_socket.c

1999-07-22 Thread Matthew Dillon
: :It's been committed before, and broke many things (X and CVSup come to :mind). I have it compiled in locally on a few machines but it's :definitely not suitable for general distribution until a solution is :found that doesn't break applications. : :Jason Young :accessUS Chief Network Engineer

Re: RE: Squid - a bug in src/sys/kern/uipc_socket.c

1999-07-22 Thread Matthew Dillon
::It's been committed before, and broke many things (X and CVSup come to ::mind). I have it compiled in locally on a few machines but it's ::definitely not suitable for general distribution until a solution is ::found that doesn't break applications. :: ::Jason Young ::accessUS Chief Network

New patch fpr uipc_socket.c (was Squid - a bug in src/sys/kern/uipc_socket.c)

1999-07-22 Thread Matthew Dillon
I believe this will solve the previously reported problems. With the original patch if I set net.inet.tcp.sendspace=63 and tried to run xterm from that machine to my local workstation, I got an X error. If I set sendspace=31 the xterm process just locked up and did nothing

Re: mbuf leakage in NFSv3 writes, possbile?

1999-07-23 Thread Matthew Dillon
is likely to be real. There is a good chance the leakage is in nfs_serv.c, which I fixed for -current. I do not think those changes have been backported to -STABLE. -Matt Matt

Re: FreeBSD: the stealth OS?

1999-07-23 Thread Matthew Dillon
same first name? -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message

  1   2   3   4   5   6   7   8   9   10   >