More info on the hang.
We routed the syslog to a remote machine and ssh'd into the server to run
vmstat while the test was running.
The syslog did not report anything anomalous.
The last line below is when the system went unresponsive and ceased disk
activity.
Here is the last entries from the vmstat:
10 1 0 17160 192 7457928 0 0 12 23672 20904 6963 0 87
12 1
3 2 0 16948 192 7457472 0 0 8 20396 18024 6743 0 80
19 0
3 9 0 17052 192 7457036 0 0 0 20056 15591 5213 0 73
27 0
2 2 0 16592 192 7457216 0 0 8 17356 13654 4533 0 70
30 0
2 0 0 15884 192 7457324 0 0 0 22896 18982 6707 0 67
33 0
1 2 0 14440 192 7458100 0 0 0 12844 11209 4904 0 68
32 0
0 7 0 14636 192 7457768 0 0 0 13152 11577 5325 0 84
16 0
0 2 0 14488 188 7457536 0 0 8 8384 7667 3651 0 58 42
0
4 4 0 14680 192 7457420 0 0 4 15100 13252 4846 0 67
33 0
9 1 0 15088 180 7456236 0 0 0 8784 7948 4008 0 61 39
0
4 1 0 15208 180 7456060 0 0 0 11800 9225 3492 0 57 43
0
3 1 0 14524 180 7456144 0 0 8 7256 7252 4216 0 61 39
0
0 10 0 15312 180 7455208 0 0 8 9712 8984 3351 0 60 40
0
procs memory swap io system
cpu
r b swpd free buff cache si so bi bo in cs us sy id
wa
11 2 0 14696 180 7455544 0 0 8 12576 9946 4221 0 75 25
0
2 0 0 14608 180 7455212 0 0 8 12832 10840 4363 0 63
37 0
9 1 0 14468 180 7455248 0 0 0 9100 8199 3885 0 62 37
1
-----Original Message-----
From: Mark Grimes
Sent: Friday, August 13, 2004 1:39 PM
To: 'Eric Sandeen'
Cc: 'linux-xfs@xxxxxxxxxxx'
Subject: RE: hang release-1.3.3pre2 from ScientificLinux
Yes, 8GB 133MHz ECC DDR memory.
Also, I have an 8GB swap partition.
modinfo xfs output:
filename: /lib/modules/2.4.21-15.EL.sgi3smp/kernel/fs/xfs/xfs.o
description: "SGI XFS 1.3.3 with ACLs, large block numbers, no debug
enabled"
author: "Silicon Graphics, Inc."
license: "GPL"
uname -r output:
2.4.21-15.EL.sgi3smp
Does an 8GB memory system require the bigmem kernel? I thought that started
at 16GB?
I had to hand copy the bt from the kdb:
Entering kdb (current=0xc0410000, pid 0) on processor 0 due to Keyboard
Entry
[0]kdb> bt
Stack traceback for pid 0
0xc0410000 0 0 1 0 R 0xc0010580 *swapper
ESP EIP Function
0xc0411fc0 0xc0109109 default_idle+0x29 (0xc0410000, 0x998000, 0xc0107000)
kernel .text 0xc0100000 0xc01090e0 0xc0109130
0xc0411fc4 0xc01091a2 cpu_idle+0x42
kernel .text 0xc0100000 0xc0109160 0xc01091c0
0xc0411fd8 0xc010704d stext+0x4d
kernel .text 0xc0100000 0xc0100000 0xc0107070
0xc0411fec 0xc0413880 Start_Kernel+0x160
kernel .text.init 0xc0413000 0xc0413720 0xc04138b0
-----Original Message-----
From: Eric Sandeen [mailto:sandeen@xxxxxxx]
Sent: Friday, August 13, 2004 11:04 AM
To: Mark Grimes
Cc: 'linux-xfs@xxxxxxxxxxx'
Subject: Re: hang release-1.3.3pre2 from ScientificLinux
8G==memory?
Hm, how is xfs config'd - `modinfo xfs` ....
Also which kernels from each distro, RHEL has -bigmem etc...
Can you enable KDB, and see if you can break in?
echo 1 > /proc/sys/kernel/kdb
-Eric
Mark Grimes wrote:
> All,
>
> I've been doing a study of SLESv8 and RHEL with XFS.
> I installed the ScientificLinux on a Dual 3GHz Xeon server from
Supermicro.
> I also have an IBM ProFiber JBOD attached on which I run XFS.
> I've been running specSFS tests.
> With 4GB the test runs great.
> When I run the same test with 8GB installed, the system hangs hard part
way
> through my first mix (1800). No console, nothing. I'm forced to use the
> reset button. I ran it twice just to make sure. Then, on the same system
I
> changed to my SLESv8 disk. With SLES, the same test did not fail. It
> continued on to very nice results. Has anyone else seen problems with
8GB?
>
> -Mark
>
>
>
|