From owner-freebsd-hackers@FreeBSD.ORG Tue Jul 22 13:41:20 2003 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 5D13037B401 for ; Tue, 22 Jul 2003 13:41:20 -0700 (PDT) Received: from main.gmane.org (main.gmane.org [80.91.224.249]) by mx1.FreeBSD.org (Postfix) with ESMTP id 5512443FAF for ; Tue, 22 Jul 2003 13:41:19 -0700 (PDT) (envelope-from freebsd-hackers@m.gmane.org) Received: from root by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19f3vZ-00015E-00 for ; Tue, 22 Jul 2003 22:40:05 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-hackers@freebsd.org Received: from news by main.gmane.org with local (Exim 3.35 #1 (Debian)) id 19f3jv-00008l-00 for ; Tue, 22 Jul 2003 22:28:03 +0200 From: othermark Date: Tue, 22 Jul 2003 20:28:03 +0000 (UTC) Lines: 32 Message-ID: X-Complaints-To: usenet@main.gmane.org User-Agent: slrn/0.9.7.4 (FreeBSD) Sender: news Subject: sys/dev/ppbus/lpt.c "advanced mode not available, polling" X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Jul 2003 20:41:20 -0000 I posted a message earlier to -stable, but maybe this a better forum for this question. I have a print server at home running -stable, and as part of bootup I run lptcontrol -e to enable extended mode on the port (since it comes up in compatible mode, I could set this with flags in the kernel). It seems without doing this, things sent to the printer take forever to print. During anysort of print operation I get thousands of these messages, generated by line 788 of sys/dev/ppbus/lpt.c: 786 case EINVAL: 787 /* advanced mode not avail */ 788 log(LOG_NOTICE, LPT_NAME "%d: advanced mode not avail, polling\n", unit); 789 break; This is quite annoying, so I wanted to know why I was getting this message because it seems that it occurs even with just lptcontrol -p. I was wondering if there's any reason why this could not be done in the case with EINVAL was returned from ppb_write() instead of just complaining about it foreach call to ppb_write(). Something like: sc->sc_irq &= (~LP_ENABLE_EXT); sc->sc_irq |= LP_ENABLE_IRQ; added to the EINVAL case block. --- Mark atkin901 at NOSPAM yahoo dot com (!wired)?(coffee++):(wired);