|
: I need a extension version of axpvms wp facility which
: has a capability to monitor read-access of system space
: as operand.
With a little more information around the problem, we might
be able to offer some suggestions. (The OpenVMS Alpha
watchpoint driver is basically what you need, but switching
the handler over to catch both write and read access to system
space data will quite conceivably result in serious performance
overhead.)
An obvious alternative would be the system code debugger...
(This is based on the standard OpenVMS debugger, and allows
symbolic debugging of the OpenVMS kernel...)
|
| re:-1
Hi,
Thank you for information.
>>> With a little more information around the problem, we might
>>> be able to offer some suggestions. (The OpenVMS Alpha
I'm in aid of debugging work of my oem customer on v6.1.
(Maybe) one of his kernel code cause system crash, once or
twice in a week.
>>> watchpoint driver is basically what you need, but switching
Purhaps, you were talking about future wp???
Our guy looked codes in vms 6.1/7.1 wpdriver listing.
He could not see any supported codes (except a piece of code in
fdt routine) in the driver.
it seems that driver still monitor only kw (kernel mode write)
access for nonpaged region (as it was before).
all,
any information appreciated.
/sayori
|
|
Without information on the crashes, we can only guess...
: Thank you for information.
Hackers is not the best source for customer support...
: >>> With a little more information around the problem, we might
: >>> be able to offer some suggestions. (The OpenVMS Alpha
: I'm in aid of debugging work of my oem customer on v6.1.
: (Maybe) one of his kernel code cause system crash, once or
: twice in a week.
The crashdump is often interesting here. I'll assume your customer
has rigged for full crashdumps, and has been saving and examining the
copies of the crashes.
You may/will want to seek assistance looking at these crashdumps.
: >>> watchpoint driver is basically what you need, but switching
: Purhaps, you were talking about future wp???
Nope, I'm not aware of that change being planned here in OpenVMS
engineering. You'll need to acquire the sources and recode it
yourself. (This _is_ hackers, after all. :-)
: Our guy looked codes in vms 6.1/7.1 wpdriver listing.
: He could not see any supported codes (except a piece of code in
fdt routine) in the driver.
: it seems that driver still monitor only kw (kernel mode write)
: access for nonpaged region (as it was before).
WPDRIVER protects the specified page against write access, and
"catches" write failures (access violations) against the page.
The access violation handler then determines where the access
was attempted, permitting accesses to addresses to locations on
the page other than those under survellience, and trapping those
specifically to the watched addresses. A similar sequence --
protecting the page against all access -- would be the modification
needed for your request.
We can probably get you a copy of the WPDRIVER code, but it's not
something that can be released to a customer without the permission
of one of the local OpenVMS product managers. (And if you extend
and debug WPDRIVER, we can probably get the new version loaded back
onto the source library here in OpenVMS. :-)
I'd start with the crashdump, trying to figure out what is going on
when the system falls over. I'd look at using pool poisoning, and
I'd look at extending the failing code to maintain a log of activity,
such as a circular buffer containing tracing information from the last
`n' event(s) of interest... (You have a far better understanding of
the problem than the folks reading this notes string -- we lack the
context around the crashes...)
(I'm assuming this involves site-specific and/or customer code, as
I'd have expected you to have already loged an IPMT on standard code.)
If this code is not site-specific, I'd definitely run this past the
CANASTA crashdump analysis tool -- see 233.* in VAXAXP::VMSNOTES for
how to send the CLUE output to the CANASTA e-mail servier -- and see
if it is recognized...
|
| : <<< Note 1704.8 by NERVE::SAYORI >>>
: -< thank you for suggestion >-
Huh?
: <<< Note 1704.9 by NERVE::SAYORI >>>
: -< any info.? >-
Huh?
I have not seen any information around the crash, nor any specifics
around the problem(s) you are trying to solve here. (You've asked
one very specific question with no surrounding context -- I have no
idea what the problem you are trying to solve is... Further, while
it can sometimes be trivial, it is usually difficult to solve these
sorts of apparently-random-system-crash problems without access to
the relevent kernel-mode source code.)
|