Port-vax archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Race in MSCP (ra/rx) driver



On rereading, it occurs to me....

> In simh, the initialization steps of the MSCP should be possible to
> have instantaneous.  No reason to emulate that part of the
> controller, is there?

Maybe.  There's comparably sloppy code out there in the init phase,
code that requires delays to work - see below.  And, depending on what
you count as "the initialization steps", what I quoted may count - that
was causing me trouble at ONLINE time.  That is, the command whose
response is being awaited there is an ONLINE command, which certainly
can be seen as part of initialization.

The boot-block code I mentioned, the code I didn't post a fix for
because modern NetBSD's version is so different I'm not sure whether it
has trouble, that bug strikes in response to setting the GO bit after
step 4 of initialization, which I would say counts as part of
initialization.  My fix there has two parts.  One is that the code
never set up the Qbus mapping registers (see below for more on that);
the other was the race.

Here's my patch, which is relative to bootxx.c,v 1.2.

diff --git a/sys/arch/vax/boot/xxboot/bootxx.c b/sys/arch/vax/boot/xxboot/bootxx.c
index 9851739..154dc0f 100644
--- a/sys/arch/vax/boot/xxboot/bootxx.c
+++ b/sys/arch/vax/boot/xxboot/bootxx.c
@@ -240,6 +240,14 @@ devopen(f, fname, file)
 
 	*file = (char *)fname;
 
+ if (vax_cputype == VAX_TYP_UV2) // others?
+  { // Set up Qbus mapping registers: access to low 4M of RAM
+    for (i=0;i<(1U<<(22-9));i++)
+     { ((volatile unsigned int *)0x20088000)[i] = 0x80000000 | i;
+     }
+    // Set LM EAE
+    *(volatile unsigned short int *)0x20001f40 = 0x20;
+  }
 	/*
 	 * On uVAX we need to init [T]MSCP ctlr to be able to use it.
 	 */
@@ -256,8 +264,6 @@ devopen(f, fname, file)
 			csr->udasa = (short)(((u_int)&uda)&0xffff) + 8;
 			while((csr->udasa & MP_STEP3) == 0);
 			csr->udasa = 0x10;
-			while((csr->udasa & MP_STEP4) == 0);
-			csr->udasa = 0x0001;
 
 			uda.uda_ca.ca_rspdsc =
 			    (int) &uda.uda_rsp.mscp_cmdref;
@@ -265,6 +271,10 @@ devopen(f, fname, file)
 			    (int) &uda.uda_cmd.mscp_cmdref;
 			if (bootdev == BDEV_TK)
 				uda.uda_cmd.mscp_vcid = 1;
+
+			while((csr->udasa & MP_STEP4) == 0);
+			csr->udasa = 0x0001;
+
 			command(M_OP_SETCTLRC, 0);
 			uda.uda_cmd.mscp_unit = rpb->unit;
 			command(M_OP_ONLINE, 0);

Without this, I was seeing (in simulation) the MSCP interface trying to
poll the rings and getting NXM errors from the Qbus because the host
hadn't yet set them up by executing the next few lines.

I'm not sure, now, whether I added the Qbus mapping register setup
before or after I found the race.  I should probably remove that and
see if the mapping set up by the ROM code is good enough.  There
certainly are uncomfortably many magic numbers there.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B


Home | Main Index | Thread Index | Old Index