Everhart, Glenn From: schenkenberg@eisner.decus.org Sent: Tuesday, August 04, 1998 1:43 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: Moving device driver to 7.1 In article <6q75t6$bck@usenet.pa.dec.com>, hoffman@xdelta.enet.dec.nospam (Hoff Hoffman) writes: > > > Follow-ups set to comp.os.vms. ...and VMSnet.internals (where this discussion is more aptly suited) has been reaffirmed. > In article , jsewell@iu.net (Joe Sewell) writes: > :They have a device driver, part of our product, that goes out & scans > :various hardware (some of it DEC-supplied, some of it our own stuff); this > :is used as part of online diagnostics. It's written in MACRO-32, with > :Alpha extensions (EVAX_LDQ et al). > > With OpenVMS Alpha kernel-mode code, I'd tend to move to DEC C and > away from Macro32 code. Why blame the medium when the message is at fault? If there's improper logic in the existing macro code, translating that logic to C would only produce the same problem -- not to mention the possibilities of newly introduced bugs from the rewrite. > : It works fine under V6.1, but it > :doesn't under 7.1. > > The addition of 64 bit addressing can be enough to confuse most any > kernel-mode code that directly references PTEs. And there were various > other changes to the kernel between OpenVMS Alpha V6.1 and V7.1, as well. > > :I believe the heart of the problem is in its manipulation of a system > :PTE. I've determined it calculates the right PFN, and it seems to set the > :right PTE bits (PTE$M_VALID ! PTE$M_KRE ! PTE$M_KWE ! PTE$M_ERE ! > :PTE$M_EWE ! PTE$M_ASM). Yet the driver fetches garbage, not the proper > :CSR's. (I can use a C program to access the same page, using SYS$CRMPSC > :to map to the correct PFN. It sees the expected data.) > : > :Curiously enough, the driver doesn't bugcheck. It just doesn't seem to > :look at the right stuff. > > The kernel-mode device driver code should never have loaded on this > system (well, not without somebody erroneously taking the "blade guards" > off), and the device driver probably should have been coded to bugcheck > (or to take itself offline, and reject all requests with a predetermined > condition status) as soon as it found critical (and unrecognized) > differences in the system data structures it references. Well, page tables didn't changes from V6.n to V7.n -- just their location in the virtual address space. I've a bit of code which accesses process's page page tables via a mapping of the process's PTBR and it works unchanged from V6.n code to V7.n code. In fact, strange as it may seem, the system idents to which this image is tagged do change for memory management but I suspect only because the the use of LDR$ALLOC_PT. Besides a few PALcode calls to invalidate TBs, there's nothing else that references the base image other than CTL$GL_PHD. (MEMORY_MANAGEMENT,PROCESS_SCHED and SHELL) > :Before I get the lab ops guys to set up an XDELTA configuration for me, > :does anybody know of any changes between AXP VMS V6.1 and 7.1 in this > :area? > > There are a few manuals that may be of interest in the OpenVMS V7.x > documentation set, including the release notes and new features manuals > for the releases between V6.1 and V7.1 (inclusive), the _OpenVMS Alpha > Guide to 64-bit Addressing_, and the _OpenVMS Alpha Guide to Upgrading > Privileged-Code Applications_. Quite possibly an address being manipulated as a 32 bit address. The list of manuals 'Hoff' lists above cover some of the common gotchas. Also, be- ware that certain macro32 addressing modes which might be used to manipulate an address will only do so as a 32 bit sign extended quantity. -- VAXman- VAXman@TMESIS.COM OpenVMS APE certification number: AAA-0001 ... and in the end, the money you take is equal to the money you make.