On Thu, 20 Aug 2009, Daniel O'Connor wrote:
Unfortunately the system is in Finland and I'm in Australia so I
can't sit at the console :(
Someone visited the site and determined that the floppy drive cable was
intermittently fouling the CPU fan. I believe this was causing the CPU
to overheat
On Fri, 21 Aug 2009, CmdLnKid wrote:
came back or the machine was rebooted. I continued for a while using
/var/mail over NFS while setting or unset mail variables for the
shell. You may also want to check into whether something is trying to
acquire a lock on a file over that NFS mount which
On Sat, 22 Aug 2009, Daniel O'Connor wrote:
On Fri, 21 Aug 2009, CmdLnKid wrote:
came back or the machine was rebooted. I continued for a while using
/var/mail over NFS while setting or unset mail variables for the shell. You
may also want to check into whether something is trying to acquire
On Sat, 22 Aug 2009, Robert Watson wrote:
On Sat, 22 Aug 2009, Daniel O'Connor wrote:
On Fri, 21 Aug 2009, CmdLnKid wrote:
came back or the machine was rebooted. I continued for a while
using /var/mail over NFS while setting or unset mail variables for
the shell. You may also want to
Hi,
On 20 Aug 2009, at 03:34, Daniel O'Connor wrote:
[...]
The problem appears to now be that the userland process that reads
data
out of the kernel is being stalled for over 4 seconds. This process
reads from the kernel and does some minor processing and then writes
it
out to a child
On Thu, 20 Aug 2009, Bob Bishop wrote:
Hi,
On 20 Aug 2009, at 03:34, Daniel O'Connor wrote:
[...]
The problem appears to now be that the userland process that reads
data
out of the kernel is being stalled for over 4 seconds. This process
reads from the kernel and does some minor
On 20 Aug 2009, at 08:25, Daniel O'Connor wrote:
This is running in 6.2 ish using 4BSD, I was under the impression ULE
wasn't very stable in 6.2.
I could probably try it though...
Hmm. ISTR having similar problems around the 6.1-2 era. You might try
6.4 if that's possible for you.
--
On Thu, 20 Aug 2009, Bob Bishop wrote:
On 20 Aug 2009, at 08:25, Daniel O'Connor wrote:
This is running in 6.2 ish using 4BSD, I was under the impression
ULE wasn't very stable in 6.2.
I could probably try it though...
Hmm. ISTR having similar problems around the 6.1-2 era. You might
On Thu, 20 Aug 2009, Daniel O'Connor wrote:
On Thu, 20 Aug 2009, Bob Bishop wrote:
On 20 Aug 2009, at 08:25, Daniel O'Connor wrote:
This is running in 6.2 ish using 4BSD, I was under the impression
ULE wasn't very stable in 6.2.
I could probably try it though...
Hmm. ISTR having
On 20 Aug 2009, at 12:06, Daniel O'Connor wrote:
On Thu, 20 Aug 2009, Daniel O'Connor wrote:
On Thu, 20 Aug 2009, Bob Bishop wrote:
On 20 Aug 2009, at 08:25, Daniel O'Connor wrote:
This is running in 6.2 ish using 4BSD, I was under the impression
ULE wasn't very stable in 6.2.
I could
On Thu, Aug 20, 2009 at 12:35:46PM +0100, Bob Bishop wrote:
On 20 Aug 2009, at 12:06, Daniel O'Connor wrote:
On Thu, 20 Aug 2009, Daniel O'Connor wrote:
On Thu, 20 Aug 2009, Bob Bishop wrote:
On 20 Aug 2009, at 08:25, Daniel O'Connor wrote:
This is running in 6.2 ish using 4BSD, I was
On Thu, 20 Aug 2009, Kostik Belousov wrote:
Things like ls on the console might take several seconds to respond
when the box didn't seem to be very busy (but wasn't idle, maybe
serving a little NFS). It wasn't the shell getting swapped out or
anything else obvious. This was on SMP, not
On Thu, 20 Aug 2009 08:42 -, doconnor wrote:
On Thu, 20 Aug 2009, Kostik Belousov wrote:
Things like ls on the console might take several seconds to respond
when the box didn't seem to be very busy (but wasn't idle, maybe
serving a little NFS). It wasn't the shell getting swapped out or
Hi,
We have several systems doing data acquisition and I had originally
thought we were seeing the interrupt handler for out PCI card not being
called quickly enough, however I misread the diagnostics :)
The digitised data is fed into a FIFO and when it is part full
(32kbytes) an interrupt is
Looking at the sources:
The 'blocked' column in vmstat is the sum of
(struct vmtotal).t_dw /* jobs in ``disk wait'' (neg priority) */ and
(struct vmtotal).t_pw /* jobs in page wait */
'systat -v' splits these into two fields (Proc:d and Proc:p) as does
sysctl vm.vmtotal
It's difficult to map
Just upgraded to June 15th sources, started up all the processes, and am
already at 29 blocked processes ...
I've checked for states D, E and L ... nothing ...
Actually, let's go one better ... attached is a complete list of my
process table (MWCHAN, STATE, COMMAND) ... right now, vmstat is
On Mon, 26 Jun 2006, Marc G. Fournier wrote:
Just upgraded to June 15th sources, started up all the processes, and am
already at 29 blocked processes ...
I've checked for states D, E and L ... nothing ...
Actually, let's go one better ... attached is a complete list of my process
table
On Mon, Jun 26, 2006 at 12:44:17PM -0300, Marc G. Fournier wrote:
On Mon, 26 Jun 2006, Marc G. Fournier wrote:
Just upgraded to June 15th sources, started up all the processes, and am
already at 29 blocked processes ...
I've checked for states D, E and L ... nothing ...
Actually,
On Mon, 26 Jun 2006, Kostik Belousov wrote:
Dumb unmotivated question: do you have nfs exports on this machine ?
neither nfs nor mountd are currently running ...
Marc G. Fournier Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]
19 matches
Mail list logo
