Why does the system hungs?

[T. E.]

Hello there,

has anybody out there an idea, why the system hungs during execution of the
script with an Kernel Error (or Kernel Exeption ... not quite sure anymore
how its called ...):
#!/bin/sh
#
DATADIR=/FTS/DATEN/21
WORKDIR=/q8/tmas/WEAT
#
if [ `ls $DATADIR | wc -l` -gt 0 ] ; then
mv $DATADIR/* $WORKDIR/an_weat
cp $WORKDIR/an_weat/* $WORKDIR/backup/an_weat
cd $WORKDIR/an_weat
ftp -n 160.83.xx.yy <<-EOF
login USERNAME
password PASSWORD
debug
prompt
bin
type
lcd /q8/tmas/WEAT/an_weat/
mput *
bye
EOF
#
fi
#
exit 0

I tested that script on an linux machine, and it worked fine.
The SCO OpenServer 5.0.5 system just hungs .... :(
It starts transfering data, and stops during doing so - simply hungs, with
an screen showing info of the memorydump, and saying "Now its safe to
shut-off the system, or reboot by pressing any key" (or something like
that).

Thanks in advance!!

c y
Torsten

[to...@aplawrence.com]

T. E. <pele...@hotmail.com> wrote:
: Hello there,

: has anybody out there an idea, why the system hungs during execution of the
: script with an Kernel Error (or Kernel Exeption ... not quite sure anymore
: how its called ...):
: #!/bin/sh
: #
: DATADIR=/FTS/DATEN/21
: WORKDIR=/q8/tmas/WEAT

(script deleted)

: I tested that script on an linux machine, and it worked fine.

: The SCO OpenServer 5.0.5 system just hungs .... :(
: It starts transfering data, and stops during doing so - simply hungs, with
: an screen showing info of the memorydump, and saying "Now its safe to
: shut-off the system, or reboot by pressing any key" (or something like
: that).

Ordinarily the phrase "or something like that" will engender severe
and well deserved chastisement. If you want help with a problem,
it behooves you to describe said problem accurately and the make
the effort to transcribe error messages precisely.

In this case, we know what you mean (you have a trap message), but you
have left out the most important piece of information: exactly what the trap
number is.

The most common trap seen is E, which is explained at
http://aplawrence.com/Unixart/trape.html

However, you might be seeing a panic that included something like
"PANIC: HTFS: Free block freed on HTFS" or similar language indicating
that a block already on the free list was found in an inode being
freed. That would be HTFS file system corruption, fixable by
a single-user fsck -ofull and on some systems preventable by
proper patches. The reason I suspect something like this is
that you only mention this happening during a certain script,
which might mean that it is a particular file that causes the problem.

Or you might be seeing something else entirely that could indicate
adaptor driver problems.

But there's no point in me or anyone else guessing: make it happen
again and this time write it all down completely.

You mighrt also read http://aplawrence.com/newtosco.html#newsg for
advice on how to ask a better question here.

--
to...@aplawrence.com Unix/Linux resources: http://aplawrence.com
Inexpensive phone/email support
Download Free SCO Skills Test: http://pcunix.com/skilltests.html

[T. E.]

<to...@aplawrence.com> schrieb im Newsbeitrag
news:bbv3fv$eph$1...@pcls4.std.com...

Hi,

so I started that script again.
First time it run without any probs, but when I staretd it a second time the
system got a trap.
This screen content was shown:

<snip>
cr0 0x80010015 cr2 0x464C458B cr3 0x00002000 tlb 0x00000000
ss 0x00002810 uesp 0x00000001 efl 0x00010207 ipl 0x00000005
cs 0x00000158 eip 0xF0094C84 err 0x00000000 trap 0x0000000E
eax 0x00000000 ecx 0xF50153A0 edx 0x00002C04 ebx 0x464C457F
esp 0xE0000924 ebp 0cE0000954 esi 0x300A680A edi 0x00000000
ds 0x00000160 es 0x00000160 fs 0x00000000 gs 0x00000000
cpu 0x00000001

PANIC: k_trap - Kernel mode trap type 0x0000000E
Cannot dump 130958 pages to dumpdev hd /1/41): Space for only 128000 pages

Dump not complete
Warning: aac: system coming down

** Safe to Power Off **
or
** Press Any Key to Reboot **

</snip>

Thanks!

c y
Torsten

[to...@aplawrence.com]

T. E. <pele...@hotmail.com> wrote:
: so I started that script again.

: First time it run without any probs, but when I staretd it a second time the
: system got a trap.
: This screen content was shown:

: <snip>
: cr0 0x80010015 cr2 0x464C458B cr3 0x00002000 tlb 0x00000000
: ss 0x00002810 uesp 0x00000001 efl 0x00010207 ipl 0x00000005
: cs 0x00000158 eip 0xF0094C84 err 0x00000000 trap 0x0000000E
: eax 0x00000000 ecx 0xF50153A0 edx 0x00002C04 ebx 0x464C457F
: esp 0xE0000924 ebp 0cE0000954 esi 0x300A680A edi 0x00000000
: ds 0x00000160 es 0x00000160 fs 0x00000000 gs 0x00000000
: cpu 0x00000001

: PANIC: k_trap - Kernel mode trap type 0x0000000E

OK, and I already referred you to http://aplawrence.com/Unixart/trape.html

Was there something there you need more explanation of?

[T. E.]

<to...@aplawrence.com> schrieb im Newsbeitrag
news:bc0a5c$2us$1...@pcls4.std.com...

To be honest: Yes .... ;-)
Well, I'm not that experienced with those errors, and my thoughts are this:
- if its a prob with the used RAM, shouldn't it also happen the first time
the script runs?
- a damaged/broken CPU wouldn't make the system run for months, would it?
- also the installed drivers wouldn't let the system run for month .... I
guess
- an fsstat showed nothing, also using fsck showed no probs
- patches might be a reason, as we never installed any (the system simply
run, and never touch a running system ... ;))

I merely hoped somebody could have said: the script os ok, and there
shouldn't be any probs with the script itself. But those probs result b/c
patch XXX is missing .....
As I'm absolute not familiar with any SCO OpenServer version I was simply
looking for any reply.

But ok, I'll ask our guys to install each 5.0.5 related system patch from
ftp://ftp.sco.com/pub/openserver5/, naybe the prob will be fixed by doing
so.

Thanks a lot!!!!!!!!

c y
Torsten

[to...@aplawrence.com]

T. E. <pele...@hotmail.com> wrote:

: <to...@aplawrence.com> schrieb im Newsbeitrag

No, not necessarily. In fact, since the FIRST time it runs file data gets
read into cache, and is read from cache on subsequent runs, a memory
problem could be exactly the issue.

: - a damaged/broken CPU wouldn't make the system run for months, would it?

As that article explained, a damaged cpu is extremely unlikely.

: - also the installed drivers wouldn't let the system run for month .... I
: guess

Correct.

: - an fsstat showed nothing, also using fsck showed no probs

: - patches might be a reason, as we never installed any (the system simply
: run, and never touch a running system ... ;))

Bad practice. Many of these patches are quite important. Even if they
have nothing to do with this problem, you need to apply at least RS505a.
See http://aplawrence.com/newtosco.html

But if it has been running, it probably is hardware..

[T. E.]

to...@aplawrence.com wrote in message news:<bc1lq4$n10$1...@pcls4.std.com>...

Hi,

just to keep you informed: its solved so far!!! :-)
I installed rs505a first, and rebootet the system, but the problem
still occured.
So I also installed oss497c, and rebootet the system once more - the
problem didn't occur anymore.
But after it there was a problem with the installed samba (2.2.1a), it
didn't work anymore. So I completly deinstalled it, rebootet the
machine, and installed samba 2.2.6, put the formerly used smb.conf to
/etc/samba.d and rebootet the machine once again.
Now all stuff seems to work fine.

Thanks a lot!!!

c y
Torsten