> 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
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
>
> > 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
Try "-mpreferred-stack-boundary=2".
Dima
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
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
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 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
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
"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
> > 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
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
> 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
> 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
[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
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
>
> 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
> 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
"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
"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
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?
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
"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
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
> > "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
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
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
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
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.
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
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
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
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
32 matches
Mail list logo