Re: Testing for the presence of an attached IO device
- From: Stephen Hoffman <hoff@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Sat, 07 Oct 2006 14:01:36 -0400
Villy Madsen wrote:
Is there a way of verifying if a specified IO address is valid (i.e. has something attached) ??
Can I use the PROBE instruction ??
Is there a system service that I can call to do that - although I could probably still scribble up the 4 or 5 instructions of macro needed to build a subroutine....
The following contains a couple of guesses, and some assumptions.
What's the particular run-time context here? A device driver is usually configured automatically by OpenVMS, when the system autoconfiguration processing runs through its configuration sequence -- probing the contents of the attached buses. If the device CSRs are set correctly (and correctly for the whole flock of controllers present on a Q-bus or Unibus, and that's a requirement based on the way the configuration processing works with the floating CSR model implemented on these older buses), you'll either have the DN11 device driver connected, or you'll not have the device connected.
Device drivers can and do use probe, but usually for accessing user memory and rather less commonly in CSR space, which is where the device announces itself. (Most drivers usually know the layout of the associated device's control and status register(s) (CSR(s)), and use addressing details retrieved out of the DDB and UCB. When messing in bus memory space, it's usually via allocation routines written into bitfields within the CSR, so the driver (still) knows where the memory space is.)
If within a VAX device driver, you'll want to use a machine check protection block, see the $PRTCTINI/$PRTCTINI mechanism in the OpenVMS VAX device driver. (Can't say I've ever tried this sequence looking for an emulated Unibus DN11 on an emulated VAX; only with VAXBI.)
At DCL, there's f$getdvi("EXISTS").
With typical system services and user-mode code, just aim a sys$getdvi (for whatever) and catch the error that would get returned for a non-existent device. I'd tend to expect to see the SS$_NOSUCHDEV condition here.
User-mode code can also occasionally get rather more directly involved in this area and in kernel-mode memory access, but it's usually via directly mapping the device. (I'm guessing you are not mapping the device from the user-mode code via the OpenVMS VAX CONINTERR connect-to-interrupt mechanism. This particular interface mechanism never really made it across to OpenVMS Alpha
or OpenVMS I64, but we are discussing OpenVMS VAX here so it's a possibility...)
I might guess that this situation is a case where whatever host software accesses the (missing) DN11 "control" device, and gets itself into some sort of a loop. Accordingly, I'd be looking at the error path(s) in whatever is accessing the DN11 "control" device. (And I'm inferring rather much here.) This situation and this approach doesn't involve any sort of physical memory probe, if it's user-mode code attempting to access a device. I've certainly encountered cases where a missed or mishandled test has caused the code to head into the weeds, and has generated I/O spikes. There's a list of common coding errors over in (1661) of the Ask The Wizard area, if that might help with a review.
.
- References:
- Testing for the presence of an attached IO device
- From: Villy Madsen
- Testing for the presence of an attached IO device
- Prev by Date: Re: DS10L Lottery Starts 10/5/2006 09:00 Ends 10/6/200606 17:00EST
- Next by Date: Re: memory question: AS800 vs AS1200
- Previous by thread: Re: Testing for the presence of an attached IO device
- Next by thread: Excessive IO on my emulated vax
- Index(es):
Relevant Pages
|
