krowitz@RICHTER.MIT.EDU (David Krowitz) (11/30/88)
I've found a strange error that neither I nor the field service office can resolve ... I have a DN3000 running SR9.7 with a 155MB disk, a floppy, and two other DMA devices -- an IKON 10092 board and a GPIB interface board. The floppy disk is the only Apollo device which uses DMA on the DN3000. It uses DRQ2 and IRQ6 (dma request 2 and interrupt level 6). The IKON board is configured normally to use DRQ0 and IRQ11. The GPIB board uses DRQ1 or DRQ3 and IRQ4. On the AT bus, DRQ0 through DRQ3 are 8-bit transfer lines and DRQ5 through DRQ7 at 16-bit transfer lines (DRQ4 is not used). The IKON board can use either 8-bit or 16-bit transfers, although the Apollo installtion manual specifies using DRQ0 (an 8-bit transfer). Here's my problem ... Whenever I try sending data to the printer at the same time that I'm running WBAK to the floppy, WBAK fails. The printer's output is fine, but if I run a test program that runs in user-mode doing DMA of a test pattern to the printer, I find that the status code returned by pbu_$dma_stop is non-zero, even though the remaining byte count returned by the call is 0. The status returned is 'dma not at end of range', even though the byte count indicates that the dma finished and the IKON boards registers show that the board finished the dma. I have tried the IKON board using DRQ0, DRQ1, and DRQ3 (all of the 8-bit lines not used by the floppy) and they all have the same problem. The GPIB interface board will also cause WBAK to fail if it (the board) is transfering data at the same time that WBAK is running, so I don't think it is a programming error in my printer test routine. If I switch the IKON board to use DRQ5 or DRQ6 (the two unused 16-bit lines) then the floppy works just fine. It seems that any 8-bit dma device will interfere with the floppy disk, but that 16-bit dma devices do not. Apollo say that they have many of these IKON boards in use, and they haven't seen the problem. The fact that the GPIB board also causes the floppy to fail leads me to believe that it's not a problem particular to the IKON board. We've update the CPU board of the DN3000 to rev 22 and tried the latest version of the winchester/floppy controller with no improvement. Has anyone else seen a problem like this before? -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)