From owner-freebsd-hackers@FreeBSD.ORG Wed Aug 27 17:00:35 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 5F36616A4BF for ; Wed, 27 Aug 2003 17:00:35 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net (pintail.mail.pas.earthlink.net [207.217.120.122]) by mx1.FreeBSD.org (Postfix) with ESMTP id 993D643F93 for ; Wed, 27 Aug 2003 17:00:34 -0700 (PDT) (envelope-from andrei@andruxa.sytes.net) Received: from h-68-164-157-51.snvacaid.covad.net ([68.164.157.51] helo=andruxa.sytes.net) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 19sADF-0006Hi-00 for hackers@freebsd.org; Wed, 27 Aug 2003 17:00:30 -0700 Received: from andruxa.sytes.net (localhost [127.0.0.1]) by andruxa.sytes.net (8.12.9/8.12.9) with ESMTP id h7S00MDe001197 for ; Wed, 27 Aug 2003 17:00:22 -0700 (PDT) (envelope-from andrei@andruxa.sytes.net) Received: (from andrei@localhost) by andruxa.sytes.net (8.12.9/8.12.9/Submit) id h7S00HdV001196 for hackers@freebsd.org; Wed, 27 Aug 2003 17:00:17 -0700 (PDT) Date: Wed, 27 Aug 2003 17:00:16 -0700 From: Andrew Konstantinov To: hackers@freebsd.org Message-ID: <20030828000016.GA669@andruxa.sytes.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jRHKVT23PllUwdXP" Content-Disposition: inline User-Agent: Mutt/1.4.1i Subject: /dev/lpt0 - always busy, except when acpi is disabled 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: Thu, 28 Aug 2003 00:00:35 -0000 --jRHKVT23PllUwdXP Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hello, I am running: FreeBSD xxxxxxx.xxxxx.xxx 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Aug 26 21:02:35 PDT 2003 root@xxxxxxx.xxxxx.xxx:/usr/obj/usr/src/sys/CUSTOM i386 I have a problem accessing the printer connected to the box via parallel port. Whenever I try to send something to /dev/lpt0, it always responds with 'device busy' error message, while that device is not being used by any other program. This behavior started once I upgraded to 5.1-release and continues through 'current.' When I was using 5.0-release, the system worked fine and I never had this problem, but once I upgraded, this mystery started to happen. Here is some background info. My kernel configuration file contains the following devices: device ppc device ppbus # Parallel port bus (required) device lpt # Printer device ppi # Parallel port interface device PPC hints in the /boot/device.hints file are: hint.ppc.0.at="isa" hint.ppc.0.irq="7" As you can see, irq number is specified, so the system is supposed to communicate with the printer in interrupt-driven mode. But, for some misterious reason that doesn't happen. Here is the part of my dmesg output related to pp* and lpt: ppc0 port 0-0x7 on acpi0 ppc0: Generic chipset (ECP/PS2/NIBBLE) in COMPATIBLE mode ppbus0: on ppc0 lpt0: on ppbus0 lpt0: Polled port ppi0: on ppbus0 As you can see, the communication is carried out in polled mode. I am not sure why...? I was going back and forth trying to make the printer work and found a 'solution' for that problem. The 'solution' is to disable acpi. hint.acpi.0.disabled="1" - works like a charm. After disabling acpi I get the ability to use my printer and the following dmesg output: ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppbus0: on ppc0 ppbus0: IEEE1284 device found /NIBBLE Probing for PnP devices on ppbus0: ppbus0: PRINTER ESCPL2,BDC,D4 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 As I already mentioned, this never happened when my box was running 5.0-release, but started to happen right after the moment when I upgraded to 5.1-release, and continues to happen on 5.1-current. I am wondering if this is a bug in the source code and can only be fixed with a patch, or there is a work around through acpi configuration? ACPI manual page says that one can disable parts of acpi through 'debug.acpi.disable' kernel environment variable. In that case, what is the minimal set of sub-devices that I would temporarly have to disable to resolve this problem? Perhaps I got right in the middle of ongoing work with acpi? Any hints, pointers or links will be greatly appreciated! Thanks in advance. Andrew --jRHKVT23PllUwdXP Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/TUYQttaE8kbpwrARAjrNAKCARJndH2TvHu+5oulWan+JknUsPgCgpohv bXwG+DOfLy/n+DXTAZvNCI4= =p5xp -----END PGP SIGNATURE----- --jRHKVT23PllUwdXP--