One more thing, here's my kernel config file just in case you need it:
machine i386
cpu I586_CPU
ident RAID
maxusers64
makeoptions DEBUG=-g#Build kernel with gdb(1) debug
options DDB_UNATTENDED
options INET
Here is my dmesg output, and btw, sorry.. the perl script was not running
on the NFS volume, just regularly on a regular 4.0 box, and it crashed the
box (yes, I had login limits set), I was just giving another example of
what seems to be some instability in 4.0 under high loads..
Here my dmesg fr
::Jason DiCioccio
Another possibility -- could you post your 'dmesg' output? One thing
that NFS does do is severely exercise both the network and the SCSI
device in a concurrent fashion.
If you happen to be using an NCR SCSI chipset, that could be the cause
of the problem (t
:The thing is i'm not sure if it's vinum, I could also duplicate this on
:another machine without vinum.. except I duplicated it differently..
:
:Consider the following perl script:
:
:#!/usr/bin/perl
:for ( ; ; ) {
:system("fetch http://www.web.site/index.html");
:}
:
:Of course, replaci
On Friday, 31 March 2000 at 0:23:04 -0500, Systems Administrator wrote:
>
> panic: lockmgr: pid -2, exclusive lock holder 5 unlocking
>
> Syncing disks... Timedout SCB handled by another timeout
> Timedout handled by another timeout
>
> That is what I get when doing a 'du -k' on an NFS mount from
panic: lockmgr: pid -2, exclusive lock holder 5 unlocking
Syncing disks... Timedout SCB handled by another timeout
Timedout handled by another timeout
That is what I get when doing a 'du -k' on an NFS mount from a remote
machine.. THe machine I am speaking of is the actual nfs server, i'm using
