HP3000-L Archives

November 2001, Week 2

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
Jon Diercks <[log in to unmask]>
Reply To:
Jon Diercks <[log in to unmask]>
Date:
Fri, 9 Nov 2001 13:30:11 -0500
Content-Type:
text/plain
Parts/Attachments:
text/plain (29 lines)
Thanks for the clarification, Bill. We have machines running 6.0, 6.5 and 7.0 with SD enabled on all of them. I had noticed that in several months of running with SD, I have never seen it successfully prevent an SA on 6.5 nor 7.0. Maybe once on 6.0, but we don't use that box as much.

I'll disable SD on >=6.5, and watch for a future fix.

--Jon

On Thu, 8 Nov 2001 17:30:39 -0700, Bill Cadier <[log in to unmask]> wrote:
>The SR is JAGad91401 aka 8606222286
>
>The problem is that when the subsystem dump facility is invoked by some
>event that would cause a system abort it attempts to dump a memory
>management known system object (KSO) that has read and write
>permissions of 0, so only processes at ring 0 which is pretty much only
>the lower level portions of the OS can touch it. The failure to access this
>object prompts the subsystem dump facility to just let the system fail
>believing that something is really wrong and a memory dump is the only
>way to diagnose it.
>
>Just enabling subsystem dump does not cause any problem, it just does not
>prevent one.
>
>This particular object is accessible on 6.0 and earlier so the problem won't
>occur there.
>
>We're fixing it but I have no patch ID or ETA just yet.

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2