aland@infmx.informix.com (Colonel Panic) (11/01/90)
I just encountered some strange i/o errors, and I'm looking for some
collective wisdom...
Platform: AT&T 6386E/33, 24MB of memory, standard AT&T/Wangtek 125 MB
streaming tape, SV/386 Rel 3.2.2
Situation: while doing a mass cpio to the streaming tape, I try to
format some 3.5" floppies or dd some disk-resident floppy
images to them. I keep getting i/o errors on the diskettes.
If I try the same operations while the tape drive is not in
use, no problems arise.
Since both are using DMA, I suspect that the DMA buffering in the
kernel is going haywire. Current pertinent kernel parms are DMAEXCL=0
(allow simultaneous DMA) and DMAABLEBUF=256.
Does anybody have any other ideas as to possible other causes and/or
possible solutions?
thanks in advance.
--
Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland
I'm Pro-Anarchy... and I Vote!aland@informix.com (alan denney) (11/02/90)
>Platform: AT&T 6386E/33, 24MB of memory, standard AT&T/Wangtek 125 MB > streaming tape, SV/386 Rel 3.2.2 >... By the way, the floppy (fd) is using DMA channel 2 and the tape (qt) is using channel 1... -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland I'm Pro-Anarchy... and I Vote!
mason@oct1.UUCP (David Mason) (11/07/90)
In article <1990Oct31.190027.8613@informix.com> aland@infmx.informix.com (Colonel Panic) writes: >Situation: while doing a mass cpio to the streaming tape, I try to > format some 3.5" floppies or dd some disk-resident floppy > images to them. I keep getting i/o errors on the diskettes. > If I try the same operations while the tape drive is not in > use, no problems arise. > >Since both are using DMA, I suspect that the DMA buffering in the >kernel is going haywire. Current pertinent kernel parms are DMAEXCL=0 >(allow simultaneous DMA) and DMAABLEBUF=256. As a matter of interest, the Interactive 2.2 (== 3.2.2) release notes state the following, under "Known Problems and Bugs": "On machines with certain types of DMA chips, concurrent use of two DMA-based devices (such as diskette drive and a tape controller) can result in erroneous data transfers or aborted commands." No saying which chips, of course. Haven't seen the problem myself. As far as I know, AT&T 3.2.2 is written by ISC, so it is likely that this problem will appear in AT&T 386 Unix. -------------------- David | mason@oct1.UUCP (David Mason) | olsa99!oct1!mason@ddsw1.MCS.COM | <well connected>!ddsw1!olsa99!oct1!mason
ted@eslvcr.wimsey.bc.ca (Ted Powell) (11/12/90)
In article <1990Nov7.155748.12583@oct1.UUCP> mason@oct1.UUCP (David Mason) writes: >In article <1990Oct31.190027.8613@informix.com> aland@infmx.informix.com >(Colonel Panic) writes: >>[...bad things happening when using both tape and floppy...] >>kernel is going haywire. Current pertinent kernel parms are DMAEXCL=0 >>(allow simultaneous DMA) and DMAABLEBUF=256. > >As a matter of interest, the Interactive 2.2 (== 3.2.2) release notes >state the following, under "Known Problems and Bugs": > "On machines with certain types of DMA chips, concurrent > use of two DMA-based devices (such as diskette drive > and a tape controller) can result in erroneous data > transfers or aborted commands." >No saying which chips, of course. Haven't seen the problem myself. >As far as I know, AT&T 3.2.2 is written by ISC, so it is likely that >this problem will appear in AT&T 386 Unix. The AT&T 386 Unix does have the DMAEXCL parameter. Before I turned it off, I tried installing Fastback Plus on the DOS partition of the disk. The installation procedure includes a check for this DMA problem. My chip passed the test, so then I turned off DMAEXCL, which is ON by default. Seems to me the best thing for the Colonel to do (he didn't mention having tried it already) is to turn DMAEXCL back on and see whether this makes the problem go away. If it does, then it's chip replacement time. -- ted@eslvcr.wimsey.bc.ca ...!ubc-cs!van-bc!eslvcr!ted (Ted Powell)
marz@cbnewsm.att.com (11/13/90)
In article <1990Nov7.155748.12583@oct1.UUCP>, mason@oct1.UUCP (David Mason) writes: > In article <1990Oct31.190027.8613@informix.com> aland@infmx.informix.com > (Colonel Panic) writes: > >Situation: while doing a mass cpio to the streaming tape, I try to > > format some 3.5" floppies or dd some disk-resident floppy > > images to them. I keep getting i/o errors on the diskettes. > > If I try the same operations while the tape drive is not in > > use, no problems arise. > > > >Since both are using DMA, I suspect that the DMA buffering in the > >kernel is going haywire. Current pertinent kernel parms are DMAEXCL=0 > >(allow simultaneous DMA) and DMAABLEBUF=256. > > As a matter of interest, the Interactive 2.2 (== 3.2.2) release notes > state the following, under "Known Problems and Bugs": > > "On machines with certain types of DMA chips, concurrent > use of two DMA-based devices (such as diskette drive > and a tape controller) can result in erroneous data > transfers or aborted commands." > > No saying which chips, of course. Haven't seen the problem myself. > As far as I know, AT&T 3.2.2 is written by ISC, so it is likely that > this problem will appear in AT&T 386 Unix. > -------------------- > David | mason@oct1.UUCP (David Mason) > | olsa99!oct1!mason@ddsw1.MCS.COM > | <well connected>!ddsw1!olsa99!oct1!mason I'll go you one better. Try formatting a floppy from UNIX and using the other floppy from vpix at the same time. You get exactly the same problem described above. I wonder if turning off simultaneous DMA in the config file would help this case. Anybody try this yet? Martin Zam (201)564-2554
aland@informix.com (Colonel Panic) (11/17/90)
In article <1990Nov11.205350.108@eslvcr.wimsey.bc.ca> ted@eslvcr.wimsey.bc.ca (Ted Powell) writes: >In article <1990Nov7.155748.12583@oct1.UUCP> mason@oct1.UUCP (David Mason) writes: >>>[...bad things happening when using both tape and floppy...] > >The AT&T 386 Unix does have the DMAEXCL parameter. Before I turned it >off, I tried installing Fastback Plus on the DOS partition of the disk. >The installation procedure includes a check for this DMA problem. My >chip passed the test, so then I turned off DMAEXCL, which is ON by >default. The funny thing is... the AT&T doc states that "some machines' DMA controllers may not be able to handle simultaneous DMA...", but AT&T Support has never been able to give me a definitive answer as to whether or not *their own machines* can handle it... (they use discrete logic rather than a major name DMA controller chip, so it's not likely to be something I can find out from anyone else...) >Seems to me the best thing for the Colonel to do (he didn't mention >having tried it already) is to turn DMAEXCL back on and see whether this >makes the problem go away. If it does, then it's chip replacement time. The problem doesn't "go away", per se... I get Double Kernel Panics if I *don't* set DMAEXCL to 0. That's how I discovered the parm in the first place. >ted@eslvcr.wimsey.bc.ca ...!ubc-cs!van-bc!eslvcr!ted (Ted Powell) -- Alan Denney aland@informix.com {pyramid|uunet}!infmx!aland "I went to Wall Street with the desire to help change society for the better, not to find a fortune." - Michael Milken