: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,
::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
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
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
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
