[lug] Re lpc status and sh

[D. Stimits]

Rob Mohr wrote:
> 
> Hello,
> 
> Well, the permission denied error was my fault, I read a deja comp.linux
> ng and followed the lead, but the party really meant, I believe on
> reflection, lpc status.  Doing that I get back
> lp:
>      queuing is enable
>      printing is enabled
>      3 entries in spool area
>      waiting for lp to become ready (offline ?)

This would tend to follow the idea of either a cable type, bios setting,
or kernel function that is required for two-way communications is
missing. An old cable (I think IEEE 1488 is the required type now that I
think about it) doesn't have all wires in it, so it can't communicate
except in one direction. Bios can be told to set the parallel port to a
one-way type, rather than a more intelligent standard (which matches
older cables). And the kernel requires support for this functionality as
well. The fact that something is waiting for lp to go online probably
means that the kernel has the ability to know to ask, but it may not
reflect actual port configuration and cable as being capable of
replying.

> Blue:#
> 
> On another post and thread to the same usenet group someone suggested the
> following sh script to check and verify.
> # sh
> # for a in /dev/lp*
> > do
> > echo "This is $a^L" >> $a
> > done
> 
> And the result of the above is
> 
> sh: /dev/lp1: Device not configured
> sh: /dev/lp2: Device not configured


Do you have more than one printer? It would be lp0 for the first printer
most of the time.


> Blue:#
> 
> A little bit of context.  I installed this debian potato this past july
> onto a 486.  Have used it for pine.  And it did ascii print from the pine
> session ok, no stair case.  And when I first fired up x session and
> mozzila browser, I test printed a page.  This first page caused a
> configuration window to pop up.  IIRC, that page did go ok.  Also, after
> the initial install I believe I did a successful test print of ls >
> /dev/lp0.  After that I had to box things up and move.  Now, last week, I
> started into LaTeX.  Got to the part foo.txt foo.dvi foo.ps and gv works
> fine on the x viewing window.  But trying to print all marked or all just
> kicks out seven-ten blank pages.  And lpr -p foo.txt just kicks out one
> page with the top header of the date-time stamp, filename, and page 1;
> that is it, just a blank page below. Finally, trying enscript foo.txt
> gives a staircase and about seven-ten blank pages.  (at first I was
> getting a "media A2 not found" error.  I patched the enscript.cfg file to
> include a line with A2 and the parameters that matched with "letter"
> media.

Postscript I think specifies media. It sounds like a ghostscript and/or
printcap entry has an inappropriate default paper size. I'm far from
proficient with this, I'd have to sit down and spend half a day
experimenting to get a better idea of what the problem is. You might
find a postscript page that displays well in ghostview, and then print
it with "lpr whatever.ps". See what that does, but in case it thinks it
is straight text, be ready to cancel, it'll be a big waste of paper if
it tries to print it as ascii. Hmm, that reminds me, make sure your
mozilla is set to print via lpr and not directly to lp0. Plus, before
you do more, maybe use lprm to remove existing queued items.

> 
> One more bit of info.  The deb install was almost nominal, but the PC did
> crash in the middle, once, twice.  And at that time I had trouble getting
> the dialup going.  "Hostname not found."  Per help from this list, I was
> missing a two line configuration file.  The minicom & wvdial setups did
> not generated this needed file.

No telling what would be missing in that case.

> 
> Here, too, I am *guessing* that I am missing a file.  Call it hanging on a
> file  Again, per a usenet post I did
> cat /etc/conf.modules And it returned No such file or directory.

/etc/conf.modules is also named modules.conf sometimes, depending on
distribution. That file is not mandatory, but if you use something that
requires kernel support, and that support is missing, a process is
started to search for the missing module (assuming the missing support
is for a /dev/ major number; having major number support but not minor
will not trigger this process), and modules.conf is consulted for
alternate names of modules, and any special cleanup or initialization.
RH always has this during install, I don't know if this is a problem for
your debian. But a typical problem is that if you monitor
/var/log/messages, e.g., "tail -f -n 30 /var/log/messages", and you try
to do something requiring support that is missing, it'll say something
like "modprobe: Can't locate module char-major-4". So a key here might
be to monitor that log while attempting to print, and seeing if such a
message appears. Or if such a message appears in general during normal
operation of your machine. Then you can figure out what device is
missing support, or at least missing an alias to identify existing
support by a new name.

> 
> cat /proc/parport/0/devices reported the same as above.
> 
> cat /proc/parport/0/hardware returns
> base:   0x378
> irq:    none
> dma:    none
> modes:  SPP

My /proc/ is quite different, maybe you have a 2.2.x kernel, I have
2.4.x. Or if you have 2.4.x, maybe you are using devfs, which I try hard
to avoid (when devfs is cleaned up I'll be a fan, it isn't ready yet
though). Anyway, my version of procfs and parport modes:
PCSPP,TRISTATE,COMPAT,ECP

It is your "SPP" that worries me, I think probably it should have "ECP"
if your printer is moderately recent...meaning it can use an IEEE 1488
cable correctly and talk to the computer. If your printer is an ink jet
and not a simple ascii dot matrix printer, this is almost certain.

> 
> And from my dmesg log (abridged here)
> parport0: PC-style at 0x378 [SPP]
> parport_probe: failed
>   NO PCI SUPPORT.
> parport0: no IEEE-1284 device present.

Hmm, maybe the thing I've called IEEE 1488 is really IEEE 1284...it's
been a long time since I looked at that. But here you are guaranteed
that your printer is not able to reply to queries about its status, at
least not in extended ways that go beyond old dot matrix printers. You
probably want to try recompiling a kernel that has ECP support, and PCI
(even if your 486 doesn't have PCI slots, it is possible it still has an
internal PCI bus for ports).

Does anyone here happen to know off hand if the two-way modern parallel
port cable spec is 1488 or 1284? If not 1488, can someone remind me of
what devices 1488 applies to (I'm a bit vague here, I must be getting
old)?

> lp0: using parport0 (polling).
> lp0 offline
> end of log file right after the preceeding line of lp0 offline
> 
> I will go back and re-read the printing HOWTO but I doubt if it will get
> me going.  My printer is an HP LaserJet 4L, which I belive is PostScript
> compliant.

This almost certainly requires ECC parallel port support in the kernel.
Now maybe it is possible your parallel port itself is old enough it
doesn't support this, but I doubt it. Add PCI support and ECC support in
the kernel. If you already have that, monitor /var/log/messages and see
if there is a note about "Can't locate module....".

> 
> One usenet post regarding "lp0 off-line" mentions having to recompile the
> kernel. I have read a bit about compiling, but I have not done that
> before.  I am under the impression that if something is left outside of
> the kernel, a module may be "started up later" via a command line
> operation.  From my viewpoint, espcially when lpq has print jobs pending
> an "offline printer" I am missing a device module vis-a-vis the kernel?

Modules can be inserted later, but automatic insert requires the device
major support also be modular. History: Major number is a category of
device, minor number is a specific device. Each piece of hardware
generally has a major number, and variations might or might not require
extra modules. A good sample is the joystick, which requires ns558
support and PCI support for the port, plus you also need a module for
joystick generic support; once you have that yet another module is
required depending on whether it is analog, or some digital type.
Printer support could be enough to print, but then the port itself might
need PCI and ECP support.

As for modules and kernel compiling, you must compile modules using
kernel source that exactly matches your running kernel. Never ever
delete the .config file, or even alter it, once you have a running
kernel. Save it, store it, archive it. Then if you want to later add
modules, you can use that config file to create a matching kernel tree,
and in some cases, add modules after-the-fact. If your kernel source is
too far off, new module compiles will fail to insert. So most likely you
will have to install a new kernel, and not just a module. But there is
no reason you have to get rid of your old kernel, it can be kept as
default until you are sure you have what you want. Just be sure that the
new kernel has a slightly different version than what you now run, else
it might overwrite the old modules.

D. Stimits, stimits at idcomm.com

> 
> Rob Mohr
> eof
> 
> _______________________________________________
> Web Page:  http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug