| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 292.1 | | STAR::LEWIS | | Thu Mar 06 1997 14:24 | 3 |
| There's not a specific driver example, but there are example
calls and discussion in the "Writing OpenVMS Device Drivers in C"
book. Does your customer have a copy of that book?
|
| 292.2 | Source Listings Available... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Mar 06 1997 16:55 | 4 |
| : Is there an example available anywhere?
The OpenVMS source listings are available for purchase on CD-ROM...
|
| 292.3 | What's the problem? | STAR::CROLL | | Fri Mar 07 1997 09:03 | 9 |
| Perhaps the customer could give us some specifics about the problems he or she
is having? Is it simply a "how does this work" kind of question, or are there
specific problems he or she is running into?
It's interesting for us to know this stuff, as it may lead to improvements in
either the book or the code. Besides, with more specific questions we may even
be able to help answer them....
John
|
| 292.4 | Customer e-mail | BSS::JILSON | WFH in the Chemung River Valley | Fri Mar 07 1997 10:02 | 129 |
| Here is the customer's e-mail concerning his problem. Probably not enough
context and I believe the customer isn't passing some value correctly.
Jilly
Attached is a copy of the dma load map routine which I am debugging.
As listed here, the exe_std$readchk and exe_std$read are not included.
This version fails at the ioc$load_map call since irp->svapte was zero.
When adding the exe_std$readchk and exe_std$read to fill the irp values,
(prior to ioc$alloc_crctx) the call to ioc$alloc_cnt_res fails with
INVEXCEPTN Exception while above ASTDEL due to access violations at :
IOC$INIT_IO_BRIDGE_C+4FC inst STL R23(R24) where
R23=FFFFFFFF.80CEE350 & R24=00000000.00002518 .
Access violation loc 0000000000002518.
(In module SYS$CPU_ROUTINES_0D02 offset 2414.)
Attachment: dma mapping portion of the **** memory driver.
=============8<--------(cut here)-------->8=================
int em$dma_map (IRP *irp, PCB *pcb, EM_UCB *ucb, CCB *ccb )
{
struct epci_dma *epcip = (struct epci_dma *)irp->irp$l_qio_p1;
int status;
ADP *adp;
CRB *crb;
VEC *vec;
IDB *idb;
MCJ *mcj;
CRCTX *crctx;
char *qioh;
#ifdef DEBUG
extern void ini$brk(void);
#endif
struct iohandle *iobar0; /*declare ptr to ioh for bar0 */
struct iohandle *iobar1; /*declare ptr to ioh for bar1 */
struct iohandle *iobar2; /*declare ptr to ioh for bar2 */
struct iohandle *iobarrom; /*declare ptr to ioh for barrom */
crb = ucb->ucb$r_ucb.ucb$l_crb;
vec = &crb->crb$l_intd;
idb = vec->vec$l_idb;
mcj = idb->idb$q_csr;
qioh = &mcj->mcj$q_entries;
iobar0 = qioh;
qioh = qioh+16;
iobar2 = qioh;
adp = idb->idb$ps_adp;
if (ucb->ucb$l_em_type != UCB$K_NONE)
return (call_abortio (irp, pcb, (UCB *)ucb, EIO) );
/* STORE THE PARTITION PARAMETERS */
ucb->ucb$l_dma_size = epcip->pci_dma_size;
ucb->ucb$l_dma_offset = epcip->pci_dma_offset;
/* allocate crctx (note that third parameter is optional */
ioc$alloc_crctx ( adp->adp$l_crab, &(UCB *)ucb->ucb$l_crctx, 0 );
#ifdef DEBUG
ini$brk();
#endif
/* fill it up */
crctx->crctx$l_item_cnt = ( ucb->ucb$l_dma_size / PAGESIZE + 2 ) *2 ;
/* *2 is for read/write */
crctx->crctx$l_callback = 0;
/* count the resources */
#ifdef DEBUG
ini$brk();
#endif
status = ioc$alloc_cnt_res ( adp->adp$l_crab,
&(UCB *)ucb->ucb$l_crctx,
crctx->crctx$q_context1,
crctx->crctx$q_context2,
crctx->crctx$q_context3);
if (status == 0)
return (call_abortio (irp, pcb, (UCB *)ucb, EIO) );
/* should check for crctx$v_item_valid in crctx$l_flags
* and item # in crctx$l_item_num
* else status = insfmemreg
*/
/* here's the UNIX code ...
flags = (DMA_CONTIG | DMA_OUT | DMA_SLEEP | DMA_ALL);
status = dma_map_alloc((u_long)epcip->pci_dma_size, ctrlr,
&ucb->ucb_dma_whan,flags);
*/
/* load 'em up */
ioc$load_map ( adp,
(UCB *)ucb->ucb$l_crctx, /* maybe should update for read
*/
irp->irp$l_svapte,
epcip->pci_write_addr,
(UCB *)ucb->ucb$l_dma_whan);
/* now, do it again for read (hopefully already allocated ) */
/* load 'em up */
ioc$load_map ( adp,
(UCB *)ucb->ucb$l_crctx,
irp->irp$l_svapte,
*epcip->pci_read_addr,
(UCB *)ucb->ucb$l_dma_rhan);
ucb->ucb$l_em_type = UCB$K_DMA;
#ifdef DEBUG
ini$brk();
#endif
return ( call_finishio (irp, (UCB *)ucb, SS$_NORMAL, 0) );
}
|
| 292.5 | | STAR::LEWIS | | Fri Mar 07 1997 15:53 | 4 |
| It looks like the failure is happening during the removal of a
descriptor, which implies to me that all the resources are nearly used
up or badly fragmented. It does appear that more data is needed.
Sue
|
| 292.6 | | CSC32::KING | | Tue Mar 11 1997 15:28 | 53 |
|
Thank you for the help so far.
This customer does not have the book, just the developer's guide and
reference manual on CD. I've been faxing him some pages from the book,
and helping him to use SDA in hopes of helping/advising him, but
letting him do all his own work. He does not have another system to
be able to use the System Code Debugger, and the code does not fail
when he single steps using XDELTA. I did suggest he might want to get
the source listings. He appears to be making some progress and here is
the latest mail he sent me;
>
> Research is showing me that the call to allocate a counted resource
> context block (IOC$ALLOC_CRCTX) is returning a successful status while
> providing a pointer causing the memory access violation when attempting
> to allocate counted resources (IOC$ALLOC_CNT_RES).
> Half the time the symptom is to crash/panic and perform a selective
> memory dump. When this is the case, the system is crashing with a
> "INVEXCEPTN, Exception while above ASTDEL" due to the access violation.
> The other half of the time the call apparently succeeds but is loading
> the maps with invalid values and attempts to use them cause the screen
> turn yellow an spew "Avanti machine check" messages and stack dumps
> followed by a machine init sequence, which I presume means I overwrote
> PCI board space owned by the graphics card. There does not appear to
> be any method of debugging this sort of fault since nothing gets saved
> anywhere.
> Using the SDA/ANALYZE utility I've been able to verify the table
> linkages between ADP, CRAB, IDB, etc. and find they are all where
> I think they belong. Due to the nature of dynamically loaded drivers,
> (which I am loading via mc sysman io connect commands) the addresses
> are changing for each run. This makes the debugging a little more
> compicated as I must maintain records unique to each reboot.
> Although not thoroughly defeated, I would appreciate any suggestions
> you can make as to why the call to IOC$ALLOC_CRCTX is not working. I
> am calling it thusly:
> ioc$alloc_crctx ( adp->adp$l_crab, &(UCB *)ucb->ucb$l_crctx, 0 );
> if (status == 0) return (call_abortio (irp, pcb, (UCB *)ucb, EIO) );
He has not saved any crash dumps for me to analyze, but from the PC,
the system is crashing in the APECS_SUPPORT portion of SYSLOA.
Any further assistance appreciated.
Peter
|
| 292.7 | A fork lock index of 0 is not good | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Tue Mar 11 1997 16:34 | 28 |
|
Besides passing the 3rd parameter incorrectly, there is nothing
too wrong with the call, presuming the crab address is correct.
He is also not checking the status correctly; you get back
either SS$_NORMAL or SS$_INSFMEM from the call, not 0.
His call to ioc$alloc_crctx should be coded as
status = ioc$alloc_crctx ( adp->adp$l_crab, &(UCB *)ucb->ucb$l_crctx);
OR
status = ioc$alloc_crctx ( adp->adp$l_crab, &(UCB *)ucb->ucb$l_crctx,
ucb->ucb$b_flck); // Or just pass spl$c_iolock8
if (!$VMS_STATUS_SUCCESS(status))
return (call_abortio (irp, pcb, (UCB *)ucb, EIO) );
For what it costs Digital to debug his code, we could have bought
him a book. This call is documented correctly in the Device Support
Manual. You could argue that the '[' is on the wrong side of the
comma in the
,[fleck_index]
description of the call.
|
| 292.8 | | STAR::LEWIS | | Thu Mar 13 1997 11:41 | 4 |
| I have just been reminded that you can't call ioc$map_io during
unit init -- IPL must be at 8 or below. Is he calling ioc$map_io
during unit init?
|
| 292.9 | Fun With IPL | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu Mar 13 1997 15:08 | 10 |
| : I have just been reminded that you can't call ioc$map_io during
: unit init -- IPL must be at 8 or below. Is he calling ioc$map_io
: during unit init?
On OpenVMS VAX, there are few (no?) repurcussions of dropping IPL in
the unit init routine, as it returned back to (on VAX) SYSGEN, which
just dropped IPL directly down. (This technique was used in at least
one OpenVMS-supported device driver.) Is this, uh, technique still
feasible on OpenVMS Alpha?
|
| 292.10 | CSR_MAPPING is what's needed | STAR::LEWIS | | Thu Mar 13 1997 15:52 | 7 |
| re: .9
Not sure about having drivers drop IPL, however there is a way to get
the I/O mapped. There's a CSR_MAPPING routine option in the ddt that
provides the right environment. It's all on page 46 of the Writing
OpenVMS device drivers in C book.
Sue
|
| 292.11 | Dropping IPL in Unit Init..... | STAR::CROLL | | Fri Mar 14 1997 13:41 | 17 |
| Generally speaking, you can fork in unit init to the driver's fork IPL routine.
After the fork block is set up, you return to AUTOGEN (LOAD_DRIVER, actually),
which shortly thereafter drops IPL back to 0, permitting the fork routine to run.
You have to be careful synchronizing things, however, since there's no guarantee
that the driver's fork routine will actually execute "shortly after" the fork
block is set up. It's possible that some other fork thread will execute ahead
of you and attempt to issue I/O before the unit init routine has executed. Or a
thread (at any IPL) on some other processor. One way to avoid this is to not
set the online bit until all unit init is complete, and to make sure the start
I/O routine checks the online state before doing anything interesting. Online
is checked somewhere in the QIO path (don't remember where), but if other fork
threads can issue I/O to your driver, you have to watch out for this.
Digital drivers frequently fork in unit init; the reason is that much of the
initialization that needs to be done can't be done at IPL 31. You just have to
be aware of the potential synchronization issues.
|
| 292.12 | | CSC32::KING | | Wed Mar 19 1997 18:09 | 81 |
|
I was out a few days, and here are the customer's latest replies.
We still appreciate all the help, and as mentioned in an earlier
reply, these may help show what type of problems a typical customer
may encounter.
Peter
______________________
(customer replies)
FYI: I seem to have found the problem with IOC$ALLOC_CRCTX.
Partly the problem was that I was not providing a lock request such as
status = ioc$alloc_crctx ( adp->adp$l_crab, &crctx, SPL$C_IOLOCK8 );
The other part of the problem is that when I place an XDELTA breakpoint
request ("ini$brk") between the IOC$ALLOC_CRCTX and the subsequent
IOC$ALLOC_CNT_RES I always get an access fault after telling XDELTA to
proceed (;P). It's pretty frustrating when you cannot trust your
debugger.
At this point I can successfully load maps (according to status
responses).
Hopefully I'm loading them correctly. The "next bug" I come accross is
another access violation in the start io routine, but is also when I
have everything breakpointed with "ini$brk" requests. (Also failing in
INIT_IO_BRIDGE_C, where I was failing before.)
_____________________
Same problem, different area. It appears that INIT_IO_BRIDGE_C is being
called with a zero argument in R5, which causes a subsequent LDQ
R18(R5)
to have an access violation in the same module when I'm trying to do
IOC$WRITE_IO calls to access on-board PCI registers. Oddly enough the
call is exactly the same as another call performed previously in the
code, and it appears not to be directly relate to the code I'm using.
As I move calls to XDELTA (ini$brk();) around I'm getting the error on
different IOC$WRITE_IO requests.
Is there a way I can set up a memory barrier from the C language? Some
compilers will allow inline macro code, and when dealing with devices
it's sometimes best to ensure bus access is sequential.
(In other words how can I embed an inline "mb" statement into a c
program?)
__________________
I bet you thought I'd gotten somewhere, but alas...
With your help I have gotten the IOC$ALLOC_CRCTX working to where I
don't get the access violations and returning SS$_NORMAL, but after
that I call IOC$ALLOC_CNT_RES and IOC$LOAD_MAP. Both return SS$_NORMAL.
(So far so good, right?) Unfortunately the "dma_address_ref" supplied
in the IOC$LOAD_MAP call is zero following the call, which causes all
kinds of grief and aggrevation at a later date.
... not much later, but not right then...
A section of code follows to demonstrate how I call it:
boff = ((*(char *)epcip->pci_write_addr) % PAGESIZE);
status = ioc$load_map ( adp,
(UCB *)ucb->ucb$l_crctx,
irp->irp$l_svapte,
boff,
&(UCB *)ucb->ucb$l_dma_whan);
if (status != SS$_NORMAL)
return (call_abortio(irp, pcb, (UCB*)ucb, EIO));
if((UCB *)ucb->ucb$l_dma_whan == 0 )
return (call_abortio(irp, pcb, (UCB*)ucb, EIO));
My problem is two-fold actually. I have commented out the check for the
address being zero. The reason I did was the call_abortio never returns
to the caller of $QIO. This causes the process to hang until
interrupted by a ^C. Any thoughts on how to fix that would also be
helpful.
|
| 292.13 | | CSC64::BLAYLOCK | If at first you doubt,doubt again. | Mon Mar 24 1997 18:32 | 32 |
| > My problem is two-fold actually. I have commented out the check for the
> address being zero. The reason I did was the call_abortio never returns
> interrupted by a ^C. Any thoughts on how to fix that would also be
> helpful.
Not knowing what his call to 'call_abortio' is, there are some hints
as to why this fails. Since he is able to type ^C, his code is
not hung in kernel mode itself but in user mode. That would indicate
that either the EFN is not getting set or if he is using an IOSB,
it is not getting set to a non-zero value. So in this case, what is
'EIO' defined as; hopefully not zero?
Not having a platform type, in at least one of them (in [CPU402.LIS])
if your call to IOC$ALLOC_CNT_RES did not do anything (ie failed)
then the load map call will return 0 in the dma_address_ref parameter
because of the zeros in the crctx.
> IOC$WRITE_IO calls to access on-board PCI registers. Oddly enough the
> call is exactly the same as another call performed previously in the
> code, and it appears not to be directly relate to the code I'm using.
> As I move calls to XDELTA (ini$brk();) around I'm getting the error on
> different IOC$WRITE_IO requests.
Static data? Stack overwrite? Data not properly saved across fork boundaries?
How does INI$BRK fail; what is the failure specifically?
> Is there a way I can set up a memory barrier from the C language? Some
> compilers will allow inline macro code, and when dealing with devices
Check out the file c_asm.h for 'asm("mb");' or use HELP CC Language Builtin
for __MB (and subsequently builtin.h).
|
| 292.14 | | BSS::JILSON | WFH in the Chemung River Valley | Thu May 15 1997 13:19 | 379 |
| Our customer has come back with one last problem. In using his driver he
is intermittently receiving the following machine check. He claims that it
is failing in his DMA subroutine he has off the Startio routine. His test
is to loop thru the following about 10,000 times and it fails within 700
times thru the loop.
Open a channel, Write, Read, Compare, Close the channel
He is saving all of his arguments to IOC$LOADMAP, IOC$READIO & IOC$WRITEIO
withing the driver and has examined them in the dump and they are all
correct. He has access to a PCI bus analyzer and has not seen anything
unusual on the bus at the time of the machine check.
Any good advise as to where he can go from here?
Jilly
******************************** ENTRY 1 ********************************
Logging OS 1. OpenVMS
System Architecture 2. Alpha
OS version E7.1
Event sequence number 41.
Timestamp of occurrence 14-MAY-1997 14:43:03
Time since reboot 0 Day(s) 1:03:56
Host name OVMS1
System Model AlphaStation 255/233
Entry type 2. Machine Check
CPU Minor class 1. Machine check (670 entry)
Byte Count x02E8
Processor Specific Offset x00000110
System Specific Offset x000001A0
PAL Error Type Code x00000205
PAL Frame Revision x00000001
- ALPHA CHIP REGISTERS -
PALTEMP1 x0000000000000000
PALTEMP2 x0015C4F800000004
PALTEMP3 xFFFFFFFF80E388C0
PALTEMP4 xFFFFFFFF80DDEE00
PALTEMP5 x0000000000000001
PALTEMP6 xFFFFFFFF80CC0128
PALTEMP7 x0000000000004200
PALTEMP8 x0000000000000400
PALTEMP9 x0000000000000803
PALTEMP10 x0000002B52B93EA8
PALTEMP11 x0000000000000000
PALTEMP12 x0000000000008000
PALTEMP13 xFFFFFFFF80C3FFF0
PALTEMP14 xFFFFFFFF800B2144
PALTEMP15 x0000000000000018
PALTEMP16 x0000000000000303
PALTEMP17 x000000000000000D
PALTEMP18 x0000000000000000
PALTEMP19 x0000000000000000
PALTEMP20 x00000000000F0000
PALTEMP21 x00003FFFFFFFFFFF
PALTEMP22 x0000000000000040
PALTEMP23 x0000000000000008
PALTEMP24 xFFFFFFFF80D0E000
PALTEMP25 x0000000000090000
PALTEMP26 x000000007FFA2000
PALTEMP27 x0000000000000000
PALTEMP28 x000000000363A000
PALTEMP29 xFFFFFFFC00000000
PALTEMP30 x0000000000390000
PALTEMP31 x0000000003638080
Exception Address Reg xFFFFFFFF80058E22
Exception Address Reg Provides Information
About The Most Recent Exception.
Address Points to Native-Mode Instruction
If Machine Check or Math Trap Exception,
PC in Exception Address is Correct.
Last Exception Addr PC: x3FFFFFFFE0016388
Exception Summary Reg x7610003677FF0033
Last Exception: Division by Zero
Floating Point Overflow
Exception Mask Reg IPR Window Bit Set
Exception Mask Reg x408035244A003690
Exception Operation Result in Register I4
Exception Operation Result in Register I7
Exception Operation Result in Register I9
Exception Operation Result in Register I10
Exception Operation Result in Register I12
Exception Operation Result in Register I13
Exception Operation Result in Register I25
Exception Operation Result in Register I27
Exception Operation Result in Register I30
Exception Operation Result in Register F2
Exception Operation Result in Register F5
Exception Operation Result in Register F8
Exception Operation Result in Register F10
Exception Operation Result in Register F12
Exception Operation Result in Register F13
Exception Operation Result in Register F23
Exception Operation Result in Register F30
Icache Ctrl & Status Reg x0015C4F800000004
Performance Counters Disabled
Empty Wrt Buffer Before Issuing Next Inst
Branch Prediction Selection: Not Taken
JSR Stack is Disabled
Instructions Can Only Single Issue
If Not in PALmode, Executing Reserved Inst
Opcode Will Result in OPCDEC Exception.
Super Page Istream Memory Mapping Disabled
Float Point Inst Will Cause FEN Exception
Icache Addr Space Numb: x0000000000000000
PALcode Base Address Reg x0000000000008000
PALcode Base Address: x0000000000000002
Hardware Int Enable Reg x00000001FFC014E0
CRD Error Interrupts Disabled
CPU Hrdw Interrupts Enabled Irq_h Pins 0,2
CPU Hrdw Interrupts Enbld Irq_h Pins 3,4,5
Performance Cntr 0 & 1 Interrupts Disabled
Serial Line Interrupts Disabled
Software Interrupts Enbld Level 9,10,11,12
Software Interrupts Enbld Levels 13,14,15
AST Interrupts Enbld in Kernel, Executive,
Supervisor, and User Mode.
Hardware Int Request Reg x0000000000000000
NO Hrdw Int Req With Companion Enable Set
NO Softw Int Req With Companion Enable Set
NO AST Int Req With Companion Enable Set
Memory Management CSR x0000000000005000
MMCSR Valid Only on Mem Mgt Err, DTB Miss,
D-Stream Fault, Dcache Parity Error.
Last Faulting Instruction RA Field: R0
Last Faulting Instruction Opcode Follows:
x28 - LDL Load Sign-Extended Longword
(Data) Cache Status Reg x0000000000000003
This is EV45 Cache Status Register(C_STAT)
EV45 Chip is Production Version of 21064A
Last Load or Store Missed Dcache
Cache Address Reg x00000007FFFFFFFF
Abox Control Reg x000000000000940A
Machine Checks Enabled for Uncorr Errors
CRD Interrupts Disabled
Single Entry Icache Stream Buffer Enabled
Lock Operation Conforms to Alpha Architect
Dcache Enabled
EV45 16K Byte Dcache Selected
Double Invalidate: Both EV45 Dcache Blocks
Addressed By iAdr_h<12:5> Invalidated.
Bus Interface Status Reg x0000000000002041
HARD ERROR Detected During External Cycle
BIU Command Cycle Type: Read_Block
Bus Interface Address Reg x0000000282008128
Address Only Valid if Bus Interface Status
Register Error Bit 0,1,2, or 3 is Set.
BIU Addr adr_h <4:2>: x2
BIU Addr adr_h<33:5>: x0000000014100409
Bus Interface Control Reg x0000000810002225
External Cache (Bcache) Enabled
PARITY MODE: External Cache Parity Enabled
Cache Rams are Output Enable Controlled
Ext Cache Rd Access Time: 3 CPU Cycles
Ext Cache Wrt Cycle Time: 3 CPU Cycles
Size of External Cache: 256 Kbyte
Ext Cache For Phys Addr Quad 3 Disabled
Ext Cache Rd Time Controlling Bcache Reads
Ext Cache Wrt En Ctrl: x0000000000000001
Fill Syndrome Reg x0000000000000000
No Error in Low Long Word of Quad Word
No Error in Upper Long Word of Quad Word
Fill Address Reg x0000000000011250
Addr Only Valid if Bus Interface Stat Reg
ECC(Bit 8) or PARITY(Bit 10) Error Set.
IF Bus Interface Stat Reg FILL_IRD Bit 11
is Clear, Cache Blk Phy Adr<4:2> is: x4
Cache Blk Phy Adr<33:5> x0000000000000892
Virtual Address Reg x00000000000061D0
Dstream FLT/DTB Miss VA x00000000000061D0
Bcache Tag Reg x1C8A00007229EC50
Last Bcache Access Resulted in a Miss
Parity Bit for Bcache Tag Status Bits Clr
Bcache Tag Dirty Bit Clear
Bcache Tag Shared Bit Clear
Bcache Tag Valid Bit Set
Bcache Tag Addrress Parity Bit Clear
Tag Being Probed: x0000000000014F62
coma_gcr x000000006D8D00B4
DMA Priority
128 bit wide MEM
Bcache enabled
Bcache long writes
coma_edsr x000000000000A1F0
coma_ter x000000006D8D3FF0
sysTag<21:17> = x0000000000001FF8
coma_elar x000000007D81FFFF
sysBus<20:5> at time of e x000000000000FFFF
coma_ehar x000000007D811FFF
sysBus<33:21> at time of x0000000000001FFF
coma_ldlr x000000007D811908
sysBus<20:5> last locked x0000000000001908
coma_ldhr x000000007D810004
sysBus<31:21> last locked x0000000000000004
coma_base0 x000000007D810000
Reg Base Adr <33:23> = x0000000000000000
coma_base1 x000000007D810000
Reg Base Adr <33:23> = x0000000000000000
coma_base2 x000000007D810000
Reg Base Adr <33:23> = x0000000000000000
coma_cnfg0 x000000007D810049
Bank Valid
Bank Size = 64 MB
Column Adr Selection x0000000000000001
coma_cnfg1 x000000006D8D0000
Bank Size = 1024 MB
Column Adr Selection x0000000000000000
coma_cnfg2 x000000006D8D0000
Bank Size = 1024 MB
Column Adr Selection x0000000000000000
epic_dcsr xFFFFFFFF801A081C
Prefetch enabled
Disable correctable error
No Device
Pass 2 Chip
Partial Bypass
PCI Cycle Type = Memory Read
epic_pear xFFFFFFFF84100408
PCI error address x0000000084100408
epic_sear x0000000000272110
DMA Address = x0000000000027211
epic_tbr1 x0000000000550000
Translation Base Adr = x0000000000002A80
epic_tbr2 x0000000000000000
Translation Base Adr = x0000000000000000
epic_pbr1 x00000000000C0000
Scatter/Gather Enabled
Window Enabled
PCI Base Adr x0000000000000000
epic_pbr2 x0000000040080000
Scatter/Gather Disabled
Window Enabled
PCI Base Adr x0000000000000400
epic_pmr1 x0000000007F00000
PCI Mask x000000000000007F
epic_pmr2 x000000003FF00000
PCI Mask x00000000000003FF
epic_harx1 xFFFFFFFF80000000
PCI_ad - memory space = x0000000000000010
epic_harx2 x0000000000000000
PCI_ad - memory space = x0000000000000000
epic_pmlt x00000000000000FF
Master Latency Timer = 0.
epic_tag0 x0000000001218000
pci_page x0000000000000242
epic_tag1 x0000000001218000
pci_page x0000000000000242
epic_tag2 x0000000001218000
pci_page x0000000000000242
epic_tag3 x0000000001218000
pci_page x0000000000000242
epic_tag4 x0000000001218000
pci_page x0000000000000242
epic_tag5 x0000000001218000
pci_page x0000000000000242
epic_tag6 x0000000001218000
pci_page x0000000000000242
epic_tag7 x0000000001218000
pci_page x0000000000000242
epic_data0 x0000000000000264
cpu_page x0000000000000099
epic_data1 x0000000000000264
cpu_page x0000000000000099
epic_data2 x0000000000000264
cpu_page x0000000000000099
epic_data3 x0000000000000264
cpu_page x0000000000000099
epic_data4 x0000000000000264
cpu_page x0000000000000099
epic_data5 x0000000000000264
cpu_page x0000000000000099
epic_data6 x0000000000000264
cpu_page x0000000000000099
epic_data7 x0000000000000264
cpu_page x0000000000000099
******************************** ENTRY 2 ********************************
Logging OS 1. OpenVMS
System Architecture 2. Alpha
OS version E7.1
Event sequence number 42.
Timestamp of occurrence 14-MAY-1997 14:43:03
Time since reboot 0 Day(s) 1:03:56
Host name OVMS1
System Model AlphaStation 255/233
Entry type 37. Crash Re-Start
Bugcheck Minor class 1. Crash Re-start
Bugcheck Msg MACHINECHK, Machine check while in kernel
mode
Process ID x00010015
Process Name
KSP x000000007FFA1B90
ESP x000000007FFA6000
SSP x000000007FFAC100
USP x000000007AFE7950
R0 xFFFFFFFF80C31B80
R1 x000000000000940A
R2 xFFFFFFFF80C33400
R3 x0000000000000003
R4 x0000000000000210
R5 x0000000000001F04
R6 xFFFFFFFF80DFF380
R7 x0000000000040050
R8 xFFFFFFFF80DFDEE8
R9 xFFFFFFFFFFFFFFFF
R10 x0000000000000128
R11 x0000000000040000
R12 x0000000000008000
R13 xFFFFFFFF80C3FFF0
R14 xFFFFFFFF80E3E980
R15 xFFFFFFFF80C05000
R16 x0000000000000215
R17 x0000000000000001
R18 x0000000000000001
R19 x0000000000000000
R20 xFFFFFFFFFFFFFFF8
R21 xFFFFFFFFFFFFFFFF
R22 x0000000100000000
R23 xFFFFFFFF80C31B88
R24 xFFFFFFFF80C31B8C
R25 x0000000000000003
R26 x0000000000000210
R27 xFFFFFFFF80C3CBD0
R28 xFFFFFFFF80055648
FP x000000007FFA1B90
SP x000000007FFA1B90
PC xFFFFFFFF80062BD0
PS x1000000000001F04
PTBR x0000000000001B1D
Process Ctl Block Base Re x0000000003638080
PRBR xFFFFFFFF80D0E000
VPTB xFFFFFFFC00000000
System Ctl Block Base Reg x00000000000001C8
Software Interrupt Summar x0000000000000000
ASN x000000000000002B
ASTSR ASTEN x000000000000000F
FEN x0000000000000001
ASN x000000000000002B
IPL x000000000000001F
MCES x0000000000000008
$ analyze/crash [sys0.sysexe0
$ analyze/crash [sys0.sysexe]
)0=<[1;1f[J
OpenVMS (TM) Alpha system dump analyzer
...analyzing a selective memory dump...
Dump taken on 14-MAY-1997 15:07:08.76
MACHINECHK, Machine check while in kernel mode
SDA> show page 84100408;1
[1;1f[J
System page table
-----------------
MAPPED ADDRESS PTE ADDRESS PTE TYPE READ WRIT BITS GH PG
TYP LOC BAK REFCNT FLINK BLINK
-------- 1 entry not in memory: VA FFFFFFFF.84100000
PTE FFFFFFFD.FFE10400
|
| 292.15 | | EEMELI::MOSER | Orienteers do it in the bush... | Thu May 15 1997 15:17 | 5 |
| is there any reason to stay at an early Raven V7.1 field test, and not
upgrade to the latest officially released version, i.e. V7.1?
Just to make sure, there are no field test anomalies left over...
/cmos
|
| 292.16 | V7.1 = Gryphon, Raven ~= V7.2 | MILORD::BISHOP | The punishment that brought us peace was upon Him | Thu May 15 1997 16:18 | 1 |
| Christian means Gryphon not Raven. :-)
|
| 292.17 | | STAR::LEWIS | | Thu May 15 1997 16:50 | 4 |
| re:.14
One thing I saw : the failing address whose pte you displayed is
presumably a PCI bus address, not a system memory address.
Sue
|
| 292.18 | | BSS::JILSON | WFH in the Chemung River Valley | Thu May 15 1997 17:06 | 9 |
| Yes that address is for the PCI space but he has no idea where it came
from. I guess that is the basic question. Where did that address come
from?
As to E7.1, that was the only version of 7.1 available when he started
writing his driver and to date he hasn't received any media to update to V7.1
and he hasn't had time to go chasing said media.
Jilly
|
| 292.19 | Contact SSB, upgrade to final V7.1 release... | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Thu May 15 1997 17:21 | 10 |
|
:As to E7.1, that was the only version of 7.1 available when he started
:writing his driver and to date he hasn't received any media to update to V7.1
:and he hasn't had time to go chasing said media.
There's either an ordering/shipping snarl, or there was no order.
(I'm curious to know what PAKs are in use -- all SDK 7.1 field test
PAKs expired several months ago.) In any case, contact SSB, and
request a shipment of the V7.1 kit -- see notes 8.* or 9.* here for
the SSB contact information.
|