TIP: Click on subject to list as thread! ANSI
echo: cis.os9.users_group
to: Kevin Darling 76703,4227 (X)
from: Nick Hall 100330,2555
date: 1994-08-09 19:30:46
subject: #20191-#alm_delete bug

#: 20197 S5/OS9 Users Group
    09-Aug-94  19:30:46
Sb: #20191-#alm_delete bug
Fm: Nick Hall 100330,2555
To: Kevin Darling 76703,4227 (X)

Kevin,

It appears that the problem is caused when a system-state 'process' (i.e a
driver) takes greater than 1 tick's worth of CPU time. Assuming the clock tick
is on a higher interrupt, the system global DTick value is still incremented,
but if the value goes past the alarm time when the driver returns, the hang can
occur. I guess the more alarms you have and the more frequent they go off, the
greater the chance of hitting the problem.

This problem has been fixed in v3.0 (so I believe) and hence the patch to our
kernel - thanks to Microware UK, who got us out of a nasty problem with only
days to going live with 2 new systems. Two useful utilities from Microware were
'alarms' and 'sleeps', which provide info on the alarm and sleep queues.

Whilst the problem no longer seems to cause the freeze, we still don't what is
soaking time in system-state. I'm looking into another problem of perceived
system slow-down when user interfaces load the network, but after reading your
message perhaps the two are related! You're not using OS-9 ISP (on MVME167/147
boards) by any chance?!

Regards,
Nick.

There is 1 Reply.

SOURCE: compuserve via textfiles.com

Email questions or comments to sysop@ipingthereforeiam.com
All parts of this website painstakingly hand-crafted in the U.S.A.!
IPTIA BBS/MUD/Terminal/Game Server List, © 2025 IPTIA Consulting™.