Bug 18352

Summary: Parallel printer does not work
Product: Base System Reporter: gburditt <gburditt>
Component: kernAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: 4.0-RELEASE   
Hardware: Any   
OS: Any   

Description gburditt 2000-05-02 20:20:02 UTC
On switching to FreeBSD-4.0-RELEASE from FreeBSD-3.3-RELEASE, I discovered
that my parallel-port printer no longer works - it appears to be
permanently offline after the first open.  lpd sits there generating
no output even if something is queued.  On the other hand, if I move 
the printer to another system, also running FreeBSD-4.0-RELEASE, it works.

There are two systems involved.  'hammy' has a stupid parallel port
not capable of special modes:
	ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
	ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode
	ppi0: <Parallel I/O> on ppbus0
	lpt0: <Printer> on ppbus0
	lpt0: Interrupt-driven port
	plip0: <PLIP network interface> on ppbus0
This port works.  (It wasn't booted with the printer attached).

'mouse' has a "more capable" parallel port, but the BIOS is set up to
use it in 'normal' mode, however, the kernel seems to insist on
detecting special modes anyway:

	ppc0: <Parallel port> at port 0x378-0x37f irq 7 on isa0
	ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
	ppbus0: IEEE1284 device found /NIBBLE/PS2/ECP
	Probing for PnP devices on ppbus0:
	ppbus0: <HEWLETT-PACKARD DESKJET 870C> PCL,MLC,PML
	ppi0: <Parallel I/O> on ppbus0
	lpt0: <Printer> on ppbus0
	lpt0: Interrupt-driven port
	plip0: <PLIP network interface> on ppbus0
This port appears to be permanently not ready, except that
sometimes when booting single-user, I can get in one 
"cat /etc/passwd > /dev/lpt0" before it locks up (and the
result appears on the printer).  If lpd gets first shot at the 
printer, nothing comes out even though it has something queued 
for printing.

The two systems have nearly-identical kernels, the differences
being in the interrupts for sio2 and sio3, and 'mouse' has
a second ethernet card.  No, IRQ 7 is not being shared.
One test on 'mouse' with a GENERIC kernel demonstrated that the
problem isn't specific to my kernel configuration (and I didn't
change anything related to the parallel port anyway).

I have tried setting EPP in the BIOS settings for the parallel 
port on 'mouse', and it didn't seem to make any difference.

The printer and its cable are not broken because it works on 'hammy'
and used to work on 'mouse' under FreeBSD-3.3.

The parallel port on 'mouse' and associated cabling is not broken because 
it (a) works under MS-DOS booted from floppy, (b) used to work under 
FreeBSD-3.3 without problems, and (c) seems to work sometimes for the first 
open under FreeBSD-4.0.  Interrupt settings for the port (if they
are even changable) haven't changed since FreeBSD 3.3 and they
worked with that.  I am reasonably convinced that this is not a 
problem with a loose cable.

lpd and apsfilter are not broken (or at least not the only problem)
because cat directly to /dev/lpt0 doesn't work either (with lpd either
killed off or not started on boot), with an apparent indefinite hang
waiting for the printer to become ready.  lpd and apsfilter worked
fine under FreeBSD-3.3.  They haven't been recompiled or reinstalled
for 4.0, but they should have appropriate old libraries available to work.

Use of lptcontrol to set modes doesn't work as this requires the 
printer to become ready, and it doesn't.  Neither system should 
have any problems using IRQ 7 with the parallel port.

Is there a problem with mode detection for some chipsets?

Fix: 

Well, attaching the printer to a different system with
	a stupid parallel port is a possibility, but annoying.
How-To-Repeat: 
	Well, on my system 'mouse', it's hard NOT to repeat.
	I think the problem involves ports capable of EPP or ECP
	since the system with the stupid port works fine.
Comment 1 Chris D.Faulhaber freebsd_committer freebsd_triage 2000-05-07 13:22:28 UTC
Responsible Changed
From-To: gnats-admin->freebsd-bugs

Misfiled PR 
Comment 2 Mike Barcroft freebsd_committer freebsd_triage 2001-07-22 02:57:08 UTC
State Changed
From-To: open->feedback


Does this problem still occur in newer versions of FreeBSD, 
such as 4.3-RELEASE?
Comment 3 Sheldon Hearn freebsd_committer freebsd_triage 2002-01-18 16:14:39 UTC
State Changed
From-To: feedback->closed

Automatic feedback timeout.  If additional feedback that warrants 
the re-opening of this PR is available but not included in the 
audit trail, please include the feedback in a reply to this message 
(preserving the Subject line) and ask that the PR be re-opened.