[1.] One line summary of the problem:
Kernel 2.2.6 hanged after generating an oops. alt-sysrq did not work
[2.] Full description of the problem/report:
System is a web,mail (free web based email service) running apache 1.3.4,
sendmail 8.9.3. I do not think this is a hardware problem becouse with
kernel 2.0.3x there were no such problems. kernel is standard 2.2.6 with
RAID support. I've experienced lockups with 2.2.5-ac3, 2.2.5 but I was
unable to get the oops log. With older kernel versions the uptime was no more
than one day, after that there were an increasing number of processes stuck
in D state, then lockup.
[3.] Keywords (i.e., modules, networking, kernel):
kernel
[4.] Kernel version (from /proc/version):
Linux version 2.2.6 (root@zerg.codec.ro) (gcc version 2.7.2.3)
#16 Thu Apr 22 12:51:22 EEST 1999
[5.] Output of Oops.. message (if applicable) with symbolic information
resolved (see Documentation/oops-tracing.txt)
oops is attached compressed becouse is rather big. symbolic info was
resolved by syslog.
[6.] A small shell script or example program which triggers the
problem (if possible)
-
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
[root@zerg]:linux/:p1:# . scripts/ver_linux
-- Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux zerg.codec.ro 2.2.6 #16 Thu Apr 22 12:51:22 EEST 1999 i586 unknown
Kernel modules 2.1.85
Gnu C 2.7.2.3
Binutils 2.9.1.0.19
Linux C Library 2.0.7
Dynamic linker ldd (GNU libc) 2.0.7
Procps 1.2.9
Mount 2.8a
Net-tools 1.50
Kbd 0.96
Sh-utils 1.16
Modules Loaded serial nfs lockd sunrpc ne 8390 unix raid0
[7.2.] Processor information (from /proc/cpuinfo):
[root@zerg]:linux/:p1:# cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 5
model : 4
model name : Pentium MMX
stepping : 3
cpu MHz : 233.867284
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : yes
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr mce cx8 mmx
bogomips : 466.94
[7.3.] Module information (from /proc/modules):
[root@zerg]:linux/:p1:# lsmod
Module Size Used by
serial 18132 1 (autoclean)
nfs 27856 1 (autoclean)
lockd 29000 1 (autoclean) [nfs]
sunrpc 48492 1 (autoclean) [nfs lockd]
ne 5984 1 (autoclean)
8390 5944 0 (autoclean) [ne]
unix 10056 31 (autoclean)
raid0 1692 1 (autoclean)
[7.4.] SCSI information (from /proc/scsi/scsi)
-
[7.5.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):
the server runs sendmail with an alias list of about 25000 users which
is ocasionally rebuilt (when there is a new user created). the rebuilding
of this list is slow and often a newaliases command take a couple of
minutes but sometimes it is stuck waiting to lock the aliases file.
if such hanged newaliases are killed then sometimes the kernel hangs.
now the oops seem to me to be the result of:
iput: Aieee, semaphore in use inode 00:00/118969, count=0
one previous oops seemed to be the reult of something like:
Free list corrupted
[X.] Other notes, patches, fixes, workarounds:
TIA,
-- Catalin Muresan CM1206-RIPE CODEC Electronic Products voice: +40-64-432450 Internet Services Department email: cata@codec.ro ----------------------------------------------------------------------- 11:44am up 18 days, 18:46, 10 users, load average: 0.35, 0.32, 0.24--LZvS9be/3tNcYl/X Content-Type: application/x-gunzip Content-Disposition: attachment; filename="oops.gz" Content-Transfer-Encoding: base64
H4sICBXHJjcCA29vcHMAzZprb9s2FIb3eb+C+zBgW7OF94uBDgiGbRhQbAW6fhqKQqKoxGhq e5LSXX79qJslObZ5WHNFhARQKPo5h4dHr18JudlViGpE8IrpFcfoX1fdoneu2rj7FXq9yfJ7 h5otuss2hT/rL6BfX794gXbb9aZxFSpc5Ur/u7EOZQ36sK6ah+weZUVRubpGuD2o4ejzm3Oh 7EPlEc233zd1/Z2tGHqOMKE58R++Ql8uBwKob3aFa2cPR2D2b9tdvUKAiT+8fL1C/gjN+/GX l/087K//UW/tu7e12xTv69tnhIprouSbEOGnFzc/v+qSIphyGZjusr9XQ5kL4gO73P9tGaVl yXn7tx2vt4v0fxfddcwKykOLcfV6ZCnbfXY9xhK6i7Xz14Vyzsnuer0b59PQlhdd3UmHmU7r 8fT8h19WW9u2113T7Ar01W5drBDlivArtBsubSo/hNkVqpvMvttlt+55l5lP/usA/VX7iVlR 99XcLxVrrEue2bE4fKrwfvJUp/PRhqOdLbHOBhLBhyd4dmIxYWVGxZTRtEvgaMPahk7oScT2 bKNni9xPfpxI6K7J7u/R71Vm3Qr1N8Nf1bpxz4hg10TyN4tBPA79U4/TjLymTPZjjXv/1nre M0GvhR8Lhd4WPqjOkSoRs0gb5Ivju9L/+EHOh/OyRAVur1qGNEOWe1x7Eq7kevfQ+DZ2H9Ze +jBe+WqsNz4oIkQbhX3frf3i77IaZffrrHb1F5cApflY4M3a76u/Ddz7bHe3rZyHoofaDewu znUf4QrZ7cOmeY4vWjkFJMrOAc0E5MpQLS8FHmaYHKhSAzUAKGKA5FIgW2E6ABXmBpKgASdo MDFJgdpoQBsKCmxDqTWVgK4R/H9yUBjzQKhjDko4ZxYOahgIoM47qMPZJx3U4cRTDupw3tJB NXb3tnL2Q2+gKL0mDOs3IcTcQmGsAtMnCzVYpM5C0cwUrsCjhbKEubxQewsFLE9nofovUN+S g4Xq2CWeWSia41zwvYXqYuchdpSFOvzwUQsluMEHFkouHFSb2BEHdQgfHFS/zsEdkZlxkN5l 0EJaxx95CuK/kv3hWpezL/n5aMPRRrOdOxrLiXEplOR562mEzTPZI63Fp1ODRpu82LiZfVhm J2R/ielltM7TdS5LSxeKtnBQ641rpruB+5tB6tFDjcNC+4cMOo1mhXdbrbXCg7Xqhwy+phSD nNWjlEZnxSnyusQMKjRSApWq9VEyaweFRKZAufYLRg63Lsv/UNKeW/UogIDJpm/B9eYWVe7P B1c3x8WSYGdMFghw9HHT2XL5uNkPBFABsRRQsRRAsRSXi6WIE0txVCy7OsvpeVOrQ7HMfPkm sRzmB9hHxbJlz8WSM0JYMYllFzsPVSpOLEVYLJl/NidLsSTcLJ83fWbH1FIcV8tuocfVkjNZ KBtUy77m56ONaumj9Wo51rNXS2qWapnZ9uHwVGrQaLPH42E3+7D5XC27S61azqOdV0vx9NRS fGK1vNy1JgfKT2eDZVjZccHdQtmHgQAqoOwSquwSqOzycmWXccouQTa45Gau7Ngwy/KgDZYg G+zZhza4NDMb3MbOQ+w4ZZcwG0yXyq6Wwt4mdkzY5Qkb3K7ztLBLfl7Y9yU/H21vg0uu9za4 LWcn7KXSM2HvkJ1DPZEaNNrMBg+b2YdVCxvcXups8CzaeWGXT0/Y5f8q7F5nScwbHRbSYdO+ sYG/gZEQIId+U2BKBQYAQ++cyJghVpxdyjtYsTKJgZoDgDJmTyAZ6sQl1BEJGgIAmsQJxrxX NCotkGDAigmOaRpAhoTGZChSAyEZRrQ1ITg1kAKAOgYoUgMBNaQYqK6MCUMvBh5kSAE1pFHf UCIp0GeoAcCYxmY4NZCkBkI2RcQAAQLrWwsO5ORS4KyxtWFYQpac+DuPxtzK3CQGQoxSHJCk BorUQHUp8GPkMCZDqVMDU7eNSt02KnXbqON++LPpiAWKxG3DyFMTm4/pa/NJgYd9jVMD6aXA xf8qCJBtiEpQpU0Qy8QJapw2QS2e2o4seSBTE1VAnhqYfIsBPchi7D/jiYEGcBuzGPtveGog oK1ZhFunGKcGktRAmhrI0wL9c2PqDAFiw1gEkJDUQMim8Jglm9RAgMCymKdGitMCKYVkqGM2 BdI2JiZDwJJ5TGNDvkXjgCIxEPL2Ii5DmTpDnhoI2eUYceA8NVCkBprEQJG6hgLShzF6CHnB EvH/2b5tII0d8UacSkiGMQJ74o3Nf5pqMnhBNgAA
--LZvS9be/3tNcYl/X--
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/