Bug 14787

Summary:	/dev/lpt0 doesn't work unless/until you do `lptcontrol -e'
Product:	Base System	Reporter:	Ronald F. Guilmette <rfg>
Component:	kern	Assignee:	freebsd-bugs (Nobody) <bugs>
Status:	Closed FIXED
Severity:	Affects Only Me
Priority:	Normal
Version:	3.3-RELEASE
Hardware:	Any
OS:	Any

Description Ronald F. Guilmette 1999-11-08 22:10:01 UTC

	Just doing `cat' of a postscript file to my Postscript printer
	(whose device name in /dev/lpt0) caused the lights on the printer
	to blink for awhile, but then nothing came out.

	After futzing around for awhile, I found (purely by trial and error)
	that using `lptcontrol -e' (on the default /dev/lpt0 device) allowed
	me to actually get the things that I was cat'ing to /dev/lpt0 printed
	by the printer.

	Obviously, on my system at least, the /dev/lpt0 device should, by
	default, START OUT in ``extended mode'' (whatever the heck that is).
	Otherwise, nothing prints, and the typical dumbo user (as exemplified
	by me) will be left scratching his head, wondering what the dickens
	is wrong.

Fix: 

Beats me.  If posible, perhaps the kernel should auto-detect cases
	where a given parallel port can support ``extended mode'' and it
	should then just set that port to that mode by default, at boot time.
How-To-Repeat: 
	Get an HP LaserJet 5MP (or any other pinter I suspect) and just plug
	it into the first parallel port of any standard/normal circt last 1997
	PeeCee.  Then try to cat some file to /dev/lpt0 and see if anything
	prints.  It won't.

Comment 1 tinguely 2000-08-16 15:41:04 UTC

Thank-you for the lpt and FreeBSD 3.x work-around for HP printers that
you posted
in the FreeBSD bugs database. I don' t have a fix, but  I believe the
problem is
at least partially found in flow control. I could print small files and
small
postscipts (< 10k) without requiring your suggestion,  but larger files
gives
the HP error code 22 (basically a data overrun). I had problems with the
new
serial driver too for this printer.

--mark tinguely

Comment 2 tinguely 2000-08-17 00:44:12 UTC

I did some more research  looking at the interrupt code and finally at
the probe/attach
code of the ppc driver and found that the  kernel configure flags of
0x40  used in the
GENERIC kernel configuration file (and I have been using to make my
kernels) affects
the detection of the ppc chipset which also affects the ability of the
interrupt code.

Removing the "flags 0x40" from the kernel configuration file  and making
a new kernel,
also removed my problems with the HP PS printer  in interupt mode.
I think the "flags 0x40"
should be removed from the GENERIC kernel configuration file.

--mark tinguely.

Comment 3 Sheldon Hearn 2000-08-17 10:52:05 UTC

On Wed, 16 Aug 2000 16:50:02 MST, mark tinguely wrote:

>  Removing the "flags 0x40" from the kernel configuration file and
>  making a new kernel, also removed my problems with the HP PS printer
>  in interupt mode.  I think the "flags 0x40" should be removed from
>  the GENERIC kernel configuration file.

So in other words, _enabling_ chipset detection for ppc(4) resolved your
problem?

The problem with removing this from GENERIC is that the BUGS section of
the manual page suggests that chipset detection causes problems for some
people.  Therefore, enabling the detection by default is going to cause
problems for other people, even though it would solve the problem for
you.

Unless someone suggests that the existing default causes problems for
more people than your proposed default would, I'd suggest that we leave
GENERIC as it is.

That said, if you'd like to draft a new FAQ entry for this, I'm sure the
freebsd-doc guys would be happy to incorporate it.

By the way, have you seen this FAQ entry?

	http://www.FreeBSD.org/FAQ/troubleshoot.html#AEN1554

Ciao,
Sheldon.

Comment 4 Sheldon Hearn freebsd_committer

2000-08-17 10:52:14 UTC

State Changed
From-To: open->feedback

Waiting to hear what Ronald has to say about Mark's 
input.

Comment 5 Sheldon Hearn freebsd_committer

2000-08-18 06:41:28 UTC

State Changed
From-To: feedback->closed

Ronald isn't in a position to track this further and is 
convinced that the problem related to specific hardware 
which he no longer has available. 

While that doesn't mean there isn't some problem to be  
solved, this PR isn't going to help us solve it any more. 

Thanks for the feedback, Ronald.