Date: Thu, 22 Jun 1995 17:15:17 +0200 From: Julian Howard Stacey <jhs@vector.eikon.e-technik.tu-muenchen.de> To: current@freebsd.org Subject: kernel response Message-ID: <199506221515.RAA00867@vector.eikon.e-technik.tu-muenchen.de>
next in thread | raw e-mail | index | archive | help
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 <JHS@FreeBSD.Org>, Alternate <jhs@regent.e-technik.tu-muenchen.de> Localhost <jhs@vector.eikon.e-technik.tu-muenchen.de>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199506221515.RAA00867>