debra@alice.UUCP (Paul De Bra) (08/21/89)
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 suspect the problem is this: > [ long explanation deleted ] Most device-drivers are a combination of interrupt-driven and polling drivers. Normally the device (parallel interface in this case) causes an interrupt when it is ready to accept a character. The kernel handles the interrupt (by sending a character to the interface, or by remembering that the device is ready) and goes back to doing whatever it was doing. When the interface has sent the character to the printer and the printer is ready for the next character the interface will again generate an interrupt. This is interrupt- mode behaviour. Normally, the kernel also checks (at some rate, which may well be the HZ rate) whether the interface is ready (by peeking at a status register). This is done because interrupts may be lost during higher priority interrupts. This is polling behaviour. In some cases the time between sending the character to the printer and the printer indicating it is ready always results in the kernel missing the interrupt. In that case the kernel does recover using the polling scheme, but will only print HZ characters per second. I actually experienced this on a combination of an AT-clone and an Epson MX100 printer. At cpu-speeds of 8 and 10 Mhz printing was slow. At 9 Mhz (i changed the cristal) printing was normal. One feasible solution is to write your own device driver which only does polling. It must not just send a character when the printer is ready, but then enter a short busy loop in which it waits for the interface to be ready again. If the interface is ready in time, the kernel sends another character, and loops again... If the interface is not ready in time the kernel gives up and tries again at the next clock tick. Such a device driver is a real cpu hog because of the busy loops. When my AT was printing bitmaps the device driver would consume up to 50% of the cpu-time. But printing was fast. Hope this sheds some light on the issue. Paul. -- ------------------------------------------------------ |debra@research.att.com | uunet!research!debra | ------------------------------------------------------
psfales@cbnewsc.ATT.COM (Peter Fales) (08/22/89)
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. This sounds so much like a problem I had, that I have to mention it, even though it may not be related to your problem. 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. Just a thought. -- Peter Fales AT&T, Room 5B-420 2000 N. Naperville Rd. UUCP: ...att!peter.fales Naperville, IL 60566 Domain: peter.fales@att.com work: (312) 979-8031
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*."