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
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,
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
I mean, WTF? 14 people answered what was nothing but a *blatant* troll! Come on, even
Rick 'shittiest VM subsystem' van Riel answered! What can I say, pathetic, simply
pathetic. No wonder FreeBSD is dead. I'm just talking on behalf of myself and my 3
friends, Bavid O'Drien, Piten Handya, and
:
:I have a potentially silly question about contigmalloc1(), if the very
:unlikely occurance that the kernel VM space ran out, (the vm_map_findspace()
:failed) wouldn't we want to return the chunk of contiguous physical space
:back on the free queue before we return an allocation failure?
:
:
:The following was initially formatted as PR, but I suppose it is reasonable
:to discuss first here. There were some vague mentions that sin_zero field
:of struct sockaddr_in may be used in future for some extensions; but this
:future is already expired;) without any real step.
:If the verdict
:on the Internet has been routers costing in the $100,000 range. Now, maybe
:BEST Internet is now wealthy enough that you can blow that kind of money on
:Cisco gear without thinking about it, but a lot of smaller ISP's are not.
:
:If you look at what happened last weekend on Sunday, and the
:Mark,
:
: I also placed some checks on vm_map_delete
:
:I did that also, and as far as I understand everything works fine.
:The only thing I found was the fact that when contigmalloc() grabs the
:contig pages it sets the value of pga[i] (for i in allocated pages)
:note that: vm_page_t pga =
:Sorry about the crosspost but I estimate that this reaches those who need
:to see this..
:
:There was a change in the 4.x kernel.h on June 15 that broke backwards
:compatibility for binary distributed driver files
:(distributed as .o files) It was an MFC of a patch by peter..
:but we didn't
The Cisco 2600 series is great for T1's. A 2620 with a T1 card (it
can take up to two) and you are done. The 2501's are ancient, don't
even bother any more. You can find 2620's on EBay in the $700-$1500
range, many of which appear (in my quick look) to include a T1 card.
:We are currently working with FreeBSD 4.3 and we found out that
:kldloading/kldunloading modules working with contigmalloc()/contigfree()
:like if_xl.ko produces a memory leak.
:
:This is due to the contigfree() function which seems to uncompletely release
:the memory ressource allocated in
:
:On Tue, 2 Oct 2001, Matt Dillon wrote:
:
:
: :
: :Dwayne wrote:
: : I'm creating an app where I want to use memory to store data so I
: : can get at it quickly. The problem is, I can't afford the delays that
: : would occur if the memory gets swapped out. Is there any way in FreeBSD
Well, I've gone through hell trying to fix the rename()/rmdir()/remove()
races and failed utterly. There are far more race conditions then even
my last posting indicated, and there are *severe* problems fixing NFS
to deal with even Ian's suggestion... it turns out that NFS's
:
:It seems like there's no activity on this subject.
:This is local DoS, guys. if it gets on public (which is probably gonna
:be soon) everything everywhere will be crashing, and there's no stable
:fix ready.
:How can i help to accelerate this problem solution?
:
: And why FreeBSD security
:The rename routine is probably the most convoluted in the entire file
:system code (FFS). Now that everybody's memory is fresh, I would like to
:ask something about it:
:
:(1) I am always wondering why not use a global rename lock so that there
:is only one rename operation in progress at
:The addition of the SOFTLOCKLEAF code is quite a major change, so
:it would be very useful if you could describe exactly what it does,
:what its semantics are, and how it fits into the rename problem.
Setting SOFTLOCKLEAF in namei will set the VSOFTLOCK flag in the
returned vnode
I recommend using cpdup ( /usr/ports/sysutils/cpdup ), mainly because
you can ^C it and restart it at any time so it's a lot easier to
play around with your directory dup'ing.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with
Ok, I'm adding -hackers... another email thread got going in -committers.
Here is a patch set for -stable. It isn't perfect but it does appear
to solve the problem. The one case I don't handle right is if you have
a hardlinked file and two renames in two different directories
Here is the latest patch I have. It appears to completely solve the
problem. I have shims in unionfs and nfs for the moment.
The patch is against -stable.
* Implements SOFTLOCKLEAF namei() option
* Implements EAGAIN error appropriate tsleep/retry code
* Universal
:
:Matt Dillon wrote:
: Here is the latest patch I have. It appears to completely solve the
: problem. I have shims in unionfs and nfs for the moment.
:
:This seems rather large compared to Ian Dowse's version.. Are you sure that
:you're doing this the right way? Adding a whole new
:
:Dwayne wrote:
: I'm creating an app where I want to use memory to store data so I
: can get at it quickly. The problem is, I can't afford the delays that
: would occur if the memory gets swapped out. Is there any way in FreeBSD
: to allocate memory so that the VM system won't swap it
:The problems all arise from the fact that we unlock the source
:while we look up the destination, and when we return to relookup
:the source, it may have changed/moved/disappeared. The reason to
:unlock the source before looking up the destination was to avoid
:deadlocking against ourselves on
: Second, application not always grows to 1G, most of the time it keeps
: as small as 500M ;). Why should we precommit 1G for 500M data? Doing
: multi-mmap memory management is additional pain.
Why not? Disk space is cheap. For a problem like this I would simply
throw in two 30G+
:
:In message [EMAIL PROTECTED], Matt Dillon writes:
:: Second, application not always grows to 1G, most of the time it keeps
:: as small as 500M ;). Why should we precommit 1G for 500M data? Doing
:: multi-mmap memory management is additional pain.
:
:Even using file-backed memory
You definite need to use a microcontroller. Something like the
68HC11F1 is a good single-chip solution (though the F1 only has
512 bytes of E^2). I'm sure Motorola has newer chips with more
on-board E^2.Stepper motors can be manipulated from a PC parallel
port but you will
: :Poul-Henning Kamp | UNIX since Zilog Zeus 3.20
: :[EMAIL PROTECTED] | TCP/IP since RFC 956
:
: I think the file descriptor problem can be solved easily... simply
: open the file, mmap() the entire 1G segment for this special application,
: and then close() the file.
: overcommit? I've always wanted the ability to turn off overcommit
: for exactly the same reasons you do.
:
:FWIW: Tru64 has had this capability since day one. You can select
:swap-overcommit mode by removing a symlink (/sbin/swapdefault - /dev/foob)
:were /dev/foob is the primary swap
:--Boundary_(ID_mQ1p0DshiB00ke/hmU0cHA)
:Content-type: text/plain; charset=us-ascii
:Content-transfer-encoding: 7BIT
:
:When an app binds an address and port to a listen socket, what
:variables
:can I adjust so the address may be reused immediately after the app
:exits.
:My understanding was
:@@ -721,9 +721,9 @@
: }
: }
:
:- while (vp-v_numoutput 0) {
:- vp-v_flag |= VBWAIT;
:- tsleep(vp-v_numoutput, PVM, vnvlbv, 0);
:+ if (VOP_GETVOBJECT(vp, object) == 0) {
:+ while (object-paging_in_progress)
:+
:
:On Sunday, 23rd September 2001, Poul-Henning Kamp wrote:
:
:Things to look out for:
:
:1. !ufs filesystems
:
:I am irredeemably slack for not testing this a lot but...
:
:I believe I saw bad interactions between vmiodirenable and isofs on 4.3-R.
:
:I mounted a CD, looked at stuff on it, did a
I totally forgot about that one. Your fix looks good, I'll start testing
it.
The bigger picture here is that vinvalbuf() is not typically called
while a vnode is still active. NFS calls it on active vnodes in order
to invalidate the cache when the client detects that the
:
:Then I suggest the following to be changed:
:
:#
:# This file is read when going to multi-user and its contents piped thru
:# ``sysctl'' to adjust kernel values. ``man 5 sysctl.conf'' for details.
:#
:
:# $FreeBSD: src/etc/sysctl.conf,v 1.5 2001/08/26 02:37:22 dd Exp $
:
:Ok, time to take a good stab at sticking my foot in my mouth here.
:
:Would it be possible to have a kernel mode where the read-only bit was
:turned on for malloc pools which shouldn't currently be accessed? This
:could be gated through the spl() calls (or specific mutexes on -current),
:I had been contemplating making a fake 'struct user' in userland only in
:order to keep the a.out coredump reader code happy. The a.out coredump
:code (see cpu_coredump() in */*/vm_machdep.c) can generate this fake
:structure in order to keep gdb happy. But then I realized that a.out
:coredump
:So, Matt, does this solve the original question? (VM Corruption) or
:is it just a fruitful red-herring?
:--
:++ __ _ __
:| __--_|\ Julian Elischer | \ U \/ / hard at work in
It seems unlikely to me, but you never know.
I really don't think it is necessary to hack up GCC to figure
out stack utilization. We have issues with only a few drivers
and it is fairly trivial (as my patch shows) to throw a pattern
into the kernel stack to determine how much is actually used.
Ok, here is the second set of results. I didn't run all the tests
because nothing I did appeared to really have much of an effect. In
this set of tests I set MAXMEM to 128M. As you can see the buildworld
took longer verses 512M (no surprise), and vmiodirenable still helped
:
:In message [EMAIL PROTECTED], Matt Dillon writes:
:
:$8 = 58630
:(kgdb) print vm_page_buckets[$8]
:
:What is vm_page_hash_mask? The chunk of memory you printed out below
:looks alright; it is consistent with vm_page_array == 0xc051c000. Is
:it just the vm_page_buckets[] pointer
:The pointers in the last few entries of the vm_page_buckets array got
:corrupted when an agument to a function that manipulated whatever was next
:in ram was 0, and it turned out that it was 0 because
: of some PTE flushing thing (you are the one that found it... remember?)
:
:I think I've also
:
:remember that we hit almost this problem with the KSE stuff during
:debugging?
:
:The pointers in the last few entries of the vm_page_buckets array got
:corrupted when an agument to a function that manipulated whatever was next
:in ram was 0, and it turned out that it was 0 because
: of some
:In message [EMAIL PROTECTED], Matt Dillon writes:
:
:Hmm. Do we have a guard page at the base of the per process kernel
:stack?
:
:As I understand it, no. In RELENG_4 there are UPAGES (== 2 on i386)
:pages of per-process kernel state at p-p_addr. The stack grows
:down from the top
:
:In message [EMAIL PROTECTED], Matt Dillon writes:
:
:Hmm. Do we have a guard page at the base of the per process kernel
:stack?
:
:As I understand it, no. In RELENG_4 there are UPAGES (== 2 on i386)
:pages of per-process kernel state at p-p_addr. The stack grows
:down from the top
:What happens on an ECC equipped PC when you have a multi-bit memory
:error that hardware scrubbing can't fix? Will there be some sort of
:NMI or something that will panic the box?
:
:I'm used to alphas (where you'll get a fatal machine check panic) and
:I am just wondering if PCs are as safe.
:
:I did it as part of the KSE work in 5.x. It would be quite easy to do it
:for 4.x as well, but it makes a.out coredumps problematic.
:
:Also, options UPAGES=4 is a pretty good defensive measure.
:
:Cheers,
:-Peter
:--
:Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
:Oh, one other thing... When we had PCIBIOS active for pci config space
:read/write support, we had stack overflows on many systems when the SSE
:stuff got MFC'ed. The simple act of trimming about 300 bytes from the
:pcb_save structure was enough to make the difference between it working or
This isn't perfect but it should be a good start in regards to
testing kstack use. This patch is against -stable. It reports
kernel stack use on process exit and will generate a 'Kernel stack
underflow' message if it detects an underflow. It doesn't panic,
so for a fun
:
:Matt Dillon wrote:
: This isn't perfect but it should be a good start in regards to
: testing kstack use. This patch is against -stable. It reports
: kernel stack use on process exit and will generate a 'Kernel stack
: underflow' message if it detects an underflow
:stack size = 4688
Sep 24 22:47:22 test1 /kernel: process 29144 exit kstackuse 4496
closer... :-)
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Well, this has turned into a rather sticky little problem. I've
spent all day going through the vnode/name-cache reclaim code, looking
both at Seigo's cache_purgeleafdirs() and my own patch.
This is what is going on: The old code refused to reuse any vnode that
had (A)
: Hmmm. This would seem to be a step back to the days when caching was done
:relative to the device as opposed to the file-relative scheme we have now.
:One of the problems with the old scheme as I recall is that some filesystems
:like NFS don't have a 'device' and thus no physical block
:VM Page Cache, and thus not be candidates for reuse anyway. So my patch
:has a very similar effect but without the overhead.
:
:Back when I rewrote the VFS namecache back in 1997 I added that
:clause because I saw directories getting nuked in no time because
:there were no pages
:Block input operations is the one notable exception and it tells a
:very interesting story: Matts patch results in a 4% increase, but
:combined with vmdirioenable it results in a 21.5% decrease.
:
:That's pretty darn significant: one out of every five I/O have
:been saved.
:
:The reason it has
:Has the problem of small-memory machines ( 64M IIRC) solved now? As I
:understand it vmiodirenable is counter-productive for these boxes.
:Maybe one could decide on-boot whether the amount of mem is enough to
:make it useful?
:
:Just a thought of course.
:
:| / o / /_ _
Here is the latest patch for -stable. vmiodirenable is turned on by
default, the cache purge code is enabled based on vmiodirenable, and
I added a new sysctl called nameileafonly which defaults to ON (1).
nameileafonly vmiodirenable action
1 1
Here is the latest patch for -current. vmiodirenable is turned on by
default, the cache purge code is enabled based on vmiodirenable, and
I added a new sysctl called nameileafonly which defaults to ON (1).
The old cache_purgeleafdirs() stuff is #if 0'd out.
nameileafonly
fdirs())
References: 1620.1001272770@critter
:
:Here is the latest patch for -stable. vmiodirenable is turned on by
:default, the cache purge code is enabled based on vmiodirenable, and
:I added a new sysctl called nameileafonly which defaults to ON (1).
:
:nameileafonly
:Notice that both the user and system times increased..
:if there had been another parallel task, the overall system throughout may have
:decreased..
:
:I'm not saying this is wrong, just that we should look at other workloads too.
:no point in optimising the system for compiling itself.. that's
I got the cache_leaf_test() return values backwards. But that's ok,
because my cache_leaf_test() if() statement is also backwards :-). I'll
turn them around in a later patch set.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
Ok, here are the first set of results. I am going to rerun the entire
suite of tests again with the machines limited to 128M of ram to see
what happens then.
BTW, these are really nice machines! I highly recommend DELL2550's.
The results w/ 512M are basically that it
Hi guys. I've been tracking down issues with vnode recycling..
specifically, getnewvnode() deadlocks in -stable in large-memory
configurations. I took a real good look at cache_purgeleafdirs()
in -current to see if it was MFCable as a solution. But
There are a
:I agree, I've never been too fond of the purgeleafdirs() code myself
:for that reason and others.
:
:If we disregard the purgeleafdirs() workaround, the current cache code
:was built around the assumption that VM page reclaims would be enough
:to keep the vnode cache flushed and any vnode which
:Well, wait a sec... all I do is zap the namei cache for the vnode. The
:check to see if the vnode's object still has resident pages is still in
:there so I don't quite understand how I turned things around. In my
:tests it appears to cache vnodes as long as there are resident
sshd died on one of our machines today. The traceback seems to
indicate that a signal is interrupting a free(). I'm going to
play with the code a bit to see if there's an easy fix.
This bug can't occur very often... the key regeneration signal
has to occur *just* as sshd
I looked at the code and there is definitely a serious issue. This
proposed patch should solve the problem. Here it is for review before
I commit it and send a bug report off to the openssh folks. I am testing
it now.
-Matt
:
:* Matt Dillon [EMAIL PROTECTED] [010917 15:32] wrote:
: sshd died on one of our machines today. The traceback seems to
: indicate that a signal is interrupting a free(). I'm going to
: play with the code a bit to see if there's an easy fix.
:
: This bug can't occur very
I forwarded the whole thing to Brian. We'll wait to see what he decides
to do. Obviously a fix like this needs to go, it's just a matter of who,
how, and when.
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe
:What about changing this to __FBSD(), which is what I was using in a
:prototype to reduce the number of characters in the macro name (and thus
:reduce the wrap around).
:
:--
:-- David ([EMAIL PROTECTED])
__FBSD() is too generic for a #define name in what is essentially a
global
:In article [EMAIL PROTECTED],
:John Baldwin [EMAIL PROTECTED] wrote:
:
: Looks good to me, but I'm only somewhat familiar with libstand. :)
:
:Thanks for taking a look at it. Matt Dillon also reviewed it and gave
:it a clean bill of health. He made a suggestion for making the code a
:bit
:
:On Sat, 25 Aug 2001, Julian Elischer wrote:
:
: AH yes, it's a race for KSe, but we are 1:1 still so it's not a problem (yet :-)
: ( at least, not the one that's hitteng me at the moment)
:
:Well, don't get frustrated, look on the bright side of things: Even if
:you don't have KSE running in
:
: MAP_INHERIT This is supposed to permit regions to be
: inherited across execve(2) system calls,
: but is currently broken.
:
: Support for the flag and reference to it in the manpage should just be
:removed.
:
:-DG
:
:David Greenman
Alfred, DG, could you take a look at pmap_copy() in i386/i386/pmap.c
and tell me if what I think I'm seeing is what I'm seeing?
My read of this code is that a global, APTDpde, is being set, and
then that pointer is being used in a loop later on in the routine.
the problem is
:
:Thinking about this a bit more
:doesn't each process ahve it's own PTD?, so a process could sleep and
:another could run but it would have a differnt PTD
:so they could change that PTDE with impunity
:because when teh current process runs again it get's its own
:ptd back again..
You guys are forgetting about the stack-boundry crap some idiot added
to GCC to optimize floating point ops, which gets stuffed in there even
if there are no floating point ops.
I really wish someone would rip it out. It is SOOO fraggin annoying.
: Hmm. Ok, I think you are right. APTDpde is what is being loaded
: and that points into the user page table directory page, which is
: per-process. So APTDpde should be per-process.
:
:But it is! (sort-of) APTDpde was per-process but is now per-address-space
:with the advent of
MAP_INHERIT is broken and always has been.
-Matt
:exec gives you an new vm space..
:inherrit only applies to forks
:
:
:On Thu, 23 Aug 2001, Alfred Perlstein wrote:
:
: * Bernd Walter [EMAIL PROTECTED] [010823 06:16] wrote:
: I do the following:
:
This gets an 'A' on my cool-o-meter.
http://www.vnunet.com/News/1124839
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
:
:* Matt Dillon [EMAIL PROTECTED] [010822 18:30] wrote:
: This gets an 'A' on my cool-o-meter.
:
: http://www.vnunet.com/News/1124839
:
:Interesting, I guess one could work around it by periodically
:sending bogus empty packets in the middle of activity.
:
:--
:-Alfred Perlstein
:Hi there,
:
:I need some mechanism to hold long-term locks (across
:context switches) while using kernel threads (kthread_*)
:and lockmgr() looked like the right thing to use.
:
:I am running FreeBSD 4.1 on a uniprocessor (..the questions
:are similar with 4.3)
:
:Looking at kern_lock.c, I see
:Matt
:
:Ok I see..the interlock is a lock on a collection (e.g
:on vfs mount list) and it can be released once the simple
:lock within the to-be-locked object has been acquired.
:These are really spin locks, now that I saw simplelock.s
:
:One more clarification if you will.. :-)
:
:What is the
:
:David Greenman wrote:
:
:- I would like to cap the size of the buffer cache at 200MB,
: giving us another 70MB or so of KVM which is equivalent to
: another 30,000 or so nmbclusters.
:
:That also seems like overkill for the vast majority of systems.
:
:But
:
:David Greenman wrote:
:
:- I would like to cap the size of the buffer cache at 200MB,
: giving us another 70MB or so of KVM which is equivalent to
: another 30,000 or so nmbclusters.
:
:That also seems like overkill for the vast majority of systems.
:
:But
:
:There are two things I would like to commit for the release:
:
: - I would like to cap the SWAPMETA zone reservation to 70MB,
:which allows us to manage a maximum of 29GB worth of swapped
:out data.
:
:This is plenty and saves us 94MB of KVM which is roughly
:
: It also has the unfortunate property of locking us into virtual
: wire mode, when in fact Microsoft demonstrated that wiring down
: interrupts to particular CPUs was good practice, in terms of
: assuring best performance. Specifically, running in virtual
: wire mode means that all your
:I'd agree that is a specialized situation, one which wouldn't
:be critical to many freebsd users. Is Terry right that the
:current strategy will lock us into virtual wire mode, in
:some way which means that this specialized situation CANNOT
:be handled?
:
:(it would be fine if it were handled
:
:Matt Dillon wrote:
: :What this, exactly?
: :
: :That virtual wire mode is actually a bad idea for some
: :applications -- specifically, high speed networking with
: :multiple gigabit ethernet cards?
:
: All the cpu's don't get the interrupt, only one does.
:
:I think that you will end
:If I remember correctly from reading a thesis (can't remember its
:author) on the page coloring which I believe widely introduced this
:concept, page coloring adds a lot of efficiency to the directly
:mapped caches but even for the 2-way caches is nearly pointless.
:
:-SB
For the most
:In article [EMAIL PROTECTED],
:Mike Smith [EMAIL PROTECTED] wrote:
:
: It looks about right, but page colouring is pointless unless and until we
: can determine the processor cache characteristics at runtime.
:
: Which we can't.
:
:Why can't we do this at least on the i386 with the CPUID
:
:If I added this to a man page would I be telling the truth :).
:
:Note, these are my notes and not the exact text that I would
:add, and I have not bother with anything to do with object
:coloring etc. I just want to make sure I've got this part
:down.
:
:Chad
It's a good description
: Since most L1 caches these days are at least 16K and most L2 caches
: these days are at least 64K (and often much higher, such as on the IA32),
: our hardwired page coloring constants wind up being about 95% effective
: across the entire range of chips our OS currently runs on.
:I should have guessed the reason. Matthew Dillon answered this question on
:Fri, 2 Jun 2000 as follows:
:
:
:The VM routines that manage pages associated with objects are not
:protected against interrupts, so interrupts aren't allowed to change
:page-object associations.
:Dear all,
:
: I study FreeBSD vm managememnt recently, however, I am a little confused
:with vm_page's page color. when you call vm_add_new_page() in vm_startup(),
:you will set each map entry's page color according to its physical addr.
:
: m-pc = (pa PAGE_SHIFT)PQ_L2_MASK;
:
:However,
:
:
:
: yes, I mean vm_page_t, and understand what you said. I will try to print the
:value of PQ_L2_SIZE in my kernel. Do you know what kernel options influence
:this value? I saw it is decided by PQ_CACHESIZE which is decided by different
:PQ_HUGE[LARGE/MEDIUM/...]CACHEsetting.
:Not really. The private IP space probably never leaves that LAN segment so
:the source IP would get set properly and the default route is irrelevent.
:Whenever
:he communicated with a block that is not diretly attached then the code has
:to
:choose a source address and then send the packet to
:..
: You have to explicitly bind to the correct source IP if you care.
:
: For our machines I bind our external services specifically to the
: external IP. Beyond that I usually don't care because I NAT-out our
: internal IP space anyway, so any packets sent 'from' an internal
:David Malone wrote (2001/06/11):
: On Sun, Jun 10, 2001 at 05:20:50PM -0700, Peter Wemm wrote:
: I agree totally. This should have been done ages ago, I've been burned on
: it a few times, but never badly enough to go fix it.
:
: I've committed this - I'll let Matt do the MFC when he feels
:could anyone think about MFC FFS dirpref code?
:is it still not enough stable in CURRENT?
:I heard OpenBSD 2.9 has it already.
Kirk aksed me to do in a month or two ago. It's been on my TODO list
but I haven't had time to do it yet. It's still on my TODO list.
But if someone
:
:
::could anyone think about MFC FFS dirpref code?
::is it still not enough stable in CURRENT?
::I heard OpenBSD 2.9 has it already.
:
:Kirk aksed me to do in a month or two ago. It's been on my TODO list
:but I haven't had time to do it yet. It's still on my TODO list.
:
:In message [EMAIL PROTECTED], Terry Lambert writes:
: FWIW, I vote that we rever to the traditional default and require
: -R1 or -b to avoid boot time hangs. The standard behaviour for most
: NFS implementations that I'm aware of would do this.
:
:I agree; people at work have bitched about
I've been trying to track down a weird problem with our mail system
suddenly believing that a host does not exist, or timing out in DNS.
I tracked it down to the DNS server, but I am not entirely sure what is
going on. What appears to be happening is that the glue IN A record
:
:
:On Mon, 16 Jul 2001, Matt Dillon wrote:
:
: I've been trying to track down a weird problem with our mail system
: suddenly believing that a host does not exist, or timing out in DNS.
:
: I tracked it down to the DNS server, but I am not entirely sure what is
: going
1 - 100 of 412 matches
Mail list logo
