Kernel Panics After Updating OSR5.0.4c Patches

[Lucky Leavell]

OS: OSR5.0.4c with SMP (2 PII-400's), VDM and 256MB RAM
Old Patches (in Order): rs504c, oss449f and oss601a

The system is heavily loaded with 50-60 MF COBOL application users. Sar
stats and SarCheck both inidicate heavy CPU and I/O loading.

Anyway, earlier this month I peeled off (in order) oss601a (both parts),
oss449f (misapplied) and rs504c. I also removed oss469c which was partially
loaded but did not install properly).

I then reapplied (in order) rs504c, oss496a, oss601a, oss469d, oss471e,
app612a and (later) oss605a.

Now we get 1-3 times/week Kernel Mode Panics:

PANIC: k_trap - kernel mode trap type 0x0000000E

The register values for eip, cs and cpu are constant across all dumps where
I have the information:

eip = 0x00000000
cs = 0x00000158
cpu = 0x00000001

(I have posted a separate message about the inability to read the dumps
using crash.)

I am familiar with several c.u.s.m threads from earlier this year
implicating oss469d as a possible culprit. I can peel off the patches I
applied and substitute oss469c for oss469d if that would cure the problem.
Comments/Suggestions?

(I seem to remember that 469c should be applied BEFORE oss601a where oss469d
had to be applied AFTER oss601a. Comments or other patch dependencies?)

Thank you,
Lucky

Lucky Leavell Phone: (800) 481-2393 (US/Canada)
UniXpress - Your Source for SCO OR: (812) 366-4066
1560 Zoar Church Road NE FAX: (812) 366-3618
Corydon, IN 47112-7374 Email: lu...@UniXpress.com
WWW Home Page: http://www.UniXpress.com

[John Gray]

Lucky Leavell wrote:

> OS: OSR5.0.4c with SMP (2 PII-400's), VDM and 256MB RAM
> Old Patches (in Order): rs504c, oss449f and oss601a
>
> The system is heavily loaded with 50-60 MF COBOL application users. Sar
> stats and SarCheck both inidicate heavy CPU and I/O loading.
>
>

Please enable the kernel debugger. Edit the /etc/conf/sdevice.d/scodb
file and change the N to Y. Then cd to /etc/conf/cf.d and run ./link_unix
reboot.

The next time the kernel panics you will see the registers and if you type
stack and hit return you will see what the kernel tripped over. The
function listed at the top will be the function that had the problem.
This isn't always 100% but it can give you a pretty good idea where to
start looking and post another question.

-john