johnl@esegue.uucp (John R. Levine) (09/01/89)
In article <2589@cbnewsc.ATT.COM> psfales@cbnewsc.ATT.COM (Peter Fales) writes: >In article <1989Aug10.191352.8363@esegue.uucp>, johnl@esegue.uucp (John Levine) writes: >> I am running 386/ix 2.0.2 on a 25MHz Intel clone, to which I have attached >> an HP Deskjet printer with the usual parallel interface. It works, but the >> printer runs at a small fraction of the speed at which it runs when I'm >> running DOS. >I had an AT&T 6386 WGS with a Deskjet printer that worked fine under DOS, >but ran terribly slowly (a few characters/second) when I started running >UNIX/386. After much trial and error, the problem turned out that another >card in the system, a network card that I hadn't even installed the driver >for, was tied to the same interrupt as the parallel interface. Once I >pulled that card out the system, things started working fine. Well, what do you know. I have an ethernet card for which I haven't installed the driver, the rest of the network being several hundred miles away. I moved it from interrupt 7 to interrupt 2, and now the printer works fine. I gather that there is some aspect of the 8259 interrupt controller chip so that if an interrupt request comes and goes away, as happens with the unlatched printer request line, the 8259 interrupts anyway on level 7. (That was reputed to be the excuse for not latching the printer request so they could avoid a 50 cent flip-flop on the card.) Did the network card make that fail, or is it more likely that having two devices on the same interrupt line made the printer unable to request the interrupt in the first place? Perhaps someone with more 8259 combat experience would know. -- John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 492 3869 {ima|lotus}!esegue!johnl, johnl@ima.isc.com, Levine@YALE.something Massachusetts has 64 licensed drivers who are over 100 years old. -The Globe
kdg@nirvo.uucp (Kurt Gollhardt) (09/03/89)
In article <1989Sep1.004003.6311@esegue.uucp> johnl@esegue.UUCP (John Levine) writes: >I gather that there is some aspect of the 8259 interrupt controller chip so >that if an interrupt request comes and goes away, as happens with the >unlatched printer request line, the 8259 interrupts anyway on level 7. >(That was reputed to be the excuse for not latching the printer request so >they could avoid a 50 cent flip-flop on the card.) Did the network card >make that fail, or is it more likely that having two devices on the same >interrupt line made the printer unable to request the interrupt in the first >place? Perhaps someone with more 8259 combat experience would know. If an interrupt request goes away after the 8259 has interrupted the CPU, when the CPU asks the 8259 for the vector, it has to supply one anyway, so it gives a 7 (arbitrary). But it's possible, by checking status registers of the 8259, to determine whether this is a real interrupt 7 or not. In UNIX, this is done, and fake interrupt 7s are discarded. In your case, I would say that the network card must have been actively driving the interrupt line to a false state, preventing the interrupt from ever getting to the 8259. This is not always what happens when two cards are on the same interrupt line, but it's one of the possible scenarios; depends on how both cards are designed. In general, you can't arbitrarily share interrupts on the AT bus. First, as your case illustrates, many cards are not designed to expect this to occur, and "take over" the interrupt line assuming nothing else will use it. Second, the 8259(s) on these machines are used in a mode (edge-triggered) which is not compatible with sharing interrupts; if you attempt to, and the two (or more) interrupt requests ever overlap, only the first one will be seen. On the other hand, MCA was specifically designed to allow interrupt sharing. The 8259s are used in level-triggered mode and the way boards must interface to the request lines are specified so as to allow sharing to work. -- Kurt Gollhardt \ Nirvonics, Inc. -- Plainfield, NJ Kurt.Gollhardt@nirvo.uucp /\ Software Design and Consulting ...!rutgers!nirvo!Kurt.Gollhardt / \ "It's all about people; not you and me or him and her, but *us*."