brian@umbc3.UMD.EDU (Brian Cuthie) (10/28/88)
[as I slip into my asbestos suit] I have decided to respond to several postings with this single response rather than tie up net bandwidth with followups to followups etc. First, I humbly apologize for two things: 1) If I came off sounding omniscient about the AT, I'm sorry. I have, in past years, designed several disk controllers for the PC and written suitable drivers that used DMA. 2) for incorrectly extrapolating PC expertise to cover the design of the AT. Some of my statements about DMA on the AT were clearly wrong as I made some bad assumptions about that particular part of the AT design. However, most of my points about DMA are true in the general case. It is true that, after pawing through the AT technical reference manual, the AT has some serious deficiencies in it's DMA design. This, however, does not change the fundamental reasons for using DMA in most systems. The Intel 80286/80386 processors have the unique ability to behave much like a DMA controller. That is, they can transfer data in single memory cycles ( please note that a memory cycle is not the same as a clock cycle). In this mode, using the string transfer instructions, the 80*86 is capable of generating address and timing signals without placing data on the bus. Thus the peripheral or memory is free to drive the data bus directly to the recipient of the data (memory for INS instructions, and peripheral for OUTS instructions). There are some instances when DMA controllers will buffer data however these are rare. Data usually flows between the peripheral and memory in single memory cycles unless, of course, the peripheral's controller cannot transfer data at memory speeds (unlikely since most peripheral controllers have some buffer cache). Normally, however, a processor does not have this ability. Thus, to transfer a block from a peripheral to memory requires that the processor read a byte/word from the peripheral and subsequently write that byte/word to memory. This operation, even under the best of caching scenarios, requires at least two memory accesses. It can be seen, then, that a processor lacking this special ability could never be as fast as a well designed DMA subsystem. DMA controllers seize the bus by placing the CPU in a HOLD state. In this state, the CPU is not able to perform any external bus accesses. Instead, all address and timing information is generated by the DMA controller. When the DMA controller has placed the CPU into a HOLD state, and has asserted the appropriate address onto the address bus, it asserts either MEMREAD (for a transfer from memory to the peripheral) or MEMWRITE (to transfer from a peripheral to memory). The device which has requested DMA recognizes these signals in conjunction with the DMA ACK signal and data is transfered over the data bus directly between the peripheral and memory with no intermediate lay-overs. It can be seen that during this transfer, the CPU will remain idle, once it has completed it's current instruction, until it can regain control of the bus. Therefor, most DMA controllers offer the ability to generate limited burst DMA transfers. The Intel 8237 is limited to either single transfers or complete block transfers. Other DMA controllers, such as the Motorola 68445 (I believe that is the correct part number), allow the burst length to be programmed over a wider range. Limiting the burst length allows some interleaving of CPU and DMA memory accesses. Interleaving CPU and DMA access to memory is usually less desirable than complete block transfers since there is substantial overhead in placing the CPU into a HOLD state. This problem can be solved by multiported memory designs. However, since processor speeds outstrip memory speeds (that is as CPUs get faster, they spend more time waiting for memory) there is little advantage to this scheme. In summary, DMA is used primarily because, in a well designed system, it can almost always be made to be more than twice as fast as the CPU in doing peripheral to memory transfers. However, memory bandwidth is limited and thus you must rob peter to pay paul, so the idea that DMA allows concurrent CPU and peripheral access to memory is somewhat mislead. -brian
zaz@jersey (Todd Koeckeritz) (08/20/90)
I have run into a rather hard to solve problem and would appreciate any input all you netters might have. I have a 386 (Mylex MX Revision 1.01 25Mhz) motherboard, an Archive VP402 card controlling an Archive 150M VP tape drive and an Adaptec ACB-2322B controlling a 300M disk all running under Xenix SysV 2.3.2. The problem I am having is that I can write tapes fine (never had a problem here), but sometimes when I am reading the tapes I'll panic with a general protection fault or a non-recoverable kernel page fault. This will happen whether I am just listing the files (as in tar tvf or cpio -iBtvc or even dd), dumping everything to the bitbucket (/dev/null) or actually attempting to put the files on disk. I do have other devices in my system, however this is the most basic hardware configuration in which I can dupicate the problem. My IRQs have all been scoped out many times (2/25, 3, 4, 5 and 7 for the tape) and I have tried both DMA channels (1 and 3) and many of the combinations of the above. The I/O addr of the tape drive is 0x220 and doesn't appear to conflict with anything else. I can cause this to happen in single user or full up, I have beat my memory and disk to a pulp attempting to test new configurations and isolate the problem. To me it has boiled down to three possibilities: 1) A bug in the tape driver or Xenix, although I would expect to have seen some other flames about this. 2) A flakey tape controller card: temperature appears to have some effect. It happens more "reliably" if my system cabinet is on than when it is off. 3) A problem with the motherboard (DMA Controllers or design) The only people I haven't talked to yet are Archive and the net. SCO of course wouldn't talk to me (mail or voice) to confirm or deny any complicity, and Mylex disavowed that they had ever had a problem with their motherboards (I have heard they did from several sources, can anyone help to confirm or deny this ?). Has anyone ran into a similar problem ? Or is their a known problem with any of the equipment I have mentioned ? This is a last ditch effort to solve the problem before I must go down and away while I track Mylex and whoever else must get involved in solving the problem. I would appreciate any guesses or new lines of thought in debugging this situation. E-Mail me if your answers are a little tentative. Thanks in advance. -- +-----------------------------------------------------------------------------+ | Todd Koeckeritz zaz@jersey (crash!orbit!jersey!zaz) | | Euler Solutions, Inc., Minneapolis, MN, USA H:(612)537-4264 W:(612)635-0088| +-----------------------------------------------------------------------------+
bill@bilver.UUCP (Bill Vermillion) (08/21/90)
In article <1990Aug20.052225.3371@jersey> zaz@jersey.UUCP (Todd Koeckeritz) writes: >I have run into a rather hard to solve problem and would appreciate >any input all you netters might have. I have a 386 (Mylex MX Revision >1.01 25Mhz) motherboard, an Archive VP402 card controlling an Archive >150M VP tape drive and an Adaptec ACB-2322B controlling a 300M disk >all running under Xenix SysV 2.3.2. The problem I am having is that I >can write tapes fine (never had a problem here), but sometimes when I >am reading the tapes I'll panic with a general protection fault or a >non-recoverable kernel page fault. This will happen whether I am just >listing the files (as in tar tvf or cpio -iBtvc or even dd), dumping >everything to the bitbucket (/dev/null) or actually attempting to put >the files on disk. [some details deleted - wjv] >To me it has boiled down to three possibilities: >1) A bug in the tape driver or Xenix, although I would expect to have > seen some other flames about this. >2) A flakey tape controller card: temperature appears to have some > effect. It happens more "reliably" if my system cabinet is on than > when it is off. >3) A problem with the motherboard (DMA Controllers or design) >The only people I haven't talked to yet are Archive and the net. SCO >of course wouldn't talk to me (mail or voice) to confirm or deny any >complicity, and Mylex disavowed that they had ever had a problem with >their motherboards (I have heard they did from several sources, can >anyone help to confirm or deny this ?). > >Has anyone ran into a similar problem ? Or is their a known problem >with any of the equipment I have mentioned ? This is a last ditch >effort to solve the problem before I must go down and away while I >track Mylex and whoever else must get involved in solving the problem. Well - I thought I must have been going crazy. And from what you describe, your symptoms and my symptoms - the ONLY commond things are SCO 2.3.2 and the '386 chip itself. I have about 2 dozen systems I take care of. One site has the Maynard Maynstream drives and 12 interface cards. The ONLY problems I have had are with the machines running 2.3.2. The 2.2.3 machines are fine. The machines are IBM Model 80 MCA bus. I haven't had the tape read problem, as I haven't read that many. But I get major problems with tape write. It will either 1) stop and start counting memory as if from a cold boot 2) just hang, 3) give me a non-recoverable page fault, or 4) double-panic with a non-recoverable page fault. I spent several hours on one of the machines and can make the crash happen when I want it too. All I have to do is write to the tape a second time without rebooting. From a cold start it always works, and if the tape has been written, and the machine not rebooted, trying to write the second time will ALWAYS crash the machine. I talked with Maynard (now an Archive company) and they deny any problems. I have another machine at another site that has an AMI motherboard, 8 megs of memory, DPT caching disc controller, a Maynstream 150 meg tape (the others are 60's) and a totaly different set of serial ports, Specialix and not Anvils. The IBMs are 16MHz, the AMI is 20. All the '286's with 2.2.3 run flawlessly as did the '386s until the change to 2.3.2. That required new software drivers so I immediately blamed them. I didn't know the latter machine was crashing as it was always turned off at night. The second time will usually lock the machine up, though it has been spontaneously rebooted at times. I had been leaning toward Maynard driver problems, but this leads me to beleive there may be something in the SCO system causing it. I have had the same results whether using tar or CTAR. I tried removing the tape drivers, and found the de-install script takes some of the base system with it - and haven't had the time to do a total re-install. That bug in the script led me to think Maynard, but your problems are SO similar I am now thinking OS. So far that's two of us with strange problems. Any one else with strange lockups or reboots with 2.3.2 ? bill -- Bill Vermillion - UUCP: uunet!tarpit!bilver!bill : bill@bilver.UUCP
cws@janus.Quotron.com (Craig W. Shaver) (08/21/90)
In article <1990Aug20.052225.3371@jersey>, zaz@jersey (Todd Koeckeritz) writes: > I have run into a rather hard to solve problem and would appreciate > any input all you netters might have. I have a 386 (Mylex MX Revision > 1.01 25Mhz) motherboard, an Archive VP402 card controlling an Archive > 150M VP tape drive and an Adaptec ACB-2322B controlling a 300M disk > all running under Xenix SysV 2.3.2. The problem I am having is that I I have locked up an interactive unix system using my archive tape. I have had problems using tar on this tape under esix when the buffer count was not 10 or 100. Cannot remember crashing the system on esix though (rev. C). mylex 386/20 adaptec 1542b + micropolis 1684-7 + archive s150 I am not ready to blame mylex, but I think the dma could be a problem. I believe the scsi has its own dma, and the crash can be consistently caused by using the tape dev that is not supposed to wait for rewind. BUT -- this only crashed on ix, not on esix. I have had trouble with a 60mb tape using the everex controller which should be similar to your archive controller. The tapes were not written properly and tapes from another machine did not produce correct files when read. My conclusions are that for the scsi the drivers are to blame, but for the 60mb using the qic02/24 adapter it could be the bus speed and dma problems. Craig W. Shaver ================================================================ Quotron Systems Inc. | Phone: (213) 302-4247 5454 Beethoven Street | uucp: trwrb!scgvaxd!janus!cws Post Office Box 66914 | craig@tradr2.quotron.com Los Angeles, CA 90066 | ================================================================
usenet@carssdf.UUCP (John Watson) (08/23/90)
I have a similar problem on a 486 card. The card with the Intel/Zymos 80..31 80..32 2 chip set is OK (I forget the whole number). Another 486 that has its own 128K cache using the "OPTI" chipset and an 80C206 peripheral/DMA/CMOS chip crashes whenever I use 2 dma devices at the same time, like floppy or archive tape in combination with hard disk. The hard disk is a 600meg ESDI with 4 Meg cacheing controller by Consensys (Toronto Canada). Panic, Double Panic etc.. I am trying things like a different 80c206, or different 80c206 vendor, Semens and Chips & Tech. both make it. So far I have only tried Semens. If this helps you good luck. If you have related info, pls pass on. Incedentally, other than this minor/fatal flaw it is the fastest system I have ever seen. This is not in the same league with 386's. John Watson ...!carsdf!usenet
campbell@Thalatta.COM (Bill Campbell) (08/23/90)
In article <1990Aug20.052225.3371@jersey> zaz@jersey.UUCP (Todd Koeckeritz) writes: >I have run into a rather hard to solve problem and would appreciate >any input all you netters might have. I have a 386 (Mylex MX Revision >1.01 25Mhz) motherboard, an Archive VP402 card controlling an Archive ...deleted stuff You might try changing your monitor card. I have a 33mhz 386 system that was running fine with one EGA card and the same Archive tape you have. I switched to another EGA card (Maxlogic 8-bit) and suddenly the tape wouldn't work at all :-( I installed a different EGA (Paradise 8-bit) and all worked fine again. Its amazing how many times that VGA cards will mess up something else in the system. This is the first time I had a problem with EGA. -- ....microsoft--\ Bill Campbell; Celestial Software ...uw-entropy----!thebes!camco!bill 6641 East Mercer Way ....fluke------/ Mercer Island, Wa 98040 ....hplsla----/ (206) 232-4164
usenet@carssdf.UUCP (John Watson) (08/24/90)
Additional info on my previous posting, 486 with OPTI chipset panics on
2 or more DMA access at same time...
The board has an 82C206 chip for DMA and other functions. The Semens chip
does not work (tried 2 with identical results) and a chip by the same number
from Chips & Technologies does work. It appears that my problem is gone.
There is a difference between these two chips and it is not just a "minor"
timing variation. Netters beware. John Watson
Self Employed ...jim@applix.com (Jim Morton [ext 237]) (08/28/90)
In article <1990Aug20.052225.3371@jersey>, zaz@jersey (Todd Koeckeritz) writes: > I have run into a rather hard to solve problem and would appreciate > any input all you netters might have. I have a 386 (Mylex MX Revision > 1.01 25Mhz) motherboard, an Archive VP402 card controlling an Archive > 150M VP tape drive and an Adaptec ACB-2322B controlling a 300M disk > all running under Xenix SysV 2.3.2. The problem I am having is that I > can write tapes fine (never had a problem here), but sometimes when I > am reading the tapes I'll panic with a general protection fault or a I've been meaning to post the final answer to a problem I had about 6 months ago that I posted here. The above problem may or may not have the same cause...I posted a problem with a Compuadd 320 where the system paniced when using the floppy drive with the system cache controller on, but worked fine with the cache controller off. After a *lot* of calls to Compuadd, they finally admitted that their rev. of the Award BIOS did not work with their cache controller and Xenix. They sent a Phoenix BIOS chipset and all has been well ever since... -- Jim Morton, APPLiX Inc., Westboro, MA ...uunet!applix!jim jim@applix.com