[PARPORT] "SOS"

From: carlz@stic.net
Date: Mon Mar 27 2000 - 10:54:08 EST

  • Next message: cpg@aladdin.de: "Re: [PARPORT] PCI slot Parallel cards"

    HELP !!

    I have been stuck on a problem for several weeks
    now and AFTER reviewing every piece of documentation I can find and
    scanning the Web for hours (including this site), I can't find anything
    that address my problem.

    In brief, I have installed Slakware's Linux Release 7.0. My printer was
    running fine until then. NO! This is NOT the "lp0" problem (I did read
    the parport.txt file). But it has similar symptoms.

    Here is what I get from 'lpc' when I try to "start" the printer:

                   STV:
                        printing enabled
                  lpc: connect: Connection refused
                       couldn't start deamon

    "STV" is the name for the printer. It looks as if my "lpc" program can
    not establish a socket into parport.

    A second problem, can anyone tell me how to re-establish the "/dev/printer="
    socket ? I managed to delete it on one of my machines while trying to
    make this work. It is correctly in place on all of the other machines.

    Some clues:

      - I get this message if I am logged in as "carlz" (me) or "root".

      - The printer works just fine if I issue something like:
                    cat xyz.txt > /dev/lp0

        This leads me to believe that the package "parport" is working
        correctly; how else could I talk to the printer via "lp0" if it
        weren't ?

      - STV is the only printer [parallel port device] on the computer.

      - Printer also works correctly under DOS and was working OK under
        Linux 2.0.35 (the old version of 'lp').
     
      - I think I have the "printcap" file set up correctly. Here is an
        extraction from it:

           STV|lp|hpj:\
                   :lp=/dev/null:\
                   :lf=/tmp/lp_log:\
            :sd=/usr/spool/lp1:\
            :mx#0:\
            :if=/usr/spool/lp1/hpjlp:\
            :sh:

        Note, that in this version I had redirected "lp=" to /dev/null, just
        to see what happened. Normally it was assigned to /dev/lp0. Same
        effect either way.

     - I also believe my spool directories and files are set up OK.
       /usr/spool/lp1/hpjlp looks like this:

                     #!/usr/bin/perl
                     print 'E';
                     while(<STDIN>)
                     {
                       chomp;
                       printf("%s\r\n",$_);
                     };
                     
       Again this was working OK under 2.0.35.

      - In one exercise I removed printcap and the spool files and then used
        the "setup" utility packaged with the AFS filter programs to attempt to
        set it up. Same result.

      - Another clue; I have several computers on my local network ranging from
        old 386s to an AMD-K2-6/350. As I convereted each over to 2.2.13 (Slakware
        7.0) they started having the same problem (which I did not notice at
        first because only two machines have a printer on them.)

      - Suspecting "permissions" might be the problem I have done a
        chmod 777 on all files involved (printcap, /usr/spool ...) and
        also their parent directories.

      - Oh, almost forgot, here are some of the important "proc" files:

    ---------------------------------------- parport's "tree" (/proc/parport/0):
    -r--r--r-- 1 root root 0 Mar 26 07:32 autoprobe
    -r--r--r-- 1 root root 0 Mar 26 07:32 devices
    -r--r--r-- 1 root root 0 Mar 26 07:32 hardware
    -rw-r--r-- 1 root root 0 Mar 26 07:32 irq

    autoprobe:
      (empty)

    devices:
     lp

    hardware:
      base: 0x378
      irq: none
      dma: none
    modes: SPP,PS2

    irq:
      none

    Could this be the problem; i.e. irq = none ?
    On my main test machine, the AMD K2-6, the i/o ports (serial and parallel)
    are built into the mother-board. I am presently still booting off of diskette
    (both the bare.i immage and one that I compiled; both have this problem.)
    Do these pre-canned images force parport to a particular irq (e.g. 7) ?

    ---------------------------------------- modules:
      
    iBCS 135456 0
    ide-scsi 6924 0
    aha152x 28932 0 (unused)
    sr_mod 16380 0 (unused)
    sg 14872 0 (unused)
    sd_mod 17116 0 (unused)
    scsi_mod 58280 5 [ide-scsi aha152x sr_mod sg sd_mod]
    ne 6448 1
    8390 5888 0 [ne]
    uart401 5872 0
    sound 57176 0 [uart401]
    soundlow 224 0 [sound]
    soundcore 2116 3 [sound]
    ppp 20428 0 (unused)
    slhc 4300 0 [ppp]
    lp 5660 0 (unused)
    parport_pc 5588 1
    parport 6724 1 [lp parport_pc]

    ---------------------------------------- devices:

    Character devices:
      1 mem
      2 pty
      3 ttyp
      4 ttyS
      5 cua
      6 lp
      7 vcs
     10 misc
     14 sound
     21 sg
     29 fb
     30 socksys
    128 ptm
    129 ptm
    136 pts
    137 pts

    Block devices:
      1 ramdisk
      2 fd
      3 ide0
      7 loop
      8 sd
      9 md
     43 nbd

    ---------------------------------------- interrupts:
               CPU0
      0: 2429526 XT-PIC timer
      1: 711 XT-PIC keyboard
      2: 0 XT-PIC cascade
      4: 18991 XT-PIC serial
      5: 57980 XT-PIC NE2000
      8: 1 XT-PIC rtc
      9: 85 XT-PIC aha152x
     13: 0 XT-PIC fpu
     14: 223018 XT-PIC ide0
    NMI: 0

    ---------------------------------------- ioports:
    0000-001f : dma1
    0020-003f : pic1
    0040-005f : timer
    0060-006f : keyboard
    0070-007f : rtc
    0080-008f : dma page reg
    00a0-00bf : pic2
    00c0-00df : dma2
    00f0-00ff : fpu
    0140-015f : aha152x
    01f0-01f7 : ide0
    02f8-02ff : serial(auto)
    0300-031f : NE2000
    0378-037a : parport0
    03c0-03df : vga+
    03f6-03f6 : ide0
    03f8-03ff : serial(auto)
    ffa0-ffa7 : ide0
    ffa8-ffaf : ide1

    Thank you very much. I hate to bother anybody about this, but I have run
    out of ideas.

    Carl Zettner
    carlz @ stic.net

    -- To unsubscribe, send mail to: linux-parport-request@torque.net --
    -- with the single word "unsubscribe" in the body of the message. --



    This archive was generated by hypermail 2b29 : Mon Mar 27 2000 - 12:00:06 EST