All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zed Pobre <zed@resonant.org>
To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: Complete freeze with 2.4.20 on 4-proc IBM xSeries 350
Date: Thu, 26 Dec 2002 15:43:38 -0600	[thread overview]
Message-ID: <20021226214338.GA1285@resonant.org> (raw)
In-Reply-To: <11930000.1039565421@flay>

[-- Attachment #1: Type: text/plain, Size: 6428 bytes --]

On Tue, Dec 10, 2002 at 04:10:21PM -0800, Martin J. Bligh wrote:
> > I'm experiencing serious problems with Kernel 2.4.20 on a IBM xSeries 350
> > machine, having 4 700 MHz processors and 4 GB RAM (same on another machine
> > with the same configuration, but only 3 GB RAM). The machine just com-
> > pletely freezes after some time, ranging from 20 minutes to 3 hours. It
> > is running IBM DB/2 with quite some load, the base system is RedHat 7.2
> > with all the updates applied. There is no oops or other fault, just a
> > plain freeze.
> 
> Can you watch /proc/meminfo and see how low "lowfree" gets?
> If it gets low (eg below 50Mb), dump /proc/slabinfo as well.

    I'm running off a Soyo Dragon KT400 board, single AMD 2400+
processor, 1GB ram (4GB limit set in kernel), and was also having
freezes, apparently related to having software raid 1 in use (on two
drives sitting on the on-board Highpoint controller).  If I started a
large data transfer over the net, the machine would freeze after some
time ranging from a few minutes to an hour, with either 2.4.20-ac2 or
2.4.21-pre2.  I tried letting the system resync before restarting, and
the first pass through it actually froze during resyncing, with
nothing special going on.  Later, after a resync, I started trying all
sorts of things, from turning off XFree86 and running a minimal set of
loaded modules, to using mdadm to fail one of the drives (it was a
RAID1 setup) to force only a single disk to be in use.  Right now,
I've taken it off of RAID entirely, and am mounting /dev/hdex
directly, and copying data to that, and it seems to be okay so far
(for the last hour or so).


cat /proc/meminfo gives:

        total:    used:    free:  shared: buffers:  cached:
Mem:  1055412224 1045782528  9629696        0 90771456 720228352
Swap: 526376960 39202816 487174144
MemTotal:      1030676 kB
MemFree:          9404 kB
MemShared:           0 kB
Buffers:         88644 kB
Cached:         684644 kB
SwapCached:      18704 kB
Active:         540556 kB
Inact_dirty:    356560 kB
Inact_clean:     44764 kB
Inact_target:   188376 kB
HighTotal:      131008 kB
HighFree:         1024 kB
LowTotal:       899668 kB
LowFree:          8380 kB
SwapTotal:      514040 kB
SwapFree:       475756 kB
Committed_AS:   322008 kB


So if you were concerned about LowFree going low, it is.

/proc/slabinfo:

slabinfo - version: 1.1
kmem_cache            68     68    112    2    2    1
fib6_nodes             5    112     32    1    1    1
ip6_dst_cache          5     20    192    1    1    1
ndisc_cache            1     30    128    1    1    1
ip_conntrack          10     24    320    2    2    1
tcp_tw_bucket          0      0    128    0    0    1
tcp_bind_bucket       25    112     32    1    1    1
tcp_open_request       0      0    128    0    0    1
inet_peer_cache        0      0     64    0    0    1
ip_fib_hash            9    112     32    1    1    1
ip_dst_cache          12     40    192    2    2    1
arp_cache              3     30    128    1    1    1
urb_priv               4     59     64    1    1    1
blkdev_requests     1408   1410    128   47   47    1
nfs_write_data         0      0    384    0    0    1
nfs_read_data          0      0    384    0    0    1
nfs_page               0      0    128    0    0    1
journal_head          26     77     48    1    1    1
revoke_table           1    250     12    1    1    1
revoke_record          0      0     32    0    0    1
dnotify_cache          0      0     20    0    0    1
file_lock_cache        4     40     96    1    1    1
fasync_cache           1    202     16    1    1    1
uid_cache              6    112     32    1    1    1
skbuff_head_cache    163    260    192   13   13    1
sock                 201    204    896   51   51    1
sigqueue               1     29    132    1    1    1
kiobuf                 0      0     64    0    0    1
cdev_cache            22    472     64    8    8    1
bdev_cache             9     59     64    1    1    1
mnt_cache             18     59     64    1    1    1
inode_cache        54639  57071    512 8153 8153    1
dentry_cache         804   4050    128  135  135    1
dquot                  0      0    128    0    0    1
filp                1563   1590    128   53   53    1
names_cache            0      2   4096    0    2    1
buffer_head       185515 191520    128 6368 6384    1
mm_struct             63     80    192    4    4    1
vm_area_struct      2749   2850    128   92   95    1
fs_cache              62    118     64    2    2    1
files_cache           62     63    448    7    7    1
signal_act            71     75   1344   24   25    1
pte_chain          70104  74592      8  221  222    1
size-131072(DMA)       0      0 131072    0    0   32
size-131072            0      0 131072    0    0   32
size-65536(DMA)        0      0  65536    0    0   16
size-65536             2      2  65536    2    2   16
size-32768(DMA)        0      0  32768    0    0    8
size-32768             2      2  32768    2    2    8
size-16384(DMA)        0      0  16384    0    0    4
size-16384             2      7  16384    2    7    4
size-8192(DMA)         0      0   8192    0    0    2
size-8192             15     19   8192   15   19    2
size-4096(DMA)         0      0   4096    0    0    1
size-4096            121    139   4096  121  139    1
size-2048(DMA)         0      0   2048    0    0    1
size-2048             50    130   2048   26   65    1
size-1024(DMA)         0      0   1024    0    0    1
size-1024             53     60   1024   14   15    1
size-512(DMA)          0      0    512    0    0    1
size-512              99    120    512   13   15    1
size-256(DMA)          0      0    256    0    0    1
size-256              86    120    256    6    8    1
size-128(DMA)          3     30    128    1    1    1
size-128             953    990    128   33   33    1
size-64(DMA)           0      0     64    0    0    1
size-64              776   1062     64   17   18    1
size-32(DMA)          52     59     64    1    1    1
size-32              714    767     64   13   13    1


Does this provide you with any useful information?

-- 
Zed Pobre <zed@debian.org> a.k.a. Zed Pobre <zed@resonant.org>
PGP key and fingerprint available on finger; encrypted mail welcomed.

[-- Attachment #2: Type: application/pgp-signature, Size: 481 bytes --]

  reply	other threads:[~2002-12-26 21:36 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-12-10 22:58 Complete freeze with 2.4.20 on 4-proc IBM xSeries 350 "Rüegg, Peter H."
2002-12-11  0:10 ` Martin J. Bligh
2002-12-26 21:43   ` Zed Pobre [this message]
2002-12-28  4:28     ` Zed Pobre

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20021226214338.GA1285@resonant.org \
    --to=zed@resonant.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.