From owner-freebsd-current Thu Jun 22 12:13:13 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id MAA21006 for current-outgoing; Thu, 22 Jun 1995 12:13:13 -0700 Received: from eikon.regent.e-technik.tu-muenchen.de (root@eikon.regent.e-technik.tu-muenchen.de [129.187.42.3]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id MAA20999 for ; Thu, 22 Jun 1995 12:13:07 -0700 Received: from vector.eikon.e-technik.tu-muenchen.de ([129.187.142.36]) by eikon.regent.e-technik.tu-muenchen.de with SMTP id <55303>; Thu, 22 Jun 1995 21:12:48 +0200 Received: (from jhs@localhost) by vector.eikon.e-technik.tu-muenchen.de (8.6.11/8.6.9) id RAA00867 for current@freebsd.org; Thu, 22 Jun 1995 17:15:17 +0200 Date: Thu, 22 Jun 1995 17:15:17 +0200 From: Julian Howard Stacey Message-Id: <199506221515.RAA00867@vector.eikon.e-technik.tu-muenchen.de> To: current@freebsd.org Subject: kernel response Sender: current-owner@freebsd.org Precedence: bulk This is mainly for our Kernel & Parallel Port Driver people (David, & Geoff Rehmet ? ) When I print via the standard spooler (lpr -#2), a 300K file, going to an hp3p laser via a parallel port, all screen updating goes dead for several seconds, ( the -#2 doubles the data, doesnt use the PCL5 print twice escape sequence). My config is: X11R6pl11+XFree86_3.1.1 33MHz 486, 16M RAM, FreeBSD current, swapinfo: swapinfo Device 1K-blocks Used Avail Capacity Type /dev/sd0s2b 32768 11456 21248 35% Interleaved /dev/sd2s3b 32768 11440 21264 35% Interleaved kernel conf: device lpt0 at isa? port 0x378 tty irq 7 vector lptintr device lpt1 at isa? port 0x278 tty (only lpt0 connected) dmesg reports lpt0 at 0x378-0x37f irq 7 on isa lpt0: Interrupt-driven port lp0: TCP/IP capable interface lpt1 at 0x278-0x27f on isa All other task were quiescent, there was no serial or ether traffic (other ether device powered off, so no broadcast stuff either) I had X running, 2 ghostviews, 6 xterms (all quiescent) no crontab driven system resource leaching stuff, & all my hard drives were quiescent. The keystrokes I typed while the OS went signle mindedly about flushing its file to laser were latched, & my vi in xterm did finally respond to go up screen 4 lines (without screen roll, so not even a screen redraw needed), but the response was abysmal (reminded me of the bad old days of inbuilt print software under Wordstar ;-) The laser has 4M of extension RAM, so it wasnt overflow causing weird errors, The data was a .pcl file previously produced by Ghostscript from a .ps (I dont have a Postscript cartridge in my laser, I guess if one did, it might stop FreeBSD flow periodically, to process data, thus giving FreeBSD a chance to to service other requests, but I have nothing to stop the full 600K of data being sent to the parallel port). So it seems the parallel port output flush is running at too high a priority for too long. If I've forgotten to mention something, please let me know. -- -- -- -- -- -- -- -- -- -- Julian Stacey Recommended , Alternate Localhost