Everhart, Glenn From: ultrajoe@my-dejanews.com Sent: Thursday, August 06, 1998 4:27 PM To: Info-VAX@Mvb.Saic.Com Subject: Re: Moving device driver to 7.1 OK, I've done some checking on stuff. Here's what I've found: In article <1998Aug4.151829.1@eisner>, VAXman@TMESIS.COM wrote: [snip] > > The driver's sole purpose in life is to check the status of various pieces of > > hardware on the militarized equivalent of a Alphastation 3000/500. The > > stuff it checks includes the SCSI adapter, both SCSI busses, ISDN, plus some > > hardware we install. It does this by remapping a buffer pointed to through > > UCB$L_SVAPTE(R5) to the appropriate hardware areas, by banging the > > SPTE behind the afore-mentioned buffer. (Definitely NOT the way I would've > > done it, but that's not my choice.) > > You haven't mentioned how this IRP comes about but if this is a direct I/O > the UCB$L_SVAPTE will point to a DIOBM -- the primary being housed within > the IRP -- and your driver may have an assumption about the number of PTEs > or pages it can access if this is the case. It may be referencing what it > assumes to be PTEs when, infact, it may be subsequent fields of the IRP. The driver is basically using UCB$L_SVAPTE to point to the page whose PFN is stored in UCB$L_SVPN. I wondered if a macro that changed in 7.1 may have been depending on UCB$L_SVAPTE pointing to a DIOBM, so I tried putting this address in part of the UCB extension. This didn't help. The driver is only mapping a single page; it's only affecting one PTE. Based on what another message mentioned (I thought it was this one, but I guess I've misplaced it), I inspected the code that actually reads from the remapped page, wondering if maybe IT was goofing up, and the page mapping was actually working. So I took that code, added a test shell around it, and replaced the page-remapper routine with a $CRMPSC_S, to let it work in user mode (and the standard debugger). The code does read the hardware registers correctly when $CRMPSC does the mapping. Here's the code to do the remapping: PHY_TO_SVAPTE:: .JSB_ENTRY PRESERVE= ; note 1 EVAX_LDQ R16, UCB_L_PHYADDR(R5) ; note 2 EVAX_SRL R16,G^MMG$GL_VPN_TO_VA,R16 EVAX_SLL R16,#PTE$V_PFN,R16 ; note 3 EVAX_OR R16,#, R16 EVAX_STQ R16, @UCB_L_SVPNSVAPTE(R5) ; note 4 MOVAQ UCB$L_SVAPTE(R5), R16 ; note 5 TBI_SINGLE R16,ENVIRON=THIS_CPU_ONLY ; note 6 RSB Notes: 1. I haven't verified if using PRESERVE to save all these registers, even those that are used as inputs & outputs, is causing the problem. Looking at the generated code, R5 isn't getting reused in the middle of this routine. 2. This looked squirrely to me at first, since it's loading a quadword from what appears to be a longword element. The next longword in this case is 0, so this isn't the issue. (I think I'll fix this instruction while I'm in there, though.) 3. My test program has verified the algorithm to this point. R16 does contain the PFN of the physical address passed in. 4. UCB_L_SVPNSVAPTE(R5) points to the PTE of UCB$L_SVAPTE(R5). This value is being set correctly, even though it's a 32-bit pointer; it's using the SPT window to get to the right PTE. (I've confirmed this via SDA.) 5. UCB$L_SVAPTE(R5) should now be remapped to the passed-in physical address. 6. ENVIRON=MP doesn't affect the results here. (This is on a single-CPU system.) Just so I'll know, what does the PTE$M_ASM bit do? Also, what does the PTE$M_WINDOW bit (which $CRMPSC sets) do? Thanks for the suggestions. Joe -----== Posted via Deja News, The Leader in Internet Discussion ==----- http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum