< said:
> AMD is easy to upset, and that's bad because it's holding a mountpoint in /
> (ie: /host) which often gets hit by every single getcwd() call when it
> gets a lstat("/host"...) or whatever. I think this is the single largest
> source of load on the amd process.
> IMHO, /host needs to
Matthew Dillon wrote:
> :On Tue, Mar 16, 1999 at 12:52:32PM -0800, Matthew Dillon wrote:
> :> A.. And if you make those AMD mounts normal nfs mounts it doesn't
> :> fry? If so, then we have a bug in AMD somewhere.
> :
> :I tried the cp several times again on a regular NFS mount,
:On Tue, Mar 16, 1999 at 12:52:32PM -0800, Matthew Dillon wrote:
:> A.. And if you make those AMD mounts normal nfs mounts it doesn't
:> fry? If so, then we have a bug in AMD somewhere.
:
:I tried the cp several times again on a regular NFS mount, to make
:sure, and no, it doesn't se
On Tue, Mar 16, 1999 at 12:52:32PM -0800, Matthew Dillon wrote:
> A.. And if you make those AMD mounts normal nfs mounts it doesn't
> fry? If so, then we have a bug in AMD somewhere.
I tried the cp several times again on a regular NFS mount, to make
sure, and no, it doesn't seem to
:
:On Tue, Mar 16, 1999 at 11:11:44AM -0800, Matthew Dillon wrote:
:>(cnp->cn_flags & NOCROSSMOUNT) == 0) {
:> if (vfs_busy(mp, 0, 0, p))
:> continue;
:...
:> You shouldn't be crossing a mount point. Are you by chance doing a
:> rec
On Tue, Mar 16, 1999 at 11:11:44AM -0800, Matthew Dillon wrote:
>(cnp->cn_flags & NOCROSSMOUNT) == 0) {
> if (vfs_busy(mp, 0, 0, p))
> continue;
...
> You shouldn't be crossing a mount point. Are you by chance doing a
> recursive cop
:On Mon, Mar 15, 1999 at 01:24:46PM -0800, Matthew Dillon wrote:
:> Compile up a kernel with 'options DDB' and get a backtrace when
:> it panics next ( 'trace' command from DDB prompt ).
:
:Ok, here goes. The kernel is compiled without -g for the moment,
:but I've provided the function offs
On Mon, Mar 15, 1999 at 01:24:46PM -0800, Matthew Dillon wrote:
> Compile up a kernel with 'options DDB' and get a backtrace when
> it panics next ( 'trace' command from DDB prompt ).
Ok, here goes. The kernel is compiled without -g for the moment,
but I've provided the function offsets if
small files) and the panic happens every time I try (with cp -rp;
:not with piped tars).
:
:The kernel is today's, with NFS compiled-in (it's not a module).
:
:I'm having the following message:
: panic: vfs_busy: unexpected lock failure
:--
:Pierre Beyssac p...@enst.fr
files) and the panic happens every time I try (with cp -rp;
not with piped tars).
The kernel is today's, with NFS compiled-in (it's not a module).
I'm having the following message:
panic: vfs_busy: unexpected lock failure
--
Pierre Beyssac p...@enst.fr
To Unsubscribe:
10 matches
Mail list logo