> On Mon, 12 Jul 1999, Dmitrij Tejblum wrote:
> > Alan Cox wrote:
> > > When you create a stack or grow an existing stack, the minimum chunk size
> > > is 128K.
> >
> > This make use of "growable" stacks in libc_r particulary useful, given
>
> I've had this problem since at least FreeBSD 3.1-RELEASE (it works in
> 2.2.7/2.2.8). Same problem in 3.2-RELEASE and -current (as of last night).
>
> Can someone reproduce this error? I can't believe that you can't newfs
> a ccd... did I miss something?
I always see the error message la
Doug Rabson wrote:
>
> This is probably because our server detects that the directory has been
> modified and rejects the solaris client's directory cookies.
I think we should not ever reject a client's cookie. Consider a local
program that scan the directoty with the getdirentries() syscall. T
[sorry for some delay...]
Doug Rabson wrote:
> > I think we should not ever reject a client's cookie. Consider a local
> > program that scan the directoty with the getdirentries() syscall. The
> > offset in the directory is essentially the cookie that would be sent to
> > an NFS client. But we
> It isn't possible to do this and still remain synchronized. If the
> directory changes on the server, the client has no way of knowing
> whether a cookie corresponds to the same file if you always return
> a valid response. This breaks the protocol.
>
> A local filesystem
> The client system -- A FreeBSD
> client system - has a buffer cache. The buffer cache holds an abstraction
> for both files and directories.
Well, the discussion is about FreeBSD NFS server, not about FreeBSD NFS
client. Neither FreeBSD server cannot assume FreeBSD client, nor
Fre
Pascal Hofstee wrote:
> Hi,
>
> Perl seems to be broken for about 3 consecutive days now
> Anybody have any idea what might be causing this ?
I suspect it is the recent changes in rtld.
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body o
> > typedef struct {
> > unsigned int n;
> > uint64_t v;
> > } sigset_t;
>
> You can't use any BSD or FreeBSD specific types (such as u_int32)t) in
> publicly visible types (such as sigset_t). It breaks programs because it's
> not ANSI and/or Posix.
You can use internal names lik
"Matthew D. Fuller" wrote:
> OK:
> #!/bin/sh
> (cvs status | grep '^File:' | grep -v 'Status: Up-to-date$') 2> /dev/null
Excuse me, I apparently completely missed the idea, but what is wrong
with
cvs -qn up
?
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-cu
Kenneth Culver wrote:
> what does this message mean?
> Sep 24 18:34:04 culverk /kernel: arpresolve: can't allocate llinfo for 127.0.0.1rt
I don't know how you got it, but here is an easy way to do so:
In /etc/rc.conf:
network_interfaces="ed0 lo0"
ifconfig_ed0="DHCP"
(ed0 apparently can be repla
"David Schwartz" wrote:
> We're talking about the special case of small root partitions, such that
> softupdates inability to make empty space available quickly can make the
> difference between a major operation's success or failure.
>
> This is almost impossible on a 1.8Gb root part
Matthew Dillon wrote:
> Actually, what I meant was that AMD itself is equivalent to a loopback
> mount, whether or not you make loopback mounts through it.
No. The loopback deadlock happen when the nfs server handle a write
operation. But there cannot be any writes in the amd filesystem.
David Malone wrote:
> A child process seems to be able to let go of a parent's lock on
> 4.0 by closing a file discriptor, the same doesn't seem to be true
> on 3.3.
So, apparently, it was broken in rev. 1.68 of kern_descript.c. (Another
example that comments (in closef() in this case) serve no
Brian Fundakowski Feldman wrote:
> There were zero comments about what order things happen in; in fact,
> the ordering in this case is Just Plain Lame (TM). It's much more
> correct to explicitly check for fp->f_count == 1.
Not sure what you mean. The commit clearly states that POSIX and BSD
lo
Try "-mpreferred-stack-boundary=2".
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
>
> > Maybe I can at least commit the addition of "volatile" to the source
> > code. That will work around that particular bug until egcs is
> > fixed...
>
> FWIW, the newly committed gcc-2.95.2 doesn't "fix" the problem.
Are you sure? GCC-2.95.2 seems OK here.
Dima
To Unsubscribe: send ma
Bruce Evans wrote:
> I would have
> expected the most generally efficient way to align doubles and the new PIII
> obkects to be aligning the stack only in functions that have such objects
> on the stack. This requires at most one extra instruction:
>
> andl $~0xf,$esp 16-byte alig
> Good luck using it under current.
>
> First site you hit quits netscape without reasons...
>
> ...until you drop out of X and see a __sh_getcontext IIRC warning on
> your console.
If you can hack on the flash plugin's Makefile, try add -fno-exceptions
there.
Dima
To Unsubscribe: send m
Brian Feldman wrote:
> The basic problem is that msdosfs panic()s quite easily with a "zone
> not free" error (INVARIANTS is /ON/ in the kernel), when I attempt to do a rw
> mount of a FAT16.
Don't you, by a chance, load msdosfs module dynamically? If so, the
module must also be compiled with INV
Jos Backus wrote:
> This occurs almost immediately after copying a file to an msdos fs. I can
> provide more info if that is deemed useful.
I suspect your kernel compiled with INVARIANTS, you load msdosfs module
dynamically, and the module isn't compiled with INVARIANTS. If so,
don't do that. If
Jos Backus wrote:
> On Tue, Feb 23, 1999 at 02:41:14AM +0300, Dmitrij Tejblum wrote:
> > Jos Backus wrote:
> > > This occurs almost immediately after copying a file to an msdos fs. I can
> > > provide more info if that is deemed useful.
> >
> > I suspe
Bruce Evans wrote:
> tail(1) assumes that mmap(2) works on works on regular files. mmap(2) on
> the irregular regular files /proc/*/map returns success but doesn't work.
IMO, it ought to work. There should be no reason why regular files on
procfs are more "irregular" than regular files on NFS.
Matthew Dillon wrote:
> - error = acquire(lkp, extflags,
> - LK_HAVE_EXCL | LK_WANT_EXCL | LK_WANT_UPGRADE);
> + if (p->p_flag & P_DEADLKTREAT) {
> + error = acquire(
This is broken: p may be NULL, it i
Matthew Dillon wrote:
>
> We'll get a quick fix committed but the lockmgr stuff needs a real
> going-over... having interrupts using the general lockmgr call is
> a disaster waiting to happen.
Hmmm. After I looked a bit further, it looks like a bug in the
scheduler (?). Here is the s
Alex Zepeda wrote:
> panic: vm_page_bits: illegal base/size 4096/2048
The panic is hopefully just fixed in vnode_pager.c rev.1.107. I didn't
quite understand if you have other msdosfs problems.
Dima
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the
> > "Jonathan M. Bresler" wrote:
> > > with volunteers, we could moderate the list(s). mail transfer
> > > would be slower as we wait for the moderator(s) to approve each piece
> > > of email. if we use more than one moderator per list, the
> > > time-sequence of email would be lostwe would
Yup, this is supposed to fix the problem, that I introduced a day
before. The problem was 'make -jN'-depended. Sorry for the
inconvinience.
BTW, I hope there will be no 'Your makefile has been rebuilt' failures
anymore.
Dima
Steve Kargl wrote:
> It doesn't fix it here, but "dt" committed a f
"Andrey A. Chernov" wrote:
> On Fri, May 14, 1999 at 11:15:35AM -0400, John R. LoVerso wrote:
> > Of course, DB 2 is still available as an easily installed port/package.
>
> Not so easily, it conflict with libc's DB in subtle but harmful manner.
Only if it is configured with --enable-compat185. J
calcru() access p_stats, which is in upages. Therefore, as I understand,
it should not be called on a swapped out process. Neither calcru() nor
its callers seem to ensure this. At least the call in procfs_dostatus()
may happen on a swapped out process. (It test for P_INMEM for another
access to
Peter Wemm wrote:
> Bruce Evans wrote:
> > >calcru() access p_stats, which is in upages. Therefore, as I understand,
> > >it should not be called on a swapped out process. Neither calcru() nor
> >
> > Does anyone object to moving everything except the stack from the upages
> > to the proc table?
"Andrey A. Chernov" wrote:
> Just check 'swapinfo' in recent -current, it shows "/dev/(null)" as swap
> device, it means that devinfo() call in kvm_getswapinfo() returns NULL,
> i.e. called with wrong argument which is swinfo.sw_dev
This is a known problem. It is because dev_t in kernel and dev_t
"Louis A. Mamakos" wrote:
>
> Before documenting it, how about we fix it's name to be more accurate
> to newcomers: net.inet.tcp.always_makedead, etc. There's no part of
> this (in many cases misguided) mechanism that keeps anything "alive."
I disagree. I use keepalive exactly to keep my connecti
32 matches
Mail list logo
