From rfg@monkeys.com Mon Nov  8 14:09:16 1999
Return-Path: <rfg@monkeys.com>
Received: from monkeys.com (i180.value.net [206.14.136.180])
	by hub.freebsd.org (Postfix) with ESMTP id 952BF14BE4
	for <FreeBSD-gnats-submit@freebsd.org>; Mon,  8 Nov 1999 14:09:04 -0800 (PST)
	(envelope-from rfg@monkeys.com)
Received: (from rfg@localhost)
	by monkeys.com (8.9.3/8.9.3) id OAA32534;
	Mon, 8 Nov 1999 14:08:21 -0800 (PST)
Message-Id: <199911082208.OAA32534@monkeys.com>
Date: Mon, 8 Nov 1999 14:08:21 -0800 (PST)
From: "Ronald F. Guilmette" <rfg@monkeys.com>
Reply-To: rfg@monkeys.com (Ronald F. Guilmette)
To: FreeBSD-gnats-submit@freebsd.org
Subject: /dev/lpt0 doesn't work unless/until you do `lptcontrol -e'
X-Send-Pr-Version: 3.2

>Number:         14787
>Category:       kern
>Synopsis:       /dev/lpt0 doesn't work unless/until you do `lptcontrol -e'
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-bugs
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Mon Nov  8 14:10:01 PST 1999
>Closed-Date:    Thu Aug 17 22:41:28 PDT 2000
>Last-Modified:  Thu Aug 17 22:42:41 PDT 2000
>Originator:     Ronald F. Guilmette
>Release:        FreeBSD 3.3-RELEASE i386
>Organization:
E-Scrub Technologies, Inc.
>Environment:

	Attempting to print a Postscript to my Postscript-capable HP LaserJet
	5MP printer (via `cat' to /dev/lpt0).

>Description:

	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.

>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.

>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.


>Release-Note:
>Audit-Trail:

From: mark tinguely <tinguely@web.cs.ndsu.nodak.edu>
To: freebsd-gnats-submit@FreeBSD.org, rfg@monkeys.com
Cc:  
Subject: Re: kern/14787: /dev/lpt0 doesn't work unless/until you do `lptcontrol 
 -e'
Date: Wed, 16 Aug 2000 09:41:04 -0500

 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
 
 

From: mark tinguely <tinguely@web.cs.ndsu.nodak.edu>
To: freebsd-gnats-submit@FreeBSD.org, rfg@monkeys.com
Cc:  
Subject: Re: kern/14787: /dev/lpt0 doesn't work unless/until you do `lptcontrol 
 -e'
Date: Wed, 16 Aug 2000 18:44:12 -0500

 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.
 
 
 
State-Changed-From-To: open->feedback 
State-Changed-By: sheldonh 
State-Changed-When: Thu Aug 17 02:52:14 PDT 2000 
State-Changed-Why:  
Waiting to hear what Ronald has to say about Mark's 
input. 


http://www.freebsd.org/cgi/query-pr.cgi?pr=14787 

From: Sheldon Hearn <sheldonh@uunet.co.za>
To: mark tinguely <tinguely@web.cs.ndsu.nodak.edu>
Cc: freebsd-gnats-submit@FreeBSD.org
Subject: Re: kern/14787: /dev/lpt0 doesn't work unless/until you do `lptcontrol -e' 
Date: Thu, 17 Aug 2000 11:52:05 +0200

 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.
 
State-Changed-From-To: feedback->closed 
State-Changed-By: sheldonh 
State-Changed-When: Thu Aug 17 22:41:28 PDT 2000 
State-Changed-Why:  
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. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=14787 
>Unformatted:
