Subject: | |
From: | |
Reply To: | |
Date: | Fri, 9 Nov 2001 13:30:11 -0500 |
Content-Type: | text/plain |
Parts/Attachments: |
|
|
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 *
|
|
|