davidsen@steinmetz.ge.com (William E. Davidsen Jr) (03/15/89)
In article <1751@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: | Any Xenix users out there want to talk about losing RS-232 interrupts during | disk access because of this? I do. I run an original AT with xenix 2.1.3, with input coming in at 2400, 9600, and via ethernet. I have never seen any indication of lost interrupts. I also run a 386 at home, 2.3.1, with two 2400 lines and a 9600, all on dumb ports. No problem. Where have you seen this? | Scott "The Pseudo-Hacker" Neugroschl | UUCP: ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge -- bill davidsen (wedu@ge-crd.arpa) {uunet | philabs}!steinmetz!crdos1!davidsen "Stupidity, like virtue, is its own reward" -me
abcscnge@csuna.csun.edu (Scott "The Pseudo-Hacker" Neugroschl) (03/19/89)
In article <13366@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: ]In article <1751@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: ] ]| Any Xenix users out there want to talk about losing RS-232 interrupts during ]| disk access because of this? ] ] I do. I run an original AT with xenix 2.1.3, with input coming in at ]2400, 9600, and via ethernet. I have never seen any indication of lost ]interrupts. I also run a 386 at home, 2.3.1, with two 2400 lines and a ]9600, all on dumb ports. No problem. ] ] Where have you seen this? 2.2.1, most notably during getty. Also during ASCII uploads (9600/7/1/odd)... Loses console and serial interrupts during disk access... Maybe I'm assuming the wrong reason, but I've had friends who wrote device drivers tell me that the disk is run from the CPU rather than DMA, and with interrupts disabled... Anyone familiar with Xenix Sys V 2.X internals know anything? P.S. This is on a True Blue AT339 (8MHz, 1MB (counting the genuine Intel Above Board), ST-4038 HD. -- Scott "The Pseudo-Hacker" Neugroschl UUCP: ...!sm.unisys.com!csun!csuna.csun.edu!abcscnge -- unless explicitly stated above, this article not for use by rec.humor.funny -- Disclaimers? We don't need no stinking disclaimers!!!
debra@alice.UUCP (Paul De Bra) (03/22/89)
In article <1774@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: >In article <13366@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes: >]In article <1751@csuna.csun.edu> abcscnge@csuna.csun.edu (Scott Neugroschl) writes: >... >2.2.1, most notably during getty. Also during ASCII uploads (9600/7/1/odd)... >Loses console and serial interrupts during disk access... Maybe I'm assuming >the wrong reason, but I've had friends who wrote device drivers tell me that >the disk is run from the CPU rather than DMA, and with interrupts disabled... > >Anyone familiar with Xenix Sys V 2.X internals know anything? > >P.S. This is on a True Blue AT339 (8MHz, 1MB (counting the genuine Intel >Above Board), ST-4038 HD. > I have done quite a bit of experimenting on an AT (8 Mhz and 10Mhz but that makes little difference) with 2.2.1. I have never had my system loose input from a serial line, even with 2 9600 baud incoming uucp connections. (i.e. no "alarm" messages) This in contrast to my new 25Mhz 386 box which looses interrupts with 1 incoming 19200 baud line if you attempt to do anything else. The serial interrupts normally have the highest priority. The only way I found to cause the serial lines to miss interrupts is to lower the priority and then cause some heavy activity on other devices. I wrote my own drivers (well, with a friend) for sound, for slow parallel printers, for ramdisks and none of this had any influence on the serial lines either or vice versa. An incoming uucp did not slow down the prelude by Bach being played on the speaker. The only thing that might cause problems and occasionally caused a glitch in Bach is switching between virtual consoles. That seems to take a "long" time while blocking interrupts. In any case the serial interrupts are handled much more efficiently in Xenix than in any other Unix implementation for the 286/386. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------