From: dond@sco.COM (don draper)
Subject: Re: A couple of questions
Organization: The Santa Cruz Operation, Inc.
Date: Mon, 23 Nov 1992 23:49:11 GMT


Two changes made to the parallel driver in Unix 3.2v4/
ODT 2.0 can cause slow printing.  

The first change is that either interrupt 5 or 
interrupt 7 can be used with each I/O base address.
In particular, address 0x3bc is no longer hard
coded to use interrupt 7 (it now defaults to 
interrupt 5).  Using the wrong interrupt forces the
driver to revert to polled mode.  Try reconfiguring 
the parallel port for the other interrupt using 
"mkdev lp".

The second change is that the polling interval for
the polled mode was increased from one clock tick 
to one second.  The attached item from our Information 
Tools database explains this in detail and provides 
a patch.


Regards,

Don 

-
Don Draper                    Support Engineer
dond@sco.COM      UUCP/Modems Technical Feature Specialist
uunet!sco!dond         The Santa Cruz Operation, Inc.
-


In article <kjell.722531469@abacus.hgs.se> kjell@abacus.hgs.se (KJELL HOLMGREN) writes:
>Hi all!
>
>I've just updated the ODT system to release 2.0 and immediatly I
>noticed that the printer goes so SLOW...What the f**k have SCO done
>with the drivers ?
>Now I just wonder if it's enough to change to the old drivers /dev/lp**
>from ODT 1.1 or is it some more files to ?
>
>Secondly is there any more annoying performance decreases in the new
>package ?
>
>I have just noticed one thing at the boot time that isn't right and that
>is a kind of "hanging". Directly after the 'loading text' message
>displays the system hangs, or if it takes itself to read the kernel
>it resets just before the hardware config should be displayed.
>The strange thing about it is that it don't happen everytime just now
>and then.
>Has anyone else had thoose problem ?
>
>Note: The machine that hangs is exactly the same that I run ODT 1.1 on 
>      with no problem at all.
>
>===============================================================================
>                ***********	               |\/\/\/|   I Kjell Holmgren    I
>             ***************	               |      |	  I  Tallbacksv. 23E  I
>     =======*****************=======           |      |	  I  811 41 SANDVIKEN I
>     |     *******************     |           | (o)(o)   I  SWEDEN
>     |     *******************     |           C      _)  I____________________ 
>     ======*******************======           |  ___|___/ 
>           ******       ******                 |   /
>            *****       *****                 /____\  
>             *****     *****                 /      \ 
>                ***   ***                                   
>					
>					kjell@abacus.hgs.se
>===============================================================================


Slow parallel printing patch for UNIX 3.2v4 and for XENIX 2.3.4 for MCA

KEYWORDS: v4 spooler printer tandy parallel _fst patch slow documentation unix 3.2 version 4 unix xenix 2.3.4 odt 2.0 hesitating nothing works lp0 lp1 lp2 0x378 0x3BC 0x278 irq 5 7

RELEASE:  SCO UNIX System V/386 Release 3.2 Operating System Version 4.0
          SCO Open Desktop Release 2.0.0
          SCO XENIX 386 Operating System Release 2.3.4 for computers based
              on Micro Channel Architecture (MCA)

PROBLEM:  I have a parallel printer that hesitates and hangs at end of each
          line -- or it prints erratically.

CAUSE:    A change was made to the parallel driver in Version 4.0 of the
          SCO UNIX Operating System, and in Release 2.3.4 of SCO XENIX for
          Micro Channel Architecture computers (but NOT in Release 2.3.4 for
          Industry Standard Architecture computers).  In these releases, the
          parallel driver polls only once per second instead of once per
          tick of the clock.  Thus, if the printer was relying on polling,
          it now prints 60 times slower than in the previous release.

SOLUTION: Polling is done only if, for some reason, the system is not
          receiving interrupts from the parallel port.  The most common
          reason for the system to miss interrupts from the parallel port is
          that the driver and the hardware disagree about which interrupt is
          being used for that port.  During the boot process, the driver
          prints a message indicating which interrupt is associated with
          which port, for example:

            %parallel 0x03BC-0x03BE       07      -       unit=1

          Before attempting any patches, make sure that the driver agrees
          with hardware settings.  Some but not all parallel port hardware
          has configurable interrupts.  It may be configured with jumpers
          or dipswitches on the hardware, or it may be configured through a
          setup program such as BIOS setup, EISA configuration utilities, or
          a Micro Channel Reference Disk.

          If the hardware cannot be configured, the driver can be configured
          in SCO UNIX Version 4.0, but not in SCO XENIX.  In UNIX, use the
          `mkdev parallel` command to change which interrupt is associated
          with which I/O address.

          If slow printing persists after the driver and the hardware have
          come to agree on interrupt numbers, the following patch may be
          used.  The patch restores the old behavior in which the parallel
          driver attempts to send characters to the printer at least once
          per clock tick (60 times per second under XENIX, and 100 times per
          second under SCO UNIX Version 4.0).  NOTE that this may have a
          negative effect on the overall performance of the system, 
          particularly while the printer is in use.

          You can use this patch with either polled or standard lp devices.

          Two versions of this patch are presented; one for UNIX and one
          for XENIX.  NOTE that this patch can only be applied to a
          pre-linked kernel because the data being patched is subject to
          relocation fixups by the linker.  Because the patch is applied to
          the kernel, you must re-apply the patch every time the kernel is
          relinked.

          For SCO UNIX System V/386 Release 3.2 Operating System Version 4.0
          and SCO Open Desktop Release 2.0
          ==================================================================

          The pound signs (#) and asterisks (*) are prompts from the system
          shell and from the patching program, /etc/_fst; do not type them in.

            # cd /
            # cp unix unix.save
            # /etc/_fst -w unix
            * papoll+59?w 1b8 0 a300           -> enter this value
            papoll+0x59: 0xa1= 0x1b8           -> values returned
            papoll+0x5b: 0x0=  0x0             ->     "
            papoll+0x5d: 0xa300= 0xa300        ->     "
            * paopen+1a0?w 1b8 0 a300          -> enter this value
            paopen+0x1a0: 0xa1= 0x1b8          -> values returned
            paopen+0x1a2: 0x0=  0x0            ->     "
            paopen+0x1a4: 0xa300= 0xa300       ->     "
            * $q

          Reboot the machine with shutdown(ADM)

          For SCO XENIX 386 Operating System Release 2.3.4 for computers
          based on Micro Channel Architecture (MCA)
          ==============================================================

          The pound signs (#) and asterisks (*) are prompts from the system
          shell and from the patching program, /etc/_fst; do not type them in.

            # cd /
            # cp xenix xenix.save
            # /etc/_fst -w xenix
            * papoll+58?w 1b8 0 a300           -> enter this value
            papoll+0x58: 0x14a1= 0x1b8         -> values returned
            papoll+0x5a: 0x32=   0x0           ->     "
            papoll+0x5c: 0xa300= 0xa300        ->     "
            * paopen+110?w 1b8 0 a300          -> enter this value
            paopen+0x1a0: 0x14a1= 0x1b8        -> values returned
            paopen+0x1a2: 0x32=  0x0           ->     "
            paopen+0x1a4: 0xa300= 0xa300       ->     "
            * $q

          Reboot the machine with shutdown(ADM)

=============================================================================

         IMPORTANT NOTE: If you do not get the expected responses from _fst,
         you need to abort the patch.  Enter "$q" at the * prompt, and copy
         the saved kernel back to its original name:

           # cp unix.save unix

                  or

           # cp xenix.save xenix

         If you find that your kernel does not function properly with the
         patch applied, you can back out of the patch by booting the saved
         kernel (enter "unix.save" or "xenix.save" at the Boot: prompt),
         then doing the above command.
-- 

-
Don Draper                    Support Engineer
dond@sco.COM      UUCP/Modems Technical Feature Specialist
uunet!sco!dond         The Santa Cruz Operation, Inc.
-
Newsgroups: biz.sco.opendesktop,comp.sys.sysv386