jgd@pollux.UUCP (Dr. James George Dunham) (01/22/88)
We have a VAX 750 with Emulex CS21 dmf boards (Rev D). We are trying to get 4.3 + NFS from Mt. Xinu up and running and have run into a problem with the dmf driver. The manual states that it should work with Emulex CS21's, but we find that it is constantly dropping characters. In particular, it seems to drop the first character after a ^M in a block of output to the screen. Under 4.2 we were using the DMF32 Driver by Chris Maloney (MDDC Version 1.00) that was last modified by Chris Torek on 4/15/85. I have several questions. 1. Is there a problem with the Rev on our CS21's causing the problem? 2. Is there really a problem with the stock driver, and if so, is there a replacement somewhere? 3. If there is no replacement driver, will the 4.2 driver work under 4.3? Any help would be appreciated as the users on my system are ready to scrap 4.3 and go back to 4.2 since they are having problems with their terminals. -Jim Dunham jgd@pollux or jgd@smu (214) 692-2812
ehrlich@inria.UUCP (Robert Ehrlich) (01/24/88)
It seems that the cause of the character loss is an improper emulation on
the Emulex board of the "dmftba" register. This register is used by the
driver for computing the number of characters which must be taken off from
the output queue, as they have just been transmitted by the board. The count
is computed as the difference between the value of the dmftba register and
the value which was loaded into it at the initiation of the dma output.
It seems that in some cases the dmftba register in the Emulex board is
incremented once more that normal. A simple fix is to keep in software the
real count at transfert initiation and to use it at interrupt instead of
the wrong computed value. I used the flag dmf_dma for that purpose, since
the count cannot exceed 60 (size of a cblock), instead of having a binary
values (0 or 1) indicating if dma was or not used for the last operation,
it now contains the character count of the last dma operation, zero if it
was not a dma operation.
After the fix I have run /usr/games/worms which is a good test for
character loss and all seems to work fine.
For people who don't have a source licence there is a way to bypass the
problem: seting (using adb /vmunix /dev/kmem) the variable dmf_mindma in the
kernel to the value 64 (or more). Since you will never have 64 contiguous
character in the ouput queue, the diver will never use dma. But in this case
you will loose the benefit of the dma feature of your board.
Here follows a context diff of the original driver and the modified one
***************
*** 579,592 ****
tp->t_state &= ~TS_BUSY;
if (tp->t_state&TS_FLUSH)
tp->t_state &= ~TS_FLUSH;
! else if (dmf_dma[unit0 + t]) {
! /*
! * Do arithmetic in a short to make up
! * for lost 16&17 bits.
! */
! addr->dmfcsr = DMFIR_TBA | DMF_IE | t;
! cntr = addr->dmftba -
! UBACVT(tp->t_outq.c_cf, ui->ui_ubanum);
ndflush(&tp->t_outq, (int)cntr);
}
if (tp->t_line)
--- 579,585 ----
tp->t_state &= ~TS_BUSY;
if (tp->t_state&TS_FLUSH)
tp->t_state &= ~TS_FLUSH;
! else if (cntr= (unsigned)dmf_dma[unit0 + t]) {
ndflush(&tp->t_outq, (int)cntr);
}
if (tp->t_line)
***************
*** 673,679 ****
if (nch >= dmf_mindma) {
register car;
! dmf_dma[minor(tp->t_dev)] = 1;
addr->dmfcsr = DMF_IE | DMFIR_LCR | unit;
addr->dmflctms = addr->dmflctms | DMF_TE;
car = UBACVT(tp->t_outq.c_cf, dmfinfo[dmf]->ui_ubanum);
--- 666,672 ----
if (nch >= dmf_mindma) {
register car;
! dmf_dma[minor(tp->t_dev)] = nch;
addr->dmfcsr = DMF_IE | DMFIR_LCR | unit;
addr->dmflctms = addr->dmflctms | DMF_TE;
car = UBACVT(tp->t_outq.c_cf, dmfinfo[dmf]->ui_ubanum);chris@mimsy.UUCP (Chris Torek) (01/26/88)
There are other solutions as well. Emulex has firmware that will put odd addresses into dmftba; Keith Muller has fixed this in the dmf driver several times, always before the next release, only to have a gremlin un-fix it. But not this time! (he said confidently). -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris