From owner-freebsd-questions@FreeBSD.ORG Fri Apr 7 20:33:03 2006 Return-Path: X-Original-To: freebsd-questions@freebsd.org Delivered-To: freebsd-questions@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id E014E16A404 for ; Fri, 7 Apr 2006 20:33:03 +0000 (UTC) (envelope-from oliver-forward@charter.net) Received: from mxsf05.cluster1.charter.net (mxsf05.cluster1.charter.net [209.225.28.205]) by mx1.FreeBSD.org (Postfix) with ESMTP id F1BFE43D53 for ; Fri, 7 Apr 2006 20:33:00 +0000 (GMT) (envelope-from oliver-forward@charter.net) Received: from mxip26a.cluster1.charter.net (mxip26a.cluster1.charter.net [209.225.28.181]) by mxsf05.cluster1.charter.net (8.12.11/8.12.11) with ESMTP id k37KWxIj017317 for ; Fri, 7 Apr 2006 16:32:59 -0400 Received: from 24-205-236-185.dhcp.snlo.ca.charter.com (HELO linux.linux) ([24.205.236.185]) by mxip26a.cluster1.charter.net with ESMTP; 07 Apr 2006 16:32:59 -0400 X-IronPort-AV: i="4.04,98,1144036800"; d="scan'208"; a="978484928:sNHT22283302" From: Oliver Iberien To: freebsd-questions@freebsd.org Date: Fri, 7 Apr 2006 13:32:57 -0700 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200604071332.57717.oliver-forward@charter.net> Subject: printing on firefox results in irq storm on printer port X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Apr 2006 20:33:04 -0000 I was printing with native Firefox 1.5.0.1 (FreeBSD 6.0) with CUPS, which Firefox sees and recognizes. The printer (Xerox N17, local, parallel port) started cycling through waiting-processing-waiting messages. Rebooting, I saw a message about an IRQ storm on the printer port being "throttled". Killing the job took care of this. Has anyone else had an issue like this? Firefox printing isn't critical but it's always nice to know what's going on. Oliver Incidentally, killing the job required a crash course in lppasswd and the cupsd.conf file, which I'll describe briefly here for the record... lppasswd stores encrypted passwords for cups administrative functions. The format is lppasswd -g group -a user. Permissions to various parts of the cupsd administrative functions (interface at http://localhost:631/admin) are set in the various location sections of /usr/local/etc/cupsd.conf. The various parameters than can be set are at http://www.cups.org/doc-1.1/sam.html.